Hi Frank, > -----Original Message----- > From: Frank Pagliughi [mailto:fpagliu...@mindspring.com] > Sent: 23. juni 2011 18:48 > To: John Dallaway > Cc: Christophe Coutand; eCos Development List > Subject: Re: Eagle 100 (Stellaris LM3S6918) > > On 06/23/2011 10:30 AM, John Dallaway wrote: > > 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. > > That makes some sense. But two things: > > (1) I worry a little about the implementation of a lot of code that I > wouldn't be able to test - like creating the plf_io.h definitions for > all 19 chips in the lm3s6xxx without the ability to test any but one. > But I suppose that would shake out in the long run.
The same dilemma applies to the lm3s8xx package that covers 9 chips. It's not possible to guarantee that the package will work on all devices without any bug fixing but I think the priority is to avoid duplicating code. > (2) I'm still unsure of how to implement the package when the different > chips have different memory sizes. A quick look through the existing > hal > and all I find is hard-coded constants in the pkgconfig files. One way to workaround that is to keep the memory layout in the board specific package. You can have something like: lm3s\lm3s6xxx -> code common to all 19 chips lm3s\ek_eagle100\ -> board specific code lm3s\ek_eagle100\include\pkgconf\ -> memory layout > For both those reasons, I started wondering if it wouldn't be better to > either create separate packages for each of the different individual > chips. That way each package would be relatively small, easy to > implement, and fully tested when implemented. But that would result in > over 180 packages just for Stellaris! > > > Then I thought maybe we group the chips by memory sizes, like a package > called "lm3s256x64" for all the chips with 256k Flash and 64k RAM. But > that would make it difficult to track chips by part number. > > > Regards > > > > John Dallaway > > eCos maintainer > > http://www.dallaway.org.uk/john > >
