[deprecated]First release of STM32F4 core

Hi Roger and all,

Repalced by viewtopic.php?f=48&t=2098

As you probably seen, I’ve released the Arduino_Core_STM32F4
https://github.com/stm32duino/Arduino_Core_STM32F4

It supports the Nucleo F429ZI.
All pins are available based on mbed pinmap feature.
PeripheralPins.c automatically generated from stm32cube mcu xml file. This avoid issue on pins definition.
Python script to generate it is available here:
https://github.com/fpistm/stm32_tools
This also saved memory compared to old implementation even if all pins are defined.
USB feature is available, I removed it from the static lib to save memory and it is disabled by default.
To enable, edit the boards.txt file then add ‘-DUSBCON’ to enable the core and ‘-DUSBD_USE_HID_COMPOSITE’ to enable HID (keyboard and mouse support)
CDC support should come soon

It respect Arduino pin naming thanks the following pin functions defined in Arduino.h:
// Convert a digital pin number Dxx to a PinName Pxy
PinName digitalToPinName(uint32_t p)
// Convert an analog pin number Axx to a PinName Pxy
PinName analogToPinName(uint32_t p)
// Convert an analog pin number to a digital pin number
uint32_t analogToDigital(uint32_t p)
// Convert a PinName Pxy to a pin number
uint32_t pinNametoPinNumber(PinName p);

So in the sketch, use A0 or 0 with AnalogRead/Write is ok as use D0 or 0 with DigitalRead/Write.
Moreover, the piname (Pxy) could be used directly in the sketch thanks: AnalogRead(pinNametoPinNumber(PC7))

Some features still to be reworked: timers, SPI and I2C. (on going with fprwi6labs )

If you have any questions/remarks/proposal do not hesitate.
If you see any issue, please enter an issue on github.

I will release the package soon. I’m waiting feedback and some rework.
Note: I will rework the other stm32 families with this new pin management in order to manage all pins and saved memory.

BR

Maybe the official core should be renamed from stm32duino to something else (stm32HALduino…), as it is confusing to have 2 projects with the same name for the same purpose.

Pin names and numbers should be interchangeable, the maple and F1 core already is like that. digitalRead(0) == digitalRead(D0) == digitalRead(PG9) (on 429ZI Nucleo). The popular bluepill does not have numbers, so using pinNametoPinNumber everywhere is not user friendly.

Why is USB code in variant?

It would be cool to have a .txt describing how to add a variant. (I mean I know how to do it, its just a drawn out process of finding files, what to put where, what to change etc… I may later try to do it for my 411RE)

(My personal pet peeve: Is there a possibility to merge the F1/L4/F4 … repositories into one? The way I see it is they are very similar with some changes here and there. Now that the peripheral pins moved to (generated, very nice!) PeripheralPins.c, they will be even more similar.)

danieleff wrote:Maybe the official core should be renamed from stm32duino to something else (stm32HALduino…), as it is confusing to have 2 projects with the same name for the same purpose.

How hard would you think is to make a variant for the stm32f407? seems like there is plenty of those floating around in ebay and aliexpress.

fpiSTM wrote:…
All pins are available based on mbed pinmap feature.

victor_pv wrote:How hard would you think is to make a variant for the stm32f407? seems like there is plenty of those floating around in ebay and aliexpress.

fpiSTM wrote:I’ve already add a new variant for F4 functional in a half-day

danieleff wrote:fpiSTM wrote:I’ve already add a new variant for F4 functional in a half-day

Like a few others I’ve downloaded the new “Cube” F1 and F4 cores and am having a play.

So far, so good with a Maple Mini and the F1 core.

With the F4, I’m working up a new variant for my “Black F4VET6” board.

Everything is going fine with your instructions, but I’m caught with step 5/.

I’ve added a new target to the Makefile, but can’t cause it to create the new static lib. Do I need to go over to my Linux box and cross compile (I’ve never tried a Make style build on my Win box) or have I missed an entry elsewhere to trigger the library compile?

Richard

Yes you will need to run make from command line in system/libstm32f4/build_gcc/ folder to compile step 5. It can be done in windows, but more straightforward in linux.

Thanks. I’ll give it a go.

Hi,
I’ve just pushed a branch STM32F407G-DISC1-Example
https://github.com/stm32duino/Arduino_C … C1-Example
This will be more easy to see what is required to add a variant.
As mentioned in the git commit:
Basic test on ADC/DAC/PWM/IO are functionnal.
USB not tested.
Serial over STLink required connection.
See UM1472 §6.1.3 ST-LINK/V2-A VCP configuration

Hope this help

Hi,

This is awesome! I just discovered this project and the only board I have is the STM32F4DISCOVERY, and just found that half an hour ago you released a branch with support for it, excellent! I’ll try to follow the steps scattered through this forum to make it work (it seems there is a bit of outdated information)

Thanks!

arcnor wrote:Hi,

This is awesome! I just discovered this project and the only board I have is the STM32F4DISCOVERY, and just found that half an hour ago you released a branch with support for it, excellent! I’ll try to follow the steps scattered through this forum to make it work (it seems there is a bit of outdated information)

Thanks!

It worked a treat, thanks.

Tomorrow I’ll try out the variant.

I spent the day creating a Cube F407VET variant (not Disco).

Given that the static library config files (build_gcc, particularly Makefile and stm32f4.mk) are related to the variant more than the F4 platform, would it make sense to move some, or all, into the variant’s directory?

I made quite a few changes to the stm32f4.mk file to add/subtract features (e.g. no Wolfson codec) on my board.

Maybe the discos all have similar hardware features, and a common build_gcc makes sense for them.

I’m about to look at the new 407 disco code – and see how it is done properly!

palmerr wrote:
Given that the static library config files (build_gcc, particularly Makefile and stm32f4.mk) are related to the variant more than the F4 platform, would it make sense to move some, or all, into the variant’s directory?

Yes, exactly.

Wouldn’t it be better for the files that need to be changed to be in the variant folder rather than the shared code folders – so that features could be edited in and out for particular boards without the possibility of breaking other variants?

Happy to go with whatever you decide, but there’s an opportunity now to adjust things before lots of people (like me) start to donate variants to your excellent core.

Richard

palmerr wrote:Yes, exactly.

Wouldn’t it be better for the files that need to be changed to be in the variant folder rather than the shared code folders – so that features could be edited in and out for particular boards without the possibility of breaking other variants?

Happy to go with whatever you decide, but there’s an opportunity now to adjust things before lots of people (like me) start to donate variants to your excellent core.

Richard

Thanks for that, it worked great!

However, I have a (very beginner) question: How do I use the serial console with this? There is no serial port being created or detected when I connect the board (I upload using the STLink, and that seems to work fine), so the Arduino IDE fails when trying to use the serial port.

I’d also like to use the USB for MIDI, but I saw that USB says “not tested” (and also not sure if the Arduino USBMIDI stuff will be included) so I’ll guess I’ll need to be patient .

Thanks again!

arcnor wrote:Thanks for that, it worked great!

However, I have a (very beginner) question: How do I use the serial console with this? There is no serial port being created or detected when I connect the board (I upload using the STLink, and that seems to work fine), so the Arduino IDE fails when trying to use the serial port.

I’d also like to use the USB for MIDI, but I saw that USB says “not tested” (and also not sure if the Arduino USBMIDI stuff will be included) so I’ll guess I’ll need to be patient .

Thanks again!

Sorry @fpiSTM, what is USART3_E?
The pins mapping seems not match with F407’s USART3, does it?
Sorry, I double checked the pins mapping and found it: USART3_E = USART3..

edogaldo wrote:Sorry @fpiSTM, what is USART3_E?
The pins mapping seems not match with F407’s USART3, does it?

fpiSTM wrote:arcnor wrote:Thanks for that, it worked great!

However, I have a (very beginner) question: How do I use the serial console with this? There is no serial port being created or detected when I connect the board (I upload using the STLink, and that seems to work fine), so the Arduino IDE fails when trying to use the serial port.

I’d also like to use the USB for MIDI, but I saw that USB says “not tested” (and also not sure if the Arduino USBMIDI stuff will be included) so I’ll guess I’ll need to be patient .

Thanks again!

Thanks. This is good news ! I’m running out of ram in my STM32F103 and will have to switch to STM32F4 soon.

Going a bit off-topic here but are there any STM32F4 boards that are size of a blue pill available ? Of course all F4 mcu’s are not yet supported by this project but if I find a small STM32F4 board I can start working on the variant config based on this project.

arcnor wrote:

…

MIDIUSB is one of the Arduino libraries (https://github.com/arduino-libraries/MIDIUSB), and it requires some kind of USB support, not sure how much (it only works on Arduinos with full USB support like the Atmega32u4 based ones, but this board should be totally capable of doing that as well).

Thank you again!

michael_l wrote:Thanks. This is good news ! I’m running out of ram in my STM32F103 and will have to switch to STM32F4 soon.

Going a bit off-topic here but are there any STM32F4 boards that are size of a blue pill available ? Of course all F4 mcu’s are not yet supported by this project but if I find a small STM32F4 board I can start working on the variant config based on this project.

BennehBoy,

I haven’t seen any tiny F4’s. (Others feel free to chip in here!) The most powerful, small ARM boards I’m aware of are the Teensys (Paul Stoffregen) with processors and speeds similar to the F4s. Googling Teensyduino will get you there.

There are a number of brave souls who have desoldered F103s from blue/red pills and put F4s in their place. Not for the faint hearted!

STM has kept the pin functions remarkably similar across the lines F1XYZ to F4XYZ, with only a few differences. You would need to look at the pin designations of the two chips before proceeding, to ensure enough of the right pins were available.

Creating a new variant is not difficult, though a bit tedious. If you find a variant with the same base chip already available, the only things to do are copy the variant to a new directory, set the Board Pins to something than makes sense and add a new board to the boards.txt file. Of course there are a number of other tweaks you will need to do, but that’s the basics to get something that will fire up your board.

The original Maple cores are very stable and reliable, but a few functions in the F4 code simply refuse to work well (USB DFU uploads for instance).

The Koduino core is coming along nicely, though the F1 code is much more complete than the F4 code, due to where Avik and friends have focused to date.

The new STM32duino code – based on STM’s CUBE is similar to Koduino, though even newer. The alpha release (yes alpha!) F4 core is less than two weeks old, but many functions work very well in their basic form – but usually just one interface of each type, and often no alternate pins (yet). The Issues log says that substantial improvements to SPI, I2C and Timers are next on the list.

So, whichever you choose, the F4 code still has some catching up to do – but it’s getting there quite quickly, due to the efforts of a few hard-working individuals.

Just wanted to shortly ask: will this core be totally different from the Arduino Star OTTO?

palmerr wrote:
I haven’t seen any tiny F4’s. (Others feel free to chip in here!) The most powerful, small ARM boards I’m aware of are the Teensys (Paul Stoffregen) with processors and speeds similar to the F4s. Googling Teensyduino will get you there.

wow, that’s pricey!

its got sd and eeprom, experience of the Black 407 VET/ZET boards suggests those peripherals might not be mapped to the data sheet defaults.
i freely admit i had assumed the default usage previously, possibly explaining why nothing seemed to work excluding the leds

stephen

stevestrong wrote:Just wanted to shortly ask: will this core be totally different from the Arduino Star OTTO?

my guess is that for a ‘small’ F4, 1’d need to go for an L4 series, but i’m yet to find any ‘tiny’ enthusiasts dev boards floating on ebay with that.
the closest is probably the nucleo which for now use a modest board space, i’d think if it gets too small it may become impossible to break out all the pins on 2.54mm headers
http://www.st.com/en/evaluation-tools/n … 476rg.html
imho the F4, e.g. F407{V,Z}ET is a good board for connecting lots of things and has decent sram and flash

Frederic,

I’ve been looking through your variant files for MCU Port to Arduino pin mappings while working on a “Black STM32F407VET6” variant – as we’ve described on the Wiki http://wiki.stm32duino.com/index.php?title=STM32F407.

The Nucleo board is fairly straightforward with its Uno V3 style headers.

With the Disco Board
– what was the reasoning behind starting with the inner pins on both sides, and the the outer pins?
– how hard did you try to match Uno-style Dxx standards for functions (e.g. SPI, I2C, UART)?

Thanks for any guidance you can provide on how to make the variants as easy to use as possible for programmers.

Richard

palmerr wrote:Frederic,
– what was the reasoning behind starting with the inner pins on both sides, and the the outer pins?
– how hard did you try to match Uno-style Dxx standards for functions (e.g. SPI, I2C, UART)?

Thanks for any guidance you can provide on how to make the variants as easy to use as possible for programmers.

Richard

Frederic,

Thanks for the advice.

I’ll go and look at my files and develop a pin mapping that makes sense for this board.

Richard

palmerr wrote:Frederic,

Thanks for the advice.

I’ll go and look at my files and develop a pin mapping that makes sense for this board.

Richard

Frederic,

Thanks again.

Looking at how the SPI code searches for the right entry in, say the MOSI array in PeripheralPins.c, is it a bad idea to have a pin, say PB5, active for both SPI1 and SPI3?

It seems that the code will stop at the first entry, say SPI1, even if SPI3 is intended and the wrong AF will be applied to the pin.

Richard

palmerr wrote:Frederic,

Thanks again.

Looking at how the SPI code searches for the right entry in, say the MOSI array in PeripheralPins.c, is it a bad idea to have a pin, say PB5, active for both SPI1 and SPI3?

It seems that the code will stop at the first entry, say SPI1, even if SPI3 is intended and the wrong AF will be applied to the pin.

Richard

hi palmerr,
i think it’d be ok to simply have SPI1 on PB3-PB5, the trouble is the the board designer placed the onboard spi flash, the spi1 header and the nrf24 connector on those same pins, this would certainly mean unavoidable conflicts
if we simply have SPI1 on PB3-PB5 the onboard spi flash can be disabled or selected using PB0 which is connected to /CS (labelled F_CS) on the spi flash.
then if a ‘user’ wants to connect say an spi lcd he/she can still use spi1 without an issue
http://www.stm32duino.com/viewtopic.php … =20#p26219
http://www.stm32duino.com/viewtopic.php … =10#p26147

actually for i2c it appears that it could be used without conflict with spi1 as PB6 I2C1_CLK & PB7 I2C1_SDA are labelled as routing to NRF_CE & NRF_CS

otherwise you may want to simply pick another set of pins for i2c (this might be preferred, it would leave NRF_CE and NRF_CS as GPIO pins) and yet set another for uart as the {V,Z}ET6 board has many pins broken out

if we want to cater to the different scenarios i’d think we can have different ‘variants’ in which the ‘user’ would have to choose between the variant for SPI+I2C or perhaps a nrf24 connector specific variant as 2 different ‘variants’ using those same PB3-PB7 pins

palmerr wrote:Frederic,

I’ve been looking through your variant files for MCU Port to Arduino pin mappings while working on a “Black STM32F407VET6” variant – as we’ve described on the Wiki http://wiki.stm32duino.com/index.php?title=STM32F407.

The Nucleo board is fairly straightforward with its Uno V3 style headers.

With the Disco Board
– what was the reasoning behind starting with the inner pins on both sides, and the the outer pins?
– how hard did you try to match Uno-style Dxx standards for functions (e.g. SPI, I2C, UART)?

Thanks for any guidance you can provide on how to make the variants as easy to use as possible for programmers.

Richard

Thanks Sheepdoll,

It’s good to hear where the STM folks started from, which illuminates how they arrived where they are.

I think we’re coming to some kind of consensus that, for the more advanced boards, Dx style numbering in code is counterproductive.

That means abandoning some of the Uno Dx defaults (SPI, LED, TXn, SDA/SCK, etc) for the default interfaces. It will break some libraries, but they’re probably in need of rewriting anyway, if they have library-level hard coded defaults for function/pin mappings, rather than obtaining them from platform/board defines.

PortToPin maps seem to have more relevance to quickly finding pins on headers, so it seems to be worth the time in the enums and arrays to list the PXNNs in some sort of order that makes sense in the physical world.

Why I’m harping on all this in the forums, is that if we DO come to a new consensus, and document how to approach the tradeoffs in creating variants, we can avoid a little chaos downstream!

For instance, at the moment Stephen (zmemw16) and I are collaborating on Black_F4VET6 variants. Daniel has put one up in GENERICSTM32, and Michel (MskMichel) has added to the Wiki documentation (and maybe working on a variant also). We could end up with three or four sub-variants of the same board! Maybe we all contribute our two cent’s worth and let the market decide which is (are) best.

Richard

Ag123,

I agree with your logic about not tying things down too tightly, so that the developer can choose which set of functions to enable, and thus have some flexibility on pins.

However, I think we may be able to get by with a single variant for almost all purposes.

1. Leave as many AF options open as possible for each peripheral – providing almost all of the flexibility you mention.
2. Only restrict pins that might cause functional issues:
– e.g. the CS pin for the flash, which must disable the chip for other hardware (including SPI modules) using PB4/5 to work.
– SWDIO/SWCLK?

On the Black F4VET6 the SPI1/SPI3 choice seems to be the only one that’s at all significant. NRF, USB (?) & SDIO are all options that can (could? should?) be disabled at code level along with the AF mappings.

Daniel Eff has opted for SPI3 to map to the NRF/Flash, and this seems to be a good choice, thought there are some NSS tradeoffs. I’m not sure whether DMA/SPI would be affected by not using NSS pins for CS.

Richard

Hello together,

thank you very much for all your work. I successfully installed the STM32F4 from Rogers directory and it worked fine.
My goal was to write some examples for the STM32F4 discovery. Because the STM32F4 core is newer and has more support for the peripherals I tried to install it relating to this description:
Hi arcnor,
I do not release yet the package for F4. Some features needs some rework to be more generic.
But If you want to try it quickly, then follow the wiki:
https://github.com/stm32duino/wiki/wiki/Getting-Started
to install the L4 core for example. This will allow to install the arm toolchain and the STM32 tools (including stlink).
Then simply clone the F4 repo into the arduino install dir:
cd <arduino_install_dir>/hardware/
create an STM dir
mkdir STM
then clone the repo:
git clone https://github.com/fpistm/arduino-core-stm32f4.git stm32f4
Do not forget to checkout the stm32f407 branch
Start arduino you should see the STM32F4 boards

I tried it on Windows10 with Arduino IDE 1.6.9 and Arduino 1.8.0
I tried it on Linux Ubuntu 16.04 LTS with Arduino IDE 1.8.1

I had no success. In none of this IDEs the STM32F4 discovery appeared in the Board-Manager. I tried it for two days now in every way I could think of. No success.

Do you have any hints? Is it probably a problem of the current commit.

Hi ChrisMicro,

Please be advised that the instructions you copied have the wrong repository. The right one is “https://github.com/stm32duino/Arduino_Core_STM32F4.git“. You also don’t need to change the branch anymore (it’s been merged to master).

Hope that helps.

Oups, yes I’ve made a mistake… this repo is not the good one…
I will update my post to point on the right one.
And now the F407 is merged in the master.

Thanks Frederic,

I’ll download the changes tomorrow and have a play.

BTW: are the floating point functions implemented yet, I’m getting slowish arithmetic?

Single precision float = 8 x fixed point, for add and multiply.

It should be closer to 1:1 for FPU?

Richard

Please be advised that the instructions you copied have the wrong repository. The right one is “https://github.com/stm32duino/Arduino_Core_STM32F4.git“. You also don’t need to change the branch anymore (it’s been merged to master).

Uhhh .. .finally that works … after this many tries.
Thank you very much

My working installation procedure ( I hope it can help some other people ):

My Arduino IDE directory is
C:\Tools\Arduino\Arduino1_8
I make a directory inside the Arduino IDE folder and change to this directory:
C:\Tools\Arduino\Arduino1_8\hardware\STM\
then:
git clone https://github.com/stm32duino/Arduino_Core_STM32F4.git stm32f4

The STM32F4 Discovery has very interesting peripherals for sound generation and processing:

– MP45DT02 ST-MEMS-Microphone
– Audio-DAC CS43L22 with class D amplifier
– 3-Axis-ST-MEMS-accelerometer

Is it planned to support them with drivers? The board is very well suited to create synthesizers if there is a possibility drive the codec.

Here I found a example using the accelerometer which uses Rogers repository.
But it is not working with this core.

There is also an example which I made using the Microphone for a VU meter including the OTG LED with Rogers repository. How can it be done with this core?

Pin Maps for the Black F4 VET6 board are now up on the wiki and my repo https://github.com/palmerr23/Black-F407 … /Documents

Corrections gratefully accepted.

Richard

Oops!

I left out PB4 from the pinouts and code for the Black F4VET6 board.

It’s only connected to the NRF socket and the Winbond Flash, so I picked it up when creating the pinout diagrams for the JTAG, TFT and NRF sockets.

Fixed in the wiki and my repo.

Richard

Hi Richard,

I’ve submit an issue with some advice on your github repo.
BR

hi masters

thanks for d f4 core release.i try f103rb with enc28j60 ,it works perfect.

but i need modbus tcp library for f103 and f411 boards to work as modbus master/slave application.

can u help to convert this arduino modbus library to work for stm32???

https://github.com/andresarmento/modbus-arduino

it will be great to connect stm32 from net and get some analog values real time

best regards

Mio
SG

Hi zook199,

sounds good.
Unfortunatelly, I do not have time to study this. If I could get some times I will check that.
But, maybe some other user could check also

@fpiSTM
Did you see, I made this demos for the STM32F4 Discovery STM32GENERIC.
Because there is no DMA-I2S and also no DAMI2S in for the microphone, I had to do it all “blocking” and “bit banging”.

When do you plan your next release which supports this peripherals?

The code is now updated for the Black F4 VET6 variant using the new analog pin definition syntax in my repo https://github.com/palmerr23/Black-F407VET6-cube.

It works directly with the new “CubeMX” F4 core at https://github.com/stm32duino/Arduino_Core_STM32F4 managed by @fpiSTM

Richard

I have added a reasonably extensive set of working HAL ADC examples for the new F4 code set at https://github.com/palmerr23/Black-F407 … r/examples

* Regular Conversion Polling – ADC1 and ADC3
* Regular Conversion Interrupt
* Regular Conversion DMA
* Dual Mode Interleaved – Continuous and burst conversions using DMA with 8 bit and 12 bit samples

If people find these useful I will create some more. A possible list might include:
* VBAT, VTemp
* Multi channel operation and scan mode
* Triple Mode Interleaved
* Analog Watchdog
* Injection modes
* LL and mixed mode examples

ChrisMicro wrote:
When do you plan your next release which supports this peripherals?

Frederic,

I’ll get on with additional modes. Probably VBAT, VTEMP, Channels and Triple interleaved first.

It would be useful to include both HAL and LL drivers for anything time sensitive in the new generic code.

I found that I ran up against the time constraints in the HAL mode interrupt routine. For scan mode applications, and other uses that require very fast responses, the LL drivers are preferred. There are some excellent mixed mode examples in the cube demo code that I have working with some additional LL driver files.

Other than ADC/DAC I’m not sure what else might need LL access. The DMA, GPIO, etc LL files would also need to be included.

Richard

On the new repo Arduino_Core_STM32,
ll are included. There is no more HAL static library.
stm32f4xx_ll_adc.c stm32f4xx_ll_crc.c stm32f4xx_ll_dac.c stm32f4xx_ll_dma.c stm32f4xx_ll_dma2d.c stm32f4xx_ll_exti.c
stm32f4xx_ll_fmc.c stm32f4xx_ll_fsmc.c stm32f4xx_ll_gpio.c stm32f4xx_ll_i2c.c stm32f4xx_ll_lptim.c stm32f4xx_ll_pwr.c
stm32f4xx_ll_rcc.c stm32f4xx_ll_rng.c stm32f4xx_ll_rtc.c stm32f4xx_ll_sdmmc.c stm32f4xx_ll_spi.c stm32f4xx_ll_tim.c
stm32f4xx_ll_usart.c stm32f4xx_ll_usb.c stm32f4xx_ll_utils.c

So, it can be easyly used.

Frederic,

Excellent.

Richard