Address control setting about erm19264_uc1609 HOT 7 CLOSED

Hi

Please provide a detailed report.

regards

from erm19264_uc1609.

OK, here you go:
I wanted to try if I could get this lcd19264 display I ordered from the well-known chinese trading platform some time ago to work and reckoned using arduino was the easiest to accomplish it, I found your library that should handle such display, which looks exactly like one of the pictures in this github project.
So I installed the lib and hooked the display to an arduino board I had laying around, an arduino M0 (atmel samd21 based). Even though it wasn't listed as one of the boards this library was tested with, I gave it a shot anyway. I took the ERM19264_UC1609_TEXT.ino example as basis. The hardware SPI didn't seem to work, so I tried the software SPI (specifying the SCL/SDA pins in the constructor). Something showed on the screen, but not what was expected. It seemed that only the first column of pixels had some 'life' in them and the rest of the display looked like some non-changing 'starry sky'. So I reckoned that there must be something wrong with the v-ram address incrementing. I found the datasheet for uc1609 and there was a register location that configures the v-ram addressing; the one I described above. I tried some other values for that setting and voila the value 1 sprung the display to life.
Then I went back to the hardware SPI and saw with the logic analyzer that there was no clock and data on the digital 11 and 13 pins of the arduino M0. I confirmed that the SCK and MOSI pins of the SPI header indeed to not connect to those digital pins on this variant of the arduino. This is due to the lack of my knowledge of the difference between arduino boards regarding SPI signals. Using the SCK and MOSI pins of the SPI header for connecting to the SCL and SDA pins of the display makes the hardware SPI work as well.

I hope this is detailed enough.

from erm19264_uc1609.

It might be that the display I have doesn't use an authentic UC1609, but some clone that has slightly different behavior wrt. the address incrementing. Such things are not rare with products sourced from the well-known chinese trading platform.

from erm19264_uc1609.

Hi

Its possible to buy a ERM192X64 LCD with a different controller on them.
For example , I brought my UC1609 ones from "buydisplay" (EastRising Technology Co) and they recently released the exact same LCD with an ST7525 controller.
https://www.buydisplay.com/2-inch-blue-192x64-graphic-lcd-display-module-st7525-spi-for-arduino

There is also different UC1609 versions , Mine have V3(version 3) written on back.

Do you have a link to where you brought it ?
Does your LCD have a version number on back?

from erm19264_uc1609.

Mine has V3.2. Its from https://www.aliexpress.com/item/4000870410380.html, bought october last year.
If it would have the ST7525 controller, it wouldn't work with your library and the small modification of just the address control setting (I guess...).

from erm19264_uc1609.

Hi

The ST7525, I was told by manufacturer it was same as UC1609(from software point of view) although I have not looked at in detail. I was just making the point there is different controllers out there and the LCD screen/PCB will look the same.

There was a report before where someone could not get the LCD to initialize , we never got to bottom of it. Although he had a different failure mode(nothing in first column, just random pixels) but that could be because he has using a different example file possibly. He had version 3.1 on his PCB , which was from a third different manufacturer/seller.

I was never able to find information as to what version 3, 3.1, or 3.2 printed on LCD PCB meant or if it matters at all to this problem.

I will add a note to README referencing this issue, maybe in future version I will break out this setting to allow users to change it on initializing as a parameter to LCDbegin method or something.

Thanks.

from erm19264_uc1609.

Hi

FYI.
Version 1.7.0 released which allows user to pass Ram address setting bits as an argument to
the "begin" method.

Thanks

from erm19264_uc1609.