I see at least three reasons for the behavior you notice:
micros()has a resolution of 4 μs. If you could call it at a period fixed to exactly 10 μs, you would see the time deltas alternate between 8 and 12 μs. But thenmicros()takes some time to execute, so if you use it to time a function that takes 10 μs to execute, you will read 12 μs more often than 8.- There is a timer interrupt firing every 1024 μs. Any process
that gets interrupted will show an execution time longer than normal.
This is the likely cause of
digitalWrite()taking occasionally a lot longer than usual. pulseIn()waits for the start of the pulse before it starts to measure its duration. Its execution time can then be significantly longer than the pulse duration it reports.
i expected maybe due to some instruction cycles or unprecise clock.
The same clock is used for sequencing the CPU instructions and for timing them. So the clock precision has no effect on the timings you measure.
Edit: There is an extra issue here, which is the overflow of
arr[6]. The execution time of pulseInLong() may be something like
138,424 μs. Since an int on the Uno is 16 bits, this value wraps
modulo 216 to 7,352, which is the value shown in the first
line of the output.
I see at least three reasons for the behavior you notice:
micros()has a resolution of 4 μs. If you could call it at a period fixed to exactly 10 μs, you would see the time deltas alternate between 8 and 12 μs. But thenmicros()takes some time to execute, so if you use it to time a function that takes 10 μs to execute, you will read 12 μs more often than 8.- There is a timer interrupt firing every 1024 μs. Any process
that gets interrupted will show an execution time longer than normal.
This is the likely cause of
digitalWrite()taking occasionally a lot longer than usual. pulseIn()waits for the start of the pulse before it starts to measure its duration. Its execution time can then be significantly longer than the pulse duration it reports.
i expected maybe due to some instruction cycles or unprecise clock.
The same clock is used for sequencing the CPU instructions and for timing them. So the clock precision has no effect on the timings you measure.
I see at least three reasons for the behavior you notice:
micros()has a resolution of 4 μs. If you could call it at a period fixed to exactly 10 μs, you would see the time deltas alternate between 8 and 12 μs. But thenmicros()takes some time to execute, so if you use it to time a function that takes 10 μs to execute, you will read 12 μs more often than 8.- There is a timer interrupt firing every 1024 μs. Any process
that gets interrupted will show an execution time longer than normal.
This is the likely cause of
digitalWrite()taking occasionally a lot longer than usual. pulseIn()waits for the start of the pulse before it starts to measure its duration. Its execution time can then be significantly longer than the pulse duration it reports.
i expected maybe due to some instruction cycles or unprecise clock.
The same clock is used for sequencing the CPU instructions and for timing them. So the clock precision has no effect on the timings you measure.
Edit: There is an extra issue here, which is the overflow of
arr[6]. The execution time of pulseInLong() may be something like
138,424 μs. Since an int on the Uno is 16 bits, this value wraps
modulo 216 to 7,352, which is the value shown in the first
line of the output.
I see at least three reasons for the behavior you notice:
micros()has a resolution of 4 μs. If you could call it at a period fixed to exactly 10 μs, you would see the time deltas alternate between 8 and 12 μs. But thenmicros()takes some time to execute, so if you use it to time a function that takes 10 μs to execute, you will read 12 μs more often than 8.- There is a timer interrupt firing every 1024 μs. Any process
that gets interrupted will show an execution time longer than normal.
This is the likely cause of
digitalWrite()taking occasionally a lot longer than usual. pulseIn()waits for the start of the pulse before it starts to measure its duration. Its execution time can then be significantly longer than the pulse duration it reports.
i expected maybe due to some instruction cycles or unprecise clock.
The same clock is used for sequencing the CPU instructions and for timing them. So the clock precision has no effect on the timings you measure.