From: "Christophe Coutand" <ccoutand@stmi.com>
To: "Frank Pagliughi" <fpagliughi@mindspring.com>,
"John Dallaway" <john@dallaway.org.uk>
Cc: "eCos Development List" <ecos-devel@ecos.sourceware.org>
Subject: RE: Eagle 100 (Stellaris LM3S6918)
Date: Thu, 23 Jun 2011 17:57:00 -0000 [thread overview]
Message-ID: <D6050C555CC56940A7AF326522830276041C851E@mail2.STMIRV01.COM> (raw)
In-Reply-To: <4E036E37.8070100@mindspring.com>
Hi Frank,
> -----Original Message-----
> From: Frank Pagliughi [mailto:fpagliughi@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
> >
next prev parent reply other threads:[~2011-06-23 17:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 11:16 eCos on AT91SAM9 - call to action John Dallaway
2011-03-16 13:40 ` Grant Edwards
2011-03-16 14:31 ` AW: " Richard Rauch
2011-03-16 17:07 ` Martin Laabs
2011-03-16 18:18 ` John Dallaway
2011-03-16 18:35 ` Michael Bergandi
2011-03-17 10:14 ` Martin Laabs
2011-03-17 13:13 ` John Eigelaar
2011-06-16 13:38 ` Frank Pagliughi
2011-06-16 14:05 ` John Dallaway
2011-06-16 14:16 ` John Eigelaar
2011-06-16 14:27 ` eCos on AT91SAM3 [ was Re: eCos on AT91SAM9 - call to action ] John Dallaway
2011-06-16 14:29 ` eCos on AT91SAM9 - call to action Frank Pagliughi
2011-06-20 15:18 ` Eagle 100 (Stellaris LM3S6918) Frank Pagliughi
2011-06-20 16:17 ` Stanislav Meduna
2011-06-21 11:05 ` John Dallaway
2011-06-21 16:34 ` Christophe Coutand
2011-06-23 14:31 ` John Dallaway
2011-06-23 16:48 ` Frank Pagliughi
2011-06-23 17:57 ` Christophe Coutand [this message]
2011-07-10 20:38 ` Ilija Kocho
2011-07-12 8:57 ` Christophe Coutand
2011-07-13 14:52 ` Ilija Kocho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D6050C555CC56940A7AF326522830276041C851E@mail2.STMIRV01.COM \
--to=ccoutand@stmi.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=fpagliughi@mindspring.com \
--cc=john@dallaway.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).