In the roughly decade and a half since the Android mobile operating system appeared on the scene it has been primarily sold on devices with an ARM core at their heart, but along the way it has also appeared for other architectures. If you had a MIPS Android phone you may have been in the minority, but Intel phones enjoyed some popularity, and the up-and-coming new kid in the world of Android is RISC-V. For anyone interested in this last architecture it’s worth looking at the Google Open Source blog, in which they’ve published an overview of the current status of the project.
In short, it’s full steam ahead — as the development environment and emulation is in place for RISC-V Android. It’s certain we’ll start seeing RISC-V phones on the market soon, but perhaps that’s not the part which should interest readers the most. Over the last decade we have seen an explosion of inexpensive ARM single board computers, and though some of them such as the Raspberry Pi owe their heritage to set-top-box SoCs, it’s fair to say that a strong driver for this trend has been the proliferation of powerful mobile chips. A take-up of RISC-V driven by Android would mean a similar explosion of powerful SoCs with those cores, leading we hope to much more accessible and powerful RISC-V computing. Sadly we expect them to still come with proprietary peripherals leading to plenty of closed source blobs, but we can’t have everything.
While there have been hiccups here and there, the general trend of electronics is to decrease in cost or increase in performance. This can be seen in fairly obvious ways like more powerful and affordable computers but it also often means that more powerful software can be used in other devices without needing expensive hardware to support it. [Manawyrm] and [Toble_Miner] found this was true of a particular inexpensive thermal camera that ships with Linux installed on it, and found that this platform was nearly perfect for tinkering with and adding plenty of other features to turn it into a much more capable tool.
The duo have been working on a SC240N variant of the InfiRay C200 infrared camera, which ships with a Hisilicon SoC. The display is capable of displaying 25 frames per second, making this platform an excellent candidate for modifying. A few ports were added to the device, including USB and MicroSD, and which also allows the internal serial port to be accessed easily. From there the device can be equipped with the uboot bootloader in order to run essentially anything that could be found on any other Linux machine such as supporting a webcam interface (and including a port of DOOM, of course). The duo doesn’t stop at software modifications though. They also equipped the camera with a lens, attached magnetically, which changes the camera’s focal length to give it improved imaging capabilities at closer ranges.
While the internal machinations of this device are interesting, it actually turns out to be a fairly capable infrared camera on its own as well. The hardware and software requirements for these devices certainly don’t need a full Linux environment to work, and while we have seen thermal cameras that easily fit in a pocket that are based on nothing any more powerful than an ESP32, it does tend to simplify the development process dramatically to include Linux and a little more processing power if you can.
If you want to hook up an existing stereo or amplifier to Spotify, there’s a fair few options on the market. You can even just order a Raspberry Pi and be done with it. [Evan Hailey] went his own way, however, and built his own Spotify Box from scratch.
Housed inside a tidy little wooden enclosure of his own creation, the Spotify Box can turn any amplifier into a remote-controlled Spotify player via Spotify Connect. Pick the songs on your smartphone, and they’ll play from the Spotify Box as simple as that.
The project is based on the Allwinner V3S, a system-on-chip with a 1.2GHz ARM-Cortex-A7 core, 64MB of DDR2 RAM, and an Ethernet transceiver for good measure. There’s also a high-quality audio codec built in, making it perfect for this application. It’s thrown onto a four-layer PCB of [Evan’s] own design, and paired with a Wi-Fi and BlueTooth transceiver, RJ-45 and RCA jacks, a push-button and some LEDs. There’s also an SD card for storage.
With a custom Linux install brewed up using Buildroot, [Evan] was able to get a barebones system running Spotifyd while communicating with the network. With that done, it was as simple as hooking up the Spotify Box to an amp and grooving out to some tunes.
Along the way, [Evan] learned all about compiling drivers and working with embedded Linux, as well as how to take a bare SoC and build it into a fully-functional single-board computer. When someone else says they “made” a Spotify player, he presumably gets to clear his throat.
While ARM continues to make inroads into the personal computing market against traditional chip makers like Intel and AMD, it’s not a perfect architecture and does have some disadvantages. While it’s a great step on the road to software and hardware freedom, it’s not completely free as it requires a license to build. There is one completely open-source and free architecture though, known as RISC-V, and its design and philosophy allow anyone to build and experiment with it, like this build which implements a RISC-V processor in VHDL.
Since the processor is built in VHDL, a language which allows the design and simulation of integrated circuits, it is possible to download the code for the processor and then program it into virtually any FPGA. The processor itself, called NEORV32, is designed as a system-on-chip complete with GPIO capabilities and of course the full RISC-V processor implementation. The project’s creator, [Stephan], also struggled when first learning about RISC-V so he went to great lengths to make sure that this project is fully documented, easy to set up, and that it would work out-of-the-box.
Of course, since it’s completely open-source and requires no pesky licensing agreements like an ARM platform might, it is capable of being easily modified or augmented in any way that one might need. All of the code and documentation is available on the project’s GitHub page. This is the real benefit of fully open-source hardware (or software) which we can all get behind, even if there are still limited options available for RISC-V personal computers for the time being.
How does this compare to VexRISC or PicoSOC? We don’t know yet, but we’re always psyched to have choices.
We are extraordinarily fortunate to live at a time in which hardware with astounding capabilities can be had for only a few dollars. Systems that would once have taken an expensive pile of chips and discretes along with months of development time to assemble are now integrated onto commodity silicon. Whether it is a Linux-capable system-on-chip or a microcontroller, such peripherals as WiFi, GPUs, Bluetooth, or USB stacks now come as part of the chip, just another software library rather than a ton of extra hardware.
Beware The Blob!
If there is a price to be paid for this convenience, it comes in the form of the blob. A piece of pre-compiled binary software that does the hard work of talking to the hardware and which presents a unified API to the software. Whether you’re talking to the ESP32 WiFi through an Arduino library or booting a Raspberry Pi with a Linux distribution, while your code may be available or even maybe open source, the blob it relies upon to work is closed source and proprietary. This presents a challenge not only to Software Libre enthusiasts in search of a truly open source computer, but also to the rest of us because we are left reliant upon the willingness of the hardware manufacturer to update and patch their blobs.
An open-source advocate would say that the solution is easy, the manufacturers should simply make their blobs open-source. And it’s true, were all blobs open-source then the Software Libre crowd would be happy and their open-source nature would ease the generation of those updates and patches. So why don’t manufacturers release their blobs as open-source? In some cases that may well be due to a closed-source mindset of never releasing anything to the world to protect company intellectual property, but to leave it at that is not a full answer. To fully understand why that is the case it’s worth looking at how our multifunctional chips are made.
If you’ve ever wanted to try your hand at creating a Raspberry Pi-like board for yourself, you should check out [Jay Carlson’s] review of 10 different Linux-capable SoCs. Back in the 1960s, a computer was multiple refrigerator-sized boxes with thousands of interconnections and building one from scratch was only a dream for most people. Then ICs came and put all the most important parts in a little relatively inexpensive IC package and homebrew computing became much more accessible. Systems on Chip (SoC) has carried that even further, making it easier than ever to create entire systems, like the Pi and its many competitors.
Only a few years ago, making an SoC was still a big project because the vendors often didn’t want to release documentation to the public. In addition, most of the parts use ball grid array (BGA) packaging. BGA parts can be hard to work with, and require a multilayer PC board. Sure, you can’t plug these into a typical solderless breadboard. But working with these relatively large BGAs isn’t that hard and multilayer boards are now comparatively cheap. [Jay] reports that he got cheap PCBs and used a hot plate to build each board, and has some sage advice on how to do it.
Monty Python once did a sketch where people tried to summarize Proust in fifteen seconds. Although summarizing eight FPGA-based CPUs is almost as daunting, [jaeblog] does a nice job of giving a quick sketch of how the CPUs work with the Xilinx Vivado toolchain and the Digilent Arty board.
The eight CPUs are: VexRiscv, LEON3, PicoRV32, Neo430, ZPU, Microwatt, S1 Core, and Swerv EH1.
The comparison criteria were very practical: A C compiler (gcc or llvm) for each CPU and no CPUs that were tied to a particular FPGA. Two of the CPUs didn’t fit on the Arty board, so their comparisons are a bit more theoretical. There were other considerations such as speed, documentation, debugging support, and others.
It was interesting to see the various CPUs ranging from some very mature processors to some new kids on the block, and while the evaluations were somewhat subjective, they seemed fair and representative of the things you’d look for yourself. You can also get the test code if you want to try things for yourself.
The winner? The post identifies three CPUs that were probably the top choices, although none were just perfect. Of course, your experience may vary.
If you want an easy introduction to adding things to a soft CPU, this RISC-V project is approachable. Or if you prefer SPARC, check out this project.