Assuming you're running at 16 MHz, you can:
- Set up Timer1 for CTC, OCR1A = TOP = 416 * 16 = 6656, no prescaling
- When your event happens, start Timer1
- When you're finished processing something, start polling TIFR1 for TOV1
These things could affect the precision of your interval:
- Sooner or later you'll be unfortunate enough for the Timer0 interrupt to be executing just as the input changes, or the interval elapses, unless you disable that interrupt. You'd run long by a little bit.
- The accuracy of the beginning and end of the interval will depend on exactly which statement is being executed when wither happens. If the relevant state chagnes just after it's tested, you'll miss it by whatever the loop overhead is - and a byte with something, branch, and read. That'll likely be something like 0.5 microsecond.
You don't mention what you want to do when the timer elapses. If it's something simple, like change the state of an output pin, you might be able to persuade the timer to do it for you. That won't suffer from any likelihood of interrupt or polling latency, at least in checking the end condition.
Ok, what I'm doing is trying to receive 'Manchester' encoded code (it may be better known by another name). Put briefly, a Manchester encoded serial bit has two halves which are always in opposite states - one convention (which is also my convention) is that if the first half of the bit is logic '1' then the value of the bit is logic '1', and if the first half of the bit is logic '0' then the value of the bit is logic '0'. In this example, one whole bit is 1664 uS long, so each half of the bit is 832uS long and a quarter of a bit would be 416uS.
Without going into too much detail I have a known start point which I know is the start of the first bit, so that's where all timing initially starts from.
At the beginning of the bit:
Delay 416uS (I could do this delay with the simple microsecond delay, no problem). This brings me to one quarter of the way through the bit.
-sample the state of the input now, save the input value as LHBIT
Now, Manchester encoded bits always have a state change half way through the bit. I wait for that by polling the input until it changes. I'm now in the middle of the bit.
Delay 416uS. Again, the simple system delay is OK.This brings me to three quarters of the way through the bit.
-sample the state of the input now, save the input value as RHBIT
Now, here's the problem. I need to time the remaining quarter bit time (416uS) to the end of the bit, so, I start a timer (416uS) and while the timer is running, I need to evaluate the bit value. If LHBIT = 1 and RHBIT = 0, that's a valid logic 1 bit, or if LHBIT = 0 and RHBIT=1, that's a valid logic 0 bit. In either case, shift the bit receiving register one place and insert this new bit into it... all this while the timer is still timing out the last quarter of the bit. When I've evaluated and stored the received bit, then I can relax and poll the timer until it times out.
At that point, I have reached the end of this bit / beginning of the next one and can go back to Start: to continue reception of the next bit. Of course there's a downcounter to keep track of how many bits I've received as well.
I could go:
Start of bit
Wait until state changes
... and then evaluate the bit I've just received.
The problem there is that as I'm doing the evaluating, the next bit is already flowing straight on from the end of the last. That's why I prefer to do the bit evaluation / shifting inside a 'hollow' last quarter bit timer. That way, when I get to the end of the bit, I'm ready to start receiving the next one straight away. Hope this makes sense.
The use of the timer as you describe it sounds to be exactly what I'm talking about in principle, but can I just go ahead and start writing to and reading from registers directly in an Arduino script as though I were writing normal embedded 'C'?