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

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

Re: Improving F4 core (libmaple based)

Post by victor_pv » Mon Apr 24, 2017 12:50 pm

stevestrong wrote:My current / future plans:

- I will test USB serial with Victor's new core.
- I will test Hardware serial (Serialx, x>=1) with speeds 115kbps and above - as Pito reported that it did not work.
- I am currently evaluating the GPIOs by driving a 16 bit parallel display - already detected some bugs.
- Next step will be the FSMC as it is the next logical step for driving parallel data bus displays - will do it instead of Pito, if it is OK.

EDIT
A question:
- what is the reason behind naming some core/system files to *_f4.*? The whole directory is anyway relevant only for F4, so it seems superfluous.
Steve, no reason other than trying to differenciate the files that are f4 specific when comparing and copying files over from the F1 branch.
I agree the whole file organization is messy and should be changed, also on the F1 core, but I followed it to make my life easier using a diff program to track down which files to replace, and which to edit.
I need to keep them in the same folders to track some more changes, then we can reorganize in a way that makes more sense. To me would be something like:
Leave common files in core and libmaple.
Take MCU specific files together to a single folder, named the cpu series.
Since they are in their own folder, take _f4 _f1 etc out of their names.
Simplify the structure in libmaple folder, too many subfolders.

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

Re: Improving F4 core (libmaple based)

Post by victor_pv » Mon Apr 24, 2017 12:57 pm

Pito wrote:With the following Overclock settings in generic_f407v.h and the other settings as above:

Code: Select all

#define CYCLES_PER_MICROSECOND  240    // F_CPU in MHz
// Note: Xtal frequency 8MHz
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 4      // Xtal divider
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 240    // PLL_Freq multiplier, PLL_Freq = Xtal / PLL_M * PLL_N
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2      // PLL_Freq post divider, F_CPU = PLL_Freq / PLL_P
#endif
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 10     // USB divider = PLL_Freq / 48
#endif
..

Code: Select all

Beginning Whetstone benchmark at 240 MHz ...

Loops:1000, Iterations:10, Duration:6010.35 millisec
C Converted Single Precision Whetstones:166.38 mflops
To see ".. at 240 MHz" you have to change the f_cpu setting in boards.txt as well..

PS: I would recommend to change the order of PLL coefs to the natural clock settings chart order from left to right - M, N, P, Q . You may also add the above explanation for easier handling.

Code: Select all

#define CYCLES_PER_MICROSECOND  168    // F_CPU in MHz
// Note: Xtal frequency 8MHz
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 8      // Xtal divider
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 336    // PLL_Freq multiplier, PLL_Freq = Xtal / PLL_M * PLL_N
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2      // PLL_Freq post divider, F_CPU = PLL_Freq / PLL_P
#endif
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 7      // USB divider = PLL_Freq / 48
#endif
..
PPS: Also you may remove the weird

Code: Select all

// PLL config for 25 MHz external crystal --> 120 MHz SYSCLK, with
// 48 MHz PLL48CK.
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 5
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 240
#endif
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 25
#endif
from boards_setup.cpp
Pito, feel free to submit a PR with corrections to any bug.
About the PLL values, I think it would be better to set the target frequency once, in the boards file, and calculate all the values from it.
If the USB frequency will end up out of range, throw a warning at compile time to warn the user.

That would make it much easier to add new boards, overclock, underclock, etc.
And I think this:
#define CYCLES_PER_MICROSECOND 168

would be better as:
#define CYCLES_PER_MICROSECOND F_CPU/1000000L

I believe is like that either on the F1 core or on Steve's, but didn't have time to change and check.
Regarding wait states, it was unintentional, but since the core was originally set to run at 120Mhz, it was using 3 wait states, and it run fine with that at 168Mhz ;)
I didn't test performance at that point, I was only blinking leds.

Currently CCM is being used for PIN_MAP and .bss (uninitialized variables), but I tested using it for all data and worked too.

EDIT:
The ring buffer for the USART was modified in the F1 core by Roger, I borught over some files, and to other I manually did changes, so there may be some bugs. The easiest would be to compare it the USART and ring buffer files with the F1 version to see if I missed something.
I will try later today when get home if someone else has not found a solution yet.
Incidentally I did all my output with SWO because my board's sub doesn't work and couldn't find my serial converter, and the SWO library works with small changes, I'll add it.
Last edited by victor_pv on Mon Apr 24, 2017 1:17 pm, edited 1 time in total.

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

Re: Improving F4 core (libmaple based)

Post by ag123 » Mon Apr 24, 2017 1:15 pm

@steve,
i think Serial is literally mapped to SerialUSB on the F1 core, i'm thinking if we should keep it the same. :roll:

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

Re: Improving F4 core (libmaple based)

Post by victor_pv » Mon Apr 24, 2017 1:21 pm

ag123 wrote:@steve,
i think Serial is literally mapped to SerialUSB on the F1 core, i'm thinking if we should keep it the same. :roll:
I think Steve posted this, otherone someone else did, but seems like the best would be to keep the following names all the time:
SerialUSB -> USB
Serial1 -> USART1
Serial2 -> USART2
Serial3 -> USART3
...
And then make a define for Serial
#define Serial Serial1
or
#define Serial SerialUSB

So any sketch compiled for Serial1 or SerialUSB will always work, and any sketch compiled to Serial will output to one or the other depending what the user wants.
In the F1 core Serial can be either USART1 or USB, Serial1 can be USART1 or USART2, all depending on board selection, so it's a mess and a pain in the ass when moving code from one board to another.

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

Re: Improving F4 core (libmaple based)

Post by ag123 » Mon Apr 24, 2017 1:39 pm

i'm wondering if it may be good to do something like this

Code: Select all

#ifdef SERIAL_USB
#include <usb_serial.h>
#define Serial SerialUSB
#else
#define Serial Serial1
#endif
as it seemed Serial is part of the 'arduino uno legacy' in which the serial console is sort of expected as Serial object. the atmega328 arduino uno basically does only uart interfaced to the host via a ft232r usb-serial converter. while maple or rather stm32f* is literally a native usb peripheral
it may 'help' some arduino sketches remain 'compatible' where they explicitly reference Serial.

a trouble though is that i'm not sure which header file would be an optimum location to place the above defines structure
:roll:

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 » Mon Apr 24, 2017 2:38 pm

While building with the new core I get for Serial or Serial1

Code: Select all

warning: undefined reference to `Serial1'
only 3x out of ~20 occurrences at random places.. Weird..
The Roger's F4 Serial is different from "old F4 Serial core" so nothing to compare basically.. :)
Last edited by Pito on Mon Apr 24, 2017 3:21 pm, edited 3 times in total.
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 » Mon Apr 24, 2017 2:40 pm

ag123 wrote:i'm wondering if it may be good to do something like this

Code: Select all

#ifdef SERIAL_USB
#include <usb_serial.h>
#define Serial SerialUSB
#else
#define Serial Serial1
#endif
as it seemed Serial is part of the 'arduino uno legacy' in which the serial console is sort of expected as Serial object. the atmega328 arduino uno basically does only uart interfaced to the host via a ft232r usb-serial converter. while maple or rather stm32f* is literally a native usb peripheral
it may 'help' some arduino sketches remain 'compatible' where they explicitly reference Serial.

a trouble though is that i'm not sure which header file would be an optimum location to place the above defines structure
:roll:
Something like that looks good, but we may even want to include SerialUSB in every case, just in case you want to use SerialUSB for usb and Serial for usart1.

Something like:

Code: Select all

#ifdef SERIAL_USB
#define Serial SerialUSB
#else
#define Serial Serial1
#endif
I have to look at the core, but wherever is the include tfor usb_serial.h already would be a good place to place the defines.

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

Re: Improving F4 core (libmaple based)

Post by ag123 » Mon Apr 24, 2017 3:29 pm

one of those things at the back of my mind is that if SERIAL_USB is defined, we'd create the object SerialUSB and define Serial to reference it.
however, if the user choose to undef SERIAL_USB (say in platforms.txt), no usb initialization/enumeration would take place.

the sketch can then fill in the usb initialization / enumeration and work as a different usb device class e.g. usb mass storage, usb audio, usb cdc, usb cdc ethernet etc etc. i'd think this may be considered 'advanced' usage but i think those would really make these boards useful as a multi-purpose usb device.

then for the 'basic' usage e.g. SERIAL_USB is defined, we could make it 'work like arduino uno' hence sketches that are looking for Serial being pre-defined would find it. this may help in many cases as i'd think a lot of sketches which uses a serial console expect Serial to be simply there.
while normally it is simply a find and replace, in sketches that reference/use Serial, the references may literally be littered in 'all over the sketch'
e.g. the sketch literally play the role of a shell and interprets commands, or for that matter Serial is used as basically the default serial interface interpreting commands from the host and sending data back

i'd guess these Serial usage could be pretty common in sketches

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 » Mon Apr 24, 2017 5:51 pm

Please take into use stevestrong's enhanced USB serial code for F4 which he made for F1 originally. Actually I'm not sure if it already is included in current F4 repo. There's huge difference in terms of speed.

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

Re: Improving F4 core (libmaple based)

Post by stevestrong » Mon Apr 24, 2017 7:46 pm

victor_pv wrote: I need to keep them in the same folders to track some more changes, then we can reorganize in a way that makes more sense. To me would be something like:
Leave common files in core and libmaple.
Take MCU specific files together to a single folder, named the cpu series.
Since they are in their own folder, take _f4 _f1 etc out of their names.
Simplify the structure in libmaple folder, too many subfolders.
Actually, the F4 structure is much more cleaner than the F1 one.
I don't really know why do we need the subfolder "system", it seems that the currently available "cores/libmaple" would actually suffice.
But I agree, we need to take over some files from F1 structure which contain bugfixes and improvements.
The board specific stuff comes into "variants" subfolders.

USB:
I am working on a structure which allows different USB functionality (CDC, MSC, DFU) separately configurable by the user. It is difficult.
Also, the USB serial is the previously available ST-code based driver. Its speed can be improved, but only later, since other peripherals should be first set up, I think.

Post Reply