facotl gravatar image

Posted 2016-02-15 21:34:54 +0100

blogs->all

Proof that the nRF52832 is a beast of computation power

Here is a demo of a small graphics engine I designed that allows me to embark moving pictures on a nRF52832 directly in code with a reasonable occupied memory size (i can do RLE or LZ4 compression).

The screen Newhaven Display (NHD-C12864A1Z-FSRGB-FBW-HT1) which is given for 3 to 4 FPS is here pushed to its limits with some tricks to 8 FPS. The nRF52832 is cool here, for animations i can run up to 100 FPS depending on complexity but the screen cannot follow the cadence (because pixel commutation time is too long and contrast become to weak).

The video is here: http://fabiencomte.tumblr.com/post/139358255959/voici-une-d%C3%A9mo-dun-petit-moteur-graphique-que

9 comments

luisOn gravatar image

Posted Feb. 16, 2016, 10 a.m.

Nice! Would be great to see what is achievable with a higher refresh speed screen. :)

wtbn gravatar image

Posted Feb. 16, 2016, 6:32 p.m.

Nice! Sad that display limited real framerate, but good to see that anyway.

facotl gravatar image

Posted Feb. 17, 2016, 11:34 a.m.

I checked that I can prepare / transfert a lot of FPS (with Saleae Logic analyser) but pixels are so light grey that it's not acceptable for a confortable human read.

But in my case I will use the display for a portable device with a low FPS target (4) and it's not a problem. The screen is transflective and that's useful, you can read it outside (with sun) and consumption is quite low (if you not activate RGB backlight or heating for sure). On the demo video, partial green backlight was activated. Without backlight it's very 90's Nintendo Gameboy style.

wilhelmsen gravatar image

Posted Feb. 20, 2016, 8:16 a.m.

@fabien, Really cool work! Do you have any source available for this?

facotl gravatar image

Posted Feb. 21, 2016, 8:45 p.m.

Hello,

I cannot provide any source because this is the property of my client but i found that during my pre research (https://github.com/olikraus/u8glib). I have not used it because I have written a special graphics lib that minimise SPI transferts to minimum to maximum avoid radio perturbations for GPS*.

*: fun fact, I did some tests. Average bytes count exchanged to update image pass from more than 1 Kbytes to 35 bytes (I just send deltas) !!! On GPS cold start for difficults conditions (indoor), first fix is up to 2 times faster (mean on multiple tries) when I activate minimisation in my lib.

wilhelmsen gravatar image

Posted Feb. 22, 2016, 9:22 a.m.

Nice :)

Anders Strand gravatar image

Posted Feb. 22, 2016, 11:13 a.m.

Cool stuff! What resolution is the screen, and how much memory is used for storing and processing the image?

facotl gravatar image

Posted Feb. 29, 2016, 9:52 p.m.

Screen is 128 x 64 monochrome => 8192 bits => 1024 bytes

I use a double buffer so about 2 x 1024 bytes + 1024 bytes as decompression work buffer + few more bytes.

So say less than 4 Kbytes RAM.

Cat animation is 35.7 Kbytes uncompressed and 21.1 Kbytes after custom compression.

facotl gravatar image

Posted March 19, 2016, 10:02 p.m.

Here is the final prototype board :-) Sub meter vertical displacements catched by GPS. http://fabiencomte.tumblr.com/post/140811118863/voir-des-mouvements-verticaux-relatifs-inférieurs

Sign in to comment.