Hello,
I have searched the forum but couldn’t find anything in relation to porting the code to Micropython. Are there any plans ( would it be possible) to port the code to micropython?
MicroPython has a Numpy like array manipulation library called ulab. It will probably be possible to use it to port the code. Any thoughts on that matter? Any suggestions? Maybe someone already done that ?
Thanks to the fact that SimpleFOC uses Arduino, you can run on it a wide variety of MCUs. I don’t see any benefit for porting the code to µPython. What benefit would be obtained by porting to µPython?
I’m not an expert and I may be wrong but I think it’s not technically feasible, since Python is an interpreted language whose performance is very much lower compared to C ++
I’ve thought about it 
MicroPython is becoming pretty popular for its ease of use and low barrier to entry for programming MCUs.
Thing is, its 100x slower than any C based solution, and SimpleFOC needs speed! The speed at which the main loop runs the loopFOC() function directly impacts the performance you can achieve - there’s no scope for jitter, breaks or timeouts there. Running it 100x slower - no chance of it working.
So porting SimpleFOC to python is a no-go, but creating API bindings so the C version of SimpleFOC can be called from MicroPython would be possible.
This would be possible on MCUs with enough power to run multiple threads. Then SimpleFOC could run in a high priority thread, while micropython could run in parallel at lower priority, and control the set-points via the API.
The thing is, there are hardly any MCUs with sufficient power to leave you with a lot of spare processing time to do a lot on the micropython side. Anything big you do there would directly impact the motor performance.
So on the whole I just don’t see the micropython and SimpleFOC on one MCU approach as a “winning” one. I think a approach where you let the SimpleFOC MCU control the motors, and add a second MCU or compact PC (RaspiPi, BeagleBone) which controls the first via CAN, I2C or similar will be much more flexible and perform much better.
I agree, calling the C from Micropython would be much faster. In relation to the MCU, what about esp32? Dual-core running at 240 MHz. So 1 core can be dedicated to SimpleFOC the other all the rest?
Update: Nevermind … For the moment Micropython runs on core1 only. So it won’t be possible until they sort the issue …
Certainly, ESP32 would be an example of a powerful MCU. Also the STM32H series and the Raspi RP2040… all these would be capable of doing it in the way I described above. If you have 2 cores like the RP2040 or the ESP32, then it’s even more likely you’ll get acceptable performance.
But really, where is the advantage? Getting the 2-core multi-threaded micropython setup (with a custom library not normally part of any MicroPython build) all set up will be a “big job”, and no longer accessible to beginner level users (whom micropython is aimed at). And if you’re a pro user, then why bother with a complex setup that won’t perform as well as just doing it all in C++?
I’m honestly asking - I don’t have any problem with micropython, and would be in favour of supporting it if it worked well and it is something people wanted and would benefit from… but at the moment I don’t quite see it as working out that way?
@exider, you seem to be in favour of it - what would be, from your point of view - the advantage or use-case that makes you want it?
People who prefer Python and use boards running Micropython obviously like the easy of use and flexibility the language provide. Form me, the main benefit would be that I won’t need to cut the project between 2 MCUs one running Micropython and second Arduino. This will add a layer of additional components and wiring…
An api that can be called from Micopython would be great!
You are right. I think it is possible to port the code to Micropython. Are you familiar with Micropython?
I am not a developer, but I use micropython freely …
There are some math libraries available for Micropython:
On the ESP32, MicroPython runs as a single task under FreeRTOS. The motor control could be run in another, high-priority FreeRTOS task, and commanded from MicroPython.
I don’t know whether running it on the second ESP32 core would be a good thing.
There would be effort involved in porting the Arduino-specific library functions to the ESP-IDF API, and in making the outer loop into its own task.
However, since the ESP32 SimpleFOC code already uses the ESP-IDF libraries for (at least) PWM control, this may not be too difficult.
(post deleted by author)
Interesting to see this thread, I was looking for something unrelated. I am actually doing exactly what some people are talking about, I actually chopped the waveform generation and acceleration off and put it on an STM32 board, the b-g431b-esc1 and did everything else like sensor calibration, stall detection, and other error compensation on a raspberry pi pico. I should post my project at some point but in reality it’s pretty crummy and I need to switch to a different approach anyway for cost reasons.
Although many people pointed out that cutting the driver into pieces like that would introduce complications, and it did, it was actually not that bad and in retrospect did make some sense. However a HAT for a RBPI Pico combined with a few micropython modules (I have read it is practical and not that hard to produce micropython modules from C++/arduino code but have never tried it and in reality how easy is this kind of stuff really, ever…)
The production of the waveform really does need very high speeds, however if this could be written very cleverly, perhaps using the PIO peripheral or whatever, maybe with interrupts, the sensor reading, stall detection, calibration and so on can all be done quite reasonably under micropython.
To be fair micropython is all written in C++ and a good library of stuff for Arduino imo ultimately makes more sense from a technical standpoint. I also don’t believe that a motor driver is something that is sensibly produced in such a way.
Invading the motor driver module and trying to make the components modular is of more limited value. A good general purpose motor driver board IMO makes ultimately much more sense. Like the VESC but cheaper basically.
There is a project to make a driver board, the xESC 2040 based on the RP 2040 chip, and it is already seeing the important benefits from being able to source this chip, while many STM32 chips are just not available.
Ultimately I think with the benefit of experience I can say that a concerted effort to make a good driver board, STM32 or RP2040 based makes a lot of sense, including the code and ideally a couple sensor solutions. However a micropython port of SimpleFOC is not that useful really. I think it would be a better idea to just pick one board and focus on making it better.
For my own application, an STM32 clocked at 64 MHz with an M0 core, so no floating point, is definitely not quite fast enough. An M4 clocked at 164 MHz appears to be adequate, and roughly 7 times as fast. The MCU used on the B-G431b-esc1 board appears to be a sound choice, being available, fast, including op amps for current sensing and generally compatible with the code base thus far due to previous work on that board.
I’ve posted about this a number of times. I hope to obtain one of the xESC 2040 boards for testing, if it is unpromising I will again return to trying to develop this board, which I would dub the Lepton 3.0.