bitbank

A blog post with details and working code to give you a 'learning remote' (aka any spare remote control you have lying around). It allows you to control any media playback on your Mac or PC from the comfort of your sofa.

A blog post about my desire to restore IR remote control to media playback on the MacBook and how it led me to re-invent the wheel and create the smallest amount of code to decode NEC 32-bit IR codes.

I was testing some sensors on various Linux SBCs and kept having to use i2cdetect. Each time I ran it, I thought that there had to be a friendlier way to get this information...

A blog post showing you how to transition your SIMD code from the ESP32-S3 to the ESP32-P4 (even though Espressif hasn't released the documentation yet)

I just shared a blog post (with Arduino code) for an ESP32 IP camera viewer. The frame rate isn't amazing, but it works. The main limitation holding back the performance is the ESP32's HTTPClient library.

This is a short video of my FastEPD library running on the M5Stack PaperS3. LVGL version 9 is set to 8-bit grayscale mode and I'm converting that to 1-bit graphics to allow fast partial updates of the eink panel. I will be publishing this and more LVGL demos at https://github.com/bitbank2/bb_lvgl

This is a project I've thought about for a while - it allows you to work on your Arduino project in Xcode. This dramatically increases productively and reduces frustration.

The pl_mpeg project is a single .H file MPEG-1 player (video+audio) written in generic C. It wasn't written for speed, but to be a simple working project that can be compiled on any system. I decided to use my experience with code optimization to bring it to 32-bit MCUs. My changes so far have sped it up about 230% (on my Mac M1). The ESP32 and Cortex-M7 are the natural targets because they have enough speed and memory (with PSRAM) to run decent sized videos. MPEG-1 isn't the best video codec, but it's patent-free and simple enough to do in a few thousand lines of C code. It requires a lot more RAM compared to a Motion-JPEG player, but the compressed data is 5 to 10 times smaller and the per-frame effort is much lower. I will publish an Arduino example shortly which will play full speed video+audio on an inexpensive ESP32-S3 PCB.

My latest blog post about my efforts to write my own parallel ink library from a blank slate.

I'm working on a new library to drive parallel e-ink displays (think Kindle). The EPDiy library has done this for the last few years, but it's missing some important features that I wanted to have. My new code is simpler, more efficient, more flexible and includes advanced features such as compressed fonts and graphics, no external dependencies and support for more hardware. More info soon...

I optimize software for a living. It's a hard sell because there's usually resistance to allow me (an outsider) to help with someone else's software. The video of the epaper animation is a good example of how I can help - the code shipped with that product allows for partial updates at 226ms. My code changes got it down to 92ms for that GIF animation (no hardware was harmed). Many products are born from generic library code and data sheet examples without careful consideration to the time it takes the CPU to do certain jobs. It's always an uphill battle to get companies to allow me to help them, but the customers benefit when they do. I'm working on sharing this code and more like it, but I need some support from the community. I share a lot of projects with the community (https://github.com/bitbank2), but need more support to keep doing it.

A short blog post on my new e-paper library which supports a lot of functionality from very constrained environments.

A brief writeup about my idea for a very effective way to losslessly compress bitmap font data for use on microcontrollers.

A short, geeky blog post about the limitations of IMUs connected with I2C.

I just added the ability to decode progressive JPEG files (of any size) down to thunbnail images (1/8th sized) on MCUs with less than 32K of RAM. This is a unique feature because normally you would need enough RAM to hold the entire image as DCT blocks (and potentially the entire decoded image as well). I decode the first scan which normally contains the DC values and maybe a few extra coefficients. This allows generation of 1 pixel per DCT block, thus a 1/8th by 1/8th sized image without needing additional RAM. I can add support for full progressive decoding (even on constrained devices), but would needing additional funding to justify the effort.

Over the years there have been many implementations of the deflate/inflate compression standard. I have been prioritizing speed for most of my projects and over the last few years have also been focused on getting things working on constrained/embedded devices. I set about profiling zlib and found some clever ways to speed it up and reduce its memory footprint. I'm mostly interested in the inflate side of the equation for decompressing gzip and PNG files. By removing the "I can work a byte at a time" feature and optimizing repeated patterns and unaligned accesses. My version runs 50-100% faster than both zlib and miniz on embedded processors (e.g. ESP32). It's down to a single C file of around 700 lines; 6.5K of RAM + the output data size. No external dependencies (not even malloc/file systems). My version forces you to use it as memory-to-memory. This can be quite useful for decoding small blocks of data on small devices (e.g. http requests). What do you think?

I think you're thinking of the ESP32-C3. The S3 does have a fully programmable USB port that can do things like HID, mass storage, etc.

True - load and store mask off the bottom 4 bits of the address. They try to help the situation by including an instruction which can shift a pair of 128-bit registers by bytes.

You need to go back and read it again. I provide links to the relevant Espressif documents and in my next article I provide a simple example to get started. Would you rather have me copy the hundreds of pages of PDF into my blog post instead of providing a link?

A brief look at the problems keeping FOSS "functional" and not "optimal".

I'm changing my Arduino library (JPEGDEC) to be competitive on PCs with libjpeg-turbo. I'm not going to support the libjpeg API, nor every option, but if you need brute force decode speed, mine will be faster :)

I wrote the Arduino library JPEGDEC for microcontrollers, but now I've decided to add SIMD optimizations for desktop processors. Initial testing shows that it's faster than libjpeg-turbo. If fast JPEG decoding is valuable/useful to you and you would like to help beta-test my library as I improve it, please let me know ([email protected]).

A minimal example with ample comments to help you get started writing ESP32-S3 SIMD code.

A short blog post about the latest MCU offerings from WCH.

A short blog post on how to get started with SIMD programming on Espressif's ESP32-S3 MCU.

My latest blog post briefly explains the benefits and liabilities of this rarely used mode of sending serial data to devices like small LCD and OLED displays.

This is a product idea I've been prototyping. In SPI mode, it's a breakout board for the Sharp Memory LCD (160x68, 1.1") with a built-in 50% duty cycle oscillator (needed by the LCD as an external component), and runs at about 55uA. In SSD1306 emulator mode it presents a normaly I2C interface and uses between 1 and 2 mA. Viable product or oddball idea?