nRF24LE1, example PRX in nRFgo SDK, why not volatile global array?

[Artem Kolesnikov]

Hello everybody, I study transceiver nrf24LE1. I'm trying to understand example of PRX in nRFgo SDK (Enhanced_shockburst_examples):

/

    / Global variables
    uint8_t payload [3];
     
    // Radio interrupt
    NRF_ISR () // #define NRF_ISR () void nrf_isr (void) interrupt 8 // RF interrupt (0x4b)
    {
    ...
         // Read payload
    ...
           hal_nrf_read_rx_payload (payload);
    ...
    }

Please explain why uint8_t payload [3] is not declared as volatile ? Thank you so much!!!

[Hung Bui]

Hi Artem,

Could you explain a little bit more why you think volatile is needed ? My understanding is that we are not using the payload anywhere outside of the interrupt handler. hal_nrf_read_rx_payload () simply read the RX buffer and put into the payload array. We have no dependency on the payload value in main loop for example.

[Artem Kolesnikov]

Thank you very much for your participation in my question. I thought that the payload [3] is a global variable that is changed in the interrupt handler, and is available in the main loop. And due to the fact that in the main loop is no reference to this variable, the optimizer will throw it. I thought that all these variables have to be volatile. If I add in the main loop to use (read) payload [3], should I declare it volatile? Thank you.

[RK]

Since it's used in the interrupt handler the optimiser won't throw it out however it's defined, as long as the interrupt routine is compiled in. Volatile, as a keyword, isn't particularly well-defined and does different things between compilers. Technically if you want to be sure that every read access goes back to the array to re-read the data incase it's changed you could declare it volatile, in practice, it makes very little difference.

[Artem Kolesnikov]

Thank you very much! I really need to address this issue. Could it be, that appeal to the array is always associated with memory access, so "volatile" does not apply?

[RK]

What do you mean 'address this issue'? If you want to put volatile on it, put volatile on it. It won't hurt, it may make your code ever so slightly less efficient but apart from that it's not going to do a lot apart from give you peace of mind that the compiler will always read from the memory and not assume the contents doesn't change during the course of a function call. Volatile isn't going to affect whether or not the buffer is optimised out (it's not) nor whether the compiler assumes the contents don't change across function calls (it doesn't assume that).