| |
In lugnet.robotics.nxt.nxthacking, Dick Swan wrote:
| |
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 8100 array to 8132 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
screenBufferyPosxPos
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 cdisplay.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 cdisplay 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.
|
I already got one shade of grey out of it by flicking between two images at the
current rate:
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 something like
this since the MDP call-up went out.
You can update the screen data faster by messing around with the interrupts, but
you run up against a big problem.
What you’re doing in code is transferring screen data over a serial link to the
single-frame buffer held on the LCD driver chip. You’re not controlling the
display’s pixels directly. The LCD controller then refreshes the physical
screen from that buffer at a rate of around 60Hz or 70Hz. It doesn’t matter how
quickly you actually dump data over the serial link, the display only gets
refreshed at the rate dictated by the LCD controller.
That’s why small matrix ‘passive’ LCD devices (like calculators, the original
Nintendo Game Boy, and the Grapevine PDA on my desk) only have two shades of
grey. They flick between two images as fast as possible, but are able to
control the delay between refreshes slightly so that one of the frames lasts a
little longer than the other, and you get two different shades of grey. They
can’t regulate the brightness of individual pixels like more recent ‘active’
colour LCD displays do (TFTs have a discrete transistor for each pixel).
I’m not sure it’s possible to affect the refresh rate of the actual LCD
controller on the NXT, so one shade of grey may well be its limit. I’ve tried
longer cycles (four frame patterns), but the flicker is too great. This may
improve if I can get the data refresh in synch with the screen refresh, but
that’s a tough one.
Only one shade of grey does have an up-side, but I’m working on that at the
moment.
Jason R
|
|
Message has 2 Replies:
 | | Re: Faster NXT LCD Screen Refresh
|
| (...) Okay, there's a little more to it than this. If you have a display that supports greyscales, it can control the level of the voltage jolt that's applied to each pixel during the actual refresh cycle. That way you get a smoother display with (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
Message is in Reply To:
| | Faster NXT LCD Screen Refresh
|
| 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 (...) (17 years ago, 22-Mar-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
