CLOSED, FOCUS GOES TO HAL BASED CORES - Improving F4 core (libmaple based)

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
Post Reply
victor_pv
Posts: 1747
Joined: Mon Apr 27, 2015 12:12 pm

CLOSED, FOCUS GOES TO HAL BASED CORES - Improving F4 core (libmaple based)

Post by victor_pv » Thu Apr 13, 2017 1:49 pm

**FOCUS HAS BEEN SHIFTED TO HAL MX BASED CORES FOR F4**
Danieleff has released a HALMX based core that seems to use the same resources as libmaple and provides compatibility with multiple MCUs since the HAL MX layer is similar between them. Since the F4 libmaple core doesn't provide a measurable advantage and is older and incomplete, it is better to focus to on the HAL MX ones.
Currently there are 2, one from Danieleff and one official from STM.
We recommend anyone wanting to use or develop for the F4 to work on those cores rather than the libmaple one.

**********************************************************************************************

**This post will be updated with major progress, or links to specific threads, boards, etc **
All,

There seems to be a lot of momentum around the cheap F4 boards, be it from flight controller (405), from alibaba (407 and others).
I think if we organized a bit the work that needs to be done on those boards, we could as a group be more productive.
Rather than 4 people spending their time trying to blink a led, 1 person works on gpio, 1 person works on something else, and we put it together with clear instructions, and once tested if we need changes to the core we send clean PRs to Roger.

Anyone else thinks this is a good idea? If so, what would you help with?

-Victor_pv: I volunteer myself to review the SPI library and add DMA support to it with functions similar to F1. Once completed I will try to work on an i2s library. Next, if could be 2nd depending on interest, port FreeRTOS.

Blackboard: http://wiki.stm32duino.com/index.php?title=STM32F407

If anyone wants to help on testing or developing, you can post in this thread and I will add it to the list.

Working:
GPIO (several people testing, seems to work)
SerialUSB (Stevenstrong)
FreeRTOS 8.2.1

Needs testing and possibly work:
SPI (Victor_pv)
DMA (Victor_pv)
i2s (Victor_pv)
ADC
DAC
Timers
PWM
FreeRTOS 9.0.0 (possibly works already since 8.2.1 worked out of the box)
i2c
USARTs
SDIO
CAN (Michael)
FSMC (Pito?)
-Stevenstrong: doing some clean up, and created new board files for the black board. Parallel displays, and usb.

Standards to follow:
Coding standards: http://docs.leaflabs.com/static.leaflab ... ndard.html
RAM will be allocated from the normal SRAM block by default. CCM not used and not defined yet in linker scripts.
Board Names: Generic STM32F407V series, Generic STM32F407Z series, etc

2 current repos:
Based on Aeroquad port of libmaple: https://github.com/stevstrong/Arduino_S ... F4_variant
Based on libmaple F2-F4 files and current stm32duino F1: https://github.com/victorpv/Updated_STM32F4

Progress:
USB working Steve's repo, still needs to be tested in Victor's.
CCM ram can be used on Victor's repo (Currently used for pin_map and .bss area, provides speed gains in whetstone test)
FPU working on both repos. Details in separate thread.
GPIO working on both. Different implementation in the latest libmaple code, may require changes.

Current issues:
Everything not confirmed as working.
Pito trying to get USART working at Mb rates, reply on this thread if you can test it.
Last edited by victor_pv on Thu Apr 27, 2017 5:52 pm, edited 22 times in total.

User avatar
Rick Kimball
Posts: 1058
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Improving F4 core (libmaple based)

Post by Rick Kimball » Thu Apr 13, 2017 2:55 pm

... deleted as the title seems to have changed to be specific to (libmaple based) .. although of course I could have completed missed that the first time reading ...
Last edited by Rick Kimball on Thu Apr 13, 2017 5:55 pm, edited 1 time in total.
-rick

ag123
Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Improving F4 core (libmaple based)

Post by ag123 » Thu Apr 13, 2017 5:49 pm

i'd think 'blinking a led' is inevitable if we are working on a particular board, as personally i need to know if the board is 'alive' :lol:
right at the moment, i think on the STM32{V,Z}ET6_black (that specific board) there are some 'headaches' on an optimal default mappings as to which physical pins on the headers is going to do SPI, which are going to do analog (assuming an A1- A6 arduino uno profile), which are going to do I2C and which are going to do UART

one of the issue seemed to be that the board designer has put an spi flash, and the SPI1 'headers' and an nrf24 connector, all on the same pins
this would probably mean that if you are going to use SPI and i2c on the nrf24 connector, use the onboard spi flash (part of the board) and drive an lcd on spi1 there may be some overlaps / conflicts
but nevertheless that board has lots of pins broken out and i'd think it shouldn't be too much of an issue as a 'user' can later remap the pins they want to use for say spi + i2c

one of the other things is 'trying things out' this to an extent is a 'learning process' of the individual and to later say participate in the development perhaps of a particular component. this could actually be seen as a 'testing' process, as even say to start with developing the SPI interface for F4, i may start with compiling the existing F4 branch codes and figure out where it breaks. accordingly the F4 branch of codes some parts of it is pretty much working well
http://www.stm32duino.com/viewtopic.php?f=39&t=1976
hence, i'd think we'd need to see what else breaks and decide how to fix that (e.g. make a common code with the F1 branch of codes?)

stevestrong
Posts: 1829
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Improving F4 core (libmaple based)

Post by stevestrong » Thu Apr 13, 2017 6:02 pm

victor, your post was just right on time.
I was just on beginning to touch the SPI lib...

In short what I did so far:
- cleaned up the whole F4 project from STMF2 and F1 defines
- generated new variant for black_f4 board
- generated a black_f4.cpp and .h file in the new variant root folder, which contain pretty detailed information about used board pins.

blinky example still runs with both new (black_f4) and old disco as board target.
I should commit these changes in my github repo, I think...

ag123
Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Improving F4 core (libmaple based)

Post by ag123 » Thu Apr 13, 2017 6:08 pm

u guys are running way fast, i'm still trying to achieve what pito has posted 24hrs back, maybe i should first blink my led :lol:

User avatar
Pito
Posts: 1628
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Thu Apr 13, 2017 6:23 pm

So those who are last now will be first then, and those who are first will be last..
Pukao Hats Cleaning Services Ltd.

ag123
Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Improving F4 core (libmaple based)

Post by ag123 » Thu Apr 13, 2017 7:17 pm

cloned repository from https://github.com/stevstrong/Arduino_STM32
let me start blinking my led 1st, i'd try the f4 branch :lol:

User avatar
Pito
Posts: 1628
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Thu Apr 13, 2017 7:50 pm

There is Chibios HAL, 100% free for commercial usage too, under Apache license.
http://www.chibios.org/dokuwiki/doku.ph ... :hal:start
http://www.chibios.org/dokuwiki/doku.ph ... l:features
It is covering almost all F407 peripherals and it is mature, well documented (825pages pdf), and well supported.
Q: could be that stuff reused here somehow??
Last edited by Pito on Thu Apr 13, 2017 8:05 pm, edited 1 time in total.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1747
Joined: Mon Apr 27, 2015 12:12 pm

Re: Improving F4 core (libmaple based)

Post by victor_pv » Thu Apr 13, 2017 8:03 pm

Rick Kimball wrote:... deleted as the title seems to have changed to be specific to (libmaple based) .. although of course I could have completed missed that the first time reading ...
Rick you were fast to reply, but I was even faster correcting the tile :P

User avatar
sheepdoll
Posts: 238
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Improving F4 core (libmaple based)

Post by sheepdoll » Thu Apr 13, 2017 8:26 pm

I got LED blinking 2 or so years back...

Where I got bogged down was USB CDC and eventually MIDI.

The other bog spot is the Pin mapping/Pin naming. That is where I started writing scripts, and it looks like ST has opted for that approach.

When I attempted to merge the non HAL lib maple stuff, there was simply too much low level register dependency to make the two libraries interchangeable. How does one take code for a STMF429 and shoehorn it into a STMF401, then relate this code to a STMF407?

With the Maple STMF103, we had a nice simple board with a nice simple layout. The easiest way is to simply state that is the hardware package and pin map supported. That the Nucleos, DISCOs, and quad copter controllers should use the STM HAL branches, and just learn to live with code bloat.

Post Reply