Have you ever driven a 16x2 I2C LCD?

Go To Last Post
90 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bought one of these inexpensive 16x2 I2C LCDs on Amazon.  There's no documentation, but I figured how hard could it be to get up and running, since I've used UART-interfaced ones before?  I can get it to respond to my ATMega328P, but I can't get it to display text, or control it in any reliable, comprehensive way.  There are endless discussions for using these in an Arduino environment, but I haven't been able to find any discussions about controlling them with bare metal, and the Arduino code is too abstracted for me to follow along.  I've found a variety of manuals for the plain LCD (the I2C interface is a tacked on board with just an I2C port expander on it) that are generally consistent, but not sufficiently informative.  Has anyone here gotten one of these to work with plain C code?  Thanks for any tips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you ever Googled?
https://www.avrfreaks.net/forum/cant-get-my-lcd-1602-i2c-work-atmega328p

Arduino IS bare metal! Seems the smoke and mirrors fool some into believing otherwise

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
how hard could it be ...

laugh laugh laugh laugh laugh laugh 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Arduino IS bare metal!

It seems that many (most?) here would disagree: https://www.avrfreaks.net/forum/what-does-bare-metal-mean-you

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
There are endless discussions for using these in an Arduino environment

So why don't you take one of those as reference, and work from there?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is nothing clever about driving an I2C backpack.

 

The LCD requires certain wiggles and timing on its control pins and data pins.

 

You either write the the individual bits from random AVR PORTx bits connected to the LCD pins

Or you group the bits in one 8-bit register on a Port Expander like PCF8574.    And send the 8-bit value via I2C

 

Achieving one "lcd_command" involves about 5 states on the 8-bit register.   i.e. to set control bits and do two wiggles.

 

David.

Last Edited: Thu. Mar 8, 2018 - 08:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have thousands of them in production units.

They do have a propensity to lock up the I2C interface if the lines see any random edges so the reset line is worth implementing. Other than that they just need instructions which mimic the HD44780 ones. Including the initialisation sequence.

I am not in the office today but can post some code tomorrow if needed.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Google Davide Gironi I2C LCD for AVR. He has modified Peter Fleurys LCD library for use with I2C. I use this and it works very well. Plenty of support for it as well

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should point out: There's an Adafruit library for driving these which supports an i2c GPIO expander for their "backpack" for these. It works, but it's very slow due to some serious inefficiencies in the code. (I don't think the person writing the code was thinking much about how an i2c->gpio expander works.) But note also that you have to adjust it, potentially, depending on how the i2c interface is implemented.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Think about it.   The PCF8574 is a 100kHz device.    I use 5 states per write_command() or write_data().    I believe that Bill Perry does it in 4 states.

 

(1 + 5) x 90us = 540us    .... note that the i2c_start(address) takes as long as an i2c_write(value)

(1 + 4) x 90us = 450us

 

Using the native parallel interface takes a typical 38us.     50us is a "safe" time.

 

Most Arduino libraries do not achieve the theoretical times.    But seriously.    No normal human can read an LCD screen in 540us and even Einstein would be unlikely to read pixels in 38us.

 

Updating an LCD too frequently (i.e. when unnecessary) gives a very unpleasant experience for the human.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was seeing lag time closer to 2-4ms for operations. For instance, imagine that you need to toggle the enable pin.

 

Consider code which does:

1. i2c read of gpio state

2. or in the enable pin bit

3. i2c write.

4. one-microsecond delay on AVR side

5. i2c read of gpio state

6. and out the write enable pin bit.

7. i2c write.

 

so four operations for the enable pin, and those four operations are *after* the operation which set the other bits.

 

... I'm not totally sure whether that's all bad. I can't figure out from the specs whether the device reads the data pins when enable goes high, or when enable goes low. if it's reading them when enable goes high, you probably do want the enable pin to go high separately from the point at which the other pins are set.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
So why don't you take one of those as reference, and work from there?
lautman wrote:
the Arduino code is too abstracted for me to follow along.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
I am not in the office today but can post some code tomorrow if needed.

 

That would be great, Brian.  Thanks, in advance.  Driving an I2C LCD is easy IF you know what "wiggles and timing on its control pins and data pins" are required.  If you don't, you're just stumbling around in the dark.  Even if you do, if you don't also know the proper initialization sequence, you're hosed.  The documentation I've come across is only marginally better than useless.  Combine all that with having to go through an unfamiliar I2C library and the likelihood of getting the thing to work is de minimis, at least for me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
Driving an I2C LCD is easy IF you know what "wiggles and timing on its control pins and data pins" are required.

But if you don't know that, then your issue is not with the I2C part - is it?

 

Clearly, you need to understand the operation of the HD44780 before you start thinking about how to transfer that over I2C!

 

If it's the basic operation of the HD44780, then that's been around for donkeys years - long before the Arduino was even a twinkle in Massimo Banzi's eye - so there's no shortage of non-Arduino examples for that!

 

Peter Fleury's library has already been mentioned ...

 

http://homepage.hispeed.ch/peterfleury/avr-software.html

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
Driving an I2C LCD is easy IF you know what "wiggles and timing on its control pins and data pins" are required.  If you don't, you're just stumbling around in the dark.  Even if you do, if you don't also know the proper initialization sequence, you're hosed.  The documentation I've come across is only marginally better than useless.  Combine all that with having to go through an unfamiliar I2C library and the likelihood of getting the thing to work is de minimis, at least for me.

 

As I said in post #8 here you go:

 

http://davidegironi.blogspot.com...

 

Combines the ease of Peter Fleury's original library for use with I2C.  I can look and see if I still have my experiment code I did before implementing into the final device if you want it.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the basic operation of the HD44780, then that's been around for donkeys years - long before the Arduino was even a twinkle in Massimo Banzi's eye

I remember using one around 1986!  We didn't have a fax machine yet, so they had to mail the datasheet.  Later, I got the databook.

 

 https://www.crystalfontz.com/blog/look-back-tech-history-hd44780-controller-data-sheet/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

lautman wrote:
Driving an I2C LCD is easy IF you know what "wiggles and timing on its control pins and data pins" are required.  If you don't, you're just stumbling around in the dark.  Even if you do, if you don't also know the proper initialization sequence, you're hosed.  The documentation I've come across is only marginally better than useless.  Combine all that with having to go through an unfamiliar I2C library and the likelihood of getting the thing to work is de minimis, at least for me.

 

As I said in post #8 here you go:

 

http://davidegironi.blogspot.com...

 

Combines the ease of Peter Fleury's original library for use with I2C.  I can look and see if I still have my experiment code I did before implementing into the final device if you want it.

 

Jim

 

Thanks, Jim.  I'll give that a look.  I agree it's more promising for my application than Peter Fleury's since it appears to be targeted specifically at these displays rather than being a generic I2C driver.  And, by no means do I mean to cast shade on Fleury's work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What AVR are you using and at what clock speed?

 

Jim

 

EDIT:

From your OP I see Arduino so I am gonna guess an UNO which would be 16Mhz.  I attached a ZIP file with Gironis project with the USART stuff removed as it always kicks up a fuss.  The project is set up for 16Mhz clock on a Mega328.  I tested on a Mega324 as thats all I have handy at the moment but I know it works, and changed the target to Mega328 for you already.  You need to set the address so that all the address pins are at logic '0' (low).  From the pictures on Amazon I cannot tell what the A0..A2 pins are at.  the project is addressed for a PCF8574.  Not the PCF8574A.  You will need to determine what device your display has.

 

Here is what you should see if it works:

 

What you should see is the above picture, but the display will blink every second or so and re-paint the text.  I did this on purpose so that if you have your SCL/SDA lines backwards you can reverse them with the power on and the display will simply start right up.

 

Jim

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Mar 9, 2018 - 02:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> What AVR are you using and at what clock speed?

 

Thanks so much for this, Jim.  I really appreciate the effort, but, alas, I'm trying to do this without resorting to Arduino (I only mentioned it in my OP to indicate that that was what the rest of the world only seemed to be interested in) as there are other things I'll be doing in this project that I'd prefer not to use an Arduino for.  So, I'm using an ATMega328P at 8 MHz (I realize some would say, "Same thing," but, please).  I've already gotten the display to work fine on an Uno (to confirm it works) using the stock Wire, LCD, and LiquidCrystal libraries.  Trying to figure out how they work, however, as each references another, is beyond me, unfortunately (reminds me of Inception), because I'm just a spaz, I guess.  I've even put a protocol analyzer on SDA and SCL to observe the packets going by, in the hope of getting Fleury's code to send the same stuff, but that's pretty slow going, too.  So far, I haven't been able to get Gironi's code to compile in AS7 due to the UART issues you mentioned, so I'm not sure that's going to work either.  In his comments he notes he developed it in Eclipse, which I have no experience with and would prefer not to jump into just to solve this issue.

 

Karl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so then all you do is modify the project I posted for 8Mhz. My project is NOT an arduino project.  Its an Atmel Studio 7 project.  I only mentioned Arduino based on your OP.

 

I'll modify it for you as there are a few sneaky spots in it that took me a while to iron out.  I'll post it in a few minutes.

 

JIm

 

EDIT:

 

See attached for 8Mhz

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Mar 9, 2018 - 03:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!  Where do you set the LCD's address?  Is it PCF8574_ADDRBASE+deviceid in pcf8574.c?  I have the A part, so I need to modify it.

 

Karl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its in the pcf8574.h file.  For the A part you do the following:

 

Change this:

#define PCF8574_ADDRBASE (0x20) //device base address

to this:

#define PCF8574_ADDRBASE (0x38) //device base address

 

This is assuming that all three address lines are at logic zero

 

I have attached the datasheet for your reference

 

Jim

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the datasheet, though I had it.  The display is still unresponsive, unfortunately.  The scope show's the clock's coming out on SCL and the data on SCA, so I suspect there's still an address problem.  The address indicated on the scope when using #define PCF8574_ADDRBASE (0x38) is 0x70, but the address that I was using with Fleury's code is 0x7e, and that's what comes out on the bus (I also verified it when testing under Arduino).  As I said in the OP, this also got a response from the display.  There are no jumpers or resistors on the address inputs on my board, even though these aren't supposed to float, according to the datasheet.  If we assume they float high (even though the ds says they don't), that would indicate an address of 0x7e for a write, and 0x7f for a read.  In fact, if I change the #define to #define PCF8574_ADDRBASE (0x7e), the display rhythmically flickers, as it does when I use Fleury's code.  So, I think 0x7e is the address, but it's still not accepting the data.  The scope says the clock is 50 kHz, so that may be the issue, but I don't know how to adjust it in your code.  Of course, it may be something else entirely.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Btw, I just verified that SCL is 100 kHz on the Arduino.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before even messing with the LCD, can you prove that each I/O line of the PCF8574 is properly controllable? Until you can 100% control each I/O line going to the display, it's senseless to try to get everything working in one swoop.  Once the 4-8 I/O lines are verified working, you can move on to ensuring the proper commands are being generated to be transmitted. Thereafter a simple handful of bytes sent to the lcd should say "hello".

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like the setting is F_CPU in twimaster.c.  I changed it from 16000000UL to 8000000UL and that resulted in a 100 kHz (well, 102.9 kHz) SCL.  Still, the display just flashes at about 1 Hz.  The data I'm seeing on the scope loops every second, as it does in your code, but the data doesn't decode to any of the text in the program, or any text at all, since all the bytes are below 0x41.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Before even messing with the LCD, can you prove that each I/O line of the PCF8574 is properly controllable? Until you can 100% control each I/O line going to the display, it's senseless to try to get everything working in one swoop.  Once the 4-8 I/O lines are verified working, you can move on to ensuring the proper commands are being generated to be transmitted. Thereafter a simple handful of bytes sent to the lcd should say "hello".

Well, since the display works fine when being driven by an Arduino, I assume all the h/w is OK.  I'm also getting valid I2C signals from my 328P, so I can only think there's a problem somewhere in the s/w.  I don't want to take anything for granted, but I don't see how a h/w problem would manifest in one scenario but not the other.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The Arduino is known good hardware. How have yiu connected up your mega328? Maybe it resets when the backlight is turned on?
Show us a picture of your hardware setup.

If the Arduino code is using i2c address 0x7e, then you’ll need to change the address to 0x3f.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I assume all the h/w is OK.

This is not to test the hardware per se; it is to test whether your micro (not your Arduino) is reliably controlling the I/O expander.  If that is not first happening, then getting the display running is hopeless.  If not checked already, verify you can fully control each expander I/O pin from your micro/libraries/code.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There might be some ideas here- especialky regarding the address. There’s mention of running an i2c scanner.
https://forum.arduino.cc/index.php?topic=128635.0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At least lautman is prepared to test with the Arduino.

He could install Bill Perry's hd44780 library with the Library Manager.

Then run the diagnostic sketch.

 

This would report the Slave Address,  presence of pullup resistors,  wiring of the PCF8574, ...

Copy-paste the report from the Serial Terminal to your message.

 

There is nothing difficult about controlling a 16x2 LCD via its pins from an 6-pin PORT providing you obey the timing sequences in the datasheet.    But we get new posts every week from users who are determined to flout the datasheet.

 

If you can control with regular AVR GPIO pins,   you do exactly the same via your I2C chip.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I forgot about the setting in twi master.c. My apologies. If the display is flashing then it's working. Try turning the pot on the board as the screen contrast may be slightly off.

Jim

Edit. What is your power supply ratings? I would recommend a 5v/500ma supply. The LCD is power hungry, plus your AVR circuit. I know they both combined do not dare 500ma but 5v/500ma is an easy supply to obtain

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Mar 9, 2018 - 12:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recommend that developers start thinking of using TFT displays instead of LCDs as a starting point for visual feedback to their users.  A 128x128 basic TFT with an ST7735r controller costs about $3-4 while a 16x2 HD77480 LCD costs about $2.  But the TFT is smaller and can display 16K pixels of information (in color) while the LCD (at 16x2 chars) displays @1000 pixels of monochrome information.  True, you need to load a character generator table at 400-500 bytes and the initialization sequence can be complex if you're doing it yourself.  But the Arduino libraries show the init sequences needed for the TFT controller.  

  With a little more expense (about $5-6 per unit) you can get a 320x240 display with a touch screen to meet all your most advanced user-interface needs without buttons, potentiometers, etc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Sorry I forgot about the setting in twi master.c. My apologies. If the display is flashing then it's working. Try turning the pot on the board as the screen contrast may be slightly off. Jim Edit. What is your power supply ratings? I would recommend a 5v/500ma supply. The LCD is power hungry, plus your AVR circuit. I know they both combined do not dare 500ma but 5v/500ma is an easy supply to obtain

If your 16x2 is power-hungry it has not got a series resistor on the backlight.

Some modules have a sensible resistor mounted on the pcb e.g. 47R or 100R.   Others just have 0R.

 

I would expect a 16x2 to draw about 50mA with the backlight.   A few mA without the backlight.

 

This applies to many items from Ebay.   If the backlight is too bright,  it needs a current limiting resistor.

16x2 expect 20-50mA

128x160 TFT expect 50mA

240x320 TFT expect 80mA

320x480 TFT expect 120-200mA

7 inch 800x480 TFT expect very high currents.   External power supply is wise.

 

Most smallish projects can be powered by USB.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The power supply is clamped at 2A but the circuit is only drawing 45 mA.  Below are some picS of my setup and one of my scope showing the I2C info is legit.  Note the address is 3F now that I've set it to 7-bit decode, stripping off the R/W bit.  Here's a link to a short video clip of the display flashing.  Adjusting contrast changes the contrast but doesn't cause text to appear.

Last Edited: Fri. Mar 9, 2018 - 09:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I watched teh video, That blinking means that the data is working as the screen blinking like that is the code resetting.  So your communicating properly.  If you remember I said that his would happen so you could simply reverse SCL/SDA in case you might have gotten them backwards...the code keeps resetting so you could swap them without having to remember to reset the AVR each time.

 

This means that there is something wrong with the display. or the board.

 

I do not know what I need to do in order to upload a video to YouTube otherwise I would of my setup showing it blinking as well.

 

But that blinking means that the code is addressed properly and is talking to the adapter.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where are the bypass capacitors?
I can’t make sense of the i2c decode on the ‘scope - count the number of clocks per segment.
The wiring also seems highly suspect - wires poked into connectors is not a good recipe.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I realize the setup's a little janky, but it IS a breadboard.  ;-)  Anyway, if I plug the corresponding four wires from an Arduino Uno into that same connector, the LCD displays the text from the Arduino sketch, so I don't think there's anything wrong with the h/w.  I'm guessing the LCD isn't being initialized properly, but Jim says this code works for him on his 328.  In any event, if you (Jim) could point me to the initialization sequence you're using, maybe I could build on that?  That's one of the big holes in the manuals I've found:  there's clearly an initialization that's required, but it's hard to understand what it is, and it's hard to figure out what the I2C code is doing to accommodate it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I figured out how to upload:

 

https://youtu.be/4MnmMAhxm3M

 

Jim

 

I did this on a mega324 not a 328, but the TWI is the same on both units.  I will set up a 328 tonight and see if there is any difference.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Mar 9, 2018 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seriously.   You have an Arduino.   You connect SDA, SCL, 5V, 0V to the LCD and away you go.

 

Having verified that the LCD works with Bill Perry's "hd44780.h" library,   you paste the diagnostic output.

 

Without ANY change of hardware wiring,   you upload your homebrew C code to the Uno.

This means that you can verify your C code.   And can go back to Arduino code at any time.

 

Life is much easier if we can see your diagnostic report.

Mind you,   I do recognise your Adapter so I know the wiring.

 

Of course you have chosen NOT to post/attach your C code.

 

When you have finished developing on your Uno hardware,   you can upload the proven code to your flaky breadboard.

 

I am constantly amazed by people who spend $1000 on a scope but are not prepared to buy a single 100nF capacitor or use proper connectors.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Of course you have chosen NOT to post/attach your C code.

 

He is using the project I created at the moment David....

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would you have ANY confidence in the breadboard from #35 ?
.
If we saw respectable wiring from a Uno to LCD, any problems would be down to the software.
.
I will run your project on a similar Adapter.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do the signals going to the LCD look like--are they as expected?  Does the schematic definition of the expander outputs (LCD pins),match up to the software definiations?  A swap of E & R/W, for example would cause  nasty surprises. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok,   I built your project in AS7 and ran it on a similar Adapter (which has a PCF8574).

 

Since it was a Uno,   I added F_CPU=16000000 to the Project Symbols.   And commented the F_CPU in main.c

 

My PCF8574 is 0x27

My PCF8574 is similar to lautman's Adapter.   So I made the corresponding defines in lcdpcf8574.h:

#define LCD_DATA0_PIN    4            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    5            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    6            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    7            /**< pin for 4bit data bit 3  */
#define LCD_RS_PIN       0            /**< pin  for RS line         */
#define LCD_RW_PIN       1            /**< pin  for RW line         */
#define LCD_E_PIN        2            /**< pin  for Enable line     */
#define LCD_LED_PIN      3            /**< pin  for Led             */

Your program ran ok.

 

But most importantly.    Running I2Cexpdiag from Bill Perry's "hd44780.h" Arduino library gives:


********************************************************************
Serial Initialized
--------------------------------------------------------------------
I2CexpDiag - i2c LCD i/o expander backpack diagnostic tool
--------------------------------------------------------------------
hd44780 lib version: 0.9.0
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.3
CPU ARCH: AVR - F_CPU: 16000000
--------------------------------------------------------------------
 A4: digital pin: 18
 A5: digital pin: 19
SDA: digital pin: 18
SCL: digital pin: 19
--------------------------------------------------------------------
Checking for required external I2C pull-up on SDA - YES
Checking for required external I2C pull-up on SCL - YES
--------------------------------------------------------------------
Scanning i2c bus for devices..
 i2c device found at address 0x27
Total I2C devices found: 1
--------------------------------------------------------------------
Scanning i2c bus for all lcd displays
 LCD at address: 0x27 | config: P01245673H | R/W control: Yes
Total LCD devices found: 1
--------------------------------------------------------------------
LCD Display Memory Test
Display: 0
 Walking 1s data test:	PASSED
 Address line test:	PASSED
--------------------------------------------------------------------
Each working display should have its backlight on
and be displaying its #, address, and config information
If display is blank, but backlight is on, try adjusting contrast pot
If backlight is off, wait for next test
--------------------------------------------------------------------
Blinking backlight test: to verify BL level autodetection
If backlight is mostly off but
you briefly see "BL Off" on display with backlight on,
then the library autodetected incorrect BL level
and the library cannot autoconfigure the device
--------------------------------------------------------------------
Displaying 'uptime' on all displays
--------------------------------------------------------------------

Note that this has diagnosed my Slave address and the PCF wiring:   One line tells you everything.

 LCD at address: 0x27 | config: P01245673H | R/W control: Yes

 

David.

Last Edited: Fri. Mar 9, 2018 - 11:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a really neat utility David! I am going to look at that later tonight.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Mar 9, 2018 - 11:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll stay out of the code discussion, but:

 

it looks like if you are using a M328P then you should have 2 V+ to Vcc connections, and a V+ to AVcc connection on the micro.

You should also have 3 Ground connections on the micro.

 

You should put a 0.1 uF cap across each of the three above power pin pairs.

Ideally you would sold them onto the little breakout board, adjacent to the micro's pins.

Plan B is to put them in the breadboard.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I know,   there are only two "likely" wirings.   i.e. your one with DB4..DB7 on P0..P3 and my one with DB4..DB7 on P4..P7

Bill Perry is the expert.   He has encountered many Adapters.

 

The main problem with Arduino is multiple libraries with the same LiquidCrystal_I2C class name.    All with incompatible methods and assumptions.

Most of these problem libraries are NOT supported by the Library Manager.

 

hd44780.h should be installed via the Library Manager.

 

Bill can diagnose most hardware and even configure it correctly for the user.

 

All the same,   the Arduino forum still gets I2C Backpack questions every day.

 

David.

Last Edited: Fri. Mar 9, 2018 - 11:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

I'll stay out of the code discussion, but:

 

it looks like if you are using a M328P then you should have 2 V+ to Vcc connections, and a V+ to AVcc connection on the micro.

You should also have 3 Ground connections on the micro.

 

You should put a 0.1 uF cap across each of the three above power pin pairs.

Ideally you would sold them onto the little breakout board, adjacent to the micro's pins.

Plan B is to put them in the breadboard.

 

I'm not using the AD so I haven't hooked up AVCC, but all the grounds are connected.  Just added the caps:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You MUST connect AVcc regardless if you use the A/D or not!  From the datasheet

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Sat. Mar 10, 2018 - 02:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops.  OK, it's connected.  No change in the display.

Last Edited: Sat. Mar 10, 2018 - 03:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well,

Since you say it works with the Arduino Sketch, and I say it works..I uploaded a video to prove it.  David has also confirmed my project works, the re MUST be something up with the display lines connections as the blinking LED tells me that the PCF is getting the data.  Can you post the arduino sketch you used?  I'll take a look at whats going on and see if there is a difference.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Pages