volatile variable access

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I have a global volatile 8-bit variable (uint8_t or int8_t) that is shared between an interrupt service routine and the rest of the program, do I have to disable interrupts to access it? It seems like using it would involve one-byte transfers, so I wouldn't have to worry about half of a word changing while reading, etc. I guess it could be a problem if the variable is used more than once in a function that depends on the value staying the same, but is it okay for one-time access that doesn't care about previous state? Sorry if this has been answered before... I wasn't able to find it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

do I have to disable interrupts to access it? It seems like using it would involve one-byte transfers, so I wouldn't have to worry about half of a word changing while reading, etc.

No worries with 8bits - as you say the access are all atomic - it's 16bit and larger variables you have to atomically protect - probably using :

http://www.nongnu.org/avr-libc/u...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Access are only atomic as long as it is a one way transaction (read-only or write-only). If you are performing a read-modify-write operation, your access is no longer atomic,and thus must be protected.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the information. I didn't think about the read-modify-write situation... that's tricky. That includes operators like |= and &= right? I'll take a look at this atomic util header. I usually do atomic block things myself by backing up SREG, clearing interrupts, writing code in the block, then restoring SREG, but it seems like the macros would make life much easier.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobasaurus wrote:
Thanks for the information. I didn't think about the read-modify-write situation... that's tricky. That includes operators like |= and &= right?

Yep. Basically unless you can do a blind write, affecting all 8 bits, your write will need to be atomic.

[note there are exceptions to this... ie the variable is known to be stored in a register so SBR/CBR can be used, or the variable is stored in a GPIOR location, where SBI/CBI can be used]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobasaurus wrote:
I usually do atomic block things myself by backing up SREG, clearing interrupts, writing code in the block, then restoring SREG, but it seems like the macros would make life much easier.
Actually, the macro does one other cool thing for you: it forces the compiler to keep everything inside the "atomic" section you specify.

When you use the SREG backup/cli/restore SREG, the optimizer is still free to look at parts of the code and move them outside the SREG/cli sequence. It usually won't do that for simple read-modify-write sequences, but more complicated sequences can get nailed.

Use the ATOMIC_BLOCK, Luke! Trust the library writers! ;-)

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!