Helpful ReplyI2C connection to LCD screen (PIC18F4553 / PCF8574)

Page: < 12 Showing page 2 of 2
Author
dannyz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/02/27 10:11:54
  • Location: Iasi, Romania
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2014/11/06 19:52:00 (permalink)
0 (1)
Only PBADEN needed to change to OFF.
After that it was getting stuck because the I2C address was wrong, so yes, when it's not connected I don't get the ACK anymore.
 
I've read about the memory addressing and I've managed to write a char in any position. But the example I gave was using the internal address increment which I guess follows the same rules ... weird.
 
P.S. The arduino board is just the PCF8574 I/O expander and a variable resistor for the contrast. I don't think it does anything at all on it's own.
 
 
post edited by dannyz - 2014/11/06 19:57:14
#21
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 16:21:24 (permalink) ☄ Helpfulby katela 2017/08/17 10:47:13
0
I am having problems with a very similar design, and some of the information here may be applicable. I am using one of the inexpensive I2C => LCD interface boards available on eBay, and it seems to have a different schematic from the one used for the Arduino. My board is the same as this:
http://www.ebay.com/itm/IIC-I2C-TWI-SPI-5VDIY-Serial-Interface-Board-Module-Port-Arduino-1602LCD-Display-/201097851956
 

For the PIC16F876, this is the schematic I found on http://www.picmicrolab.co...al-lcd-interface-i2c/:

 
This seems more like what I have, although my board has a PC8574 and not the PC8574A which has a different address:
http://www.instructables.com/id/LCD-display-I2C-adapter-for-Arduino-with-PCF8574A/step2/Schematic/
 

 
However, my connections are:
 
LCD[4] = RS => P0
LCD[5] = RW => P1
LCD[6] = E => P2
LCD[7:10] = D0:D3 => N/C
LCD[11] = D4 => P4
LCD[12] = D5 => P5
LCD[13] = D6 => P6
LCD[14] = D7 => P7
 
I don't know if or where P3 is connected, or if the INT- line of the P8574 (pin 13) is connected. There seem to be 4.7k pullups on the SDA and SCL lines.
 
I am probably not performing the correct operations on the I2C SSP engine, and I might have the pins incorrectly set for analog, as was the case for the OP. Also, I may want to get the I2C library from the Microchip website. It seems that I don't have it on this computer, and my PIC projects have so far been very simple. I'm using a PIC15F1825 for this project, and I just want to be able to display information on a 16x2 display.
 
I'll get the library and also review my understanding of the I2C interface, and report back. There is a pretty good tutorial but it uses assembly code. That's OK, but I'd rather use C.
http://ww1.microchip.com/downloads/en/DeviceDoc/i2c.pdf
 
Thanks for any ideas. :)
post edited by PStechPaul - 2015/01/31 16:34:15

 
#22
dannyz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/02/27 10:11:54
  • Location: Iasi, Romania
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 16:32:32 (permalink) ☄ Helpfulby PStechPaul 2015/01/31 21:43:51
+3 (4)
I have uploaded the LCD library I ended up using.
Probably the initialization codes are different for your LCD. You might need to check it's datasheet.
 
The only difference between PC8574 and PC8574A its the address range. And it seems that all your addressing pins are connected to ground. Mine were connected to VCC.
 
P3 is probably the back light if it's connected.
 
It uses microchip's I2C library.
post edited by dannyz - 2015/01/31 16:47:46
#23
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 21:56:48 (permalink)
0
Thanks for the LCD library and other tips. I have tried to find the Microchip I2C library with questionable success. I downloaded the Microchip Libraries for Applications and it seems to have only an SPI library. I found the I2C.h file in my existing XC8 v1.30 includes folder, but the libraries appear to be individual files for each function, in the path:
 
C:\Program Files (x86)\Microchip\xc8\v1.30\sources\pic18\plib\i2c

 
#24
dannyz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/02/27 10:11:54
  • Location: Iasi, Romania
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 21:58:38 (permalink)
0
It's the same here. Just include i2c.h and it should work.
#25
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 22:17:16 (permalink)
0
OK, I'll try that. It seems that there are quite a few different versions of I2C for various PICs, so hopefully that gets sorted out by conditional compiles. For instance, there are three versions of "ACK":
 
#if defined (I2C_V1)
#undef AckI2C
void AckI2C( void )
{
  SSPCON2bits.ACKDT = 0; // set acknowledge bit state for ACK
  SSPCON2bits.ACKEN = 1; // initiate bus acknowledge sequence
}
#endif

#undef AckI2C1
#if defined (I2C_V2) || defined (I2C_V3) || defined (I2C_V5) || defined (I2C_V6) || defined (I2C_V6_1) || defined (I2C_V6_2)
void AckI2C1( void )
{
  SSP1CON2bits.ACKDT = 0; // set acknowledge bit state for ACK
  SSP1CON2bits.ACKEN = 1; // initiate bus acknowledge sequence
}
#endif

#if defined (I2C_V3) || defined (I2C_V6) || defined (I2C_V6_1)
#undef AckI2C2
void AckI2C2( void )
{
  SSP2CON2bits.ACKDT = 0; // set acknowledge bit state for ACK
  SSP2CON2bits.ACKEN = 1; // initiate bus acknowledge sequence
}
#endif

 
Oddly, it seems that I2C.h uses macros to define the functions. Like this:
 
#define AckI2C1() SSP1CON2bits.ACKDT=0, SSP1CON2bits.ACKEN=1;while(SSP1CON2bits.ACKEN)

#define AckI2C AckI2C1

#define AckI2C2() SSP2CON2bits.ACKDT=0, SSP2CON2bits.ACKEN=1;while(SSP2CON2bits.ACKEN)

#define AckI2C() SSPCON2bits.ACKDT=0;SSPCON2bits.ACKEN=1;while(SSPCON2bits.ACKEN)

 
Hopefully, then, I can just use the more generic AckI2C for all flavors, and similarly for other functions.
post edited by PStechPaul - 2015/01/31 22:38:53

 
#26
dannyz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/02/27 10:11:54
  • Location: Iasi, Romania
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 22:35:38 (permalink)
0 (1)
Those are because some chips have more than one I2C peripherals.
And you use AckI2C1 and AckI2C2 for the other ones.
 
#27
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/01/31 23:28:50 (permalink)
0
OK. I am trying to get my simple program to compile with your library, and it needs "utils.h" which I can't find. It apparently has a definition for _XTAL_FREQ, and bit_test().
 
There is also a problem with uint8_t and int32_t.
 
Could you post or send me the entire project? Thanks.

 
#28
ric
Super Member
  • Total Posts : 22101
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/01 00:34:31 (permalink)
0 (1)
You should define _XTAL_FREQ yourself.
That is how you tell the compiler what speed your CPU is running at. It's covered in the compiler user guide.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#29
dannyz
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2014/02/27 10:11:54
  • Location: Iasi, Romania
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/01 08:15:38 (permalink)
0
bit_test is a macro to check if a bit in a int is 1 or 0

#define bit_test(D,i) (D & (0x01 << i))

#30
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/01 13:23:24 (permalink)
0
Also, that schematic above (one of them actually) is lacking one power pin of the 876 PIC...
 
As for I2C, just to be sure I often prefer Bit-Banged code over the hardware one...

GENOVA :D :D ! GODO
#31
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/02 01:17:56 (permalink)
0
I have now basically rewritten Danny's LCD library and I made my own I2C library from the macros and functions in the Microchip i2c.h file and the associated plib function files. I made the registers specific for my PIC16F1825, and I got it to compile and load to the target. However, I found that it was hanging up at the following:
 
 
void I2C_start(void)
{
    SSP1CON2bits.SEN = 1; // Send start bit
    while(SSP1CON2bits.SEN);
}

 
I am now running the program with the PICkit3 as debugger and it is halted at the loop that should exit when the SEN bit changes to zero, indicating the send has completed. But when I try to examine the register, it does not recognize the SEN bit and instead seems to refer to the SSP1STAT register, and the BF (buffer full) flag is set.
 
I am still running MPLABX Ver 2.05 and XC8 Ver 1.30, and perhaps this is a bug that has been fixed. SSP1CON2 is mapped at 0x216 which is the address in BANK4 for this register. This project has been rather frustrating but I think I am finally pretty close to getting it working. I'll update my tools and try again when I get some sleep. If you have any ideas, please let me know. [edit] I attached a zipfile with the relevant source and header files.
 
Thanks!
post edited by PStechPaul - 2015/02/02 01:27:55

 
#32
ric
Super Member
  • Total Posts : 22101
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/02 04:20:22 (permalink)
0 (1)
I don't have XC8 v1.30, but certainly in 1.31 the header file for the PIC16F1825 has the correct value for SSPCON2
What leads you to thing it is referring to SSP1STAT, apart from bit 0 being set?
I'd recommend updating to the latest XC8 before continuing.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#33
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/02 14:34:28 (permalink)
0
When I hover the cursor over the SSP1CON2 register, it shows the bits labeled as they would be for SSP1STAT, and BF is set to 1. It is the same if I look at the Variables tab. I will update my tools and try again. Thanks.
 
[edit] I installed MPLABX 2.30 and XC8 1.33 (but I forgot to change the compiler from 1.30) and got the same problem.
 
But I changed to 1.33 and got the same result. sad: sad
 
The SFR list shows location 216 as containing 0x01.
 
I have verified that SSP1CON1 is set for Master Mode I2C (0x08), but the SSPEN bit 5 is 0. It is set in this I2C_init() function:
 
    SSP1CON1  = 0x28;        // Select and enable I2C in master mode


So somewhere that bit is getting reset. I found a possible bug here:
 
void LCD_init()
{
    LCD_open();

    // Following bytes are all Command bytes, i.e. address = 0x00
    LCD_write_byte(0x00, 0x03); // Write Nibble 0x03 three times (per HD44780U initialization spec)
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x03); //
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x03); //
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x02); // Write Nibble 0x02 once (per HD44780U initialization spec)
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x02); // Write Nibble 0x02 once (per HD44780U initialization spec)
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x01); // Set mode: 4-bit, 2+lines, 5x8 dots
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x0C); // Display ON 0x0C
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x01); // Clear display
    DelayMsec(5); // (per HD44780U initialization spec)
    LCD_write_byte(0x00, 0x06); // Set cursor to increment
    DelayMsec(5); // (per HD44780U initialization spec)

// LCD_close();
}

 
The LCD_close function also closes the I2C module:
 
void LCD_close()
{
    I2C_idle();
    I2C_close();
}

 
I commented out the call as shown above, but that didn't fix it.
 
Is there any way that the SEN bit can get "stuck"? If so, it seems that the I2C_start function should not block code execution. Maybe it can have a check for SSPEN, or incorporate a timeout.
post edited by PStechPaul - 2015/02/02 18:16:16

 
#34
PStechPaul
Super Member
  • Total Posts : 2060
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re: I2C connection to LCD screen (PIC18F4553 / PCF8574) 2015/02/02 18:29:16 (permalink)
+1 (1)
Well, I changed the function as follows:
 
void I2C_start(void)
{
    if(SSP1CON1bits.SSPEN == 0)
       SSP1CON1 = 0x28;
    SSP1CON2bits.SEN = 1; // Send start bit
    while(SSP1CON2bits.SEN);
}

 
And now it works! I have "Hello" on my screen!
 
I tried to find anyplace where the SSPEN bit might be getting reset, and that is what I probably should do, because this is really a "hack". But I do question why this is a blocking function that can halt execution if the MSSP module is not working. Seems like it (and others) should either time out or check for proper setting of the module before entering an endless loop if a bit is "stuck". In fact, IMHO, the hardware should not allow such bits to be set unless the module is configured.

 
#35
Page: < 12 Showing page 2 of 2
Jump to:
© 2018 APG vNext Commercial Version 4.5