I'm been using a EZ4 ultrasonic rangefinder to measure the distance to an object. It produces a pulse whose width is directly proportional to the range to the object.
The simple way to measure the pulse width, is to use the pulseIn() function. The only catch with this is that it seems to be very slow.
Would it be feasible to feed the pulse from the EZ4 to two interrupt pins. One set to measure a rising edge, and the other a falling edge? The rising edge interrupt would 'start the clock' the falling edge interrupt would 'stop the clock' and between the two I could work out the pulse width and thereby the distance to the object. Since this would be driven by interrupts, I would hope it would be a lot quicker than the way PulseIn() has to hang around waiting for a pulse to come in and then spend time measuring it's duration?
Would what I'm describing work? would it be sensible? is it ok to effectively 'short' two input together (since they'd both be connected to the same source)?
I had a look at the library, it seems to be designed for a different range of proximity sensors to what I'm using. None of the documentation/forum threads I looked at indicate it works with the maxtor range of sensors, and my coding skills aren't good enough to work out what the library is actually doing. It seems to be designed to work with rangefinders that have a 'trigger' pin and an 'echo' pin. The maxtor range produce a continuous stream of pulses whose width needs to be measured to provide distance.
You could use a single interrupt set for CHANGE. That will interrupt on both edges. You can check the state of the pin to see which edge just occurred (HIGH->RISING or LOW->FALLING) . Use the micros() function to get the time in microseconds.
The Timer/Counter 1 has an Input Capture feature which can store the current timer count when the Input Capture pin changes. That might give you a hardware way to time pulses to 1/8th of a microsecond. The Input Capture interrupt can be set for a Rising edge at which time you can grab the timer value and change it to a Falling edge. When the falling edge interrupt occurs you can subtract the old time from the new time to get the pulse length. Then set the edge back to Rising. This will use very little CPU time and should give accurate results regardless of interrupt latency.