SparkFun Forums

[pellepl]

Yep that looks familiar - keep in mind though, that the SD13* GPIO signal going into the display DISP is supposed to be 2.5V - not 3.3V. A simple resistor divider worked for me, guess you could use a diode as well.

[seulater]

not sure I follow you.
are you talking about GPIOx going to the DISP pin?
refer to the Interfacing Sharp... pdf.

The Interface data sheet explains that the PIOVDD pin should be the same voltage as the LCD voltage of 2.5v

My next problem is if this S2D13742 has 3.3v compatible IO on the CPU bus side. if not then I have another problem.

[pellepl]

Ah sorry - yep, it's the GPIOx to the DISP pin I mean. The thing is, the GPIOx on the S1D13742 won't have PIOVDD level, but IOVDD level. On my PCB I used 3.3V on IOVDD as the memory bus interfaces a microprocessor running on 3.3V (and of course 2.5V on PIOVDD). So, you'd need to convert the GPIOx to 2.5V before feeding it to the DISP on the display, hence the diode or resistor divider.

As a matter of fact, when first trying the display out with an FPGA, I interfaced all the panels pins with 3.3V (slightly above max levels according to spec). This worked fine, however I don't know what it did to the lifetime of the display

[seulater]

Gotcha, thanks for pointing that out.

[seulater]

Does someone have a part# for the 2 pin LED connector ?

EDIT: i mean 4 pin, and i found it. hvymtlsteve said its a part # XF2L-0425-1A from digi-key.

[pellepl]

Hmm, would that be the four pin fpc you mean? I used an Omron one from Farnell - farnell part# 1430942, Omron part# XF2U-0415-3A

[pma]

I used the Omron XF2L-0425-1A before, and found it was too loose. It is designed for 0.3mm FPC, whereas the Sharp cable is 0.2mm.

I ended up using Molex 0513790473 (or 0513790471, which just has a different plating). Hard to find in distribution, but a few samples were readily available from Molex.

Regards,
Pete

[seulater]

Well, I just thought I let you all know that I finally wound up making a PCB using the S1D13742 and the LPC2378 ARM. IT works! Now its just a matter of getting the code all straightened out and work on the performance end of things.

[pellepl]

Cool! So, did you end up using a resistor divider or a diode for the GPIOx?

[seulater]

at the moment i am running the lcd @ 3.3v so i just ran the GPIO directly to the LCD.

[pellepl]

Ah - you're bold! On the other hand, one lousy signal being maximum rated shouldn't degrade the panel too much. As mentioned before, I ran all signals on 3.3v more than 60 hours constantly without noticing any problem.

[seulater]

well, I got the core of the Epson running @ 1.5v and the I/O @ 3.3v
The data sheet the max is 3.6v so im ok there.
The LCD sheet says Typ. 2.5, max 3.3 and Absolute Maximum is 4.5 so I felt ok it trying it out this way just to see if it all work work.

Though I have been successful in putting up .jpg on the screen, I noticed that when I go full balls out and say fill the screen red, green, blue over and over as fast as the processor can go, there are times when the panel stops working. It just heads off into the weeds. I took a look at things and when this happens the PCLK to the LCD go back to its original 4mhz clock instead of the 9mhz it needs. When this happens I have the uP read all the registers in the Epson and they all come back to the defaults. So somehow when I go balls out the Epson controller resets itself. I have tried this 4 different ways all with the same results in which the Epson looses its mind at times.

#1) Motorola 5270 processor, to which I used its address / data bus to connect to the Epson controller.
#2) Motorola 5270 processor, using its GPIO (general purpose I/O pins) to mimic the data bus.
#3) LPC2378 using address / data bus
#4) LPC2378 using GPIO

SO... Either I got a bad Epson part, or I am doing something I should not be, or what else I just don't know. when I write to it SLOWLY... It seems to be ok. But at that rate it would be pointless to even have it.

The next problem is according to the Epson data sheet, when you go into burst mode, you leave the CS# pin low, while you are clocking in the data using only the WR# pin. Now, I did not catch this when I was first looking at the part. I think I may go on another hunt to find a more uP friendly LCD controller. That has an actual address and data bus.

[pellepl]

Now, that is interesting!

I experienced exactly same thing using an ADuC7129 and an AT91RM9200. Doing it the GPIO way worked fine as long as I went slow, using the external bus worked partly and seldom. I tried different PLL clocks, 48MHz atmost if I remember correctly. The conclusion was the same- the S1D13742F01A2 resetted itself, at least it seemed so. Sometimes some registers were left unchanged after a "reset".

Hence, I did not dare post my schematics and gerbers here, since it didn't work (the constant risk of embarrasment ). I mailed Epson about this - about 3 months ago - and of course no reply. This made me lose the interest of going any further so I went on to other projects.

Would you find another suitable LCD controller, please let us know! I for one would gladly design a new pcb that is actually working.

Oh, anyone interested in some S1D13742F01A2 epson lcd driver parts by any chance - I'll sell them cheap

[seulater]

Well at least someone else is having the same problem. Thats good news.
I did find this uP, and its only $9.00 which is less than the Epson controller.
amybe i make a board with this one.
http://www.standardics.nxp.com/products ... 0/#LH79520

LH79520 from NXP.

[seulater]

as I have been poking around the net. I was looking farther that I should. If you look this kit from SFE: LPC-2478STK its using an color LCD, but what's more interesting is that there is no LCD controller on this board. If you go to olimex site and look at the skiz for it, its wired directly to the LPC2478. I have to look up the data sheets on that one, but its clear from the skiz that the LPC2478 is generating the PCLK and all signals for the screen.