Adding Temperature Sensor Functionality To The CH32V003 MCU

As cheap as the WCH CH32V003 MCU is, its approximately $0.10 price tag looks far less attractive when you need to start adding on external ICs for missing basic features, such as temperature measurement. This is a feature that’s commonly found on even basic STM32 MCUs. Fear not though, as [eeucalyptus] shows, you can improvise a working solution by finding alternative sources that can act as a thermometer.

Plot of the temperature measurement using the improvised CH32V003 -based temperature sensor. (Credit: eeucalyptus)
Plot of the temperature measurement using the improvised CH32V003 -based temperature sensor. (Credit: eeucalyptus)

The CH32V003 is a low-end, 32-bit RISC-V-based MCU by the China-based Nanjing Qinheng Microelectronics, commonly known abbreviated as ‘WCH’, and featured on Hackaday previously. Although it features a single-core, 48 MHz CPU, its selection of peripherals is fairly basic:

So how do you create an internal temperature sensor using just this? [eeucalyptus] figured that all that’s needed is to measure the drift between two internal clocks – such as the LSI and HSI – as temperatures change and use this to calibrate a temperature graph.

Unfortunately, the LSI isn’t readily accessible, even through the Timer peripheral. This left the AWU (automatic wake-up unit) which also uses the LSI as a clock source. By letting it go to sleep and wake up after N LSI cycles, the AWU enabled indirect access to the LSI.

Internal diagram of the CH32V003 MCU. (Credit: WCH)
Internal diagram of the CH32V003 MCU. (Credit: WCH)

After calibrating against room temperature (~22 °C) and ice water (0 °C), a temperature plot was obtained, which could conceivably be somewhat accurate. As [eeucalyptus] warns, this is a kind of calibration that likely differs per MCU, and no attempt to quantify the absolute accuracy of this method has been made yet. Even so, as a crude temperature measurement, it might just be good enough.

BeagleV Catches Fire With The BeagleV-Fire

A new BeagleBoard is on the way, full of FPGA hotness: the BeagleV-Fire has been announced. The new $150 Single-Board Computer (SBC) from the pioneering open source BeagleBoard company is built around a RISC-V chip that has FPGA features built in. The BeagleV-Fire is built around the snappily named Microchip PolarFire MPFS025T FCVG484E, a System on a Chip (SoC) that has five Reduced Instruction Set Coding Version 5 (RISC-V) cores and a big chunk of FPGA fabric built in. That means it combines the speed of RISC-V processors with the flexibility of Field Programmable Gate Arrays (FPGA), a big pile of logic gates that can be reprogrammed.

The new BeagleV-Fire includes a sizeable chunk of FPGA to work with: the core chip includes 23 K logic elements and 68 Math blocks, plus 4 Serializer/Deserializer (SerDer) lanes that can throw about 12.7 Gbps of data into and out of the fabric. On the BeagleV-Fire, the main chip is supported by 16 GB of eMMC and 2 GB of LPDDR4 RAM, plus a micro SD slot for extra storage. Gigabit Ethernet is also included, plus USB-C power and a few serial connections for debugging. There is no WiFi built in, but there is an M.2 Key E connection were you could plug in an a wireless adapter if you need it.

Like most other BeagleBoards, the BeagleV-Fire has two headers with 92 pins, which offer access to pretty much every signal on the board, plus lots of analog to digital stuff that works with add-on boards (BeagleBoard refers to them as capes). Also present is the usual 22-pin CSI connector for attaching cameras and other devices.

Want one? They are available for immediate order on BeagleBoard.org or from the usual suspects. It looks like they are already in stock for next-day delivery. If this all sounds familiar, it’s probably because we’ve been posting about this particular board for awhile now, covering both the announcement and first tests. Continue reading “BeagleV Catches Fire With The BeagleV-Fire”

Android: Coming Soon To A RISC-V Processor Near You

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.

If you’d like to read more about the whole blob situation and RISC-V, we’ve got you covered.

Because You Can: Linux On An Arduino Uno

There are a few “Will it run” tropes when it comes to microcontrollers, one for example is “Will it run Doom?“, while another is “Will it run Linux?”. In one of the lowest spec examples of the last one, [gvl610] has got an up-to-date Linux kernel to boot on a vanilla Arduino Uno. And your eyes didn’t deceive you, that’s a full-fat kernel rather than the cut-down μClinux for microcontrollers.

Those of you who’ve been around a while will probably have guessed how this was done, as the ATmega328 in the Uno has no MMU and is in to way powerful enough for the job. It’s running an emulator, in this case just enough RISC-V to be capable, and as you’d imagine it’s extremely slow. You’ll be waiting many hours for a shell with this machine.

The code is written in pure AVR C, and full instructions for compilation are provided. Storage comes from an SD card, as the ATmega’s meagre 32k is nowhere near enough. If you’re having a bit of deja vu here we wouldn’t blame you, but this one is reputed to be worse than the famous 2012 “Worst PC Ever“, which emulated ARM instead of RISC-V.

Thanks [Electronics Boy] for the tip!

Tiny Linux On A No-MMU RISC-V Microcontroller

In the vast majority of cases, running a Linux-based operating system involves a pretty powerful processor with a lot of memory on hand, and perhaps most importantly, a memory management unit, or MMU. This is a piece of hardware which manages virtual memory, seamlessly giving each process its own memory sandbox in which it shouldn’t be able to rain on its neighbours’ parade. If there’s no MMU all is not lost though, and [Uros Popovic] gives us a complete guide to building the MMU-less μClinux on a RISC-V microcontroller.

The result is something of a Linux-from-scratch for this platform and kernel flavour, but it’s so much more than that aside from its step-by-step explanation. It’s probable that most of us have heard something of μClinux but have little direct knowledge of it, and he leads us through its workings as well as its limitations. As examples, standard ELF binaries aren’t suitable for these systems, and programmers need to use memory-safe techniques.

Whether or not any of you will run with this guide and build a tiny MMU-less Linux system, anything which expands our knowledge on the subject has to be a good thing. it’s not the first time we’ve seen a RISC-V microcontroller turned to this task, with a nifty trick to get round the limitations of a particular architecture.

Linux On A Commodore 64

We are used to seeing Linux running on almost everything, but we were a bit taken aback to see [semu-c64] running Linux on a Commodore 64. But between the checked-out user name and the caveat that: “it runs extremely slowly and it needs a RAM Expansion Unit”, one can already start piecing together what’s happening here.

The machine running Linux is really a RISC-V32. It just so happens that the CPU is virtual, with the C64 pretending it is a bigger machine. The boot-up appears to take hours, so this is in no way practical, even though the comment is that optimization might be able to get a 10X speed up. It would still be about as slow as you can imagine.

To further add a layer of abstraction, the code hasn’t run yet on real Commodore hardware. Instead, it is running on an emulator. The emulator has “warp” mode to run faster than a real machine, and it is still slow. So think about that before you rush out to volunteer to boot this on your real hardware.

Tricks like this fall into the talking dog category. If a dog can talk, it isn’t that you think it will have something important to say. You just marvel that it can do it at all. Still, we get it. We spend a lot of time doing things at least as pointless. But at least it is fun!

Maybe emulate the whole thing in VR? Or maybe write some virtualization code for the C64 so you can emulate a Linux box and a quantum computer simultaneously.

Debian Officially Adds RISC-V Support

As time goes on, more and more computer manufacturers are moving towards the ARM architecture and away from the bloated and outdated x86 instruction set. Apple is the most prominent producer to take this step, but plenty others are using ARM for its flexibility and efficiency. The only problem with ARM is that it’s licensed, so if you want to go even further down the open-source path the RISC-V instruction set is the next logical step. Now at least one mainline Linux distribution will officially support this architecture.

While Debian did have some support for RISC-V before this as a Debian port, which was not officially part of Debian. However, the official support will begin with the release of Debian 13, which is currently in the testing phase and hasn’t seen a stable release yet. To that end, the current state of this official version is extremely limited, being described as “almost empty” but with planned support for an initial 90 packages in the coming days. Most users working on a RISC-V platform will most likely to continue to use their Debian ports version.

It might be a little while before the RISC-V version is as full-featured as the ARM or x86 versions of this Linux distribution, but we are happy to see it move in this direction at all. And don’t think that RISC-V is limited to embedded systems or otherwise limited computing platforms, either. We’ve seen full Linux desktops with RISC-V processors since at least 2019.