Embedded computing has been around for as long as computers have existed, but prior to the IoT (Internet of Things) revolution, it remained something of a black-art: a field of computing only available for electrical engineers and highly specialized developers. But with the release of the Raspberry PI back in 2012, embedded went mainstream under the moniker "IoT" – and the market has just exploded.
If there is a benefit with consumerism, it's that cost and attainability is optimized. A decade ago a true embedded board (read: mini computer) would cost at least $200. This is also why the PI became so popular, because it completely turned the pricing on its head and offered a small but capable computer for as little as $35. Obviously there is a limit to what a PI can do, but as the PI foundation has advanced through iterations of their product, it has become increasingly more powerful and capable.
As of writing, the PI foundation has released version 4 of their IoT board, which is nothing short of a quantum leap in power and functionality: sporting 4 gigabytes of RAM (the high-end model, costing around $79) and a Quad core Cortex-A72 (ARM v8) 64-bit SoC clocked at 1.5GHz. Add a SATA storage device and that spec is well into the mid-range laptop region, in terms of computing power.
Alternative Boards
While the Raspberry PI is by far the most known IoT board, its success has spawned and fostered an avalanche of competitors hoping to get a piece of the proverbial pie. This brings some interesting challenges to developers who want to leverage cheap, off the shelves hardware to create new products. A computer is only as good as its drivers (to make a point). You can have the most technically capable device on the planet, but if the drivers are lacking or the software is too esoteric, you won't be able to use it to its full potential.
With so many SBC's (single board computers) available, which can I use out of the box with Elements? I figured this is a worthwhile endeavor, so I went out and ordered a few models. Here is the list of boards I have tested so far:
- Raspberry PI 4b
- ODroid N2
- ODroid XU4
- NanoPI Fire
- Atomic PI [x86]
- UP board [x86]
I should underline that Elements doesn't require anything special to work, there are no elaborate files to ship for example. You can target both 32-bit and 64-bit ARM devices, providing the Linux distribution you are using is based on Debian. If you prefer Android, that's even easier. So the boards I have in the list above were picked solely on the merits that they were easy to obtain in Norway.
Elements for IoT
Being able to target IoT devices is important, because while you might not have any interest in creating your own devices, chances are your customers would want to leverage the financial savings such mini computers represent. A local medical company actually replaced their expensive x86 boards with ARM boards recently, saving roughly $300 per unit. When you consider they sell thousands of these devices to doctors and hospitals every year, the financial benefits of supporting ARM devices, both small and large, suddenly becomes tangible.
Thankfully you have some options with Elements. Not just in terms of physical platforms that you can target, but also in terms of operating systems. Some developers prefer Android, and with the exception of a few rare ARM based IOT boards, Android is supported by pretty much all of them. But truth be told, Linux is the de-facto operating system on these devices, and with Elements you can target both 32- and 64-bit Linux, provided it's based on Debian.
There is also WebAssembly to consider, because you can in fact run WebAssembly based services under node.js, which is a prospect I find very exciting since it's 100% hardware agnostic. Being able to physically copy a service from Windows to macOS on a $45 IoT device without recompiling a line of code is pretty cool.
GPIO and Linux
Before we go over the boards I want to take a minute to mention GPIO. GPIO (general purpose IO) are those pins that most IoT boards expose. Developers typically use these pins to connect their own circuitry, expansion boards – or perhaps something simple as LED lights. The point of these pins is that you can turn the power on/off from your code, and thus write programs that can affect things in the physical world.
Take something simple, like a garage door opener. Whenever you use your remote from your car, the signal from the remote fires an event in the kernel; an event that your code can subscribe to and act on. Your code can then turn on the power that drives a step-motor, thus opening or closing the garage door.
The way Linux deals with things like GPIO is that the kernel exposes a set of proxy files (fake files, if you will). Each pin can be read and written to via the ordinary filesystem. The reason I mention this is because it's one of the principal differences between how Windows and Linux approach things. Like many others I am quite new to the world of Linux, and I was positively surprised when I realized the beauty of that design.
It also means that you don't need highly specialized libraries that cost a fortune to get started with IoT either. Linux as a platform doesn't box you into a typical C/C++ reality where other languages plays second fiddle. If open-source has a silver lining, it's that there is no financially motivated organization seeking to force you into their habits. You can use whatever language you want. That's pretty cool.
With that factoid out of the way, let's have a look at some of the boards, starting with the x86 offerings.
x86 IoT boards
I don't think I need to write much about x86_64 boards. In our case I first tested the Atomic PI, a Kickstarter project exclusive to the US. A friend of mine had one shipped over to Norway for me and I was positively surprised by the value for money the board represents. It sports an Intel Atom x5-Z8350, a quad-core SoC that was initially designed for Windows tablets. This is a three-year-old chip clocked at 1.44 GHz (you can overclock it to 1.92 GHz, if you add active cooling). The board also ships with 2 GB RAM as standard.
The second board is another project originating with Kickstarter, namely the UP board. This is powered by the same Intel Atom™ x5-z8350 processor as the Atomic PI. You can pick between 1, 2 and 4 gigabytes of RAM.
Both of these boards can run either Linux or Windows, and both are more or less ordinary PC class computers in a small, affordable form-factor. Since Elements has supported Windows and Linux for x86 since the beginning, there really is not much to say about these boards. If you prefer x86 then either of these offer great value for your money. My personal favorite is the UP board since it has the same form-factor as the Raspberry PI (give or take a passive heat-sink), but both models have their merits.
The ODroid N2, 64-bit ARM
While the Raspberry PI is by far the most known and popular ARM device, the ODroid line of SBC's (single board computers) from Korean company Hardkernel has gained a loyal following. Their biggest seller is without a doubt the ODroid XU4, which is a 32-bit IoT device that was created as a direct competitor to the Raspberry PI 3b (covered later in this article). Needless to say, when Hardkernel announced their new N2 model and listed some of its specs, I was all ears.
The ODroid N2 is a 64-bit ARM system powered by the Amlogic S922X. This SoC is known as "Little-Big" since it consists of four Cortex-A73 @ 1.8GHz CPUs, and an additional two Cortex-A53 @ 1.9GHz (hexa-core). The N2 comes with either 2 or 4 gigabytes of RAM (I picked the 4 gigabyte version). It also ships with four USB 3.0 sockets, which is a definitive bonus, as well as a BlueTooth and IR receiver on-board. This means you can hook up a SATA disk and enjoy fast disk IO, and buy a cheap remote control – no USB dongle required.
As you can read from these specs, the N2 is definitively a powerful board, one that can take on the Raspberry PI v4 when it comes to brute force.
Having said that, there are some issues that you should be aware of. Just like the ODroid XU4, the N2 uses a Mali GPU, which in my personal experience can be a red flag. In 2018 I tested roughly 15 IOT boards, where five of these were fitted with a Mali GPU. All five boards were sadly haunted by graphical glitches and instability issues. The only SBC that I have tested and used in a production environment that ran well on a Mali GPU is the ODroid XU4.
Another note is that Mali has completely dropped all support for the aging X desktop system. You can download a minimal disk-image which gives X ordinary 2D hardware acceleration, but the full might of OpenGL is not supported by the vendor.
I contacted the developers at Hardkernel about this, and they informed me that Mali has moved its focus towards Wayland, the new Linux desktop system. So Hardkernel is busy implementing drivers for that and has promised to issue new disk-images shortly.
Verdict: While the lack of full OpenGL support for X was disappointing, I have to admit that the N2 is one of my favorite SBCs. It is stable, extremely powerful, delivers twice as many GPIO pins as the Raspberry PI and doesn't need active cooling. If you add a SATA SSD drive to the mix, you will be hard pressed to notice the difference between a full PC and the N2. It is fiendishly clever and powerful.
Suitable applications:
- Web servers for home or small businesses
- Network active storage devices
- Media center (Kodi) with full HD support
- Gaming and emulation
- Advanced automation systems [due to its large GPIO array]
ODroid XU4, 32-bit ARM
As mentioned before, the ODroid XU4 was created as a direct alternative to the Raspberry PI 3b. Like its successor, it sports a big-little CPU architecture and uses the Exynos 5422 octa-core, with four ARM Cortex-A15 @ 2.0 GHz combined with four Cortex-A7 CPUs.
You can target this board from Elements by selecting the ArmV6 architecture in project settings. Like the N2, the XU4 has a Mali GPU, but unlike all the other boards I have tested with said GPU brand, the XU4 is rock solid. So if you are looking for an SBC that is faster than the Raspberry PI 3b yet costs the same, the ODroid XU4 is a safe bet. I actually use five of these in a cluster for one of my IoT projects, and they have never failed me.
The board also ships with active cooling, which is a bonus. But I should warn that if you overclock the CPU, you must get a case with active ventilation, because the on-board fan is not enough for overclocking. In my case I run Node.js services as fast as the cores can carry it, and without a proper case and ventilation you hit the 70ºC mark faster than you think – at which point the SoC shuts down to avoid melting.
Verdict: The XU4 is by far my favorite SBC. I have used it in three IOT projects without any problem, no matter how CPU or graphically intensive the application may be - the XU4 does a brilliant job.
Suitable applications:
- Works well in a cluster configuration
- Alarm systems and automation
- Kiosk systems
- Surveillance and security
- POS and cash machines
- Retro gaming and emulation
The NanoPI Fire 3, 32-bit ARM
The NanoPI is a small but extremely powerful SBC. It is a shame that FriendlyElec only gave this board 1 Gigabyte of RAM, because the computational power and raw force of this board is through the roof. It's powered by the Samsung's Cortex-A53 Octa Core S5P6818 @ 1.4 GHz SoC and ships with 1GB DDR3 RAM.
Having said that, this board is not as easy to use as the ODroid or Raspberry PI models out there. The target audience is C/C++ developers using QT, with Android development thrown in at the last minute. There are no drivers openly available to give you a hardware accelerated X desktop (much like the ODroid N2), so unless you have specific use-cases involving Android, I would look elsewhere.
I only ran a standard command-line test program for this board, which ran just fine. Impressive stats indeed, but somewhat muffled by the lack of GPU drivers for X.
Verdict: a very powerful board, easy to target from Elements via the Armv6 architecture. But to be painfully honest, I would not invest in this board unless you are using "Android of things" (a custom version of Android designed to only run one application in kiosk mode).
Suitable applications:
- Android based Kiosk systems
- Alarm systems
- HTML5 based information booths
The Raspberry PI v4, 64-bit ARM
I saved this board for last since I knew my love for this device would show. I must admit that the release of the PI v4 came as a complete surprise for me, roughly a week after Hardkernel presented their ODroid N2 model. There is no point trying to pretend that the PI is not the de-facto maker-board in the market. It's available, it's affordable, it's polished, the software is stable and optimized. The Raspberry PI has been and continues to be the trendsetter for IoT computing - and the V4 is no exception.
The first thing you will notice with the Raspberry PI v4, is that the PI foundation has ramped up the CPU capacity by magnitudes of 10. It's based on the Broadcom BCM2711 SoC (system on a chip) fitted with a 64-bit Quad core Cortex-A72 (ARM v8 @ 1.5GHz. And unlike its predecessor, the v4 is open for overclocking to 2GHz with active cooling. You can choose between 1, 2 and 4 Gigabytes of RAM. Needless to say, I bought the 4Gb model. We are talking serious firepower here, way beyond the average tablet and closer to a mid-range laptop.
Part of the PI's success is its choice of GPU, and the v4 continues with the same brand that made its earlier models successful. It uses the Broadcom video core VI which provides everything from hardware based video decoding, upsampling, scaling – and much much more. The PI v4 has full support for OpenGL on X too, something that puts it ahead of the ODroid N2 (in my humble opinion).
The board comes with built-in support for WiFi (both 2.4 GHz and 5.0 GHz IEEE 802.11ac) and Bluetooth 5.0 LE, so communicating with the IoT device (e.g adding a remote control) is straightforward and painless – you don't even need a USB dongle any more, it's all built-in and ready to go.
One caveat though is that Pixel, the desktop distribution that ships with the board, is 32-bit only. As such I downloaded an Ubuntu build from the PI's user-forums that was compiled for 64-bit, and my command-line test ran without any issues whatsoever. I would presume that the same is true for 32-bit binaries, but I did not take the time to test that.
Verdict: what can I say? It's incredibly fast, it has enough RAM for a dedicated swapfile and memory mapping; it has WiFi and Bluetooth out of the box, uses USB C and the GPU is supported by both Wayland and X. It has USB 2.0 and 3.0 sockets, and most surprising - it ships with 2 x HDMI out for dual monitor support!
With USB 3.0 you can easily connect a SATA based SSD disk, and the result is what can only be classified as a functional desktop computer, capable of the exact same tasks as a mid-range laptop.
While subjective, that is the difference in experience between Raspberry PI v3 and v4, namely that the v4 represents more than just garage-door openers and automation electronics. On earlier versions of the PI, things like compiling code would exhaust the CPU; you really couldn't use the PI v2 and v3 for anything but dedicated tasks. The v4 however is powerful enough for doing builds directly on the device without having to wait hours for the result. Not that I'm advocating a PI over a high-end Mac or Windows box, naturally.
Reflections
Being able to target popular, off the shelf devices like the Raspberry PI and the ODroid XU4 is a wonderful thing. As a software developer the concept of building products that you can physically interact with, or that can serve a particular function in a business scenario (like a POS system, kiosk system or cash machine) is quite exciting. Most of the work we developers do are in the realm of code and ideas, and being able to bridge into the physical world of devices opens up a whole new reality of possibilities.
There is also another aspect that I find extremely important in all this, namely that of WebAssembly. Since runtime platforms like node.js now supports running WebAssembly modules, this means that it's now technically possible to implement your system services in a format that is universal. The beauty of runtime environment like node.js is that your code will behave identical regardless of OS or hardware. This material is rich with both technical and financial opportunities for those that take the leap to investigate. And if nothing else, it should force us to re-evaluate how we build service stacks in 2020 and beyond.
