From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9793 invoked by alias); 6 Nov 2009 12:07:45 -0000 Received: (qmail 9785 invoked by uid 22791); 6 Nov 2009 12:07:45 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from vicky.2020media.com (HELO smtp.2020smtp.net) (212.124.192.213) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 12:07:37 +0000 Received: from [212.124.199.38] (helo=hercules.zynaptic.com) by smtp.2020smtp.net with esmtp (Exim 4.63) (envelope-from ) id 1N6Nax-0001IM-3A; Fri, 06 Nov 2009 12:07:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by hercules.zynaptic.com (Postfix) with ESMTPA id EAE423FF8A; Fri, 6 Nov 2009 12:07:29 +0000 (GMT) Message-ID: <4AF41181.8020209@zynaptic.com> Date: Fri, 06 Nov 2009 12:07:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mike DeSimone CC: ecos-discuss@sources.redhat.com References: <6F98B979-9CF0-40BE-BD07-C476F84D1E55@arlut.utexas.edu> In-Reply-To: <6F98B979-9CF0-40BE-BD07-C476F84D1E55@arlut.utexas.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] ATSAM3U support? X-SW-Source: 2009-11/txt/msg00010.txt.bz2 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