From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13890 invoked by alias); 23 Mar 2011 10:51:04 -0000 Received: (qmail 13827 invoked by uid 22791); 23 Mar 2011 10:51:02 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 10:50:54 +0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110323105051.AIS13167.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Wed, 23 Mar 2011 10:50:51 +0000 Received: from cog.dallaway.org.uk ([213.106.80.48]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110323105051.TOWO20122.aamtaout01-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Wed, 23 Mar 2011 10:50:51 +0000 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id p2NAojt2022399; Wed, 23 Mar 2011 10:50:45 GMT Message-ID: <4D89D085.603@dallaway.org.uk> Date: Wed, 23 Mar 2011 10:51:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Gian Maria CC: ecos-devel@ecos.sourceware.org Subject: Re: STM32F107 on STM3210C-EVAL References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-03/txt/msg00021.txt.bz2 Hi Gian Maria Gian Maria wrote: > I'm porting eCos to STM3210C and I find a logical error on the > implementation of CYGPKG_HAL_CORTEXM_STM32. > CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not > correct for me to use > > cdl_option CYGHWR_HAL_CORTEXM_STM32 { > display "STM32 variant in use" > flavor data > default_value {"F103ZE"} > legal_values {"F103RC" "F103VC" "F103ZC" > "F103RD" "F103VD" "F103ZD" > "F103RE" "F103VE" "F103ZE" } > description "The STM32 has several variants, the main differences > being in the size of on-chip FLASH and SRAM > and numbers of some peripherals. This option > allows the platform HAL to select the specific > microcontroller fitted." > } > > That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl", > because with my EVB for example > the uP is a STM32F107VC. With this I can't set the right uP as default for > the template. > I'm right? I think the correct is to put the code inside > "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl" I am not sure I understand your question. Are you intending to create a new platform HAL package for STM3210C-EVAL? > Can someone modify this so I can update my CVS and work with the right code? It will be no problem to extend the set of legal values for CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your local CVS checkout until you are ready to contribute your platform support for STM3210C-EVAL. > 1 - When I finish my piece of port, that is at the beginning and I'm > learning eCos who can upload? Please refer to the eCos contributions page for details of the contribution procedure: http://ecos.sourceware.org/contrib.html > 2 - For every suggest Is this the right place? Yes, ecos-devel is a good place to discuss platform porting strategy. > 3 - I have to post the full port or can post pieces of code as they are > ready? It is a good idea to develop in the open so that other people can advise you on best practice. However, the maintainers will wait until you make a full formal contribution (via Bugzilla) before review. You will also need to make a copyright assignment. Ref: http://ecos.sourceware.org/assign.html John Dallaway eCos maintainer http://www.dallaway.org.uk/john