That's what I was thinking. Nevermind not having things like bit shifting, python can't even run on most micros, because there's no interpreter for them. Micro-python is a thing that exists, but hasn't expanded yet and is probably a long way off.
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.
Hmmmm...I don't remember what I was thinking then. I remember wanting to use something more typically low level, like bit shifting, and it either being way too much hassle or not supported.
The big problem I've had with Python and bit shifting has just been dealing with negative numbers. Python doesn't have a concept of unsigned ints, or even just 32bit numbers so I end up having to mask everything by 0xFFFFFFFF. Not really a big deal but maybe that's the issue you were running into?
That sounds like it might have been the case. I probably got annoyed and just did it a different way. I'm not really sure though. It's one of those things where it happened awhile ago and made an impression on me, but the details have long since faded, leaving only my opinion :)
Does embedded mean micro-controllers only? I've worked on i7 boxes with 16GB of RAM as "embedded systems". Various customers bought them as such. I guess we've been fooling ourselves and our customers for 10+ years.
Not well defined, but to me embedded just means the device is not a PC or a server.
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.
I think there's a lot of room in the embedded system space beyond just a microcontroller, but I would not be comfortable calling something that beefy "embedded."
It's not the size that makes it embedded. It's that it's something that isn't supposed to be a computer - it's supposed to be a nuclear power plant, or a railroad locomotive, or a microwave oven. Size has nothing to do with it.
Embedded systems mostly means that the OEM delivers a complete device (hardware and software) where the endcustomer doesn't install anything else. These systems can contain anything from 8bit microcontrollers to i7 processors.
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.
An airborne radar signal processor. We were using telecom-ruggedized IBM blades to run a large-scale (for an airplane) clustered signal processing application. The processing was divided spatially, but needed to be implemented as a grid because the workers had to move in lockstep through the stages of the pipeline.
Is there any custom hardware, built in house, in it? like is it a custom motherboard or do you put in custom PCIe cards that you can't find anywhere else?
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.
It was about a 2U server size but with additional external packaging, cooling improvements. Some specific hardware cards in in it, wouldn't say "can't get anywhere else" but it was very specific for application domain.
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.
Yes you are right. So just saying "embedded system" is very misleading. He did not mention any of specific field. So I still think he does not know embedded system.
The argument that new graduates will know Python and have an easier time with embedded systems never sits well with me. If they graduated in something to do with embedded systems then they will know C. If they have a general programming background then they will need some training anyway, as embedded systems often require a different mindset geared more towards low-level programming. So they might as well learn C while they're at it.
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.
I think an important point in the context of Python (and other languages) vs. C/C++ is the proliferation of cheap hardware capable of running Linux. The relatively new phenomenon of a $10 Linux device makes it an attractive option in many situations. The cost gap between a traditional microcontroller (no Linux) and a linux device is closing.
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.
I am a total MicroPython fan boy. I've done a lot of embedded C-on-bare-metal development and related electronics. For most non-embedded work, I use Python and am a huge fan of the language, so having Python on an ARM Cortex gets me very excited. MicroPython is absolutely great for getting a complex embedded project up and running quickly. Execution performance, of course, is nowhere near C. But, since a lot of performance critical I/O handling is already done as a C extension (import machine), and it is just as easy to write a MicroPython C extension as it is to write a CPython C extension, you can always move the performance critical parts to C as needed. Overall it is a huge win in development time. MicroPython does require a fairly biggish ARM Cortex M3, though.
> MicroPython does require a fairly biggish ARM Cortex M3, though.
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.
Yes, but the ESP8266 is a bit of a squeeze. It's a more comfortable fit on larger processors.
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.
The code for Micropython is very well structured. The toolchain is pretty easy to set up, just apt-get and go. The configuration things like I/O pin assignments and such are all on pretty simple definition files. I'd be very surprised if the repl loop takes more than flipping a #define to turn off. No C wizardry needed.
Hmm, I'll have a look, but currently you need the repl to be able to write files (otherwise I'd have to include my files in the firmware and copy the entire thing every time).
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.
Err. I wouldn't learn python to make yourself more attractive in the embedded software engineering field. I do embedded software in mostly Python and C these days and when I get messages on Linked in from recruiters they're normally looking for C++ experience which I've become weak on.
I've been brushing up on Python (and Elixir!) to make myself more well-rounded as a software engineer, not just an embedded engineer. However I stand by my point that many "embedded" domains are served just fine by a Linux device, which can be programmed using Python.
Also not sure how much stock I put in what the recruiters on LinkedIn are touting...
> When it comes to speed, however, runtime speed isn't the only aspect of development to consider—you also have to consider development speed.
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.
Python is great for simulating, processing data, providing an interface to automation control, but I'd still use C++ for anything time critical. With more recent versions of the standard and Boost, you can be quite productive with C++ without giving up much in the way of runtime performance.
I don't know C++, so take this with a grain of salt, but I'd rather use Rust for those things right now. The problem with the embedded landscape right now (I mean really embedded, not MCUs that run Linux) is that tooling around using unrelated libraries isn't very good.
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.
I'm actually very surprised with modern (C++11/14) you're having to write so much boilerplate. I actually find I spend more time tracking down weird bugs in Python (that only show up at runtime) than I do with C++. Especially with great static analyzers.
When you do embedded you have to deal things like memory mapped IO, setting up pointers for various devices and stuff like that. How do you expect to that with python?
Erm, Rust-as-designed may or may not be suited for embedded, but Rust-as-it-is-now has some nasty limitations - not the least of which is the lack of support for anything that is not ARM.
> not the least of which is the lack of support for anything that is not ARM.
This might be true with regards to embedded architectures, but isn't in general; MIPS and PowerPC are in tree, and we can fundamentally support anything LLVM can, there's just the initial work to get it going.
It's too bad that nobody is replying to you. Personally, I would be over the moon if I could develop for the ESP8266 in Rust, but that might be a tall order, since it's a very small chip.
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...
>I don't know C++, so take this with a grain of salt, but I'd rather use Rust for those things right now.
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.
C++ on embedded is a godsend. It's so much easier to be productive, the code looks much cleaner, etc. At this point, static analyzers and compilers are also pretty good at catching the most common issues. Too bad many embedded compilers don't support all of the latest features.
Embedded systems has begun changing in a way that makes much of this discussion (about Python vs. C++) moot. There are small devices with a ton of compute power that run Linux quite easily, i.e. Raspberry Pi. However, devices are also getting much smaller and consuming less power, i.e. chipsets for smart watches.
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.
Python is already incredibly popular when it comes to testing embedded systems, and also incredibly popular when it comes to prototyping algorithms and doing data analysis.
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.
Python being or becoming the most popular introductory language for CS is irrelevant to understanding what graduates know. There's 4 years between their introductory course and their graduation.
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.
How about distinguishing between arduino-level embedded systems and raspberry-pi-level?
In first case python is fine, you have full-featured OS anyway already. in second case python doesn't fit at all. what's the question then?
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
55 comments
[ 5.4 ms ] story [ 120 ms ] threadHonestly, 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.
https://github.com/micropython/micropython/
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.
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.
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.
[1] http://nerves-project.org/
Also not sure how much stock I put in what the recruiters on LinkedIn are touting...
I appreciate the opinion though!
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.
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.
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.
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.
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.
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.
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.