search

gavinlyonsrepo / ERM19264_UC1609

Arduino Eco-system Library to Support the ERM19264 LCD driven by the UC1609C / UC1609 controller.
https://gavinlyonsrepo.github.io/
GNU General Public License v3.0
17 stars 6 forks source link

Address control setting #4

Closed rohoog closed 12 months ago

rohoog commented 1 year ago

I had to change the address control setting (line 41 in ERM19264_UC1609.h) to 1 in order to get the display to work using this code. Also note that with the M0 arduino (samd21), the pins 11 and 13 don't work for hardware SPI; you have to use the SPI header pins 3 and 4.

gavinlyonsrepo commented 1 year ago

Hi

Please provide a detailed report.

regards

rohoog commented 1 year ago

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.

rohoog commented 1 year ago

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.

gavinlyonsrepo commented 1 year ago

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?

rohoog commented 1 year ago

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...).

gavinlyonsrepo commented 1 year ago

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.

gavinlyonsrepo commented 12 months ago

Hi

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

Thanks