Display frustration #1019
-
|
Good evening, all. I've got a minidexed build up and running on a Zero 2W, and it's functioning as expected as USB Gadget, but I can't wrap my mind around the display. I'm running a 1602B with built-in I2C pins, but without a backpack board. This one is a Freenove version, of which I have a few--there is no contrast adjustment or jumpers as the I2C circuit is built into the main board. Occasionally, the display runs perfectly. Most of the time, the characters look like garbled hieroglyphs, which I've read about elsewhere without finding a solution. It's set up at 0x27, and while I've tested all addresses in the 27 and 3f range, the reality is that I've seen the full, clear menu at 0x27, so I know it can work. I've ensured the data lines aren't swapped. I tried running it at 3.3v instead of 5 (nope). I've considered solder problems, and reflowed everything. I've changed cables. The pattern is as follows: i will reboot the pi 30 times or so, memorizing the clicks and turns around the garbled text. Then I'll unplug and replug the usb cable, and minidexed boots up fine, with a legible display. I'll work through the menus, testing different performances, and, planning to finally put this thing into a case, unplug and replug to verify operation, and the hieroglyphs return. In the meantime, I've ordered a few new (identical) 1602 displays, wondering if the display itself might be damaged? If those of you have have seen the garbled text could chime in, I'd appreciate it. 
|
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 3 replies
-
|
One other detail: if, on garbled display as above, I pull the cable from the display with the Pi still running, the plug it back in, the display is clear and accurate, but displays only one line. For instance, if I've already clicked and rotated through to performance/load, I had see the bank and patch number of each performance setting. If I did this immediately after boot, the display reads "Minidexed", with no second line. Are there further settings for I2C displays that could be added to the .ini file? |
Beta Was this translation helpful? Give feedback.
-
|
One additional point, which may relate to this thread: (note that we are both running on Zero 2W.) |
Beta Was this translation helpful? Give feedback.
-
|
I am the the person that started the thread you linked to. Fortunately my experiences are a bit more predictable so I have been able to work around the issue. I am pretty sure there is some sort of race condition occurring and/or certain MIDI traffic causes too much latency that causes issues with some displays. The lower performance of the pi zero 2w is possibly a contributing factor. I suspect changing the boot order to ensure the USB gadget is initialized AFTER the display would likely fix the boot issue. Here are some additional observations that may help to get to the bottom of it.
The concerning thing with your setup is that you still observe issues while connected to a power supply. Just spitballing here... I suspect for the display to become corrupted, it has to receive the corrupted data. In order to do that, it would have to respond to its i2c address so the first byte of the transfer should be good. Since most/all the characters look bad I wonder if the corruption occurs before the buffer is sent as I find it unlikely only the address byte would be correct. If you have a scope and can capture the i2c traffic when the display is working and not working, you might be able to confirm if bad data is being sent to the display. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, @sgreasby. I ordered 2 more displays with one day shipping, determined to figure this out. I read elsewhere (but I can't find where) that these displays can fail to sync to the right clock speed, hence my question about whether other LCDI2C= variables could be added? |
Beta Was this translation helpful? Give feedback.
-
|
You say the displays have native i2c built in, have you tried a piggy back i2c adaptor and a standard display just to rule out your built in i2c display? |
Beta Was this translation helpful? Give feedback.
-
|
@craigyjp, I haven't, and unfortunately I don't have a piggy back on hand. However, I think I may have just found (part of?) the problem: the data pins are feeding back 5v to the PI rather than 3.3V. There are a few tiny jumpers beside the i2c port, but I'm going to need to do some digging to see if any of them affect outgoing voltage or level-shifting. Turns out I have a pile of "i2c" displays that are not, in fact, i2c displays. |
Beta Was this translation helpful? Give feedback.
-
|
Well my only concern is that most of these i2c display adaptors are based on a particular chip set the PCF7584, your board has its own i2c chip which may not be fully compatible with the driver. It's really the only thing I can think of to isolate this fault. A cheap LCD is what about $3-5 dollars and those adaptors are less than $1 each. Worth a try in my book |
Beta Was this translation helpful? Give feedback.
-
|
@craigyjp, you were correct. I picked up a new display with backpack this morning, and everything runs just fine. I'm a little surprised major companies are selling non-standard products, but I suppose these things are driven by cost in the end. Now to find a better case. |
Beta Was this translation helpful? Give feedback.
-
|
It's quite common to find that unless the controller and driver match you will get inconsistent results, for example I have some 4002 OLED displays that have a WS0010 controller rather than the standard parallel HD4780 interface and sometimes they produce garbage even when used with a piggy back. Glad you tested with the adaptor to make sure it was the onboard i2c interface. |
Beta Was this translation helpful? Give feedback.
@craigyjp, you were correct. I picked up a new display with backpack this morning, and everything runs just fine. I'm a little surprised major companies are selling non-standard products, but I suppose these things are driven by cost in the end. Now to find a better case.