Real Time Hacking Of A Supermarket Toy

Sometimes those moments arise when a new device comes on the market and hardware hackers immediately take to it. Over a few days, an observer can watch them reverse engineer it and have all sorts of fun making it do things it wasn’t intended to by the original manufacturer. We’re watching this happen in real time from afar this morning, as Dutch hackers are snapping up a promotional kids’ game from a supermarket (mixed Dutch/English, the site rejects Google Translate).

The Albert Heijn soundbox is a small handheld device with a barcode reader and a speaker, and as far as we can see it forms part of an animal identification card game. The cards have a barcode on the back, and sliding them through a reader causes a sample of that animal’s sound to be played. They’re attractively cheap, so of course someone had to take a look inside. So far the parts including the microcontroller have been identified, the ROM has been dumped and the audio reverse-engineered, and the barcode format has been cracked. Still to come are the insertion of custom audio or codes and arbitrary code execution, but knowing these hackers that won’t take long. If you’re Dutch, we suggest you head over to your local Albert Heijn with a few euros, and join in the fun.

European supermarkets can be fruitful places for the hardware hacker, as we’ve shown you before.

Putting A Pi In A Container

Docker and other containerization applications have changed a lot about the way that developers create new software as well as how they maintain virtual machines. Not only does containerization reduce the system resources needed for something that might otherwise be done in a virtual machine, but it standardizes the development environment for software and dramatically reduces the complexity of deploying on different computers. There are some other tricks up the sleeves as well, and this project called PI-CI uses Docker to containerize an entire Raspberry Pi.

The Pi container emulates an entire Raspberry Pi from the ground up, allowing anyone that wants to deploy software on one to test it out without needing to do so on actual hardware. All of the configuration can be done from inside the container. When all the setup is completed and the desired software installed in the container, the container can be converted to an .img file that can be put on a microSD card and installed on real hardware, with support for the Pi models 3, 4, and 5. There’s also support for using Ansible, a Docker automation system that makes administering a cluster or array of computers easier.

Docker can be an incredibly powerful tool for developing and deploying software, and tools like this can make the process as straightforward as possible. It does have a bit of a learning curve, though, since sharing operating system tools instead of virtualizing hardware can take a bit of time to wrap one’s mind around. If you’re new to the game take a look at this guide to setting up your first Docker container.

Free And Open E-Reader From The Ground Up

Although ebooks and e-readers have a number of benefits over reading an analog paper book as well as on more common electronic devices like tablets, most of them are locked behind proprietary systems like Kindle which make it difficult to take control over your electronic library. While there are a few off-brand e-readers that allow users to take a bit of control back and manually manage their files and libraries, there are few options for open-source solutions. This project aims to provide not only a free and open e-reader from the hardware to the software, but also a server to host a library as well.

The goal of most of the build is to keep everything as FLOSS as possible including the hardware, which is based on a Raspberry Pi compute module. The display comes from Good Display, which includes a built-in light and a touchscreen. There’s a lithium battery to power the tablet-like device with a number of support chips to charge it, handle the display, and interface with the Pi. On the software side, the system uses MuPDF which has support for most ebook file types while the server side is based on Calibre and the Open Publication Distribution System.

A subsection of the build log discusses a lot of how the code works for those looking to build their own similar system based on this project. The project code is even hosted on GitLab, a more FLOSS-y version of GitHub. Free and open ebook readers have been a goal of a number of builders for some time now, as we’ve seen projects going back at least a few years now and others that hope to make the Kindle hardware a little more open instead.

Displays We Love Hacking: DSI

We would not be surprised if DSI screens made up the majority of screens on our planet at this moment in time. If you own a smartphone, there’s a 99.9% chance its screen is DSI. Tablets are likely to use DSI too, unless it’s eDP instead, and a smartwatch of yours definitely will. In a way, DSI displays are inescapable.

This is for a good reason. The DSI interface is a mainstay in SoCs and mobile CPUs worth their salt, it allows for higher speeds and thus higher resolutions than SPI ever could achieve, comparably few pins, an ability to send commands to the display’s controller unlike LVDS or eDP, and staying low power while doing all of it.

There’s money and power in hacking on DSI – an ability to equip your devices with screens that can’t be reused otherwise, building cooler and cooler stuff, tapping into sources of cheap phone displays. What’s more, it’s a comparably underexplored field, too. Let’s waste no time, then!

Decently Similar Internals

DSI is an interface defined by the MIPI Alliance, a group whose standards are not entirely open. Still, nothing is truly new under the sun, and DSI shares a lot of concepts with interfaces we’re used to. For a start, if you remember DisplayPort internals, there are similarities. When it comes to data lanes, DSI can have one, two or four lanes of a high-speed data stream; smaller displays can subsist with a single-lane, while very high resolution displays will want all four. This is where the similarities end. There’s no AUX to talk to the display controller, though – instead, the data lanes switch between two modes.

Continue reading “Displays We Love Hacking: DSI”

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?”