C++ for the Embedded Programmer

David Ledger shows some advantages of using C++ in embedded microcontroller applications.
The use of template classes and meta programming to make code more platform independent and readable (and fun!) (David made me add that last bit).

[_-martin-_]

This is an unfair comparison. Yes, ultimately you can achieve a higher level of abstraction with C++ compared to C but what you are doing there is comparing highly abstracted C++ code with almost non-abstracted C code. It's not so much a language problem but rather a failure to apply the same level of abstraction on both sides of the equation.

[sayersgraham]

For any embedded programmers, I highly recommend Bob Martin's popular book "Clean Code". It guides you in a similar direction to what Dave is showing here, but goes into detail about why it matters and specific steps on how to get there. Being a EE, I never encountered these ideas in school, so it was very valuable. As others have pointed out, the C code on the right is not really a fair comparison. While functional, the C code still needs to be cleaned. Your main C loop (top level of the application) could look something like this:

if (isButtonPressed())
turnLedOn();
else
turnLedOff();

[nBoxes]

Yes, please go into depth on this. Something like 45 minutes explanation of the Pin and Led classes along with the template part would be highly appreciated.

[izimsi]

I'm sure this video took some time to produce, but it wasn't a good time spent. It has virtually no sense to compare semi-standard library from a manufacturer in C to a custom library in C++. It's not a comparison between languages, it's a comparison between libraries.
I it surely possible to create a library in C with a similar interface, obviously not using "methods" or overloaded operators, but the same amount of code should fit in around 10 lines of C code.

[kentvandervelden]

David, don't know if this would be of interest to you, but how about a lesson on timing constraints of FPGAs, how and why to specify them, impact on propagation, layout, and upper end clock speed, and such? I mention it because it seems a really cool topic, the importance was emphasized in my graduate reconfig computing class but nothing practical was provided.

[fdlouw]

I actually prefer the C way, because I can see exactly what is happening. Sure, I can just put everything in some function in a different file and get the same result, but even for C++ the constructors have to be somewhere in some library. It comes down to how abstract you prefer your main program to be.

[maciejbacal]

just put the C code into functions, it's the exact same thing you did for the C++ example

[robertjay]

I love the end card. It's good to see a bit of software stuff on this channel too, modern hardware is half software after all.

[mbaker]

I stopped using assembler over 30 years ago. Yet so many people still use it because it is 'fast' or some other arcane reason. C++ which itself is decades old shows how code can be simple, fast, understandable and supportable. The question is will you release your libraries for others to play with? Otherwise we get everyone reinventing the wheel. Yet again.

[lodevijk]

I've been working with visual studio for years now, and just now (thanks to this video) I realized you can select columns with the cursor by pressing Shift+Alt. Thanks!

[Psychlist]

To be fair, everything is horrible in Eclipse. :D

[lodevijk]

I would love to see how you built these classes and what's behind that C++ syntax.

[mattb]

Wow this is awesome. Right now at work we are getting further with our prototypes, and i'm doing this exact transition with our code from the brute force C code, to the much more usable C++ version.

[altair]

FWIW, there's really no reason the C code has to be any more complicated (all told) than the C++ code. It's just that you're using a very low-level library of C code and a higher-level library of C++ code. You could build a higher level C library and the code wouldn't look hugely different (you'd have to call a function to set the LED or Enter output, whereas in C++ you presumably use assignment).

[mikeselectricstuff]

Manufacturer libraries for things as simple as GPIO are a waste of time - more stuff to learn, more scope for bugs. Just stupid.

[obriska]

1) You have to mention, that LED is a variable that occupies some space in RAM whereas C code occupies RAM only for the initialization part. It might not be critical for this case, but it might be critical piece of information for somebody, who decides to use your advice; 2) You have put data into the type declaration instead of the instance of the class (struct) yet an instance of your type Pin<> still occupies some space in RAM even though it holds no state - that is clearly not a good practice from a C++ design standpoint. 3) Since you are encoding state into a type declaration, what do you think will happen, if you define a new variable with the same type? You will get two variables referring to the same pin yet wasting the double amount of RAM to hold both variables; You could have defined a const variable in the global scope, but then your fancy operator overloads would look even stranger; 4) Now lets look at your assignment operator overload - you have a variable that holds no state, instead the assignment operator changes the global state (the GPIO pin); What if you assign one variable of the same Pin<> type to another? It doesn't do what a typical programmer would except it to do, because the assignment operator doesn't transfer state of the variable but rather copies the global state onto itself. This is mind boggling and is not a good C++ programming practice as well. While it is encouraging that C++ is squeezing into the embedded space (not so long ago the C had a very similar fate trying to compete with assembly language) yet we are not there yet. Making you code not just shorter, but also to obey basic principles of C++ design would require quite a lot of effort. And we are talking only about GPIO pins here. So, maybe there is a reason, why the embedded world is still holding to C and assembly language - these languages are perfectly solving the problem w/o having to dwell into the wonderful world of metaprogramming and building of multi-layer abstractions.

Edit: I just want to add that GPIO pins are very similar animals, but using your technique it is not possible to group them or to put into a collection, which is also something to think about before taking you advice as it is presented.

[MrNukKKT]

David, I don't think this is about C vs C++. One one side, you are using a nice GPIO framework, and on the other side, you are using STM's GPIO library.

You demonstrated that STM's library is horrible, but this has nothing to do with C vs C++. You can have a sane GPIO framework in C, and you wouldn't have to worry about "all this". Or you can have a bad framework in C++.

You have demonstrated that a good library will simplify the code and improve readability. I am in full agreement with this conclusion. But a good library has little to do with the language.

[Elavid]

The C++ code on the left was not platform agnostic since it has "Port::B, 7" in it. On a Raspberry Pi, you just have a pin number and don't worry about ports. On most microcontrollers you'd at least need to think about changing those pin assignments. I think it makes a lot of sense to just have a single pin number like the Raspberry Pi or Arduino environments, so you can put that single number in a macro or constant easily.

[felixdube]

LOVE IT!! I want more of these video!
You're great David!

[lodevijk]

I would like more of this kind of stuff, I really enjoyed this video. No-nonsense, just a tutorial