Hi Greg,
Thanks for the replies. Comments embedded;
What is the interface to the ePaper device? Is it through a serial
interface? Or a framebuffer interface?
The interface is over SPI. It 'looks like' a normal lcd supported by
lcd_dev_s. The particular one I have is write-only, but read/write ones
exist too.
What do you might by NXGL? It is library of simply drawing helpers.
I take it you are not using NX, the full graphics system. It would
update automatically and we would not be having this discussion.
It's worth explaining a little bit more about how these devices work,
then it'll be clearer, I hope.
They have a display RAM just like an SPI or I2C interfaced LCD does. You
write to it in the same way using similar commands. The difference is
that the display RAM _does _not_ automatically get transferred onto the
screen. That has to be done by a separate operation which, depending on
the device in question, can take up to 15 seconds or so.
NXGL offers a nice set of drawing primitives which remain applicable to
these displays. There is no difference to NXGL or the way that it is
used, and no code in NXGL is changed to allow it to work with ePaper.
Unfortunately, nothing changes on the screen until the send-to-screen
(redraw) command is issued.
Since you are redrawing something that was not drawn by NX, it must be
something that you drew in your application? True? Are you using a
software framebuffer?
It was drawn by NX, it just didn't make it to the screen yet.
The correct way to implement a software framebuffer driver for a
serial graphics device is via drivers/lcd/lcd_framebuffer.c. That
driver will allocate the software framebuffer and export a standard
NuttX framebuffer driver interface. The framebuffer driver at
drivers/video/fb.c will expose the framebuffer driver to the
application. From the framebuffer driver you can use the FIOC_MMAP
IOCTL command to get the address of the framebuffer. You would need
enable CONFIG_LCD_UPDATE, then you can use FBIO_UPDATE command to
force the software software framebuffer to be written to the serial
hardware.
A framebuffer isn't needed, as there is already one on the device.
However, what I need to do is directly equivalent to FBIO_UPDATE.
Normally FBIO_UPDATE works from NuttX RAM to the LCD (and automatically
onto the display), I want to go from the ePaper RAM to the display.
Using the framebuffer wouldn't help me as I'd still need to perform the
redraw operation to get the stuff onto the actual display after sending
the FBIO_UPDATE.
Now, that sounds like you are using NX. NX will automatically update
the display.
I cannot imagine a situation where that would be necessary. Let's talk
more before you waste your time. I would have to understand what you
are really doing to be able to help you.
NX _thinks_ it's updated the display and indeed, in the normal scheme of
things (with an LCD), it would have. Unfortunately, for this class of
displays, this second step to sync the display ram to the display itself
is needed.
I've just read through the other notes you've sent. To avoid fragmenting
my reply;
*) It's an ePaper electrophoretic display which is bi-stable - whatever
is on the display will stay there, even without power. That means
transferring the contents of the display frame memory to the display is
a second step operation which takes a while to happen.
*) I can use nxgl to write to it no problem. As far as nxgl is
concerned it looks just like an ILI9341 or similar (different command
set, but the same principles). The problem is that what is written to it
does not end up on the display until a separate, time consuming, redraw
command is issued. While the redraw is going on the display is away with
the faries and will not communicate at all. That isn't a problem for us
as new drawing commands will just back up in the NXGL MQ until it
becomes available again.
*) There is no modification needed to any existing nxgl or other code
for this to work...it's a simple extension to add this redraw
command...but I need to be comfortable that I've put it in the right
place, hence why I'm asking for input. It means that some practical
details of the implementation of the display technology are 'leaking' up
into the graphics abstraction, but I don't really see a way to avoid it.
Only the application knows when it's permissible to take an extended
time to perform an update.
Regards
DAVE
