Closed Peerke1 closed 5 years ago
Different resolution I can add, pinout you need to fix and yes, there should be something visible. How exactly did you connect Arduino and display?
VO is supplied by an external invertor. pot: -15V (leg 1) - VO (leg2) - GND(leg3) Arduino Mega 1,2 =GND 3 = +5V from Ardiuno 4 = leg 2 of poti 5 = WR = 17 6 = RD = 18 (output and HIGH) 7 = CE = 14 8 = C/D = 15 9 NC 10 = RESEt = 16 11 D0 12 = D1 13 = D2 14 = D3 15 = D4 16 = D5 17 = D6 18 = D7 19 = NC (backlight 9V minimal to start working) 20 = NC
FS0 and FS1 are hard to GND on the pcb of the LCD
![LCD_160x128-pixels] (https://user-images.githubusercontent.com/48998939/58325791-30448080-7e2b-11e9-852c-9fe127734e2e.jpg)
Most of the pixel are black on the display (except for the line). Can you make all pixel transparent by moving the var pot? And how does the u8g2 constructor look like?
When i move the var pot the pixels disapear or become more black.
constructor i initially used: U8G2_T6963_240X128_F_8080 u8g2(U8G2_R0, 8, 9, 10, 11, 4, 5, 6, 7, /enable/wr=/ 17, /cs/ce=/ 14, /dc=/ 15, /reset=/ 16); // Connect RD with +5V, FS0 and FS1 with GND
What i noticed is that the WR, RD, CE and C/D all have a pull-up to 5V on the PCB.
I don't know if that is suppose to be the case on these kind of LCD's?
The pin-header is directly connected to the pins on the 6963 IC, so if these pin float they are in an '1' state because of the pull-up.
I control the RD by setting an output pin in arduino to HIGH, this could be illuminated as the pin is already high per default.
I dont know if this could cause issues with the other pins like WR, CE and C/D?
(in the datasheet of the T6963C they have the inverse symbol (flat line above the name))
When i move the var pot the pixels disapear or become more black.
sounds good.
What i noticed is that the WR, RD, CE and C/D all have a pull-up to 5V on the PCB. I don't know if that is suppose to be the case on these kind of LCD's? The pin-header is directly connected to the pins on the 6963 IC, so if these pin float they are in an '1' state because of the pull-up.
should be fine.
I dont know if this could cause issues with the other pins like WR, CE and C/D?
RD must be reliable on high. Thats all...
How did you build everything together? Is the display reliably connected?
I have a pcb daughter board on top of the mega and there a put on a pin-header to attach the display with a band-cable (already took a brand new one). see pictures. I will recheck all connections ones again to make sure the dont short somewhere.
well yes, looks correct as far as I can see this from the pictures.
while thinking about your display, I remember, that there might be a lot of RAM attached to the display controller. U8g2 writes to a certain RAM area, assuming, that this is displayed accordingly. We probably need to crosscheck the datasheet of the display to figure out how the RAM is mapped to the pixels on the display. Is the datasheet of your display available?
I searched on Google and could not find any documentation. I got the display a while back and most likely it came from an IP Phone. I was thinking the same as i cam across a threat with this in it: I assume all the hardware connections are correct.
What does the datasheet of LCD say on the G_BASE and T_BASE addresses? Many moons back, I had similar problem in getting a T6963 based LCD to work. After a week of trouble, I realised the problem was with the addressing scheme. For some reason that LCD was mapped to a higher base address than normally done. I suggest you should experiment with higher base address starting 0x1000,0x2000,...etc. I have to dig my archeives to check the details. It will be helpful if you could post the make and model number of the LCD.
Here is the back of the LCD, the 6963 chip is there and the kolom driver. the row drivers are on the other side behind the glass. The numbers on the PCB are GEB-2294V-0 S ( i found that alot only not in relation to the 6963's DG011Z is on the front
The memory chip LC3664NML-12 is a 64Kbit (8K x 8-Bit). Is that normal for these kind of displays?
Is that normal for these kind of displays?
yes, thats a usual RAM.
Maybe you can experiment a little bit with the graphics home address: https://github.com/olikraus/u8g2/blob/master/csrc/u8x8_d_t6963.c#L160
Try
U8X8_AAC(0x00,0x01,0x042), `` or
U8X8_AAC(0x00,0x02,0x042), ``
and so on...
BTW: What kind of Arduino board do you use?
Try U8X8_AAC(0x00,0x01,0x042),
or U8X8_AAC(0x00,0x02,0x042),
and so on...
Will give it a try.
Also found this: https://www.mikrocontroller.net/topic/48456 Where a guy has the same sort of issue with a 160x128 look for Autor: hft47 (Gast) Datum: 30.05.2010 15:24 Its all in german so maybe easier for you to follow. i am from the neterlands so parts of it i can udnderstand.
I use a Arduino Mega 2560
The only difference is indeed a different value for the above mentioned 0x042 command.
I was waiting for my tl497 to arrive so i could create a -15V modules that would repace my external power supply as i cant test very convenient with that connected, i found this post
https://forum.mikroe.com/viewtopic.php?f=22&t=9906
how does 0a20 map to your line U8X8_AAC(0x00,0x01,0x042)
update: i found in in this PDF http://www.hantronix.com/files/down/t6963app.pdf
U8X8_AAC(0x0a,0x20,0x042)
i also noticed that some other addresses are a bit different. If i replace all the 240/8 with 160/8 in thes routines below would that be enough to make a temp 160 routine?
static const uint8_t u8x8_d_t6963_240x128_init_seq[] = {
Just getting started with Arduino, did some C+ way back with PIC's and a bit new to arduino. if i update the files on disk ( in the installed lib) will arduino sketch pick them up?
i also noticed that some other addresses are a bit different. If i replace all the 240/8 with 160/8 in thes routines below would that be enough to make a temp 160 routine?
Some more modifications are needed. But yes, to make something visible correctly, this is a good approach.
if i update the files on disk ( in the installed lib) will arduino sketch pick them up?
yes
display shows 2 black lines on init, after that it keeps showing the all black pixels. Does not matter what i put in the file. My scope shows that there is data being send to the pins on the lcd. only stang thing is that some of the D0 - D7 pins are 1 bij default and go to 0 when active and some are 0 bij default and go to 1 when active. I think somewhere down the line setting it up i fried the t6963 or the sram chip...
thanks for the help, need to look for another nice display to use for my project.
What about this display: https://www.aliexpress.com/item/NoEnName-Null-20PIN-COG-240160-LCD-Module-ST75256-Controller-3-3V-5V-White-Backlight-Black-Word/32827915862.html
I personally like SPI much more than the 8 bit interfaces...
Can we close this issue here?
I didnt know there where LCD's like this that have a price tag below 100,- I will close this issue as i dont expect the LCD to come alive. Yesterday i got hold of a couple of LCD;s ultrachip fm1611FC, i am going to try if they match the UC1611 thanks for the great support, really appriciated.
I have a T6963C display that has a different pinout and resolution then available in the lib. The pinout i got fixed. 1: GND (connected to 2) 2: GND 3:+5V 4: VO (powered by external -15V and POT) 5: WR 6: RD 7: CE 8: C/D 9: NC 10: RESET 11: D0 .. 18: D7 19: Backlight (+12V needed) 20: NC
At this point the display is only showing all pixels with a light line in the middle. When i count the pixels i come up with 160X128. How can i add this resolution to the lib? (or should 160X<128 also show something?)
Kind regards,
Peter