
Python vs. C/C++ in embedded systems - opensourcedude
https://opensource.com/life/16/8/python-vs-cc-embedded-systems
======
nibnib
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.

------
geis
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.

------
Jtsummers
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.

------
kbumsik
in embedded systems? If he is talking about using Python in microcontrollers,
he does not know what is embedded system.

~~~
rdtsc
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.

~~~
Matthias247
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.

~~~
vonmoltke
> 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.

~~~
JoachimSchipper
Just out of interest - what were you doing?

~~~
vonmoltke
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.

------
w_t_payne
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.

------
out_of_protocol
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

~~~
fumplethumb
> In first case python is fine...

I think you meant second case (RPi), just switched up your wording.

------
minipci1321
> 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.

------
fumplethumb
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.

~~~
rch
What do you think about MicroPython?

~~~
dbcurtis
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.

~~~
StavrosK
> 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.

~~~
dbcurtis
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.

~~~
StavrosK
I imagine I could, but I'm very bad with C :(

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.

~~~
dbcurtis
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.

~~~
StavrosK
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.

------
TYPE_FASTER
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.

~~~
StavrosK
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.

~~~
JoachimSchipper
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.

~~~
steveklabnik

      > 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.

Which platforms are most important to you?

~~~
StavrosK
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.

~~~
steveklabnik
Funny enough, when researching this,
[https://news.ycombinator.com/item?id=9573390](https://news.ycombinator.com/item?id=9573390)

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...

------
new_hackers
I think 'Python vs C ...' and 'Python vs C++ ...' are different questions.
Much like 'C vs C++ in embedded systems' is its own topic.

