This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

(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.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]