From: "Christophe Coutand" <ccoutand@stmi.com>
To: "John Dallaway" <john@dallaway.org.uk>,
"Frank Pagliughi" <fpagliughi@mindspring.com>
Cc: "eCos Development List" <ecos-devel@ecos.sourceware.org>
Subject: RE: Eagle 100 (Stellaris LM3S6918)
Date: Tue, 21 Jun 2011 16:34:00 -0000 [thread overview]
Message-ID: <D6050C555CC56940A7AF326522830276041C822F@mail2.STMIRV01.COM> (raw)
In-Reply-To: <4E007A9B.70800@dallaway.org.uk>
Hi John and Frank
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.
John, is that way off?
Christophe
-----Original Message-----
From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of John Dallaway
Sent: 21. juni 2011 13:04
To: Frank Pagliughi; Christophe Coutand
Cc: eCos Development List
Subject: Re: Eagle 100 (Stellaris LM3S6918)
Hi Frank and Christophe
Frank Pagliughi wrote:
> Hi, I was going to grab my SAM3 eval boards from the closet, but to make
> space for them on my desk I had to put away the Micromint Eagle 100
> board that was sitting there. Then got to thinking the Eagle 100 would
> be a really good board for eCos. It's a COTS board around a Stellaris
> LM3S6918 with a decent amount of I/O. I'm not an Ethernet guy, so I
> probably couldn't get networking going on the board, but could probably
> manage the rest of the port pretty quickly.
>
> I looked at the existing Stellaris eCos port for the lm3s8xx, and
> thought to make a corresponding lm3s6xxx. But on closer inspection, I
> found 19 processors in the 6000 series, all with different memory sizes
> and I/O. The only thing they share in common is that they have Ethernet
> but not CAN. The 8000 series has Ethernet and CAN. The 5000 series has
> CAN and USB. And so on...
>
> So the breakdown of the Stellaris series doesn't exactly mesh with eCos
> directory structure, since the chip internals may have more in common
> with chips across the different series than within it.
>
> So I'm at a loss on how to proceed. Any advice?
A quick glance of the parametric search table suggests that the various
sub-families of LM3S parts do indeed offer different permutations of
on-chip peripherals. I expect that all these parts can be accommodated
by extending the existing eCos LM3S8xx variant HAL package.
Christophe, do you concur?
John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john
next prev parent reply other threads:[~2011-06-21 16:34 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 [this message]
2011-06-23 14:31 ` John Dallaway
2011-06-23 16:48 ` Frank Pagliughi
2011-06-23 17:57 ` Christophe Coutand
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=D6050C555CC56940A7AF326522830276041C822F@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).