Larry Bank Is Laying Out the Libraries We All Love to Lament!

For some of us, it may seem that the Arduino aurora is simply irresistible — the pull of a tiny AVR/PIC or the temptation of the all powerful Teensy 4.x can be too much to ignore!

With a single microprocessor board from one of many choices available — it seems that any of us can sit down at our IDE of choice and churn out the next hottest product on GroupGets.

The thing is, look around — I know that at first pick, there are far many more suitable job descriptions that I could choose to describe my talents than "software engineer" — and I have a hunkering suspicion that the same would apply to the majority of the people we know poking and playing around with Arduinos.

Serial.println('The maker scene is so lucky!');

We see the next generation getting to grips with things so quickly as there is a huge, huge existing contribution to the community from the previous contenders, leaving in their wake the abundance of software and litany of libraries they have written apropos that so easily abstract the somewhat monumental undertaking of streaming a serial prompt from a sliver of silicon.

And unlike the slews of short-handed, sometimes snarky snippets of "help" that can be found on places like StackOverflow — the libraries we find ourselves starring on GitHub are thankfully, much more often adorned with comments, and written with some sense of sanity!

From AnimatedGIFs to unzipLIB!

One man who had made it his mission to make more quality code available to the masses is Larry Bank.

We've covered some of his contributions before over here in the halls of Hackster — starting with the gloriously smooth AnimatedGIF library, showing off the Hackster livery below!

Bringing some pretty powerful pixel pushing to your supported processor platform of choice, AnimatedGIF is the perfect way to polish up your next project's GUI, with a proudly presented GIF to push things off to the right start. `

JPEGDEC, TIFF_G4 and PNGdec

With the showy aside, it might be time to turn an eye to tuning your next project for performance!

Bank has a primary focus in his work, and that is very much just that — performance. With an intimate eye on the internal workings of the target device, and a want to wrangle the most out of every clock cycle — he wants your application to work smarter, not harder — with benefits that impact far beyond boot time.

While there have been ways to show image data on the Arduino et al. platforms for quite some time, few of them have been as finessed as the JPEGDEC,TIFF_G4 and (new) PNGdec libraries that Bank has published.

JPEGDEC was born out of ancient (>25 years old) code that Bank had left collecting dust on his hard drive. He used to write imaging codecs for his own document imaging product and had kept everything trade secret up until recently. Starting last summer he decided that it would be much more useful to have his old code take on a new life in the open source community. He set out to not only release the old code, but turn it into something unique for embedded devices. There’s a method to his madness — he painstakingly removes all use of malloc, free, fopen, fread, etc. from the code so that it can be compiled on any CPU without an operating system or even C-runtime support. This is the main stumbling block when trying to use “big” computer libraries on embedded devices — their dependency on system calls and heap management.

JPEGDEC...

• Supports any MCU with at least 20K of RAM (Cortex-M0+ is the simplest I've tested).
• Optimized for speed; the main limitation will be how fast you can copy the pixels to the display. You can use DMA assisted SPI to help.
• Supports decoding all baseline JPEG images.
• Optionally read the EXIF thumbnail from photos.
• Built-in fast scaling by ½, ¼, and ⅛.
• Optimized to generate RGB565 output for low cost LCDs.
• JPEG image data can come from memory (flash/RAM), SD card or any media you provide.

And what is more, it does all this in a hugely optimized fashion — it's very fast! Check those times in the table below! The code was originally optimized for low end PCs and those same improvements help it run so well on MCUs.

It is of no surprise, to see the Teensy 4 with it's Cortex-M7, clocked at 600 MHz absolutely stealing the first place in the table above, which shows various times for the JPEGDEC decode functions.

What is perhaps surprising to see is a row showing the times taken for the functions to run on a Cortex-M0+ — with it's lowly 48MHz clock still showing some usable times from the profiling.

And of PNGdec?

With a similarly impressive spec sheet, a few of which are listed below, PNGdec aims to bring PNG file decoding to the microcontroller masses, by making light work of the underlying bit magic, and providing some handy functions that target portable contexts...

With support already shown above for the RP2040 MCU — one of the few you might actually be able to source at the moment! — we can see that Bank is focused on providing support to the maker masses!

• Runs on any MCU with at least 48K of free RAM.
• No external dependencies (including malloc/free).
• Decode an image line by line with a callback function.
• Decode an image to a user supplied buffer (no callback needed).
• Arduino-style C++ library class with simple API.

Zoom through zipped archives!

With GIFs, JPEGs, TIFFs and PNGs all now in the arsenal for projects, things like memory might soon be of concern for coded applications.

While any of these formats will offer memory savings over the bitmaps that we'd bundle onto our boards in the old days, one might get carried away with all this new found functionality.

With the ability to drop a fly GIF, or pop a PNG anywhere you wish — you may want to figure out a way to fit more files onto your flash storage.

unzipLIB provides the ability to un-compress ZIP archives in an embedded context. Again, with some targeted design choices, this library is really tailored to the embedded tinkerer.

• Runs on any MCU with at least 41K of free RAM.
• No external dependencies (including malloc/free, file system calls).
• unzip API implemented in C and C++.
• ZIP files can come from RAM, flash, SD card or any media by using callbacks.
• Decompress files by reading any sized chunk at a time (full sized buffer not needed).

That last feature stands out to me, meaning that this code would sit nicely in a time-slotted / RToS configuration, rather than needing to sit in a loop, spinning until it returns from what could perhaps be a lengthy operation.

Want to bet what's next for Bank?

We often find asking the community what features or functions they might want from future code developments.

Over on Twitter, Larry (the_perf_guy) runs a lively ship, either working on the next lightning fast library for the community to build upon, or seeking feedback on what they should set their sights on next!

We suggest giving him a follow over there, and most certainly adding Bitbank2 to your followed GitHub user accounts! And if you want to support his work, you can sponsor him on GitHub.