[PD] Sensors GPIO Raspberry Pi Pd

Martin Peach martin.peach at sympatico.ca
Thu Apr 25 15:57:53 CEST 2013

On 2013-04-25 07:10, Julian Brooks wrote:
> "I'm trying to think how this could be generalized into a useful Pd
> external but it seems very specific to a particular setup."
> I do think a more general [i2c] object would be super-useful.
> Particularly if it could directly open up and access the i2c line.  Not
> sure how he does it but wiringPi has some kind of test routine that
> figures out what rev board it's on, which is pretty nifty too.  If
> there's a method to incorporate the i2cdetect functions as well then it
> would be a one-stop-shop - so to speak.
> Maybe an additional object to [gpio], plus the 2 omron's as externals /
> or combined into one and that's definitely the start of a new bad-ass lib:)

Yesterday I connected a sensor clock line through a MC14051 analog 
multiplexer running at 3.3V, with the sensor side clock pin pulled up to 
3.3V via a 10k resistor and it works fine. The next step is to switch 
the clock line using a GPIO pin so I can read 2 sensors off the same i2c 
bus. This setup should work with up to 8 sensors with the same address, 
using 3 GPIO pins to select a sensor, but the clock line must only be 
switched between 12c reads.

> OAN - Really impressed with the C program: the drain on system resources
> is very minimal.
> I'm still getting PEC errors on a regular basis though I still think we
> may have a dodgy connection somewhere down the line - sometimes when
> i2cdetect the sensor isn't registering and need to give it a little
> wiggle (not ideal).
> Also presuming that as the clock is running at 100000 cycles that the
> readings being passed to Pd are set here:
> char                          netbuf[256];
> in the C code?
> (could be talking out of my rear-end here I know)
> And I'm also presuming they can be edited in those multiples (128, 512 etc)?

Yes, netbuf is where the string sent to Pd is constructed. It only needs 
to be as large as the message, I made it too long to be sure it wouldn't 
cause trouble. The length doesn't need to be a multiple of anything.

> I haven't started experimenting yet but the plan is to run the
> installation headless.
> Is there anything I'll need to change in the code to allow the C program
> to run from boot:
> Like at the moment the readings are being spat out in the xterm (stdout)
> via 'printf' I think, which is also replicated via the [netreceive]
> patch, so I'm guessing I can start to trim stuff down.

You can comment out any lines with 'printf' in them by prefixing a 
double slash //. I have been running it headless via ssh as:
nohup ./d6treader 0 >> /dev/null &
This sends all the text output to nowhere and also keeps the program 
running after I close the connection. (I had it running for a day 
without redirecting output and it nearly filled up the sd card.)


More information about the Pd-list mailing list