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.