When the busy bit never clears, this will wait indefinitely. In my case, this was because the HOLD pin was left floating and activated, but I think this would also happen when the device is not connected or otherwise not present. In these cases, blocking indefinitely creates a hard-to-debug, and un-userfriendly situation, so it would be better to use a timeout instead.
The value of this timeout can be found in the datasheets, which state the maximum write cycle time (tWC) and seems to be typically 5ms (4ms for the ST M95640). Using a 5ms might be a good default, or alternatively a timeout per device could be specified as well).
Technically, this timeout should apply from the end of the previous transaction, but a simpler implementation would be to apply the timeout from the beginning of the next write or read (for the common case of a responsive device, this should not change the behaviour anyway).
The code that reads and writes contains snippets like this: https://github.com/mattairtech/EEPROM_CAT25/blob/4987ced17c01e104900a28008d1ccd1f75af132a/src/EEPROM_CAT25.cpp#L108-L110
When the busy bit never clears, this will wait indefinitely. In my case, this was because the
HOLDpin was left floating and activated, but I think this would also happen when the device is not connected or otherwise not present. In these cases, blocking indefinitely creates a hard-to-debug, and un-userfriendly situation, so it would be better to use a timeout instead.The value of this timeout can be found in the datasheets, which state the maximum write cycle time (tWC) and seems to be typically 5ms (4ms for the ST M95640). Using a 5ms might be a good default, or alternatively a timeout per device could be specified as well).
Technically, this timeout should apply from the end of the previous transaction, but a simpler implementation would be to apply the timeout from the beginning of the next write or read (for the common case of a responsive device, this should not change the behaviour anyway).