Digital Audio For Microcontrollers Doesn’t Come Much Simpler Than A WART

July 11, 2021 by Jenny List 11 Comments

Adding an audio channel to your microcontroller project can mean a pile of extra components and a ton of processing power, as a compressed stream must be retrieved and sent to a dedicated DAC. Or if you are [rdpoor], it can mean hooking up a low-pass filter to the UART that’s present on even the simplest of devices, and constructing a serial data stream that mimics PWM audio.

Sound on your microcontroller, it’s this simple!

WART is a Python script that converts a WAV file into a C formatted byte array that can be baked into your microcontroller code, and for which playback is as simple as streaming it to the UART. The example uses a Teensy and a transistor to drive a small speaker, we’re guessing that better quality might come with using a dedicated low-pass filter rather than relying on the speaker itself, but at least audio doesn’t come any simpler.

The code can be found in a GitHub repository and there’s a few recordings of the output in the files section Hackaday.io page, one is embedded below. It’s better than we might have expected given that the quality won’t be the best at the PWM data rate of even the fastest UART. But even if you won’t be incorporating it into your music system any time soon we can see it being a useful addition for such things as small warning sounds. Meanwhile if persuading serially driven speakers to talk is of interest, there’s always the venerable PC speaker.

Continue reading “Digital Audio For Microcontrollers Doesn’t Come Much Simpler Than A WART” →

C64 Demo, No C64

July 8, 2021 by Dan Maloney 24 Comments

Never underestimate the ingenuity of the demoscene. The self-imposed limitations lead to incredible creativity, and, the range of devices they manage to get their demos running on never ceases to amaze us. But we never thought we’d see a C64 demo without one central component: the C64.

Full disclosure: [Matthias Kramm]’s demo, called “Freespin”, does need a C64 to get started. The venerable 6502-based computer runs a loader program on a 1541 disk drive. But from then on, it’s all floppy drive. And [Matthias] has laid bare all his tricks.

The video below shows the demo in full, including a heart-stopping on-camera cable mod. By adding a single 100 Ω resistor, [Matthias] turned the serial clock and data lines into a two-bit digital-to-analog converter, good enough to generate signals for both black and white pixels and the sync pulses needed for the display.

No demo would be complete without sound, and Freespin’s tunes come from controlling the drive’s stepper motor, like a one-voice Floppotron.

Watching nothing but a floppy drive run a cool demo is pretty amazing. Yes, we know there’s a full-fledged computer inside the floppy, but the bit-banging needed to make this work was still mighty impressive. It might be cool to see what you could do with multiple drives, but we understand the minimalistic aesthetic as well. And speaking of tiny little demos: the 256 bytes of [HellMood]’s “Memories” or [Linus Åkesson]’s “A Mind is Born” still leave us speechless.

Continue reading “C64 Demo, No C64” →

DIY Wireless Serial Adapter Speaks (True) RS-232

April 18, 2021 by Donald Papp 80 Comments

There is a gotcha lurking in wait for hackers who look at a piece of equipment, see a port labeled “Serial / RS-232”, and start to get ideas. The issue is the fact that the older the equipment, the more likely it is to be a bit old-fashioned about how it expects to speak RS-232. Vintage electronics may expect the serial data to be at bipolar voltage levels that are higher than what the typical microcontroller is used to slinging, and that was the situation [g3gg0] faced with some vintage benchtop equipment. Rather than deal with cables and wired adapters, [g3gg0] decided to design a wireless adapter with WiFi and Bluetooth on one end, and true RS-232 on the other.

The adapter features an ESP32 and is attached to a DB-9 plug, so it’s nice and small. It uses the ST3232 chip to communicate at 3 V logic levels on the microcontroller side, supports bipolar logic up to +/-13 V on the vintage hardware side, and a rudimentary web interface allows setting hardware parameters like baud rate. The nice thing about the ST3232 transceiver is that it is not only small, but can work from a 3 V supply with only four 0.1 uF capacitors needed for the internal charge pumps.

As for actually using the adapter, [g3gg0] says that the adapter’s serial port is exposed over TCP on port 23 (Telnet) which is supported by some programs and hardware. Alternately, one can connect an ESP32 to one’s computer over USB, and run firmware that bridges any serial data directly to the adapter on the other end.

Design files including schematic, bill of materials, and PCB design are shared online, and you can see a brief tour of the adapter in the video, embedded below.

Continue reading “DIY Wireless Serial Adapter Speaks (True) RS-232” →

WebSerial: Browser Based Development For Your Boards And Electronic Badges

March 21, 2021 by Jenny List 9 Comments

For years, one of the most accessible and simplest-to-implement methods of talking to a dev board has been to give it a serial port. Almost everything has serial in some form, so all that’s needed is to fire up a terminal. But even with that simplicity, there are still moments when the end user might find a terminal interface a little daunting. Think of a board aimed at kids for example, or an event badge which must be accessible to as many people as possible.

We’ve seen a very convenient solution to this problem in the form of WebUSB, but for devices without the appropriate USB hardware there’s WebSerial, an in-browser API for communicating with serial ports including USB-to-serial chips. [Tom Clement] argues that this could serve as the way forward for event badges. Best of all it can be a retro-fit to enable in-browser development for older badges or dev boards with a serial port.

The boards on which he demonstrates the technique are the series of event badges running the badge.team firmware platform including his own i-Pane from CampZone 2019 and going right back to the SHA 2017 badge, but there’s no reason why the same technique can’t be extended to other boards.

There’s a snag with all this though, sadly only browsers in the Chrome family support it at the time of writing, with no plans from Mozilla and apple, and silence from Microsoft. So things look likely to stay that way. It is however inevitable that in time there will be commercial products taking advantage of it via the use of cheap USB to serial chips, so perhaps the case to incorporate it will make itself.

Header: Mobius, Public domain.

Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware

March 11, 2021 by Mike Szczys 29 Comments

1987 was a glorious year. It brought us the PS/2 keyboard standard that’s still present on many a motherboard back panel to this day. (It also marked the North America/Europe release of The Legend of Zelda but that’s another article.) Up until this point, peripherals were using DIN-5 and DE-9 (often mistakenly called DB9 and common for mice at the time) connectors or — gasp — non-standard proprietary connectors. So what was this new hotness all about? [Ben Eater] walks us through the PS/2 hall of fame by reverse-engineering the protocol.

This is a clocked data protocol, so a waveform is generated on the data pin for each key pressed that can be compared to the clock pin to establish the timing of each pulse. Every key sends a unique set of encoded pulses and voila, the whims of the user can quickly and easily be decoded by the machine.

This is where [Ben’s] dive really shines, we know he’s a breadboarding ninja so he reaches for some DIP chips. A shift register is an easy way to build up a parallel PS/2 interface for breaking out each data packet. There are a few quirks along the way, like the need to invert the clock signal so the shift register triggers on the correct edge. He also uses the propagation delay of a couple inverter gates to fire the 595 shift register’s latch pin slightly late, avoiding a race condition. A second 595 stores the output for display by a set of LEDs.

Beyond simply decoding the signal, [Ben] goes into how the packets are formatted. You don’t just get the key code, but you get normal serial interface error detection; start/stop bits and a parity bit as well. He even drills down into extended keys that send more than one packet, and a key-up action packet that’s sent by this particular keyboard.

This is the perfect low-level demo of how the protocol functions. On the practicality side, it feels a bit strange to be breaking out the serial to parallel when it would be very easy to monitor the two signal lines and decode them with a microcontroller. You might want to switch it up a bit, stick with the clock and data pins, but connect them to a Raspberry Pi using just a few passive components.

Continue reading “Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware” →

Linux Fu: Serial Untethered

February 11, 2021 by Al Williams 28 Comments

Serial ports used to be everywhere. In a way, they still are since many things that appear to plug in as a USB device actually look like a serial port. The problem is that today, the world runs on the network. Sure, you can buy a terminal server that converts a serial port to an Ethernet port, but what fun is that? In this article, I’m going to show you how to stream serial ports over the network using some available Linux tools. It isn’t perfect, and it won’t work for every case, but when it works it works well.

Everything is a File, Until it Isn’t

At some point in the past, Unix — the progenitor of Linux — treated virtually everything as a file, and all files were created more or less equal. Programs didn’t care if a file was local, on the network, from a tape drive, or arriving over a named pipe.

But things started to change. Even though a serial port is just a file under Linux, it has some special attributes that let you set, for example, baud rates. Worse, some programs “know” too much about files and insist on certain naming conventions. So, in theory, you should be able to create a network socket, connect one end to a serial port and the other end to a program, and be done with it. In theory.

Continue reading “Linux Fu: Serial Untethered” →

Modified Yost Tames Pinout Plethora

December 25, 2020 by Chris Lott 27 Comments

Every hacker has an assortment of USB to TTL-serial adapters kicking around in their lab, and we have all been annoyed that each one has a different pinout. You layout a PCB or breadboard for the Sparkfun flavor (GND, CTS, VCC, TXD, RXD, DTR), but when you begin troubleshooting all you can find is a CH340 board (GND, +5V, TXD, RXD, DTR, +3.3V). You have to jumper everything, and it becomes a mess. It wasn’t much better back in the days of RS-232 level signaling, either. While the pinouts were consistent, there were other headaches. Did the connection need a NULL modem adaptor? And if you were unlucky, you might need a DB-25 to DE-9 adaptor, and the really unlucky might need one or more gender changers. Surely there’s a better way.

It turns out there was a better way, although it didn’t seem to have become as popular as one might expect. Back in 1987 [Dave Yost] formalized an interconnection scheme using RJ45 plugs and jacks while at Berkeley. The signals were arranged in a mirrored fashion so that each cable is always a crossover — just plug two cables back-to-back if you really need a straight thru connection.

Even though he was dealing with RS-232 serial, nothing prevents us from using this scheme for logic level signaling. For example, consider the following 1×10 header pinout, where the original 8-pins are expanded to 10 to allow for power:

This is an extreme example, and can obviously be shrunk depending on how much handshaking, if any, or power is desired. Such a pinout lets you switch between DCE and DTE by simply flipping the connector around. And if a Dupont-style header slips off too easily in your applications, you could always use an RJ connector. This still doesn’t solve the Tower of Babel pinout problem with the USB-TTL adaptors. But standardizing on a serial pinout such as this for your projects and making cables or kludging your TTL adaptors will make serial debugging less painful.

Back when he released this scheme in 1987, [Dave] pontificated:

“Maybe one day before the year 2,000, the world will have a new, simple, high-speed, flow-controlled, standard type of connection for point-to-point applications currently using RS-232, with an adaptor available to talk to old, RS-232 equipment.”

Let us know your thoughts in the comments below.