Python vs. C/C++ in embedded systems

6 readers like this.
One lightbulb lit out of several

Opensource.com

The C/C++ programming languages dominate embedded systems programming, though they have a number of disadvantages. Python, on the other hand, has many strengths that make it a great language for embedded systems. Let's look at the pros and cons of each, and why you should consider Python for embedded programming.

C/C++ are compiled languages, while Python is an interpreted language. C/C++ have been around for ages; C was first developed in 1969, and C++ came along in 1983. Python is younger as it was created in 1989 by Guido van Rossum. Since then, it's become one of the most popular open source programming languages. All Python releases are open source and freely usable and distributable, even for commercial projects. (If you're looking for commercial- grade support and indemnification, distributions like ActivePython are available.)

The case for Python

Python is the most popular introductory programming language at the top computer science (CS) departments in the United States. According to a study by the Barr Group, eight of the top ten CS departments currently use Python to teach coding. Debate the merits of it if you want, but the simple fact is that the most widely understood language in the hiring pool of recent graduates is Python. It's dramatically more likely that a recent graduate will understand how to code in Python than in C/C++.

Hobbyist developers are likely to have some experience with Python, and it's more likely that they'll be proficient in Python than in C/C++. Since only about 40% of computer software engineers and system analysts have computer science degrees, a lot of industry hires are coming from hobbyist backgrounds. But when it comes to embedded systems, the numbers flip pretty severely. The Barr Group study shows that over 95% of the code for embedded systems is written in C/C++. This legacy on embedded systems might be hard for Python to overcome, but its attributes and the sheer number of people coding in Python might help it overtake C/C++ in the future.

Python isn't only the most-popular language for introductory CS programs, it's also the fastest-growing language for embedded computing. Maybe that sounds silly when you scan the numbers again and realize it's the fastest-growing language of the remaining 5% of embedded systems code that aren't C/C+ +, but Python will start eating into C/C++'s monopoly even more over the next few years. Hobbyists migrating into the industry with experience programming drones, robots, or other projects frequently have an Arduino or Raspberry Pi background. They'll likely have dealt with Python on some level in that time, and it's also likely that they'll have bumped up against some embedded systems programming.

While C/C++ is slow to write, error prone, and frequently unreadable, Python is known for its writability, error reduction, and readability. The importance of readability can't be overemphasized: when you're working in a team, readability is paramount to maintaining the code. It has to be easily decipherable unless you're willing to shell out more time and money on debugging and quality assurance. The design reuse of Python far outclasses C/C++, and in today's Agile environments design reuse can be the difference between staying ahead or falling behind the competition.

Embedded algorithms are getting increasingly complex. Simple control loops are being replaced by neural networks and other heavily-involved processes that have helped Python gain its foothold. There are Python libraries like Theano that will optimize Python code for these processes. While Theano is mostly written in C/C++, Python is used to interface with high-performance libraries in a human-friendly way. Python libraries are thriving—PyPI, the Python package index, has over 80,000 modules, and these massive compendiums dramatically increase the productivity of programmers by giving them the option to skip a few steps and use already-established functions in their own code.

The case for C/C++

The case for C/C++ is pretty obvious: it creates more compact and faster runtime code, and it's already the language of choice for 95% of embedded system code, so it has a whole legacy that Python will have to overcome. When it comes to speed, however, runtime speed isn't the only aspect of development to consider—you also have to consider development speed. While Python may be less efficient than C/C++ at runtime, during development it's much more efficient. Interpreters read each line of code, parse it, do runtime checks and call routines in order to execute the operations in the code. This is a lot more activity than what you get from running C/C++ code, where the same line of code might be compiled into just a couple of instructions. This can lead to slower runtime speeds and higher energy consumption with Python.

Improving Python's speed

So the main case against Python versus C/C++ is its runtime speed, but there are several ways to optimize the code so it runs more efficiently. Aside from libraries like Theano, there are optimizing extensions for Python like Cython, which is essentially Python with static typing and keywords to run math more quickly. Because Cython is statically typed, you can easily compile to C/C++ and run at C/C++ speeds.

Just-In-Time (JIT) compilers are another good way to improve Python's runtime speed. These compilers work in parallel with Python's interpreter to generate compiled machine instructions for code inside loops. This allows subsequent passes by the interpreter to execute faster. The PyPy JIT compiler is able to increase Python's execution speed by nearly a factor of two. JIT compilers should only be used if there's enough space, though, and embedded systems don't usually have a lot of that to spare. The best optimization is to use better data structures and algorithms, but this is the hardest task in software design and implementation, so it might be best to utilize one of the tools above, depending on your skill level.

Using Python to communicate with embedded systems

Python might be at its strongest when used as a communication middleman between the user and the embedded system they're working with. Sending messages through Python to or from an embedded system allows the user to automate testing. Python scripts can put the system into different states, set configurations, and test all sorts of real-world use cases. Python can also be used to receive embedded system data that can be stored for analysis. Programmers can then use Python to develop parameters and other methods of analyzing that data.

Currently the main debate about the merits of Python and C/C++ comes down to what's more important to your team: development speed or runtime speed. In the future, though, it might not be up to Python programmers to make their case for its use in embedded systems, but rather for embedded systems designers to figure out how to accommodate the relentlessly increasing popularity of Python.

User profile image.
Tom Radcliffe has over 20 years experience in software development and management in both academia and industry. He is a professional engineer (PEO and APEGBC) and holds a PhD in physics from Queen's University at Kingston. Tom brings a passion for quantitative, data-driven processes to ActiveState.

24 Comments

I have nothing against Python, but I think if you are embedding software you must consider using Lua first.

Well, you've given misleading information. A huge percentage of embedded systems don't even have an operating system. C/C++ programs can run without it. You've forgotten to say that. You also forget to say that Python, as well as Java, C# and Ruby, needs not only an operating system, but also the virtual machine, the JIT, and the garbage collector. That makes it too fat for embedded systems. Ok, RPi has a lot of resources, but Python is slow as hell, so it's only purpose on an embedded system is to drive the GUI, if there exists one. Last, but not less important, is the fact that Python allows you to write (or code) a program, but it doesn't mean you know how to program. The same issue is with arduino, anyone can write anything on it without knowing what is being done. Sad for us that learn programming.

I completly agree with you.
This article is not even considering optimizations in C/C++ itself, and how could you even compete a Python program resource usage with another same purpose program made with C/Assembly?
I see programing languages as tools to solve my problems, and using Python for dedicated embedded drivers or embedded software is like hammering a screw.

In reply to by Xavier

That is not true.
There exist the great Micropython Project, which is especially for embedded devices:
https://micropython.org/
It is far from slow and with the esp8266 port you can run Python on a $2-device with wlan.

So for connecting switches, sensors or relays to the internet, it can't be easier than with micropython on a esp8266.

In reply to by Xavier

There is an OS there - only enough to run uPython but its still an OS.

In reply to by STuart (not verified)

C/C++ and Python serve for different purposes.
Is like comparing apples and oranges, both are fruits but still are different. A minimalistic C++ Hello World program has about 8.8KB, while a python interpreter+shared libraries it is a much bigger combination, and and often many times slower.
Obviously the speed of python code can improved substantially, but there is still much to be done in this direction. Python is more for prototyping applications in a fast way, RAD style.
Python himself is mostly written in C language.

http://svn.python.org/view/python/branches/release32-maint/Python/

Working with embedded systems is not for hobbyists. Mostly it is for the industry and is serious work for electronic engineers, not for software engineers.

When applied in industry, it can not be left anything to chance. You need a robust programming language, close to the low level. A lot of code in embedded systems has parts in assembler, and others have RTOS, where the convergence is vital. Seriously, if something went wrong, a pneumatic pad could rip someone's arm.

You could not be more right. People who are amateurs or enthusiasts may know enough, but nothing can ensure the integrity of the system when it comes to efficiency and safety. The awareness of the danger is not common even when amateurs assemble a drone or a motorbike, it must be the responsibility of the retailer/provider when it comes to that but it is difficult to control such a big market so bad stuff will happen anyways. Sad but true

In reply to by tute_avalos (not verified)

MicroPython runs on several embedded devices (STM32F4, ESP8266, and others)

I actually believe the future for embedded programming lies with source-to-source compilers. You can get high-level safety and ease with C/C++ performance. Only the hardware abstraction layer really needs to be in C/C++.
The Vala language has proved the concept on desktop computers.

Comparing C++ and python not good idea. Actually when you use java or python for embedded systems. You code c/c++ more than java or python. You code c/c++ after you link your code java or python vm. Actually it is shit. You cant use all feature of python or java languages. You already use c/c++. You can make every project with c/c++ at embedded platform. Java or python good for server , web , cloud .etc

i think top 3 programming language for future. Javascript, c/c++ and java.

I like nodejs than orders. Because node js will be the most popular language for industry 4.0 , iot , big data, cloud.

What exactly makes C++ so "hard to read"? Well written C++ is going to be eaisr to read than poorly written python. Not sure i get language advocacy. Every serious language does pretty much the same thing,..its just expressed a little differently. You spend a lot more time figuring out the nuances of an api than you do on language syntax.

Most of these comments are spot on. Sorry Tom, I'm sure you're a smart man but you missed the boat on this one, by 20 years. People like you have been saying Python, Python, Python for embedded for that many years, if it was so great, it would have taken hold. Actually python is a horrible language for what you're advocating it for. There are many reasons why you don't use it in ANY systems critical environments. Sure ActiveState has modified Python just like Microsoft modifies every language it has ever encountered, that doesn't make it an end all language. You're basically saying interpreted(corporate modified) vs compiled. Python hasn't taken over for the same reason that Java hasn't taken over the embedded market. You're just another marketeer for the company ActiveState. People need to understand what this article is written for, to advertise. Corporate has been, 20 years experience at the age of 55+, that means you're a retread who never had any interest in computing/engineering until your, let me guess, "marketing degree" wasn't worth anything anymore. It was the sudden vogue thing to get into, right? Shill.

For crying out loud, there is no such language as "C/C++".
There is C, and there is C++.
One of them has progressed a great amount in the last couple of years, and sometimes feels quite close to Python:
http://preshing.com/20141202/cpp-has-become-more-pythonic/

Besides, has no sense the use of C/C++ to increase the speed of Python. At the end you are using C/C++

@Tom Radcliffe;

Yeah, no. Take it from a HUGE Python fan who spent part of his career in embedded development: Python will never be the sole language used on any embedded system. Space constraints, true real time response requirements, high performance will keep that from occurring.

However, I could see it being used to develop code quickly, then see large parts of it replaced by C, C++, and/or assembler modules. After all, this is Python's primary use in a lot of application development scenarios. It makes for extremely fast prototyping to quickly get functions working.

Once performance analysis is complete, developers can concentrate on the areas where the code is running too slow. This approach is generally more efficient than attempting to guess ahead of time where code might contribute to performance issues. However, this still assumes that there is enough on board storage available to get Python loaded. Not all devices will allow for that.

To those engineers doing embedded development today who don't believe that Python has any place in your toolkit, I can only say you had better take a long look around. You're not doing yourself or your employer any favors if you ignore all the exciting work being done to miniaturize full blown computers. Your options for device types has exploded over the past five years or so. Keep an open mind when you survey the market.

If there is one truism that you should always keep in mind in this business, it is that fundamental principles don't change, but technology changes every day. If you don't stay on top of the technology, you will be replaced by someone who is.

I agree 100%, my target was C++ but I started prototyping in python because doing it in C++ was such pain in the ass.
But then, if you are really proficient in C++, there is no reason why deployment should be in python. It's as in college, we took notes quickly, dirty, unindexed, scratches, notes on the side... then the recomendation is to take your time to copy it to a cleaner and indexed document, to lower as possible the cognitive workload and give you a better performance edge at studying it.

In reply to by sgtrock (not verified)

Have you tried ROOT - https://root.cern.ch/ - it a sort of interpreted C++.
If I wasn't trying to teach people coding I'd re-write Zim in ROOT and use that for documenting the C++ code that falls out of it at the moment. For now I am happy to teach Python and hope they learn enough to switch to C++ rather than using the python interface to it that is almost ubiquitous these days!

In reply to by Guillem

My previous project has the constraint of 128 KB code/data storage and 32 KB RAM. Let me know when Python can fit in that environment!

The micro:bit uses micropython - 16Kram and 256K Flash memory. I'd still use C++ (or probably machine code for larger production runs) in anger but you can teach lot in micropython and you have to learn a lot to use C++ properly - but then you have to learn the same stuff to use programming properly.

In reply to by Yongwei Wu (not verified)

I'm afraid your argument on the readability of python doesn't hold water, readability is primarily (though not entirely) a function of developer skill. As you point out, many in the python community are hobbyists and non-computer scientists, and frankly it shows. I have had to find/fix bugs or create work-arounds for a number of problems with open-source projects written in python, and have found many cases where there was little or no documentation in the code, in one instance a 1200 line module had not a single comment in it. Whenever people declare a language to be more readable, newer programmers start thinking they don't need to document anything, making code in that language on average less readable than other more mature languages. Of the roughly 60 languages I have worked with over the years, Ada was probably the most readable, however, this was most likely due primarily to the skill level of people who used the language at the time. While it is true that different languages make it easier or harder to write readable code, good programmers write good, readable code in any language, bad programmers write bad, hard to read code in any language.

FWIW.

Twenty years ago you would have been correct. Today you can write perfectly acceptable python code on a RaspberryPi Zero that will perform miracles and do the job. I'd rather they had chosen ROOT but there is enough momentum behind python (and micro-python) as a learning-coding tool not to ignore it. Once you've learned the basics of coding then changing to another language is remarkably easy and a great learning experience in itself. There is too much bigotry about computer languages around and that causes more problems than any of the languages do - its important to remember that whatever you code in is really only AND,OR and NOT in the end.

In reply to by Guillem

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.