Writing directly to image Framebuffer - Spresense SDK

[Cameron R MANN]

I am overlaying data on the camera stream using the NuttX graphics API, and I am running into the basic problem of a flickering graphics overlay. Clearly the NuttX graphics routines are being overwritten by the next video frame, and Spresense can't write fast enough to make this less noticeable. Does anyone know of a good way to access the Spresense framebuffer directly? If I had this level of access I could write my own routines and sidestep NuttX graphics.

I've spent some time with the NuttX graphics manual, and have tried some "sketchy" approaches at modifying the buffer/array directly with some minor success, albeit with doubtful stability. Any ideas out there?

[TE-KarlKomierowski]

Hi @Cameron-R-MANN

I assume that you are using the ILI934x display?
I think that the nx system can write both directly to the display but also through a framebuffer, but I am not sure on how to configure that. I don't want to say too much because at the moment I am not 100% sure of the details.

But one thing that can help you to speed up writes to the display is to enable DMA for the SPI TX, this is done via menuconfig.

CXD56xx Configuration  ---> 
SPI[X ]
DMAC support for SPI[X] TX

And also to increase the SPI frequency, this I do by modifying the file:
sdk/bsp/board/spresense/include/board.h

#define ILI9340_SPI_MAXFREQUENCY    40000000

[Cameron R MANN]

Karl:
Yes I am using the ILI934x (I omitted that detail). From reading the NuttX docs I also had the "impression" I could write to the display directly or via a framebuffer, but there didn't seem to be much detail / use examples.

I have not examined/used the DMA options, nor adjusted the SPI frequency - I will definitely try those out...thanks for the tip!

Side Note: Presently I am modifying the "image" array/buffer in the camera_bkgd.c source file (found in line 234):
https://github.com/sonydevworld/spresense/blob/master/examples/camera/camera_bkgd.c

I've been able to increment the address and write 0xFFFF to several locations, drawing a white line across the screen. As I expected, the line itself does not flicker when overlaid across the camera stream, while my NuttX graphic primitive continues to "flicker" (redrawn). I would say it is good progress, but I was uncertain if this is the "correct" approach to my problem. I will continue to investigate the usability/stability of this method.....

[TE-KarlKomierowski]

@Cameron-R-MANN

I've been able to increment the address and write 0xFFFF to several locations, drawing a white line across the screen. As I expected, the line itself does not flicker when overlaid across the camera stream, while my NuttX graphic primitive continues to "flicker" (redrawn). I would say it is good progress, but I was uncertain if this is the "correct" approach to my problem. I will continue to investigate the usability/stability of this method.....

A good approach would be to use the NX graphic functions to write directly to the camera stream buffer before it is pushed to the display. I guess that there are people with Nuttx nx experience that have a good answer to on how to setup a framebuffer with NX. I would really like to use it my self since it is very slow to write every line/or text directly to the display.

If you figure this one out, I would really appreciate if you could update this thread with that info! It would be nice to use the present NX functions in Nuttx instead of writing custom graphic functions.

[Cameron R MANN]

@TE-KarlKomierowski
I enabled the DMA option as you suggested, but I did not notice any change to the severity of the flickering. I also checked ILI9340_SPI_MAXFREQUENCY and it was set to 40000000 just as your example.

I agree regarding the NX graphics + framebuffer usage. No sense in re-inventing the wheel. Now that I have discovered a "hook" into the framebuffer, the NX documentation might make a little more sense. I will revisit and research a bit more.

I will definitely keep this thread updated...I also think it is an important dev topic and worth digging into. Stay tuned!