These days, when most folks think of a computer they imagine a machine with multiple CPUs, several gigabytes of RAM,  and a few terabytes of non-volatile storage for good measure. With such modern expectations, it can be difficult to see something like a microcontroller as little more than a toy. But if said MCU has a keyboard, is hooked up to a display, and lets you run basic productivity and development software, doesn’t that qualify it as a computer? It certainly would have in the 1980s.

With that in mind, [Olimex] has teased the RVPC, which they’re calling the “world lowest cost Open Source Hardware All-in-one educational RISC-V computer” (say that three times fast). The tiny board features the SOIC-8 variant of the CH32V003 and…well, not a whole lot else. You’ve got a handful of passives, a buzzer, an LED, and the connectors for a PS/2 keyboard, a power supply, and a VGA display. The idea is to offer this as a beginner’s soldering kit in the future, so most most of the components are through-hole.

On the software side, the post references things like the ch32v003fun development stack, and the PicoRVD programmer as examples of open source tools that can get your CH32V computer up and running. There’s even a selection of retro-style games out there that would be playable on the platform. But what [Olimex] really has their eye on is a port of VMON, a RISC-V monitor program.

When paired with the 320×200 VGA text mode that they figure the hardware is capable of, you’ve got yourself the makings of an educational tool that would be great for learning assembly and playing around with bare metal programming.

It might not have the timeless style of the Voja4, but at least you can fit it in a normal sized pocket.

Thanks to [PPJ] for the tip.

Last year the introduction of  RISC-V support to the Android-specific, Linux-derived Android Common Kernel (ACK) made it seem that before long Android devices might be using SoCs based around the RISC-V ISA, but it would seem that these hopes are now dashed. As reported by Android Authority, with a series of recently accepted patches this RISC-V support was stripped again from the ACK. While this doesn’t mean that Android cannot be made to work on RISC-V, any company interested would have to do all of the heavy lifting themselves, which might include Qualcomm with their recently announced RISC-V-based smartwatch Snapdragon SoC.

No reason was provided by Google for this change, and the official statement from Google to Android Authority says that Google is not ready to provide a single supported Android Generic Kernel Image (GKI), but that ‘Android will continue to support RISC-V’. This change however, removes RISC-V kernel support from the ACK, and since Google only certifies Android builds which ship with a GKI featuring an ACK, this effectively means that RISC-V is not supported at this point, and likely won’t be for the foreseeable future.

As discussed on Hacker News, a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.