View Single Post
  #7   Spotlight this post!  
Unread 02-12-2004, 17:45
Kevin Watson's Avatar
Kevin Watson Kevin Watson is offline
La Caņada High School
FRC #2429
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 2001
Location: La Caņada, California
Posts: 1,335
Kevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond repute
Re: Is there a built in tick/millisecond counter?

Quote:
Originally Posted by eugenebrooks
The solution is to read the clock/counter twice, and if you don't get the same value, read it twice until you do!
Well, yes you could do this, but in general it's not a good idea because the two tasks that may alter the one variable may be synchronous to one another. Because of this you may constantly read the wrong value. It's better to just temporally disable the interrupt (e.g., PIE1bits.TMR2IE = 0, <access variable>, PIE1bits.TMR2IE = 1) or use a synchronization mechanism, like a semaphore.



Quote:
Originally Posted by eugenebrooks
The C-BOT compiler does not appear to "optimize away" the required reads, so the use of volatile does not appear to be required. If this were a problem, using volatile would be your last hope.
The C18 compiler does indeed store values locally for some time, most notably in the W register. It's just good practice to use the volatile keyword where applicable.



Quote:
Originally Posted by eugenebrooks
How often you get a corrupt value depends on your usage. If you busy poll the clock value in the "fast loop", you will get a bad value every few seconds.
It's a very hard thing to quantify. As an example, if the variable in question is a char, you'll never get corrupted data because all byte accesses on the 18F8520 are atomic in nature.

-Kevin
__________________
Kevin Watson
Engineer at stealth-mode startup
http://kevin.org