I have ran the I2C scanner address code and found this device @ 0x27. I have tried a few different libraries, including the OpenLCD is an LCD with Serial/I2C/SPI interfaces.
By: Nathan Seidle
SparkFun Electronics
Date: April 19th, 2015
for The Sparkfun SerLED here:
This device was found at address: 0x72 and this device functions correctly. In an attempt to make the YC1602A-Y function, using the code that had worked for the Sparkfun device, after changing the address to match the address found by the scanner, the YC1602A-Y just blinks, no characters. I have tried code from a few different libraries, to no avail. Tutorials on this subject no longer have images associated with them so I am at a loss finding the answers. This device is 3.3v, so I believe no additional resistors are necessary. If anyone has already connected these devices (3.3V 1602 16x2 LCD Display Module w/HD44780 Controller / IIC Adapter For SPI or Paraller 51 STM MCU), please provide the necessary libraries and code. TIA
However, be aware that the Argon can only accept 3.3V on any of its GPIOs, so when the board has 5V pull-ups you may need to protect your I2C pins on the controller.
Thank you for your quick response. Yes, I had tried that library but still gave it another go with your code, I have power, but no characters. This is a 3.3v display item. They also offered a 5v version, but I am currently attempting to get this to work with the Argon, so I purchased the 3.3v version. Is the 3.3v display not compatible with a 3.3v board? … or do I need to add additional resistors? The reason I ask is that I had mentioned that this was the 3.3v version in the original message, yet you still warned me about voltage compatibility. The Sparkfun SerLED was also 3.3v and it worked without issue but that may have little reference here. I am supplying 3.3v power to the controller only. I have soldered the controller to the display. I have paired (soldered together) more than one of these (LCD & Controller) and the behavior is identical. Is it that I have purchased a 3.3v display that requires a 5v power supply to the controller? Could that possibly be the issue? If I supplied 5v to the controller, could it damage the display.
The risk always exists. Unfortunately I couldn't find any datasheets for that particular device, hence it's always better to be save than sorry.
That also goes for the 3.3V "rating" of the board. While the claims given on the advertisement should be trustworthy, double checking won't harm.
That's also something that can be tested on the board and/or datasheet but only guessed without.
You can try to follow the traces or measure the resistance between the I2C pins and Vcc.
Since you mentioned you had ordered multiple of these devices you may also want to check with another set.
If you can I'd also not directly solder the two together but rather use a (un)plugable connection
We have successfully used 3.3 volt 16x2 LCD displays on our RFID access control system:
We used the plain old LiquidCrystal library - worked just fine for us. Two things that you might want to check:
did you put a 10K pot wiper to the contrast pin and try adjusting the pot? If not adjusted properly, you won’t see the display.
Make sure that you use lcd.begin() in setup() and specify the correct pins. (LiquidCrystal lcd; )
We tested our displays with Photons but implemented the RFID stations using Argons (and Xenons – back in the mesh days). If the devices are rated at 3.3 volts, use only 3.3v supply for the lcd device and also across the contrast pot. All of the levels will be 3.3v, which are fine for Particle devices.
Our devices did not need any external pullups, in fact I’ve never seen a 16x2 LCD need external pullups (either 5 volt ones or 3.3 volt ones).
First off, thank you kindly for your help. I will try the 5v w/resistors to the controller. I assume you are talking about soldering a row of female connectors to it. That certainly sounds like an exceptional idea given that it could be a controller mismatch (controller 5v, LCD 3.3v). Again, TIA for your quick responses.
I certainly appreciate the help and effort with this. I am somewhat new to particle but not so much Arduino, but by no means ‘well versed’. It my be me but if I look at you .ino from your project the initiates the LCD, if I am reading this correctly, the LCD is hooked up in parallel mode?
// instatiate the LCD
LiquidCrystal lcd(A0, A1, A2, A3, D5, D6);
I am using to pins only SCL(D1) & SDA(D0)
If I pass just two variables into LiquidCrystal lcd(), I get an error.
I am using the HD44780 controller module, which only has 2 inputs other than VCC and ground.
I was looking to control this with the I2C interface as I need to utilize as few pins as possible. Looks like you are connecting the LCD up directly. Am I correct in this assumption that this direction won’t work for me with that criteria?
Maybe you should send a picture of how you soldered the I2C backpack onto the LCD? If you can talk to the backpack, it seems like the problem could be there.
To add to what @bko said, a picture of your exact complete wiring and setup would be ideal. I am still unclear on exactly what hardware you are using and how you have it all wired up.
I am unaware how I could have wired this incorrectly. I could purchase these items individually or together. I purchased these two items as a package. There are 16 pins that fit into 16 holes and there are images as to the placement in relation to each other, so one would not connect it upside down. When I connect this device to power, I see the LCD back light, lit. The controller has four pins. Ground, VCC, Data, and Clock. I have connected I2C devices before and the connection are Ground to Ground, VCC to VCC, SDA to SDA or DA, SCL to SCL or CL. When I run a scan of I2C devices, this device is found and shows up with an address of 0x27. So there is communication to, and from it. I have soldered 3 of these and they all behave the same. So I have power and communication, just no ability to have characters on the screen. Perhaps I should connect this to an Arduino, as I have seen a few examples of code for that. At least I could verify functionality. Then, upon verification, try to find the corresponding particle libraries.
You did a nice job connecting these–sorry to be skeptical but we have seen people not solder connections or blob solder all over shorting out the pins in the past. It pays to see what’s going on with your own eyes sometimes.
Have you taken a voltmeter and measured the voltage between the Vss and Vdd pins on the display yet? They should be 3.3V. Then measure Vss to pin 3 Vo. You should be able to adjust the blue square trim pot on the backpack board and change the voltage on Vo and the contrast on the display. At one extreme you might see nothing (as you have it now) and at the other the pixels seem to be all on. Find somewhere in between where you can just see them and try sending some characters to the display.
bko - Thanks.
“It pays to see what’s going on with your own eyes sometimes.” - I get that.
“Have you taken a voltmeter and measured the voltage between the Vss and Vdd pins on the display yet?”
3.28v
V0 to Pin 3 (D3?)
3.8v
If I turn up the pot, I get solid white squares.
I am extremely appreciative of the input from everyone regarding diagnostics with this issue. Although, I am quite certain this is not a hardware issue. We keep going down that road and I am not quite sure why. I am only trying to narrow the field of practical possibilities for expediency purposes. If I looked at this statistically, for example the soldering issue, in order for, as I had said, to have ‘all three device behave the same way’, I would have had to make the exact same mistake three times. Let’s say I only made a mistake on just one pin, pin 7 of 16. There are two states, working (soldered correctly) and non-working (soldered incorrectly). For the first board there are 2^16 (65,536) possibilities, as there could have been multiple, non-working pins and a myriad of pin sequences (1,5,9; 2,6,12,16). To have made the same error on the second board, being only one pin and that being the same pin, would be 1 in 2^16 (65,536). The probability of making this same error on a third board, being only one pin and that pin being 7, would be 2^32 or 1 in 4,294,967,296. So, this is why I believe this is not hardware related. I had found a particle article that had the code necessary in the forum, but all of the images with that code, are missing. I only get references to what those image contained. I tried other examples code from around the internet to no avail. I believe this should put the hardware aspect, to rest and isolate the issue to a library/code territory. Again, thanks for all of the help so far from everyone. Still in search for the answer to this issue though. These LCD boards are approximately 1/4 the price of a Sparkfun LCD and controller for example. In a situation where builds of thousands of these devices are used, this would be a great advantage financially. The responses from purchase are numerous, and positive, so I am led to believe this item functions correctly, given the right power / library / code.
You have a 16 character by 2 line (bog standard) LCD display–the HD44780 is under the larger black blob on the back on the display. It takes a parallel interface with either 4 or 8 data bits transferred at time. You also have a standard i2c to parallel convertor meant to directly attach with a PCF8574 i2c to parallel chip on in. That chip connects to the 4 bit data bus plus several of control signals (EN, RS, RW, etc. on the display).
Poking around I found this which looks very promising:
You may need to “port” this library to the Particle world or it may just work with Particle’s Arduino support. “Porting” is generally removing things that are not needed in Particle like WProgram.h. It looks like there are four files that you need, the LiquidCrystal_I2C.h and .cpp plus the I2CIO.h and .cpp. The later are not really needed on Particle but you need to either port that library or edit the main library LiquidCrystal_I2C to use Wire (i2c) directly.
