[ECOS] ATSAM3U support?

[ECOS] ATSAM3U support?

[Mike DeSimone]

Guys,

I was wondering if anyone is working on supporting the Atmel ATSAM3U  
processor?

If not, I'm looking at trying to add it.  It's a Cortex-M3 core, so it  
should be at least something like the existing ST chip that has that  
core.  Does anyone have any pointers regarding porting?

The Atmel-recommended GCC toolchain is arm-eabi (or arm-none-eabi),  
and I have used these tools to build the demo programs.  Does anyone  
know if there are any problems with compiler/linker features with  
EABI? (ref: http://ecos.sourceware.org/fom/ecos?file=39)

Thanks for your time.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ATSAM3U support?

[Chris Holgate]

Mike DeSimone wrote:
> Guys,
> 
> I was wondering if anyone is working on supporting the Atmel ATSAM3U
> processor?
> 
> If not, I'm looking at trying to add it.  It's a Cortex-M3 core, so it
> should be at least something like the existing ST chip that has that
> core.  Does anyone have any pointers regarding porting?

The Cortex-M3 is quite helpful in this regard, since all implementations
use the same vectored interrupt controller.  That means all the
interrupt handling code from the STM32 port should work out of the box.
 You'll obviously have to change the interrupt map in var_intr.h to
match the new interrupt vector assignments of the Atmel part.

Memory setup will be very different between the two devices - especially
if you're planning to use external SRAM (recommended for development
purposes).  I'd say the order of business should be to get a very basic
ROM based eCos build done which you can put into internal FLASH via
JTAG, and which only uses the on-chip SRAM.  This will give you a basic
platform for writing and JTAG debugging the drivers for the UARTs and
static memory controller.  Once those are in place you should be able to
use a RAM based build with RedBoot debug for development of the other
peripheral drivers.

> The Atmel-recommended GCC toolchain is arm-eabi (or arm-none-eabi), and
> I have used these tools to build the demo programs.  Does anyone know if
> there are any problems with compiler/linker features with EABI? (ref:
> http://ecos.sourceware.org/fom/ecos?file=39)

The 'eCos standard' GCC/EABI toolchain provided by eCosCentric for the
V3.0 eCos release is well tested with the STM32.  I don't see a good
reason for using anything else.

Good luck with the port,

Chris.

-- 
Christopher J. Holgate

Thinking Of The Future @ Zynaptic Limited (www.zynaptic.com)

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss