command buffer

LK/ELK/VK/PK/OK/MX/GLK/EGLK/GVK/GLT Series

Moderators: Henry, Mods

Post Reply
joseph
LCD?
Posts: 1
Joined: Fri Aug 31, 2001 6:00 pm
Location: Joseph Fernandez
Contact:

Post by joseph »

i am working with glk12232-25. how do we manage the command buffer (which the manual says can hold 96 bytes)? when this buffer gets full, it rejects subsequent command bytes. how do i prevent that from happening?
thx,
joseph..
DeepRoot Linux
Bangalore

Aniso
-=Beloved by all=-
-=Beloved by all=-
Posts: 286
Joined: Tue Aug 14, 2001 6:00 pm
Location: ...I could tell you my velocity...

Post by Aniso »

Well, first lets state that this is something you don't want to happen. You never want to send more data than the unit can hold. This is obvious, but there can be side effects beyond the simple lose of data. When the unit is forced to try to deal with excess data, it CAN get a bit messed up. We have tried to make the unit as forgiving as possible, but we have made the assumption that this overrun of data is something that will only be seen during development and not "in the field". If we were to make the unit 100% "bullet proof", we would have to sacrifice performance in other areas.

I believe that the details of the "handshaking" mode are in the manual, but basically it is like this.

Send the command to enter this mode and specify when you want to receive alerts. You can say that you want to know when the unit has only 20 bytes free in it's buffer and it will send you the code FE to let you know when this is true. It will also send FE for every byte that exceeds this limit.

When you send the mode command you will also specify when you want to hear that the buffer is almost empty. If you set this to 10, then when there are just 10 bytes left to be processed, the unit will send you a FF code to let you know that it is safe to send more data. This is sent only once.

When you are using this mode, you must be doubly sure that you do not overrun the buffer or send data faster than the unit can keep up with. Doing either of these things will cause the data counters to become un synched.

For instance, it is probably possible to break the process by using 115 Kbaud and sending many commands in sequence which require writes to memory (such as a program which changes contrast on a slider and is using "write contrast and save" commands). Any parameter which is remembered between power-ups will write to memory.

Most developers do not have trouble with this sort of thing, but if you do, you should manual override, wipe the file memory, reset, and think about what you are doing. Solutions are not difficult to find.

Make sure that this mode is not on when you attempt to upload new fonts or bitmaps. Make sure that if you are in this mode that your system is actually using it in all cases. Failure to respect the messages that the unit sends will result in weird behavior. Do not forget about any buffers which may exist in your host system - such as the FIFO buffer of a UART.

Please ask for any clarifications you require. I hope that I have been helpful today.

Post Reply