AT91SAM7X Port

AT91SAM7X Port

[John Eigelaar]

Hi,

During the next week I wil be starting with a new project on the
AT91SAM7X256. I will definitely be using eCos for the project hence a few
questions:

* Has anyone done a port for the SAM7X, I don't want to re-invent the
wheel, if so where can I get hold of it ?

* If I have to roll my own would it be a good idea to patch the SAM7S port
to support the SAM7X as well or would it be better to start with a clean
SAM7X variant based on the SAM7S ?

Thanx for your time.

John Eigelaar

Re: AT91SAM7X Port

[Andrew Lunn]

On Fri, May 12, 2006 at 11:21:57AM +0200, John Eigelaar wrote:
> Hi,
> 
> During the next week I wil be starting with a new project on the
> AT91SAM7X256. I will definitely be using eCos for the project hence a few
> questions:
> 
> * Has anyone done a port for the SAM7X, I don't want to re-invent the
> wheel, if so where can I get hold of it ?

Not yet. There is a strong chance that i will need such a port next
month. If this happens i will be tasked by my employer to make the
port. So if you are doing a port i suggest we work together. Which of
the X peripherals are you interested in? I need an Ethernet driver
which i can connect to lwip.
 
> * If I have to roll my own would it be a good idea to patch the SAM7S port
> to support the SAM7X as well or would it be better to start with a clean
> SAM7X variant based on the SAM7S ?

My current feeling is add support for the X to the existing S.
Handling the ethernet driver should not be a problem. Make a cdl
interface in the AT91 ETH package which any HAL with the required
hardware supports should implement. Same goes for the CAM, and other
bits of hardware the X has but not the S.

What may be more of a problem is the two GPIO controllers. The
existing code, var HAL, SPI, USART etc, assumes that the pins they use
are on GPIO port A. If this is not true with the X it might get
messy. We need to compare the S and X and see what is connected where
with respect to the GPIO controllers.

The other change that will be needed is in the flash driver. It
queries the device ID to see if it is a supported device and how big
the flash is. This will need extending with the ID of the X.

Otherwise, i think a basic port should be quite easy.

      Andrew

Re: AT91SAM7X Port

[John Eigelaar]

On Fri, 12 May 2006 13:04:41 +0200, Andrew Lunn wrote:

> 
> Not yet. There is a strong chance that i will need such a port next
> month. If this happens i will be tasked by my employer to make the
> port. So if you are doing a port i suggest we work together. Which of
> the X peripherals are you interested in? I need an Ethernet driver
> which i can connect to lwip.

SPI, UART, EMAC with lwip, probably the same as you do ...

> 
> My current feeling is add support for the X to the existing S.
> Handling the ethernet driver should not be a problem. Make a cdl
> interface in the AT91 ETH package which any HAL with the required
> hardware supports should implement. Same goes for the CAM, and other
> bits of hardware the X has but not the S.

I agree, the X and the S is close enough to each other that you would be
missing out in terms of bug fixes and patches if you split them.

> 
> What may be more of a problem is the two GPIO controllers. The
> existing code, var HAL, SPI, USART etc, assumes that the pins they use
> are on GPIO port A. If this is not true with the X it might get
> messy. We need to compare the S and X and see what is connected where
> with respect to the GPIO controllers.

This is actually a problem with the existing S port as well, as the
alternative peripheral pinouts is not really addressed. This might be a
good oppurtunity to devise a proper solution for this if we are forced to.
 
> The other change that will be needed is in the flash driver. It
> queries the device ID to see if it is a supported device and how big
> the flash is. This will need extending with the ID of the X.

Should be straight forward ... (Famous last words)

> Otherwise, i think a basic port should be quite easy.
Agreed
 
John Eigelaar

Re: AT91SAM7X Port

[Andrew Lunn]

On Fri, May 12, 2006 at 02:05:13PM +0200, John Eigelaar wrote:
> On Fri, 12 May 2006 13:04:41 +0200, Andrew Lunn wrote:
> 
> > 
> > Not yet. There is a strong chance that i will need such a port next
> > month. If this happens i will be tasked by my employer to make the
> > port. So if you are doing a port i suggest we work together. Which of
> > the X peripherals are you interested in? I need an Ethernet driver
> > which i can connect to lwip.
> 
> SPI, UART, EMAC with lwip, probably the same as you do ...

I don`t need SPI. However the existing AT91 SPI driver compiles
cleanly with the SAM7S. So it just needs testing...

> > What may be more of a problem is the two GPIO controllers. The
> > existing code, var HAL, SPI, USART etc, assumes that the pins they use
> > are on GPIO port A. If this is not true with the X it might get
> > messy. We need to compare the S and X and see what is connected where
> > with respect to the GPIO controllers.
> 
> This is actually a problem with the existing S port as well, as the
> alternative peripheral pinouts is not really addressed. This might be a
> good oppurtunity to devise a proper solution for this if we are forced to.

If i remember correctly, i did add them to var_io.h. However nothing
actually uses them.

         Andrew