Implementing critical sections on AVR 8 bit processors

I don't think you're going to find a single instruction to do what you want. I suggest looking at the CLI/SEI instructions to force a block of two or more to execute atomically.

Yeah - I think you are correct. And when I think about it, processors that support test-and-set instructions must effectively do the same thing - but probably more efficienty than just disabling all interrupts. :)

Thanks a lot for the reply.

In my experience, the processors which have those also tend to have other features which make the situation more complicated, such as support for multiprocessor or multicore architectures, memory caches, or pipelines. The AVR has none of these, so you *can* make something atomic just by turning off interrupts, with no other low-level support required.

You're very welcome. I hope it works out well.

Then I have to conclude that your experience doesn't include the 8051, right? That one's had a test-and-set instruction (well, test-and-clear actually) longer than those multi-* terms exist.

Erm, no, I don't think so. To be generically atomic, you have to restore the interrupt state to what it was before the critical section, not just to a default "enabled". The interrupt-enable flag itself may have to be protected from concurrent access, too.

"the el vez" skrev i meddelandet news: snipped-for-privacy@8g2000cwh.googlegroups.com...

You can use these instructions on the I/O memory (actually half the I/O memory) On newer AVRs there are general purpose registers in the I/O area for this very purpose.

"the el vez" skrev i meddelandet news: snipped-for-privacy@8g2000cwh.googlegroups.com...

You can use these instructions on the I/O memory (actually half the I/O memory) On newer AVRs there are general purpose registers in the I/O area for this very purpose.

I think that SBIS,SBIC may skip the following instruction, but I am not at all sure that you cannot get en interrupt between the SBIS/C instruction and the next instruction. I assume you can, so the real thing is to disable the interrupt to get the critical section.

If you want to use the producer-consumer paradigm, this works. You let the producer (interrupt routine?) do an SBI (uninterruptable) to set the bit and the consumer do a CBI to clear the bit.

Since only the producer sets the bit, you have no need to do anything fancy in the producer task except check if the bit is set and then wait, else set the bit and continue.

... snip ...

Most interrupt disable routines will return the previous enable state, which you then use to restore. At the same time, once you have disabled interrupts there is nothing except your own faulty code than can re-enable them before you arrive at the end of your critical section.

Yes. But the core question is: does the platform allow to implement such a function in a truly reliable way? The 8051 does, because it has the JBC instruction. Other architectures may not.

The issue is not with premature enabling of interrupts in the routine, i.e. doing the right thing at the wrong time. The issue is doing the wrong thing at the right time: re-enabling interrupts when they shouldn't be, because the real sequence was:

main code reads state of some interrupt: enabled That interrupt strikes ISR disables its own interrupt for some good reason ISR runs ... and finishes main code disables interrupt 2 ... main restores saved interrupt state: enabled

Now the main code has trampled over the ISR's wish to leave that interrupt disabled, because there was a time slot between its instructions reading interrupt state, and changing it.

No problem for the AVR 8 bit CPUs which this thread is about. The main code saves the status register containing the global interrupt flag. It then uses a instruction CLI to clear it. At the end of the critical section, it restores the status register.

An ISR that wants to disable its own interrupt would never touch the global interrupt flag in the status register, rather it would clear the peripheral-specific interrupt enable bit in the appropriate IO register.

... snip ...

As far as I am concerned you have just described a faulty ISR. An ISR should perform some action, but not (net) alter the machine state.