[PD] Sensors GPIO Raspberry Pi Pd

[Julian Brooks]

'Nother 2 dumb questions:
What's the difference between the ones that have spider/centipede type legs
and the straight ones (which would be best to get).
And also are you attaching the MC14051 to any type of board/adaptor or just
soldering straight on to the pins?

Thanks for the above info too - really helpful.


On 25 April 2013 14:57, Martin Peach <martin.peach at sympatico.ca> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130425/2bf61d9a/attachment.htm>