Thanks. I understand better now.
This is very specific to this hardware. I don't think this should
involve the graphics system in such a device-specific way since this is
a hardware interfacing issue that has nothing to with graphics other
than a graphics device is involved. There are easy hacks or complex
architectural changes to accomplish what you want to do.
For easy hacks, I would suggest a minimal, trivial device driver that
just supports the the FBIO_UPDATE command (and any other command unique
to the hardware). This driver would have to lie in the board-specific
logic or else have an SPI interface passed to it during initialization.
Or maybe a boardctl(BOARDIOC_IOCTL) command.
If you wanted to support a graphics driver interface via NX, that is
okay too. But we would have to do that right, that is, in a
device-independent, platform-independent, general way.
A better functional partitioning would be to have this hardware-specific
functionality implemented inside of the LCD driver, rather than in some
hack character driver or BOARDIOC_IOCTL. There is, however, no LCD
driver interface exposed to the application; the LCD driver interface is
only available to NX. I suppose it would be possible to add to an
ioctl() method to every LCD (or FB) driver and and nx_ioctl() method to
communicate and device-specific commands with the driver. But that
would be a pretty big effort (but a worthwhile contribution). I would
help on that one; the other, simpler ideas are basically hacks that
could give you the functionality you need. A generic graphics hardware
IOCTL command would besystematic and general and common to all graphics
devices.
Greg
On 12/17/2019 7:44 AM, Dave Marples wrote:
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
