A fast-enough bitbanged HUB75 driver on an ESP32
125 FPS on 6-bit images and 250FPS on 5-bit images.
out.mp4
The image format I came up with is having the pixel for both rows packed into the same byte: [r1_g1b1r2_g2b2] where _ are two ignored bits.
The ignored byte is cleverly placed in that position to reduce the amount of bit-shifting necessary, and it constrains the relationship between usable pins.
At 64x32, each RGB image takes 1KiB per bit of depth -- a 6-bit-depth image uses 6KiB. Overhead is 25% (6/8 bits are used).
The screens are 16bit -- RGB565 so going beyond 6 bit depth doesn't make sense.
As these panels are RGB111, displaying more than 1-bit color can be done by iteratively displaying each bit of the depth. The images are composed of "frames" which use BCM to show higher color depth.
Each 'frame' can be rendered by bit-banging the protocol in ~120us; but that has to be done 2bit-depth times (6 => 26 => 64) which makes each full frame take ~7.9ms.
Clock runs at 9.4MHz and that's probably the upper limit.
At this speed, it's reasonable to run 2 screens on 6-bit depth, or up to 4 on 5-bit depth.
- Only pins 0..=31 can be used for ADDR and DATA; as they are part of the port 0 and can be changed in 1 write
- This is a software implementation - each 6-bit frame takes 7.9ms to render and it must be called roughly once every 20ms to have no flicker.
- ~Half of one core will be consumed by this
- Using 5 bit color will bring it down to ~4ms, making it 25% of one core
- The relationship between the used pins is constrained as an optimization
- You need to use 3 ~contiguous pins (at most a gap of 1; for me: 4, 5, 6) for R1G1B1
- You need to use 3 ~contiguous pins (at most a gap of 1; for me: 18, 19, 21) for R2G2B2
- You need to use 4 contiguous pins (for me: 12, 13, 14, 15) for ABCD
There's a script (script.py) which can convert a set of 64x32 PNG files into a binary file in the right format for the ESP32.
You can include_bytes! the file later.