drivers: Break conditions for waiting loops

[OlegHahm]

As discussed in #2911 (comment): In many places in hardware dependent code, one has to wait for an undetermined time until e.g. a register is set. Typically this is done in a while loop, which, however, could cause an endless loop in case of a hardware failure. Ergo, I would strongly vote to introduce a simple counter or similar that breaks the loop if the expected state has not been reached after N tries.

[BytesGalore]

I don't know if such approach would ease things.
If the hardware is blocked on a condition state, e.g. like discussed in #2911, and we break out this loop we continue into an undefined state.
My concern is that this will result in even more complicated situations/wait-states etc.

[OlegHahm]

The driver should return with an error code then.

[PeterKietzmann]

I partly agree with @BytesGalore that there might be a risk of undefined states. But in general I still think it's more comfortable to return somehow instead of running in an endless loop. Just returning and continuing the program should be avoided. The possibilities I see is either (i) return a defined error code, explicitly document it and check for this code or (ii) running into hard fault. With (i) there might be still a risk to run programs in an undefined state. (ii) feels a bit overstated to me.
Anyway, one needs to check several documentations to make a concrete statement as this is a hardware-specific thing.

[jnohlgard]

I think returning an error code is the only sensible thing to do. If the application is critically dependent on a subsystem which gives an error code, then the application should be able to decide if/when to perform a system reset (which would be the end result of the hardfault alternative). I don't think we should force the system into a hardfault or similar because of e.g. a communication problem on an SPI bus.

[PeterKietzmann]

So the consensus is to add a timeout or similar to all of these occurrences and return with an error then. Right?

[OlegHahm]

I guess so.

[LudwigKnuepfer]

This is also related to #3366

[PeterKietzmann]

@gebart stated in #5282:

• I2C: Agreed, clock stretching or misbehaving slave devices can potentially make a transaction stall, depending on the periph implementation this may hang indefinitely.
• SPI: No, SPI only needs a timeout in slave mode which is not implemented right now (the master drives the clock, time to complete is always deterministic)
• UART: the periph/uart API only supports RX via asynchronous callbacks per byte received, and UART TX is driven by the MCU clock, so the TX time is always deterministic.

@sdalu answered in #5282:

• SPI: I guess slave mode is going to be implemented some days, if it will require changes to the existing SPI API to handle timeout, perhaps it would be better to prepare for it earlier and minimize futur code change.
• UART: if flow control is enabled this could block TX

[PeterKietzmann]

So we still need some (/one) volunteer(/s) to take over that routine work as well as someone to test it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.