Hi, First off I would like to thank everyone for their excellent support provided from this forum. My problem is this; I'm using a spark fun glcderial backpack for a basic oscilloscope. It works well but I can only print one pixel at a time and I have to delay a few milliseconds or I get errors on the LCD. So when I look at a square wave the screen takes almost one second to update. Is there a way to fill some sort of buffer on the glcd backpack then print it all at once?
I’m using spark fun glcd with Summoning Dark’s firmware, arduino nano.
I have tried changing the baud rate on glcd, right now it is at 115200
I have tried adding a cap across the glcd power input and Rx.
//___________________________________________________________________________________________scope print to lcd_______________________________
for(int f = 0; f < 113; f++)
{
lcd.togglePixel(f, (myArray[f]),1);
while((myArray[f] > myArray[f-1]) && ((myArray[f-1]+d)<(myArray[f])) && f > 0)
{
delay(5);
lcd.togglePixel(f, (myArray[f]-d),1);
d=d+1;
}
d = 0;
while((myArray[f] < myArray[f-1]) && ((myArray[f-1]-d) > myArray[f] )&& f > 0)
{
delay(5);
lcd.togglePixel(f, (myArray[f-1]-d),1);
d=d+1;
}
d = 0;
delay(5);
keyRead3 = analogRead(0);
if (keyRead3 > 10 && keyRead3 < 45)
{
keyPad = 99;
delay(500);
goto scopeMenu;
}
}
The serial protocol is slow. There is no handshaking to speak of, so sending data too fast will corrupt and give rubbish.
If you want anything even resembling sensible refresh rates you will need to drive a GLCD directly through a parallel interface. Using that, even writing every single pixel on the screen individually, you can get a few frames per second of display - enough for a simple 'scope.
I do see a difference between SPI serial, I2C serial and RS232 serial. GLCDs with SPI should be fast enough. With a Chipkit Uno i got more than 70Hz frame rate with a 102x64 Display.
I don't believe that the Serial interface is the cause of data loss in this case.
That backpack code isn't very efficient. The parallel interface for a ks0108 even for pixel operations is WAY faster
than even the transfer time for a single byte at 115200. Their code is just not very fast.
If you have enough free pins (you will need 13) then you could remove the glcd backpack and talk
to the display in parallel mode using the glcd library
glcd can plot around 18,000 random pixels per second. If you can spare 1k of RAM
it can use it for a read cache and plot around 30,000 pixels per second.
If you have your own buffer, which it kind of looks like you do, then you would not need the glcd library
read cache and could call the low level glcd library WriteData() function to slam out bytes to the display.
Updating the glcd display will be VERY fast as long as you store data in your buffer in the same format as the glcd
display memory as no checking or translation would be needed when moving it to the glcd.
Just move the pixel/page data 8 vertical pixels (byte) at time directly to glcd memory horizontally across the display
by repeatedly calling WriteData().
Hey, thanks for the info, Im using the glcd display in a multi function meter (arduino powered)with several other functions. I have only 1 free digital pin. The arduino mounts onto PCB's I had made for this project already. so Controlling the display directly is out of the question. It is functional the way it is, just the scope only refreshes once a seccond depending on the wave form. So I guess i will have to live with it. Thanks for the help regardless.