[PD] Sensors GPIO Raspberry Pi Pd
Julian Brooks
jbeezez at gmail.com
Thu Apr 25 13:10:56 CEST 2013
"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:)
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)?
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.
Thinking aloud here - what I think would be really useful would be a method
to have everything start at boot and then a method to route vital test info
from both Pd and the C program to one shell so I could ethernet/wireless in
via my lappy to check that all is well with the piece.
My leaky memory thinks that there's also a fairly recent workaround for the
Pi (for M.E.Grimm I think) with routing pretty much this kind of stuff.
Anyways, thoughts starting to wander, back to it:)
J
On 23 April 2013 14:45, Martin Peach <martin.peach at sympatico.ca> wrote:
> Yes that would work too, if you can handle the soldering ;(
> I suppose you could modify the c code to run two sensors and send the data
> to two different port numbers, or use two different selectors for the
> message. Another way would be to have the Pd patch request a reading from a
> specific sensor.
> I'm trying to think how this could be generalized into a useful Pd
> external but it seems very specific to a particular setup.
>
> Martin
>
>
> On 2013-04-23 05:06, Julian Brooks wrote:
>
>> Bit more digging re ic switch:
>> My understanding is that if we got one of these:
>> http://uk.farnell.com/roth-**elektronik/re933-03/adaptor-**
>> smd-tssop-16-0-65mm/dp/1426182<http://uk.farnell.com/roth-elektronik/re933-03/adaptor-smd-tssop-16-0-65mm/dp/1426182>
>> and one of these:
>> http://uk.farnell.com/nxp/**pca9546apw/ic-switch-4ch-i2c-**
>> 16tssop/dp/2212120<http://uk.farnell.com/nxp/pca9546apw/ic-switch-4ch-i2c-16tssop/dp/2212120>
>> we should in theory be able to run both sensors off the same pins?
>> BUT - would the current code you wrote function better/easier if the
>> sensors were run from 2 separate sets of pins - ie how to parse the info
>> from one patch sounds tricky and presume much simpler with 2
>> [netreceive] objects attached to 2 C files?
>>
>> J
>>
>>
>> On 23 April 2013 09:42, Julian Brooks <jbeezez at gmail.com
>> <mailto:jbeezez at gmail.com>> wrote:
>>
>> Hey Martin / all,
>>
>> Omron tech support finally got back to me re the address issue, this
>> is what they had to say:
>>
>> "D6T sensor can not change the address.
>> When you connect multiple sensors we recommend that you use the IC
>> switching.
>> Please refer to the below document.
>> http://media.digikey.com/pdf/**Data%20Sheets/Omron%20PDFs/**
>> D6T44L_8L_Appl_Note.pdf<http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf>
>> "
>>
>>
>> I've been through the spec sheet several times and don't see
>> anything (admittedly not sure exactly what I'm looking for though)
>> that relates to IC switching.
>>
>> We've still got 2 of these doing nothing currently if they could be
>> brought into action:
>> http://adafruit.com/products/**757 <http://adafruit.com/products/757>
>>
>> Or people on the RPi forum seem to have got the 2nd i2c pins going
>> but that seems to be for rev.2 boards only (I think - have posted a
>> question on the thread to ask).
>>
>> Also asked tech support about the PEC errors but no response to that
>> one.
>>
>> I've noticed that the PEC doesn't trigger errors all the time so am
>> wondering if it's possible to filter the errors out of the data
>> somehow in the C file?
>>
>> Still delighted though - the sensors great!
>>
>> Cheers,
>>
>> Julian
>>
>>
>>
>> On 22 April 2013 00:20, Julian Brooks <jbeezez at gmail.com
>> <mailto:jbeezez at gmail.com>> wrote:
>>
>> Wonder if it's a difference between rev boards on the Pi?
>>
>> I've also built a custom image based on Hexxeh's minimal install
>> which is working great for audio stuff. My Pd patch that
>> wouldn't run without overclocking on a standard Raspian is now
>> working fine on the rev1 256mg board. So I've been adding stuff
>> as and when it comes up to try and keep t is minimal as poss.
>>
>> I'm also not sure what installed libi2c-dev? Guess I'll have to
>> wait and see what squeals.
>>
>> Of possible interest is this message when removing the lib with
>> apt-get:
>> The following packages will be REMOVED:
>> libi2c-dev
>> 0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded.
>> After this operation, 19.5 kB disk space will be freed.
>> Do you want to continue [Y/n]? y
>> (Reading database ... 33610 files and directories currently
>> installed.)
>> Removing libi2c-dev ...
>> Removing 'diversion of /usr/include/linux/i2c-dev.h to
>> /usr/include/linux/i2c-dev.h.**kernel by libi2c-dev'
>>
>> So guess the diversion was messing with the compile for the C
>> code.
>>
>> Anyway - code runs and I can compile C files too so all ok so far.
>>
>> Thanks again for everything Martin,
>>
>> Julian
>>
>>
>>
>>
>>
>> On 21 April 2013 06:45, Martin Peach <martin.peach at sympatico.ca
>> <mailto:martin.peach@**sympatico.ca <martin.peach at sympatico.ca>>>
>> wrote:
>>
>> On 2013-04-20 21:09, Julian Brooks wrote:
>>
>> Oh and btw
>>
>> Still don't know why I can't compile the .c files on the
>> pi with
>> libi2c-dev installed but I can't. Presuming the
>> compiling is working
>> for you Martin?
>>
>>
>> Yes it works for me. I don't have the same
>> /usr/include/linux/i2c-dev.h as you so no redefinition
>> errors, not sure which package(s) install that file.
>>
>> Martin
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130425/3931981b/attachment.htm>
More information about the Pd-list
mailing list