Larry the optimizer

ish? Anything below 20C is too cold 😜

How about "The design error that condemned Linux GPIO to poor performance - treating it like a file to be placed somewhere in /dev"

Take a look in my bb_spi_lcd library in linux_io.inl. You'll see the GPIO direct access code which detects RPI 1/2/Zero/3/4 and adjusts things accordingly. No support for RPI5 since they changed the rules and hid the GPIO registers behind another chip :(

If you can run as sudo or mark the executable as root you can just directly manipulate the GPIO MMIO registers (not affected by currently loaded kernel drivers). I have code to do that too 😀. I wrote code to drive 8-bit parallel and QSPI displays like that.

I created one which uses GPIOD and runs on nearly any Linux SBC. It's currently in a private repo, but if you're interested, I'll send it to you.

This is made possible by creating custom LUTs (look up tables) for the update. By pushing mostly towards a single color and then doing a small push back for the grays, you can get 2-bit mode without all of the flashing.

YouTube video by tdfsoftware Fast 4-gray LUT for SSD1677 EPDs

Fast 2-bit (4 gray level) updates are now available in my bb_epaper library for both SSD16xx and UC81xx panels. I'll be adding/testing them slowly across devices:
youtu.be/JD3HbJ2l6xk

youtu.be/zDrvb8IJgks

PCB silkscreen

PCB 3D preview

1st product prototype with aluminum enclosure

New sensoria C5 PCB sent to fabrication today
Thanks to @fast-code-r-us.bsky.social for reviewing my schematics. This is the hardware sensor and reports visualiser from sensoria.cat projectPC

New release for mid February: 1.1 version of #Raspberry Pi (Zero2W and 4 versions) parallel Epaper monitor, great for monitoring of displaying your sensors information. Framerate around 12 frames per second. Designed in team with @fast-code-r-us.bsky.social
Anyone interested? Please RT & comment

This tiny pocket-friendly e-reader is packed with frustration and potential The Xteink X4 is small enough to slip into a shirt pocket.

This tiny pocket-friendly e-reader is packed with frustration and potential

New product taking shape - a #RaspberryPi AMOLED display HAT. It works on RPI Zero/1/2/3/4. Hi-res, super saturated colors and wide viewing angles. This one is 460x460 with capacitive touch. Excellent for gaming too (it's fast). Who's interested?

Palette settings are just coming online now. I'm implementing 3/4/6-color support too. All will work correctly soon...

True - late 70's was when LED watches started appearing. The first few home computers and electronic calculators/clocks became more prevalent soon after. The bulk of digital devices started appearing in the early 80s. My father and I built a Heathkit TV around that time too.

It can be either. You can choose the palette on the web portal.

YouTube video by tdfsoftware Fast Eink solution

You can also harvest the display and drive it with an ESP32 or Raspberry Pi:

youtu.be/3Aufe0aCyuU

blink twice if you're in need of help

New KiCad project shared to Github - my RPI to UNO LCD shield HAT. Allows use of high speed parallel (and cheap) LCDs.

github.com/bitbank2/RPI...

Why not both?😜

🤚

YouTube video by tdfsoftware RPI02W emulated games running direct to LCD (no fbcp)

I got inspired today to write some Arm NEON SIMD code. This allows fast 150% stretching (with pixel averaging) of emulated games on the RPI 02W. No need for fbcp or devicetree drivers for the LCD - this is my GBC emu using bb_spi_lcd to draw directly on the ST7789 SPI LCD.
youtu.be/eqq6glU0Sl0

LCDs & C++ & Linux = Beginner-Friendly? Intro There are many reasons to choose a programming language and environment for your projects and products. C++ has gotten a reputation fo...

New blog post for the new year:

bitbanksoftware.blogspot.com/2026/01/lcds...

That's easy for the compiler when the loop count is a constant. A trick to make it work on variable length arrays is to make an inner loop of a constant size:

In other words - recursion is a completely unnecessary way to write code that has been used as a form of mental torture for poor innocent CS students? 😜

GitHub - bitbank2/rpi_gif_hat: An example project showing how to play animated GIF images on "HAT" LCDs An example project showing how to play animated GIF images on "HAT" LCDs - bitbank2/rpi_gif_hat

I just shared a new C++ example project which allows you to easily flip through a series of GIF animations and display them on a Raspberry Pi "HAT" LCD:
github.com/bitbank2/rpi...

Video demo:
youtu.be/m-PzmW8scac

Well - keeping it behaving this way helped pay my salary for a while :)
I fixed this for a few clients with my kludge/workaround.

That's not a fix :(
The compiler should see that multiple accesses to the same member var should be held in register (conditional or not) and write them back when the function or loop is finished.

I'm glad I'm not the only person stumped by this behavior. My way of fixing it is a kludge - explicitly use local vars to do the work. I think this is related to "MT" - the compiler assumes everyone is using multiple threads and therefore all member vars must be kept up to date.

Here's an example using your compiler explorer:

godbolt.org#g:!((g:!((g:...

It's the default behavior and I don't see a way to stop it. It hurts performance on a large % of C++ projects because passing objects by pointer is very common practice.

Good that you brought this up. Passing a structure pointer is good, until it isn't. The compiler treats the member variables as volatile. Is there an easy way to tell it not to do that? e.g. a function furiously modifies a member var and reads/modifies/writes it back every time ☹️