> Sorry, i didn't explain it properly, was referring to protect I2C read and
> write functions using a critical section instead of the actual mutex, then
> a thread accessing I2C cannot be interrupted by the tick handler.

That's a very bad thing to do. I2C shouldn't keep interrupts masked that
long or latency is horrible for audio playback. Latency should be
effectively non-existent if possible. Doing that stuff on AS3525 was causing
recording glitches, especially when not using DMA (due to interrupt
frequency making it more likely).

> This is a small modification affecting only target code but not valid for
> a definitive solution, everybody agrees slow polling must not be done
> inside critical sections. By the way, some info about I2C timing using
> default clocks:

> time to transfer 1 byte + ACK (9 bits total) = 43-45 usecs
> i2c_read(N registers) = (3.3 + N) * 45 usecs approx.
> holdswitch polling = 200 usecs approx.
> get date = 500 usecs approx.

Like I said: horrible thing to do. I think we agree, yay?

A queueable driver can make problems like that disappear.

Mike
Received on 2012-03-10