14 ms·

Python vs. C/C++ in embedded systems

• kbumsik 10y ago
  in embedded systems? If he is talking about using Python in microcontrollers, he does not know what is embedded system.
  • r_smart 10y ago
    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.
    • gtaylor 10y ago
      Python does have bit shifting, for what it's worth.
      • r_smart 10y ago
        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. Either way, thanks for the correction.
        • knicholes 10y ago
          >>> 1 << 4 16
        • chocolatebunny 10y ago
          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?
          • r_smart 10y ago
            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 :)
    • stinos 10y ago
      it's written just micropython without the dash and is actually quite close to having all python3 syntax implemented https://github.com/micropython/micropython/ https://github.com/micropython/micropython/
      • r_smart 10y ago
        Thanks for the link. Cool to see that they're making progress getting it going on ARM.
  • rdtsc 10y ago
    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.
    • fumplethumb 10y ago
      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.
      • dom0 10y ago
        There's a whole industry built around embedded Linux. Just FYI.
    • GFK_of_xmaspast 10y ago
      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."
      • AnimalMuppet 10y ago
        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.
    • RobertDeNiro 10y ago
      Depends who you're talking to I guess. I wouldn't call that an embedded system, although it could technically be described as such.
    • Matthias247 10y ago
      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.
• nibnib 10y ago
  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.
• fumplethumb 10y ago
  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.
  • shandor 10y ago
    Another problem is power consumption. 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.
  • rch 10y ago
    What do you think about MicroPython?
    • dbcurtis 10y ago
      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.
• new_hackers 10y ago
  I think 'Python vs C ...' and 'Python vs C++ ...' are different questions. Much like 'C vs C++ in embedded systems' is its own topic.
• minipci1321 10y ago
  > 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.
• TYPE_FASTER 10y ago
  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 10y ago
    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.
    • alfalfasprout 10y ago
      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.
      • c0rtex 10y ago
        What static analyzers do you use for your embedded C++ work?
    • samfisher83 10y ago
      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?
    • JoachimSchipper 10y ago
• geis 10y ago
  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.
• w_t_payne 10y ago
  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.
• Jtsummers 10y ago
  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.
• out_of_protocol 10y ago
  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 10y ago
    > In first case python is fine... I think you meant second case (RPi), just switched up your wording.