I’m going back to work soon! (I think) Yay!
In other news I’m having trouble getting an HC-SR04 ultrasonic distance sensor working with the Raspberry Pi. I refuse to sit there and poll for the signal back. I’d rather just have a thread dealing with that (actually I’m tinkering with gevent at the moment) and just be able to get the distance data when I need it in another thread.
Here’s the issues I’m having:
1) No matter how I set it, if use any of the asynchronous event management from the RPi.GPIO callback (which is a separate C thread). I’ve solved this by having another thread deal just with sending triggers so that I know there is always a recent distance measurement available when it’s needed. It’s a bit of extra overhead, but not enough that I mind and it means that any measurement is fresher.
2) As I’m doing more it’s more and more likely that the interrupt misses the falling edge of the output signal.
1) Code my own interrupt routine to replace RPi.GPIO’s in C.
2) Dedicate a thread to polling for rising and falling edges on the signal pin.
3) Outsource this, and possibly some other functions, to a dedicated microcontroller.
There are pros and cons to all of the solutions. 1) I was really trying to code the entire thing in Python… because challenge, not for any practical reason. 2) Okay, not really any reason not to do this… I haven’t investigated it a lot (at all) to see how much overhead this would use. 3) Well, downside is that I really want to have all of the code out there and simple to use.
Don’t know which way I will go right now. I’m leaning toward #3 because, well, I actually think outsourcing it to an MSP430 with really good power management would be cheaper from a power budget standpoint… Might do 2 and 3 with a config option to switch so people can still use the code without extra hardware if they want.