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: Will it be succeeded by a TCAL9535?

Part Number: TCA9535
Other Parts Discussed in Thread: TCA9539, , TCAL9539, TCAL6416

Tool/software:

Some GPOI devices have newer superior successors, for example the TCA9539 now has a 1MHz lower voltage TCAL9539 counterpart, which also has more nice features on board and is a drop in replacement as well.

Can we expect the same to happen with the TCA9535? For our design we cannot use the TCAL9539 but we would really like to have those features.

Thank you for your answer.

  • Hi Ruud,

    Today is a TI holiday- responses will be delayed and the team will get back to you as soon as possible.

    Regards,

    Jack

  • Hi Ruud,

    For now, the TCAL9535 is not in the pipeline at the moment. Closest option will be TCAL9539 / TCAL6416 for now. 

    Is the reason that you can't use the TCAL9539 is due to address pin limitations? 

    Regards,

    Tyler

  • Hi Tyler,

    Thank you for the quick answer. I really appreciate it that you are open on this, since normally companies do not disclose information on their near future plans. Although I hoped for an other outcome, at least we can now make some firm decisions on this. "Cannot" is always relative. To use the TCAL9539 we must:

    • find an other pressure sensor since ours is on 0x76 or 0x77, thus colliding with the addresses of TCAL9539 (0x74-0x77). And if we do, rewrite the firmware for the new sensor as well. Possible, not nice.
    • settle for only four TCAL9539 in our circuit since there is an !RESET instead of the A2 line. Since we can cycle power on all I2C peripherals in case of a bus hang, we do not need the !RESET line. And although at the moment 4 devices is enough, we would rather have some air here for future developments. (Personally I do not see the need of the !RESET line in a broader picture. If the I2C bus hangs, you are not going to find out which device is causing the problems, and since most I2C devices do not have a !RESET line, you must be able to power cycle anyway, so ...)

    On the other hand, using TCA9535, which gives us up to 8 devices and a free address space (0x20-0x27) also has some challenges, since it has no "what caused the interrupt" register. Thus we must interrogate (and possibly wake up) all devices, if the interrupt cause is gone. Doable? Yes. Nice? No. 

    As you see, the -non existing- TCAL9535 would solve all our problems Smile (and I believe it would be a nice device for others as well)

    Best Regards, Ruud.