[En-Nut-Discussion] branches\devnut_m3n and STM32F2 devices
ulrich.prinz at googlemail.com
Sat Dec 3 21:14:15 CET 2011
Am 02.12.2011 18:32, schrieb Henrik Maier:
> Hi STM32 developers,
> Finally I have a STM3220G-EVAL board on my desk and started playing with
> the current STM32 port of Nut/OS.
> Toolchain is yagarto-20110429 and I managed to compile Nut/OS for the
> stm3210e-eval board. The next step will be to port the current driver
> set across from the STM32F1xx CPUs to STM32F2xx.
Just try to add the stm32f20x.h from the STM driver lib and then just
patch in the missing features or flags. This would be mich easier that
to try to understand and convert the stm driver lib.
> This is not as straightforward as I hoped as ST uses a different
> standard peripheral library for the STM32F2xx devices and not all
> peripherals are compatible between the F1 and F2 series (Reference:
> AN3427 Migrating a microcontroller application
> from STM32F1 to STM32F2 series)
Yes but most of it is possible to be handled by #ifdef. I just checked.
> What I thought I do for now is to create an new subdir under
> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily holds
> the drivers I ported across from the stm directory. Once that becomes
> all stable and working I can work with the other STM32F1 developers to
> maybe merge those files into one driver set suitable for F1, F2 and
> maybe even F4 devices. I like to avoid as much code duplication as possible.
As long as you stay in devnut_m3n this might be a way to do it. But I am
pretty sure it must be possible to keep all in stm32.
With the STM32F10x not all possible devices are supported until now.
LCD, SD-Card/SDIO, SPI and ADC could be much more feature rich and
clean. Timers are supported only for PWM config.
But USARTs, I2C and other peripherals do not have much more features
available regardless of manufacturer and core. So if they did not change
the names to much, it should work to change the names in the stm32fxxx.h
And you might not want to change/duplicate the whole stm32.nut file...
No you don't, it costed me some nights to write that.
What might be difficult is to understand the pll setup that I wrote, as
it works reverse. You configure the clock you have and write the speed
you want. The rest is done by the pll code. This code is completely
different from the STM lib.
But a hint: The stm lib is educative code, so worse performance and big
code results. But it clearly shows of how to init certain devices. Keep
the follow up of the init codes and rewrite the rest :)
As I told you by PM, I have the 3221G-EVAL for STM32F20x and the small
STM32F40x kit. So keep updated. I also have holidays in one week and try
to go into nutos open tasks right away.
More information about the En-Nut-Discussion