Christian:
Thanks for the link. I'll take a look at the code ... it seems
straight-forward enough that I
should be able to make sense of it as is. :-) I've noticed that you are
setting levels of gray or
something similar. What LCD were you using, if you don't mind me asking?
I'd love to find
something that supports a few shades of gray without breaking the bank, if
possible. It
would allow very basic anti-aliasing, for example, without all the headaches of
a full color
LCD.
Kevin.
Setting Pixels for ST7920 based 128x64 LCD
Started by ●November 24, 2008
Reply by ●November 26, 20082008-11-26
Reply by ●November 26, 20082008-11-26
Thanks to everyone's help here, I now have the screen acting like I
expected, and can set all
the pixels. I'm a bit turned off by the performance, though. I've made some efforts to
minimise all the required delays, etc., but it is impossible to have instant-seeming screen
refreshes on an lpc2148 or similar device? I can put everything in a memory map and then
write it all at once (16-bit row by row), but I'm still seeing the scren visible 'scroll down' as I
draw on the screen, taking maybe 1/2s to draw the whole screen.
Any idea how I might be able to most efficiently fill the screen with black pixels, for example,
without the user seeing the pixels scroll down the screen?
the pixels. I'm a bit turned off by the performance, though. I've made some efforts to
minimise all the required delays, etc., but it is impossible to have instant-seeming screen
refreshes on an lpc2148 or similar device? I can put everything in a memory map and then
write it all at once (16-bit row by row), but I'm still seeing the scren visible 'scroll down' as I
draw on the screen, taking maybe 1/2s to draw the whole screen.
Any idea how I might be able to most efficiently fill the screen with black pixels, for example,
without the user seeing the pixels scroll down the screen?
Reply by ●November 26, 20082008-11-26
Am Mittwoch, 26. November 2008 schrieb Kevin Townsend:
> Christian:
>
> Thanks for the link. I'll take a look at the code ... it seems
> straight-forward enough that I should be able to make sense of it as is.
> :-) I've noticed that you are setting levels of gray or something similar.
> What LCD were you using, if you don't mind me asking? I'd love to find
> something that supports a few shades of gray without breaking the bank, if
> possible. It would allow very basic anti-aliasing, for example, without
> all the headaches of a full color LCD.
>
> Kevin.
Hi Kevin,
while i dont know what the exact display is, it is a 128x160 pixel display
using the SSD1854 controller. It is capable of 4 gray levels. To be true,
there is not much gain using "anti-aliasing" on a 2bpp display. After all you
end up only having white, light-gray, dark-gray and black as "colours".
The whole remote control i talked about was a for some kind of interactive-tv
system they had in germany for a while. Never used it as intended, instead it
makes a nice platform to get used to the LPC's. And it made a fun project to
hack that thing ;) It has flash, lcd, sound, buttons, a cc1100 rf
transceiver, infrared, etc....
Greetings,
Chris
> Christian:
>
> Thanks for the link. I'll take a look at the code ... it seems
> straight-forward enough that I should be able to make sense of it as is.
> :-) I've noticed that you are setting levels of gray or something similar.
> What LCD were you using, if you don't mind me asking? I'd love to find
> something that supports a few shades of gray without breaking the bank, if
> possible. It would allow very basic anti-aliasing, for example, without
> all the headaches of a full color LCD.
>
> Kevin.
Hi Kevin,
while i dont know what the exact display is, it is a 128x160 pixel display
using the SSD1854 controller. It is capable of 4 gray levels. To be true,
there is not much gain using "anti-aliasing" on a 2bpp display. After all you
end up only having white, light-gray, dark-gray and black as "colours".
The whole remote control i talked about was a for some kind of interactive-tv
system they had in germany for a while. Never used it as intended, instead it
makes a nice platform to get used to the LPC's. And it made a fun project to
hack that thing ;) It has flash, lcd, sound, buttons, a cc1100 rf
transceiver, infrared, etc....
Greetings,
Chris
Reply by ●November 26, 20082008-11-26
Am Mittwoch, 26. November 2008 schrieb Kevin Townsend:
> Thanks to everyone's help here, I now have the screen acting like I
> expected, and can set all the pixels. I'm a bit turned off by the
> performance, though. I've made some efforts to minimise all the required
> delays, etc., but it is impossible to have instant-seeming screen refreshes
> on an lpc2148 or similar device? I can put everything in a memory map and
> then write it all at once (16-bit row by row), but I'm still seeing the
> scren visible 'scroll down' as I draw on the screen, taking maybe 1/2s to
> draw the whole screen.
>
> Any idea how I might be able to most efficiently fill the screen with black
> pixels, for example, without the user seeing the pixels scroll down the
> screen?
Hi Kevin,
there are serveral things you can do to speed up things.
First, dont expect to use it like a regular, generic computer graphics thing.
There are many things you can optimize, but you have to trade off
some "genericness" then.
First, use a small local buffer, much smaller than the whole display. Like, a
complete line or two. Do all drawing on that buffer, and send it out once
done. You can also use a buffer as tile, say, 32x32 pixels, work on that and
update at once.
Next, write special functions for special cases. Like, horizontal and vertical
lines, instead od a single function for all. Note that the bresenham i use in
my code is far from optimal. Another example is the one you brought up,
clearing the screen. Instead of drawing one pixel after the other, just send
the same byte(s) over and over again, until the display is filled. So, all
1's or all 0's, depending on what you want (black vs. white).
If the chip has an external memory bus, connect the lcd to that instead (this
is also what is done here in the remotes). So instead of fiddling with i/o
pins yourself, just write/read to/from a memory address.
Next, put your critical graphic routines in RAM instead of flash, since ram is
somewhat faster usually, at least here for me.
In any case, try to prepare as much graphics as possible in a local buffer,
combine the display's memory with that, and then (in a second pass) write out
all the data at once.
Greetings,
Chris
> Thanks to everyone's help here, I now have the screen acting like I
> expected, and can set all the pixels. I'm a bit turned off by the
> performance, though. I've made some efforts to minimise all the required
> delays, etc., but it is impossible to have instant-seeming screen refreshes
> on an lpc2148 or similar device? I can put everything in a memory map and
> then write it all at once (16-bit row by row), but I'm still seeing the
> scren visible 'scroll down' as I draw on the screen, taking maybe 1/2s to
> draw the whole screen.
>
> Any idea how I might be able to most efficiently fill the screen with black
> pixels, for example, without the user seeing the pixels scroll down the
> screen?
Hi Kevin,
there are serveral things you can do to speed up things.
First, dont expect to use it like a regular, generic computer graphics thing.
There are many things you can optimize, but you have to trade off
some "genericness" then.
First, use a small local buffer, much smaller than the whole display. Like, a
complete line or two. Do all drawing on that buffer, and send it out once
done. You can also use a buffer as tile, say, 32x32 pixels, work on that and
update at once.
Next, write special functions for special cases. Like, horizontal and vertical
lines, instead od a single function for all. Note that the bresenham i use in
my code is far from optimal. Another example is the one you brought up,
clearing the screen. Instead of drawing one pixel after the other, just send
the same byte(s) over and over again, until the display is filled. So, all
1's or all 0's, depending on what you want (black vs. white).
If the chip has an external memory bus, connect the lcd to that instead (this
is also what is done here in the remotes). So instead of fiddling with i/o
pins yourself, just write/read to/from a memory address.
Next, put your critical graphic routines in RAM instead of flash, since ram is
somewhat faster usually, at least here for me.
In any case, try to prepare as much graphics as possible in a local buffer,
combine the display's memory with that, and then (in a second pass) write out
all the data at once.
Greetings,
Chris
Reply by ●November 26, 20082008-11-26
Reply by ●November 26, 20082008-11-26
Christian:
Thanks again for the (very thorough) reply. I'll likely have to spend a day or two on it, but
I'll try some of the suggestions you made (particularly the ram buffer) and see where I can
get.
In any case, the biggest offender in terms of performance seems to be the following
method:
// Toggles the Enable pin on then off
void st7920_strobeEnable(void)
{
GPIO0_IOSET = ST7920_E;
DelayUS(750);
GPIO0_IOCLR = ST7920_E;
}
If I drop the delay below 700 S between toggling the Enable pin high and low, the display
goes all nutty, but leaving it this high unfortunately means that I'm adding a decent
amount of delay every single time I send either a command or data to the controller, and I
don't see how I can avoid that?
Kevin.
PS: The remote indeed sounds like an interesting project. I've only been playing with
embedded devices for a couple months myself (coming from a background of 10 years in
PC software development), but it's the kind of project that would interest me just to see
what the end result might be with a bit of effort on my part. I've found embedded
development a lot more satisfying on the whole, just because at the end of all that effort
you at least have something you can hold in your hand. Sometimes it seems crazy to me
that I can spend 2 years working on a project at work, and have nothing to show for it but
a few dozen screenshots of Internet Explorer, or Windows, etc. :-)
Thanks again for the (very thorough) reply. I'll likely have to spend a day or two on it, but
I'll try some of the suggestions you made (particularly the ram buffer) and see where I can
get.
In any case, the biggest offender in terms of performance seems to be the following
method:
// Toggles the Enable pin on then off
void st7920_strobeEnable(void)
{
GPIO0_IOSET = ST7920_E;
DelayUS(750);
GPIO0_IOCLR = ST7920_E;
}
If I drop the delay below 700 S between toggling the Enable pin high and low, the display
goes all nutty, but leaving it this high unfortunately means that I'm adding a decent
amount of delay every single time I send either a command or data to the controller, and I
don't see how I can avoid that?
Kevin.
PS: The remote indeed sounds like an interesting project. I've only been playing with
embedded devices for a couple months myself (coming from a background of 10 years in
PC software development), but it's the kind of project that would interest me just to see
what the end result might be with a bit of effort on my part. I've found embedded
development a lot more satisfying on the whole, just because at the end of all that effort
you at least have something you can hold in your hand. Sometimes it seems crazy to me
that I can spend 2 years working on a project at work, and have nothing to show for it but
a few dozen screenshots of Internet Explorer, or Windows, etc. :-)
Reply by ●November 26, 20082008-11-26
Am Donnerstag, 27. November 2008 schrieb Kevin Townsend:
> Christian:
>
> Thanks again for the (very thorough) reply. I'll likely have to spend a
> day or two on it, but I'll try some of the suggestions you made
> (particularly the ram buffer) and see where I can get.
>
> In any case, the biggest offender in terms of performance seems to be the
> following method:
>
> // Toggles the Enable pin on then off
> void st7920_strobeEnable(void)
> {
> GPIO0_IOSET = ST7920_E;
> DelayUS(750);
> GPIO0_IOCLR = ST7920_E;
> }
>
> If I drop the delay below 700 S between toggling the Enable pin high and
> low, the display goes all nutty, but leaving it this high unfortunately
> means that I'm adding a decent amount of delay every single time I send
> either a command or data to the controller, and I don't see how I can avoid
> that?
Hi Kevin,
hmm, that doesnt sound right. According to the Datasheet of the LCD controller
you use, the enable cycle time Tc is given as 1200 or 1800 nS, which is 1.2
or 1.8 S. So, a wait of 750 S for the toggling of the enable-line looks way
too much.
Have you checked the signal integrity with a scope, on the physical line? What
C do you use, at what frequency, and what PLL (if any)? How is the display
connected?
>
> Kevin.
>
> PS: The remote indeed sounds like an interesting project. I've only been
> playing with embedded devices for a couple months myself (coming from a
> background of 10 years in PC software development), but it's the kind of
> project that would interest me just to see what the end result might be
> with a bit of effort on my part. I've found embedded development a lot
> more satisfying on the whole, just because at the end of all that effort
> you at least have something you can hold in your hand. Sometimes it seems
> crazy to me that I can spend 2 years working on a project at work, and have
> nothing to show for it but a few dozen screenshots of Internet Explorer, or
> Windows, etc. :-)
Well, as said, the remote itself is not a project of mine. You can grab them
for 10 or 20 Euro on eBay in Germany. Maybe you still can get some in
Switzerland on eBay as well. They have not been used anywhere else, from what
i know. The package comes with the remote, a modem and a scart-adapter (to
grab the VTX signal). They all communicate through the 433 MHz band, using
the CC1100 chips. We are just about to write new firmware for that thing,
since the company who made the system is out of business.
Greetings,
Chris
> Christian:
>
> Thanks again for the (very thorough) reply. I'll likely have to spend a
> day or two on it, but I'll try some of the suggestions you made
> (particularly the ram buffer) and see where I can get.
>
> In any case, the biggest offender in terms of performance seems to be the
> following method:
>
> // Toggles the Enable pin on then off
> void st7920_strobeEnable(void)
> {
> GPIO0_IOSET = ST7920_E;
> DelayUS(750);
> GPIO0_IOCLR = ST7920_E;
> }
>
> If I drop the delay below 700 S between toggling the Enable pin high and
> low, the display goes all nutty, but leaving it this high unfortunately
> means that I'm adding a decent amount of delay every single time I send
> either a command or data to the controller, and I don't see how I can avoid
> that?
Hi Kevin,
hmm, that doesnt sound right. According to the Datasheet of the LCD controller
you use, the enable cycle time Tc is given as 1200 or 1800 nS, which is 1.2
or 1.8 S. So, a wait of 750 S for the toggling of the enable-line looks way
too much.
Have you checked the signal integrity with a scope, on the physical line? What
C do you use, at what frequency, and what PLL (if any)? How is the display
connected?
>
> Kevin.
>
> PS: The remote indeed sounds like an interesting project. I've only been
> playing with embedded devices for a couple months myself (coming from a
> background of 10 years in PC software development), but it's the kind of
> project that would interest me just to see what the end result might be
> with a bit of effort on my part. I've found embedded development a lot
> more satisfying on the whole, just because at the end of all that effort
> you at least have something you can hold in your hand. Sometimes it seems
> crazy to me that I can spend 2 years working on a project at work, and have
> nothing to show for it but a few dozen screenshots of Internet Explorer, or
> Windows, etc. :-)
Well, as said, the remote itself is not a project of mine. You can grab them
for 10 or 20 Euro on eBay in Germany. Maybe you still can get some in
Switzerland on eBay as well. They have not been used anywhere else, from what
i know. The package comes with the remote, a modem and a scart-adapter (to
grab the VTX signal). They all communicate through the 433 MHz band, using
the CC1100 chips. We are just about to write new firmware for that thing,
since the company who made the system is out of business.
Greetings,
Chris
Reply by ●November 26, 20082008-11-26
Oh,
and even keeping in mind the execution time for the commands, which is 72 S,
the 750 S is way too high, imho. Only the display clear command takes
longer, 1.6 mS. Reading the busy flag is immediate, 0 S.
Greetings,
Chris
and even keeping in mind the execution time for the commands, which is 72 S,
the 750 S is way too high, imho. Only the display clear command takes
longer, 1.6 mS. Reading the busy flag is immediate, 0 S.
Greetings,
Chris
Reply by ●November 27, 20082008-11-27
> Hi Kevin,
>
> hmm, that doesnt sound right. According to the Datasheet of the LCD controller
> you use, the enable cycle time Tc is given as 1200 or 1800 nS, which is 1.2
> or 1.8 S. So, a wait of 750 S for the toggling of the enable-line looks way
> too much.
>
> Have you checked the signal integrity with a scope, on the physical line? What
> C do you use, at what frequency, and what PLL (if any)? How is the display
> connected?
I managed to speed it up significantly by lowering all the delays to 100 microSeconds, but
putting an explicit 12ms delay after the clear command (which requires a > 10ms delay
according to the datasheet). There is probably still some room for improvement, but this
allows me to reduce the delay when toggling the Enable pin from 750 us to 110 us, and
significantly improves performance.
Thanks again for everyone's help with this. There are still some off issues to sort out with
this controller, but I suspect I understand enough to figure out the rest.
Kevin.
>
> hmm, that doesnt sound right. According to the Datasheet of the LCD controller
> you use, the enable cycle time Tc is given as 1200 or 1800 nS, which is 1.2
> or 1.8 S. So, a wait of 750 S for the toggling of the enable-line looks way
> too much.
>
> Have you checked the signal integrity with a scope, on the physical line? What
> C do you use, at what frequency, and what PLL (if any)? How is the display
> connected?
I managed to speed it up significantly by lowering all the delays to 100 microSeconds, but
putting an explicit 12ms delay after the clear command (which requires a > 10ms delay
according to the datasheet). There is probably still some room for improvement, but this
allows me to reduce the delay when toggling the Enable pin from 750 us to 110 us, and
significantly improves performance.
Thanks again for everyone's help with this. There are still some off issues to sort out with
this controller, but I suspect I understand enough to figure out the rest.
Kevin.
Reply by ●November 27, 20082008-11-27
--- In l..., Christian Klippel wrote:
> Well, as said, the remote itself is not a project of mine. You can
grab them
> for 10 or 20 Euro on eBay in Germany. Maybe you still can get some in
> Switzerland on eBay as well. They have not been used anywhere else,
from what
> i know. The package comes with the remote, a modem and a
scart-adapter (to
> grab the VTX signal). They all communicate through the 433 MHz band,
using
> the CC1100 chips. We are just about to write new firmware for that
thing,
> since the company who made the system is out of business.
>
> Greetings,
>
> Chris
>
Do you have a ebay link to this device you can post ??
thanks
donH
> Well, as said, the remote itself is not a project of mine. You can
grab them
> for 10 or 20 Euro on eBay in Germany. Maybe you still can get some in
> Switzerland on eBay as well. They have not been used anywhere else,
from what
> i know. The package comes with the remote, a modem and a
scart-adapter (to
> grab the VTX signal). They all communicate through the 433 MHz band,
using
> the CC1100 chips. We are just about to write new firmware for that
thing,
> since the company who made the system is out of business.
>
> Greetings,
>
> Chris
>
Do you have a ebay link to this device you can post ??
thanks
donH
