This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Eagle 100 (Stellaris LM3S6918)

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
        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
        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"}
            active_if ((!CYG_HAL_STARTUP_PLF) || \
            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"}
        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
        '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,
> Christophe
>> -----Original Message-----
>> From: [mailto:ecos-devel-
>>] On Behalf Of Ilija Kocho
>> Sent: 10. juli 2011 22:39
>> To:
>> 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
>> ( 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]