Bringing The PIO To The FPGA

We’ve seen some pretty incredible hacks using the Raspberry Pi 2040. However, one of the most exciting bits of hardware onboard is the Programmable I/O (PIO). Not content with it just being a part of RP2040-based projects, [Lawrie Griffiths] has been porting the PIO to Verilog so anyone can enjoy it.

This particular implementation is based only on the spec that Raspberry Pi provides. For assembling PIO code, [Lawrie] uses Adafruit’s pioasm assembler they use for their MicroPython framework. There’s a simulator to test different programs, and the project targets the Blackice MX and the Ulx3s. A few example programs are included in the repo, such as outputting a pleasant guitar note over I2S and driving a chain of WS2812s.

The project is still incomplete but slowly making progress. It’s an incredible feat of reverse engineering. While the simulator can be used to debug programs, step through instructions, and inspect waveforms, the ultimate value of bringing the PIO to other systems is that now we can re-use the code. Things like the can2040, an implementation of the CAN bus protocol using the PIO. Or even a PIO-based USB host.

Watch A Web Page Fetch Itself Over TLS, Complete With Commentary

TLS, byte by byte performs an unusual and interesting function: it fetches itself over HTTPS, and provides a complete annotation of what’s going on in the process, one byte at a time. Visit the site and give the button a click to watch it happen, it’s neat!

Transport Layer Security (TLS) is what’s responsible for encrypting traffic over the internet, and it’s normally implemented on top of TCP to encrypt an application-layer protocol like HTTP (resulting in HTTPS and the little padlock icon in browsers indicating a connection with a web site is encrypted.) Back in the day, traffic over the internet was commonly unencrypted, but nowadays no communication or hardware is too humble for encryption and methods are easily accessible.

So for what purpose would someone actually need or use such an implementation of TLS? Well, probably no one actually needs it. But it is a userspace TLS implementation in javascript that may fit a niche for someone, and it certainly provides beautifully-indented and annotated binary data in the process. Sound up your alley? The GitHub repository for the project has all the details, so give it a look.

This Week In Security: .zip Domains, Zip Scanning

The world may not be ready, but the .zip Top Level Domain (TLD) is here. It’s a part of the generic TLD category, which was expanded to allow applications for custom TLDs. Google has led the charge, applying for 101 such new TLDs, with .zip being one of the interesting ones. Public registration for .zip domains has been open for a couple weeks, and some interesting domains have been registered, like update.zip, installer.zip, and officeupdate.zip.

The obvious question to ask is whether this new TLD can be abused for scamming and phishing purposes. And the answer is yes, sure it can. One of the trickiest ways is to use the AT symbol @ in a URL, which denotes user info at the beginning of the URL. It usually is used to include a username and password, like http://username:password@192.168.1.1/. That is pretty obvious, but what about https://google.com@bing.com? Still looks weird. The catch that really prevents this technique being abused is that slashes are disallowed in user data, so a abusive URL like https://google.com∕gmail∕inbox@bing.com is right out.

Except, take a look at that last link. Looks like it has slashes in it, so it should take you to google, and ignore the AT symbol. But it doesn’t, it goes to Bing. You may have guessed, it’s Unicode shenanigans again. Those aren’t slashes, they’re U2215, the division slash. And that means that a .zip TLD could be really sneaky, if the apparent domain is one you trust. Continue reading “This Week In Security: .zip Domains, Zip Scanning”

Go In All The Directions With Omniwheeled ESP32 Bot

The ability to change direction without turning is the specialty of omnidirectional wheels, which [maker.moekoe] used to their full potential on a pair of ESP32-controlled robots. Video after the break.

Thanks to the rollers on the wheels, the wheels could be arranged at 120° in relation to each other on the 3-wheeler and 90° 4-wheeler. [maker.moekoe] used ChatGPT and a simple python simulation to find and verify the motor control algorithm required for smooth omnidirectional driving.

A single custom PCB incorporates all the electronics, and doubles as the robot’s chassis, with the geared brushed motors bolted directly to it. An ESP32-S2 runs the show, and can also stream FPV video from the same OV2640 camera used on the popular ESP32-cam modules. The LiPo battery is held by a 3D-printed support plate screws to the bottom of the PCB. The robots can controlled by a simple web-app served by the ESP32, or a using the IMU on custom controller also built around an ESP32-S2 which uses the ESP-NOW wireless protocol.

Even though the robots’ software is still in the early stages, the movement looks extremely smooth and effortless. Plus, their all-in-one PCB chassis makes for an elegant and clean build

Continue reading “Go In All The Directions With Omniwheeled ESP32 Bot”

MIDI Interface For NeXTcube Plugs Into The Past

[Joren] recently did some work as part of an electronic music heritage project, and restored an 80s-era NeXTcube workstation complete with vintage sound card, setting it up with a copy of MAX, a graphical music programming environment. But there was one piece missing: MIDI. [Joren] didn’t let that stop him, and successfully created hardware to allow MIDI input and output.

The new panel provides all the connectors necessary to interface with either classic MIDI devices, or MIDI over USB (where it appears as a USB MIDI device to any modern OS.)

Interestingly, the soundcard for the NeXTcube has an RS-422 serial port and some 8-pin mini DIN connectors. They are not compatible with standard MIDI signals, but they’re not far off, either.

To solve this, [Joren] used a Teensy developer board to act as an interface between classic MIDI devices like keyboards or synthesizers (or even not-so-common ones like this strange instrument) while also being able to accommodate modern MIDI over USB connections thanks to the Teensy’s USB MIDI functionality.

A metal enclosure with a 3D-printed panel rounds out the device, restoring a critical piece of functionality to the electronic music-oriented workstation.

MIDI as a protocol isn’t technically limited to musical applications, though that’s one place it shines. And just in case it comes in handy someday, you can send MIDI over I2C if you really need to.

DIY Programmable Guitar Pedal Rocks The Studio & Stage

Ever wondered how to approach making your own digital guitar effects pedal? [Steven Hazel] and a friend have done exactly that, using an Adafruit Feather M4 Express board and a Teensy Audio Adapter board together to create a DIY programmable digital unit that looks ready to drop into an enclosure and get put right to work in the studio or on the stage.

The bulk of the work is done with two parts, and can be prototyped easily on a breadboard.

[Steven] also made a custom PCB to mount everything, including all the right connectors, but the device can be up and running with not much more than the two main parts and a breadboard.

On the inside, the Adafruit Feather M4 Express board works with the audio board over I2S, a standard for sending serial digital audio between chips. Working with the audio itself is done with the Teensy Audio Library, providing a fantastic array of easy-to-use functions for processing and manipulating digital audio streams.

Together, all the right pieces are in place and [Steven] provides the code for a simple tremolo effect as a glimpse of what’s possible with the unit. Interested in going a bit further? [Steven] shares additional details about what’s involved in writing a custom effect from scratch using the Teensy Audio Library.

As mentioned, I2S is where it’s at when it comes to working with digital audio at the chip level, and our own Jenny List can tell you everything you need to know about I2S, a useful protocol that has actually been around since 1982!

A DR-DOS console showing the IDLE command

Missing DR-DOS Power Management Source Code Found In Patent

Modern processors come with all kinds of power management features, which you don’t typically notice as a user until you start a heavy program and hear the CPU fan spin up. Back in the early 1990s however, power management was largely unheard of, meaning that a CPU with nothing to do would run through an idle loop that dissipated about as much power as a real computing task. [Michal Necasek] noticed this while experimenting with DR-DOS 6.0 in a virtual machine – his laptop fan would start running on full blast whenever he opened the VM. His search for a solution to this annoyance led him down a fascinating journey into the intricacies of DOS power management.

As it turned out, DR-DOS 6.0 does have functionality built in for putting the CPU in power saving mode when it’s idle. This feature is not complete, however: Digital Research required each computer manufacturer to develop an IDLE driver customized to their specific hardware platform in order to enable power management. Sadly, no manufacturer ever bothered to do so, leaving [Michal] with no option other than writing a driver himself. While there was some documentation available, it didn’t include any example code or sufficient detail to write a driver from scratch.

A snippet of x86 assembly code found in a patentWhat it did include was a reference to U.S. Patent No. 5,355,501. Normally this sort of information is of interest only to those planning to sell a competing system, but this specific patent happens to include dozens of pages of well-documented but poorly-scanned x86 assembly code, including source code for a basic IDLE86.SYS driver. As [Michal] wasn’t looking forward to chasing bugs caused by OCR errors, he simply copied the source code by hand, then ran it through an assembler. The end result was a working IDLE driver, which is now available for download from his website.

[Michal]’s blog post also includes lots of details on early power saving implementations, including all the DOS interrupt calls involved in the process. Patents might seem boring in contrast, but they sometimes contain surprising amounts of usable information. You might find enough details to reverse-engineer a wireless protocol, or even to help track down an obscure instrument’s original designer.