At inovex, I am widely known for my strong opinion about the Raspberry Pi. I had lots of discussions about the idea of using (standard) Raspberry Pi’s for professional embedded products.
Thus, I initially wanted to write a rant, which I can refer to during the next discussion. But when thinking about what is the issue with Raspberry Pi for professional use and products, I came up with a lot of general things to consider when deciding for a hardware platform for IoT or embedded devices.
Of course, I do not hate Raspberry Pis in general. As most (embedded) developers, I have a bunch of them of my own, and yes, they are great—for tinkering, learning, general use at home, and sometimes even for prototyping. But if it comes to more professional industrial IoT or embedded software development, they have some major weaknesses to consider and are a great example of what should be actively evaluated before deciding for a platform. In this blogpost, I want to discuss some of these weaknesses of the Raspberry Pi. Some are specific to this platform, but you should ask the same questions about each other one before making the decision to use it as a base for your product.
Hardware side
The baseline: standard Raspberry Pis
When it comes to discussions about using Raspberry Pis in professional environments, it is mostly about the usual customer-targeted ones. But they are not necessarily designed with a rougher industrial surrounding and product requirements in mind, which leads to some weaknesses and issues to consider:
Consumer design and long-term availability
Common Raspberry Pis (not the compute modules!) are consumer-targeted devices for tinkering and learning. New hardware versions are released frequently in contrast to other, rather industrial-targeted embedded platforms. This is great if you wait for a better model with more RAM, e.g. to run your home media server on it, but it may lead to issues in professional development. The hardware design and the related software, in the embedded environment mostly called board support package (BSP), is not as rock-solid as it would be needed.
For example, the first revision of Raspberry Pi 4 had a buggy implementation of the USB-C standard. Thus, some chargers were detected as audio devices and as a result, the Raspberry Pis did not boot with certain chargers connected to them. This seems like an easy to solve issue, but you need some time to find the root cause, find a fix and ensure the USB-C issue does not affect you in other cases, too. And of course, the USB-C standard is a mess of itself, but such bugs are a no-go when using the board embedded in industrial products.Assuming you selected a Raspberry Pi version, validated the board design for your use case (and it is ok for you not having things like onboard ADCs, EEPROMs or Flash storage), checked for hard- and software issued on the specific revision, and in the end, no one assures you it is available for the next x years in exactly this configuration. The Raspberry Pi Foundation is a charity with the goal to get people into computer science and programming but not to distribute industrial boards for the lifespan of a third-party product.
And when thinking about lifetime, you should ensure that the device is still supported for the time you want to ship your product after you finished development. Developing a product may take approximately 2 years and, for example, the Raspberry Pi 3 B+ was introduced in February 2016 (and not well-tested and bullet-proof at this time) while its guaranteed production lifetime will end January 2023. That is not a long time and it is still not guaranteed there are certain numbers of them available when needed.
SD Cards
The weakest point on usual consumer Raspberry Pis is the SD card. This does not apply though if you tinkered around to make them able to boot off NVME SSDs (but remember the impact on your product’s size when using a SSD instead of SD cards or eMMC) or when using the compute module with proper memory on board or on the break-out. But when you must to stick to SD cards for cost reasons or just because it is less effort, you should think about the following things:
- general reliability (of the card itself, but at the same time of the mechanical contact between card and Raspberry Pi),
- the write cycles of your application and the used operating system,
- what you want to do when the card fails out in the field and
- tamper protection.
Even the better SD cards have a limited lifetime. The more write cycles you have on the card, the earlier it will fail. In the best case, the card fails completely and the device just does not boot anymore, but faulty sectors may result in strange behavior which could last several days and impact whatever the device is used for. You could try to reduce write cycles on the card to max out the lifetime, but that is not really a valid guarantee to get the resulting product working rock-solid with a certain availability over years.
Besides, unplanned power loss during write operations is one of the most important reasons why SD cards fail or get corrupted. This means the power supply should be backed with some kind of additional energy storage and logic to guarantee a proper shutdown in any situation without data loss.
When you decide to use the SD card, nevertheless, think about the options (and costs) to fix the devices in the field. It may sound easy to just change SD cards, but this does not work out at scale and leads directly to the next possible pitfall: tamper protection and security issues: Having the SD card accessible, so it can easily be replaced when it fails, but seals or similar will rather not protect the firmware on the device from getting modified. This may affect the general safety of your resulting product, e.g., if it drives potentially dangerous machines.
And if the application on the device is your actual product, your intellectual property, it is almost too easy to get it from an unprotected SD card and analyze it. Remember that even epoxy resin can be removed and extracting a SD card from a resin block needs less knowledge than dumping information from an on-board flash chip. On the other hand, resin or seals may protect the device from getting tampered with. If the attacker does not remove the resin completely and add a new one, it should probably be visible to users that the device was modified.
Before going further, I want to give a short comment on lifetime of memory. Of course, the lifespan of SSD, eMMC, EEPROM and memory technologies in general is limited, too. An extensive number of write operations is never completely unproblematic for each kind of memory. Thus, there are for example specific lines for server grade hard drives. And yes, it is right, the most common alternative for SD cards on embedded devices, an eMMC, is technically the same thing. Nevertheless, an eMMC is usually assumed to be more reliable and robust against physical corruption.
If you want to get deeper into embedded memory, I would recommend reading The Fundamentals of Embedded Memory by Jacob Beningo, which gives a good introduction into the technologies and their pros and cons.
Stability of Power Supply
The common, customer targeting Raspberry Pis are using a Micro-USB or lately a USB-C type connector for power supply. These are rather fragile from a mechanical point of view, but that is not the only issue.
Depending on the parameters of the actually used charger, connected devices like sensors and general utilization of the processor, the power supply may become unstable and the voltage level drops. This often leads to strange behavior, for example on buses like I²C. Logical signals must be between well-defined voltage ranges to be interpreted correctly. If the general power supply of the board drops, the higher level for a logical “1“ is not met in some cases and the connected hardware shows unexpected behavior or becomes even damaged while the software part seems to be and actually is correct. As above, a crappy power supply is not an exclusive issue of the Raspberry Pi. You should ensure that the used device is sufficient for your requirements in any case. Depending on your use case, it may be needed to develop a more sophisticated power management which is able to survive short fluctuations and allows a safe shutdown in case of an outage.
Features and environment
Carefully evaluating the product’s requirements vs. the feature set of a hardware platform should be self-evident, but for some reasons, this is often not the case when thinking about the Raspberry Pi. Yes, the Pi is cheap (on a first look), rather powerful and well-known but holding these points above other professional criteria has the potential to become expensive in the long run.
At first, you should ask yourself if the Pi truly fulfills the needs for your product or if you just wish it would because you are used to it. For professional use, you mostly need a real-time clock (RTC) which is externally backed by a battery and able to keep the time even if the device is powered off. This is for example needed to trigger events, like turning the device back on after a deep sleep period or just to avoid issues due to a wrong system time, e.g., to verify HTTPS certificates. The Raspberry Pi does not come with a real-time clock on board which means, if you need one, an additional component is needed.
And when thinking about certificates – a trusted platform module (TPM) should nowadays be a must for most applications. TPMs are (mostly) dedicated chips that enhance devices with additional security features. They offer, for example, a safe world for cryptographic keys. Key (and according certificates like X509 used for SSL) can be created directly within the TPM and must not leave it to be used which is a great advantage in security. If you are interested in the full feature set of TPMs, have a look at the TCG’s TPM 2.0 – A Brief Introduction.
Besides, the Pi lacks of the following, usually rather essential, components for an embedded computing platform:
- real-time clock (RTC)
- trusted platform module (TPM)
- USB header connectors
- flash storage and/or eMMC
- EEPROM and/or FRAM
- power over ethernet (PoE) support (available with a additional HAT at RPi 3 and 4)
- analog/digital converters (ADCs),
and only offers a limited set of the following
- UART (only one available on the header)
- GPIOs (many of them double occupied, e.g., with I2C, UART, SPI)
- bus systems and protocols (only offers UART, I2C, SPI, ethernet, USB, no on-board support for industrial protocols like CAN, Profibus)
Of course, you can add the missing components externally, but this causes additional cost and effort, enlarges the hardware footprint and occupies some of the already limited interfaces like I2C and SPI. At the same time, an industrial/commercial product does, depending on the application, not necessarily need some features of the Raspberry Pi like HDMI (the Raspberry 4 has two of them!) or a composite video port. These features are great in case you want to use the Pi as a cheap computer for education. From the point of building an embedded or an IoT product, these are a rather unneeded hardware footprint which consumes power and space that would be better filled with some of the above named, missing components.
An often minor point in this game are environmental conditions like temperature. Devices are usually manufactured to meet some defined temperature ranges, which may vary depending on specification, manufacturer or application. Some common and accepted are:
Commercial: 0˚C – 70˚C
Industrial: -40˚C – 85˚C
Military: -55˚C – 125˚C
Automotive: -40˚C – 125˚C
The standard Raspberry Pi is specified to work within 0°C and 50°C, which means it does not even meet the commercial range according to this list. Leaving this range may lead to increasing failure rates or a complete failure of the device. Besides the external temperature, you should also be aware of the on-device temperature. If you are running a CPU-intensive application, it is probably needed to take care for proper cooling to avoid overheating of the CPU. Otherwise, the CPU will probably thermal throttle itself to prevent damage. This must be avoided if you are running a time-sensitive application. A colder temperature is mostly not that critical for the Pi itself, but be aware of increasing issues if you do not meet the specifications and remember battery capacity drops when operating below a certain limit.
Raspberry Pi Compute Module
If you nevertheless decided to use a Raspberry Pi for some reason, the more professional and actual valid way to build a commercial product on this base is using the Compute Modules (CM) version.
The idea behind it is simple and not specific to Raspberry Pi. The essential but complex parts of a platform design, means the integration of the SoC, RAM, PMIC and depending on the design, memory and connectivity, is done only once and bundled into a very small board with nothing but a more or less standardized connector on it. This is referred to as System on a Module (SoM). Everything else needed, depending on the target application respectively the target product is done on a so-called base or extension board. This allows manufacturers to develop and produce custom hardware designs faster and cheaper.
For Raspberry Pi Compute Modules, this means the CM contains only the actual SoC with RAM, PMIC and depending on the selected version eMMC and/or connectivity modules. Everything else the SoC actually offers is led out via the connector and can be implemented on the base board. The CM itself cannot be used standalone. It is not equipped with a power supply connector or a programming interface. But this allows you to design a base board that matches exactly the needs of your application as long as the SoC supports the hardware interfaces and buses you want to implement.
The main plus point of the CM is the eMMC directly available instead of using SD cards – if you select the appropriate variant. If not, you can add eMMC or a M.2 interface to the baseboard. Even in case you do not want or cannot do your own baseboard design, the compute module and one of the commercially available designs match your needs better than a common Raspberry Pi, but without some of the pain points explained above. Besides the Raspberry Pi Foundation’s IO Board, e.g., Waveshare offers different baseboards that may suit your requirements.
But I do not want to discuss these products in detail. Compute modules and matching commercial base boards may or may not solve the issues of the common Raspberry Pis depending on your requirements. To match them without compromises, it is necessary to do your own baseboard design. In this case, the Raspberry Pi is a very valid hardware option – if you considered and solved the issues discussed above for your product’s needs. Of course, doing an own board design causes more costs than just using the standard Pi, but it avoids unplanned costs during development caused by trying to hot-fix issues from the hardware or dealing with SD card failures in the wild.
At last, there are some points to keep in mind when planning to go with Raspberry Pi compute modules: Currently, CM4 is almost not available by nearly any supplier. This is probably due to the global chip shortage, but it is not predictable when this situation will change. CM 3 and CM 4 are equipped with different, incompatible connectors. It is not possible to use a CM 4 on a CM 3 targeting baseboard without changing it. If this connector stays for the next revision is not guaranteed, while the assured lifespan of CM 4 is only 8 years – which is rather short for developing a commercial product (as already mentioned before).
And what about “Industrial Pis“ ?
Raspberry Pis promoted as “Industrial Raspberry Pi“ or industrial-grade Raspberry Pi are a true rabbit hole. It is not defined what you get if you buy one of the many options. The range goes from rather unserious “start-ups“ selling basically standard Pis to actually very valid and properly engineered products. But the key application of a bigger share of these “Industrial Pis“ is not building industrial products at a large scale based on them. It is rather enhancing existing single production facilities and similar to make them smart and ready for industrial internet of things (IIoT) applications. If you found an option that is well suited to fulfill this job and deals well with the already discussed weaknesses of Raspberry Pis, even then it might not necessarily be suitable to build a custom product on this base. Form factors, features, high costs and a different focus make them unattractive to do so. But they are still very interesting because at least the better ones show the additional engineering needed to adopt a Pi to the requirements of their target application.
Software Side
Usually, Raspberry Pi is used with its own Linux-based operating system called Raspberry Pi OS (previously known as Raspbian). This is great if you want to tinker around, use the Pi as an educational tool and for smaller hobby projects – and maybe even when you want to make your existing factory “smart“. But in case of developing a firmware for an embedded product, using any kind of desktop targeting Linux distributions will cause some serious problems as it is no longer a limited number of devices to manage but some hundreds to thousands. I will discuss some of these issues here, but as before these points are not only valid for Raspberry Pi OS but for each kind of desktop distribution as a base for embedded products.
Basing your firmware on a desktop Linux distribution is not reproducible
In case you want more from your base distribution than running a base system to start your single application, it is necessary to make changes in the system. This could be simple things like removing applications and dependencies but also more complex ones like adding additional drivers or configuring systemd. Doing these things manually in your base system image and creating a modified one from this is often referred to as building a “Golden Image“. As a result, you have one golden instance to replicate for all other devices. But if your image (and backups) get corrupted, there is no way to reconstruct exactly the state you had before. It is nearly impossible to download exactly the same base image as you had before. Even if it is still available, there were probably security patches on top that may change the behavior of your application. And of course, it is a lot of ungrateful work to start from scratch again – even if you have some documentation on what you changed lying around.
Instead, you want to have reproducibility – for each version you have released, control about what to ship with your image and in which version.
Desktop distributions do not provide deterministic update and a roll-back mechanism – you cannot update all devices at once
Linux distributions do updates on application level – in the Linux world referred to as packages. This point is perfectly fine in case you use Linux (or Windows or Mac, it is the same for all of them) each day on your personal device as a user. But if you change your perspective to a product manufacturer, it becomes worse. What happens to your product and its software if parts of them are updated to different times and versions? Can you ensure that everything still works fine, and be able to fix issues without having access to the device anymore?
Most package-based distributions provide updates and security fixes on nearly a daily basis. This would force you to test all combinations of packages and your application constantly – what is barely doable in itself, but what would happen if a combination or a package is broken and affects the functionality of your product? If you do not disable the internet connection and updates in general (which is mostly unrealistic for the use case), you would need a way to deal with it.
Much better would be deterministic updates on a (well-tested) image base and an integrated roll-back mechanism. The image-based approach allows you to control versions and test all components of your firmware in interaction while the roll-back mechanism ensures the device is never trapped in a bad state in case your image had an issue nevertheless, or the update was corrupted during download.
Licenses and support
If you ship a product with any software, you should care about licenses. It is an annoying but necessary topic to avoid legal issues. Linux distributions are mostly open-source, but this does not mean you do not need to take care of them. Some software may be open to use but, for example, only in non-commercial or non-military environments. As far as I know, this does not target Raspberry Pi OS in general, but you should keep track of used licenses and remember, even these ones are not completely unproblematic as some parts of the software is only allowed together with a Raspberry Pi device (https://github.com/raspberrypi/firmware/blob/master/boot/LICENCE.broadcom) .
The Raspberry Pi OS has no official commercial support. If you are basing your firmware on it and run into problems there is no single institution to help you. If you instead encounter a security issue, the team behind Raspberry Pi OS will be probably interested to fix it mainline, so it is absolutely worth reporting it. But there is no guarantee they see the same urgency in it as you do and fix it in a defined time.
Instead, what is the solution?
Taking the key points from above:
- reproducible and controllable images without overhead
- and an image base update mechanism with roll-back functionality that works at scale
leads to my recommendation for creating a Linux-based firmware for your embedded product: Embedded Build Systems. These systems allow you to create exactly the Linux image needed for your product in a reproducible way. Together with a proper image-based update tool do they provide a reasonable alternative to the issues of package based standard distributions – without any overhead.
The most common choices for an embedded build system are:
- The Yocto Project
- and buildroot
Both of them are suitable to create your custom embedded Linux distribution but they do not provide the update mechanism. This is, for example, provided by projects like
- Mender.io
- RAUC
- or SWUpdate
which integrate all with Yocto as well as with buildroot and implement image based, A/B updates and roll-backs.
Which of the mentioned options is to be picked is a matter of requirements and personal preference. If you want to read more about embedded build systems and why they should be prefered over package-based distributions consider reading What I want from an Embedded Build System from my co-worker Stefan.
Raspberry Pi in Professional Products: what now?
Is there a generally recommendable alternative to Raspberry Pi?
Short answer: No.
There is no cheap, reliable platform that always fits your requirements. But considering the topics discussed above are a nice guideline to follow when evaluating different boards. And if you have considered all the things from this article carefully, even the Raspberry Pi may be a valid option.
TL;DR
Raspberry Pis are great devices for tinkering and learning but not necessarily for using it as a base for a commercial embedded or IoT product. In case you plan to do it nevertheless, consider:
- using the compute module instead of standard Pis,
- if the Pi actually fits your needs or if another board would be more suitable instead,
- if the guaranteed lifetime of the model matches the desired lifespan of your product (remember the time it takes to develop the product and how long you want to sell it),
- the general availability in needed quantities,
- technology of on-device storage,
- and how to deal with SD card failures if using standard Pis or compute modules without eMMC,
- how to realize a sufficient power supply,
- if the device specification meet your environment requirements,
- using an embedded build system with an image-based update and roll-back mechanism over a standard package based distribution.
Obviously, this text was written with the Raspberry Pi in mind, but most points are generally valid. Keeping them in mind when deciding for a hard- and software base is a great starting point to build better, maintainable and secure embedded products. This list should give you some hints to remember for your decision.
