Rockbox mail archiveSubject: Re: Classic holdswitch polling
Re: Classic holdswitch polling
From: Michael Sevakis <jethead71_at_comcast.net>
Date: Sat, 10 Mar 2012 16:20:19 -0500
> 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.
Received on 2012-03-10