I looked through the datasheet, but it was not clear to me if it is specified the delay from switching the mux to a different path and when it is ready to send data.
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.
Our device requires a stop condition to be issued after a write transaction has been done to our device. (Not a restart condition)
From here, if you need to be compliant to the I2C spec, then the the required time between a start condition after a stop condition is 4.7us for standard mode, 1.3us for fast mode, and 0.5us for fast mode plus. This is accordance to the t_BUF parameter stated in the I2C specification for version 2.6.
From a device perspective, I estimate we should be able to receive a new transaction likely within double digit nanoseconds though.
So there is no quantitative value for "much faster"? For example if one of the buses is hung, if you switch to it, will it break the connection on the first bus you are switching away from it in time not to corrupt the first bus.
Should we disconnect from all buses before switching buses?
OK, bad example then, but I guess everybody is answering every question except the one I asked.
How long does it take for the internal switches to change from one bus to another after being commanded?
If it is not specified, how about a range of expected operation. It does not seem like to hard of a question to answer.
The state machine for the device would be already in the state to be ready change the mux before the ACK even occurs. The device doesn't actually execute this until the stop condition is seen by the device. This should occur approximately at 70% of Vcc when SDA is transitioning from low to high assuming that SCL is already above the 70% threshold (a stop condition).