LCDi2cR with Arduino 1.0.5 problems

Other Hardware Displays
1

Dear all.

I have been using the library LCDi2cR in my project to work with a C2042A 20x4 Display with Arduino 0023 for Mac with no problems. But recently I have updated to Arduino 1.0.5 and I start to have problems with the LCDi2cR library. Now when I compile the project I get:

In file included from Eletrovalve.pde:4:
/Users/Quintino/Documents/Arduino/libraries/LCDi2cR/LCDi2cR.h:25: error: conflicting return type specified for 'virtual void LCDi2cR::write(uint8_t)'
/Volumes/HDD/Quintino/Downloads/Arduino.app/Contents/Resources/Java/hardware/arduino/cores/arduino/Print.h:48: error: overriding 'virtual size_t Print::write(uint8_t)'

Does any one knows how to solve this? Maybe I need to change something on the LCDi2cR.h

2

I ran into the same problems with the LCDi2cR library on IDE 1.0.5. Then I found that someone updated the LCDi2cW library to work with IDE 1.0.2 (Index of /filevault/Electronics/Arduino), so I did a diff of the CPP and H file. Basically there are a few changes. So I did these same changes to LCDi2cR:

  • change the write method to return size_t instead of void (both CPP and H).
  • change all Wire.send to Wire.write (CPP)
  • change all endTransmission() to endTransmission(1) (CPP)
  • and change all Wire.receive() to Wire.read()

After I did this, the test hello world code compiles, HOWEVER, my C2042A LCD still doesn't display a damn thing aside from the bootup i2c address screen :frowning:

3

OMG! After days of banging my head against a wall, I got my C2042A Devantech LCD05 to work with LCDi2cR!!!!

So to get it to work, follow the steps to fix the LCDi2cR library as I outlined above, THEN, download the i2cLCDguesser.zip from this thread: [Tutorial] How to use an unknow I2C LCD library - Programming Questions - Arduino Forum ([Tutorial] How to use an unknow I2C LCD library - Programming Questions - Arduino Forum)

What the i2c guesser told me was that the bootup i2c address display was WRONG!! No wonder the LCD was behaving like nothing was talking to it, because nothing WAS talking to it.

My LCD's bootup shows the i2c address at 0xC6, but the i2cLCDguesser says it is at 0x63. I also ran the i2cScanner (Arduino Playground - I2cScanner) as well, and it said the same thing.

With this in hand, I opened the LCD_Test example in the LCDi2cR library, and used this:

#include <LCDi2cR.h>
LCDi2cR lcd = LCDi2cR(4,20,0x63,0);

And voila! It works!!!

Who'd thunk it, the bootup diagnostics address display (which I thought was amazingly useful) was the culprit this entire time.

Btw, the factory documentation is here:

http://www.robot-electronics.co.uk/htm/Lcd05tech.htm

It says the address range is: 0xC6 - 0xCE ( even numbers only ).

Well, mine is at 0x63, that's certainly not in above range.

Oh, also, I did originally try to add the pullup resistors between VCC SCL and VCC and SDA, but even when I connect the board's SCL/SDA directly to the Arduino's corresponding pins, it still works. The real key was the i2c address.

Good luck!

4

After getting my LCD05 to work, I emailed Devantech support. And they shed some light on the i2c address situation.

Apparently it is very simple, Arduino ignores the lowest bit in the i2c address, so my device's address is 0xC6, which in binary is 11000110. However, if you ignore the lowest bit, it becomes 1100011, which is 0x63.

I am going to suggest that they put this bit of critical information into the documentation, cause for n00bs like myself, this took forever to figure out.

5

borgchick:
After getting my LCD05 to work, I emailed Devantech support. And they shed some light on the i2c address situation.

Apparently it is very simple, Arduino ignores the lowest bit in the i2c address, so my device's address is 0xC6, which in binary is 11000110. However, if you ignore the lowest bit, it becomes 1100011, which is 0x63.

I am going to suggest that they put this bit of critical information into the documentation, cause for n00bs like myself, this took forever to figure out.

It would be better if they (Devantech) were to learn more about I2C addressing and use the correct terminology.

I2C addresses are only seven bits long so when correctly padded out to fit in an 8-bit byte the high bit will always be 0. As a result there are no I2C addresses larger than 0x7F.

In use the 7-bit I2C address is shifted to the left and the resulting available bit at the right is used to determine the direction of data flow. A zero indicates a 'write' and a one indicates a 'read'.

In your case the I2C address of the device is 0b01100011 or 0x63. When it is operating as a slave device and you are writing to it then the shifted slave address for writing is 0b11000110 or 0xC6. When it is operating as a slave device and you are reading from it then its slave address for reading is 0b11000111 or 0xC7.

Since the direction of data travel is determined by the software it should be the software that does the shifting and filling in of the least significant bit. In my opinion the writer of the software library should always have the user supply the actual unshifted 7-bit I2C address.

It seems to me that the manufacturers of the I2C devices have conspired to make this address almost impossible to find in their datasheets - but that is a different problem.

Don

6

Wow, thank you very much for the detailed explanation.

It certainly didn't help that the particular library that this LCD works with is called LCDi2cR, and this is listed on a page (Arduino Playground - HomePage) which also talks about a different library called LCDi2cW. But in this case I think the R and W has anything to do with read/write.

floresta:
It would be better if they (Devantech) were to learn more about I2C addressing and use the correct terminology.

I2C addresses are only seven bits long so when correctly padded out to fit in an 8-bit byte the high bit will always be 0. As a result there are no I2C addresses larger than 0x7F.

In use the 7-bit I2C address is shifted to the left and the resulting available bit at the right is used to determine the direction of data flow. A zero indicates a 'write' and a one indicates a 'read'.

In your case the I2C address of the device is 0b01100011 or 0x63. When it is operating as a slave device and you are writing to it then the shifted slave address for writing is 0b11000110 or 0xC6. When it is operating as a slave device and you are reading from it then its slave address for reading is 0b11000111 or 0x0xC7.

Since the direction of data travel is determined by the software it should be the software that does the shifting and filling in of the least significant bit. In my opinion the writer of the software library should always have the user supply the actual unshifted 7-bit I2C address.

It seems to me that the manufacturers of the I2C devices have conspired to make this address almost impossible to find in their datasheets - but that is a different problem.

Don