Increase Your Blinkenlights With This Silicon Wafer Necklace

Necklaces aren’t often very high-tech, mostly because of the abuse they have to go through being worn. This was obviously a problem that needed solving, so [Matt Venn] decided to change that by making a necklace out of ASICs just in time for Supercon.

Although this isn’t the first time [Matt] made such a necklace, he though his previous one was “too hip-hop” and not enough “15 million dollar Nikon Lithography Stepper”. Obviously, this means designing the whole chain, art included, from scratch with the blinkenlights to match. Together with [Pat Deegan] and [Adam Zeloof], the team created a beautiful technopunk necklace with art on every chain link and of course a real silicon wafer with a RISC-V tapeout from 2022 on it.

With [Adam] doing modeling for the chain links, and [Pat] and [Matt] designing the electronics required for the mandatory blinkenlights, and some last-minute soldering and assembling the project was finished just in time for Supercon, where it fit right in with all the other blinkenlights. It even runs on one of the RISC-V cores from the same tapeout as the central wafer!

Trouble Brewing For RISC-V As Issue Of Technology Transfer Is Questioned

Within the messy world of international politics, a major consideration by governments concerns which types of kn0w-how and technology can be transferred and sold to other nations, with each type facing restrictions depending on how friendly the political relations are with the target country at that point in time. Amidst all of this, there are signs that a so far relatively minor player in the world of CPU instruction set architectures – RISC-V – may become a victim of this, as a bipartisan group of US politicians is petitioning the White House to restrict transfer of know-how (so-called Intellectual Property, or IP) to RISC-V, as this may benefit adversaries like China.

As a US citizen who is involved in the RISC-V ecosystem, [Andrew ‘bunnie’ Huang] feels rather strongly about this, and has written an open letter to the US President, pleading to not restrict the way that US citizens can deal with the Switzerland-based RISC-V organization. This comes as the California-based RISC-V startup SiFive has announced that it’ll lay off 20% of its workforce. Depending on how a restriction on RISC-V is implemented, this could mean that US citizens would be forbidden from contributing to this ISA and surrounding ecosystem.

China has made it clear that RISC-V is a big part of its strategy to loosen its dependence on the West along with its investments in its MIPS-based Loongson processors, all of which strengthens the case for restricting US participation in RISC-V, even if it forces US companies like SiFive to move countries or cease its operations.

(Thanks to [cbjamo] for the tip)

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.