|
Rockbox mail archiveSubject: Re: Classic holdswitch pollingRe: 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. Mike Received on 2012-03-10 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |