Delay issues in GLK240128-25

[caribman]

The slowness in writing the display baffles me. Is the code written in C? The predictability of this delay has caused me to add multiple millisecond displays throughout my code. I design laboratory instruments which require fast display response to rapid key entry. Every key stroke requires at least 8 large 14 pt characters to be written to the screen, before the next key is retrieved. I employ the I2C interface and transmit these characters to the display one at a time. All my code is written in assembly, with the I2C running at 50kHz. In my production code, I have inserted a 2msec delay between transmit, with an additional 15 msec added after the eight 14 pt characters are written. The product seems stable for now, but I am concerned, since the delay required by the display does not seem to be deterministic.

What magnitude of delay would you suggest in these instances?

1 - After each single character transmit?
2 - After a new font selection?
3 - After setting new font metrics?
4 - After writing eight 14pt characters?
5 - After writing eight 8pt characters?
6 - After displaying a 60 X60 embedded bitmap?
7 - How soon after the display accepts a valid key can I poll for it?
8 - How much separation is required between polls?

I appreciate your help.

[Raquel]

Hello caribman,

Thank you for your post.

Our graphic displays are optimized to be able to draw bitmaps and fonts as fast as it can. The processes that are performed to do these plots on the screen can take up quite a bit of time, since the unit will have to gather the font information from an external memory and then translate this to something that the parallel display would understand. Adding to this the use of I2C which is a slower implementation than USART on the microcontroller on our boards.

You are right, the processing times (delays in the case for you host) for different sized fonts (and glyphs) will be vary accordingly. I will find out these delay times for you and post it here.

Thanks,