'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.pe...@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 > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
