'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@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