Glasgow Uses An FPGA As An Embedded Systems Multitool

August 10, 2020 by Al Williams 13 Comments

Everyone who builds embedded systems wants tools to help build and debug systems faster, so it isn’t uncommon to see boards outfitted with various tools like serial port sniffers. We’ve seen a few incarnations and the latest is Glasgow. The small board uses an FPGA and claims to do the following:

UART with automatic baud rate determination
SPI or I2C
Read and write common EEPROMs and flash chips
Read and write common EPROMs including a data rescue function
Program AVR chips via SPI
Play back JTAG SVF files
Debug ARC and some MIPS CPUs
Program XC9500LX CPLDs
Communicate to several wireless radios and CPUs
Do sound synthesis
Read raw data from floppy drives

The revC board is the first to be relatively functional and sports 16 I/O pins operating at up to 100 MHz, although the documentation hints that 6 MHz might be the top of what’s easily accomplished. The software is written in Python and the iCE40 FPGA toolchain that we’ve talked about many times in the past.

This already looks like a useful tool and the reconfigurable nature of FPGAs makes it a good platform to expand. The documentation discusses the difficulty in debugging things for the board, so the base software offers support such as a built-in logic analyzer to help.

We have seen dev boards become bench tools, like using the iCEstick as a logic analyzer. It’s nice to see dedicated tools like this one built up around the speed and versatility of FPGAs.

Continue reading “Glasgow Uses An FPGA As An Embedded Systems Multitool” →

Official Arduboy Upgrade Module Nears Competition

August 4, 2020 by Tom Nardi 14 Comments

We’ve been big fans of the Arduboy since [Kevin Bates] showed off the first prototype back in 2014. It’s a fantastic platform for making and playing simple games, but there’s certainly room for improvement. One of the most obvious usability issues has always been that the hardware can only hold one game at a time. But thanks to the development of an official add-on, the Arduboy will soon have enough onboard storage to hold hundreds of games

Even the rear silkscreen was a community effort.

The upgrade takes the form of a small flexible PCB that gets soldered to existing test points on the Arduboy. Equipped with a W25Q128 flash chip, the retrofit board provides an additional 16 MB of flash storage to the handheld’s ATmega32u4 microcontroller; enough to hold essentially every game and program ever written for the platform at once.

Of course, wiring an SPI flash chip to the handheld’s MCU is only half the battle. The system also needs to have its bootloader replaced with one that’s aware of this expanded storage. To that end, the upgrade board also contains an ATtiny85 that’s there to handle this process without the need for an external programmer. While this is a luxury the average Hackaday reader could probably do without, it’s a smart move for an upgrade intended for a wider audience.

The upgrade board is currently available for pre-order, but those who know their way around a soldering iron and a USBasp can upgrade their own hardware right now by following along with the technical discussion between [Kevin] and the community in the “Project Falcon” forum. In fact, the particularly astute reader may notice that this official upgrade has its roots in the community-developed Arduboy cartridge we covered last year.

Continue reading “Official Arduboy Upgrade Module Nears Competition” →

Hackaday Podcast 074: Stuttering Swashplate, Bending Mirrors, Chasing Curves, And Farewell To Segway

July 3, 2020 by Mike Szczys 5 Comments

Hackaday editors Elliot Williams and Mike Szczys recap a week of hacks. A telescope mirror that can change shape and a helicopter without a swashplate lead the charge for fascinating engineering. These are closely followed by a vibratory wind generator that has no blades to spin. The Open Source Hardware Association announced a new spec this week to remove “Master” and “Slave” terminology from SPI pin names. The Segway is no more. And a bit of bravery and rock solid soldering skills can resurrect that Macbook that has one dead GPU.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 074: Stuttering Swashplate, Bending Mirrors, Chasing Curves, And Farewell To Segway” →

Updating The Language Of SPI Pin Labels To Remove Casual References To Slavery

June 29, 2020 by Mike Szczys 288 Comments

This morning the Open Source Hardware Association (OSHWA) announced a resolution for changing the way SPI (Serial Peripheral Interface) pins are labelled on hardware and in datasheets. The protocol originally included MOSI/MISO references that stand for “Master Out, Slave In” and “Master In, Slave Out”. Some companies and individuals have stopped using these terms over the years, but an effort is being taken up to affect widespread change, lead by Nathan Seidle of Sparkfun.

The new language for SPI pin labeling recommends the use of SDO/SDI (Serial Data Out/In) for single-role hardware, and COPI/CIPO for “Controller Out, Peripheral In” and “Controller In, Peripheral Out” for devices that can be either the controller or the peripheral. The change also updates the “SS” (Slave Select) pin to use “CS” (Chip Select).

SPI is widely used in embedded system design and appears in a huge range of devices, with the pin labels published numerous times in everything from datasheets and application notes to written and video tutorials posted online. Changing the labels removes unnecessary references to slavery without affecting the technology itself. This move makes embedded engineering more inclusive, an ideal that’s easy to get behind.

[2022 Editor’s Note: The OSHWA changed its recommended naming to PICO/POCI for “Peripheral In, Controller Out” and “Peripheral Out, Controller In”. Fine by us! I’ve updated this throughout the rest of the article because it doesn’t change Mike’s original argument at all.]

Continue reading “Updating The Language Of SPI Pin Labels To Remove Casual References To Slavery” →

Subwoofer Gets Arduino Brain Transplant

April 6, 2020 by Tom Nardi 15 Comments

The Samsung PS-WTX500 subwoofer is designed to be used as part of a 5.1 channel home theater system, but not just any system. It contains the amplifiers for all the channels, but they’ll only function when the subwoofer is connected to the matching receiver. [Alejandro Zarate] figured there must be some way to unlock the system’s full functionality without being limited to the original receiver, he just needed to reverse engineer how the subwoofer worked.

All the wires tuck underneath the Arduino

The result is a fantastically well documented write-up that covers the whole process, starting with how [Alejandro] identified and researched the Pulsus PS9829B Digital Audio Processor (DAP). Documentation for this particular chip seems hard to come by, but he was able to find a similar chip from the same manufacturer that was close enough to put him on the right track. From there, he started studying the SPI communications between the DAP and the subwoofer’s S3P70F4 microcontroller.

After analyzing the communication between the two chips, [Alejandro] pulled the S3P70F4 off the board and wired an Arduino Pro Mini 328 in its place. The Arduino was quite a bit larger than the original microcontroller, but with some careful wiring, he manged a very professional looking installation. Short of coming up with a custom PCB adapter, we don’t think it could look much better.

With some relatively straightforward code and a listing of the captured byte sequences, the Arduino was able to power up the PS-WTX500’s amplifiers and handle the incoming audio signal as a stand-alone device.

In the past we’ve seen a similar trick done with the ESP8266, which had the added benefit of enabling WiFi control of the speakers. We’re all for adding modern functionality to older hardware, even if you’ve got to hang it off the back as an external module.

Continue reading “Subwoofer Gets Arduino Brain Transplant” →

Slice Through Your Problems With A Shukran

February 4, 2020 by Kerry Scharfglass 38 Comments

We’d wager most hackers are familiar with FTDI as the manufacturer of the gold standard USB-UART interfaces. Before parts like the ultra cheap CH340 and CP2102 became common, if you needed to turn a USB cable into a TTL UART device, “an FTDI” (probably an FT232RL) was the way to make that happen. But some of the parts in the FT232* family are capable of much more. Wanting to get at more than a UART, [linker3000] designed the Shukran to unlock the full potential of the FT232H.

The FT232H is interesting because it’s an exceptionally general purpose interface device. Depending on configuration it can turn USB into UART, JTAG, SPI, I2C, and GPIO. Want to prototype the driver for a new sensor? Why bother flashing your Teensy when you can drive it directly from the development machine with an FT232H and the appropriate libraries?

The Shukran is actually a breakout for the “CJMCU FT232H” module available from many fine internet retailers. This board is a breakout that exposes a USB-A connecter on one side and standard 0.1″ headers on the other, with a QFN FT232H and all the passives in the middle. But bare 0.1″ headers (in a square!) require either further breadboarding or a nest of jumper wires to be useful. Enter the Shukran. In this arrangement, the CJMCU board is cheap and handles the SMT components, and the Shukran is easy to assemble and makes it simple to use.

The Shukran gives you LEDs, buttons and switches, and a bunch of pull up resistors (for instance, for I2C) on nicely grouped and labeled headers. But most importantly it provides a fused power supply. Ever killed the USB controller in your computer because you forgot to inline a sacrificial USB hub? This fuse should take care of that risk. If you’re interested in building one of these handy tools, sources and detailed BOM as well as usage instructions are available in the GitHub repo linked at the top.

Swapping The ROMs In Mini Arcade Cabinets

December 6, 2019 by Tom Nardi 10 Comments

You’ve probably seen a few of these miniature arcade games online or in big box retailers: for $20 USD or so you get scaled-down version of a classic arcade cabinet, perfect for a desk toy or to throw up on a shelf as part of your gaming collection. Like any good Hackaday reader, you were probably curious about what makes them tick. Thanks to [wrongbaud], we don’t have to wonder anymore.

Over the course of several blog posts, [wrongbaud] walks readers through the hardware and software used in a few of these miniature games. For example, the Rampage cabinet is using a so-called “NES on a Chip” along with a SPI flash chip to hold the ROM, while Mortal Kombat is using a Genesis emulation solution and parallel flash. It wouldn’t be interesting if they didn’t throw you a few curves now and again, right?

But these are more than simple teardowns. Once [wrongbaud] gives an overview of the hardware, the next step is reading the respective flash storage and trying to make sense of the dumped data. These sort of games generally reuse the hardware among a number of titles, so by isolating where the game ROM is and replacing it, they can be made to play other games without hardware modification. Here, this capability is demonstrated by replacing the ROM data for Rampage with Yoshi’s Cookie. Naturally it’s one of those things that’s easier said than done, but it’s an interesting proof of concept.

The Mortal Kombat cabinet is a newer addition to the collection, so [wrongbaud] hasn’t progressed quite as far with that one. The parallel flash chip has been dumped with the help of an ESP32 and a MCP23017 I/O expander, and some Genesis ROM headers are identifiable in the data, but there’s still some sifting to be done before the firmware structure can be fully understood.

Even if you’re not in the market for a diminutive arcade experience, the information that [wrongbaud] has collected here is really phenomenal. From understanding protocols such as I2C and SPI to navigating firmware dumps with a hex editor, these posts are an invaluable resource for anyone looking to get started with reverse engineering.