eCos on AT91SAM9 - call to action

eCos on AT91SAM9 - call to action

[John Dallaway]

All

There has been a lot of delay in getting AT91SAM9 support into the eCos
repository. Far too much delay. I think the best way forward now is to
focus on Evgeniy Dushitov's contribution (port for AT91SAM9263) initially:

  http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819

This seems sensible because:

a) The patches themselves are well abstracted.
b) Some people are already using these patches as a baseline for
   further AT91SAM9 ports.
c) There is support for running this port under QEMU, allowing
   wider testing.

I would like to invite everyone with an interest in AT91SAM9 support for
eCos to add themselves to the CC list for bug 1000819 and contribute to
the review process. Let's make this a community effort.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: eCos on AT91SAM9 - call to action

[Grant Edwards]

On 2011-03-16, John Dallaway <john@dallaway.org.uk> wrote:
> All
>
> There has been a lot of delay in getting AT91SAM9 support into the eCos
> repository. Far too much delay. I think the best way forward now is to
> focus on Evgeniy Dushitov's contribution (port for AT91SAM9263) initially:
>
>   http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819
>
> This seems sensible because:
>
> a) The patches themselves are well abstracted.
> b) Some people are already using these patches as a baseline for
>    further AT91SAM9 ports.
> c) There is support for running this port under QEMU, allowing
>    wider testing.
>
> I would like to invite everyone with an interest in AT91SAM9 support
> for eCos to add themselves to the CC list for bug 1000819 and
> contribute to the review process.

I'm in.

> Let's make this a community effort.

We're using a AT91SAM9 running Linux for one project, but I've been
keeping an eye on the eCos port and would be happy to see it move
forward.

-- 
Grant Edwards               grant.b.edwards        Yow! Now I'm concentrating
                                  at               on a specific tank battle
                              gmail.com            toward the end of World
                                                   War II!

AW: eCos on AT91SAM9 - call to action

[Richard Rauch]

Hi,

I will join too.
We are still working on a port for Atmels AT91SAM9G45. We have based our
port on the patches from Evgeniy.
This port we will contribute soon, too.

Richard


Richard Rauch
email: rrauch@itrgmbh.de
 
_______________________________________________

ITR GmbH 
Informationstechnologie Rauch 
Schnepfenreuther Hauptstrasse 27b
D-90425 Nuernberg
 
phone:  +49 (0) 911 3784437
VoIP:    +49 (0) 911 495221739
web:     http://www.itrgmbh.de
email:   info@itrgmbh.de
 
Geschaeftsfuehrer: Richard Rauch
Handelsregister: Nuernberg HR B 21676
USt-Id Nr. : DE228051873
_______________________________________________

-----Ursprüngliche Nachricht-----
Von: ecos-devel-owner@ecos.sourceware.org
[mailto:ecos-devel-owner@ecos.sourceware.org] Im Auftrag von John Dallaway
Gesendet: Mittwoch, 16. März 2011 12:16
An: eCos Development List
Betreff: eCos on AT91SAM9 - call to action

All

There has been a lot of delay in getting AT91SAM9 support into the eCos
repository. Far too much delay. I think the best way forward now is to focus
on Evgeniy Dushitov's contribution (port for AT91SAM9263) initially:

  http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819

This seems sensible because:

a) The patches themselves are well abstracted.
b) Some people are already using these patches as a baseline for
   further AT91SAM9 ports.
c) There is support for running this port under QEMU, allowing
   wider testing.

I would like to invite everyone with an interest in AT91SAM9 support for
eCos to add themselves to the CC list for bug 1000819 and contribute to the
review process. Let's make this a community effort.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: eCos on AT91SAM9 - call to action

[Martin Laabs]

Hello,

my port based on the one of Evgeniy Dushitov at the very beginning. However 
- after some weeks I discovered that it was very hard to support more CPUs 
out of the AT91SAM9 family with that code-base.
So I started from beginning, reusing only some code snipplet from Evgeniy. 
I made the decision to split the port into three packages.

The at91sam9 package contains all the stuff that is common to all at91sam9 
CPUs. The at91sam9260 package contains the CPU specific 
definitions/function and the board package handles all the board specific 
things like pin assignment, linker scripts etc.

I used the atmel register definitions to generate the includes for the 
register that are common to every at91sam9 cpu and the cpu specific parts. 
The names are not equal to the ones in the at91 packages - but its worth 
the price for a (nearly) complete register description that is also equal 
to the ones in the datasheets.

I also changed the pin handling to a somewhat better readable style. I.e.

#define SPI1_NPCS0 
AT91SAM9_PIN(AT91SAM9_PIN_TYPE_PERIPH_A,AT91SAM9_PIN_PORT_B, 3)

Currently we ported the SPI driver in polled and dma mode (including the 
cache coherency handling), the serial driver and ethernet peripheral. I 
also wrote code for the SSI but this is to application specific.

Board support is limited to the AT91SAM9260EK and our specific board. 
However we plan to add the olimex eval board of the AT91SAM9260 soon.

The include files for all other processors are generated as well. So 
porting to other CPUs and/or boards should be no great deal.

Currently we use our own GIT server. But I think we can open it for 
publicly - at least reading access. I will ask for permission to open the 
GIT server and publish the URL if someone want to look on the code base.

Greetings,
  Martin Laabs

Re: eCos on AT91SAM9 - call to action

[John Dallaway]

Hi Martin

Martin Laabs wrote:

> my port based on the one of Evgeniy Dushitov at the very beginning.
> However - after some weeks I discovered that it was very hard to support
> more CPUs out of the AT91SAM9 family with that code-base.
> So I started from beginning, reusing only some code snipplet from
> Evgeniy. I made the decision to split the port into three packages.

[ snip ]

It sounds like your input will be valuable. Please do track the
discussion in bug 1000819 and comment where appropriate. To be clear, I
still think it makes sense that we focus on Evgeniy's contribution and
modify it where necessary during the review.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: eCos on AT91SAM9 - call to action

[Michael Bergandi]

> Martin Laabs wrote:
>
>> my port based on the one of Evgeniy Dushitov at the very beginning.
>> However - after some weeks I discovered that it was very hard to support
>> more CPUs out of the AT91SAM9 family with that code-base.
>> So I started from beginning, reusing only some code snipplet from
>> Evgeniy. I made the decision to split the port into three packages.
>
> [ snip ]
>
> It sounds like your input will be valuable. Please do track the
> discussion in bug 1000819 and comment where appropriate. To be clear, I
> still think it makes sense that we focus on Evgeniy's contribution and
> modify it where necessary during the review.
>
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
>

I hope that a serious look at what Martin has to offer will be
considered before deciding on which contribution is used as a base.
IMHO, simply because an existing contribution is currently being used
in the community, that should not preclude a new contribution for
replacing it, if it is in fact a 'better' contribution. I haven't seen
or worked with either code base, so I have no vested interest either
way.

-- 
Mike

Re: eCos on AT91SAM9 - call to action

[Martin Laabs]

Hello,

as I announced I opened our git server for public read. The url is

git@git.assembla.com:SOMP-eCos.3.git

Have a look to packages/hal/arm/at91sam9/

Greetings,
  Martin Laabs

Re: eCos on AT91SAM9 - call to action

[John Eigelaar]

On 16/03/2011 13:16, John Dallaway wrote:
> All
>
> There has been a lot of delay in getting AT91SAM9 support into the eCos
> repository. Far too much delay. I think the best way forward now is to
> focus on Evgeniy Dushitov's contribution (port for AT91SAM9263) initially:
>
>    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819
>
> This seems sensible because:
>
> a) The patches themselves are well abstracted.
> b) Some people are already using these patches as a baseline for
>     further AT91SAM9 ports.
> c) There is support for running this port under QEMU, allowing
>     wider testing.
>
> I would like to invite everyone with an interest in AT91SAM9 support for
> eCos to add themselves to the CC list for bug 1000819 and contribute to
> the review process. Let's make this a community effort.
>
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
John
We, Keystone Electronic Solutions, have already done a Redboot port for 
the AT91SAM9X512 and AT91SAM9260 devices based on Evgeniy's patches if 
anybody is interested. I have no idea as to how up to date our patch is 
but I will be will to provide our source if anybody is interested.

I have also used the port to build some test applications for these 
devices but nothing enterprise level yet. We use the Redboot port as 
boot loader for our Linux platforms.

I have a personal copyright assignment for eCos, but will probably need 
a blanket company wide in order to contribute this work.

Regards
John Eigelaar

Re: eCos on AT91SAM9 - call to action

[Frank Pagliughi]

On 03/17/2011 09:13 AM, John Eigelaar wrote:
> On 16/03/2011 13:16, John Dallaway wrote:
>> All
>>
>> There has been a lot of delay in getting AT91SAM9 support into the eCos
>> repository. Far too much delay. I think the best way forward now is to
>> focus on Evgeniy Dushitov's contribution (port for AT91SAM9263) 
>> initially:
>>
>>    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819
>>
>> This seems sensible because:
>>
>> a) The patches themselves are well abstracted.
>> b) Some people are already using these patches as a baseline for
>>     further AT91SAM9 ports.
>> c) There is support for running this port under QEMU, allowing
>>     wider testing.
>>
>> I would like to invite everyone with an interest in AT91SAM9 support for
>> eCos to add themselves to the CC list for bug 1000819 and contribute to
>> the review process. Let's make this a community effort.
>>
>> John Dallaway
>> eCos maintainer
>> http://www.dallaway.org.uk/john
> John
> We, Keystone Electronic Solutions, have already done a Redboot port 
> for the AT91SAM9X512 and AT91SAM9260 devices based on Evgeniy's 
> patches if anybody is interested. I have no idea as to how up to date 
> our patch is but I will be will to provide our source if anybody is 
> interested.
>
> I have also used the port to build some test applications for these 
> devices but nothing enterprise level yet. We use the Redboot port as 
> boot loader for our Linux platforms.
>
> I have a personal copyright assignment for eCos, but will probably 
> need a blanket company wide in order to contribute this work.
>
> Regards
> John Eigelaar
>

Hey All,

What's the latest news on the AT91 chip sets?  From Bugzilla it appears 
that there will be some reshuffling.  I've been away from eCos for a few 
years, but am looking to start a project with a legacy AT91 then 
hopefully move it to a SAM3 in a few months.

Has anyone started work on the SAM3's?
How can I help?

Frank

Re: eCos on AT91SAM9 - call to action

[John Dallaway]

Hi Frank

Frank Pagliughi wrote:

> On 03/17/2011 09:13 AM, John Eigelaar wrote:
> 
>> On 16/03/2011 13:16, John Dallaway wrote:
>> 
>>> All
>>>
>>> There has been a lot of delay in getting AT91SAM9 support into the eCos
>>> repository. Far too much delay. I think the best way forward now is to
>>> focus on Evgeniy Dushitov's contribution (port for AT91SAM9263)
>>> initially:
>>>
>>>    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819
>>>
>>> This seems sensible because:
>>>
>>> a) The patches themselves are well abstracted.
>>> b) Some people are already using these patches as a baseline for
>>>     further AT91SAM9 ports.
>>> c) There is support for running this port under QEMU, allowing
>>>     wider testing.
>>>
>>> I would like to invite everyone with an interest in AT91SAM9 support for
>>> eCos to add themselves to the CC list for bug 1000819 and contribute to
>>> the review process. Let's make this a community effort.
>>>
>>> John Dallaway
>>> eCos maintainer
>>> http://www.dallaway.org.uk/john
>> 
>> John
>> We, Keystone Electronic Solutions, have already done a Redboot port
>> for the AT91SAM9X512 and AT91SAM9260 devices based on Evgeniy's
>> patches if anybody is interested. I have no idea as to how up to date
>> our patch is but I will be will to provide our source if anybody is
>> interested.
>>
>> I have also used the port to build some test applications for these
>> devices but nothing enterprise level yet. We use the Redboot port as
>> boot loader for our Linux platforms.
>>
>> I have a personal copyright assignment for eCos, but will probably
>> need a blanket company wide in order to contribute this work.
>>
>> Regards
>> John Eigelaar
> 
> Hey All,
> 
> What's the latest news on the AT91 chip sets?  From Bugzilla it appears
> that there will be some reshuffling.  I've been away from eCos for a few
> years, but am looking to start a project with a legacy AT91 then
> hopefully move it to a SAM3 in a few months.

Welcome back!

The information you quote above is still current and I will try to find
some time to push forward with the review of Evgeniy Dushitov's
contribution soon.

> Has anyone started work on the SAM3's?
> How can I help?

I am not aware of anyone working with eCos on AT91SAM3 hardware. There
are existing Cortex-M variant ports for eCos on LM3S8xx, LPC17xx and
STM32 processor families so I would expect variant support for AT91SAM3
to be fairly straightforward. Hopefully some of the existing AT91
drivers can be reused for AT91SAM3.

I am sure that others within the eCos community will be interested in
variant support for AT91SAM3. Be sure to let us all know if/when you
start work on this.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: eCos on AT91SAM9 - call to action

[John Eigelaar]

> > Has anyone started work on the SAM3's?
> > How can I help?
> 
> I am not aware of anyone working with eCos on AT91SAM3 hardware. There
> are existing Cortex-M variant ports for eCos on LM3S8xx, LPC17xx and
> STM32 processor families so I would expect variant support for AT91SAM3
> to be fairly straightforward. Hopefully some of the existing AT91
> drivers can be reused for AT91SAM3.
> 
> I am sure that others within the eCos community will be interested in
> variant support for AT91SAM3. Be sure to let us all know if/when you
> start work on this.


We, Keystone Electronic Solutions, did a port for the AT91SAM3U. The
port was completed and was using most of the AT91 drivers from the SAM7
family. We have, however, decided to use an STM32 part instead of the
SAM3. The port is still available if anybody is interested

> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john

eCos on AT91SAM3 [ was Re: eCos on AT91SAM9 - call to action ]

[John Dallaway]

Hi John

John Eigelaar wrote:

>>> Has anyone started work on the SAM3's?
>>> How can I help?
>> 
>> I am not aware of anyone working with eCos on AT91SAM3 hardware. There
>> are existing Cortex-M variant ports for eCos on LM3S8xx, LPC17xx and
>> STM32 processor families so I would expect variant support for AT91SAM3
>> to be fairly straightforward. Hopefully some of the existing AT91
>> drivers can be reused for AT91SAM3.
>>
>> I am sure that others within the eCos community will be interested in
>> variant support for AT91SAM3. Be sure to let us all know if/when you
>> start work on this.
> 
> We, Keystone Electronic Solutions, did a port for the AT91SAM3U. The
> port was completed and was using most of the AT91 drivers from the SAM7
> family. We have, however, decided to use an STM32 part instead of the
> SAM3. The port is still available if anybody is interested

Very interesting. Are you able to contribute the port to the eCos
project? This would involve assignment of copyright. Details at:

   http://ecos.sourceware.org/contrib.html

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: eCos on AT91SAM9 - call to action

[Frank Pagliughi]

On 06/16/2011 10:16 AM, John Eigelaar wrote:
>>> Has anyone started work on the SAM3's?
>>> How can I help?
>> I am not aware of anyone working with eCos on AT91SAM3 hardware. There
>> are existing Cortex-M variant ports for eCos on LM3S8xx, LPC17xx and
>> STM32 processor families so I would expect variant support for AT91SAM3
>> to be fairly straightforward. Hopefully some of the existing AT91
>> drivers can be reused for AT91SAM3.
>>
>> I am sure that others within the eCos community will be interested in
>> variant support for AT91SAM3. Be sure to let us all know if/when you
>> start work on this.
>
> We, Keystone Electronic Solutions, did a port for the AT91SAM3U. The
> port was completed and was using most of the AT91 drivers from the SAM7
> family. We have, however, decided to use an STM32 part instead of the
> SAM3. The port is still available if anybody is interested
>

Errr. Yeah. I guess you could send it to me. But maybe it would be 
better to formally submit it to eCos, and I can jump on it to test, 
validate, and patch if necessary. Plus I'm looking more to the SAM3S for 
this project, so could use your port to expand the offerings to a couple 
different SAM3 chip sets.

But I suppose the sooner the better. I'm also considering the STM32 for 
the upgrade, so better to get this done before I change my mind, like 
you did!

Thanks,
Frank

Eagle 100 (Stellaris LM3S6918)

[Frank Pagliughi]

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?

Thanks,
Frank

Re: Eagle 100 (Stellaris LM3S6918)

[Stanislav Meduna]

On 20.06.2011 17:18, Frank Pagliughi wrote:

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

Stellaris processors come with a StellarisWare driver library
(opensource, but only allowed to be used with their processor),
some of them even do have it in the processor's ROM. I don't know
the LM3S6918, but I worked with LM3S9B96 and getting an usable
Ethernet driver was a half day's job.

However, its license is 'You may not combine this software
with "viral" open-source software in order to form a larger
program' - i.e. if one intends to write something that can
be copyright-assigned and can become part of the 'official'
eCos, it can't be used.

> 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?

Forget that the peripherals are part of the chip and treat
them as devs/eth/... etc with dependencies on the
HAL/variant/whatever.

There are more gotchas, the chips come in quite a few
revisions that can differ significantly in what is in ROM,
what bugs are present (sometime grave ones) etc.

-- 
                                  Stano

Re: Eagle 100 (Stellaris LM3S6918)

[John Dallaway]

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

RE: Eagle 100 (Stellaris LM3S6918)

[Christophe Coutand]

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

Re: Eagle 100 (Stellaris LM3S6918)

[John Dallaway]

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

Re: Eagle 100 (Stellaris LM3S6918)

[Frank Pagliughi]

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
>

RE: Eagle 100 (Stellaris LM3S6918)

[Christophe Coutand]

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

Re: Eagle 100 (Stellaris LM3S6918)

[Ilija Kocho]

Hi  all

I am solving similar problems in a course of porting eCos to Kinetis so
I would discuss / propose some ways for CDL management of a large
controller family.

1. Part naming management

Dealing with big number of (similar) parts can be simplified for both
programmer and user, if device selector menu instead being a single
cdl_option, is broken in a number of cdl_options (grouped in
cdl_component). User will select chip features (or name segments) and
build a part.

2. Memory layout and feature management

2.1 Every option from cdl_component described in 1., if needed, can be
used in either CDL or C code as parameters, switches, etc.

2.2 Some of selected features can be further used to resolve memory
layout issues.
      - file name segments such as MLT files
      - defines for memory size and layout

You can find sources at
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001187
( component CYGHWR_HAL_CORTEXM_KINETIS in hal_cortexm_kinetis.cdl ).


3. Further considerations

In present post CYG_HAL_STARTUP is placed in the platform CDL, but I
think for chips without external memory it can be placed in variant CDL
with option (for provision for extension/override by platform). I am
exploring such possibility and am going to propose new attachment soon.

Every comment is welcome.

Regards
Ilija



On 23.06.2011 18:47, Frank Pagliughi wrote:
> 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
>>
>
>

RE: Eagle 100 (Stellaris LM3S6918)

[Christophe Coutand]

Hi Ilija,

1. Ideally as a user I prefer to select the device from a menu and get all the characteristics propagated from the selection. The CDL could have a component 
"Device characteristics" that lists all the peripherals included for the selected device, with internal memory size etc..). For a family with large number 
of sub-variants it can be a tedious work to write the CDL. To mitigate it in the lm3s HAL, some of the work is done in .h file (to select the peripherals for instance). 
The drawback is that it is no longer available from the configuration GUI therefore not visible to the users and also developers at first glance. If a common solution should be approved, I hope it will not add too much extra effort when developing a new port.

3. If none of the device can have external memory it makes sense to have the layout included in the variant HAL otherwise I am not sure it is worth the effort.

Regards,
Christophe

> -----Original Message-----
> From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-
> owner@ecos.sourceware.org] On Behalf Of Ilija Kocho
> Sent: 10. juli 2011 22:39
> To: ecos-devel@ecos.sourceware.org
> Subject: Re: Eagle 100 (Stellaris LM3S6918)
> 
> Hi  all
> 
> I am solving similar problems in a course of porting eCos to Kinetis so
> I would discuss / propose some ways for CDL management of a large
> controller family.
> 
> 1. Part naming management
> 
> Dealing with big number of (similar) parts can be simplified for both
> programmer and user, if device selector menu instead being a single
> cdl_option, is broken in a number of cdl_options (grouped in
> cdl_component). User will select chip features (or name segments) and
> build a part.
> 
> 2. Memory layout and feature management
> 
> 2.1 Every option from cdl_component described in 1., if needed, can be
> used in either CDL or C code as parameters, switches, etc.
> 
> 2.2 Some of selected features can be further used to resolve memory
> layout issues.
>       - file name segments such as MLT files
>       - defines for memory size and layout
> 
> You can find sources at
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001187
> ( component CYGHWR_HAL_CORTEXM_KINETIS in hal_cortexm_kinetis.cdl ).
> 
> 
> 3. Further considerations
> 
> In present post CYG_HAL_STARTUP is placed in the platform CDL, but I
> think for chips without external memory it can be placed in variant CDL
> with option (for provision for extension/override by platform). I am
> exploring such possibility and am going to propose new attachment soon.
> 
> Every comment is welcome.
> 
> Regards
> Ilija
> 
> 
> 
> On 23.06.2011 18:47, Frank Pagliughi wrote:
> > 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
> >>
> >
> >

Re: Eagle 100 (Stellaris LM3S6918)

[Ilija Kocho]

HI Christophe

Thank you for comments.

On 12.07.2011 10:53, Christophe Coutand wrote:
> Hi Ilija,
>
> 1. Ideally as a user I prefer to select the device from a menu and get all the characteristics propagated from the selection.

Menu may get veery big if you have hundreds (or even tens) of devices.
But if there's a system in naming you can use it in order to break the
menu in several small menus. But I saw Stellaris device portfolio and
now I think I understand you better...

>  The CDL could have a component 
> "Device characteristics" that lists all the peripherals included for the selected device, with internal memory size etc..). For a family with large number 
> of sub-variants it can be a tedious work to write the CDL.

Indeed, it can be challenging, but usually they all have a subset of a
same set of peripherals.
However there may be other reason to break them in several variants. For
instance memory size. Tiny devices (RAM <= 16KiB) like one you have
contributed recently may need different set-up than ones with larger
memory (RAM >= 32KiB). Also address different users.

>  To mitigate it in the lm3s HAL, some of the work is done in .h file (to select the peripherals for instance). 
> The drawback is that it is no longer available from the configuration GUI therefore not visible to the users and also developers at first glance. If a common solution should be approved, I hope it will not add too much extra effort when developing a new port.
> 3. If none of the device can have external memory it makes sense to have the layout included in the variant HAL otherwise I am not sure it is worth the effort.

I would say the variant CDL should be _preferred_ place for start-up
type and memory layout for "entirely single chip families". I wish I
would have done it in my previous ports.

And in order to illustrate it's usage for families that include external
memory I am presenting the CDL snippets below.

The variant CDL contains the familiar CYG_HAL_STARTUP, only promoted in
cdl_component. It contains CYG_HAL_STARTUP_VAR optiob that manages
on-chip memory resources and allows to be overriden by
CYG_HAL_STARTUP_PLF. For single chip members there will be no
CYG_HAL_STARTUP_PLF, and for members with external memory there will be
something like one in "Platform CDL" below. It contains entry ByVariant
that, when selected, enables CYG_HAL_STARTUP_VAR. Startups are
accompannies by respective memory layout options (not presented).

The result is a single, variant-wide copy of CDL components/options for
management of on-chip memory, and incremental CDL components/options for
board specific (external) memory resources where needed.

--- Variant CDL
--------------------------------------------------------------

    cdl_component CYG_HAL_STARTUP {
        display       "Startup type"
        flavor        data
        calculated  {
            (CYG_HAL_STARTUP_PLF && (CYG_HAL_STARTUP_PLF!="ByVariant")) ?
                                CYG_HAL_STARTUP_PLF : CYG_HAL_STARTUP_VAR
        }
        no_define
        define -file system.h CYG_HAL_STARTUP
        description   "
        Startup type defines what type of application shall be built.
        Startup type  can be defined by variant (CYG_HAL_STARTUP_VAR) or
        platform (CYG_HAL_STARTUP_PLF). If CYG_HAL_STARTUP_PLF
        is defined and not equal to 'ByVariant' then it shall
        override CYG_HAL_STARTUP_VAR."
   
        cdl_option CYG_HAL_STARTUP_VAR {
            display       "By variant"
            flavor        data
            default_value {"ROM"}
            legal_values  {"ROM" "SRAM"}
            no_define
            active_if ((!CYG_HAL_STARTUP_PLF) || \
                        (CYG_HAL_STARTUP_PLF=="ByVariant"))
            description   "Note: Variant startup type can be overriden
by Platform Startup Type."
        }
    }

--- Platform with external memory CDL
----------------------------------------

    cdl_option CYG_HAL_STARTUP_PLF {
        display       "By platform"
        flavor        data
        parent        CYG_HAL_STARTUP
        default_value {"RAM"}
        legal_values  {"ByVariant" "RAM" "JTAG"}
        no_define       
        description   "
        Startup tupes provided by the platform, in addition to variant
startup types.
        If 'ByVariant' is selected, then
        startup type shall be selected from the variant
(CYG_HAL_STARTUP_VAR).
        'JTAG' startup builds application similar to 'SRAM' but will use
external RAM.
        'RAM' startup builds application
        intended for loading by RedBoot into external RAM."
    }


Regards
Ilija


> Regards,
> Christophe
>
>> -----Original Message-----
>> From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-
>> owner@ecos.sourceware.org] On Behalf Of Ilija Kocho
>> Sent: 10. juli 2011 22:39
>> To: ecos-devel@ecos.sourceware.org
>> Subject: Re: Eagle 100 (Stellaris LM3S6918)
>>
>> Hi  all
>>
>> I am solving similar problems in a course of porting eCos to Kinetis so
>> I would discuss / propose some ways for CDL management of a large
>> controller family.
>>
>> 1. Part naming management
>>
>> Dealing with big number of (similar) parts can be simplified for both
>> programmer and user, if device selector menu instead being a single
>> cdl_option, is broken in a number of cdl_options (grouped in
>> cdl_component). User will select chip features (or name segments) and
>> build a part.
>>
>> 2. Memory layout and feature management
>>
>> 2.1 Every option from cdl_component described in 1., if needed, can be
>> used in either CDL or C code as parameters, switches, etc.
>>
>> 2.2 Some of selected features can be further used to resolve memory
>> layout issues.
>>       - file name segments such as MLT files
>>       - defines for memory size and layout
>>
>> You can find sources at
>> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001187
>> ( component CYGHWR_HAL_CORTEXM_KINETIS in hal_cortexm_kinetis.cdl ).
>>
>>
>> 3. Further considerations
>>
>> In present post CYG_HAL_STARTUP is placed in the platform CDL, but I
>> think for chips without external memory it can be placed in variant CDL
>> with option (for provision for extension/override by platform). I am
>> exploring such possibility and am going to propose new attachment soon.
>>
>> Every comment is welcome.
>>
>> Regards
>> Ilija
>>
>>
>>
>> On 23.06.2011 18:47, Frank Pagliughi wrote:
>>> 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
>>>>
>>>