Go Down

Topic: Replacement for AVR libc ATOMIC_BLOCK macros, now for DUE and other platforms. (Read 12258 times) previous topic - next topic


Oct 04, 2012, 08:25 am Last Edit: Oct 04, 2012, 10:42 am by pico Reason: 1

You are correct that break is still a valid statement, and that this would be an ever greater problem:

Yep, that's a real problem, and potentially an easy trap for the unwary to fall into. Initially, I thought it was an unlikely bug to cause real problems, but now I think this is a shortcoming with potential to cause some real grief. I don't think it unreasonable or unlikely that someone would want to protect only a section of code within a "for" or "while" loop. If that section contains a break or continue, things certainly won't work as expected anymore if using ATOMIC_BLOCK macros.

In which case, I think Pyro's alternative is looking better all the time... I'll have to get around to having a play.

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)


Oct 05, 2012, 05:12 am Last Edit: Oct 08, 2012, 12:58 am by pYro_65 Reason: 1

The only caveat (as far as I can tell) is placement
The Libc macro does not have the same potential problem.

This is a problem indeed, but I believe the macros do suffer too as the atomic operation doesn't take effect until the macro is encountered. I think this is entirely up to the programmer to order their code carefuly, but worth a mention in the documnetation for sure.

@WizenedEE, that is a nice example of a 'break' failure.

Its good to see a few things being discussed weren't even something I had considered.

Now that I can consider the library mildly stable after doing some tests, I can start experimenting with some new ideas.
I have implemented some nice extensions coming soon, with entirely new ways of doing things for more flexibility.


Oct 08, 2012, 04:17 am Last Edit: Oct 08, 2012, 04:42 am by pYro_65 Reason: 1
G'day all,

I have finished a major update to the library, it is more of an extension as the original functionality hasn't changed.
The library now supports in-line atomic operations on any kind of element* giving you greater control of how long interrupts are held. Some situations may warrant the atomic/critical section to be as short as possible, accessing 'safe' data may be better with short multiple accesses, compared to one long blocking operation. This creates a very easy interface to do so.

For example ( explanations in updated reply #1 ):

  • Atomic reads.

  • Atomic writes.

  • Atomic function calls.

  • Atomic pointer manipulation.

You can download the new code from the first post [here]. The documentation has been updated there as well as a full explanation inside the AtomicBlock.h file. There is more documentation to come, I just wanted to get a quick run down of the new features.

This uses some high level C++ techniques to accomplish safe and efficient operation. If you would like explanations of any parts of the code feel free to ask.

*Object member functions are not currently supported, next update.


Nov 02, 2012, 06:44 am Last Edit: Nov 02, 2012, 06:47 am by pYro_65 Reason: 1
As the new Due has come out, I have recently updated my AtomicBlock system to now support a few more platforms.

AtomicBlock V1.2 (beta)

Now supports:

AVR 8-bit processors

  • Arduino 8-bit family ( Compiled / Tested )

  • Teensy 2.0 ( Not Compiled / Not Tested )

  • Teensy++ 2.0 ( Not Compiled / Not Tested )

ARM Cortex-M3

  • Arduino DUE ( Compiled / Not Tested )

  • Olimex STM32 / Leaflabs Maple. ( Compiled / Not Tested )

ARM Cortex-M4

  • Teensy 3.0 ( Compiled / Not Tested )



  • Initial implementation. ( Not Compiled / Not Tested )
       ASF ( AVR Software Framework )
       Reference: http://asf.atmel.com/docs/2.11.1/index.html
    GNU Toolchain support will be available soon.


  • C++ compiler required.

The new code is posted on google code here: http://code.google.com/p/arduino-extensions/downloads/list
I have also uploaded the file to the original post [here].


Standard atomic block also has some problems with different C standards as well, I actually made a new macro that works as a one-shot to avoid the issue instead. My application for it is to wrap malloc/free/realloc so that it is IRQ safe.

You can look at what I did here: https://github.com/xxxajk/xmem2/blob/master/malloc.c

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131