From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1456 invoked by alias); 12 Oct 2011 20:34:22 -0000 Received: (qmail 1221 invoked by uid 22791); 12 Oct 2011 20:34:21 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Oct 2011 20:34:06 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A326B2F78015 for ; Wed, 12 Oct 2011 21:34:05 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcuAvC5Hrbfz; Wed, 12 Oct 2011 21:34:03 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001219] Ethernet driver for STM32 connectivity line with port on MMstm32f107 board. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 12 Oct 2011 20:34:00 -0000 Message-Id: <20111012203403.29E8D2F78010@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2011-10/txt/msg00024.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219 --- Comment #15 from Ilija Kocho 2011-10-12 21:33:58 BST --- (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #7) > > > Created an attachment (id=1396) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1396) [details] [details] [details] > > > Variant modification needed by STM32 CL > > > > http://bugs.ecos.sourceware.org/attachment.cgi?id=1396&action=diff#ecos_clear/packages/hal/cortexm/stm32/var/current/include/var_io.h_sec7 > > > > Ethernet definitions are usually stored with Ethernet driver, either with C > > source or in a header file (I prefer the second). If you move it there than > > that would imply that names do not contain "_HAL_". > I would like to follow convention e.g. ADC registers with pin description are > stored in this header. I thought that any new peripheral description will be > stored in var_io.h > Obviously there's more than one convention. However I think that driver is better place for Ethernet #defines than HAL. I can imagine somebody using ADC without driver so it would be convenient having defines handy in HAL. On the other hand using Ethernet without driver is unlikely. Also, if for some reason, in future new variant is added (this is not a proposal merely possibility) it would reuse the header. > > > > http://bugs.ecos.sourceware.org/attachment.cgi?id=1396&action=diff#ecos_clear/packages/hal/cortexm/stm32/var/current/src/hal_diag.c_sec1 > > > > What is the reason for renaming of hal_stm32_serial_init() into > > hal_stm32_serial_init_channel() > I'm not sure now :) but as I suppose it doesn't work. > BTW. > Definition of function is static void hal_stm32_serial_init(void) but function > is called with argument > &stm32_ser_channels[CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL] > IMHO in case of non virtual vector is initialized other serial port than I > expect I am referring (and link points) to changes in hal_stm32_diag_init() See discussion on issue below. > > > > > http://bugs.ecos.sourceware.org/attachment.cgi?id=1396&action=diff#ecos_clear/packages/hal/cortexm/stm32/var/current/src/stm32_misc.c_sec2 > > > > Changes like this may look attractive but (as well as previous one) may (will) > > break other user's applications. Conditional compilation may help but in this > > case I suggest to keep old code, it's simple and provides working conditions > > to all peripherals. > I agree I have just added it because in case of non virtual vector isn't such > function. I am referring (and link points) to changes in hal_variant_init(). Once these functions were published they are being (as are) used in applications not known to me or you. Such changes may make many users unhappy and are unacceptable. > > > http://bugs.ecos.sourceware.org/attachment.cgi?id=1396&action=diff#ecos_clear/packages/hal/cortexm/stm32/var/current/src/stm32_misc.c_sec3 > > > > Is this necessary? > Yes RCC (clock generation) module for CL has another PLL stage which is > required to achieve proper clock for eth module. > My question is referring to cyg_uint32 hal_arch_default_isr(). Why do you need it? > BTW > I have further bad news : in STM32F2xx family RCC module is different than > STM32f105/7 family. > Regarding this (and in general), take in consideration future extensions when you design system software. > > > > http://bugs.ecos.sourceware.org/attachment.cgi?id=1396&action=diff#ecos_clear/packages/hal/cortexm/stm32/var/current/src/stm32_misc.c_sec4 > > > > I'm referring to following: > > - hal_stm32_sysclk /= 2; > > + hal_stm32_sysclk = CYGARC_HAL_CORTEXM_STM32_INTERNAL_CLOCK / 2; > > > > If it works don't fix it :) > It was made assumption that internal clock is the same as input clock but it's > wrong for CL controller. OK so this is needed (sorry :). Then you can add it, but again, take care not to break backward compatibility. Preprocessor may help you. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.