Hi everyone,
I am going to use a 128x64 monochromatic display for a project I am doing, the DEM128064L_FGH-PW by Display Elektronik.
This is the connection circuit I got from Display Elektronik:
Which works with my Arduino nano and the U8G2 library. I am using a newhaven display struct:
U8G2_ST7565_NHD_C12864_F_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* cs=*/ 10, /* dc=*/ 9, /* reset=*/ 8);
Because there was no struct for this particular display.
It controls the display fine, however there is a rather large, vague spot in the middle of the display, that I would ofcourse like remove:
Do you know why this spot might occur?
My first thought is that it might be caused by the fact that the capacitors are so far away from the display (long jumper cables), but I want to be certain before I design and order a PCB to test further.
Thanks advance,
Chris
Go on. The NHD constructor might "work" but is obviously not 100%.
I suggest that you try all the other ST7565 constructors (regardless of geometry)
Choose the "clearest" constructor. Report to Oliver.
I am utterly gobsmacked that anyone would choose a bare display that required a whole herd of rats to assemble. Especially since SPI modules are available.
David.
Hi David,
This project will eventually be made in a larger series, and none of the displays in ready to go packages were fit for my purpose. As I said I will design a PCB once I am happy with how the display functions to use in the project instead of this rats nest of wires.
I will give the other structs a try once I am back home.
Can you tell me what the differences are between the different structs in terms of the display control?
Thanks you
ST7565R is just a standard Silicon chip. The physical LCD panel might vary between different makes and models.
It has a set of "Manufacturer" registers for on-chip voltage generators, lcd drive patterns, row, column geometry, ...
These get set in the display.init() or equivalent method. However "clues" will be gleaned from the constructor.
Your photos show that the panel is not being set correctly.
I have not studied Oliver's code but I can make a few guesses.
But the best approach is to tell Oliver how your panel behaves.
Or to ask the panel manufacturer for the initialisation sequence.
David.
For the multiplexing frequencies at which these displays operate, the length of the jumper wires - inductance and resistance - is pretty much irrelevant (unlike the length of wires connecting to a microcontroller which are critical).
Clearly, the voltages being applied to the display are wrong.
Hi everyone,
I tested the different structs. The results were varying greatly (as you probably expected), but there was one struct that gave a good result:
U8G2_ST7565_64128N_F_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* cs=*/ 10, /* dc=*/ 9, /* reset=*/ 8);
Result:
As you can see the result is quite clear.
Thank you for the help David.
@Paul,
What makes you think the voltages are wrong? Could display performance be enhanced further with a different voltage? (gray to gray time is a little longer than I would ideally like it to be right now, but very workable.)
Right now the voltage over VCC-Ground is 3.47 V (as measured by my multimeter), so a little higher than the rated 3.3V.
Paul was referring to the on-chip voltage generators.
These are fairly immune to variations in supply voltage.
You don't want the display to vary if your battery voltage drops from 3.3V to 2.5V
But obviously chip registers affect the behaviour of different panels.
David.
Ah, that makes it more clear.
So the different structs in effect supply different voltages to the display?
Just think in terms of different initialisation sequence for each panel.
e.g. write special values to special registers that control the internal chip behaviour to suit the panel.
Think about it. A 100mm wide panel probably needs different voltages, waveforms to a 20mm wide panel from a different manufacturer.
Subsequent "user commands" will be exactly the same for any panel
e.g. plot a white pixel at coordinates: 10, 25
Oliver probably has a set of different sequences for each constructor. e.g. what value to write to which register. And what interface is used e,g, SPI, Parallel, ..., which pins, ...
David.
Oliver probably has a set of different sequences for each constructor. e.g. what value to write to which register. And what interface is used e,g, SPI, Parallel, ..., which pins, ...
If the manufacturer reveals the setup code, then this code is used in the corresponding constructor. The interface itself depends only on the chip (i mean it does not depend on the configuration) so U8g2 usually generates all interfaces for all displays.
But: All sequences "known to me" are implemented, so there is nothing more and the current constructors reflect my list of init sequences.
One remark to the initial pictures: The displays also do differ in the required contrast setup. The picture with the NHD constructor (first pic) was little bit high. So maybe also the initial constructor for the NHD display will work, if you reduce the contrast (with the setContrast command).
On the other side, if you increase the contrast with the 64128N constructor, the spot might appear again.
One reason for the spot could be a missing transient load decoupling capacitor near the power supply lines of the display. I suggest to add a 100nF cap between VSS and VDD on the adapter board next to the flex cable connector.
Oliver
