In the hoverboard thread I started to investigate the option to use a smaller math-library for the Cortex_M0 MCU, called qfplib.
I want to use a batch-file to locate all the replaceable math-functions in simpleFOC libraries.
So far I could identify some of them, but the basic qfp-routines are unmatched yet.
(see end of file)
See the attached document for more and feel free to add the missing pieces
It’s not as simple as that lol
Example for the multiplication:
the source code is using the * operator
gcc is replacing * by the builtin ___aeabi_dmul or ___aeabi_fmul function depending on the data type, because you have no FPU
the nanofloat library you shared declares a __wrap___aeabi_fmul function that uses the qfplib qfp_fmul function, and adds the -Wl,-wrap,__aeabi_dmul gcc option so that __wrap___aeabi_fmul is intercepted and ___aeabi_fmul is called instead
If * could be directly mapped to qfp_fmul with some gcc or linker magic, probably you wouldn’t have to change the source
Ideally if this works, we could save memory and increase speed on Cortex M0 and M3, without touching SimpleFOC. This is already used with Cortex M0+ for RP2040 it seems.
I think we should only be careful not use this for the precise sensor angle calculation because it needs a double.
But I can replace sinf, cosf, etc. functions directly, like you did with atan2?
Maybe that’s already a big step forward…
I found that STSTM uses a dedicated arm_cortexM0l_math.lib (Cortex-M0 / Cortex-M0+, Little endian) and also a readme how to compile a new library with cmake. (or replace the existing?)
But that’s one step too far?
Problem is, that *variable_name would be mapped too. But it has a totally different meaning.
Same thing with var++ or var--
I wouldn’t mind having a simpleFOC branch for Cortex M0 & M3 MCUs.
IMHO there should also be an 8-bit simpleFOC branch. Because the ongoing development will no longer work on them. It will probably be a dead branch with outdated sFOC-version, but at least it will fit.
Anyone is free to create his own branch and support it.
I have my own SimpleFOC branch for gd32, but it’s only for PWM and current sense driver, so I can just synchronize it with most of the new changes coming in the main SimpleFOC.
A branch with Qpflib will be a lot of work to adapt the changes, or a dead branch as you said.
It’s a bit offtopic, but aims to the same goal: reduction of flash-useage:
I was crawling through the sFOC source code and found some code that doesn’t make sense to run at every start.
We are checking if “pins are configured twice” or if the “timers are the best match”.
That makes no sense on all_in_one boards IMHO. Because the driver- and sensor pins are already hardwired.
I’d like to remove these functions, like I can outcomment motor.monitoring.
Furthermore I was thinking to split the program in two pieces:
run a program that only tests the configuration.
It contains all the pin mappings, init routines and commander declarations.
This prog writes a board_init file, which we can include in the main program.
the main program would only have to read the board_init file and focusses on initFOC and the main loop.
That’s a very good tip.
It will reduce the file count I had to crawl through, if I wanted to manually include qfp-math.
It would also be easier to remove the useless parts for AIO-boards (as mentioned above)
In the end, it’s all in one directory and can’t be confused with other setups.
Maybe it’s because the minimal branch uses sFOC V2.01, but I compiled the example-file STM32_hall.ino including the commander (which is a lot different than the current version) and it uses only 89% of flash.
With the current version, I am almost 4k short of flash-mem and can’t use the commander.