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.

To Turn An ATtiny817 Into A 150MHz Counter, First Throw Out The Spec Sheet

One generally reads a data sheet in one of two ways. The first is to take every spec at face value, figuring that the engineers have taken everything into account and presented each number as the absolute limit that will prevent the Magic Smoke from escaping. The other way is to throw out the data sheet and just try whatever you want, figuring that the engineers played it as safely as possible.

The latter case seems to have been the motivation behind pushing an ATtiny way, WAY beyond what the spec sheet says is possible. According to [SM6VFZ], the specs on the ATtiny817 show that the 12-bit timer/counter D (TCD) should be limited to a measly 32 MHz maximum frequency, above which one is supposed to employ the counter’s internal prescaler. But by using a 10-MHz precision frequency generator as an external clock, [SM6VFZ] found that inputs up to slightly above 151 MHz were countable with 1-Hz precision. Above that point, things started to drift, but that’s still pretty great performance from something cobbled together on an eval board in a decidedly suboptimal way.

We’d imagine this result could lead to some interesting projects, since the undocumented limit for this timer puts it well within range of multiple amateur radio allocations. Even if it doesn’t prove useful, that’s OK — just seeing how far things can be pushed is cool too. And it’s not like this is the first time we’ve caught [SM6VFZ] persuading an ATtiny to do unusual things, either.

KittyOS: Writing A Toy OS For The ATmega168 From Scratch

Writing an operating system for a computing platform is one of those non-trivial tasks few people actually need to do, regardless of whether it’s for a small microcontroller or a larger general-purpose computer. Many of us spend a large amount of our time working on producing robust code for embedded systems, occasionally diving deeper into the abstraction when we’re stuck on a problem. Quite often this work is sitting on top of an RTOS, which we consider a solved problem. [Jonathan Diamond] had picked up a fair bit of knowledge of some of the low-level AVR black magic, as well as some details of how operating systems work internally, and so decided to have a crack a building a toy operating system called KittyOS, for the learning experience alone.

[Jonathan] hastens to add that this is not a practical OS, but a learning platform that needs a few more bells and whistles added to be useful. Aimed at the 8-bit AVR ATmega168 with its mere 16kB of flash and 1kB of SRAM, the diminutive chip can still perform more than well enough to host the rudimentary OS — up to four application tasks, and some basic system call support.

Already, KittyOS sports preemptive multitasking, with prioritization and support for applications written in C. Hardware support is a bit limited, with just serial I/O and a spot of GPIO, but that’s more than enough for a demonstrator. Applications can be loaded into any of the four available slots, with per-slot run state control, using the Python-based host interface. The post is a long one, with an absolute ton of the gory details we love around these parts, and we’re very glad [Jonathan] took the time to make a proper write-up as well as a demonstration video, which can be found after the break.

Continue reading “KittyOS: Writing A Toy OS For The ATmega168 From Scratch”

Blinking An Arduino LED, In Julia

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!