From: "Christophe Coutand" <ccoutand@stmi.com>
To: "Ilija Kocho" <ilijak@siva.com.mk>, <ecos-devel@ecos.sourceware.org>
Subject: RE: Eagle 100 (Stellaris LM3S6918)
Date: Tue, 12 Jul 2011 08:57:00 -0000 [thread overview]
Message-ID: <D6050C555CC56940A7AF3265228302760428BAC2@mail2.STMIRV01.COM> (raw)
In-Reply-To: <4E1A0DCB.7000705@siva.com.mk>
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
> >>
> >
> >
next prev parent reply other threads:[~2011-07-12 8:57 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
2011-07-12 8:57 ` Christophe Coutand [this message]
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=D6050C555CC56940A7AF3265228302760428BAC2@mail2.STMIRV01.COM \
--to=ccoutand@stmi.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=ilijak@siva.com.mk \
/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).