Comprehensive Power Management For The Raspberry Pi

The Raspberry Pi has been a revolutionary computer in the maker space, providing a full Linux environment, GUI, and tons of GPIO and other interfacing protocols at a considerably low price. This wasn’t its original intended goal, though. Back in the early 2010s it was supposed to be an educational tool for students first, not necessarily a go-to for every electronics project imaginable. As such there are a few issues with the platform when being used this way, and [Vin] addresses his problems with its power management in his latest project.

[Vin]’s main issue is that, unlike a microcontroller, the Raspberry Pi doesn’t have a deep sleep function. That means that even when the operating system is shut down the computer is still drawing an appreciable amount of current, which will quickly drain some batteries. We’ve covered [Vin]’s farm and his use case for the Raspberry Pi in the past, but a quick summary is that these boards are being used in a very rugged environment where utility power isn’t as reliable as he would like.

In [Vin]’s post he not only outlines his design for the board but goes through his design process, starting by using discrete logic components and then trying out various microcontrollers until settling on an ATmega88. The microcontroller communicates with the Raspberry Pi over I2C where the Pi can request a power-down as well as a time for future power-on. A latching relay controlled by the microcontroller ensures the Pi doesn’t drain any battery while the ATmega can put itself into actual sleep in the meantime.

The build for this project goes into an impressive amount of detail, and not only are the designs and code available on the project’s GitHub page but [Vin] also wrote another blog post which uses this project to go over his design philosophy more broadly.

Homebrew Phosphorescence Detector Looks For The Glow In Everyday Objects

Spoiler alert: almond butter isn’t phosphorescent. But powdered milk is, at least to the limit of detection of this homebrew phosphorescence detector.

Why spend a bunch of time and money on such a thing? The obvious answer is “Why not?”, but more specifically, when [lcamtuf]’s son took a shine (lol) to making phosphorescent compounds, it just seemed natural for dad to tag along in his own way. The basic concept of the detector is to build a light-tight test chamber that can be periodically and briefly flooded with UV light, charging up the putatively phosphorescent compounds within. A high-speed photodiode is then used to detect the afterglow, which can be quantified and displayed.

The analog end of the circuit was the far fussier end of the design, with a high-speed transimpedance amplifier to provide the needed current gain. Another scaling amp and a low-pass filter boosts and cleans up the signal for a 14-bit ADC. [lcamtuf] went to great lengths to make the front end as low-noise as possible, including ferrite beads and short leads to prevent picking up RF interference. The digital side has an AVR microcontroller that talks to the ADC and runs an LCD panel, plus switches the 340 nm LEDs on and off rapidly via a low gate capacitance MOSFET.

Unfortunately, not many things found randomly around the average home are all that phosphorescent. We’re not sure what [lcamtuf] tried other than the aforementioned foodstuffs, but we’d have thought something like table salt would do the trick, at least the iodized stuff. But no matter, the lessons learned along the way were worth the trip.

You Can Program AVRs From The Commodore 64

These days, most of our microcontroller boards come with bootloaders so you can squirt hex into them straight over USB. However, you don’t need to do things this way. If you’re more old school, you can program your AVRs right from a Commodore 64. [Linus Akesson] shows us how.

Programming an AVR isn’t that hard. By holding the chip in reset, it’s possible to flash code via a serial protocol using just three wires. However, that’s pretty impractical to do with modern PCs — they don’t come with addressable IO pins anymore. Normally, you’d use a dedicated programmer to do the job, but [Linus] found his had died on a Friday night. So he set about turning his C64 into one instead.

He decided to use the pins of the C64’s Joystick Port 2, with pins 1, 2, 3, and 4 hooked up to SCK, MOSI, Reset, and MISO on the AVR, respectively. 5 V and Ground were also provided courtesy of the C64’s port. He then whipped up a simple bit of assembly code to read a bit of AVR hex and spit it out over the Joystick port following the in-circuit programming protocol. With a 1541 Ultimate to load files on to the C64 in hand, it was easy to pull his compiled AVR program off his modern PC, chuck it on the C64, and then get the old Commodore to program the AVR in turn.

It’s not the first time [Linus] has wowed us with a C64 in hand. If you’ve got your own fresh projects for the best-selling computer of all time, don’t hesitate to let us know!

Pushing Crates In 8-bit Color

Moore’s law isn’t strictly holding anymore, but it is still true that most computing systems are at least trending towards lower cost over time, if not also slightly smaller size. This means wider access to less expensive hardware, even if that hardware is still an 8-bit microcontroller. While some move on to more powerful platforms as a result of this trend, there are others still fighting to push these platforms to the edge. [lcamtuf] has been working to this end, stretching a small AVR microcontroller to not only play a classic video game, but to display it on a color display. Continue reading “Pushing Crates In 8-bit Color”

Audio Playback Toy For DSP Adventures

The declining costs of single-board computers has made serious computing power available for even the most trivial of tasks. It’s easy enough to slap a Raspberry Pi onto almost anything for nearly the same cost as a powerful 32-bit microcontroller platform, but this takes some of the fun out of projects for a few of us. Looking to get into the weeds can be a challenge as well, as [Michal Zalewski] demonstrates in this audio playback device he built from a simple 8-bit microcontroller.

The small toy takes audio input from a microphone through an op-amp and feeds this signal to an ADC within the AVR128DA28 microcontroller. The data is then stored on a separate memory chip ready to be played back through another op-amp paired with a speaker. This is where being familiar with the inner workings of the microcontroller comes in handy. By manipulating the interrupt routines in specific ways, the audio stored in memory can be played back at various speeds.

[Michal] intended this build to be a toy for one of his younger relatives, and for the price of a few ICs and buttons it does a pretty good job of turning a regular voice into a chipmunk voice like some commercial children’s toys some of us might remember. If the design aesthetics of this gadget look familiar, you may be thinking of his minimalist gaming device which we recently featured.

Turning A Microchip MPLAB Snap Into A UDPI AVR Programmer

The Unified Program and Debug Interface (UPDI) is Microchip’s proprietary interface for programming and on-chip debugging, and has become the standard on AVR MCUs after Microchip’s purchase of Atmel. Being a proprietary interface means that even entry-level programmers like the Atmel-ICE are rather expensive at over $100. That’s when for [Scott W Harden] the question arose of whether the much cheaper MPLAB Snap board (~$34) could be used as well for AVR UDPI purposes.

The stages of grief that [Scott] went through before he had it working involved among others the updating of the MPLAB Snap board firmware, getting yelled at by the Microchip Studio IDE when attempting to use the Snap for AVR MCU programming, and ultimately fixing the board following the relevant Microchip Engineering Technical Note (ETN #36) that specifies the removal of a 4.7 kΩ pull-down resistor (R48) on the Snap board. This allows the UDPI line to be pulled high by the MCU.

As the ETN notes, an external pull-up may also be used to override the pull-down, which would leave the ICSP functionality of of the Snap intact. As [Scott] mentions in his conclusion, it feels as if UDPI AVR support with the Snap is really an afterthought for Microchip. Meanwhile there are also more DIY solutions as [Scott] adds, which are useful for just flashing the MCU. An example is with a USB-TTL serial adapter and pymcuprog.

The problem with DIY solutions like jtag2updi, ftdi2updi, and their kin is the effort required to assemble them, and the uncertainty of long-term support as the UPDI ecosystem keeps evolving with new devices and new features. The MPLAB Snap with resistor mod may be just that middle ground between an Atmel-ICE and reverse-engineered OSS projects.

(Featured image: MPLAB Snap resistor mod illustrated, from Microchip ETN #36)

Squeezing GIFs Into Even Tighter Spaces

Showing images on a TFT or OLED display with a small AVR microcontroller can be a challenge as it requires significant storage space. One solution is to compress the images, but then you need more RAM to decompress it, and that’s a whole other problem. [David Johnson-Davies] of Technoblogy couldn’t find a GIF decoder that fit his needs, so he started writing his own.

We had previously seen a minimal GIF decoder aimed at a Cortex-M0+ that required 24 K of RAM, but this technique is running on an AVR with just 12 K of RAM. Along the way, [David] uses little tricks to shave down the requirements. Since the TFT he targets is a 5-6-5 color space, those 3-byte colors become 2 bytes. The LZW lookup table is encoded as 12-bit pointers to earlier entries plus an additional pixel. However, these savings come at a cost. Animated, local color tables, transparency, interlacing, or GIF87a formatted images aren’t supported. But he ports it over to the PyBadge, which is ATSAMD51 based.

[David] provides some sample code to display a GIF from program memory and an SD card. All the code is on GitHub under a CC By 4.0 license.