3 ms·

There's nothing wrong with using Python on an embedded platform in certain circumstances, but this article is a poorly written advertisement. > "Expert and ski

There's nothing wrong with using Python on an embedded platform in certain circumstances, but this article is a poorly written advertisement. > "Expert and skilled C programmers could justify this stating that “C generates a faster, more compact, and more reliable code”… BUT … if you replace C with “assembly” in that statement, you’d have exactly what an extinct generation of programmers said about 20 years ago!" Yes, the differences between C and Assembly are directly comparable to the differences between Python and C. > "There’s an enormous crowd of professionals skilled in using Python “potentially” able to develop the software for the “next big thing” in IoT and to ship new amazing embedded applications in a short time." Python doesn't even appear on the IEEE rankings shown at the start of the article, It's amazing how this "enormous crowd" can stay so silent. Are there any examples of products with an MCU running Python being manufactured at scale? Even if Python provides benefits for rapid prototyping, I'm really struggling to think of a business case where you wouldn't replace it with C or C++ before going into production.

xapata 9y ago
Write in Python, sprinkle some Cython, compile to C. The replacement is via compiler. I hear good things about MicroPython as well.
- chipsandkip 9y ago
  Sure, this is a viable approach. But again, are there any examples of companies actually doing this at scale? I'm not familiar with MicroPython, but checking out their website, I expected a testimonial section heralding how it's used by * insert IoT company here *. I'm still not convinced that Python is being used for anything other than hobby work and prototyping on MCU-based designs, but maybe I'm just not looking hard enough.
  - hasbroslasher 9y ago
    > maybe I'm just not looking hard enough This was linked in the article and at the top of the page so.. https://www.zerynth.com/built-with-zerynth/ https://www.zerynth.com/built-with-zerynth/ You're not wrong though, almost no one is using it right now
  - xapata 9y ago
    MicroPython is still fairly new. Cython has been used for C-speed for quite some time.
jjoonathan 9y ago
> Yes, the differences between C and Assembly are directly comparable to the differences between Python and C. To unpack that for PC programmers: the best documentation, API design, and tooling for a microprocessor often happens at the memory map level. Sad, but true. Everything above that is typically cat shit wrapped in dog shit. The C ecosystem natively supports memory and addresses as abstractions, letting you directly consume those APIs, documentation, and tools. Note that this is one of those cases where "best" emphatically does not imply "good," and that it lies in stark contrast to the situation on "real" processors where you'll almost always find solid abstractions much further up the stack.
- chipsandkip 9y ago
  Yeah, my biggest issue with C/C++ on embedded systems is that it's cumbersome to build useful, safe abstractions of hardware. Almost every manufacturer-provided MCU driver library I've encountered is filled with void* and #define abuse that wouldn't fly in any other type of project. I once worked on a project where some poor soul took the time to provide a zero-cost abstraction, described in a Scott Meyers presentation[1], for every register on an MCU. This resulted in thousands of lines of C++ template classes, which, while hurting compile times, resulted in a really strong, safe and performant API that drivers could be built upon. It was wonderful to use, but all that upfront work isn't realistic for most projects. I'd definitely be interested in a language that supports this type of abstraction "natively" (i.e. doesn't require lots of boilerplate code) while providing C-like performance on bare-metal platforms. I know that some people are trying to make Rust fit this hole but I'm not sure how that's coming along. 1. http://www.aristeia.com/c++-in-embedded.html http://www.aristeia.com/c++-in-embedded.html
  - jjoonathan 9y ago
    Agreed 100%. I don't think memory maps will ever go away as the "API" between hardware and software -- the "alternatives" always seem to involve staggering complexity or a violent neutering on either the SW or the HW side (always the opposite of the person doing the talking, of course) -- but I do think that it's profitable to contain that interface beneath application code, preferably with a language-enforced barrier. I'm cautiously optimistic about Rust's "unsafe" as well. I'm just not cautiously optimistic about python :-)
hasbroslasher 9y ago
The author isn't claiming this is happening right now, the author is making a "next big thing" claim: > "There’s an enormous crowd of professionals skilled in using Python “potentially” able to develop the software for the “next big thing” in IoT and to ship new amazing embedded applications in a short time." Potentially is the key word. People aren't currently doing this, but they will if Zerynth succeeds in what they're doing.

xapata 9y ago

Write in Python, sprinkle some Cython, compile to C. The replacement is via compiler. I hear good things about MicroPython as well.

chipsandkip 9y ago
Sure, this is a viable approach. But again, are there any examples of companies actually doing this at scale? I'm not familiar with MicroPython, but checking out their website, I expected a testimonial section heralding how it's used by * insert IoT company here *. I'm still not convinced that Python is being used for anything other than hobby work and prototyping on MCU-based designs, but maybe I'm just not looking hard enough.
- hasbroslasher 9y ago
  > maybe I'm just not looking hard enough This was linked in the article and at the top of the page so.. https://www.zerynth.com/built-with-zerynth/ https://www.zerynth.com/built-with-zerynth/ You're not wrong though, almost no one is using it right now
- xapata 9y ago
  MicroPython is still fairly new. Cython has been used for C-speed for quite some time.

jjoonathan 9y ago

> Yes, the differences between C and Assembly are directly comparable to the differences between Python and C. To unpack that for PC programmers: the best documentation, API design, and tooling for a microprocessor often happens at the memory map level. Sad, but true. Everything above that is typically cat shit wrapped in dog shit. The C ecosystem natively supports memory and addresses as abstractions, letting you directly consume those APIs, documentation, and tools. Note that this is one of those cases where "best" emphatically does not imply "good," and that it lies in stark contrast to the situation on "real" processors where you'll almost always find solid abstractions much further up the stack.

chipsandkip 9y ago
Yeah, my biggest issue with C/C++ on embedded systems is that it's cumbersome to build useful, safe abstractions of hardware. Almost every manufacturer-provided MCU driver library I've encountered is filled with void* and #define abuse that wouldn't fly in any other type of project. I once worked on a project where some poor soul took the time to provide a zero-cost abstraction, described in a Scott Meyers presentation[1], for every register on an MCU. This resulted in thousands of lines of C++ template classes, which, while hurting compile times, resulted in a really strong, safe and performant API that drivers could be built upon. It was wonderful to use, but all that upfront work isn't realistic for most projects. I'd definitely be interested in a language that supports this type of abstraction "natively" (i.e. doesn't require lots of boilerplate code) while providing C-like performance on bare-metal platforms. I know that some people are trying to make Rust fit this hole but I'm not sure how that's coming along. 1. http://www.aristeia.com/c++-in-embedded.html http://www.aristeia.com/c++-in-embedded.html
- jjoonathan 9y ago
  Agreed 100%. I don't think memory maps will ever go away as the "API" between hardware and software -- the "alternatives" always seem to involve staggering complexity or a violent neutering on either the SW or the HW side (always the opposite of the person doing the talking, of course) -- but I do think that it's profitable to contain that interface beneath application code, preferably with a language-enforced barrier. I'm cautiously optimistic about Rust's "unsafe" as well. I'm just not cautiously optimistic about python :-)

hasbroslasher 9y ago

The author isn't claiming this is happening right now, the author is making a "next big thing" claim: > "There’s an enormous crowd of professionals skilled in using Python “potentially” able to develop the software for the “next big thing” in IoT and to ship new amazing embedded applications in a short time." Potentially is the key word. People aren't currently doing this, but they will if Zerynth succeeds in what they're doing.