1. It depends on the Clock Frequency
2. It also might not actually take anytime depending on what happens in the instruction pipeline ... you should read about it at ARMs website.
3. If I ever actually felt the need to use a busy wait delay I would use CyDelay or CyDelayUs because we took care of the timing for you
Using a hardware timer is generally the go-to solution, but if you really want a busy-wait, using the CyDelay as arh stated would be the best choice. Otherwise, the NOP will be a single instruction's worth of clock time which depends on your currently set clock frequency.
The NOP instruction in ARM CM-0 takes one Machine Cycle which includes fetch, Decode and Execute operation. Being an ONE byte instruction generally it takes 4-T states which results in 4*Clock_Period time.
Im not really arguing... but here is a quote from the ARM page that I linked before "
NOPis not necessarily a time-consuming
NOP. The processor might remove it from the pipeline before it reaches the execution stage."
An example of NOP usage exemplifying your point arh: The Effect of the ARM Cortex-M NOP Instruction | pabigot
Generally the NOP will perform a delay unless a previous/surrounding instruction is already introducing an equal or greater delay, in which case it will have little or no effect.
That is a very nice Article... thank you for the link.
I suppose the real lesson from all of this is use busy wait delays is tricky business... and it is probably best to use hardware if the time actually matters.
Personally I try to never ever put them in my code.... the one possible exception is an RTOS delay which is a different beast.
I've had need to use NOP in projects before, but they were only needed for very precise audio timing, and even then could have been supplanted with hardware timers. NOP usage is a trick to use only as a last resort imo.