This is the mail archive of the
mailing list for the eCos project.
Re: AT91SAM7X Port
- From: Andrew Lunn <andrew at lunn dot ch>
- To: John Eigelaar <jeigelaar at mweb dot co dot za>
- Cc: ecos-devel at sources dot redhat dot com
- Date: Fri, 12 May 2006 13:04:41 +0200
- Subject: Re: AT91SAM7X Port
- References: <firstname.lastname@example.org>
On Fri, May 12, 2006 at 11:21:57AM +0200, John Eigelaar wrote:
> 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
> * 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.