From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5525 invoked by alias); 23 Jun 2011 14:31:33 -0000 Received: (qmail 5515 invoked by uid 22791); 23 Jun 2011 14:31:32 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 14:31:15 +0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110623143055.NZVY16165.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Thu, 23 Jun 2011 15:30:55 +0100 Received: from cog.dallaway.org.uk ([213.106.80.48]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110623143055.TTUM20122.aamtaout01-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Thu, 23 Jun 2011 15:30:55 +0100 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id p5NEUnFw017031; Thu, 23 Jun 2011 15:30:49 +0100 Message-ID: <4E034E19.4030609@dallaway.org.uk> Date: Thu, 23 Jun 2011 14:31:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Christophe Coutand , Frank Pagliughi CC: eCos Development List Subject: Re: Eagle 100 (Stellaris LM3S6918) References: <4D809BF2.6040205@dallaway.org.uk> <4D8208F0.5010500@kses.net> <4DFA071F.4060504@mindspring.com> <4DFA0DAA.3000601@dallaway.org.uk> <1308233778.22353.4.camel@hp-study> <4DFA1320.7090500@mindspring.com> <4DFF64B3.9070507@mindspring.com> <4E007A9B.70800@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2011-06/txt/msg00020.txt.bz2 Hi Christophe and Frank Christophe Coutand wrote: > I had the same thinking as Frank when adding the lm3s family, i.e. create > a new package every time a new LM3S series is added, in the present case, > a new lm3s6xxx layer that covers all 19 devices. > > The interrupt mapping in lm3s/var/include/var_intr.h should cover all series > as far as I could see. Few interrupts are currently missing, they shall be > filled as new series are added. The lm3s/var/include/var_io.h can be extended > to include Ethernet, CAN, USB register definitions etc.. I use the > lm3s8xx/include/plf_io.h to refine the set of peripherals included in each > device of the 800 series. Since sub-series of the 6000 series have different > memory sizes, the memory layout must be included in the board specific package. > > In addition, current device drivers for the LM3S (I2C, ADC) are only > constrained to use the LM3S HAL and not constrained by series or sub-series. > In practice, this means that using the LM3S ADC driver with the LM3S800 for > instance, will not raise any dependency error during configuration. Since the > LM3S800 does not have an ADC peripheral, the lm3s8xx/include/plf_io.h will not > allow the lm3s/var/include/var_io.h to define the ADC registers, therefore, > the ADC driver will not compile. I believed this to be ok, users most have a > minimal knowledge of the hardware in use. As long as the refining of definitions performed in the "LM3S series" HAL packages such as lm3s8xx provide information that is truly specific to that series and cannot be inferred simply by testing for the presence of various peripheral driver packages, then I don't see any problem here and it would make sense for Frank to follow this pattern by creating an lm3s6xxx HAL package. Regards John Dallaway eCos maintainer http://www.dallaway.org.uk/john