Input Capture Ping)))

Created Sun, 08 Nov 2015 13:56:26 +0000 by majenko

majenko

Sun, 08 Nov 2015 13:56:26 +0000

I have just finished writing the first draft of an Input Capture Ping))) library for chipKIT.

This library uses the Input Capture facilities of the PIC32 to give a high accuracy reading from a typical cheap 4-pin ultrasound module (e.g., HC-SR04). It has a "free running" mode where it constantly captures the distance measured so you don't have to do any blocking or anything in your program - the most up-to-date distance measured is always available for you.

Everything happens in the background using the PIC32 internal hardware where possible. If you're not in free-running mode then just fire a ping, and, when you're ready to use the results they're there for you.

• [url]https://github.com/MajenkoLibraries/ICPing[/url]

dangeljs

Mon, 09 Nov 2015 13:06:58 +0000

Looks really good. I have done something similar, but I used the OC module to trigger the 10us pulse and then set the timer to a period that is long enough to not interrupt the current ping in progress. It was a trade off between using another resource and removing an extra ISR to retrigger the next pulse.

Most people don't want to give up the extra OC, so what you have provided should be a great addition their library base. Just thought I'd pass along the info though.

-Jason

majenko

Mon, 09 Nov 2015 13:46:06 +0000

The IC module is by far the most accurate method for measuring the duration of a pulse - after all, that's what it's designed to do. The length of the trigger pulse and how you generate it is of almost no importance - what is important with these ultrasound modules is finding the time between the leading and trailing edges of the echo pulse. The second best way is with interrupts, but those can be delayed and it's tricky on a PIC32 having an interrupt that responds to both rising and falling edges - you have to manually switch from one to the other.

So enter the IC module. It uses a free-running timer to provide a "tick" count, and at the moment the incoming signal changes level (actually 2 ticks later) the tick count is stored in a buffer and an interrupt is triggered. You then read the tick count buffer, so it doesn't matter if the interrupt was delayed at all - the tick count buffer will still be the value when the transition occurred. Then the same happens at the next transition (falling) and you just subtract the two tick count values.

The faster your free-running timed the more fine grained the tick count, and so the better the resolution. Unfortunately you only get the choice of timer 2 or timer 3, and timer 2 is already used by the OC modules, so it has to run with timer 3. It would be nice if there was more flexibility - it's possible to use timer 2 and timer 3 together as a 32-bit timer, which means it can run considerably faster and as a result have a much greater resolution. But with timer 2 already in use you're scuppered on that front. Still, for these cheap modules you can't expect any great accuracy, so one timer in 16-bit mode is fine.

dangeljs

Mon, 09 Nov 2015 14:04:17 +0000

I completely agree with you on the IC module, which is why I use the equivalent on a PIC12 8pin chip with an HC-SR04 in my garage to help my wife park her car :D.

What you have provided is by far the most flexible and modular, which is what is great about it. I was just trying to share another way of using the IC with the OC module for more nitch type projects. It has been a while since I looked at it, but I actually had the timer used in 32bit mode and was driving servos at a 20ms update rate and using one OC channel as the trigger. But looking back at it I think I did end up using another interrupt to handle any overflows of the 20ms period.

I'm not trying to make a comparison with your work (what i did worked for a specific application and hacked together), just providing info that might spark more of your creativity of other things that could be done (and definitely better than I could do).