public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* AT91SAM7X Port
@ 2006-05-12  9:25 John Eigelaar
  2006-05-12 11:05 ` Andrew Lunn
  0 siblings, 1 reply; 4+ messages in thread
From: John Eigelaar @ 2006-05-12  9:25 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AT91SAM7X Port
  2006-05-12  9:25 AT91SAM7X Port John Eigelaar
@ 2006-05-12 11:05 ` Andrew Lunn
  2006-05-12 12:05   ` John Eigelaar
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Lunn @ 2006-05-12 11:05 UTC (permalink / raw)
  To: John Eigelaar; +Cc: ecos-devel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AT91SAM7X Port
  2006-05-12 11:05 ` Andrew Lunn
@ 2006-05-12 12:05   ` John Eigelaar
  2006-05-12 12:09     ` Andrew Lunn
  0 siblings, 1 reply; 4+ messages in thread
From: John Eigelaar @ 2006-05-12 12:05 UTC (permalink / raw)
  To: ecos-devel

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AT91SAM7X Port
  2006-05-12 12:05   ` John Eigelaar
@ 2006-05-12 12:09     ` Andrew Lunn
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2006-05-12 12:09 UTC (permalink / raw)
  To: John Eigelaar; +Cc: ecos-devel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-12 12:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-12  9:25 AT91SAM7X Port John Eigelaar
2006-05-12 11:05 ` Andrew Lunn
2006-05-12 12:05   ` John Eigelaar
2006-05-12 12:09     ` Andrew Lunn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).