@Erik,

please look carefully on the code, it is secure under all circumstances.

Assuming long delay on interrupts of higher priority is irrelevant, since then never a stable reading can be reached. It place no role, if you stop the timer delayed or read the timer delayed.
The higest priority must always be reserved for this software capture routine, otherwise only a hardware capture unit (PCA) can be used.


"...the TL will always be at some low value"

No !
Any value is possible, because I measure an external event.


And the trick with the XCH is very important.
If you read the low byte with MOV and get 0xFF, then you can be sure, that the high byte was advanced and thus the high byte was wrong. On reading FE, FD or so, the high byte can be wrong or maybe not.

But on using XCH the high byte contain always the correct value !

Since an overflow occur only on counting FF->00, but never on loading 00 into the low byte regardless the state prior loading.

Thus only loading and reading at the same cycle (XCH) catch the cow.


I tested it verbose, without XCH you get flickering results.


Peter