4 ms·

Well, "Embedded Systems" represents a continuum ranging from simple non-smart programmable thermostats to microwave ovens, televisions, engine controllers, navi

Well, "Embedded Systems" represents a continuum ranging from simple non-smart programmable thermostats to microwave ovens, televisions, engine controllers, navigation systems, high performance servo controllers and more. I have always found discussion about programming languages to completely miss the reality of what it is to deliver, support and maintain these products. I have developed embedded systems in the context of a real business manufacturing and supporting these products using everything from assembly language, through Forth, C, C++ and, yes, Python. There was always a good reason to make an choice at the time. For example, an embedded system running a sophisticated control panel with dozens of knobs and buttons was done entirely in assembly language eons ago. It didn't take long for that to become a very bad idea. It was very difficult to maintain, improve and evolve the system. We ultimately decided to bite the bullet and port the code to C. The difference in the ability to express ideas was massive. The only two languages I would avoid today are assembly language and Forth. The first because it is a nightmare to support, maintain and evolve outside of trivial systems. The second because it is impossible to find good Forth programmers these days and the ecosystem (libraries, etc.) is nonexistent. That said, I still think everyone should learn both. I have yet to see an embedded system that can't be done well (and by that I mean the entire life cycle of a product) with plain-old C. Nothing wrong with the language. No magic. It works and it can produce clean, reliable fast code. C++. Well. If you came up through assembler and Forth you learn to despise waste. And that's what forcing an object oriented approach tends to be when there is, in the end, no real need to take this route. Sometimes I see OO as a tool lazy programmers reach for. Some of the funniest code I've seen are things like erecting a complex OO solution to implement a state machine when a simple lookup table and minimal procedural code could do exactly the same, run faster and with less resources. I also do hardware in FPGA's so that's a formula for being keenly aware of resources and not wasting them. As for Python. Well, frankly, it's about the libraries and nothing else. If you need to do an advanced embedded system with, for example, vision, you almost can't beat the Python ecosystem. Not because of the language. No. I couldn't care less. I care about time to market and the Python ecosystem offers a cornucopia of solutions covering just about any field one might care to name. You can hire Python programmers and anyone who knows C-like languages can learn it fast. That's important. In the end we build products and all that matters is to build said products as cost-effectively as possible and the ability to support, maintain and evolve them just as effectively.

AnimalMuppet 9y ago
> C++. Well. If you came up through assembler and Forth you learn to despise waste. And that's what forcing an object oriented approach tends to be when there is, in the end, no real need to take this route. I like wrapping an object around a hardware resource, so that the only way it can be modified is a call that went through a public member of that object. You can enforce consistency that way. And C++ has the philosophy that "you don't pay for what you don't use". (Of course, if you use what you don't need, you can still cause waste...)
- rebootthesystem 9y ago
  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.

AnimalMuppet 9y ago

> C++. Well. If you came up through assembler and Forth you learn to despise waste. And that's what forcing an object oriented approach tends to be when there is, in the end, no real need to take this route. I like wrapping an object around a hardware resource, so that the only way it can be modified is a call that went through a public member of that object. You can enforce consistency that way. And C++ has the philosophy that "you don't pay for what you don't use". (Of course, if you use what you don't need, you can still cause waste...)

rebootthesystem 9y ago
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.