- Wed Nov 30, 2016 12:58 am
#192435
I would like to connect a flowmeter to my Infocast 3.5. Previously I have connected this meter to an interrupt line of an AVR to count pulses.
Frequency is fairly low at 100Hz to 2Khz
1) Is there a way to attach an interrupt to a GPIO pin to reliably catch rising or falling edges?
2) Is the 3.5 fast enough that I could just poll the GPIO for a pulse count at ~1Khz?
3) Is a GPIO even suitable for this purpose, or would I need some additional counter/accumulator IC in between the chumby and the flowmeter? If so, does anyone have any suggestions, perhaps one which supports i2c.
2KHz is pretty slow compared to the 3.5's 454MHz. Check out Madox's Python GPIO library:
I'm going to try this route first for sure. Will probably end up using perl or C just because I'm crotchety about Python, but maybe this will be the catalyst to change smile
use an ATtiny. It should be pretty low-power in this application.
Yeah, it just seemed so silly to add a uC to such a beefy system. If there were an i2c accumulator that I could just throw on the existing bus, somehow that feels better. Irrational, I know, and hopefully completely unnecessary if I can just poll the pin.
Looked at Madox's Python script as well as the source for regutil, and was able to cook up something (using much of regutil as a basis) which worked just fine. I'll post the source if anyone is interested.
Polling the pin was fast enough, but highly inefficient. If I can get away with putting a usleep() in the loop or using a timer perhaps that will be enough. I saw in the documentation that the GPIO pins can be used as interrupt triggers, but I have no idea how I might go about writing code for that. Any pointers in that regard would be appreciated.I was already able to do everything in C, which is my preference over Python. The main thing I'd like additional advice on now is how I might tie into an interrupt on a GPIO rather than polling the line, so if anyone has any pointers on that I'd appreciate it. Polling works, but feels icky.
Actually, it looks like you can get pin headers which don't require solder. IMO it's not worth 10% of the cost of the Infocast to get them, but these guys sell them for some Xbox or cablemodem modifications.
Does anyone know what they're called to order from kynix or Digikey or something? Could be useful for some things. I know it would have saved me a lot of frustration when I soldered the header in upsidedown on my 3.5. Ugh.
http://www.kynix.com/Parts/2145099/M22-2660505.html Will this be helpful?
My code polls a GPIO only?
Yes, and as skcolb pointed out above, polling is easily fast enough. I put the polling code on a timer that catches all of the transitions at the flow rates I need and it only takes a few %cpu time according to htop. I would still love to use the standard Linux gpio module(if nothing else, so that I could use w1-gpio), but it doesn't come compiled on the device and I've yet to get a reliable cross compiling rig working.(It seems there are 5 ways to do it, but none of the instructions for them work without -to the newb at least- SuperSecretKnowlege.)
Frequency is fairly low at 100Hz to 2Khz
1) Is there a way to attach an interrupt to a GPIO pin to reliably catch rising or falling edges?
2) Is the 3.5 fast enough that I could just poll the GPIO for a pulse count at ~1Khz?
3) Is a GPIO even suitable for this purpose, or would I need some additional counter/accumulator IC in between the chumby and the flowmeter? If so, does anyone have any suggestions, perhaps one which supports i2c.
2KHz is pretty slow compared to the 3.5's 454MHz. Check out Madox's Python GPIO library:
I'm going to try this route first for sure. Will probably end up using perl or C just because I'm crotchety about Python, but maybe this will be the catalyst to change smile
use an ATtiny. It should be pretty low-power in this application.
Yeah, it just seemed so silly to add a uC to such a beefy system. If there were an i2c accumulator that I could just throw on the existing bus, somehow that feels better. Irrational, I know, and hopefully completely unnecessary if I can just poll the pin.
Looked at Madox's Python script as well as the source for regutil, and was able to cook up something (using much of regutil as a basis) which worked just fine. I'll post the source if anyone is interested.
Polling the pin was fast enough, but highly inefficient. If I can get away with putting a usleep() in the loop or using a timer perhaps that will be enough. I saw in the documentation that the GPIO pins can be used as interrupt triggers, but I have no idea how I might go about writing code for that. Any pointers in that regard would be appreciated.I was already able to do everything in C, which is my preference over Python. The main thing I'd like additional advice on now is how I might tie into an interrupt on a GPIO rather than polling the line, so if anyone has any pointers on that I'd appreciate it. Polling works, but feels icky.
Actually, it looks like you can get pin headers which don't require solder. IMO it's not worth 10% of the cost of the Infocast to get them, but these guys sell them for some Xbox or cablemodem modifications.
Does anyone know what they're called to order from kynix or Digikey or something? Could be useful for some things. I know it would have saved me a lot of frustration when I soldered the header in upsidedown on my 3.5. Ugh.
http://www.kynix.com/Parts/2145099/M22-2660505.html Will this be helpful?
My code polls a GPIO only?
Yes, and as skcolb pointed out above, polling is easily fast enough. I put the polling code on a timer that catches all of the transitions at the flow rates I need and it only takes a few %cpu time according to htop. I would still love to use the standard Linux gpio module(if nothing else, so that I could use w1-gpio), but it doesn't come compiled on the device and I've yet to get a reliable cross compiling rig working.(It seems there are 5 ways to do it, but none of the instructions for them work without -to the newb at least- SuperSecretKnowlege.)