Bring your Raspberry Pi to work

Bring your Raspberry Pi to work

The Raspberry Pi is a single board computer designed for home and educational use. It has approximately the computing power of a low end laptop and typically runs Linux. Unlike a laptop or mini PC it has plenty of microcontroller-style digital I/O, enabling automation and embedded computing applications. This allows the Raspberry Pi to bridge the gap between a desktop computer and a microcontroller, yielding many of the advantages of each.

We recently used the Raspberry Pi as the basis of an Industrial IoT proof of concept. This was a monitoring system feeding data from many and varied sensors to a database server in the cloud. Some of the sensing techniques were experimental and previously untried for this particular use case. The customer needed a proof of concept for demonstration and testing. There was a list of requirements, but these were not detailed, nor prioritised up front. It was vital to produce a working system by the end of a twelve week deadline. At this point the system would be shipped to a pre-arranged field trial which would determine the future of the project.

The system design ultimately envisaged an integrated microcontroller/cellular data module as the CPU but the mainboard PCB could alternatively mount a Raspberry Pi in this role. The overriding objective was to take the fastest and lowest risk route to a functioning proof of concept. With this in mind, we opted to use the Raspberry Pi and were glad that we did. The ability to jump straight into application development was crucial, as was the visibility provided by the Pi’s excellent networking, logging and debugging capabilities.

Batteries Included

Compared to embedded development environments, a Linux system such as Raspberry Pi comes with a wealth of facilities installed or instantly available with just 'apt-get' or 'git clone' command. There is a huge difference in expectations for code reuse between the embedded and non-embedded world. Non-embedded programmers expect to work almost entirely on application-specific code and turn to frameworks, libraries, database engines, middleware, etc. to provide the rest. Embedded programmers often find themselves programming against the “bare metal”, using the hardware reference manual and peripheral datasheets as their guide. Why does this happen? A variety of factors contribute, including; low-specification devices; non-standardised hardware; and a closed engineering culture.

In a general-purpose computer, computing power is valued as the headline specification of the product. Conversely, embedded microcontrollers are seen as a cost to be minimised. This cost minimisation can be rational for mass market devices where the marginal cost of higher-spec components soon adds up to real money; this concern pervades the embedded computing culture. Often high price / low unit count products are designed with irrationally cheap hardware for savings that will not recover the increased development costs. Due to the pervasive sense of computational scarcity, embedded software engineers are wary of the overheads involved in programming against reusable abstractions¹.

Relatedly, the lack of hardware standards is a particular problem. General purpose computing exists in a highly standardised hardware environment programming against well-defined Operating System interfaces. Embedded programmers usually work with custom hardware and idiosyncratic microcontrollers. Where libraries exist, they are often too ‘thin’ and wrapper-like to be useful; it is still necessary to know the underlying hardware interface.

The embedded software business is culturally more like that of electronics than application software. Confidentiality, patents and trade secrets are the default. Transparency and open source distribution are less common. Anecdotally, it seems like a disproportionate number of GPL licence violations are in firmware. There are excellent embedded open source projects (such as FreeRTOS) but overall the commons is much smaller.

Hopefully the standard set by other computing fields will encourage the embedded programming world to adopt code reuse practices to a greater degree. There are signs this is already happening with tools such as ST Microcontroller’s STM32Cube code generation framework².

Another huge advantage of the Raspberry Pi development environment over a bare metal microcontroller is that of visibility, by which we mean the ability to inspect the operation of the system for monitoring, verification and debugging. On a Raspberry Pi there is a full command line terminal accessible over the network (or even a GUI if you want); plenty of RAM and storage for logging; debugging tools; a memory management unit³ etc. In every aspect there are spare resources to assist the programmer.

By comparison, the visibility features of an embedded environment are patchy and irregular. You might have JTAG for debugging. You might have a free I/O channel to create a debug console (that you will likely have to write yourself). You might have a little spare memory to create an event log. You might be able to pass error codes to a host system with better visibility. You might, in the worst case, be able to flash an LED Morse-code style to indicate the cause of a crash. It will not be easy.

For rapid (and thereby cheap) prototyping the Raspberry Pi is a clear winner.

Raspberry Pi in Production?

Could you go a step further and use the Raspberry Pi in a shipping product? While we have not done this, others apparently have. Although publicised examples are rare, we can see evidence of professional use of the Raspberry Pi in the support and hardware available. For commercial or industrial applications there are compatible versions of the Raspberry Pi platform such as the Compute Module and the Hilscher netPI. These substitute the oft criticised micro SD storage with on-board flash, among other improvements. Entirely customised boards are available through an official partner of the Raspberry Pi Foundation. Even the regular consumer boards have obsolescence statements promising availability to a given date.

Obviously, the Raspberry Pi is not for safety-critical applications or those that require especially high reliability. However, in comparison to regular single board computers, there is no reason to suppose that the Raspberry Pi is of lesser quality. Just as the reputation of the Linux operating system has grown from “just a hobby” to a first class option for serious applications, so too can the perception of the Raspberry Pi.

Addendum on the Raspberry Pi 4

The Raspberry Pi 4 has been released with significant improvements to RAM and I/O. Obviously, this increases the space of potential applications. I have used this model as a basic Linux desktop machine and found it quite usable for tasks such as running web and office applications, Linux development and remote desktop access. Two disadvantages of the new design are the lack of an industrial Compute Module version and the increased need for active cooling to enable the full computing power of the device.

Footnotes

¹ This is also a reason why embedded programming is still dominated by low overhead languages such as C, C++ and assembler.