| |
Here's a trick to get a faster rate on the LCD display refresh.
It currently takes 16 milliseconds to refresh the NXT LCD. 16
"messages" are sent to the LCD. One message is sent per millisecond.
There are two messages from the ARM to the LCD for each of the eight
horizontal stripes; one message sets up the starting address to the
first column of the stripe and the second message transmits the 100
bytes of the stripe.
I wanted to see if it was possible to generate multiple shades of gray
wihtout flicker by rapidly redrawing slightly different images. For
example, either display a bit or text string or display a blank region
in the same place. [Credit to Guy? for inspiring this activity]. By
changing the duty cycle of the display/erase you should be able to get
shades of gray. This seemed to work quite well except the "brightness"
scale and duty cycle are not linear.
I wanted to increase the LCD refresh rate to maximum possible to
increase the number of gray shades. For example, 10 shades of gray
requires 160 milliseconds to properly paint with the 16 millisecond
refresh.
The first thing I tried was takingadvantage of the LCD's controller
cpability to wrap from one stripe to another if you send it more than
100 bytes of data. I wanted to use a single message to send all 800
bytes of the LCD pixel map. This sort of worked. It turns out the LCD
display chip supports screens up to 132 pixels wide. The NXT only uses
the first 100 pixels.I wanted the wraparound at addresses modulo 100
and instead it was occuring at modulo 132.
This proved relatively easy to fix. I changed the pixel map definition
from a [8][100] array to [8][132] array. Only elements 0..99 will be
used. Elements 100..131 are unused. In an ideal world this would be
all that was required. Except that there's several places in the NXT
source code where pixels are referenced as
((UBYTE *) &screenBuffer)[xPos + 100*yPos]
The "screenBuffer' is being 'cast' as a UBYTE pointer and then the
reference is the byte offset from this pointer. I changed these
references to
screenBuffer[yPos][xPos]
and everything works fine. With this change it's easy to swap between
reserving '100' bytes or '132' bytes per row -- it's a single change
for complete firmware source.
With this change, the refresh is now two messages. One to set up the
initial address. And one to transmit the 8x132 bytes. Each message is
sent on a 1-msec tick basis. The first takes a small fraction of a
millisecond. The second takes 5 milliseconds or so -- a 2MHz baud rate
is used. So screen refresh is now 5 or 6 milliseconds.
Anyone exploring this furthur may want to note there is also a flag in
the c_display.iom to turn display refresh on/off. You could use this
flag to ensure there was absolutely no screen flicker due to
background LCD redrawing in the c_display module.
There's really no additional CPU real-time overhead for the faster
refresh. The actual transmission of the screen buffer is done by DMA.
RAM memory access is running at 48 MHz, so "stealing"~1000 of these
cycles for the DMA every 5 milliseconds is 0.4%. And I didn't read the
specs in detail, but it might be as small as 0.1% if the DMA operates
on 32-bit words and not 8-bit bytes.
The faster screen refresh will be in the next version of RobotC.
Individual drawing functions in RobotC (text line draw, fill/erase
rectangle, etc) almost all take under 100 microseconds to operate. So
it would be easy to experiment with this via a simple RobotC program.
You can do a lot of things in 5 milliseconds! If interested in
exploring, send me a email and I'll ensure you get early access to the
next version.
|
|
Message has 3 Replies:
 | | Re: Faster NXT LCD Screen Refresh
|
| (...) I already got one shade of grey out of it by flicking between two images at the current rate: (URL) I use all those spare cycles to mix and merge screen layers in real time, so this image has full parallax scrolling. I've been trying to do (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
| | | Re: Faster NXT LCD Screen Refresh
|
| (...) <snip> (...) This is really interesting. If I understand correctly, to get colors, or at least shades of grey, you have to refresh the screen quickly and the "darker" the pixel, the more often it shows up in the pattern. For example, let's say (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
| | | Re: Faster NXT LCD Screen Refresh
|
| (...) Could you be a little more specific regarding the changes you made to this method: UBYTE DisplayUpdate(UWORD Height,UWORD Width,UBYTE *pImage) { static UWORD State = 0; static UWORD Line; if (State == 0) { if (DisplayWrite(CMD,(U...itString)) (...) (18 years ago, 4-Apr-07, to lugnet.robotics.nxt.nxthacking)
|
8 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
