You just set sofar to equal micros and then you subtract it from micros. Isn't that kinda like a-a and aren't you always going to end up with zero?
Bear in mind that if you change nothing w.r.t. timer0, the resolution of micros() is 4us. That's 64 clock cycles. A lot can happen in 64 ticks, especially if echpin is LOW. If you're looking to get high resolution timing, better to use timer1 or 2 with no prescaler and then log TCNT before and after. That way you're counting 62.5ns ticks. Even a prescaler of 8 will give you half micro ticks and millimeter resolution. The default prescaler is 64 and a bit granular for high-speed timing.
If none of that seems like it works, double check what values you're getting on your echo pin. If you want a low to kick in to stop/start the timing, do you have a pull-down resistor on the pin or does it just float? Floating inputs are not helpful if you want a valid reading to make a decision.
No, the 2nd micros() will return a slightly bigger (or much bigger) number than the 1st micros(), depending on how long it takes for the digitalRead to return HIGH.
The digitalRead() of the echo pin is LOW right after the trigger, and the while statement is not pausing the program and sofar and micros will have the same value.
CrossRoads:
No, the 2nd micros() will return a slightly bigger (or much bigger) number than the 1st micros(), depending on how long it takes for the digitalRead to return HIGH.
In a perfect world you'd be correct, and the code would be working as well. If while(digitalRead(echpin) != LOW) { }; fails, i.e. echpin is LOW, the code falls straight through, and it's going to do so in a lot less than 4us, ergo a-a will still equal zero.
DKWatson:
In a perfect world you'd be correct, and the code would be working as well. If while(digitalRead(echpin) != LOW) { }; fails, i.e. echpin is LOW, the code falls straight through, and it's going to do so in a lot less than 4us, ergo a-a will still equal zero.
how much time does a digitalRead() takes ?
The while (condition) is a compare and a jump so 2 clockcycles ~1/8 uSec.
Depends on whether the pin is configured for PWM. If so, about 5.1us (based on 20,000 iterations), else about half. bitRead(port,pin) is only 2 clock cycles. Every other permutation is between.
If while(digitalRead(echpin) != LOW) { }; fails, i.e. echpin is LOW, the code falls straight through
Correct, and the echo pin is LOW for aprproximately 200 microseconds after the trigger post. Then it goes HIGH for a period which indicates the distance. This is shown in the data sheet linked in reply #7.
Typically the blocking proceedures for reading this device uses pulseIn(HIGH) which waits for the pulse to go high before starting the timing. When using non blocking interrupt techniques, you must detect the echo pulse going HIGH and then LOW.
Now this is reaching, but if you've copied and pasted code, you never really know how the non-character characters get carried across. I've wasted a lot of time distinguishing quotes.
With duration = micros()-sofar; simply try re-typing it and see what happens and then throw a couple of free parentheses into the mix duration = (micros()-sofar); just for fun. See what happens.
DKWatson:
Depends on whether the pin is configured for PWM. If so, about 5.1us (based on 20,000 iterations), else about half. bitRead(port,pin) is only 2 clock cycles. Every other permutation is between.
simple test of digitalRead - the original code of OP is not using bitRead()
for (int pin = 2; pin < 14; pin++)
{
start = micros();
int x = digitalRead(pin);
stop = micros();
Serial.print(pin);
Serial.print("\t");
Serial.println(stop - start);
}
DKWatson:
With duration = micros()-sofar; simply try re-typing it and see what happens and then throw a couple of free parentheses into the mix duration = (micros()-sofar); just for fun. See what happens.