Re: Controlling HD44780 LCD via I2C-GPIO-Expander?

[Conrad Braun <cdbraun@xxxxxx>]

Jeff Sutherland wrote:
> On Tuesday 16 June 2009, Conrad Braun wrote:
>> Hello,
>>
>> I'm currently trying to control an LCD via a PCF8574 I2C GPIO expander.
>> It looks as if I'm running into timing problems on an AT91RM9200 conitec
>> board with the I2C_GPIO driver and kernel 2.6.28; there is a delay of
>> almost 8ms between every byte sent over the I2C bus. Is this possibly an
>> effect of using the I2C_GPIO driver, or am I looking at the wrong suspect?
>> I haven't found any hints on this matter in the mailing list archives or
>> the web, though, so maybe there's another problem. I'm out of clues, tbh,
>> and any help is appreciated.
>>
>> Thanks,
>>  Conrad
> 
> The I2C_GPIO driver in itself is probably not to blame, although using a 
> hardware I2C uart will be faster.  What is the clock frequency you've 
> selected?  What kind of messaging are you using?  For the best performance 
> trying to send multi-byte messages it's probably best to use the low level 
> I2C interface by formatting the message into a buffer then sending it out 
> using the 'ioctl(<i2c_device>,I2C_RDWR,&buffer);'
> 
> -Jeff

Jeff,

I'm using the default settings of the I2C device (not that I would, but I haven't found how to change the speed). The problem is, I can not send multi-byte messages, as I have to toggle one of the GPIO's eight pins (used as ENABLE for the LCD, to clock in the data nibbles), and can only do so by sending the same byte again, with the bit set/unset, after the pulse.

It seems the overhead of consecutive
  write(<i2c>, &byte_with_ena_set, 1);
  nanosleep(ENA_PULSE_WIDTH);
  write(<i2c>, &byte_with_ena_unset, 1);

was causing the trouble. Following your suggestion, I went to see what would happen when I sent both bytes in one write(<i2c>, combined_buffer, 2) statement, without nanosleep in between. After all, one byte-time is longer than the ENA_PULSE_WIDTH of 450ns. 
That seems to have done the trick, now I have to go and fix all the timings that depend on this ;)

Thanks for your help,

  Conrad

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php