3 ms·
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
by 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 agoAgreed 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 :-)