Thanks for the feedback. I think the playground article and the readme file for the previous version of the library are correct (if not completly clear) - that version, like the new one, will automatically include the correct file if you use a standard arduino board (ATmega 168 or 328), Mega or Sanguino board.

But its not made explicit that when you use the default pin assignments everything would get configured automatically for the supported boards. You only needed to edit a config file if you changed the wiring or used an unsupported board type.

The new library and documents replace the old, I trust that they are clear enough.

I will be updating that playground page with info for the new library when the beta cycle is over so new users will be directed to the new version.

copiertalk

This was my fifth or 6th project. I got this inexpensive display off of ebay as I mentioned before. I hooked it up four or five ways and read every bit of information I could find was interesting at the time. I finally sat down, went pin by pin, connection by connection, line by line from the datasheet (As I should have from the beginning).

It has been on my board for several months playing with it.

You mentioned frame buffers in a previous thread, can you elaborate on that a little more or is there some documentation on how to take advantage of it released yet?

The GLCD library uses the memory in the LCD panel instead of a frame buffer in Arduino RAM. A frame buffer require lots of RAM which is a scarce resource on Arduino chips. Was there something you wanted to do that needs a frame buffer or were you just curious?

The GLCD library uses the memory in the LCD panel instead of a frame buffer in Arduino RAM. A frame buffer require lots of RAM which is a scarce resource on Arduino chips. Was there something you wanted to do that needs a frame buffer or were you just curious?

Personally, I would love to see a frame buffer, if it could be made optional (so that if you didn't want it or need it, no RAM would be taken up). In theory, this would allow you to do updates off-screen (erase/redraw), then just dump the entire buffer to the GLCD as fast as possible, to reduce or eliminate any flicker.

If it could be put in now while it is fairly early in the game, then if faster GLCDs become available, it would only help. Plus, with such a buffer, you could potentially do collision detection, sprite handling, and a few other things related to graphics and game development.

I understand that such an option would increase memory footprint, even in a 328 there wouldn't be much left. Perhaps, though, in such a situation the 328 could be made "standalone" as a graphics engine processor, and maybe an I2C, SPI, or bit-bang serial interface could be incorporated into the engine's core to allow other microcontrollers (another Arduino, perhaps) to control it...

I know I have pushed this idea before; I am already glad somebody has went this far with GLCDs and a library - I just think adding this kind of functionality could open up other development avenues for our favorite device...

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

@ cr0sh, although there are applications such as animation where a frame buffer would be more suitable, in many cases a frame buffer would not be a good solution. Updates involving relatively few pixels would be slower with a frame buffer. But the main problem is RAM - a 64x128 panels would need 1k, a 64x192 panel 1.5k. Color panels (which will be supported in a future version) would need more RAM then an entire Mega.

That said, the architecture of the Library could accommodate a frame buffer. The drawing and text functions are in a separate layer from the code that sends pixels to the LCD panel. If someone wanted to experiment, have a look at the glcd_Device.cpp module, this could be modified to use a frame buffer instead of LCD memory. But it would be complex to implement and there are more pressing things we are looking at adding in future like:- supporting more display controller types- displays larger than 256 pixels- color displays

But if someone has the desire and skills to implement a frame buffer within the architecture, please do PM me or bill.

@cr0shUnfortunately, it is not early in the game as far as design and coding goes.When designing something like this, in order to get fast efficient code, you have to go one way or the other.There are advantages to either method. As Michael said the biggest issue with using a framebuffer architecture is that it consumes quite a bit of memory. In fact to do anything really nice you actually need multiple buffers for different "planes".With multiple planes you can do fancy things like scroll text on top of the graphics or have different animations on different layers.There simply is not enough RAM memory in AVR chips to support frame buffers especially for larger displays.

It really is something that can not be "optional". Well ok, it could be butin order to really take advantage of a frame buffer architecture, it really needs to be different code for the low level and especially the text rendering code. Yes the current text code and graphic code could run on top of a frame buffer "as is" but it would not be as efficient compared to what is possible.

Currently the routines would need a bit of a re-write to take advantage of direct access to frame memory, as currently they assume indirect page based memory access and do alot of extra things to ensure things are bundled up and packaged into lcd page bytes. This is because the LCD memory interface is SLOW compared the speed of the AVR, so it is advantageous timewise for the AVR to do a few extra instructions to ensure that the glcd write pipeline is not broken and reads are avoided as much as possible. This page logic and indirect function call overhead to access the data is simply not needed when updating a local frame buffer.

In reality, a frame buffer is not always faster. It may sound counter intuitive but in many real world situations it will be no faster and can actually be slower than what the current code is doing as the current code only updates those lcd pages that are being changed vs updating the entire display or even a region of the display.

Along with some fancy multiple graphic "planes" features,the biggest thing that a frame buffer architecture can do is time shift when the display update gets done rather than actually improving display update performance speed.

I have a long post about this in the other ks0108 thread on page 27, 5th from the top.

Now a couple of the things we could do that would be very easy and is actually on our "to do" list is to have some sort of alternate DrawBitmap() function that takes a pointer to a RAM buffer address rather than a FLASH address. Or perhaps some kind of ram buffer dump routineso that people could then experiment with their own frame buffer code.

If someone wants to experiment with frame buffers then the following (untested) fragment added to a sketch should allow a frame in RAM to be sent it to the display. Filling the RAM frame with pixel data in the correct format is left as an excercise to the reader.

agib

I'm in the process of cleaning up and creating a library from some GUI code I wrote (for stuff like text labels, text boxes, scroll bars etc) and most of it seems to be working fine with some minor tweaks. (Though I suppose some of it is redundant now gText exists).

Mario_H

I just ordered my first GLCD to play with. I made sure it uses a controller currently supported by this library.During my search for a GLCD I've seen some very nice (mostly big) GLCD's that unfortunately used "unsupported" controllers like T6963C.Can you shed some light on which other controllers are going to be supported by the library?

Can you shed some light on which other controllers are going to be supported by the library?

In addition to the KS0108 and compatibles, the SED 15220 controller is supported in the current version.

Some work has been started on a number of other LCD controller chips.

The KS-0713 is coded but we don't have a controller to test this with.

Some work has been done for the SED1330 but this is a complex beast and it may be a while before its ready.

There is a prototype of the Nokia 6610 display working with the library although the code is not ready to release (it was done primarily as an experiment to explore color support in the library).

It would be interesting to hear what displays would be most appealing. If you want to use a display that is not yet supported then please post a reply saying why you chose that display along with links to product sources.

Priority for development depends on lots factors, including the potential popularity of the display, the development effort needed to integrate, and the availability of samples to test. The latter does have significant weight and if a couple of samples of a panel were sent to Bill and me, that will help to peak our interest (You can PM me or Bill for details)

Mario_H

I think one of the most other used controllers would be the T6963C. This one is #1 on my request list for the library. While browsing the web for GLCD suppliers the controllers listed below were mostly used.S6B0086 (=NT7086)NJU6450ASPLC501CST7920NT7532SED133XST7565R(Some may be compatible, I haven't checked yet)

I'm not sure what you mean with you last remark "send a couple of samples to Bill and me that will definitely peak our interest"?Currently I'm guarding my mailbox awaiting the arrival of the postman who should deliver my first (KS0108) GLCD any day now.

For testing the T6963C controller I may be able to help. I've salvaged a 320x64 display from some old device, but I don't have the connections/specs for this display yet.I've requested info from the vendor but they have trouble finding the datasheet for this (10 year old) module. When (and if) I get the data I need I will be able to power-up the display and do some testing.

There are a lot of part numbers that may be compatible with the ks0108. I have tested with the ks0107 and S6B0108.

Here is a more extensive list I have come across of parts that may be compatible:KS0107/KS0108, HD61202/HD61203, AX6108/AX6107, PT6608/PT6607, KS0708, S6B0708, S6B0108A, S6B2108, S6B0108, SBN0064, ST7548, NT7108, RA8808, RW1065