Fair question. Yes, the product works fine and has been in service in a demanding industrial setting for a year. To make it work we had to write portions of t

Fair question. Yes, the product works fine and has been in service in a demanding industrial setting for a year. To make it work we had to write portions of the code in assembler. Extracting performance out of Python is a losing proposition. You are starting out at somewhere around 70x slower than C. We thought MicroPython could pull it off. By the time we understood it could not, there was no way to start over with C. Things that are trivial to code in a performant way in C are impossible to code in Python. A simple example of this is a cyclic redundancy routine. We had to write those in assembler. Also, garbage collection was problematic, even controlling it manually. If I remember correctly, it took out a 5 us chunk of time. We had to resort to such things as allocating large buffers globally to avoid allocation/de-allocation issues, etc. This was done mostly by declaring global variables as tuples (due to the simple memory structure) and then accessing them with assembler routines. The immutability of tuples only exists within the confines of Python, outside of that, it’s just memory. This approach resulted in massive performance and memory utilization (reduction) gains. Beyond that, the entire codebase was a single function running a state machine, this to avoid costly (time and resource) function calls. Eventually the thing starts to look like a typical bare metal embedded system where you create a round robin scheduler, etc. At that point it is very hard to justify using Python for anything, in fact C is far easier. Code like that quickly becomes something that is hard to maintain, enhance and evolve. It became very obvious that we had to switch the product to C as soon as possible.