From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4479 invoked by alias); 12 Mar 2010 11:11:13 -0000 Received: (qmail 4465 invoked by uid 22791); 12 Mar 2010 11:11:12 -0000 X-SWARE-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,BAYES_00,BOTNET,RDNS_NONE X-Spam-Check-By: sourceware.org Received: from Unknown (HELO postoffice.kontron.pl) (217.153.153.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Mar 2010 11:11:08 +0000 Received: from postoffice.kontron (localhost [127.0.0.1]) by postoffice.kontron.pl (Postfix) with ESMTP id D53BB666C2; Fri, 12 Mar 2010 12:14:50 +0100 (CET) Received: from jerzdy.rnd.kontron.pl (unknown [192.168.3.20]) by postoffice.kontron.pl (Postfix) with ESMTP id B90D2666BE; Fri, 12 Mar 2010 12:14:50 +0100 (CET) From: jerzy dyrda To: Daniel Helgason Date: Fri, 12 Mar 2010 11:11:00 -0000 User-Agent: KMail/1.9.9 Cc: ecos-devel@ecos.sourceware.org References: <201003081237.26940.jerzy.dyrda@kontron.pl> <1268331224.21484.17.camel@localhost.localdomain> In-Reply-To: <1268331224.21484.17.camel@localhost.localdomain> MIME-Version: 1.0 Message-ID: <201003121211.05358.jerzy.dyrda@kontron.pl> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [ECOS]Port to ARM9 STR9 uC X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.26/RELEASE build 1, bases: 20100312 #3772365, check: 20100312 notchecked Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2010-03/txt/msg00012.txt.bz2 Hi Daniel, On Thursday 11 March 2010 19:13:44 Daniel Helgason wrote: > On Mon, 2010-03-08 at 12:37 +0100, jerzy dyrda wrote: > > Announcing of other ARM9 port remember me that I should do it in the sa= me > > way i.e. Now I'm developing port to ARM9 STR9 uC -> > > http://www.st.com/mcu/modules.php?name=3Dmcu&file=3Ddevicedocs&DEV=3DST= R912FAW4 > >4&FAM=3D101 but as a reference board I use such board MMstr912 -> > > http://www.propox.com/products/t_163.html ( due to fact of lacking > > original ST development board but this board is very close to > > "original"). ... > Hi! Do you know if the STR9 shares same peripherals with the STR7 > devices? After first look I can say some yes RTC, WDG and maybe TIM seem similar res= t=20 no. General feeling is that they didn't use any FIFO.=20 Summarazing : I'm afaraid that differences between STR7 and STR9 are to big. > I have some eCos code for the STR7 and a few dev boards. I have to admit > it has been some time since I looked at it. I would be able help if you > thought that was a good idea. I very glad. I think any kind of help increase quality of software. =20 > With a little bit of planning maybe we could cover the whole family of > chips and avoid the mess that is happening trying to get AT91SAM9 into > the AT91SAM7 tree.=20 I agree it's good time to think about structure of ST HAL's layer. I implemented it in such manner : Drivers : devs/"type of driver"/arm/str9 and HAL hal/arm/str9/=20 with to directories board dependent "mmstr912" and common for STR9 "var" Every new development board will be located in hal/arm/str9/ with own name = as=20 it's doing for other hal implementation. >At the very least, maybe you could keep in mind that > somebody somewhere will want to add STR7 support and arrange your eCos > port accordingly. Maybe it should be created common stub hal/arm/st"something"/var which=20 provide hal function for STR9 and STR7 as well, platform dependent code as= =20 it's done i.e. "mmstr912". In turn drivers which are totally different=20=20 should be separated e.g. STR7 devs/"type of driver"/arm/str7 STR9 devs/"type of driver"/arm/str9 --=20 Mi=C5=82ego dnia / Best regards Jerzy Dyrda