Electronics > Projects, Designs, and Technical Stuff
Measuring time span very precise
HendriXML:
--- Quote from: imo on September 07, 2019, 11:20:38 am ---TDC7200, easy to use, libs for arduino..
PS: with that chip (works fine) you may upgrade from the nerf darts gun to a railgun later on.. :D
--- End quote ---
The time range it can measure is a bit narrow for a multi usable timer circuit.
magic:
Not sure why you are trying to read anything "atomically"?
Kleinstein showed how to do it.
Check the overflow flag. If it's zero, no problem. If it's one, you need to figure out if the event has been captured just after the overflow or just before the overflow. You do it by checking if the captured timestamp is just above 0 or almost 0xffff.
Alternatively, compare it against the current counter value. That enables you to block interrupts for almost entire counter period and still avoid overflow errors. Figuring out the details is left as an exercise for the reader. :P Because it's pointless, just don't block interrupts for longer than a few dozen cycles.
By the way, the value of TCNTn or ICRn is one of the few things that can actually be read atomically; consult the datasheet.
HendriXML:
--- Quote from: magic on September 08, 2019, 06:32:13 am ---Not sure why you are trying to read anything "atomically"?
Kleinstein showed how to do it.
Check the overflow flag. If it's zero, no problem. If it's one, you need to figure out if the event has been captured just after the overflow or just before the overflow. You do it by checking if the captured timestamp is just above 0 or almost 0xffff.
Alternatively, compare it against the current counter value. That enables you to block interrupts for almost entire counter period and still avoid overflow errors. Figuring out the details is left as an exercise for the reader. :P Because it's pointless, just don't block interrupts for longer than a few dozen cycles.
By the way, the value of TCNTn or ICRn is one of the few things that can actually be read atomically; consult the datasheet.
--- End quote ---
I was not trying to make a point to the very experienced. I mostly write with starters like myself in mind.
Off course you can always read the flag, but why do so if you act on its value only if the counter is low (overflow happened in counter as well).
From my perspective the "thread" that reads a positive flag takes responsibility to also do the high bit increment and clearing the flag. It's showing a way of thinking about this stuff. It is mostly about "atomic" read and writes, having stuff consistent with each other. Think about it that way leads to solid solutions in other problems as well, that why I like to hammer on it. :popcorn:
HendriXML:
--- Quote from: magic on September 08, 2019, 06:32:13 am ---You do it by checking if the captured timestamp is just above 0 or almost 0xffff
--- End quote ---
In my posts I compare it to the 50% value, 0x7fff
- just to explain the 50% terminology
magic:
--- Quote from: HendriXML on September 08, 2019, 09:27:42 am ---Off course you can always read the flag, but why do so if you act on its value only if the counter is low (overflow happened in counter as well).
--- End quote ---
I'm not sure if I understand what you are doing and I'm not sure if you are doing it right.
You don't need to check if TCNT1 is low or high to detect overflows. The overflow flag tells you that an overflow has just happened and hasn't been handled yet and that's all you need to know about overflows.
But if you use input capture, you need to check if ICR1 is low or high, if you discovered that there is a recent unhandled overflow.
The value of ICR1 tells you whether the captured event happened before (ICR1>50%) or after (ICR1<50%) the unhandled overflow.
This information is required to decide whether to increment the high bits before processing the captured event or leave it to be incremented later by the overflow ISR.
edit
Well, if you want to, of course you don't need to leave that job to the overflow ISR, you can increment it yourself and clear the flag.
But it needs to happen after a copy of ICR1 and the old high bits has been recorded by the input capture ISR as the event timestamp.
Again, I don't know. Maybe I'm saying the obvious, maybe you are making a mistake.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version