Hello,
I've written some code for an LCD module that uses this controller, and a
99% there, but I'm experiencing a bit of a problem. I am aware this coul well be just a driver coding issue of my making, but I've almost exhauste all avenues of investigation now so am hoping that the symptoms of m problem will ring a bell with someone there.Basically I am drawing a bitmap on screen (approx 50 * 50 pixels), row a a time, using the "command byte+stream of data bytes" (per row) method Rarely, a problem occurs where an additional 8 pixels can be written o the end of the row. After investigation it appears that an extra byte ha been inserted during the row write for some reason, since the first byte of th row is always written correctly and the last few bytes seem to have bee pushed along by 8 pixels. I know this looks like a silly coding error but bear with me!!
What is extremely confusing though is that this behaviour only occur under certain conditions.
It happens far far less frequently if I write my bitmap rows with "comman byte + data byte + command byte + data byte...", but of course this is muc less efficient. This could be a coding issue, though I currently don' think so.
Also, it seems to almost go away completely if the data stream following the command byte is a good mix of 1s and 0s. However, if I send lots of
0s it happens a lot. This doesn't look like a coding issue though? My code should in theory work the same regardless of data byte values I've done a quick check for any unusual optimisations etc but can see nothing.Also, this problem goes away if I disable the screen before the bitma write and then re-enable it, but this doesn't explain what is going wron and I can't do this in practise anyway due to flicker.
If anyone there can offer any advice about what's going wrong I'd b grateful!
One other thing worth mentioning, when writing data bytes (followin memory write commands) I synchronise the writes with the status flag o D6.
Regards, Richard.