RPi gpio, polling & MH

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

RPi gpio, polling & MH

Rick Bolen(gm)
Another serving of Pi...

I'm leveraging xPL for IPC between gpio and MH on the same RPi (This is
the original pi, with single processor and 256MB? ram).

The "quick and dirty" way for me to use the RPi's gpio for simple switch
triggers was to run a separate perl script on the RPi that uses the
"Device::BCM2835" perl module. Detecting gpio pin states has to be
polled for in a loop (at least this is what I'm currently doing). This
has the side effect of having a script that spins the CPU to 100%.

It might be cool to support RPi gpio natively in MH, but in thinking
about this, since the gpio can actually be used for a bunch of different
things (L2C, SPI, UART, GPIO), I think it would be very ambitious to
comprehensively cover that ground within MH (at least for me).

So, in sticking with the "quick and dirty", is there a way to throttle
the app to be less CPU intensive?

I've tried two things:

1) Launching the app using nice:
   nice -19 ./contact_xpl.pl

2) using "select(undef, undef, undef, 0.160)" in the loop to sleep this
script for a period of time (160 milliseconds) to reduce the number of
loops-per-second the app performs.

After using both of these, the script is still the most CPU intensive
process running (as reported by "top"). And maybe this is just how it
goes when using "nice" and "select()"... I don't know.

Is there well regarded, "tribal knowledge", ways of throttling these
little polling scripts and apps?



Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users