From: Cástor Muñoz <cmvidal_at_gmail.com>
Date: Sat, 10 Mar 2012 19:43:03 +0100

On 05/03/12 12:40, Michael Sparmann wrote:
>> a) Put PMU polling into a critical section and continue polling from
>> irq handler. The delay for some i2c operations (i2c_read(date)) is
>> relatively high so i think this is not the best solution, but its easy
>> and probably it will work.
> Will not work, because if some other thread was accessing I2C while that
> IRQ fires, the IRQ handler will mess up a thread's I2C access.
> Things that are run from an IRQ handler are in fact in a critical
> section, no need to arbitrarily create one :)

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. 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.

I also observed an I2C read mismatch rate of about 1/100000, sometimes
i2c_read() returns 0x00 value with no ACK or timeout error, it happens
for all I2C reads not only PMU polling, to verify it FS#12520 does a
second read when the holdswitch status changes.
Received on 2012-03-10