Python vs. C/C++ in embedded systems
opensource.com
opensource.com
I think the popularity of Arduino with complete beginners shows that the barrier of entry is rolling the bootstrapping code and getting tools set up, not the language itself.
Saying all embedded will get so fast that you can always use Python ignores the side that is focused on smaller footprint and power consumption. Saying that embedded is only hard-core C or C++ stuff that must be compiled is ignoring the Arduino/Pi world where devices that used to be clearly embedded are now powerful but still very small.
However, in either case, we do still regularly deal with a lot of issues such as constrained resources, real-time needs, etc. Grabbing a random engineer who knows Python and saying they're going to be good at that is silly. In many, many cases you'll still need to learn how the system truly works top to bottom to be effective.
A good CS program will introduce CS students to several (hopefully many) languages. Some form of assembly, imperative languages like C, something like C++/Java/C#, hopefully a "purer" OO language like Smalltalk, functional languages like the ML-family, and others. Ideally with a properly chosen language (or a couple languages) in each of the first series of courses, and leaving it up to the students after that for their 3xx and 4xx courses.
And any CS graduate who can't pick up a new language in short order has been cheated out of a good education by their school.
Honestly, if we're talking about replacing C / C++, it would seem we should be comparing them to Rust or something, not a language whose use model isn't really intended for embedded systems.
I love Python, but this just doesn't seem like the place for it.
And by embedded, he probably meant Raspberry Pis running Debian or something like that.
Either way, thanks for the correction.
Could be a microcontroller running bare-metal code or an RTOS with application code. Could be a device like you describe above which, in some cases, resemble a PC with custom I/O requirements.
But of course, when many people talk about embedded systems (especially in the context of development) they mean the more constrained devices (microcontrollers without OS or with realtime OS, ...). That's because the others are more PC-like and therefore don't have these special requirements during (software) development.
Requirements are based on the task, not the hardware. I have written firm real-time software for multi-processor, multi-node Xeon and POWER7 systems.
If it's a standard Dell server with just some custom software and nothing else special about it, then I have a tough time comprehending why it would be called an embedded system.
If it has like a PCIe card that you can't get anywhere else. that you can only interact with the embedded software you provide. Then maybe I can see it being called an embedded system.
The difference I saw was that a customer was not supposed to interact with it as a general server. They didn't install stuff on it, interacted mainly via external devices and via a web-based config interface.
It was also configured for a specific purpose and had tweaks to kernel scheduling algorithms to provide low latency data processing.
From my perspective, C and Python provide a nice complement to one another and whilst I wouldn't necessarily put Python onto a very constrained embedded target, I'd certainly use it for everything else - simulators, build systems, unit tests, requirements tests, nonfunctional KPI testing, end-of-line production testing, calibration, documentation generation, configuration file generation and all that jazz.
Also, for arduino-level systems i wish there would exist (and in active use) better language then C/C++ something in Rust/Nim/mruby/Crystal-direction. Low overhead and better syntax
I think you meant second case (RPi), just switched up your wording.
It is not clear what sub-domain of the embedded-systems world this article targets. I read once somewhere that controlling equipment for nuclear stations is also embedded development. In general though, first and foremost, you will be considering the BOM cost -- how to reduce it, and how your software choices will impact it.
Several strategies are possible: in the small-uC world, people start by developing on higher-end models, then optimise the size and speed as the product ships, to shoehorn the sw into a smaller, less expensive models. This is only possible if the cost of validation is not prohibitive (and if it is at all possible to re-validate the product again -- think about any possible re-certifications to do if the hw changes).
If such re-validation is too costly or impossible, one will be cost-optimising the platform right from the start, and in general, cost of development -- an important factor (especially for those who has failed a product at least once ;-)) -- will come only in second to that.
The Linux device is compelling when speed (and ease) of development is important, scale is low, or the market is insensitive to pricing. Not to mention the added bonus of more processing power. On the other hand a traditional microcontroller is still compelling where volumes are high or there are strict real-time concerns.
As an embedded software engineer, I'm watching closely. Personally I'm reaching up to higher languages like Python to make myself more attractive in an industry that I see moving toward more Linux devices.
Wit the current, appallingly bad battery technology the only way off-the-grid IoT can hope to proliferate is by keeping the power consumption as small as possible. This is of course a problem for a rather specific use case of IoT/WSNs, but one that gets completely destroyed if not taking this into account.
What do you mean? I run it on an ESP8266 just fine, the tooling isn't great (it launches a REPL and takes up your serial port with no way to stop that), but other than that it's fantastic.
As to the serial port/repl issue, can't you build your own image to do something else that you like better? Micropython is pretty easy to build, in general.
The REPL is fantastic when you want to prototype stuff, but it's not great when you want to actually deploy things. I'm sure there's going to be some way to avoid launching it in the future, though, such as having a main.py file that has a `repl.run()` you can take out when deploying your own code.
That's not really so bad, as it's what you do for the C++ version, but it would be nice if there were a way to update the code somehow. Maybe I'll write some code to fetch a file from an HTTP server and unpack it, though.
Also not sure how much stock I put in what the recruiters on LinkedIn are touting...
I appreciate the opinion though!
I use PlatformIO for managing dependencies, but generic libraries that aren't exclusive to embedded programming aren't in the repositories. In general, if you want to add a library, you unzip it into a directory and pretty much never update.
I find development with C/C++ much more painful than with Python, when most of the time I just want the thing to work, not to spend two hours writing boilerplate.
> not the least of which is the lack of support for anything that is not ARM.
Which platforms are most important to you?
It seems like a lot of people are interested in this, but there isn't an LLVM backend yet. There is someone working on a Rust -> C transpiler, so if that matures enough...
Right now? Do you do any embedded development at all? In principle, I would love to ditch C++ in favor of Rust forever, but in practice Rust isn't anywhere near "there" yet in terms of tooling and platform support.