Embedded "Smart" character LCD driver. Is this a good idea?

Posted by chris12892 on Stack Overflow See other posts from Stack Overflow or by chris12892
Published on 2010-05-23T15:53:58Z Indexed on 2010/05/23 16:01 UTC
Read the original article Hit count: 248

Filed under:
|
|
|

I have an embedded project that I am working on, and I am currently coding the character LCD driver.

At the moment, the LCD driver only supports "dumb" writing. For example, let's say line 1 has some text on it, and I make a call to the function that writes to the line. The function will simply seek to the beginning of the line and write the text (plus enough whitespace to erase whatever was last written).

This is well and good, but I get the feeling it is horribly inefficient sometimes, since some lines are simply: "Some-reading: some-Value"

Rather than "brute force" replacing the entire line, I wanted to develop some code that would figure out the best way to update the information on the LCD.

(just as background, it takes 2 bytes to seek to any char position. I can then begin writing the string)

My idea was to first have a loop. This loop would compare the input to the last write, and in doing so, it would cover two things:

A: Collect all the differences between the last write and the input. For every contiguous segment (be it same or different) add two bytes to the byte count. This is referenced in B to determine if we are wasting serial bandwidth.

B: The loop would determine if this is really a smart thing to do. If we end up using more bytes to update the line than to "brute force" the line, then we should just return and let the brute force method take over. We should exit the smart write function as soon as this condition is met to avoid wasting time.

The next part of the function would take all the differences, seek to the required char on the LCD, and write them.

Thus, if we have a string like this already on the LCD: "Current Temp: 80F" and we want to update it to "Current Temp: 79F"

The function will go through and see that it would take less bandwidth to simply seek to the "8" and write "79". The "7" will cover the "8" and the "9" will cover the "0". That way, we don't waste time writing out the entire string.

Does this seem like a practical idea?

© Stack Overflow or respective owner

Related posts about c#

Related posts about embedded