Want to display a PNG file on a display attached to an Arduino or other microcontroller board? You’ll want to look at [Larry Bank]’s PNGdec, the Arduino-friendly PNG decoder library which makes it much easier to work with PNG files on your chosen microcontroller.
The PNG image format supports useful features like lossless compression, and was generally developed as an improved (and non-patented) alternative to GIF files. So far so great, but it turns out that decoding PNG files on a microcontroller is a challenge due to the limited amount of memory compared to desktop machines. When the PNG specification was developed in the 90s, computers easily had megabytes of memory to work with, but microcontrollers tend to have memory measured in kilobytes, and lack high-level memory management. [Larry]’s library addresses these issues.
PNGdec is self-contained and free from external dependencies, and also has some features to make converting pixel formats for different display types easy. It will run on any microcontroller that can spare at least 48 K of RAM, so if that sounds useful then check out the GitHub repository for code and examples.
We’ve seen [Larry]’s wonderful work before on optimizing GIF playback as well as rapid JPEG decoding, and these libraries have increasing relevance as hobbyists continue to see small LCD and OLED-based displays become ever more accessible and affordable.
[PNG logo: PNG Home Site]
Over the last year or so we’ve noticed a definite uptick in the number of folks using OpenOCD on the Raspberry Pi. It’s a cheap and convenient solution for poking around with various microcontrollers and embedded devices, but not always the most elegant. Looking to improve on the situation somewhat, [Matthew Mets] has been working on a purpose-built JTAG Hat to clean things up a bit.
Onboard level shifters allow you connect to JTAG and SWD interfaces from 1.8 to 5 V, and if you power the target device from the Pi itself, there’s even support for measuring the voltage and current. To connect up to your target, the open hardware board features a “legacy” pin header perfect for jumper wires, as well as a dedicated 10-pin Cortex Debug Connector. Whether you spin up your own or buy one assembled, it certainly looks like a tool worth having around if you often find yourself working with the appropriate chips.
In addition to the design files for the hardware, [Matthew] has also provided some nice documentation on how to get the software side of things up and running. Starting with a blank SD card, it walks you through the initial setup of the Raspberry Pi all the way through the installation and configuration of a patched version of OpenOCD designed to support the JTAG Hat.
If you spend more time working with 8-bit AVR chips, don’t worry. Last year we covered a similar project to turn everyone’s favorite Linux SBC into an all-in-one microcontroller development powerhouse.
For a monochrome display where refresh rate isn’t particularly important, there’s almost no better option than an E Ink display. They’re available in plenty of sizes and at various price points, but there’s almost no option cheaper than repurposing something mass-produced and widely available like an E Ink (sometime also called eInk or ePaper) price tag. At least, once all of the reverse engineering is complete.
[Dmitry Grinberg] has been making his way through a ton of different E Ink modules, unlocking their secrets as he goes. In this case he set about reverse engineering the unknown microcontroller on the small, cheap display show here. Initial research showed an obscure chip from the ZBS24x family, packaged with a SSD1623L2 E Ink controller. From there, he was able to solder to the communications wires and start talking to the device over ISP.
This endeavor is an impressive deep dive into the world of microcontrollers, from probing various registers to unlocking features one by one. It’s running an 8051 core so [Dmitry] gives a bit of background to help us all follow along, though it’s still a pretty impressive slog to fully take control of the system.
If you happen to have one of these price tags on hand it’s an invaluable resource to have to reprogram it, but it’s a great read in general as well. On the other hand, if you’re more interested in reverse-engineering various displays, take a look at this art installation which spans 50 years of working display technologies.
Over the years, artists have been creating art depicting weapons of mass destruction, war and human conflict. But the weapons of war, and the theatres of operation are changing in the 21st century. The outcome of many future conflicts will surely depend on digital warriors, huddled over their computer screens, punching on their keyboards and maneuvering joysticks, or using devious methods to infect computers to disable or destroy infrastructure. How does an artist give physical form to an unseen, virtual digital weapon? That is the question which inspired [Mac Pierce] to create his latest Portrait of a Digital Weapon.
[Mac]’s art piece is a physical depiction of a virtual digital weapon, a nation-state cyber attack. When activated, this piece displays the full code of the Stuxnet virus, a worm that partially disabled Iran’s nuclear fuel production facility at Natanz around 2008. Continue reading “Portrait Of A Digital Weapon”
In the most simple computer system architecture, all control lies with the CPU (Central Processing Unit). This means not only the execution of commands that affect the CPU’s internal register or cache state, but also the transferring of any bytes from memory to to devices, such as storage and interfaces like serial, USB or Ethernet ports. This approach is called ‘Programmed Input/Output’, or PIO, and was used extensively into the early 1990s for for example PATA storage devices, including ATA-1, ATA-2 and CompactFlash.
Obviously, if the CPU has to handle each memory transfer, this begins to impact system performance significantly. For each memory transfer request, the CPU has to interrupt other work it was doing, set up the transfer and execute it, and restore its previous state before it can continue. As storage and external interfaces began to get faster and faster, this became less acceptable. Instead of PIO taking up a few percent of the CPU’s cycles, a big transfer could take up most cycles, making the system grind to a halt until the transfer completed.
DMA (Direct Memory Access) frees the CPU from these menial tasks. With DMA, peripheral devices do not have to ask the CPU to fetch some data for them, but can do it themselves. Unfortunately, this means multiple systems vying for the same memory pool’s content, which can cause problems. So let’s look at how DMA works, with an eye to figuring out how it can work for us.
Continue reading “Direct Memory Access: Data Transfer Without Micro-Management”
One of [Sasa]’s life goals is to be able to sit back in his home and watch as robots perform all of his work for him. In order to work towards this goal, he has decided to start with some home automation which will take care of all of his house plants for him. This project is built from the ground up, too, and is the first part of a series of videos which will outline the construction of a complete, open-source plant care machine.
The first video starts with the sensors for the plants. [Sasa] decided to go with a completely custom module based on the STM32 microcontroller since commercial offerings had poor communications designs and other flaws. The small board is designed to be placed in the soil, and has sensors for soil moisture as well as other sensors for amount of light available and the ambient temperature. The improvements over the commercial modules include communication over I2C, allowing a large number of modules to communicate over a minimum of wires and be arranged in any way needed.
For this build everything is open-source and available on [Sasa]’s GitHub page, including PCB layouts and code for the microcontrollers. We’re looking forward to the rest of the videos where he plans to lay out the central unit for handling all of these sensors, and a custom dashboard for controlling them as well. Perhaps there will also be an option for adding a way to physically listen to the plants communicate their needs as well.
Continue reading “Your Plants Can Take Care Of Themselves Now”
We’re knee-deep in new microcontrollers over here, from the new Raspberry Pi Pico to an engineering sample from Espressif that’s right now on our desk. (Spoiler alert, review coming out Monday.) And microcontroller peripherals are a little bit like Pokemon — you’ve just got to catch them all. If a microcontroller doesn’t have 23 UARTS, WiFi, Bluetooth, IR/DA, and a 16-channel 48 MHz ADC, it’s hardly worth considering. More is always better, right?
No, it’s not. Chip design is always a compromise, and who says you’re limited to one microcontroller per project anyway? [Francesco] built a gas-meter reader that reminded to think outside of the single-microcontroller design paradigm. It uses an ATtiny13 for its low power sleep mode, ease of wakeup, and decent ADCs. Pairing this with an ESP8266 that’s turned off except when the ATtiny wants to send data to the network results in a lower power budget than would be achievable with the ESP alone, but still gets his data up into his home-grown cloud.
Of course, there’s more complexity here than a single-micro solution, but the I2C lines between the two chips actually form a natural division of work — each unit can be tested separately. And it’s using each chip for what it’s best at: simple, low-power tasks for the Tiny and wrangling WiFi on the ESP.
Once you’ve moved past the “more is better” mindset, you’ll start to make a mental map of which chips are best for what. The obvious next step is combination designs like this one.