3 ms·

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

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

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