You don't need C++ for that. Let's say we are talking about a serial port and a motor driver, all in the same MCU. A programmer would have to be pretty sloppy to use motor controller functions to try and talk to the serial port.

If I write a function called "set_serial_baud_rate()" and another called "set_motor_rpm()" it would be alarming if someone tried to use it to set the set_motor_rpm() to change the serial port's baud rate.

I understand encapsulation very well but it simply isn't necessary in a lot of embedded cases. I can't remember a single instance in thirty years of product development when we had an issue in development because code was NOT object oriented. Product development never slowed down due to not using OO. More bugs were not introduced due to not using OO. Code was just as maintainable and extensible using C or C++. It truly does not matter at all as far as I am concerned.

What I look for is "done for you" code. Libraries that can produce power-of-two or order-of-magnitude gains in developing a product. Show me gains of that magnitude and I'll code in COBOL if necessary. I truly don't care about languages any more. Just like I don't care about code editors (counting milliseconds in vim). Give me a decent IDE like JetBrains products and life is good.

I know this puts me at odds with most of what they teach today. Kids come out of school and automatically reach for objects for even the simplest of problems. OO has it's place, of course, but it should not be the first tool one reaches for unless it is well justified.

A CPU couldn't care less if you wrote the code in machine language or Python. The facilities provided by these languages are for the programmer, not for the CPU.

One of my favorite interview techniques: Ask someone to solve a problem. If they are on the younger side they'll immediately define a class, members, properties, maybe multiple classes. When they are done, ask them to do the same in procedural form. I've seen people get completely tangled-up by this simple request.

EDIT: To be clear, I am NOT saying OO doesn't have it's place. Of course it does. I've written a bunch of iOS apps in Objective-C with a good mix between OO and procedural when justified. For example, a genetic solver done in procedural form on iOS is miles faster than the same solver implemented in OO. A lot of it has to do with using layers of data objects rather than the raw data types typically used in C. In other words, there's a cost associated with using an object to store and manipulate what would otherwise be a simple array. You might be surprised to see just how dramatic the performance improvement can be.