Go Down

Topic: 7" LCD CPLD problem. (Read 569 times) previous topic - next topic

EFI_Muz

Hi All,

This is my first post, so go easy!

I have purchased a 7" TFT LCD with CPLD controller (Sainsmart as it turns out.  :-\ )

I have the display connected directly to a DUE and have changed the model parameter in the sketch to
:- UTFT myGLCD(CPLD,38,39,40,41);

I have the latest version of the UTFT library and uploaded the "UTFT_Demo_800X480".

The display "works" but has artifacts left from the previous screens and results in blotchy and incorrect colours displayed.

The only other similar instance I could find was at the link below.
http://forum.arduino.cc/index.php?topic=290406.0

I have tried many different power supplies and these have little to no effect.
I am currently using a BK precision 15A bench power supply.
The touch screen and SD control wires are not connected to the DUE.

I am suspecting it is a timing issue with the signal or simply, the screen is junk.

Any help would be appreciated.

ZinggJM

Where is the link to your display, or a photo?
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

EFI_Muz

Hi Zingg,

In the picture with the sine wave you can see the artifacts of the last screen.

In the picture of the last screen the blotchy colours can be seen.

I purchased this through ebay. Item 190268644488.

ZinggJM

Don't think only of your problem, consider what any responder needs to be able to answer: identification of the display.

I am watching a Ski-Run, not time to go searching for a product ID!
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

ZinggJM

#4
Jan 21, 2018, 02:52 pm Last Edit: Jan 21, 2018, 07:30 pm by ZinggJM
Quote
I have the display connected directly to a DUE and have changed the model parameter in the sketch to
:- UTFT myGLCD(CPLD,38,39,40,41);
Connected directly, without a shield or wires for mapping? Then I would not expect anything is shown.

Please be more precise to get meaningful help.

Edit: If you see a chip marked SSD1963 on the backside of your TFT and tell us so, you could get a faster answer. Or the name of any chip you see that might be the controller of the display.
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

artisticforge

Hi All,

This is my first post, so go easy!

I have purchased a 7" TFT LCD with CPLD controller (Sainsmart as it turns out.  :-\ )

I have the display connected directly to a DUE and have changed the model parameter in the sketch to
:- UTFT myGLCD(CPLD,38,39,40,41);

I have the latest version of the UTFT library and uploaded the "UTFT_Demo_800X480".

The display "works" but has artifacts left from the previous screens and results in blotchy and incorrect colours displayed.

The only other similar instance I could find was at the link below.
http://forum.arduino.cc/index.php?topic=290406.0

I have tried many different power supplies and these have little to no effect.
I am currently using a BK precision 15A bench power supply.
The touch screen and SD control wires are not connected to the DUE.

I am suspecting it is a timing issue with the signal or simply, the screen is junk.

Any help would be appreciated.
I need to point out that the author of the UTFT libraries does not support the use of his libraries on any Sainsmart nor Mcufriends.com products. They are using the libraries in violation of the licenses.

http://www.rinkydinkelectronics.com/contact.php

If you had purchase a different display i would stop to help.
><>

EFI_Muz

Thanks Zinng,

Sheild? Not really, hand wired perf board. I have been over this many times as I suspected it to be the problem. Currently this is the third iteration, having gone from ribbon cable to this board. wires are <50mm long. Without any change in the display output behavior.

Display; Only two identifiable marks on the PCB, TFT070TN92 & 1982AY-TF. (I think the TFT070TN92 refers to the actual display)
   Processor, ALTERA MAX II EPM570T144CSN.
   SDRAM, Winbond W9864G6JH-6.


I think it is a timing issue. If I write the following code 3 times the display looks good. But it needs to be writtten at least 3 times to clean it up. Not very practical.

  myGLCD.clrScr();

  myGLCD.setColor(255, 0, 0);
  myGLCD.fillRect(0, 0, 799, 13);
  myGLCD.setColor(64, 64, 64);
  myGLCD.fillRect(0, 466, 799, 479);
  myGLCD.setColor(255, 255, 255);
  myGLCD.setBackColor(255, 0, 0);
  myGLCD.print("* Universal Color TFT Display Library *", CENTER, 1);
  myGLCD.setBackColor(64, 64, 64);
  myGLCD.setColor(255,255,0);
  myGLCD.print("<http://www.RinkyDinkElectronics.com/>", CENTER, 467);

  myGLCD.setColor(0, 0, 255);
  myGLCD.drawRect(0, 14, 799, 465);

  delay(1000);


Is there any convenient way of slowing the DUE for testing purposes?





RE artisticforge; I was not aware of the issues with regards sainsmart products prior to purchasing this screen. It has become abundantly clear that they are not the preferred product. Thank you.

ZinggJM

#7
Jan 22, 2018, 07:40 am Last Edit: Jan 22, 2018, 09:09 am by ZinggJM
@EFI_Muz

Thank you for the information.
I still would like to get a link to the display you bought, but I understand it might no longer be available.
A photo of the backside of your display might also have helped.

You report the marks on the PCB, and no marks of any chips on the PCB, so the controller may be hidden on the display panel or on the flexible connection part.

As you get output on your display, you seem to have selected the correct controller in UTFT, and I can look there and google the marks on your PCB to find out more.

CPLD controller : Complex Programmable Logic Device is a general name, the specific CPLD display controller used in these displays would need more searching.

I do not know if the clock speed of the Due can be easily reduced, but it may be easy to increase the length of the write pulse to the display in UTFT. I will take a look, and report later.

Make sure you have uncommented line 4 in HW_ARM_defines.h, if you use a wiring that corresponds to the CTE shield.
You can increase the WR pulse length in UTFT\hardware\arm\HW_ARM_defines.h:
//#define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask);
#define pulse_low(reg, bitmask) cbi(reg, bitmask); cbi(reg, bitmask);cbi(reg, bitmask);sbi(reg, bitmask);



@david_prentice

David,

if you happen to look into this topic, you could help with your broader knowledge, now that some information is available.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

david_prentice

#8
Jan 22, 2018, 10:19 am Last Edit: Jan 22, 2018, 10:21 am by david_prentice
I have never owned a CPLD.   Nor programmed one.

I did get a CPLD "running" with MCUFRIEND_kbv (remotely. ghlawrence testing on his hardware)
From memory,  the CPLD is unintelligent.   You can't change rotations etc in hardware.

Most CPLDs will simply provide a 8080-16 parallel interface to your Due.
Accept a tiny number of commands.

I have no idea what screen or CPLD is involved.   The OP has not provided any photos of the pcb or links to the sale item.

If the OP can display something on the screen,  the 8080-16 driver must be correctly wired.
You can slow down the UTFT pulse_low() operation.    Most modern TFT controllers have a minimum 66ns Write cycle.   The actual low pulse is 15ns.
The SSD1963 has a 33ns WR cycle.   I would expect a CPLD to be at least 66ns.

Yes,  you do have to worry about timing on a fast Cortex-M4 or possibly a Due M3.

David.

EFI_Muz

#9
Jan 22, 2018, 07:24 pm Last Edit: Jan 22, 2018, 07:38 pm by EFI_Muz
Thank you David,


Can you please give me some direction for correcting the timing or slowing it down in HW_ARM_defines.h

I can run the demo code and the display does "work". The issue is that artifacts from the previous screen remain when the screen is rewritten.

If I run a particular piece of code to rewrite a particular screen three or four times over the picture actually looks quiet good.


Please see attached picture of board.

The display only has two identifiable marks on the PCB, TFT070TN92 & 1982AY-TF. (I think the TFT070TN92 refers to the actual display)
   Processor, ALTERA MAX II EPM570T144CSN.
   SDRAM, Winbond W9864G6JH-6.

ZinggJM

You have learned to provide the information needed.

Now you need to learn to read - the answers that have been given.
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

david_prentice

It looks as if your display was made by Sainsmart.   I am sure that several owners are on this forum.
Perhaps Graham Lawrence will drop by within a few days.

Regarding slowing down the interface:   these are the original macros:
Code: [Select]

#define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask);
#define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask);

extend the pulse width with:
Code: [Select]

#define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask);
#define pulse_low(reg, bitmask) cbi(reg, bitmask); cbi(reg, bitmask); sbi(reg, bitmask);


You could extend the cycle with:
Code: [Select]

#define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask);
#define pulse_low(reg, bitmask)  cbi(reg, bitmask); cbi(reg, bitmask); sbi(reg, bitmask); sbi(reg, bitmask);


Something like sbi() or cbi() will not be optimised.

Looking at the USE_DUE_16BIT_SHIELD in my MCUFRIEND_kbv library:
Code: [Select]

#define write16(x)    { write_16(x); WR_ACTIVE; WR_STROBE; WR_IDLE; WR_IDLE; }

I have obviously used one extra cbi (i.e. WR_ACTIVE) and two trailing sbi (i.e. WR_IDLE)

I doubt if UTFT would need all of these delays.   You would notice missing or corrupt pixels in a fillRect() call.  

David.

EFI_Muz

Jean-Marc and David, you guys are geniuses.

It works perfectly. Thank you.

This was sufficient to correct what ever was going on.

Code: [Select]

#define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask);
#define pulse_low(reg, bitmask) cbi(reg, bitmask); cbi(reg, bitmask); sbi(reg, bitmask);

david_prentice

An 84MHz Due has a 11.9ns clock cycle.   I would be amazed if a Due can achieve cbi() in one clock cycle.
On the other hand,   if I had to use two cbi() for an SSD1963 perhaps the Cortex-M3 output driver does achieve 11.9ns.   (the SSD1963 requires minimum tPWLW=12ns pulse width,  tDSW=4ns is not significant)

I would never expect UTFT to have timing problems.   Perhaps the Compiler has done something new.
And we seem to be talking about 0.1ns i.e. 100 picosec !!    Pcb track length becomes significant.

David.

EFI_Muz

Well the tracks are pretty long, they go right past a SMPS on the board.
It may just need the data on the bus that bit longer to become stable.

If there is anything (testing) I can help with please let me know.

Thanks again.

Paul.

Go Up