From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19522 invoked by alias); 28 Mar 2011 19:13:54 -0000 Received: (qmail 19510 invoked by uid 22791); 28 Mar 2011 19:13:52 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from nm3.bullet.mail.ukl.yahoo.com (HELO nm3.bullet.mail.ukl.yahoo.com) (217.146.182.224) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Mon, 28 Mar 2011 19:13:47 +0000 Received: from [217.146.183.214] by nm3.bullet.mail.ukl.yahoo.com with NNFMP; 28 Mar 2011 19:13:45 -0000 Received: from [77.238.184.72] by tm7.bullet.mail.ukl.yahoo.com with NNFMP; 28 Mar 2011 19:13:45 -0000 Received: from [127.0.0.1] by smtp141.mail.ukl.yahoo.com with NNFMP; 28 Mar 2011 19:13:45 -0000 Received: from Mr32bitPC (g_giacomello@87.5.239.219 with login) by smtp141.mail.ukl.yahoo.com with SMTP; 28 Mar 2011 19:13:45 +0000 GMT X-Yahoo-SMTP: 8PrKJ4mswBBHp1ODFO7RBimth51qcE5VEw-- From: "Gian Maria" To: "'jerzy dyrda'" , References: <23118906-1707f2ce17e92d08d3084915122281bc@pkn7.m5r2.onet> <201103281246.55061.jerzdy@gmail.com> In-Reply-To: <201103281246.55061.jerzdy@gmail.com> Subject: R: STM32F107 on STM3210C-EVAL Date: Mon, 28 Mar 2011 19:13:00 -0000 Message-ID: <3E47EE2FBA0343E9B42A8DF0F8B8F5D9@Mr32bitPC> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-03/txt/msg00041.txt.bz2 I agree with you for HSE configuration, for my opinion this type of settings that are not common to all STM32 must be put under specific EVB. Connectivity line is a little bit different respect other STM32. For my tests I have implemented a new option like cdl_option CYGHWR_HAL_CORTEXM_STM32_CLOCK_HCLK_DIV2 { display "HCLK divider 2" flavor data default_value 5 legal_values { 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 } } And made a restriction in the EVB to set the right value =20 requires { CYGHWR_HAL_CORTEXM_STM32_CLOCK_PLL_DIV2 =3D=3D 5} In this way I can control the configuration, but I don't have to modify much the original cdl. My idea is to make STM3210C-EVAL running with eCos and RedBoot when all is working I want to upload it, but I'm at the beginning and I have to study a lot of eCos platform so I don't have a date. Best regards Gian -----Messaggio originale----- Da: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-owner@ecos.sourceware.org] Per conto di jerzy dyrda Inviato: luned=EC 28 marzo 2011 12:47 A: ecos-devel@ecos.sourceware.org; Gian Maria Oggetto: Re: STM32F107 on STM3210C-EVAL Hello all, On Monday 28 March 2011 11:51:45 qber_@poczta.onet.pl wrote: (...) > There is only one thing left - the RCC differences. In RM there is a > seperate section about RCC config for CL. But at the first look it seems > that registers are compatible. RCC registers are extended to support 2 extra PPL's with appropriate divider and multiplier. Main differences is that source of PLL clock it isn't anymore taken directly from HSE or HSE/2 clock=20 but it's introduced new divider PREDIV1 thus PLLSRC bit in RCC_CFGR register has partially=20 different meaning. And another issue is external crystal. It value is 25MHz not 8 MHz like in=20 STM3210E what causes need of using second PLL to produce CPU 72MHz. HSE =3D=3D 25MHz / PREDIV2 =3D=3D 5 -> 5MHz * PLLMUL2 =3D=3D 8 ->=20= =20 40MHz / PREDIV1 =3D=3D 5 -> 8MHz * PLLMUL =3D=3D 9 -> 72MHz =3D SYSCLK It's looks ugly but above method it's used in ST source code for STM3210C evaluation board. Best regards jerzy