Questions? Call us: +1 760-918-6722


I have two things going on at the same time.
I received new S128240C displays. Unlike the first two displays I worked with, these new displays do not appear to get their VOLCTRL set during initialization. At any time after the unit is running I can go to my setup mode and set VOLCTRL, at which time the contrast of the display becomes normal. Even if I enter exactly the value used the first time in initialization. The two pieces of code are identical. I have single stepped my code through these functions for varification.
I have tied all unused pins to Vcc, since I am using the serial interface. I have also added a bleed resistor between Vcc and Vlcd. Programming the VOLCTRL to occur in other locations within my code has been unsuccessful.
I would like to use inverse video to highlight the line a user is currently on as he/she scrolls up or down the screen. ( This is nor the scrolling function in the controller.) This is done using up and down keys to step through the displayed lines. The area I would like to invert is the first 3 characters of the current line. I have used DISINV and it has always inverted the entire display.Is it true that DISINV always inverts the entire displayed area and I will need to create a display area only as large as desired and place it where the data is to be inverted? HOW?? What happens if my lines do not align with blocks?


Guest's picture
July 24, 2009

It sound like you're making good progress on the display.
Here are a few ideas on the issues posted:
You're right, DISINV does indeed invert the entire display (not a local area), so you need another method to create a local inversion.
There are several ways to achieve this, here's the method I use:
I pass an INVERT flag to the font generator and re-paint the string I want to invert.
In the font generator I simply swap the 'on' and 'off' pixel value depending on the invert flag - hey-presto - inversion.
You'll need to be a bit careful if you're using generated under-lines, over-bars, spaces and non-font-defined line spacing to ensure that these invert correctly too.
2) Block alignment
The LCD's API to rows should not be giving a problem - the API is line-based, so you should be able to write to any arbitrary line.
However, the LCD's column API is block-based - so you cannot directly write to any arbitrary column, but only at 3-column starting points.
When you use the 8-bit interface you can always read the current value, and then modify it.
But the serial interface does not allow read (which is what you're using I think).
I've thought about several tricks around this, but the most simple would be to keep your strings starting on block boundaries.
This allows individual characters to be arbitrarily aligned, but compromises the start of the string by up to 2-pixel widths.
My guess for this issue is that the first LCD had it's VOLCTRL setting committed to the LCD's E2 at some point, and the new ones did not.
This would explain why different LCD's would behave differently under the identical code.
You can test this by performing a VOLCTRL commit to e2 on the new LCD's (EPMWR)

Guest's picture
July 24, 2009

I have been looking for the source of the first problem. First I raided my test units and took one of the display boards to test it for the same problem. Results, positive, this display didn't set the VOLCTRL either, or so it seemed. I then did a comparison of the code I uploaded and that I am now using. The only difference I found was in the original code I had DISON in two places, before clearing the memory and setting the display area and before the end of the initialization. Apparently I removed what I thought was a redundant DISON at the end of the initialization.
After replacing the DISON at the end of initialization the display comes to life as expected. Apparently PTLIN turns off the DISON making it necessary to turn the display on afterward.

Guest's picture
July 24, 2009

Thanks for the information.