10 ms·

As someone with embedded development experience going back to the 1980’s and across more platforms than I can remember, I agree with your perspective. Still, e

As someone with embedded development experience going back to the 1980’s and across more platforms than I can remember, I agree with your perspective. Still, even so, I decided to give MicroPython a go for a new design; an industrial product we would ship in the tens of thousands of units. This will count as one of the many choices I will regret making in my business history. I won’t bore you with details. We shipped 250 units. We are busy porting the code to C as fast as humanly possible. At least I can say we tried. I have coded embedded systems with assembler, Forth, C and C++. Any one of these would be better than Python. Yes, I use Python extensively for desktop, data science and web work. It simply isn’t a good fit for embedded work.

rowanG077 3y ago
I'm curious what made you backpedal after shipping 250 units. I imagine you at least very least made it work at that point.
- robomartin 3y ago
  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.

rowanG077 3y ago

I'm curious what made you backpedal after shipping 250 units. I imagine you at least very least made it work at that point.

robomartin 3y ago
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.