eCos on AT91SAM9 - call to action

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

eCos on AT91SAM9 - call to action

John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

Grant Edwards-6
On 2011-03-16, John Dallaway <[hidden email]> 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!

Reply | Threaded
Open this post in threaded view
|

AW: eCos on AT91SAM9 - call to action

Richard Rauch
In reply to this post by John Dallaway-2
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: [hidden email]
 
_______________________________________________

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:   [hidden email]
 
Geschaeftsfuehrer: Richard Rauch
Handelsregister: Nuernberg HR B 21676
USt-Id Nr. : DE228051873
_______________________________________________

-----Ursprüngliche Nachricht-----
Von: [hidden email]
[mailto:[hidden email]] 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


Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

Martin Laabs
In reply to this post by John Dallaway-2
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

Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

Martin Laabs
In reply to this post by John Dallaway-2
Hello,

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

[hidden email]:SOMP-eCos.3.git

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

Greetings,
  Martin Laabs

Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

John Eigelaar-4
In reply to this post by John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

John Eigelaar-4
> > 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


Reply | Threaded
Open this post in threaded view
|

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

John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

Re: eCos on AT91SAM9 - call to action

Frank Pagliughi
In reply to this post by John Eigelaar-4
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Eagle 100 (Stellaris LM3S6918)

John Dallaway-2
In reply to this post by Frank Pagliughi
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
Reply | Threaded
Open this post in threaded view
|

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: [hidden email] [mailto:[hidden email]] 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
Reply | Threaded
Open this post in threaded view
|

Re: Eagle 100 (Stellaris LM3S6918)

John Dallaway-2
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
Reply | Threaded
Open this post in threaded view
|

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
>

Reply | Threaded
Open this post in threaded view
|

RE: Eagle 100 (Stellaris LM3S6918)

Christophe Coutand
Hi Frank,

> -----Original Message-----
> From: Frank Pagliughi [mailto:[hidden email]]
> 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
> >

12