Go Down

Topic: is a read/write from/to an uint8_t atomic? (Read 2 times) previous topic - next topic

JosAH




You are enabling interrupts within an interrupt handler? That is a big red flag.


No it isn't, I know what I'm doing (<--- famous last words ;-) My interrupt function is triggered by a falling edge and then it starts decoding an IR signal from a digital pin; that can takes several milli seconds (I simply poll that pin in the interrupt function) and I want the millis() etc. interrupts to go on. At the start of my function I've detached it from the particular interrupt because I don't want it to be called recursively by another falling edge on that pin. b.t.w. I only enable interrupts after I've detached my function from that falling edge interrupt.


Instead of polling the IR receiver in the ISR, why don't you leave the interrupt attached, and at each interrupt:

- call micros() to get the current time
- calculate the time since the previous edge, so that you can decode the next bit
- store the time you got from micros(), ready for the next interrupt



That was my first approach; the code ended up a bit too messy: it was a state machine and it had to keep track of a bit too many state variables; I rewrote it and the code looks a bit cleaner now. It isn't cast in stone that this will be my final implementation maybe I'll go back to your suggestion if I can make a cleaner implemenation.

Thanks for replying and kind regards,

Jos

JosAH


Fair enough, but enabling interrupts inside an ISR is a last resort, as far as I am concerned.


Why is everybody so itchy when it comes to (re)enabling interrupts in an interrupt handler? I'm not longjmp( ... )ing around, I just want the micros() and millis() things to keep working (I have to keep track of a wall clock time (*)). Neither does my interrupt handler need to be reentrant ...

kind regards,

Jos

(*) yes, the device syncs its notion of time with an NTP server each day.

Nick Gammon

Let me turn the question around.

What is your objection to doing what the IRremote library does? It doesn't re-enable interrupts inside an ISR.

JosAH


Let me turn the question around.

What is your objection to doing what the IRremote library does? It doesn't re-enable interrupts inside an ISR.


I've seen that library; it records 'ticks' between state transitions and it uses 100 two byte ints for it (200 bytes!) and it decodes afterwards. I decode 'on the fly' for one particular protocol (NEC); reading 32 bits in that protocol takes +- 108 millis and I don't want to lose the millis() ticks. The 'header' pulse takes 560us and I might lose a millis() tick in there. Maybe if I use edge change interrupts (my first approach) I don't need to (re)enable interrupts inside my handler ...

kind regards,

Jos

Nick Gammon

You won't lose a millis() tick in 560uS - the interrupt is queued.

Go Up