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

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Tue Apr 25, 2017 4:10 pm

Ask if any issue in order to save your time :)
Pukao Hats Cleaning Services Ltd.

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

Re: Improving F4 core (libmaple based)

Post by victor_pv » Wed Apr 26, 2017 4:06 am

Pito wrote:Ask if any issue in order to save your time :)
Thanks :) I left it after I got the packs installed, at least that part was successful too.
I gave a shot to Danieleff core, and get the same Mflops we were getting on this core, and similar RAM usage.
I wonder if it may be better to put all the effort on that core and the STM ones since they are based on HalMX and should be much more portable.

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

Re: Improving F4 core (libmaple based)

Post by ag123 » Wed Apr 26, 2017 6:25 am

actually that's a good idea, just that having a libmaple based core would possibly offer a (different) alternative, it is likely that as the cores developed, they would diverge in terms of the features offered
but working on danieleff and stm cores could really save resources and efforts as my guess is that as we progress on building the cores, we'd do similar things like trying to make the same code base work across the different series (e.g. f1, f2, f3, f4, f7 etc)

developing it this way targetting the f4 may however let us target certain soc (e.g. f4) features and the combined board features or perhaps implement some features differently. e.g. how we are working with ccm now may not be quite the same as how a hal based core does it. e.g. hal based core may use ccm differently to maintain compatibility across series. e.g. we may prioritise ccm usage vs the shared 128k while a default configuration in perhaps hal core may first use the shared 128k and subsequently use ccm after the shared 128k runs out

just 2 cents

michael_l
Posts: 337
Joined: Mon Aug 24, 2015 6:11 pm

Re: Improving F4 core (libmaple based)

Post by michael_l » Wed Apr 26, 2017 6:40 am

STM32F4 has quite nice amount of RAM and FLASH compared to F103. With F103 having libmaple core is justified in a way that we have max amount of precious RAM available(16k or so). The same may not apply for F4. In Daniel's core HAL is available so we can concentrace on creating Arduino libraries on top of them in the first place. Ok, maybe that was an over simplification but anyway... Later, if some area needs optimization I believe it can be done per peripheral. Personally I would like to see rich Arduino F4 core that has ability to use every peripheral F4 boards have.

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

Re: Improving F4 core (libmaple based)

Post by ag123 » Wed Apr 26, 2017 6:58 am

yup, the f4 platform with the modestly higher amount of ram and flash and other features e.g. fpu makes it more usable for 'real' apps. rather i tend to think that apps targeting the f4 platform would eventually take the form of using it as a small computer (mini pc), no longer like the arduino uno
e.g. on the f4 with the somewhat larger ram, it is pretty feasible to run a micro (windows) gui while doing all other things adc, dac, spi etc that's done on f1. while in the f1 20k would easily run out for 'ram intensive' usage like a windows style gui
actually for f4 192k isn't truly a very generous amount of ram, but it would many allow more apps to work where it otherwise couldn't
e.g. apps like micropython and elua mainly targets platforms like f4 due to the combined features of more ram, flash and a faster cpu (intepreted languages do have overheads)

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

Re: Improving F4 core (libmaple based)

Post by victor_pv » Wed Apr 26, 2017 12:55 pm

ag123 wrote:yup, the f4 platform with the modestly higher amount of ram and flash and other features e.g. fpu makes it more usable for 'real' apps. rather i tend to think that apps targeting the f4 platform would eventually take the form of using it as a small computer (mini pc), no longer like the arduino uno
e.g. on the f4 with the somewhat larger ram, it is pretty feasible to run a micro (windows) gui while doing all other things adc, dac, spi etc that's done on f1. while in the f1 20k would easily run out for 'ram intensive' usage like a windows style gui
actually for f4 192k isn't truly a very generous amount of ram, but it would many allow more apps to work where it otherwise couldn't
e.g. apps like micropython and elua mainly targets platforms like f4 due to the combined features of more ram, flash and a faster cpu (intepreted languages do have overheads)
I haven't tried to build anything complicated with Daniel's core, but a simple sketch uses almost the same flash and RAM in the F4.

In the maple mini saving 1KB is already a big deal given that only as 20KB.From early in this forum we managed to save 3KB that were reserved for the bootloader and another 1KB or more used for the PIN_MAP table. That was a big deal in that device, and I think libmaple continues having the edge in resource utilization.
But when very few KB don't make a difference, I side with Michael in that would be of more value dedicating time to the application and higher level libraries rather than low level drivers.

Now working in the cores provides for one thing in my view, you get to learn the peripherals real good, which I feel is essential to really take advantage of them.

Roger said it many times from the start, that it would be better if someone had the time and energy to start working on a HalMX core to be portable. Sheepdoll started, several other people worked a bit on it, and seems that Daniel has taken the effort so far that it seems like a real option.
We will see where it gets, if the ram and flash usage is comparable, I don't see any advantage on using libmaple for the F4, and the modifications to use CCM can still be done, with the advantage that can be applied across multiple series rather than a single one.
We could easily modify Daniel's linker script to use CCM (I actually did yesterday for a test), and make changes to the core that remain compatible with all series so CCM is used when available and ignored when not.

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: Improving F4 core (libmaple based)

Post by BennehBoy » Wed Apr 26, 2017 1:05 pm

Have to say that as a relative newcomer, one unified core which covers all variants is extremely appealing. Less to learn, easier to scale things up/down.
-------------------------------------
https://github.com/BennehBoy

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

Re: Improving F4 core (libmaple based)

Post by stevestrong » Wed Apr 26, 2017 1:29 pm

Victor, it seems that you have decided to go Daniel's way.
Me, I have to first try it, too.

A very first look into those sources on github shows an apparently logical structure.

And I have to agree that for F4 that approach would give more value and faster development times than the libmaple based one.
Also providing marginal compatibility with mbed.

Meaning, I think we all can conclude at the moment:

the "libmaple based" implementation will not be continued.

Let's switch to Daniel's track and concentrate all our forces in one direction (hopefully Daniel will welcome this decision :mrgreen: )

Me, however, I will still continue to use Arduino_STM32 (Roger's repo) for F1.
And I think we can use it as basis to improve performance of some peripherals (USB serial, SPI, hardware serial,...) for F4.

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

Re: Improving F4 core (libmaple based)

Post by Pito » Wed Apr 26, 2017 2:05 pm

I've tried with Daniel's repo - it works fine, none issues found, tried SPI1 (SdFat Bench works), Whetstone, CMSIS FFT demo (with simple ADC sampling), Serial, SerialUSB, and blinking PF9/PF10 with my ZE variant. The stuff with STM HAL simply works (therefore my Q few posts back on chibios' STM HAL as a template).
Is there something specific what libmaple can do and STM HAL can't??
Pukao Hats Cleaning Services Ltd.

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

Re: Improving F4 core (libmaple based)

Post by stevestrong » Wed Apr 26, 2017 2:13 pm

Pito wrote:Is there something specific what libmaple can do and STM HAL can't??
For example: 600kBps download speed on USB serial on blue pill.

Post Reply