nanogui: Thread: qn. on offscreen mem. transfer / h.w. integration

Hi All,

I'm using Nano-X 0.91 on a custom ARM system using uCLinux.  On this 
particular system the CPU communicates with
a separate LCD controller via a fast shared serial line.  The LCD 
controller has it's own onboard memory for storing pixel
data.  I created a custom Nano-X driver for this LCD based on one of the 
samples in the distribution.
My question is where is the optimal place in the code for transferring 
data from the CPU's memory buffer (storing
an image of what is to be sent to the LCD) to the LCD controller itself?

Originally I had each of the low level driver routines such as 
LCD_drawpixel(), LCD_drawvline() etc. send
out the data to the LCD controller on each call.  This did work but was 
quite slow for high level routines such as text and bitmap
rendering as the LCD must be setup with col & page registers before you 
send down the pixel data.

My next optimization was to not perform any writes to the LCD in the low 
level driver pixel/line routines, but have
those routines instead just set bits on an offscreen memory buffer in 
the CPU's address space.  I then hacked in an extra "Flush"
command into the driver which transfers the data in the offscreen buffer 
to the LCD's memory in one single
block of writes.

This technique works OK, except I had to hack in calls to the new Flush 
command into the higher level Gd
functions such as GdText() and GdDrawImage().  This is starting to get 
too hacky for my liking.

Can anyone suggest a better method of efficiently getting the pixel data 
to the LCD in a h.w. configuration like mine?

Thanks,
Sean
BTW : Good work Greg & others on Nano-X, we like it a lot here.

>This technique works OK, except I had to hack in calls to the new Flush 
>command into the higher level Gd
>functions such as GdText() and GdDrawImage().  This is starting to get 
>too hacky for my liking.
>
>Can anyone suggest a better method of efficiently getting the pixel data 
>to the LCD in a h.w. configuration like mine?

You could use two buffers, one that Nano-X draws into, and the other
being a shadow of what the LCD displays.  Then on a timer, you can see what's
different between Nano-X's buffer and the LCD shadow, and send the
differences to the LCD as well as copy them to the shadow...

Then you can use the interval to control how often you update the LCD.

-- 
Peter Barada
####@####.####