pico
Member
Is there an ARM equivalent of ATOMIC_BLOCK(ATOMIC_RESTORE_STATE){ } ? Or does the different architecture and more involved interrupt capabilities mean that you need to think about things a bit differently?
Sorry if this is somewhere in a FAQ list I have overlooked -- I did search, and was surprised I didn't turn anything up.
gbulmer
Moderator
pico - you'll have to give us a bit more information about what you are trying to do so we have enough to go on to give a meaningful answer. Are you trying to protect access to a variable, or something more complex?
I assume you are referring to http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
pico
Member
I assume you are referring to http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
Yes, that's correct.
I am porting some Arduino/AVR code over to a Maple 5, and since the ATOMIC_BLOCK macro wasn't defined in the Maple ARM compiler environment, I did a bit digging to see what the equivalent was, but couldn't find anything definitive. It did make me appreciate that the ARM interrupt architecture is far more complex than the much simpler AVR model, though.
The macro basically turns off external interrupts while the code block executes, in case there is some undesirable effect an interrupt at that point might cause. The ATOMIC_RESTORE_STATE option is just fancy wrapping for (pseudocode)
original_state = int_enabled_register_bit<br />
cli()
<non interrupt code block here>
if (original_state == enabled) sei()I use it from time to time in a variety of situations, typically doing things like assigning values to a set of variables that would be inconsistent if an external interrupt service routine were to find them in a state where some variables had been changed but not the others -- stuff like that. Just anywhere that I have identified a critical section that I want to lock out any interrupts until complete.
pico
Member
Just started testing a port of the AVR "atomic.h" macros to the Maple5, in case anyone else is interested. So far so good... preliminary testing showing eveything as expected.
One advantage (for me) of going to the additional trouble of porting the higher level macros instead of just the primitives is that it makes portability between AVR <-> ARM just that bit cleaner.
You must log in to post.
