I'm very new to electronics, but picked it up since I need it for a project i'm working on.
I have an Arduino Uno and a "ILI9325 TFT LCD Touch 2.8". The goal is to display images on the LCD, touch is not needed to be set.
Image of the LCD, which has 2 x 20 pins:
Image of the pin layout:
Now on a tutorial page for another LCD, it says the basic setup is:
DB0 to DB7 > Arduino D0 to D7 respectively
RD > 3.3 V
RSET > A2 (I suppose this is "REST" on this LCD module?)
CS > A3
RW > A4 (I suppose this is "WR" on this LCD?)
RS > A5
backlight 5V > 5V (Which pin?)
backlight GND > GND
My questions to you:
Is there other way besides soldering to connect the wires to the LCD?
Do you think the REST pin is the same as the RSET pin?
Do you think the WR pin is the same as the RW pin?
Is there other way besides soldering to connect the wires to the LCD?
Do you think the REST pin is the same as the RSET pin?
Do you think the WR pin is the same as the RW pin?
Which pin do I connect the backlight pin to?
Thanks for your help!
Joost
You can use an IDC connector which crimps onto a ribbon cable to connect wires/ribbon cable to the LCD (see MANTECH Electronics for example). If you only need to connect to the LCD data and control pins you don't need that many connections and you could use SIL sockets (www.mantech.co.za/Stock.aspx?Query=SOCK+SIL+STR+HOUSED+2.54and) but then you'll need to solder wires to the socket pins. You can also use SIL housing (http://www.mantech.co.za/Stock.aspx?Query=housing+SIL+2.54and) but this requires that you crimp wires on terminals, not all that easy without a proper crimping tool. Perhaps the easiest would be to get hold of an old IDE hard drive ribbon connector (What is IDE?), I think it should fit.
I'm fairly sure you can assume that REST = RSET and WR = RW.
Backlight pin is probably LED_A.
I suggest you try and find a tutorial/code/description for your specific LCD board, because the LCD controller chip is only rated to work with input voltages up to 3.3V. Some boards put in voltage shift IC's which makes them compatible with the Arduino 5V output. There are also different data transfer settings (8 bit, 16 bit, SPI). If you only push 8 bit data but the controller is configured for 16 bit data you will have an obvious problem. If it is configured for 8 bit transfer, you need to know whether you must connect to DB0-DB7 or DB8-DB15. I have an LCD board which is configured for 8 bit transfer, but have to use pins DB8-DB15.
Are you working with the raw LCD without being attached to the PCB and you're trying to connect to a 40 pin plastic ribbon cable, or is it a more complete module as in your picture, with the LCD mounted on the board and you are trying to connect to the two rows of pins?
(I'm currently in the middle of making an adapter board to plug a module like the one you have pictured, directly onto a mega2560 like a big shield)
I wasn't able to get things working so I sort of gave up a bit and orderd a pair of new panels and an actual adapter board. When the parts arrived, they still weren't working, so I knew it was a software issue.
I spent a little more time with the libraries and figured out how to make it work. I finally figured out what I was doing wrong, and the uTFT library works great, on all five of my LCD panels AND on my very iffy looking adapter board.
I strongly recommend the uTFT library. The author/maintainer of it however is strangely elusive when discussing support for new panels. I suspect he expects a sizable compensation to add support for new displays. I found proper drivers for the 2.4" display and he wasn't interested in adding support unless I somehow got the manufacturer to contact him. (even sending him a free panel and working code wasn't sufficient??) Owell, still a good piece of work he has there.
The uTFT driver is very flexible, and it's usually a matter of (1) selecting the correct chipset, and (2) wiring it up right. Without knowing precisely what chipset is on the board the panel is mounted to, it's difficult to give advice. Fortunately though, the 2x20 pinout is an actual standard, so once you get it wired up you're good to go.
Thanks. I'm getting an error uploading to my Uno - not enough memory I think is the problem.
Which arduino are you using? The only other arduino I have worth trying is a new Due.
And this is 8-bit parallel mode?
Texy
The uTFT library is MASSIVE unless you comment out the chipset drivers you don't need. All of them are enabled by default, and the whole library itself will probably not fit on an uno.
I use mostly mega2560's and their various clones. (256k of memory) Most of the shields for these display modules are meant for the mega or mega2560 because of the amount of pins you will want to use. 16 total digital pins for the display itself, if it's running in parallel. You really don't want to try to feed a display THAT big via serial, the updates would be painfully slow. A lot of the chipsets can run in serial or parallel mode though.
After you have the 16 digital pins, you need three more digital control pins, plus a few for the touch control, and another for the backlight. Really not practical to run one of the bigger LCDs on anything short of a mega.
(is anyone else getting "To view this page, you must log in to this area on www.qbasiq.com:80:" popup twice anytime they open a thread here?? I am logged in)
I got the HY28B 2.8" ILI9325C display to work with my Uno. The problem was not lack of memory, but the Uno chip had got corrupted so I reloaded the bootloader and all is well. Of course the Uno doesn't have much memory left after loading the default UTFT library, but at least it works. So I then moved over to my Due, but I can't get that to work - just a blank screen. I tried various different control line connections, but no joy so far. The display is set to 8 bit parallel.
Any further help appreciated.
regards,
Texy
huh. never heard of a bootloader going bad. suppose it happens sometime though. glad to head you got it working. yes, the megas are kinda pricey. I generally have been buying name brand one or two of arduino gear, and if I find I need more, I go generic. support the designers but don't abuse the wallet, if you know what I mean.
Thats certainly a good thing that is working with your uno, so we can rule out a faulty display.
First i find it quite odd that that display manufacturer is already offering code for the Due. most likelly you are using the code for the mega!? If so you need to check that all pins are compatible and they are being mapped to the correct place.
I am not yet familiar with the due. I ordered one a few days ago, but hasnt arrived yet. From experience with the maple I can tell you there are often some bugs and some libraries need to be ported. Even tough this is a arduino product it is quite likelly that some things are not quite 100% compatible. It is a good thing that it compiled with no errors, but even so you should check the signals with an oscilloscope to make sure you are in fact getting something on the display pins and that is not defaulting to 16 bit mode data transfer.
lastly, I dont see a level shifter on the PCB (altough there might very well be one), is that display 5V tolerant? Just because it can be supplied to 5V it doesnt mean that the data lines are 5v tolerant so I would be very carefull about that. To remove any doubts I sugest you power your arduino from a 3V3 supply to verify that the display still works.
it's been awhile since I looked carefully over the utft documentation, but iirc there are differences between the different arduinos as to how they handle the displays. There is quite a lot of code forking going on in the drivers and in the core library depending on which arduino you are using. I ran into several discussions of certain displays not woring on certain arduinos. The due and the nano I believe were the biggest troublemakers. I saw a lot of that in the TimerOne library also, that may make for a shorter read if you're curious as to what kind of adaptations are necessary when switching between differnet models of arduino. TimerOne has to deal with some substantial differences in hardware timers between the models.
As for the level shifting, my adapter board got by fine using a swarm of 10k resistors. (bought a reel snippet of 203's off ebay!) It's difficult to predict how hardware will react to overvoltage. Sometimes it fries, sometimes it doesn't mind, and occasionally it degrades it to where it will work normally with the new voltage but never again at the old one. (LEDs are frequently that way, overcurrent them and they might cook up a bit to the higher current, and you will have to continue supplying the higher current to maintain their brightness, never working normally at their lower rating again)
I don't have a due myself, but those are 3.3 on the digital aren't they? So one possibility is that the uno cooked the digital lines a little and now they won't respond to 3.3 anymore?
As yes - I forgot the Uno is a 5v device, not a 3v3 one. However I have swapped back the 2.8" to the Uno and it still works. The 2.4" (which is also 3v3, and uses the IL9325C chip) still works on the Uno and not the Due. I am convinced it is software related on the Due side.
Texy
casemod:
That doesn't make any sense at all. Surelly with an LED it might be true, certainly not with an integrated device such as an LCD controller
Before I started fabricating my "10k resistor" level protecting shield I did a little research to see why resistors would convert level properly. It appears that the traditional way to level-protect on digital lines is to use zeners and fets. 10k is placed in series in the "poor man's level converting shield" because it causes a safe amount of current to drop across the small protecting zeners in the chip (170uA) without dropping the signal out. This method should only be used with such protective circuitry in place, otherwise 5v through 10k will still be 5v on the other side of the resistor, and may do damage.
I checked my work with a scope and was pleasantly surprised to see nice crisp digital square waves right at 3.3v on the other side of my resistors on the adaper shield I fabbed, verifying that my LCD panels had the required protection on their inputs. (you cannot test for this using a DVM unless you hold a pin high, they can't measure the peak on a digital signal)
I have no experience with how such a level-protecting circuit reacts to unmanageably high current, but I have no reason to believe that it can't degrade its specs in a way similar to an LED that is run overcurrent, as one possible outcome. I do know that if you try to stuff 5v directly into a basic protector like that you will cause current far in excess of spec on the zener. The more complex protectors don't have that issue and are ok with any current level on the input, at up to much higher voltages. (25v etc) I assume those use input directly to fet without the zener, though they may require pull-up or pull-down resistors externally.
Someone with some "expendable hardware" would need to verify this, and ymmv depending on who fabbed the display driver IC etc.
Hi again,
I forgot I had a pro mini 3v3 arduino and hooked up my display to it.....and it is working fine.
So I still think it is related to the Due code somehow, and no damage to my display.
regards,
Texy