[PD] Sensors GPIO Raspberry Pi Pd

[Martin Peach]

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.)

Martin