Hacker News Reader

> 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.

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

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 :-)

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.

Write in Python, sprinkle some Cython, compile to C. The replacement is via compiler.

I hear good things about MicroPython as well.

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.

> 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/

You're not wrong though, almost no one is using it right now

MicroPython is still fairly new. Cython has been used for C-speed for quite some time.