Go Down

Topic: New library: RGB GLCD (LDS183 Controller) (Read 12 times) previous topic - next topic


RGB_GLCD v1.6 has been released

  • Fixed a bug in the print() function when using a background color different from the screen background color.

Any further updates to the library will only be announced on my website: http://www.henningkarlsen.com/electronics/
All site news is available as a RSS-feed.

@Loren: This new version should solve your problem with vertical lines :)




I just started using your library. It looks very nice. There are some things I like about it - mainly the fairly full featured print implementation. I have also been using a (expensive) 4D board, and the available libraries are a mess compared to your's. The 4D board with it's onboard processor and memory card is pretty fast.

I want faster screen redraw with bitmaps, as the current speed is just not useful for my application. :D

I see you have put in the basic commands to deal with using the PCF8833 RAM. I am hoping the RAM would allow for faster screen drawing. I want to put an SPI EEPROM with images on the SPI with the display and load the images at startup.

You are clearly fairly experienced with this display, and I was wondering if you have any advice on this task?

Thank you!



You are clearly fairly experienced with this display, and I was wondering if you have any advice on this task?

I am sorry, but I can help you there. The main problem as I see is not the speed of the display, but the speed which the ATmega can push data to the display.



Jan 20, 2011, 07:24 pm Last Edit: Jan 20, 2011, 07:38 pm by moutonnoir Reason: 1
Doc Henning,

I do realize the arduino is the bottle neck. My plan was a 'Loading' splash screen with a little progress bar. Like video games. (I am making a game, in fact).

I want a few sprites, icons, and images in the RAM at program start.. Probably about 80k.. I will be putting the images into a I2C Serial 128K or 256K EEPROM (24LC128\256) - then using the Arduino to read from EEPROM to display RAM.

I am gonna make it work.. I think the process is:

1)Load appropriate data from EEPROM into a byte array
2)Send RAM Access X\Y command to display
3) Send data from byte array to display RAM
4)Cancel RAM writing by sending any other command
5)To restore from RAM, use the 'read sector\column' code.

I will be working on it. I am not that good at writing communication routines with all of the bytes, timing, and bits and whatnot - but I can usually make things work when i want them to.

Thank you for the library! It is awesome.



Jan 20, 2011, 07:53 pm Last Edit: Jan 20, 2011, 08:23 pm by moutonnoir Reason: 1
Uh Ohhhhh..

Let me ask: Is there even RAM available on the display for what I am describing, or is this 209K just the 132x132x12bit 'Screen RAM'  which displays immediately when filled?

What is the major bottle neck? I do not need scolling sprites or animation or anything - but i do want to be able to display full screen images without having to watch them draw. I also want to be able to make menus using my web design techniques - which requires a few images in memory at once - or loading to memory much faster.

Is the bottleneck the SPI interface? Is it 8 or 9-bit? Is the 9-bit only for displays 132x132, not 128x128? Are you using bit banging or library SPI commands? Is SPI the major bottleneck because of throughput potential - or just implementation? Are there any first places you would look to get some speed increases? Would parallel mode be faster?

I am going to upload some videos and link them - of my menu system as it is implemented on a 4D systems board. I really do not like the 4D systems stuff that much though - and want to use your library.

finally, do you know about any other displays? What about using this display in an actual manufacturing project? I am working towards manufacturing something with an LCD, and currently these Phillips screens are the cheapest option I have found.

Go Up