Go Down

Topic: Atomic reading of uint16_t ? (Read 5410 times) previous topic - next topic

solderspot

Quote
Um... wrong. You need to cast high before shifting it so far left.


Actually the code works as is. Most processors are not internally 8 bit and compilers will, by default, upcast to the native word size for speed reasons. But to be pedantic then yes we should cast first, or we could define high and low as uint16 and handle casting in the comparison operators.

zapta

#16
Jan 03, 2014, 08:19 pm Last Edit: Jan 03, 2014, 08:23 pm by zapta Reason: 1

... The problem is that to do what you want to do you will have to live with the possibility of some error.


Will the code snippet I asked about in my original post give any error?  

If so, can you explain the scenario that will cause an error?


It's really hard to fix code when you don't know the specifics of what it has to do.


I think the original post gives all the information. It has to read a 16 bit value that is updated by an ISR, without disabling interrupts.


Coding Badly

Can you make the counter in to two 8 bit values thus:


There is at least one fatal flaw in the code.

solderspot

Quote
There is at least one fatal flaw in the code.


And that is...?

Coding Badly

Badly, with all the respect, you are avoiding answering my original question...


Bullshit...

Quote
uint16_t reads are not atomic, right?


PaulS gave you the correct direct answer.  There is nothing more I can offer.

Quote
If so, what is a reasonable way to do so without disabling interrupts?


"Reasonable" is a subjective term.  What is reasonable to PaulS may be different than what is reasonable to me which may be different than what is reasonable to you.  The only way to answer that question is for you to define "reasonable".  Something I was trying to help you do.

Quote
For example, is this safe and reasonable?


At this point the answer is clearly "no".

Coding Badly

Instead you keep asking me to analyze what will happen in any future program...


Do I?  I thought my questions were about the application you described in your first post.

Delta_G



... The problem is that to do what you want to do you will have to live with the possibility of some error.


Will the code snippet I asked about in my original post give any error?  

If so, can you explain the scenario that will cause an error?


It's really hard to fix code when you don't know the specifics of what it has to do.


I think the original post gives all the information. It has to read a 16 bit value that is updated by an ISR, without disabling interrupts.




Describe a scenario in what code?  Should I dream up every possible code that could ever be written and look to see if your snippet will work in it?  Get real.  I don't know anything about the ISR that is changing that value except that you said it may be incremented multiple times in one ISR.  I see that potentially causing a problem with your snippet depending on how fast things run and how time critical it is that you get that info.  But I can hardly describe something I can't see. 

If you want help, then help the people trying to help you.  If you don't want help then close the window and never open this thread again.  But don't come in here with a partial piece of information and then bitch when nobody knows what you are doing with that snippet of code. 
|| | ||| | || | ||  ~Woodstock

Please do not PM with technical questions or comments.  Keep Arduino stuff out on the boards where it belongs.

zapta

Ok, thank you guys for the info. I think I have enough information now to continue on my own.

Go Up