This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001219] Ethernet driver for STM32 connectivity line with porton MMstm32f107 board.
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Tue, 11 Oct 2011 22:44:38 +0100
- Subject: [Bug 1001219] Ethernet driver for STM32 connectivity line with porton MMstm32f107 board.
- Auto-submitted: auto-generated
- References: <bug-1001219-777@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219
--- Comment #13 from Jerzy Dyrda <jerzdy@gmail.com> 2011-10-11 22:44:36 BST ---
(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]
> > 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
>
> 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
>
> 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.
> 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.
BTW
I have further bad news : in STM32F2xx family RCC module is different than
STM32f105/7 family.
>
> 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.
> Now some minor remarks:
> Comments like
> #endif // CYGINT_HAL_CORTEXM_STM32_CL>0
> on some places are not consistent with their respective #ifs.
> And: (this is my personal only)
> #if CYGINT_HAL_CORTEXM_STM32_CL != 0
> or
> #if CYGINT_HAL_CORTEXM_STM32_CL
> is more common than >0.
OK I check it.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.