Once upon a time, if you wanted to generate some waveforms, you needed to buy an expensive off-the-shelf function generator or whip up a big pile of analog electronics. Not so today, when you can grab a fast microcontroller off the shelf and have it squirt out whatever fancy waves you might desire. That’s just what [rgco] did to build this nifty arbitrary wave generator.
The build improves on prior work by [rgco] with the Arduino Uno, with which they built a device that could output at 381 kilosamples per second, with each sample update taking 42 instruction cycles. Thanks to the Pi Pico’s faster clock speed and certain performance optimizations, they were able to up that to a mighty 125 megasamples per second, using the DMA and PIO subsystems to output a new sample every single clock cycle.
The result is a cheap function generator you can build with a Pi Pico and a handful of resistors, which will probably cost you the grand total of $12. It readily outperforms, at least in regards of speed, devices based on the AD9833 function generator chip, which only runs at 25 megasamples. Plus, that chip can only output sines, triangles, and squares!
Even a passable function generator can be a useful tool to have in the workshop, as we’ve seen before. Video after the break.
Continue reading “Arbitrary Wave Generator For The Raspberry Pi Pico”
There are reports that some Nintendo Wii U systems out in the wild are falling victim to mysterious failures. As is so often the case, certain error codes have been found in common across failed units out in the community, and [Voultar] decided to investigate to see if he could fix this problem with a little hacking.
[Voultar] wasn’t able to source a Wii U with the much-discussed NAND failure mode, but he was able to source a number of supposedly bricked Wii U systems displaying the error codes 160-0101 and 160-0103. The hack is achieved with an exploit in the Wii U’s USB Host Stack descriptor parsing module, developed by [GaryOderNichts]. It allows the injection of a payload that lets one run unsigned code on the Wii U, achieved via a Raspberry Pi Pico. The Pico is ultimately used to boot off an SD card running a recovery program for the Wii U. By resetting the Wii U’s “coldboot title ID”, it solves the error and gets the console booting properly, as per normal.
[Voultar] was able to fix five consoles displaying the common error messages, which we’d call a win. It’s not going to be a fix for every failed Wii U out there, but if you’ve got the dreaded 160-0101 or -0103 errors, it might be worth a shot.
Continue reading “Resurrecting A Bricked Wii U With A Raspberry Pi Pico”
The folks at Raspberry Pi are riding on a bit of a wave at the moment, with the launch of the Pi 5 with its PCIe and RP1 peripheral chip, the huge success of the RP2040 microcontroller, and the supply chain issues that dogged the Pi 4 and Compute Module 4 during and after the pandemic finally working themselves out. But as always there are plenty of would-be competitors snapping at their heels, so [Jeff Geerling] has posed the question of what it takes to make a Raspberry Pi killer. He’s in a good position to do this, as he’s amassed an impressive collection of every competing Compute Module board.
It’s a well-observed analysis of the world of small Linux SBCs, on hardware, software, community, and price, and we find ourselves pretty much in agreement with it. The Pi hardware has quirks and is rarely the best on paper when compared to the competition, but they win hands-down on distribution support and community. In a sense what you really buy when you get a PI is this, because Raspberry Pi OS will run on it for the reasonable future. Rival makers would do well to read his piece, because we sense that if one of them tried to give the Pi a run for its money away from the hardware it would make for a much better SBC ecosystem. Take a look at his Compute Module comparison below the break.
We recently took a look at the strategic importance of the Pi 5 and in particular the RP1.
Continue reading “What It Takes To Make A Raspberry Pi Killer”
When the Raspberry Pi 5 launched, many were left chomping at the bit after seeing the PCIe FPC connector alongside the promise that an ‘NVMe SSD HAT would be forthcoming’. Although the official Raspberry Pi NVMe HAT is still a long while off, the Polish company Pineberry Pi is ramping up to release its Top & Bottom versions of its very wittily called HatDrive.
They sent a prototype to [Jeff Geerling], who has been putting his grubby mitts all over them before putting together a video showing off the HatDrive Top, which can accept 2230 and 2242 size NVMe drives.
The primary goal of adding an NVMe drive to the RPi is of course to get rid of those slow and fragile SD cards. Although the SD card standard supports near-NVMe-like speeds with UHS-III, the Raspberry Pi 5 bottoms out at UHS-I, around 100 MB/s. Despite this, using an NVMe drive for booting still takes some work, as [Jeff] lays out in a clear article. Most of this involves tweaking the
/boot/config.txt file to enable external PCIe support, editing the onboard EEPROM to change the boot order (in lieu of having a PC-like BIOS screen) and getting the OS image flashed onto the NVMe drive you intend to boot from.
Although things seem to work fine during [Jeff]’s testing, some caveats remain, such as the RPi 5 officially supporting only PCIe Gen 2 x1, with Gen 3 possible, but with potential data integrity issues. There’s also the fundamental limit of having only a single lane of PCIe available. If that’s no problem, then Pineberry Pi offers the aforementioned HatDrive Top for traditional HAT-style mounting, and a Bottom version that can accept up to 2280 format NVMe SSDs. Including the provided ribbon cables, you can order the Top and Bottom for €20 and €25.99 respectively, with the first batch to ship in early December.
Continue reading “Pineberry Pi HatDrive: Using NVMe SSDs With The Raspberry Pi 5”
The Raspberry Pi series of boards are noted for their good software support, with a continuous flow of operating system upgrades such that an original Pi from 2012 will still boot the latest Pi OS. But these upgrades are best done by writing a fresh SD card, so oddly, the Pi remains surprisingly difficult in many cases to upgrade in place. [Iustin Pop] has taken a look at the problem, and finds that though it’s not always easy it remains possible with a bit or work.
An upgrade in place of a Raspberry Pi OS install that’s running on a headless device is probably the simplest of the lot, with a relatively small set of issues. Do it on a machine using the GUI though, and the switch from x.org to Wayland makes for a whole world of pain.
Perhaps most interesting for the insight it gives us into the way Raspberry Pi OS is derived from Debian, is the crossgrade process from the ARMhf build for earlier machines to the ARM64 one for the more recent ones. Here aside from a headache of differing paths and versions, he encounters the Pi-specific compilation tweaks put in place by the developers of Raspberry Pi OS, leading to the ARMhf version being a different branch from the original Debian than the ARM64 one.
Having read his examination of in-place upgrades we have to say that simply writing a new SD card remains the most attractive option. But sometimes along comes a remote system where that’s simply not possible, and this guide might just be very useful sometime.
The Raspberry Pi has come a long way since its humble origins, adding faster processors and better interfaces with each new generation. Now, the Raspberry Pi 5 has a lovely new PCIe port right on board, and [Jeff Geerling] has gone right ahead and slammed in an NVMe SSD as a boot drive.
[Jeff] explains that to use an NVMe to boot, you first have to modify /boot/config.txt to enable PCIe and modify the Raspberry Pi’s boot order. Once the bootloader is appropriately configured, you can boot straight off an SSD with Raspberry Pi OS installed. To get the operating system on to an NVMe drive, he recommends cloning an existing boot volume from a microSD install.
One of the primary reasons you might want to do this is speed. NVMe drives are generally a significant cut above even the best microSD cards, both in speed and reliability. [Jeff] also notes that you can use an NVMe SSD through a PCIe switch on the Pi 5 if you so desire, but you can’t currently boot with this configuration.
It’s a great feature to have on the Pi 5, and it follows on from the earlier implementation on the Raspberry Pi Compute Module 4. Video after the break.
Continue reading “Booting The Raspberry Pi 5 With An NVMe SSD”
Ever since an impromptu build completed during a two-week COVID-19 quarantine back in 2020, [Will Whang] has been steadily improving his Raspberry Pi solar photography setup. It integrates a lot of cool stuff: multiple sensors, high bandwidth storage, and some serious hardware. This is no junk drawer build either, the current version uses a $2000 USD solar telescope (an LS60M with 200mm lens) and a commercial AZ-GTi mount.
He also moved up somewhat with the imaging devices from the Raspberry Pi camera module he started with to two imaging sensors of his own: the OneInchEye and the StarlightEye, both fully open source. These two sensors feed data into the Raspberry Pi 4 Compute Module, which dumps the raw images into storage.
Because solar imaging is all about capturing a larger number of images, and then processing and picking the sharpest ones, you need speed. Far more than writing to an SD Card. So, the solution [Will] came up with was to build a rather complex system that uses a CF Express to NVME adapter that can keep up, but can be quickly swapped out.
Unfortunately, all of this hard work proved to be in vain when the eclipse came, and it was cloudy in [Wills] area. But there is always another interesting solar event around the corner, and it isn’t going anywhere for a few million years. [Will] is already looking at how to upgrade the system again with the new possibilities the Raspberry Pi 5 offers.
Continue reading “Solar Camera Built From Raspberry Pi”