PhilHornby
Senior Member
I just bought myself a third Sainsmart LCD2004 and was surprised to find it behaving somewhat differently to the previous two, when connected to a Picaxe 20X2.
[The Sainsmart LCD2004 is a HD44780 compatible LCD, connected to an I²C I/O expander]
My first two devices have a PCF8574 on-board, wired to respond to I²C address $3F. The new one has a PCF8574A instead. The difference being that this one responds to I²C address $27 instead (being similarly wired). From my research, this is the main difference between the two devices - though I'm suspecting there may be something else...
I have an LCD diagnostic program, which when run on a Picaxe 20X2 @ 64MHz, does not work with the new (PCF8457A) device. It results (fairly quickly, if not instantly) in an I²C bus 'lock-up', that requires the technique described by edmunds, in this thread, to fix. I modified my test program so that I could have old and new LCD displays on the bus at the same time - it was always when addressing the new one, that the problem occurs. (The problem being the SDA line stuck low and neither device responding).
Lowering the Picaxe clock speed to 32MHz meant the problem was no longer reproducible - both devices work correctly....
I looked in more detail at the I2Cslow_x parameters that I was passing into my HI2CSetup call. They have the following decimal values (ignoring the top bit, which AIUI is only used on input) :-
It struck me that they double in value, as the clock speed doubles - apart from the last one. Doesn't this mean that @ 64MHz, the i2cslow_64 parameter results in an I²C bus running @ 125KHz instead of 100KHz? ... (I may have misunderstood how this works!)
If this theory is correct, it's amazing that any I²C devices work with the 20X2 @ 64MHz ?!?
I tried running the Picaxe @ 32MHz, but using the i2cslow_16 parameter instead. I expected this to result in instant failure on both devices ... yet, they both seem perfectly happy. Isn't the I²C bus speed running at 200KHz under these circumstances?
Any thoughts as to what I'm seeing? - Although I can work around my problem, I'd like to understand what's going on.
[The Sainsmart LCD2004 is a HD44780 compatible LCD, connected to an I²C I/O expander]
My first two devices have a PCF8574 on-board, wired to respond to I²C address $3F. The new one has a PCF8574A instead. The difference being that this one responds to I²C address $27 instead (being similarly wired). From my research, this is the main difference between the two devices - though I'm suspecting there may be something else...
I have an LCD diagnostic program, which when run on a Picaxe 20X2 @ 64MHz, does not work with the new (PCF8457A) device. It results (fairly quickly, if not instantly) in an I²C bus 'lock-up', that requires the technique described by edmunds, in this thread, to fix. I modified my test program so that I could have old and new LCD displays on the bus at the same time - it was always when addressing the new one, that the problem occurs. (The problem being the SDA line stuck low and neither device responding).
Lowering the Picaxe clock speed to 32MHz meant the problem was no longer reproducible - both devices work correctly....
I looked in more detail at the I2Cslow_x parameters that I was passing into my HI2CSetup call. They have the following decimal values (ignoring the top bit, which AIUI is only used on input) :-
Code:
i2cslow_4 = 9
i2cslow_8 = 19
i2cslow_16 = 39
i2cslow_32 = 79
i2cslow_64 = 127
It struck me that they double in value, as the clock speed doubles - apart from the last one. Doesn't this mean that @ 64MHz, the i2cslow_64 parameter results in an I²C bus running @ 125KHz instead of 100KHz? ... (I may have misunderstood how this works!)
If this theory is correct, it's amazing that any I²C devices work with the 20X2 @ 64MHz ?!?
I tried running the Picaxe @ 32MHz, but using the i2cslow_16 parameter instead. I expected this to result in instant failure on both devices ... yet, they both seem perfectly happy. Isn't the I²C bus speed running at 200KHz under these circumstances?
Any thoughts as to what I'm seeing? - Although I can work around my problem, I'd like to understand what's going on.