* eCos on AT91SAM9 - call to action
@ 2011-03-16 11:16 John Dallaway
2011-03-16 13:40 ` Grant Edwards
` (4 more replies)
0 siblings, 5 replies; 23+ messages in thread
From: John Dallaway @ 2011-03-16 11:16 UTC (permalink / raw)
To: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
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
` (3 subsequent siblings)
4 siblings, 0 replies; 23+ messages in thread
From: Grant Edwards @ 2011-03-16 13:40 UTC (permalink / raw)
To: ecos-devel
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!
^ permalink raw reply [flat|nested] 23+ messages in thread
* AW: eCos on AT91SAM9 - call to action
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 ` Richard Rauch
2011-03-16 17:07 ` Martin Laabs
` (2 subsequent siblings)
4 siblings, 0 replies; 23+ messages in thread
From: Richard Rauch @ 2011-03-16 14:31 UTC (permalink / raw)
To: 'eCos Development List'
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
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-17 10:14 ` Martin Laabs
2011-03-17 13:13 ` John Eigelaar
4 siblings, 1 reply; 23+ messages in thread
From: Martin Laabs @ 2011-03-16 17:07 UTC (permalink / raw)
To: John Dallaway, ecos-devel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-03-16 17:07 ` Martin Laabs
@ 2011-03-16 18:18 ` John Dallaway
2011-03-16 18:35 ` Michael Bergandi
0 siblings, 1 reply; 23+ messages in thread
From: John Dallaway @ 2011-03-16 18:18 UTC (permalink / raw)
To: uni; +Cc: ecos-devel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-03-16 18:18 ` John Dallaway
@ 2011-03-16 18:35 ` Michael Bergandi
0 siblings, 0 replies; 23+ messages in thread
From: Michael Bergandi @ 2011-03-16 18:35 UTC (permalink / raw)
To: John Dallaway; +Cc: uni, ecos-devel
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-03-16 11:16 eCos on AT91SAM9 - call to action John Dallaway
` (2 preceding siblings ...)
2011-03-16 17:07 ` Martin Laabs
@ 2011-03-17 10:14 ` Martin Laabs
2011-03-17 13:13 ` John Eigelaar
4 siblings, 0 replies; 23+ messages in thread
From: Martin Laabs @ 2011-03-17 10:14 UTC (permalink / raw)
To: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-03-16 11:16 eCos on AT91SAM9 - call to action John Dallaway
` (3 preceding siblings ...)
2011-03-17 10:14 ` Martin Laabs
@ 2011-03-17 13:13 ` John Eigelaar
2011-06-16 13:38 ` Frank Pagliughi
4 siblings, 1 reply; 23+ messages in thread
From: John Eigelaar @ 2011-03-17 13:13 UTC (permalink / raw)
To: John Dallaway; +Cc: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-03-17 13:13 ` John Eigelaar
@ 2011-06-16 13:38 ` Frank Pagliughi
2011-06-16 14:05 ` John Dallaway
0 siblings, 1 reply; 23+ messages in thread
From: Frank Pagliughi @ 2011-06-16 13:38 UTC (permalink / raw)
To: John Eigelaar; +Cc: John Dallaway, eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
2011-06-16 13:38 ` Frank Pagliughi
@ 2011-06-16 14:05 ` John Dallaway
2011-06-16 14:16 ` John Eigelaar
0 siblings, 1 reply; 23+ messages in thread
From: John Dallaway @ 2011-06-16 14:05 UTC (permalink / raw)
To: Frank Pagliughi; +Cc: John Eigelaar, eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
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
0 siblings, 2 replies; 23+ messages in thread
From: John Eigelaar @ 2011-06-16 14:16 UTC (permalink / raw)
To: John Dallaway; +Cc: Frank Pagliughi, eCos Development List
> > 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* eCos on AT91SAM3 [ was Re: eCos on AT91SAM9 - call to action ]
2011-06-16 14:16 ` John Eigelaar
@ 2011-06-16 14:27 ` John Dallaway
2011-06-16 14:29 ` eCos on AT91SAM9 - call to action Frank Pagliughi
1 sibling, 0 replies; 23+ messages in thread
From: John Dallaway @ 2011-06-16 14:27 UTC (permalink / raw)
To: John Eigelaar; +Cc: Frank Pagliughi, eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: eCos on AT91SAM9 - call to action
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 ` Frank Pagliughi
2011-06-20 15:18 ` Eagle 100 (Stellaris LM3S6918) Frank Pagliughi
1 sibling, 1 reply; 23+ messages in thread
From: Frank Pagliughi @ 2011-06-16 14:29 UTC (permalink / raw)
To: John Eigelaar; +Cc: John Dallaway, eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Eagle 100 (Stellaris LM3S6918)
2011-06-16 14:29 ` eCos on AT91SAM9 - call to action Frank Pagliughi
@ 2011-06-20 15:18 ` Frank Pagliughi
2011-06-20 16:17 ` Stanislav Meduna
2011-06-21 11:05 ` John Dallaway
0 siblings, 2 replies; 23+ messages in thread
From: Frank Pagliughi @ 2011-06-20 15:18 UTC (permalink / raw)
To: John Dallaway; +Cc: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
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
1 sibling, 0 replies; 23+ messages in thread
From: Stanislav Meduna @ 2011-06-20 16:17 UTC (permalink / raw)
To: ecos-devel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
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
1 sibling, 1 reply; 23+ messages in thread
From: John Dallaway @ 2011-06-21 11:05 UTC (permalink / raw)
To: Frank Pagliughi, Christophe Coutand; +Cc: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Eagle 100 (Stellaris LM3S6918)
2011-06-21 11:05 ` John Dallaway
@ 2011-06-21 16:34 ` Christophe Coutand
2011-06-23 14:31 ` John Dallaway
0 siblings, 1 reply; 23+ messages in thread
From: Christophe Coutand @ 2011-06-21 16:34 UTC (permalink / raw)
To: John Dallaway, Frank Pagliughi; +Cc: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
2011-06-21 16:34 ` Christophe Coutand
@ 2011-06-23 14:31 ` John Dallaway
2011-06-23 16:48 ` Frank Pagliughi
0 siblings, 1 reply; 23+ messages in thread
From: John Dallaway @ 2011-06-23 14:31 UTC (permalink / raw)
To: Christophe Coutand, Frank Pagliughi; +Cc: eCos Development List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
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
0 siblings, 2 replies; 23+ messages in thread
From: Frank Pagliughi @ 2011-06-23 16:48 UTC (permalink / raw)
To: John Dallaway; +Cc: Christophe Coutand, eCos Development List
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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Eagle 100 (Stellaris LM3S6918)
2011-06-23 16:48 ` Frank Pagliughi
@ 2011-06-23 17:57 ` Christophe Coutand
2011-07-10 20:38 ` Ilija Kocho
1 sibling, 0 replies; 23+ messages in thread
From: Christophe Coutand @ 2011-06-23 17:57 UTC (permalink / raw)
To: Frank Pagliughi, John Dallaway; +Cc: eCos Development List
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
> >
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
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
1 sibling, 1 reply; 23+ messages in thread
From: Ilija Kocho @ 2011-07-10 20:38 UTC (permalink / raw)
To: ecos-devel
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
>>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Eagle 100 (Stellaris LM3S6918)
2011-07-10 20:38 ` Ilija Kocho
@ 2011-07-12 8:57 ` Christophe Coutand
2011-07-13 14:52 ` Ilija Kocho
0 siblings, 1 reply; 23+ messages in thread
From: Christophe Coutand @ 2011-07-12 8:57 UTC (permalink / raw)
To: Ilija Kocho, ecos-devel
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
> >>
> >
> >
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Eagle 100 (Stellaris LM3S6918)
2011-07-12 8:57 ` Christophe Coutand
@ 2011-07-13 14:52 ` Ilija Kocho
0 siblings, 0 replies; 23+ messages in thread
From: Ilija Kocho @ 2011-07-13 14:52 UTC (permalink / raw)
To: ecos-devel
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
>>>>
>>>
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2011-07-13 14:52 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-16 11:16 eCos on AT91SAM9 - call to action John Dallaway
2011-03-16 13:40 ` Grant Edwards
2011-03-16 14:31 ` AW: " Richard Rauch
2011-03-16 17:07 ` Martin Laabs
2011-03-16 18:18 ` John Dallaway
2011-03-16 18:35 ` Michael Bergandi
2011-03-17 10:14 ` Martin Laabs
2011-03-17 13:13 ` John Eigelaar
2011-06-16 13:38 ` Frank Pagliughi
2011-06-16 14:05 ` John Dallaway
2011-06-16 14:16 ` John Eigelaar
2011-06-16 14:27 ` eCos on AT91SAM3 [ was Re: eCos on AT91SAM9 - call to action ] John Dallaway
2011-06-16 14:29 ` eCos on AT91SAM9 - call to action Frank Pagliughi
2011-06-20 15:18 ` Eagle 100 (Stellaris LM3S6918) Frank Pagliughi
2011-06-20 16:17 ` Stanislav Meduna
2011-06-21 11:05 ` John Dallaway
2011-06-21 16:34 ` Christophe Coutand
2011-06-23 14:31 ` John Dallaway
2011-06-23 16:48 ` Frank Pagliughi
2011-06-23 17:57 ` Christophe Coutand
2011-07-10 20:38 ` Ilija Kocho
2011-07-12 8:57 ` Christophe Coutand
2011-07-13 14:52 ` Ilija Kocho
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).