I may be a purist, but that techinque is not useful for determining the frequency of a clock. It is useful for determining the minimum interval between two transitions.
Why?
- the CPU cannot be doing anything else at all. If interrupts cause it to do something else, then the intervals will obviously be extended. If the clock is only intermittent then there will extra tests in the while clause. If data is to be transmitted then there will be extra statements in the loop body.
- depending on the CPU, what is/isn't in a cache will cause timing variations, resulting in jitter
For an OS like a PC or Linux, then I agree. For a real-time system interrupts can be masked and latencies controlled. A SPI clock only has to run during a bus transaction. Otherwise it is off. There are no caches, data or instruction, in a Cortex M micro. The term "bare metal" compiler means something here.
I agree about the CPU, hence my prefixing the statement with "depending on the CPU". Ditto "If" in the statement about interrupts. I'm fully aware of the implications of bare metal; I've even declined to use the Arduino environment for an atmega328, since I knew I couldn't predict what
assumptions were in the libraries
The other, more important, points about the CPU not being able to do anything else stands, for the reasons given.
Hence this technique is only useful for determining the minimum interval between two transitions - it is not useful for determining the frequency of a clock.