Resolved: Rogue pixels using glcdlib with Vatronix LCD
Wonder if anyone has seen this effect before. I’m using the JCW glcdlib to drive a 128 x 64 Vatronix LCD which uses the same SPI LCD controller chip (ST7565) as the JCW Graphics Board. All seems to be working well after I fixed an issue where the top line is appearing halfway down the screen by changin the PAGE_FLIP parameter in GLCD_ST7565.cpp. However I am having an issue where I have a few ‘rogue’ pixels around the left hand side of the display. I have tried several different LCD panels and always have this issue so I don’t think it’s hardware. Could it be a parameter I could try and tweak in the glcd library? See attached photo.
This is the LCD I’m tying to use is this unit: http://www.vatronix.com/products/129.html
Ok loading up the font demo it’s clear what’s going on: the whole display is shifted a few pixels to the right. Is there a paramater in glcd lib I can use to offset this offset?
RE: Rogue pixels using glcdlib with Vatronix LCD - Added by martynj over 2 years ago
Hmm - not convinced. How do the SPI edges look at the board connector?
RE: Rogue pixels using glcdlib with Vatronix LCD - Added by jcw over 2 years ago
Glyn, I do remember seeing something like this before. Not sure when, or how it was fixed back then - some change in the init commands, or even the choice of brightness of voltage multiplier settings? Maybe this line is a remnant of that settings change?
Sorry I can’t be of any more help.
Thanks for your suggestions. I tried SET_BIAS_9 but it didn’t work, looking at the datasheet SET_BIAS_7 is the correct command for the ST7565R which I’m using. The problem seems to be getting worse, I’m not sure what I’ve changed but I’m now getting 3 pixels of garbage on the left hand side of the LCD. Maybe it is a hardware issue.
I’m actually running two LCD’s in parallel to test off a emonGLCD V2 SMT prototype, few photos here:
On the plus side the push button rotary encoder works well, will be great for navigating between screens :-)
It’s definitely not a hardware issue. LCD works great with st7565 Adafruit library
Just seen your post. I did some of the work on the Jeelab’s library back in the day, and I have seen this before.
The GLCD lib was based on the Ada library (although TBH, there really wasn’t much of it left by the time JC and I had finished with it!). I remember having a screen offset issue with the JeeLab’s LCD panel, but in the other direction, namely falling off the left. I resorting to reading the ST7565 spec sheet, and changing some of the settings we’d got from the Ada library, which didn’t make any sense with the Jeelabs panel.
IIRC there are some differences in how the panels are mapped onto the “banks”. You found the bank order difference (we’d seen that, so coded in an option), but I’ve never seen one that actually needed the offsets the Ada library had included.
I’m going to have to have a look at the libraries side by side and remind myself, but in the mean time, try the LCDUNUSEDSTARTBYTES value… Give it a try with 1 or 0.
Woop woop! Reducing LCDUNUSEDSTARTBYTES from 4 to 1 solved the offset issue :
Thanks a lot, obvious when you know how :
Thanks again, I can now continue to use the JeeLib library which I like very much. You and JCW have done some nice work making it easy to use
Glad to be of service :
Sorry I didn’t see your post for so long. I’ve been distracted by many shiny things. Okay, it’s mainly one… An Odroid-W with LCD base board…
What I’ll do is add your offset line to the standard library as a commented out #define and a note to say that it’s for the Vatronix, then I’ll submit a pull request to JC and get it into the standard library… Unless JC sees this comment first, and just does it ;
I also need PAGE_FLIP 0x3
Mmm shiny, that board sounds interesting. Bit like a mini raspberrypi?
Exactly like a Raspberry Pi. Same Broadcom SoC… Which has caused some problems, namely Broadcom won’t supply them with any more after the first batch is gone.
But it’s completely software compatible with the Pi, and quite a long way hardware compatible, although physical connections would be a problem.
I’ve got a slightly modified kernel to drive the screen by default and read the battery stats (finally managed to get cross compile working on the PC, so can compile in 5 minutes instead of 8 hours native!).
It has in built RTC and LiPo charger, so it can run happily off a little 3.7v battery (or you can use that as a UPS).
And it is very small
That’s it talking to a Jeenode via a USBBUB :D
(Keyboard not pictured!)