Handling a Family of Hardware Devices with a Single Implementation - Ben Saks - CppCon 2021

[@technik27]

This is exactly why I always say C++ is the best language for embedded microcontrollers. Whereas in C people usually solve this with a mess of macros and duplicated code, in C++ you get type safe, perfectly optimized code that is very flexible and easier to extend.

[@ruslangabitov5202]

Very thanks for this video. I believe not only me are impressed with the techniques demonstrated in this presentation. Thank you for inviting such a great expert to the Conference.

[@CppCon]

Thank you very much!

[@jg5275]

Amazing talk! I always enjoy watching your presentations and especially the back to basics because I am a bit of a novice. Thank you!

[@CppCon]

You are so welcome!

[@rinoan1]

First of all: thank you - Ben Saks - for creating and sharing this talk. I found it downright interesting to see this low-level generalizing of timers as a show-case of how useful C++ is - without the cost of performance. I would be interesting to hear more about the performance measurements of direct-mapping vs pointer-to-register that you mentioned in the talk. Why would the pointer solution be slower (and noticeable so)?

[@brandonlewis2599]

For the record, the embedded Rust team has a pretty killer HAL that's built along these lines, and also worth a look. Rather than having to roll your own templates and drivers, you can just use theirs. You get similar guarantees about static "devirtualization" (the Rust equivalent of), PLUS you can take advantage of the borrow checker / ownership / *reliable* move semantics in the safe subset of the language. I.e. you can confine your unsafe blocks to the stuff that actually touches hardware, and write the rest of your app / RTOS / etc in the safe subset.

[@brandonlewis2599]

Granted, there are still plenty of embedded arches that LLVM, and therefore mainline rust, does not support, including AVR (though in that specific case, there is a port).

[@tchitchikov]

Great presentation. Thanks Ben!

[@101constexpr]

great talk, thanks Ben

[@marcbotnope1728]

No no no no no this is the ROAD to madness! Andrei Alexandrescu wrote about this in Modern C++ Design calling it Policy-based design. The complexity needed here is outside the skill set of 95% of the C++ programmers in existence.

[@embeddor2230]

I think that policy-based design Andrei Alexandrescu wrote about isn't that compicated at all once you clearly state what the "best practices / rules" are to implement it correctly. After that it actually reduces complexity of your design by providing a symmetrical and recognizable pattern that is easily extensible. IMO, it's the best extensible design pattern ever.

[@rafikmoh9295]

hi thanks for nice and brilliant lecture. can we communicate and wrire and read data from the sensor associated with ARDUINO OR ARM LPC2148 without using their IDE? I mean can that can we write the program (software) in C and C++ to direct communicate with the hardware in UBUNTU.

[@md2perpe]

This is like the Strategy pattern, but instead of passing a strategy object to a function that constructs an object, one is passing a strategy class to a functor that constructs a class.

[@АлександрИзмайлов-т8ь]

16-bit timers have special ritual to get counter value. Low byte first (maybe the compiler does this way already). And with interrupts disabled or not accessing TEMP register. So real get_counter() method should be not so trivial.

[@PedroOliveira-sl6nw]

Gonna try this with GPUs and rendering APIs

[@fromgermany271]

Arduino is only the board (hardware). The software environment is avr-gcc, which is also used by Arduino, but here the Arduino libs are missing. Good so, because Arduino library is a horrible piece of C++ code. I often came to the conclusion that they tried to accumulate the odds of C++ and C.