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-ow...@ecos.sourceware.org [mailto:ecos-devel-
>> ow...@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
>>>>
>>>
