LAUNCHXL-CC26X2R1: How to use std::atomic

Hi Michael,

I'm forwarding this onto the compiler/CCS/tool team for comment.

Best,

Nate

Thanks. Just wondering: Is there a better way to ask question specifically relating to the toolchain? Just because I'm currently working with a BLE-capable chip, obviously doesn't mean that my problem is BLE related. But as soon, as I enter the name of my current board, I can only select wireless related forums.

Hi George,

thanks for your reply and sorry it took so long for me to come back to you.

George Mock said:

Look into what is available in the software development kit (SDK) for the CC26X2R1.

Inside the SDK documentation I could only find the the synchronization primitives from TI-RTOS, like semaphores and queues which are relatively "heavy" weight. Can you (or someone else) confirm that I'm not just blind and there are no supported primitives equivalent to the atomic C and/or C++ interface? I.e. no atomic CAS operations or at least guaranteed atomic reads/writes to 32 Bit variables paired with memory barriers.  

daniel_o said:

Depending on what you're trying to accomplish, your best bet will be to use Semaphores, Mailboxes, and Queues provided by the RTOS.

I mainly try to reuse some existing datastructures from a different project that use atomics (i.e. use portable code). More generally, os primitives that interact with the scheduler like semaphores or queues are pretty heavy weight (both in terms of memory footprint as well as execution time) for simple tasks, like incrementing a counter in a thread safe manner.

In any case:

After some experimenting it seems that contrary to the c++11 types, the c11 atomic types are actually "supported" by the ti toolcahin (ti clang v1.3.0.LTS). "Supported" as in "it compiles, seems to produce the correct assembly and seems to work in my initial test cases (no stress testing so far)".

As this seems to contradict the anwser by @George Mock: Am I correct with my assumption that this is not officially supported by TI and you give no guarantee that this will continue to work with future versions of the toolchain, nor that they will actually behave correctly (as specified in th c standard) under all circumstances?

Hi Daniel,

thanks for the clarification - disappointing as it may be.

Is there a place where you are collecting user feedback/feature requests for the toolchain?

Best

Michael