public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Ilija Kocho <ilijak@siva.com.mk>
To: ecos-devel@ecos.sourceware.org
Subject: Re: Eagle 100 (Stellaris LM3S6918)
Date: Sun, 10 Jul 2011 20:38:00 -0000	[thread overview]
Message-ID: <4E1A0DCB.7000705@siva.com.mk> (raw)
In-Reply-To: <4E036E37.8070100@mindspring.com>

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

  parent reply	other threads:[~2011-07-10 20:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-16 11:16 eCos on AT91SAM9 - call to action John Dallaway
2011-03-16 13:40 ` Grant Edwards
2011-03-16 14:31 ` AW: " Richard Rauch
2011-03-16 17:07 ` Martin Laabs
2011-03-16 18:18   ` John Dallaway
2011-03-16 18:35     ` Michael Bergandi
2011-03-17 10:14 ` Martin Laabs
2011-03-17 13:13 ` John Eigelaar
2011-06-16 13:38   ` Frank Pagliughi
2011-06-16 14:05     ` John Dallaway
2011-06-16 14:16       ` John Eigelaar
2011-06-16 14:27         ` eCos on AT91SAM3 [ was Re: eCos on AT91SAM9 - call to action ] John Dallaway
2011-06-16 14:29         ` eCos on AT91SAM9 - call to action Frank Pagliughi
2011-06-20 15:18           ` Eagle 100 (Stellaris LM3S6918) Frank Pagliughi
2011-06-20 16:17             ` Stanislav Meduna
2011-06-21 11:05             ` John Dallaway
2011-06-21 16:34               ` Christophe Coutand
2011-06-23 14:31                 ` John Dallaway
2011-06-23 16:48                   ` Frank Pagliughi
2011-06-23 17:57                     ` Christophe Coutand
2011-07-10 20:38                     ` Ilija Kocho [this message]
2011-07-12  8:57                       ` Christophe Coutand
2011-07-13 14:52                         ` Ilija Kocho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1A0DCB.7000705@siva.com.mk \
    --to=ilijak@siva.com.mk \
    --cc=ecos-devel@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).