This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Suffix U/UL & volatile variable

1. In 32 bit, do all unsigned numeric constants should be suffixed by U or 32 bit should be suffixed by UL.

Is it:

uint8_t var_1   = 4U;

uint16_t var_2 = 5U;

uint32_t var_3 = 6U;

uint64_t var_4 = 7UL;



or 

uint8_t var_1   = 4U;

uint16_t var_2 = 5U;

uint32_t var_3 = 6UL;

uint64_t var_4 = 7UL;

2. I have a code in which a var get incremented in ISR. This variable gets incrmented & read. What should be correct approach so that operation cannot be interrupted. As operation divides into three steps - Load, mdify & store.

In had tried second method, but again the instruction "var = temp", breaks into LDR & STR, again this can cause 

interrupt in between. Is there any step so that this operation cannot be interrupted. 

volatile uint8_t var;

void isr(void)

{

   var++;  /* load, Add, Str  */

}

void main(void)

{

  while(1); /* do something */

}





or





volatile uint8_t var;

void isr(void)

{

  uint8_t temp;

  temp = var;

  temp++;

  var = temp;          /* load,store  */

}

void main(void)

{

  while(1); /* do something */

}

  • Hi Aamir,

    Regarding the 2nd point specifically, make sure that you have initialized "var" in the main code before you do anything else. This will ensure the integrity of the results. Secondly you can do "var++". Even if the processor gets a higher priority interrupt, it will maintain the variable value in stack/SRAM and when it comes back you would get the correct results.

    Amit

  • Volatile is not atomic!

    Volatile only guarantees that access will take place (Not optimized out or in) and the order in which they occur.

    It does not offer assurances that the operation(s) will not be interrupted ot that other operations will not be interleaved.

    The increment and decrement operators  (++/--) likewise offer no guarantees of atomic updates or access.

    I know only three ways to provide atomic access

    1. Use your RTOS/RTX primitives
    2. Use compiler library/extensions to disable other access (such as through interrupt disable)
    3. Drop to assembler

    Option 1 may not be available, option three only gives advantage for small access. 

    Robert

  • Amit Ashara said:
    Secondly you can do "var++". Even if the processor gets a higher priority interrupt, it will maintain the variable value in stack/SRAM and when it comes back you would get the correct results.

    Unless, the ISR modifies var (think buffer management) in which case var will be wrong.

    Robert

  • Of course Robert. Any code which has multiple updates to the same variable and specially if no interlock is kept, can corrupt variables. The earlier post was w.r.t to the poster's code usage for var++ v/s using a temp variable which is also likely to corrupt var.

    Amit

  • Aamir Ali said:
    1. In 32 bit, do all unsigned numeric constants should be suffixed by U or 32 bit should be suffixed by UL

    On most 32 bit processors int types and long types both map to 32 bit so the L suffix is optional.  The various "processor independent" like unit32_t size types break down when it comes to constant since there is no way I have seen to declare constants in a similarly processor independent fashion.

    Whether unsigned constants smaller than 32bit need a U suffix is mostly a matter of style.  All compilers should work "correctly", most will not even give a warning. The danger area is when the high bit is set. 

    Personally I think there should be a U suffix on all unsigned numbers.  Not to make it work but to keep clarity of intent. 

    Robert

  • Amit Ashara said:

    Of course Robert. Any code which has multiple updates to the same variable and specially if no interlock is kept, can corrupt variables. The earlier post was w.r.t to the poster's code usage for var++ v/s using a temp variable which is also likely to corrupt var.

    The temp variable is an auto variable.  If it gets corrupted the chance of anything working is pretty slim. After all nothing else should be able to access it, even with multiple calls to the same routine.

    Robert

  • Hi Robert,

    When doing buffer management the user modifying it at two places (since it is a global variable) could also corrupt it!!!

    Amit

  • Amit Ashara said:

    Hi Robert,

    When doing buffer management the user modifying it at two places (since it is a global variable) could also corrupt it!!!

    Amit

    That is why I said you had to guard it.

    Robert

  • Robert Adsett said:
    Personally I think there should be a U suffix on all unsigned numbers.  Not to make it work but to keep clarity of intent.

    Well stated!  Undisciplined/unclear "intent" most often will rise to impale execution - later if not sooner...

  • There are several separate issues here.

    First the difference between using an increment and an auto variable as a temp

    • There is no difference.  Both are vulnerable to interruption (non-atomic).  Neither is vulnerable to corruption of the intermediate value by another process.  In fact, all compilers I know of for ARM will store any intermediates on interruption on the stack in both cases.

    Second the global variable being modified as an end result

    • Is vulnerable to modification by separate processes unless it is protected by some means to provide atomic access. Either by means of RTOS primitives, compiler extensions or dropping to assembly and using built-in cpu mechanisms to assure atomicity.

    Robert

  • cb1_mobile said:

    Personally I think there should be a U suffix on all unsigned numbers.  Not to make it work but to keep clarity of intent.

    Well stated!  Undisciplined/unclear "intent" most often will rise to impale execution - later if not sooner...

    [/quote]

    I use a static analyser that amoung other things points out signed/unsigned mismatches. Annoying if you have not used it regularly since you know the code is correct but I have found that when you have a number of these complaints is usually points to some manner of incorrect and/or error prone abstraction.  I.E. if you have to keep changing type to keep the analyzer happy there is almost always something wrong that you have not looked at and thought about or are avoiding making correct.

    Robert