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.
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.
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?
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?
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]).