Interrupts: potential concurrency issue
Posted: Thu Aug 14, 2014 8:25 am
When I worked in hardware and firmware development we had a well-formed fear and loathing of edge triggered interrupts, the reason being that it was hard to avoid occasional situations in which an interrupt was missed. A debugging nightmare. Doubtless the technology has moved on in the last quarter of a century but perhaps someone could advise me how to implement this:
I need to maintain an accurate count of interrupts. To simplify this, let's pretend the count is a global. My interrupt handler has
count += 1
My main program (running in its own context, not that of the interrupt) needs to read the counter and reset it to zero. Ideally we would use an indivisible read-modify-write instruction. Lacking this, I disable the interrupt, read and modify the value, and re-enable the interrupt.
If an edge occurs while the relevant interrupt is disabled, will the hardware/interpreter call the handler when it is re-enabled? Even this isn't ideal because theoretically muliple dges might occur but I'm not planning to accommodate hardware that fast...
Or is there a better way? I've not yet delved into ARM assembler but perhaps someone can advise.
Regards, Pete
I need to maintain an accurate count of interrupts. To simplify this, let's pretend the count is a global. My interrupt handler has
count += 1
My main program (running in its own context, not that of the interrupt) needs to read the counter and reset it to zero. Ideally we would use an indivisible read-modify-write instruction. Lacking this, I disable the interrupt, read and modify the value, and re-enable the interrupt.
If an edge occurs while the relevant interrupt is disabled, will the hardware/interpreter call the handler when it is re-enabled? Even this isn't ideal because theoretically muliple dges might occur but I'm not planning to accommodate hardware that fast...
Or is there a better way? I've not yet delved into ARM assembler but perhaps someone can advise.
Regards, Pete