The TKey is a RISC-V-based security key that plugs into a USB port. The device has a number of features, including a device-specific serial number, RAM scrambling, and a monitor that kills the CPU in the event of access to protected memory. There is also an FPGA that, on the end-user version, is locked down. This prevents you from changing the core features and the unique ID number for the device.
As part of the start-up code, the device calculates a hash of the application and merges it with the device ID and, potentially, a user-defined secret. If this number matches a previous calculation, it is reasonably certain that nothing has changed between the times of the calculations.
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!
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.
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)
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)
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.
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.
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.
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.
