From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6402 invoked by alias); 10 Jul 2011 20:38:56 -0000 Received: (qmail 6392 invoked by uid 22791); 10 Jul 2011 20:38:54 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,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; Sun, 10 Jul 2011 20:38:38 +0000 Received: from [77.29.113.166] (port=58320 helo=[192.168.178.28]) by tirion.supremecenter202.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qg0lv-0004Af-3a for ecos-devel@ecos.sourceware.org; Sun, 10 Jul 2011 20:38:35 +0000 Message-ID: <4E1A0DCB.7000705@siva.com.mk> Date: Sun, 10 Jul 2011 20:38: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> In-Reply-To: <4E036E37.8070100@mindspring.com> 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/msg00000.txt.bz2 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 >> > >