This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCA9535: How to check for interruptions

Part Number: TCA9535

Hi team,

If the microcontroller periodically checks to see if the input port has changed (inside the expander), is there a problem with open processing without using the interrupt pin?

When the microcontroller goes to check whether the input port is high or low via I2C, is it possible to know the status of the input port in real time?
Or is there a delay (if so, how long?)? I am not sure if there is a delay.

Best,
Ryu.

  • Hi Ryu,

    If the microcontroller periodically checks to see if the input port has changed (inside the expander), is there a problem with open processing without using the interrupt pin?

    I don't see a problem with open processing if this just means that the customer will leave /INT pin floating since they do not need the interrupt trigger to read the input port register changes. 

    When the microcontroller goes to check whether the input port is high or low via I2C, is it possible to know the status of the input port in real time?
    Or is there a delay (if so, how long?)? I am not sure if there is a delay.

    I2C is a serial and synchronous protocol sending bits most significant to least significant in a data byte format based off a clock signal. 

    The internal logic diagram shows a series of D flip-flops that are edge triggered. When a clock signal is present from an I2C master/controller onto the IO expander during a read transaction, the edge of the clock will shift the data of the I/O pin into the shift register in which I2C will read data. If somehow the data on the IO pin changes before and after the rising edge of the clock signal, then the stable data present on the I/O pin during the edge of the clock will be seen on a read transaction in I2C. All 8-bits (8 ports) of the IO expander have to be accounted for followed by an ACK before the I2C master/controller can read another byte of data again. 

    This is potentially why the /INT pin is important, because it shows that an input has changed it state from its original logic state. An /INT can also be deasserted if the input is original a low signal, changes to high, then back to low. If a read transaction is conducted after the second low state, then the I2C controller/master might miss the pin state change due to de-asserted interrupt. 

    So all of this to say, the IO expander is limited to how "real-time" it can read data from its input pins. 

    The only delay specs that we consider for IO expanders is found in the table 6.7 from the datasheet. 

    With the largest delays being the setup and hold times as well as the data valid timings. 

    Regards,

    Tyler

  • Hi Tyler,

    Thanks for the reply.
    I understand now.

    Best,
    Ryu