From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21395 invoked by alias); 13 Jul 2011 14:52:07 -0000 Received: (qmail 21381 invoked by uid 22791); 13 Jul 2011 14:52:05 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_KG X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jul 2011 14:51:33 +0000 Received: from [195.189.206.101] (port=34906 helo=[192.168.209.101]) by tirion.supremecenter202.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qh0mi-0007T6-1A for ecos-devel@ecos.sourceware.org; Wed, 13 Jul 2011 14:51:32 +0000 Message-ID: <4E1DB0F0.1000602@siva.com.mk> Date: Wed, 13 Jul 2011 14:52:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: Eagle 100 (Stellaris LM3S6918) References: <4D809BF2.6040205@dallaway.org.uk> <4D8208F0.5010500@kses.net> <4DFA071F.4060504@mindspring.com> <4DFA0DAA.3000601@dallaway.org.uk> <1308233778.22353.4.camel@hp-study> <4DFA1320.7090500@mindspring.com> <4DFF64B3.9070507@mindspring.com> <4E007A9B.70800@dallaway.org.uk> <4E034E19.4030609@dallaway.org.uk> <4E036E37.8070100@mindspring.com> <4E1A0DCB.7000705@siva.com.mk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-07/txt/msg00002.txt.bz2 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 >>>> >>>