Loading ...
Sorry, an error occurred while loading the content.
 

I2C delay doesn't work on OKI675001

Expand Messages
  • flaretom
    Hi Everyone! I m having some trouble with the 675001 regarding the i2c-hardware in the MCU. The Oki-i2c hardware is connected to an Atmel-AVR, which is working
    Message 1 of 3 , Mar 18, 2010
      Hi Everyone!
      I'm having some trouble with the 675001 regarding the i2c-hardware in the MCU.
      The Oki-i2c hardware is connected to an Atmel-AVR, which is working as i2c-slave. Sometimes the AVR is not as fast as the oki-mcu and pulls the i2c-scl line low after its acknowledge pulse(i2c-delay). Unfortunately the oki-mcu does not detect this and continues to send its data on the i2c-sda line. Of curse this ruins the whole communication, and to make things worse the state can't be left by software means (reinitializing the i2c hardware in the oki-mcu).
      Does anybody observe a similar behavior and hopefully has a workaround?
    • ChrisH
      A few years back, one of the I2C slave devices we needed to support was a power supply which required I2C clock stretching (pulling the I2C SCL line low)
      Message 2 of 3 , Mar 19, 2010
        A few years back, one of the I2C slave devices we needed to
        support was a power supply which required I2C clock stretching
        (pulling the I2C SCL line low) similar to what you are experiencing.
        We were using the OKI675003, and if I recall correctly, the I2C
        master in this part does not support clock stretching. It would
        do exactly as you are observing -- continue clocking data even though
        the slave is holding down SCL.

        I implemented a bit-bang I2C master which used the same GPIOs
        as the OKI master. That worked quite well. In fact, that
        code is now being used in a new design with the OKI675003
        which supports several I2C buses directly attached to OKI
        GPIOs. I suggest you search the net as there are most likely
        a good number of sample bit-bang I2C masters out there.

        -Chris Hooper


        --- In OKI-ARM-mcus@yahoogroups.com, "flaretom" <thorn@...> wrote:
        >
        > Hi Everyone!
        > I'm having some trouble with the 675001 regarding the i2c-hardware in the MCU.
        > The Oki-i2c hardware is connected to an Atmel-AVR, which is working as i2c-slave. Sometimes the AVR is not as fast as the oki-mcu and pulls the i2c-scl line low after its acknowledge pulse(i2c-delay). Unfortunately the oki-mcu does not detect this and continues to send its data on the i2c-sda line. Of curse this ruins the whole communication, and to make things worse the state can't be left by software means (reinitializing the i2c hardware in the oki-mcu).
        > Does anybody observe a similar behavior and hopefully has a workaround?
      • flaretom
        Hi, Chris! Thank You for Your reply. Yes, i m afraid thats the only solution to deal with the missing i2c-delay capability of the oki-mcu (in the docs i
        Message 3 of 3 , Mar 22, 2010
          Hi, Chris!

          Thank You for Your reply. Yes, i'm afraid thats the only solution to deal with the missing i2c-delay capability of the oki-mcu (in the docs i discovered that the scl-pin is an output only --> no support for i2c-delays). Some time ago i already implemented a soft-i2c master for the oki and until now it worked fine. But now we use the AVR as multiple UART device and the full bandwith of the i2c bus is needed. Meanwhile i optimized the AVR firmware, so there is no delay anymore and anything works fine (, until the AVR is on its limits ;) ).
          Anyway, it's a big disadvantage, that Oki didn't implement a "real" I2c-master.
          Best regards Thomas Horn
        Your message has been successfully submitted and would be delivered to recipients shortly.