Support for ATOMIC_BLOCK?

matt

Member
Any plans to implement the atomic functionality provided by the AVR file utils/atomic.h for the Teensy3?
I'd like to use an RFM22 library which uses the ATOMIC_BLOCK macros so currently it won't compile

Matt
 
I've ported a version of Dean Camera's ATOMIC_BLOCK macros from AVR to Maple, which is ARM Cortex M3, so I can't see why it shouldn't also work straight-up on the Teensy 3.0. The assembly language instructions should be the same, and the underlying compiler is gnu. If you want to test it on your Teensy 3.0, let me know and I'll email you the cortex_m3_atomic.h file (it includes everything, the inline functions are defined in the .h file.) Also, if Paul wants to include this in his distribution for the Teensy 3.0, I'm happy to donate to the cause.
 
Thanks, I'll give your file a go (PM sent). Hopefully Paul will be able to add support into Teensy 3.0 at some point.

Matt
 
Thanks, I'll give your file a go (PM sent). Hopefully Paul will be able to add support into Teensy 3.0 at some point.

Matt

I've emailed you the file to the address in your PM. I've also cc'ed Paul at paul (at) pjrc.com. Hopefully, "should just work", but any questions or issues, let me know.
 
I've emailed you the file to the address in your PM. I've also cc'ed Paul at paul (at) pjrc.com. Hopefully, "should just work", but any questions or issues, let me know.
Thank you. I added the file into the library RF22 library directory for now (until it becomes part of the Teensy distribution)
I did find a small error in the file:

Code:
..\sketchbook\libraries\RF22/util/cortex_m3_atomic.h: In function 'void __set_primask(uint32_t)':
..\sketchbook\libraries\RF22/util/cortex_m3_atomic.h:18: error: expected ';' before 'asm'

So I added the missing ; here

Code:
{ __asm__ volatile ("MSR PRIMASK, %[value]\n\t""dmb\n\t""dsb\n\t""isb\n\t"::[value]"r"(setval):)[COLOR="#FF0000"];[/COLOR]

And it compiles. I can't confirm if it works yet, as I've found another problem :-(

Code:
..\sketchbook\libraries\RF22\RF22.cpp:520: error: 'memcpy_P' was not declared in this scope
Thanks for your help

Matt
 
Here is an updated Teensy 3 core library, with Pico's atomic.h and a definition for memcpy_P. I was able to compile the RF22 test example. I don't have the hardware, so I can't test if it actually works.

http://www.pjrc.com/teensy/beta/teensy3_27nov12.zip

To use this, replace your hardware/teensy/cores/teensy3 directory with the one from this file. Restart Arduino before using it.

Please let me know if it works?
 
I did find a small error in the file:

Code:
..\sketchbook\libraries\RF22/util/cortex_m3_atomic.h: In function 'void __set_primask(uint32_t)':
..\sketchbook\libraries\RF22/util/cortex_m3_atomic.h:18: error: expected ';' before 'asm'

So I added the missing ; here

Code:
{ __asm__ volatile ("MSR PRIMASK, %[value]\n\t""dmb\n\t""dsb\n\t""isb\n\t"::[value]"r"(setval):)[COLOR="#FF0000"];[/COLOR]

And it compiles.

Yes, don't know how that crept in. Usual random source of error between chair and keyboard, no doubt.

Actually, three characters went missing. As well as the ';', there should be a ' ' and '\' (space and backslash) to indicate a continuation line.

Code:
{ __asm__ volatile ("MSR PRIMASK, %[value]\n\t""dmb\n\t""dsb\n\t""isb\n\t"::[value]"r"(setval):)[COLOR="#FF0000"]; \[/COLOR]

I'm not sure if it makes any difference to the inlining of the function, to have the function broken over more than one line, but that's the way Dean had them in the original, so I was trying to keep to the convention.
 
Please let me know if it works?
The library will recognise an RFM22B device attached to the SPI port, so it's partially working (it can at least read the device ID over the SPI port)
It now seems to get stuck in an endless interrupt loop. I need to debug further to find out why

Matt
 
I've got it working successfully now. Thanks Paul & Mark.

The problem with the interrupts were 2 fold
1) INT0 is Pin0, not Pin2 as on an Arduino
2) As posted elsewhere in the forum, I had to set Pin0 to input before the interrupts would work.
Since the attachInterrupt call is in a library, that means changing the library.

I assume that the arduino behaves differently in this case. Is it possible/sensible to make teensy3 set a pin as input when calling attachInterrupt?

Matt
 
The reason of defining the PinMode separately to attachInterrupt is the possibility of SoftwareInterrupts. If you define an Output Pin and attach the Pin to an Interrupt you can write to the Pin and call the ISR.
 
Arduino's attachInterrupt() function does not actually set the pin to input mode.

However, on Arduino, every pin defaults to input mode at startup. On Teensy 3.0, the non-analog pins default to disconnected.

I've considered adding startup could that would set every pin to input mode, so more closely emulate Arduino. I might indeed still do this, but there are trade-offs. The main problem is "floating" or disconnected input mode pins consume power. This happens on AVR too, and on a board like Teensy++ it can add up to quite a bit of current. I haven't tested how much current it can add on Teensy 3.0, but generally the problem can become worse as the chip runs on lower voltages.

So far, most programs have used pinMode() to define the pin as INPUT. Obviously the RF22 library example does not. Maybe it would be worthwhile to contact the author about adding pinMode to the examples?
 
Both weak pullups and pulldowns are available.

However, in terms of emulating Arduino, enabling those by default would be even worse. The default behavior before your code runs is high impedance, which is needed for lots of circuitry that could be adversely affected if driven (even weakly) before your program runs.
 
Yes, don't know how that crept in. Usual random source of error between chair and keyboard, no doubt.

Actually, three characters went missing. As well as the ';', there should be a ' ' and '\' (space and backslash) to indicate a continuation line.

Code:
{ __asm__ volatile ("MSR PRIMASK, %[value]\n\t""dmb\n\t""dsb\n\t""isb\n\t"::[value]"r"(setval):)[COLOR="#FF0000"]; \[/COLOR]

I'm not sure if it makes any difference to the inlining of the function, to have the function broken over more than one line, but that's the way Dean had them in the original, so I was trying to keep to the convention.

The compiler doesn't care, as long as you break it between the pairs of double quotes, since the compiler will glue together adjacent double quoted strings with only whitespace and comments in between the adjacent strings. I often times do this to make things more readable:

Code:
{ __asm__ volatile ("MSR PRIMASK, %[value]\n" \
                            "\tdmb\n" \
                            "\tdsb\n" \
                            "\tisb\n\t" \
                            : \
                            : [value] "r" (setval):); \
 
Back
Top