Hello all,
I used allot the STM32Duino Framework with the Arduino IDE.
Now I just wanted to test, if SimpleFOC could be compiled with it:
Do you have an idea we just including
#include <SimpleFOC.h>
leads to that error?
Hello all,
I used allot the STM32Duino Framework with the Arduino IDE.
Now I just wanted to test, if SimpleFOC could be compiled with it:
Do you have an idea we just including
#include <SimpleFOC.h>
leads to that error?
I just found this post here on discord where MoidKhan manged to compile with STM32duino in Nov’21 for ST Nucleo-F030R8.
So I was looking which Version of the library was with high probability used at this date and decreased the Version from 2.2.2 to 1.6.0.
With Version 1.6.0 I can succeeded to compile for an F030 and an F405.
Conclusion: The Library was broken for STM32duino between V1.6.0 and V2.2.2
Hey,
So with SimpleFOC 2.2.3 (dev branch) Arduino IDE 2.0.0-rc9 and stm32duino 2.1.0 it compiled ok.
It compiles fine with GenericSTM32F4 in general, but not with the STM32F405RG variant - but this appears to be a problem with the board description files rather than SimpleFOC.
With Arduino IDE 1.8.13, Simple FOC 2.2.3 and stm32duino 2.2.2 it compiles fine for me for the STM32F405:
What version of the STM32duino do you have installed?
Thanks for your hint.
Indeed, I had STM32duino V1.9 and the changed the json-Link so I didn’t realize there are newer versions.
Now I changed to
I want to experiment with the code on a VESC 4.12 Hardware with SimpleFOC on it (because I just have it)
Do you see any chance?
I don’t know about V4.12, but I believe some others have managed to get SimpleFOC running on VESC hardware. I think there are some forum threads about it…
It compiles fine with GenericSTM32F4 in general, but not with the STM32F405RG variant - but this appears to be a problem with the board description files rather than SimpleFOC.
By the way STM32duino V2.3.0 compiles the variant. So it seems that they have fixed the problem.
Thanks for the hint
I will try to find this posts.
The DRV8302 of the VESC is connected with 6 PWM lines.
To have a simple example I wanted to use the Arduino example “bldc_driver_6pwm_standalone”.
I realized that it is not working and when I’m looking into the code I see
// Configuring PWM frequency, resolution and alignment
// - BLDC driver - 6PWM setting
// - hardware specific
attribute((weak)) void* _configure6PWM(long pwm_frequency, float dead_zone, const int pinA_h, const int pinA_l, const int pinB_h, const int pinB_l, const int pinC_h, const int pinC_l){
_UNUSED(pwm_frequency);
_UNUSED(dead_zone);
_UNUSED(pinA_h);
_UNUSED(pinA_l);
_UNUSED(pinB_h);
_UNUSED(pinB_l);
_UNUSED(pinC_h);
_UNUSED(pinC_l);return SIMPLEFOC_DRIVER_INIT_FAILED;
}
For me it looks as if the driver is not implemented ?
The driver for STM32 is certainly implemented. What you’re looking at is the “default” implementation, which for 6 PWM is really “not implemented “.
But we use a C construct called “weak bindings” and there are additional, hardware specific implementations of the PWM methods that take precedence over the default implementation.
And for STM32 there is a hardware specific implementation for 6 PWM… it’s in the drivers/hardware_specific folder.
And for STM32 there is a hardware specific implementation for 6 PWM… it’s in the drivers/hardware_specific folder.
Thanks
Let me explain how I came to the conclusion:
Because I didn’t want to overwrite the VESC firmware I thought I should the library first on another board. It is a BlackPill F411CE with an ST-Link attached to it. I compiled the example with VS-Code and stepped with the debugger till I found the code fragment I showed.
When I look in the source you pointed to, there is the implemented 6PWM, but during debugging it does call the dummy routine.
…
Meanwhile I found here in the forum the documentation using VS-Code.
The important entry in “platform.ini” is
lib_archive = false
Without this, it will not compile the STM32 code.
Doh, sorry, yes, I should have mentioned that!
lib_archive = false
is needed for PlatformIO
That could probably help for some improvements of the examples:
I realized that when the setup is correct the example compiles correct and there are no errors.
But for instance in that missing “lib_archive = false” case, no warning is given to the user. So it seems that all examples are only tested for “good cases” but in error cases no message is given to the user. Here a “#pragma warning” in corresponding code fragment could be one solution to help
That’s a really good idea! We should look into adding a warning for this case - I wonder if #pragma can do it - I fear not because it does actually compile all the code, just not link it…
But perhaps there is another way to add a compiler warning for this case.