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.