Putting A Pi In A Container

August 30, 2024 by Bryan Cockfield 16 Comments

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

July 17, 2024 by Bryan Cockfield 21 Comments

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

June 12, 2024 by Arya Voronova 10 Comments

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

January 25, 2024 by Arya Voronova 8 Comments

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?

January 20, 2024 by Elliot Williams 26 Comments

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.

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?

December 21, 2023 by Lewin Day 40 Comments

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

October 14, 2023 by Elliot Williams 81 Comments

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!