Displays We Love Hacking: Parallel RGB

You might have seen old display panels, from 3″ to 10″, with 40-pin FFC connectors where every pin seems to be used for some data signal. We call these displays parallel RGB, or TTL RGB, or DPI, and you can find them in higher-power MCU, Raspberry Pi, and other Linux SBC projects. You deserve to know what to do with those – let’s take a look.

The idea is simple – this interface requires you to constantly send a stream of pixels to the display, and you need to send those pixels through a parallel bus. You can send up to 8 bits per color channel per pixel, which makes for 24 bits, and the 24-bit mode is indeed the standard, but in practice, many parallel RGB implementations don’t bother with more than 5-6 bits of color – two common kinds of parallel RGB links are RGB565 and RGB666. The parallel RGB interface is a very straightforward approach to sending pixels to your display, and in many cases, you can also convert parallel RGB to LVDS or VGA interfaces relatively easily!

If you’re new to it, the easiest way you can drive a parallel RGB display is from a Raspberry Pi, where the parallel RGB interface is known as DPI. This is how 800 x 480 display Pi HATs like the Pimoroni HyperPixel work – they use up almost all of the GPIOs on your Pi, but you get a reasonably high-resolution display with a low power footprint, and you don’t need any intermediate ICs either. FPGAs and some higher-grade MCUs also often have parallel RGB output capability, and surely, someone could even use the RP2040 PIO as well!

Throughout the last decade, parallel RGB has been used less and less, but you will still encounter it – maybe you’re working with an old game console like the PSP and would like to put new guts into it, maybe you’re playing with some tasty display that uses parallel RGB, or maybe you’d like to convert parallel RGB into something else while treating it with respect! Let’s go through what makes parallel RGB tick, what tools you have got to work with it, and a few tips and tricks. Continue reading “Displays We Love Hacking: Parallel RGB”

Hardware Should Lead Software, Right?

Once upon a time, about twenty years ago, there was a Linux-based router, the Linksys WRT54G. Back then, the number of useful devices running embedded Linux was rather small, and this was a standout. Back then, getting a hacker device that wasn’t a full-fledged computer onto a WiFi network was also fairly difficult. This one, relatively inexpensive WiFi router got you both in one box, so it was no surprise that we saw rovers with WRT54Gs as their brains, among other projects.

Long Live the WRT54G

Of course, some people just wanted a better router, and thus the OpenWRT project was born as a minimal Linux system that let you do fancy stuff with the stock router. Years passed, and OpenWRT was ported to newer routers, and features were added. Software grew, and as far as we know, current versions won’t even run on the minuscule RAM of the original hardware that gave it it’s name.

Enter the ironic proposal that OpenWRT – the free software group that developed their code on a long-gone purple box – is developing their own hardware. Normally, we think of the development flow going the other way, right? But there’s a certain logic here as well. The software stack is now tried-and-true. They’ve got brand recognition, at least within the Hackaday universe. And in comparison, developing some known-good hardware to work with it is relatively easy.

We’re hardware hobbyists, and for us it’s often the case that the software is the hard part. It’s also the part that can make or break the user experience, so getting it right is crucial. On our hacker scale, we often choose a microcontroller to work with a codebase or tools that we want to use, because it’s easier to move some wires around on a PCB than it is to re-jigger a software house of cards. So maybe OpenWRT’s router proposal isn’t backwards after all? How many other examples of hardware designed to fit into existing software ecosystems can you think of?

How Do You Test If An EEPROM Can Hold Data For 100 Years?

Data retention is a funny thing. Atmel will gladly tell you that the flash memory in an ATmega32A will retain its data for 100 years at room temperature. Microchip says its EEPROMs will retain data for over 200 years. And yet, humanity has barely had a good grasp on electricity for that long. Heck, the silicon chip itself was only invented in 1958. EEPROMs and flash storage are altogether younger themselves.

How can these manufacturers make such wild claims when there’s no way they could have tested their parts for such long periods of time? Are they just betting on the fact you won’t be around to chastise them in 2216 when your project suddenly fails due to bit rot.

Well, actually, there’s a very scientific answer. Enter the practice of accelerated wear testing.

Continue reading “How Do You Test If An EEPROM Can Hold Data For 100 Years?”

Close To The Metal

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

A Mainframe Computer For The Modern Age

The era of mainframe computers and directly programming machines with switches is long past, but plenty of us look back on that era with a certain nostalgia. Getting that close to the hardware and knowing precisely what’s going on is becoming a little bit of a lost art. That’s why [Phil] took it upon himself to build this homage to the mainframe computer of the 70s, which all but disappeared when PCs and microcontrollers took over the scene decades ago.

The machine, known as PlasMa, is not a recreation of any specific computer but instead looks to recreate the feel of computers of this era in a more manageable size. [Phil] built the entire machine from scratch, and it can be programmed directly using toggle switches to input values into registers and memory. Programs can be run or single-stepped, and breakpoints can be set for debugging. The internal workings of the machine, including the program counter, instruction register, accumulator, and work registers, are visible in binary lights. Front panel switches let you control those same items.

The computer also hosts three different microcodes, each providing a unique instruction set. Two are based on computers from Princeton, Toy-A, and Toy-B, used as teaching tools. The third is a more advanced instruction set that allows using things like emulated peripherals, including storage devices. If you want to build one or just follow along as the machine is constructed, programmed, and used, [Phil] has a series of videos demonstrating its functionality, and he’s made everything open-source for those more curious. It’s a great way to get a grasp on the fundamentals of computing, and the only way we could think of to get even more into the inner workings of a machine like this is to build something like a relay computer.

Continue reading “A Mainframe Computer For The Modern Age”

MeArm 3.0: The Pocket-Sized Robot Arm

We all might dream of having an industrial robot arm at our disposal, complete with working controller that doesn’t need constant maintenance and replacement parts, and which is able to help us with other projects with only a minimum of coding or instruction. That’s a pipe dream for most of us, as without a large space, sufficient funding, or unlimited amounts of troubleshooting time we’ll almost always have to look for something smaller and simpler. Perhaps something even as small as this pocket-sized robotic arm.

This isn’t actually the first time we’ve seen the MeArm; the small robot has been around since 2014 and has undergone a number of revisions and upgrades. Even this revision has been out for a little while now but this latest in the series is now available with a number of improvements over the older models. The assembly time required has been reduced from two hours to about 30 minutes and the hardware has even been fully open-sourced as well which allows virtually anyone with the prerequisite tools to build this tiny robot for whatever they happen to need it for, due to its very permissive licensing.

The linked Instructable goes into every detail needed for building the robot as well as documenting all of the parts needed, although you will need access to some specialty tools to make a lot of them. We also featured a Friday Hack Chat about these robots back in 2018 that has some interesting details about these robots in it, and although this is a relatively small robot in the grand scheme of things it’s always possible to upgrade to something larger in the future.

Continue reading “MeArm 3.0: The Pocket-Sized Robot Arm”

Recreating An Analog TV Test Pattern

While most countries have switched to digital broadcasting, and most broadcasts themselves have programming on 24/7 now, it’s hard to remember the ancient times of analog broadcasts that would eventually stop sometime late at night, displaying a test pattern instead of infomercials or reruns of an old sitcom. They were useful for various technical reasons including calibrating the analog signals. Some test patterns were simply camera feeds of physical cards, but if you wanted the most accurate and reliable test patterns you’d need a Philips pattern generator which created the pattern with hardware instead, and you can build your own now because the designs for these devices were recently open-sourced. Continue reading “Recreating An Analog TV Test Pattern”