FPGA guru [Max Maxfield] recently took a look at the XLR8 (pronounced accelerate) board from a company called Alorium. On the surface, it looks like another Arduino UNO clone. But instead of a CPU, it contains an Intel MAX10 FPGA that runs a softcore AVR processor. Of course, that’s only part of the story. If the board was just a mock Arduino using an FPGA, that’s not very interesting for practical purposes. However, by incorporating accelerator blocks or XBs, you can add FPGA modules to the soft CPU. [Max] shows an example that you can see in the video below where an FPGA block controls servos more easily than a standard Arduino. There’s also a version that looks like an Arduino Nano, but can clock much faster as well as use the XBs.
In addition to prebuilt XBs, there is a workflow to build your own if you are familiar with working with FPGAs. The products aren’t exactly new, but we enjoyed [Max’s] take on the product. We also appreciated the simple code examples showing exactly how you would convert a program to use the accelerated functions. Continue reading “Arduino And FPGA Done Differently”
We are big fans of POV displays, particularly ones that move into 3D. To do so, they need to move even faster than their 2D cousins. [danfoisy] built a volumetric display that doesn’t move LEDs or any other digital display through space, or project light onto a moving surface. All that moves here is a bead of styrofoam and does so at up to 1 meter per second. Having low mass certainly helps when trying to hit the brakes, but we’re getting ahead of ourselves.
[danfoisy] and son built an acoustic levitator kit from [PhysicsGirl] which inspired the youngster’s science fair project on sound. See the video by [PhysicsGirl] for an explanation of levitation in a standing wave. [danfoisy] happened upon a paper in the Journal Nature about a volumetric display that expanded this one-dimensional standing wave into three dimensions. The paper described using a phased array of ultrasonic transducers, each with a 40 kHz waveform.
After reading the paper and determining how to recreate the experiment, [danfoisy] built a 2D simulation and then another in 3D to validate the approach. We are impressed with the level of physics and programming on display, and that the same code carried through to the build.
[danfoisy] didn’t stop with the simulations, designing and building control boards for each
100 x 100 10 x 10 grid of transducers. Each grid is driven by 2 Intel Cyclone FPGAs and all are fed 3D shapes by a Raspberry Pi Zero W. The volume of the display is 100 mm x 100 mm x 145mm and the positioning of the foam ball is accurate down to .01 mm though currently there is considerable distortion in the positioning.
Check out the video after the break to see the process of simulating, designing, and testing the display. There are a number of tips along the way, including how to test for the polarity of the transducers and the use of a Python script to place the grids of transducers and drivers in KiCad.
Continue reading “Surf’s Up, A Styrofoam Ball Rides The Waves To Create A Volumetric Display”
Spec sheets are an important tool in determining the performance of a given part or system, but they’re not the be all and end all when it comes to engineering. However, specs alone don’t prove whether a given system can complete a given task. Sometimes, you need to actually do the work to prove it instead – as [Sylvain] has done, running DOOM on the iCE40 FPGA.
DOOM’s minimum specifications demand a 386 with 4MB RAM minimum, but it’s commonly agreed that a 486 DX2 running at 66MHz with 8MB of RAM is required to play the game smoothly. With an iCEBreaker v1.0b running a RISC V softcore at 25MHz, it may seem like a difficult task, but the RISC V core has the benefit that many instructions run in a single clock cycle that take many on the 486. While the iCEBreaker doesn’t have much RAM onboard, it’s a simple job to piggyback an 8MB SPI device on top of the existing flash storage. Control of the game is via keystrokes sent to the iCEBreaker over serial, while video is handled over a PMOD video interface with an HDMI connector.
[Sylvain] does a great job of explaining all the minute details of the work that was required to get things working, and has provided files on Github for those keen to replicate the feat or expand upon the code. Music is notably absent but MIDI output could likely be achieved without much hassle. “Does it run DOOM?” is still a question asked of many platforms, even the new Nintendo Game & Watch. Video after the break.
Continue reading “Ice40 Runs DOOM”
It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more peace of mind than holding your coins in a soft or web wallet.
But of course, as we know, nothing is totally secure.
And we were reminded of this fact by Kraken Security Labs, when they showed us how they bypassed all of the safeguards in a popular wallet, the Trezor, to dump and decrypt it’s seed.
It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.
The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.
Continue reading “Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor”
PCI Express (PCIe) has been around since 2003, and in that time it has managed to become the primary data interconnect for not only expansion cards, but also high-speed external devices. What also makes PCIe interesting is that it replaces the widespread use of parallel buses with serial links. Instead of having a bus with a common medium (traces) to which multiple devices connect, PCIe uses a root complex that directly connects to PCIe end points.
This is similar to how Ethernet originally used a bus configuration, with a common backbone (coax cable), but modern Ethernet (starting in the 90s) moved to a point-to-point configuration, assisted by switches to allow for dynamic switching between which points (devices) are connected. PCIe also offers the ability to add switches which allows more than one PCIe end point (a device or part of a device) to share a PCIe link (called a ‘lane’).
This change from a parallel bus to serial links simplifies the topology a lot compared to ISA or PCI where communication time had to be shared with other PCI devices on the bus and only half-duplex operation was possible. The ability to bundle multiple lanes to provide less or more bandwidth to specific ports or devices has meant that there was no need for a specialized graphics card slot, using e.g. an x16 PCIe slot with 16 lanes. It does however mean we’re using serial links that run at many GHz and must be implemented as differential pairs to protect signal integrity.
This all may seem a bit beyond the means of the average hobbyist, but there are still ways to have fun with PCIe hacking even if they do not involve breadboarding 7400-logic chips and debugging with a 100 MHz budget oscilloscope, like with ISA buses.
Continue reading “The Bus That’s Not A Bus: The Joys Of Hacking PCI Express”
With so many smaller and more capable microcontroller boards on the market it’s now fairly safe to say that the classic Arduino footprint and form factor is rather outdated. That’s not to say that there’s no fight left in the old contender though, and to prove it here’s a new platform in the familiar style set by the venerable Atmel-based board. [Eduardo Corpeño]’s Brainfuino is an Arduino competitor that runs everyone’s favourite esoteric programming language, Brainf*ck. (Keeping it SFW, folks.)
And in case you mistake it for a Brainf*ck emulator on a PCB then stand ready to be corrected, for this board runs the language natively in a Brainf*ck softcore on a Lattice MachXO2 FPGA. This is the real deal, on which only a true genius or masochist would dare to code.
The board itself is very neatly executed with a graphical style that presents more than a nod to the original Arduino. On this board is the FPGA, 256 kB ROM and 138 kB RAM, an STM32 to provide a USB serial port and an analogue input, and a level shifter to provide Arduino-style 5 V logic on the pins. We can see it’ll provide hours of fun to anyone interested in learning Brainf*ck, but besides that it has potential as an Arduino-shaped FPGA board. We like the joke, we like the graphical and engineering design, but underneath that lies quite the technical achievement.
Brainf*ck has made it to Hackaday before, not least in this jaw-dropping relay computer.
For as many of them as we’ve seen, we still love a good persistence of vision display project. There’s something fascinating about the combination of movement and light creating the illusion of solid surfaces, and there’s always fun to be had in electromechanical aspects of a POV build. This high-resolution spherical POV display pushes all those buttons, and more.
Called “Flicker” for obvious reasons by its creator [Dan Foisy], this POV display started with a pretty clear set of goals in terms of resolution and image quality, plus the need to support animated images, all in a spherical form factor. These goals dictated the final form of the display — a PCB disc spinning vertically. The shaft has the usual slip rings for power distribution and encoders for position feedback. The PCB, though, is where the interesting stuff is.
[Dan] chose to use an FPGA to slice and dice the images, which are fed from a Raspberry Pi’s HDMI port, to the LED drivers. And the LEDs themselves are pretty slick — he found parts with 1.6 mm lead spacing, making them a perfect fit for mounting on the rim of the PCB rather than on either side. A KiCAD script automated the process of laying out the 256 LEDs and their supporting components as evenly as possible, to avoid imbalance issues.
The video below shows Flicker in action — there are a few problem pixels, but on the whole, the display is pretty stunning. We’ve seen a few other spherical POV displays before, but none that look as good as this one does.
Continue reading “Edge-Mounted LEDs Make This Spherical POV Look Fantastic”