Raspberry PI – not all it seems?

Back in 2011, a new computing platform was announced that dazzled the nation. Astonishment at how a fully functional ‘PC’ could be miniaturised excited Joe Public (though DSL are always keen to point out it had a similar product in 1991!) even the more informed embedded community took a moment to admire the petite purported price.

Designed for education to put the fun back into learning computing, here is a product that could solve one of the biggest questions in our industry “How do we inspire our children to become Engineers?”

Unfortunately with all ‘mass market’ technologies, there are always those keen to push that technology into other areas, some good (Teflon on frying pans!) and some bad (Speed Cameras?) – such innovation has been the cornerstone of mankind’s technological progression, but can also be very dangerous when a technology is driven, without full contemplation, into an area it never claimed to be at home in (hydrogen in airships anyone?!)

The danger allured to here is that of employing the faddish Raspberry PI into a real life embedded or industrial computing application – the lure of the low price tag encouraging imagination of vastly increased profits or supplying at a fraction of a cost of your nearest competitor.

The Raspberry PI has been a technological, but primarily a sociological achievement – though designed to educate on, not integrate into, embedded applications. Developers considering transferring this hardware into unknown territory should carefully consider the following.

Full documentation is not available for developers, nor never will be – heavily under protection from the designers. In contrast to a typical embedded platform, where a plethora of supporting documentation is made instantly available to the developer, guiding them smoothly though their project.

Whilst the ability to play 1080p video via HDMI may instantly create a perception of blistering performance, in reality this is handled off chip and the CPU performance is the equivalent of a creaky 300MHz Pentium 2. This is important as few embedded/industrial applications have a call for much graphical grunt, if they use graphics at all!

Using an SD card to house any kind of Operating System (OS) has its pitfalls, the only option on a Raspberry PI. An SD Card’s maximum read/write speeds are a fraction of typical storage mediums, similarly to total read/write cycles, so little longevity is offered to the developer, who’s used to specifying systems to reside in the field for up to 10 years without servicing.

Interestingly the Raspberry PI supports only RCA or HDMI, their argument that VGA is a dying format does hold some truth in the retail sector (most new LCD displays have HDMI input), though in the embedded sector, if a display is required at all of course, a ruggedized industrial display is unlikely to have HDMI, especially as they tend to be much smaller (down to 5.7”).

The defining ‘feature’ of most embedded single-board-computers (SBCs) is their wide temperature range, allowing their usage in the most extreme environments. Typically you’d expect to see a standard temperature range of -20°c – +70°c, though more often than not the full industrial temperature range of -40°c – +85°c – the Raspberry PI’s components can only offer 0-70°c and if you read the manufacturer’s FAQ they do not qualify the board itself to any extreme.

Other features embedded developers often take for granted including PXE Boot (the ability to boot directly from a server) aren’t supported, nor are high data transfer rates. The on board Ethernet interestingly is derived from the USB 2.0 port, this means that both the Ethernet is restricted to 10/100 and the USB 2.0 cannot operate at full speed, as it is sharing the bandwidth.

One interesting omission that many would struggle with in this sector is the absence of a Real Time Clock (RTC) or Hardware Watchdog. Furthermore if one ponders its implementation for more complex equipment, the absence of any expansion capability beyond USB (which has its own drawbacks for such peripherals) is a cause for concern.

No Windows based OS is supported, though many these days favour other OS’s – the Windows environment offers the ultimate easy development platform and support for alternative OS’s isn’t there yet.

Taking a step back from the product itself momentarily, for a product to be a valid solution in the embedded market, it needs to follow the mantra that DSL themselves hold so highly of continuity of supply.

This takes many forms, including component control/obsolescence management, strict version control on the BIOS (including the ability to create tailored custom BIOS’s), monitoring of future component availability, last time buys and far more than you could ever realise happens behind the scenes in the embedded industry. The combination of all the above providing that confidence that what was purchased yesterday; integrated into a product that entailed huge approval costs will be available in 1, 2 or 5 years, or longer!

To conclude, the Raspberry PI is a fantastic product, innovative and to which we will probably owe a substantial debt for inspiring and educating the next generation of embedded developers to do ever wonderful things with future technologies –but please be careful what else you propose it as a solution for…

From the manufacturers of educational SBCs…

‘We do not encourage the use of the board that we manufacture in commercial products. We are not able to schedule parts and arrange for production for orders that we cannot see. Meeting demand is difficult as a result.

In addition, we will make revisions to the board as we find necessary and we will not continue to make older revisions. This can result in supply and compatibility issues for those using them in a product.’