this is a short vid showing a binary clock in a 6x6 grid with an analog clock (on the right) showed for reference.
row 1 : blue (seconds)
row 2: red (minutes)
row 3: green (hours … 24hr clock)
row 4: yellow (day of month)
row 5: purple (month)
this is the image file suitable for burning (to a 32GB uSD). it is NOT a flasher.
credentials:
gomer@mercury:/dev/shm$ ls -ltr WS2812B.img.gz ; cksum WS2812B.img.gz
-rw-rw-r-- 1 gomer gomer 1079190350 Dec 17 10:13 WS2812B.img.gz
3636748220 1079190350 WS2812B.img.gz
gomer@mercury:/dev/shm$
debian@WS2812B:~/demo$ cat /etc/dogtag
BeagleBoard.org Debian Image 2018-10-07
debian@WS2812B:~/demo$
user: debian
password: WS2812B
user: root
password: WS2812B
connect P9-25 to data in on device
connect P9-27 to oscilloscope (optional, but interesting for frame rate)
this project uses the same paradigm as my earlier project for the ILI9341 display device: Turnkey PRU deskclock application for BBB
it extends the device (WS2812B) firmware to the pru, and can be controlled by sending simple text instructions in this format:
20ggrrbb – gg = green, rr = red, bb = blue (0x00-0xFF) … color record in force until superseded by subsequent color record
4fssseee – f (flush: 1, dontflush: 0), sss = start pixel, eee = end pixel
sss must be <= eee … coded in HEX (of course)
to flush is to write to device, flush = 0 will only update the cache in pru memory
up to 3K pixels supported (shared memory 12K bytes, 3K words… one word / pixel cache)
the vid shows two 256 pixel panels bought here: Amazon.com … it should work for any neopixel (adafruit) or ws2812b device…
check the ‘demo’ directory for samples, the binary clock can be invoked thusly: debian@WS2812B:~/demo$ ./binaryclock.pl | ncat WS2812B 4200
the hostname is WS2812B and coded into the ‘/etc/hosts’ file as 127.0.0.1 … you can easily change the configuration of the ‘ncat’ daemon to accept instructions from your network.
as I understand the protocol, each pixel takes 30us to ‘render’ (1250 ns per bit x 24 bits). thus it takes ~7.7 ms to ‘render’ 256 pixels. this is constant, so the superior speed of the 200Mhz pru over an arduino does not seem to be useful… unless you don’t connect multiple panels together, but instead use multiple data lines and drive them in parallel (yet undeveloped). If my math is correct, attempting to connect 12 panels ( 12 x 256 = 3k pixels ) would result in no more than 11hz, likely producing significant flicker… not yet demonstrated… check the demo directory for ‘speed.pl’ which on my scope approaches the 120hz limit for one 256 pixel panel.
don’t forget to follow the instructions in the motd for debian user, just create the file in the /root directory, this will load and start PRU0 and the appropriate daemons (DJB cr.yp.to). This file only needs to be created one time, subsequent boots will load and start the PRU automatically.
simplest of smoke tests:
debian@WS2812B:~/demo$ ncat WS2812B 4200
20800000 410FF0FF (turns pixel 255 green)
410f00f0 (turns pixel 240 green)
20800000 400f00ff (pixels 240-255 loaded green in cache, not rendered)
410ff0ff (flushes cache, so 240-255 would turn green)
each ‘render’ costs 30us per pixel on every connected panel, so loading the cache without rendering will result in greater frame rate.
TIP: ‘ncat’ will support multiple streams of instructions, but to the PRU it all looks like one stream of instructions… without frequent ‘color’ records, one stream may unintentionally use the color record of another stream.
TIP: shielding the data line is not necessary, but keeping it short, and away from obvious induction sources will keep it from acting as an antenna and corrupting the data stream.
TIP: don’t forget the level shifter… device needs 5v logic… I have not YET experimented with eliminating the level shifter by using one pixel as the level shifter… might be interesting to try.
please reply with status if:
- you successfully installed and tested
- you found the instructions confusing (like I left something out)
- you had trouble with the image
- you find the paradigm interesting
gomer