I checked it in practice, and it seems fine. Reading and parsing a 115200 baud telemetry stream from the ESC is the most expensive part of the whole thing, but

I checked it in practice, and it seems fine. Reading and parsing a 115200 baud telemetry stream from the ESC is the most expensive part of the whole thing, but even still, I split it up in a way that caps the amount of work that this subsystem is allowed to perform per loop, so all other parts of the loop get a chance to execute very often. The GC by default only collects garbage once you don't have enough memory for the next allocation, I thought I might need to adjust that, but even though it triggers regularly in my code, it never seems to cause a noticeable slowdown. Despite "flight controller" sounding realtimey, the code is resilient to some reasonable latency. One potential concern is that CircuitPython does not support user defined interrupts, but I haven't needed that personally. And I think you can still have those if you drop into C? Not sure. At any rate, if it does get slower as I add more code, for me it's easier (and safer) to deal with that, than with subtle memory corruption foot guns in cpp.