Message resent for thread archives with smaller picture size.
Julian
---------- Forwarded message ---------- From: Julian Brooks jbeezez@gmail.com Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@iem.at
Hey Martin / list,
Finally got all the stuff and ...
It’s not working!
We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet.
Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off.
We then moved on to case 2 page 3 of this same document…
At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
The grid shows no attached devices every time we run it.
We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked).
As you can see we’re using a pi protoplate:
https://www.adafruit.com/products/801
In the photo I’ve attached the cables are coded as follows:
Orange GND
Yellow 5v
Blue SCL
Green SDA
The white is also 5v for the pull up resistors.
The resistor values are 4.7k btw.
We have tested the cable that terminates at the sensor and all that is OK.
I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v…
I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v…
Don’t know if this means anything or could be useful to know!
Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of).
I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare.
Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end.
Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd.
Any thoughts/pointers/options from anyone will be really appreciated?
Cheers,
Julian
Hey all,
Some success finally:
Hurrah!!
The scl breakout pin on the pi proto plate wasn't working properly.
When unscrewed halfway it works, when fully screwed in it doesn't.
So - now got this:
i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- 0a -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
and
i2cdump -y 0 0xa No size specified (using byte-data access)
Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening.
Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this:
i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least.
Cheers,
Julian
On 12 April 2013 11:27, Julian Brooks jbeezez@gmail.com wrote:
Message resent for thread archives with smaller picture size.
Julian
---------- Forwarded message ---------- From: Julian Brooks jbeezez@gmail.com Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@iem.at
Hey Martin / list,
Finally got all the stuff and ...
It’s not working!
We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet.
Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off.
We then moved on to case 2 page 3 of this same document…
At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
The grid shows no attached devices every time we run it.
We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked).
As you can see we’re using a pi protoplate:
https://www.adafruit.com/products/801
In the photo I’ve attached the cables are coded as follows:
Orange GND
Yellow 5v
Blue SCL
Green SDA
The white is also 5v for the pull up resistors.
The resistor values are 4.7k btw.
We have tested the cable that terminates at the sensor and all that is OK.
I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v…
I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v…
Don’t know if this means anything or could be useful to know!
Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of).
I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare.
Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end.
Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd.
Any thoughts/pointers/options from anyone will be really appreciated?
Cheers,
Julian
Last weekend I did an installation in a room wrapped in bubble-wrap. Friends had the idea, and asked me to "do something interesting with sound."
A bubble-wrap pop isn't terribly interesting on its own, so I thought I'd pitch-shift (starting with the pitchshift example patch) and delay the inputs, and then I added randomization of the pitch shifting and delay parameters. On top of that, I randomized the intervals at which the params were updated. I used four mic inputs and randomized panning to four outputs. The patch, ultimately, looked like this:
http://onezeromusic.com/snwv/impulse_noise.png
Kind of ugly there, but it's a work in progress, and worked great for the three-and-a-half-hour installation time. I didn't worry much about feedback, but the mics did pick up the input, so there was a generative thing going on there, particularly by the end.
The results, summed to stereo: http://snwv.bandcamp.com/album/impulse
Now I'm experimenting the patch on oscillators: https://soundcloud.com/maurice-rickard/tonebubble2
In a few weeks, I'll be doing an improv show in which I'll use this on guitar. Should be fun.
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
FWIW all that you described can be done in one external disis_munger~ provided you don't go over 64 channels of audio output. Latest pd-l2ork will come prepackaged with this and some other flext externals.
Best wishes,
Ico On Apr 13, 2013 1:02 PM, "Maurice Rickard" maurice@mauricerickard.com wrote:
Last weekend I did an installation in a room wrapped in bubble-wrap. Friends had the idea, and asked me to "do something interesting with sound."
A bubble-wrap pop isn't terribly interesting on its own, so I thought I'd pitch-shift (starting with the pitchshift example patch) and delay the inputs, and then I added randomization of the pitch shifting and delay parameters. On top of that, I randomized the intervals at which the params were updated. I used four mic inputs and randomized panning to four outputs. The patch, ultimately, looked like this:
http://onezeromusic.com/snwv/impulse_noise.png
Kind of ugly there, but it's a work in progress, and worked great for the three-and-a-half-hour installation time. I didn't worry much about feedback, but the mics did pick up the input, so there was a generative thing going on there, particularly by the end.
The results, summed to stereo: http://snwv.bandcamp.com/album/impulse
Now I'm experimenting the patch on oscillators: https://soundcloud.com/maurice-rickard/tonebubble2
In a few weeks, I'll be doing an improv show in which I'll use this on guitar. Should be fun.
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oh, cool--good to know. I wanted to have the learning experience of building it up from smaller elements, but I'll definitely check out the disis_munger~.
Thanks, Ivica!
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
On Apr 13, 2013, at 8:56 PM, Ivica Bukvic ico@vt.edu wrote:
FWIW all that you described can be done in one external disis_munger~ provided you don't go over 64 channels of audio output. Latest pd-l2ork will come prepackaged with this and some other flext externals.
Best wishes,
Ico
On Apr 13, 2013 1:02 PM, "Maurice Rickard" maurice@mauricerickard.com wrote: Last weekend I did an installation in a room wrapped in bubble-wrap. Friends had the idea, and asked me to "do something interesting with sound."
A bubble-wrap pop isn't terribly interesting on its own, so I thought I'd pitch-shift (starting with the pitchshift example patch) and delay the inputs, and then I added randomization of the pitch shifting and delay parameters. On top of that, I randomized the intervals at which the params were updated. I used four mic inputs and randomized panning to four outputs. The patch, ultimately, looked like this:
http://onezeromusic.com/snwv/impulse_noise.png
Kind of ugly there, but it's a work in progress, and worked great for the three-and-a-half-hour installation time. I didn't worry much about feedback, but the mics did pick up the input, so there was a generative thing going on there, particularly by the end.
The results, summed to stereo: http://snwv.bandcamp.com/album/impulse
Now I'm experimenting the patch on oscillators: https://soundcloud.com/maurice-rickard/tonebubble2
In a few weeks, I'll be doing an improv show in which I'll use this on guitar. Should be fun.
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Interesting! I like the final result
2013/4/13 Maurice Rickard maurice@mauricerickard.com:
Oh, cool--good to know. I wanted to have the learning experience of building it up from smaller elements, but I'll definitely check out the disis_munger~.
Thanks, Ivica!
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
On Apr 13, 2013, at 8:56 PM, Ivica Bukvic ico@vt.edu wrote:
FWIW all that you described can be done in one external disis_munger~ provided you don't go over 64 channels of audio output. Latest pd-l2ork will come prepackaged with this and some other flext externals.
Best wishes,
Ico
On Apr 13, 2013 1:02 PM, "Maurice Rickard" maurice@mauricerickard.com wrote:
Last weekend I did an installation in a room wrapped in bubble-wrap. Friends had the idea, and asked me to "do something interesting with sound."
A bubble-wrap pop isn't terribly interesting on its own, so I thought I'd pitch-shift (starting with the pitchshift example patch) and delay the inputs, and then I added randomization of the pitch shifting and delay parameters. On top of that, I randomized the intervals at which the params were updated. I used four mic inputs and randomized panning to four outputs. The patch, ultimately, looked like this:
http://onezeromusic.com/snwv/impulse_noise.png
Kind of ugly there, but it's a work in progress, and worked great for the three-and-a-half-hour installation time. I didn't worry much about feedback, but the mics did pick up the input, so there was a generative thing going on there, particularly by the end.
The results, summed to stereo: http://snwv.bandcamp.com/album/impulse
Now I'm experimenting the patch on oscillators: https://soundcloud.com/maurice-rickard/tonebubble2
In a few weeks, I'll be doing an improv show in which I'll use this on guitar. Should be fun.
Maurice Rickard http://mauricerickard.com | http://onezeromusic.com | http://yoctonaut.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks jbeezez@gmail.com wrote:
Hey all,
Some success finally:
Hurrah!!
The scl breakout pin on the pi proto plate wasn't working properly.
When unscrewed halfway it works, when fully screwed in it doesn't.
So - now got this:
i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- 0a -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
and
i2cdump -y 0 0xa No size specified (using byte-data access)
Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening.
Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this:
i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least.
Cheers,
Julian
On 12 April 2013 11:27, Julian Brooks jbeezez@gmail.com wrote:
Message resent for thread archives with smaller picture size.
Julian
---------- Forwarded message ---------- From: Julian Brooks jbeezez@gmail.com Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@iem.at
Hey Martin / list,
Finally got all the stuff and ...
It’s not working!
We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet.
Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off.
We then moved on to case 2 page 3 of this same document…
At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
The grid shows no attached devices every time we run it.
We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked).
As you can see we’re using a pi protoplate:
https://www.adafruit.com/products/801
In the photo I’ve attached the cables are coded as follows:
Orange GND
Yellow 5v
Blue SCL
Green SDA
The white is also 5v for the pull up resistors.
The resistor values are 4.7k btw.
We have tested the cable that terminates at the sensor and all that is OK.
I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v…
I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v…
Don’t know if this means anything or could be useful to know!
Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of).
I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare.
Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end.
Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd.
Any thoughts/pointers/options from anyone will be really appreciated?
Cheers,
Julian
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca>> Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/products/757#Blog/Flickr We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/products/801 In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Martin,
This is wonderful news.
Will add some more when I have an opportunity to test it out.
Yah!
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> Cc: PD List <pd-list@iem.at mailto:pd-list@iem.at>
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
yay! not yah! :)
On 19 April 2013 15:51, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
This is wonderful news.
Will add some more when I have an opportunity to test it out.
Yah!
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> Cc: PD List <pd-list@iem.at mailto:pd-list@iem.at>
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Hey Martin,
When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'?
In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger.
Julian
On 19 April 2013 19:51, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Ok -found I had to remove 'libi2c-dev'.
Then builds.
More soon...
On 19 April 2013 21:28, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'?
In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger.
Julian
On 19 April 2013 19:51, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
hmmm - both files: ./hello-2 Segmentation fault
Try again...
On 19 April 2013 21:51, Julian Brooks jbeezez@gmail.com wrote:
Ok -found I had to remove 'libi2c-dev'.
Then builds.
More soon...
On 19 April 2013 21:28, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'?
In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger.
Julian
On 19 April 2013 19:51, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.camartin.peach@sympatico.ca
>
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as
per the Omron ‘App Note 01’ spec sheet.
Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from
scratch to check that end.
Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too).
Also tried reinstalling libi2c-dev and then running 'hello' - same.
On 19 April 2013 21:54, Julian Brooks jbeezez@gmail.com wrote:
hmmm - both files: ./hello-2 Segmentation fault
Try again...
On 19 April 2013 21:51, Julian Brooks jbeezez@gmail.com wrote:
Ok -found I had to remove 'libi2c-dev'.
Then builds.
More soon...
On 19 April 2013 21:28, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'?
In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger.
Julian
On 19 April 2013 19:51, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.ca wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
Hi Martin,
Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers,
Julian
On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working
properly.
When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't
care currently as something is actually happening.
Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
.XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:
jbeezez@gmail.com>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.camartin.peach@sympatico.ca >> Cc: PD List <pd-list@iem.at mailto:pd-list@iem.at>
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as
per the Omron ‘App Note 01’ spec sheet.
Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/**
products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew
absolutely bugger all about any of this and now I do (sort of).
I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from
scratch to check that end.
Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks jbeezez@gmail.com wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too).
Also tried reinstalling libi2c-dev and then running 'hello' - same.
On 19 April 2013 21:54, Julian Brooks jbeezez@gmail.com wrote:
hmmm - both files: ./hello-2 Segmentation fault
Try again...
On 19 April 2013 21:51, Julian Brooks jbeezez@gmail.com wrote:
Ok -found I had to remove 'libi2c-dev'.
Then builds.
More soon...
On 19 April 2013 21:28, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'?
In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger.
Julian
On 19 April 2013 19:51, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin,
Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian
On 19 April 2013 14:36, Martin Peach martin.peach@sympatico.cawrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin
On 2013-04-19 07:01, Julian Brooks wrote:
> Hi Martin, > > Did you manage to make any progress with the sensor on the Pi? > I also wanted to ask whether the output we're receiving from i2cdump > makes any sense to you as it doesn't to us currently? Tried > searching > around for possible info on the 'XX' & 'ff' but drawing a blank here. > > Cheers, > > Julian > > > On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com > mailto:jbeezez@gmail.com> wrote: > > Hey all, > > Some success finally: > > Hurrah!! > > The scl breakout pin on the pi proto plate wasn't working > properly. > > When unscrewed halfway it works, when fully screwed in it > doesn't. > > So - now got this: > > i2cdetect -y 0 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > and > > i2cdump -y 0 0xa > No size specified (using byte-data access) > > Gives a whole host of stuff I don't yet understand but I don't > care > currently as something is actually happening. > > Will figure out a way of saving the console info (any hints > anyone?) as it gets badly mangled when cutting and pasting but > basically something like this: > > i2cdump -y 0 0xa > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e > f 0123456789abcdef > 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX > .XXXXXX.XXXX...X > 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX > X.XXXXX.X.X.XX.X > 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff > .XX.XX.XXXX.XXX. > 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX > X.X.XXXX...XXXXX > 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff > XXX.X.XXXdXX?XX. > 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX > X.XXXXXXX.XX.XXX > 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX > .XXX.XXXXXXXX.XX > 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX > XXXXXXX.XXXXXXXX > 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX > X.XX..XXX.XXXXXX > 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX > XX.XX.X.X..XX..X > a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX > X.XX.XXXXXXXXX.X > b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX > XX.XXX.XX.XXXXXX > c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX > XXXX.XX..XX..XXX > d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff > XXXXX.X.XXXXX.X. > e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX > XXX.X.XXXXXXXX.X > f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX > .X..XXXXXXXXXX.X > > > Progress at least. > > Cheers, > > Julian > > > > > > > > On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com > mailto:jbeezez@gmail.com> wrote: > > Message resent for thread archives with smaller picture size. > > Julian > > ---------- Forwarded message ---------- > From: *Julian Brooks* <jbeezez@gmail.com mailto: jbeezez@gmail.com>> > Date: 11 April 2013 19:24 > Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd > To: Martin Peach <martin.peach@sympatico.ca > <mailto:martin.peach@**sympatico.camartin.peach@sympatico.ca > >> > Cc: PD List <pd-list@iem.at mailto:pd-list@iem.at> > > > Hey Martin / list, > > Finally got all the stuff and ... > > It’s not working! > > We spent the day soldering cables and connecting stuff up as > per > the Omron ‘App Note 01’ spec sheet. > > Started off super-conservative using the I2C level converter > (case 3 page 4) http://www.adafruit.com/** > products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr > > We tried resistors on both sides (being super paranoid!) and > then we took the low (Pi) side ones off. > > We then moved on to case 2 page 3 of this same document… > > At each stage we checked with “I2Cdetect –Y 1” and nothing > was > visible. > > The grid shows no attached devices every time we run it. > > We re-booted at every stage following the various online > tutorials/methods of setting up I2C GPIO on the Pi (checked & > double checked). > > > As you can see we’re using a pi protoplate: > > https://www.adafruit.com/**products/801https://www.adafruit.com/products/801 > > In the photo I’ve attached the cables are coded as follows: > > Orange GND > > Yellow 5v > > Blue SCL > > Green SDA > > The white is also 5v for the pull up resistors. > > The resistor values are 4.7k btw. > > We have tested the cable that terminates at the sensor and > all > that is OK. > > I put a multimeter on the GND and SDA solder points on the > sensor itself and got 3.7v… > > I put a multimeter on the GND and SCL solder points on the > sensor itself and got 0.0v… > > Don’t know if this means anything or could be useful to know! > > Stuck and frustrated now but hey, 3 weeks ago I knew > absolutely > bugger all about any of this and now I do (sort of). > > I'm thinking we could do with the most basic i2c sensor we > can > find as we have nothing to compare. > > Tonight I'm going to d/l a fresh raspbian and start from > scratch > to check that end. > > Feel like if we can't get past the 'i2c-tools' tests we're > screwed - never mind getting it in and out of Pd. > > Any thoughts/pointers/options from anyone will be really > appreciated? > > > Cheers, > > > Julian > > > > > > > > > > ______________________________**_________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/** > listinfo/pd-list http://lists.puredata.info/listinfo/pd-list > >
Well that looks a total mess...
I did "sudo apt-get install i2c-dev" before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning.
Martin
On 2013-04-19 17:37, Julian Brooks wrote:
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh. I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff). Julian On 19 April 2013 14:36, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca>> wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens. Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here. Cheers, Julian On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> wrote: Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message ---------- From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca> <mailto:martin.peach@__sympatico.ca <mailto:martin.peach@sympatico.ca>>> Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at> <mailto:pd-list@iem.at <mailto:pd-list@iem.at>>> Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/__products/757#Blog/Flickr <http://www.adafruit.com/products/757#Blog/Flickr> We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/__products/801 <https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian _________________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining "if (argc > 0)" should say "if (argc > 1)".
Martin
On 2013-04-20 13:30, Martin Peach wrote:
Well that looks a total mess...
I did "sudo apt-get install i2c-dev" before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning.
Martin
On 2013-04-19 17:37, Julian Brooks wrote:
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally
defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh. I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi
https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian On 19 April 2013 14:36, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca>> wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens. Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here. Cheers, Julian On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> wrote: Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data
access)
Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data
access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> wrote: Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message
From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca> <mailto:martin.peach@__sympatico.ca <mailto:martin.peach@sympatico.ca>>> Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at> <mailto:pd-list@iem.at
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4)
http://www.adafruit.com/__products/757#Blog/Flickr
http://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/__products/801 <https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So I tested the 4X4 sensor and it actually works! Here is the code for a reader that sends to [netreceive 33333], and a receiver patch. You need to set the IP to that of the machine running Pd, and maybe other settings before compiling, as with the previous version.
Martin
On 2013-04-20 17:17, Martin Peach wrote:
Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining "if (argc > 0)" should say "if (argc > 1)".
Martin
On 2013-04-20 13:30, Martin Peach wrote:
Well that looks a total mess...
I did "sudo apt-get install i2c-dev" before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning.
Martin
On 2013-04-19 17:37, Julian Brooks wrote:
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally
defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0
not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi
https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian On 19 April 2013 14:36, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca>> wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens. Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here. Cheers, Julian On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data
access)
Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data
access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message
From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca> <mailto:martin.peach@__sympatico.ca <mailto:martin.peach@sympatico.ca>>> Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at> <mailto:pd-list@iem.at
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4)
http://www.adafruit.com/__products/757#Blog/Flickr
http://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/__products/801 <https://www.adafruit.com/products/801> In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Martin,
Yes indeed! Blimey.
So I added the localhost ip and changed the i2c port from 1 (rev2 boards) to 0 (rev1) on this line: sprintf(filename, "/dev/i2c-0"); Reinstalled libi2c-dev and boom - off it went. Wow.
Still getting some errors though wondering if these are the same ones you previously mentioned with the crc (PEC) checks not working correctly? :
Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F D6T_checkPEC says 0x52 182 140 148 154 156 160 160 162 162 159 166 173 170 172 176 173 172 <0x52> d6t44l 182 140 148 154 156 160 160 162 162 159 166 173 170 172 176 173 172
Data turning up in Pd and I'm quite happy (i.e. a bit delirious:)
Been quite an adventure with all this the last few weeks/month - soldering those tiny pins was well tricky, as was finding some housings!! Also built a couple of custom RPi images as minimal as poss and got quite a lot more oomph out of the cpu. Dipped my toes into C too which is cool - you know I had to search around how to run a C program - './' dur.
Would've been screwed without that C file of yours so thank you Martin.
Julian
On 20 April 2013 22:59, Martin Peach martin.peach@sympatico.ca wrote:
So I tested the 4X4 sensor and it actually works! Here is the code for a reader that sends to [netreceive 33333], and a receiver patch. You need to set the IP to that of the machine running Pd, and maybe other settings before compiling, as with the previous version.
Martin
On 2013-04-20 17:17, Martin Peach wrote:
Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining "if (argc > 0)" should say "if (argc > 1)".
Martin
On 2013-04-20 13:30, Martin Peach wrote:
Well that looks a total mess...
I did "sudo apt-get install i2c-dev" before all this, as well as all the things in http://www.instructables.com/**id/Raspberry-Pi-I2C-Python/#** step1 http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning.
Martin
On 2013-04-19 17:37, Julian Brooks wrote:
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:**38:8: error:
redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:**90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:**7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0
not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks <
jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi
https://projects.drogon.net/**raspberry-pi/wiringpi/the-**gpio-utility/https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian On 19 April 2013 14:36, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca<martin.peach@sympatico.ca>>>
wrote:
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens. Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here. Cheers, Julian On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data
access)
Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data
access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message
From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca<martin.peach@sympatico.ca>
<mailto:martin.peach@__sympati**
co.ca http://sympatico.ca <mailto:martin.peach@**sympatico.camartin.peach@sympatico.ca
>
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at> <mailto:pd-list@iem.at
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4)
http://www.adafruit.com/__**products/757#Blog/Flickrhttp://www.adafruit.com/__products/757#Blog/Flickr
<http://www.adafruit.com/**products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked & double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/__**products/801<https://www.adafruit.com/__products/801> <https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801>
In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of). I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to compare. Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**___________________ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__**listinfo/pd-listhttp://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
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?
Found the hints (same errors) here: http://ubuntuforums.org/archive/index.php/t-1833646.html and more pertinently here: https://github.com/symptog/rpi_lcd/issues/1
Both pages say the fix is to remove the lib.
On 21 April 2013 01:43, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
Yes indeed! Blimey.
So I added the localhost ip and changed the i2c port from 1 (rev2 boards) to 0 (rev1) on this line: sprintf(filename, "/dev/i2c-0"); Reinstalled libi2c-dev and boom - off it went. Wow.
Still getting some errors though wondering if these are the same ones you previously mentioned with the crc (PEC) checks not working correctly? :
Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F D6T_checkPEC says 0x52 182 140 148 154 156 160 160 162 162 159 166 173 170 172 176 173 172 <0x52> d6t44l 182 140 148 154 156 160 160 162 162 159 166 173 170 172 176 173 172
Data turning up in Pd and I'm quite happy (i.e. a bit delirious:)
Been quite an adventure with all this the last few weeks/month - soldering those tiny pins was well tricky, as was finding some housings!! Also built a couple of custom RPi images as minimal as poss and got quite a lot more oomph out of the cpu. Dipped my toes into C too which is cool - you know I had to search around how to run a C program - './' dur.
Would've been screwed without that C file of yours so thank you Martin.
Julian
On 20 April 2013 22:59, Martin Peach martin.peach@sympatico.ca wrote:
So I tested the 4X4 sensor and it actually works! Here is the code for a reader that sends to [netreceive 33333], and a receiver patch. You need to set the IP to that of the machine running Pd, and maybe other settings before compiling, as with the previous version.
Martin
On 2013-04-20 17:17, Martin Peach wrote:
Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining "if (argc > 0)" should say "if (argc > 1)".
Martin
On 2013-04-20 13:30, Martin Peach wrote:
Well that looks a total mess...
I did "sudo apt-get install i2c-dev" before all this, as well as all the things in http://www.instructables.com/**id/Raspberry-Pi-I2C-Python/#** step1 http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning.
Martin
On 2013-04-19 17:37, Julian Brooks wrote:
As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@>> %s << ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@<0x%02X> ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d)
BTW - I've removed libi2c-dev again and will leave it that way for now.
Going to stop now but will be back tomorrow.
Cheers,
Julian
On 19 April 2013 22:07, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks <jbeezez@gmail.com <mailto:jbeezez@gmail.com>> wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:**38:8: error:
redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:**90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:**7: note: originally defined here
Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0
not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh.
I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks <
jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi
https://projects.drogon.net/**raspberry-pi/wiringpi/the-** gpio-utility/https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff).
Julian On 19 April 2013 14:36, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca<martin.peach@sympatico.ca>>>
wrote:
Hi Julian, Yes I've been messing with coding it in c on
the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens.
Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with
the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' & 'ff' but drawing a blank here.
Cheers, Julian On 13 April 2013 01:11, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- --
10: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data
access)
Gives a whole host of stuff I don't
yet understand but I don't care currently as something is actually happening.
Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled
when cutting and pasting but basically something like this:
i2cdump -y 0 0xa No size specified (using byte-data
access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX .XXXXXX.XXXX...X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX X.XXXXX.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff .XX.XX.XXXX.XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX X.X.XXXX...XXXXX 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff XXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX X.XXXXXXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX .XXX.XXXXXXXX.XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX XXXXXXX.XXXXXXXX 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX X.XX..XXX.XXXXXX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX XX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX X.XX.XXXXXXXXX.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX XX.XXX.XX.XXXXXX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX XXXX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff XXXXX.X.XXXXX.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX XXX.X.XXXXXXXX.X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX .X..XXXXXXXXXX.X
Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks <jbeezez@gmail.com
mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com mailto:jbeezez@gmail.com>> wrote:
Message resent for thread archives with smaller picture size. Julian ---------- Forwarded message
From: *Julian Brooks* <jbeezez@gmail.com <mailto:jbeezez@gmail.com> <mailto:jbeezez@gmail.com <mailto:jbeezez@gmail.com>>> Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca<martin.peach@sympatico.ca>
<mailto:martin.peach@__sympati**
co.ca http://sympatico.ca <mailto:martin.peach@**sympatico.camartin.peach@sympatico.ca
>>
Cc: PD List <pd-list@iem.at <mailto:pd-list@iem.at> <mailto:pd-list@iem.at
Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec
sheet.
Started off super-conservative using the I2C level converter (case 3 page 4)
http://www.adafruit.com/__**products/757#Blog/Flickrhttp://www.adafruit.com/__products/757#Blog/Flickr
<http://www.adafruit.com/**products/757#Blog/Flickrhttp://www.adafruit.com/products/757#Blog/Flickr
We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up
I2C GPIO on the Pi (checked & double checked).
As you can see we’re using a pi protoplate: https://www.adafruit.com/__**products/801<https://www.adafruit.com/__products/801> <https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801>
In the photo I’ve attached the cables are coded as follows: Orange GND Yellow 5v Blue SCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… Don’t know if this means anything or could be useful to know! Stuck and frustrated now but hey,
3 weeks ago I knew absolutely bugger all about any of this and now I do (sort of).
I'm thinking we could do with the most basic i2c sensor we can find as we have nothing to
compare.
Tonight I'm going to d/l a fresh raspbian and start from scratch to check that end. Feel like if we can't get past the 'i2c-tools' tests we're screwed - never mind getting it in and out of Pd. Any thoughts/pointers/options from anyone will be really appreciated? Cheers, Julian
______________________________**___________________ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__**listinfo/pd-listhttp://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list
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
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@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
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.... "
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
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@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@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
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/d... and one of these: 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@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.... "
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
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@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@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
Sorry - meant to add this link from RPi forum about running 2 i2c busses: "enable both i2c busses" http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=33092&p=33684...
On 23 April 2013 10:06, Julian Brooks jbeezez@gmail.com 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/d... and one of these: 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@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.... "
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
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@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@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
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/d... and one of these: 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@gmail.com mailto:jbeezez@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 " 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 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@gmail.com <mailto:jbeezez@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@sympatico.ca <mailto:martin.peach@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
On 23 April 2013 14:45, Martin Peach martin.peach@sympatico.ca wrote:
Yes that would work too, if you can handle the soldering ;(
Don't think I can tbh - Don't like soldering at the best of times and those teeny pins and housings almost drove us to despair.
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.
Don't think this is possible with the rev1 board - I do have a rev2 so might have to jump ship, though my super minimal image has some networking issues - I can't get it to ssh and register on home network with fixed ip on rev2 (must be sortable).
Another way would be to have the Pd patch request a reading from a specific
sensor.
Can we do that if they have the same address?
I'm trying to think how this could be generalized into a useful Pd external
but it seems very specific to a particular setup.
Yep - it is very specific, bloody good tho'.
Julian
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/1426182http://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/2212120http://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@gmail.com mailto:jbeezez@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.pdfhttp://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@gmail.com <mailto:jbeezez@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@sympatico.ca <mailto:martin.peach@**sympatico.ca <martin.peach@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
"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@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/1426182http://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/2212120http://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@gmail.com mailto:jbeezez@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.pdfhttp://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@gmail.com <mailto:jbeezez@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@sympatico.ca <mailto:martin.peach@**sympatico.ca <martin.peach@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
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
'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
On 2013-04-25 10:37, Julian Brooks wrote:
'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).
The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots.
And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins?
I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit.
Martin
Just spotted this: https://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-04-25 10:37, Julian Brooks wrote:
'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).
The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots.
And also are you attaching the MC14051 to any type of board/adaptor or
just soldering straight on to the pins?
I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit.
Martin
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup.
Martin
On 2013-04-25 20:04, Julian Brooks wrote:
Just spotted this: https://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca> wrote:
On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
Super-useful, thanks Martin.
Will be testing it out in a couple of days so will report back then.
Julian
On 29 April 2013 16:38, Martin Peach martin.peach@sympatico.ca wrote:
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup.
Martin
On 2013-04-25 20:04, Julian Brooks wrote:
Just spotted this: https://github.com/kadamski/**i2c-gpio-paramhttps://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> wrote:
On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
Hi Martin / all,
Possibly overly-nerdy question here:
I'm buying the various bits and pieces we require for the multiplexer and I'm noticing quite a difference in pricing options for the pull-up resistors. There's this one: http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938 which is 86p each. Or there's something like this: http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/933906... which is 2p each.
The former's spec sheet talks about its very low noise ratio and thinking on from reading the sensors spec sheet it's also pushed there to use low-noise components.
Do you think it actually makes any difference? I have to buy a minimum 50 of the cheap ones so buying a couple of the dearer ones doesn't actually make much of a difference.
It got me thinking as you mentioned that your getting virtually no PEC errors from the sensors whereas as we are getting them very regularly. I had been thinking it was the soldering of those pernickety sensors but could it also be the cheap 4k resistors currently on our board?
Cheers,
Julian
On 29 April 2013 16:38, Martin Peach martin.peach@sympatico.ca wrote:
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup.
Martin
On 2013-04-25 20:04, Julian Brooks wrote:
Just spotted this: https://github.com/kadamski/**i2c-gpio-paramhttps://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> wrote:
On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
BTW This is the multiplexer: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109 and the housing: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846
Think these are right?
On 29 April 2013 22:44, Julian Brooks jbeezez@gmail.com wrote:
Hi Martin / all,
Possibly overly-nerdy question here:
I'm buying the various bits and pieces we require for the multiplexer and I'm noticing quite a difference in pricing options for the pull-up resistors. There's this one: http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938 which is 86p each. Or there's something like this:
http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/933906... which is 2p each.
The former's spec sheet talks about its very low noise ratio and thinking on from reading the sensors spec sheet it's also pushed there to use low-noise components.
Do you think it actually makes any difference? I have to buy a minimum 50 of the cheap ones so buying a couple of the dearer ones doesn't actually make much of a difference.
It got me thinking as you mentioned that your getting virtually no PEC errors from the sensors whereas as we are getting them very regularly. I had been thinking it was the soldering of those pernickety sensors but could it also be the cheap 4k resistors currently on our board?
Cheers,
Julian
On 29 April 2013 16:38, Martin Peach martin.peach@sympatico.ca wrote:
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup.
Martin
On 2013-04-25 20:04, Julian Brooks wrote:
Just spotted this: https://github.com/kadamski/**i2c-gpio-paramhttps://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> wrote:
On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for
robots.
And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
On 2013-04-29 17:59, Julian Brooks wrote:
BTW This is the multiplexer: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109 and the housing: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846
Think these are right?
Yes.
Martin
:) - ta
On 29 April 2013 23:07, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-04-29 17:59, Julian Brooks wrote:
BTW This is the multiplexer: http://uk.farnell.com/jsp/**search/productdetail.jsp?sku=**1106109http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109 and the housing: http://uk.farnell.com/jsp/**search/productdetail.jsp?sku=**1103846http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846
Think these are right?
Yes.
Martin
Ordinary 5% resistors will work fine. Probably anything from 1k to 100k would work. Most likely you have a loose connection somewhere. Did you try running the bus at a lower speed? If your wiring is long (> 10cm) it may be better to run it slower.
Martin
On 2013-04-29 17:44, Julian Brooks wrote:
Hi Martin / all,
Possibly overly-nerdy question here:
I'm buying the various bits and pieces we require for the multiplexer and I'm noticing quite a difference in pricing options for the pull-up resistors. There's this one: http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938 which is 86p each. Or there's something like this: http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/933906... which is 2p each.
The former's spec sheet talks about its very low noise ratio and thinking on from reading the sensors spec sheet it's also pushed there to use low-noise components.
Do you think it actually makes any difference? I have to buy a minimum 50 of the cheap ones so buying a couple of the dearer ones doesn't actually make much of a difference.
It got me thinking as you mentioned that your getting virtually no PEC errors from the sensors whereas as we are getting them very regularly. I had been thinking it was the soldering of those pernickety sensors but could it also be the cheap 4k resistors currently on our board?
Cheers,
Julian
On 29 April 2013 16:38, Martin Peach <martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca> wrote:
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup. Martin On 2013-04-25 20:04, Julian Brooks wrote: Just spotted this: https://github.com/kadamski/__i2c-gpio-param <https://github.com/kadamski/i2c-gpio-param> Could be useful On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca> <mailto:martin.peach@__sympatico.ca <mailto:martin.peach@sympatico.ca>>> wrote: On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
Hey Martin / all,
Oh there's much chin scratching and head shaking going on at our end atm...
Can we ask if we have the hardware configured correctly before moving onto software issues please:
Attached is the diagram of our 4051 mux'er.
This is what we have and aren't sure if it's correct 16 to 3.3v RPi 14 to SCL (sensor 1) 13 to SCL (sensor 2) [Each SCL has 10k resistor and a feed of 3.3v from RPi] 11 to P1-11 (GPIO 17) - RPi 10 to SDA (sensor 1) 9 to SDA (sensor 2) 7 to Ground 3 to SDA P1-03 (GPIO 0) - RPi
The power for the sensors is wired directly into 5v from the RPi. The ground for the sensors is wired directly into the RPi.
I'm not sure if this has happened after running the code for the sensors but I'm now unable to access the i2c busses:
cat /dev/i2c* cat: /dev/i2c-0: Input/output error cat: /dev/i2c-1: Input/output error
I note from the code that we're now using gpio17 instead of the i2c busses which would account for that error I guess?
Few more coding issues but feel like we could do with some confirmation that the hardware's correct before moving on?
Cheers,
Julian
On 29 April 2013 16:38, Martin Peach martin.peach@sympatico.ca wrote:
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup.
Martin
On 2013-04-25 20:04, Julian Brooks wrote:
Just spotted this: https://github.com/kadamski/i2c-gpio-param Could be useful
On 25 April 2013 15:54, Martin Peach <martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca> wrote:
On 2013-04-25 10:37, Julian Brooks wrote: '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). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin
On 2013-05-03 10:26, Julian Brooks wrote:
Hey Martin / all,
..
This is what we have and aren't sure if it's correct
Yes it's a bit wrong...
16 to 3.3v RPi 14 to SCL (sensor 1)
Yes, pin 3 is connected through to pin 13 when pin 11 is low, and to pin 14 when 11 is high. So it's actually sensor 2 on pin 14.
13 to SCL (sensor 2)
Is actually sensor 1
[Each SCL has 10k resistor and a feed of 3.3v from RPi] 11 to P1-11 (GPIO 17) - RPi
Yes, 11 selects which channel. 9,10, and 11 make up a 3-bit address which selects which of the 8 output channels is connected to the input on pin 3. If you only have 2 sensors the two extra selector pins must be set low.
10 to SDA (sensor 1)
10 to Ground or another selector pin if you have more than 2 sensors The sensor data pins are connected directly to the RPi SDA pin, only the SCL line goes through the 4051.
9 to SDA (sensor 2)
9 to Ground or another selector pin
7 to Ground
Also, 6 (Inhibit) must be low for the chip to function (this permits expanding to more than 8 channels by using more 4051s) Pin 8 to Ground
3 to SDA P1-03 (GPIO 0) - RPi
3 to SCL RPi, you're switching the clock line, not the data
The power for the sensors is wired directly into 5v from the RPi. The ground for the sensors is wired directly into the RPi.
Martin
Ok - thanks for that, makes more sense now.
When I run the C code this happens:
"./jb_d6t_reader_ic3 0 ...export file accessed, new pin now accessible ...direction set to output ./jb_d6t_reader_ic3: initialized:0 Write failed (5)
Input/output error <<
...unexport file accessed, pin now inaccessible"
I've done my best to go through the code and make changes where appropriate.
Replaced D6T8L with DRT44L2 and changed packet size. Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to 0 for rev1 board.
Weirdly I can't access the i2c bus anymore? cat /dev/i2c* cat: /dev/i2c-0: Input/output error cat: /dev/i2c-1: Input/output error
Tried to follow the code to figure where it's falling down but I'm not getting it.
Also do I still need 1 or 0 after './jb_d6t_reader_ic(n)? 1 seems to make it to go into PEC spiral with no readings.
Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F Read failed (5)
Input/output error <<
D6T_checkPEC says 0x8F Read failed (5)
Input/output error <<
etc etc.
i2cdetect -y 0 also draws a blank.
Very best wishes,
Julian
On 3 May 2013 16:31, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-03 10:26, Julian Brooks wrote:
Hey Martin / all,
..
This is what we have and aren't sure if it's correct
Yes it's a bit wrong...
16 to 3.3v RPi
14 to SCL (sensor 1)
Yes, pin 3 is connected through to pin 13 when pin 11 is low, and to pin 14 when 11 is high. So it's actually sensor 2 on pin 14.
13 to SCL (sensor 2)
Is actually sensor 1
[Each SCL has 10k resistor and a feed of 3.3v from RPi]
11 to P1-11 (GPIO 17) - RPi
Yes, 11 selects which channel. 9,10, and 11 make up a 3-bit address which selects which of the 8 output channels is connected to the input on pin 3. If you only have 2 sensors the two extra selector pins must be set low.
10 to SDA (sensor 1)
10 to Ground or another selector pin if you have more than 2 sensors The sensor data pins are connected directly to the RPi SDA pin, only the SCL line goes through the 4051.
9 to SDA (sensor 2)
9 to Ground or another selector pin
7 to Ground
Also, 6 (Inhibit) must be low for the chip to function (this permits expanding to more than 8 channels by using more 4051s) Pin 8 to Ground
3 to SDA P1-03 (GPIO 0) - RPi
3 to SCL RPi, you're switching the clock line, not the data
The power for the sensors is wired directly into 5v from the RPi. The ground for the sensors is wired directly into the RPi.
Martin
On 2013-05-03 12:34, Julian Brooks wrote:
Ok - thanks for that, makes more sense now.
When I run the C code this happens:
"./jb_d6t_reader_ic3 0 ...export file accessed, new pin now accessible ...direction set to output ./jb_d6t_reader_ic3: initialized:0 Write failed (5)
Input/output error <<
...unexport file accessed, pin now inaccessible"
I've done my best to go through the code and make changes where appropriate.
Replaced D6T8L with DRT44L2 and changed packet size. Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to 0 for rev1 board.
Weirdly I can't access the i2c bus anymore? cat /dev/i2c* cat: /dev/i2c-0: Input/output error cat: /dev/i2c-1: Input/output error
Yes I get that too. (unless the sensor returns one byte it's probably normal) But "i2cdetect -y 1" still shows a sensor at 0x0A. I run the code as "sudo ./d6t_reader 0", otherwise I don't have permission to set the GPIO pin. I don't get any write errors though. Are you writing to the correct i2c? There are two places in the code that could throw the write error. Maybe change the message so you can tell which one it is. Anyway the setup should work with the old code (only one sensor), the 4051 circuit should have no effect on the communication betwen the Pi and one of the sensors, the select pin select which sensor receives the clock. So if the older code isn't working the circuit is wrong, otherwise the code is buggy.
Martin
Hey Martin / all,
Had to put this down for a few days but back at it today.
Finally got it working - huzzah!
I changed the c file so that although it's gpio17 it's actually pin 11 (define_SENSOR_SELECT_PIN) and boom! Why the numbering scheme is so confusing is beyond me but anyway.
Also for us we're running the IC at 5v as well as the 10k resistors on the clock line.
Thanks again Martin - you rock.
Have a great weekend,
Julian
On 3 May 2013 18:17, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-03 12:34, Julian Brooks wrote:
Ok - thanks for that, makes more sense now.
When I run the C code this happens:
"./jb_d6t_reader_ic3 0 ...export file accessed, new pin now accessible ...direction set to output ./jb_d6t_reader_ic3: initialized:0 Write failed (5)
Input/output error <<
...unexport file accessed, pin now inaccessible"
I've done my best to go through the code and make changes where appropriate.
Replaced D6T8L with DRT44L2 and changed packet size. Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to 0 for rev1 board.
Weirdly I can't access the i2c bus anymore? cat /dev/i2c* cat: /dev/i2c-0: Input/output error cat: /dev/i2c-1: Input/output error
Yes I get that too. (unless the sensor returns one byte it's probably normal) But "i2cdetect -y 1" still shows a sensor at 0x0A. I run the code as "sudo ./d6t_reader 0", otherwise I don't have permission to set the GPIO pin. I don't get any write errors though. Are you writing to the correct i2c? There are two places in the code that could throw the write error. Maybe change the message so you can tell which one it is. Anyway the setup should work with the old code (only one sensor), the 4051 circuit should have no effect on the communication betwen the Pi and one of the sensors, the select pin select which sensor receives the clock. So if the older code isn't working the circuit is wrong, otherwise the code is buggy.
Martin
On 2013-05-09 12:25, Julian Brooks wrote:
Hey Martin / all,
Had to put this down for a few days but back at it today.
Finally got it working - huzzah!
That's great!
I changed the c file so that although it's gpio17 it's actually pin 11 (define_SENSOR_SELECT_PIN) and boom! Why the numbering scheme is so confusing is beyond me but anyway.
Also for us we're running the IC at 5v as well as the 10k resistors on the clock line.
Unless you have level shifters you should have the 10ks to 3.3V. (Although at 10k, it's probably not too dangerous to go to 5V)
Thanks again Martin - you rock.
Have a great weekend,
Have a great sensation;)
Martin
Hallo again,
10k's and clock now at 3.3v but the IC only works at 5v.
Got a bit carried away before - my friend George, who's the sensor co-explorer, is normally only available on Friday's so very much had that Friday feeling - and of course giddy with the sensors all finally working. Started to lose the plot with it all last weekend and was getting a bit frenzied with my interactions on the breadboard - was probably the wise thing to just put it down for a few days and come back with a clear head.
Think my codes still a bit buggy as I'm only getting one sensor coming into Pd but have 2 sets from the console.
Back to it,
Julian
On 9 May 2013 18:41, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-09 12:25, Julian Brooks wrote:
Hey Martin / all,
Had to put this down for a few days but back at it today.
Finally got it working - huzzah!
That's great!
I changed the c file so that although it's gpio17 it's actually pin 11 (define_SENSOR_SELECT_PIN) and boom! Why the numbering scheme is so confusing is beyond me but anyway.
Also for us we're running the IC at 5v as well as the 10k resistors on the clock line.
Unless you have level shifters you should have the 10ks to 3.3V. (Although at 10k, it's probably not too dangerous to go to 5V)
Thanks again Martin - you rock.
Have a great weekend,
Have a great sensation;)
Martin
Hey Martin,
Can I please peck your head hopefully one last time?
We're so close, got the hardware for the installation up and running, box made etc etc.
Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't-see-it!!
Keep wondering if there's a way of being able to test the 2nd sensor in a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one.
Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file.
As per usual any and all comments/advice gratefully received.
Cheers,
Julian
On 9 May 2013 23:42, Julian Brooks jbeezez@gmail.com wrote:
Hallo again,
10k's and clock now at 3.3v but the IC only works at 5v.
Got a bit carried away before - my friend George, who's the sensor co-explorer, is normally only available on Friday's so very much had that Friday feeling - and of course giddy with the sensors all finally working. Started to lose the plot with it all last weekend and was getting a bit frenzied with my interactions on the breadboard - was probably the wise thing to just put it down for a few days and come back with a clear head.
Think my codes still a bit buggy as I'm only getting one sensor coming into Pd but have 2 sets from the console.
Back to it,
Julian
On 9 May 2013 18:41, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-09 12:25, Julian Brooks wrote:
Hey Martin / all,
Had to put this down for a few days but back at it today.
Finally got it working - huzzah!
That's great!
I changed the c file so that although it's gpio17 it's actually pin 11 (define_SENSOR_SELECT_PIN) and boom! Why the numbering scheme is so confusing is beyond me but anyway.
Also for us we're running the IC at 5v as well as the 10k resistors on the clock line.
Unless you have level shifters you should have the 10ks to 3.3V. (Although at 10k, it's probably not too dangerous to go to 5V)
Thanks again Martin - you rock.
Have a great weekend,
Have a great sensation;)
Martin
On 2013-05-17 09:39, Julian Brooks wrote:
Hey Martin,
Can I please peck your head hopefully one last time?
Sure.
We're so close, got the hardware for the installation up and running, box made etc etc.
Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't-see-it!!
You need to show me your code... The file I sent was to read two sensors. The second was the 1X8 sensor so it reads a different number of bytes. You have to change that, everything else should be the same..
Keep wondering if there's a way of being able to test the 2nd sensor in a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one.
Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V or ground to select one or the other. But disconnect the GPIO pin when you do that.
Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file.
Sounds like the multiplexer isn't working right. Do you have a photo of your setup? Can you confirm that the GPIO pin switches?
Martin
Sorry meant to attach the code (doh!).
My compadre has all the photo's on his phone so will give him a nudge now and get back to you when I hear from him...
(hey George:)
Thanks for the testing tip - of course, seems so obvious now that you've said it.
And I guess we can't definitely confirm that the pin switches although the last big problem we had was that I'd set the switch to pin 17 rather than pin 11 (gpio 17). What would happen then is that we would get one reading from the 1st sensor and then it would stall/quit-out.
More soon hopefully,
Julian
On 17 May 2013 15:14, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-05-17 09:39, Julian Brooks wrote:
Hey Martin,
Can I please peck your head hopefully one last time?
Sure.
We're so close, got the hardware for the installation up and running,
box made etc etc.
Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't-see-it!!
You need to show me your code... The file I sent was to read two sensors. The second was the 1X8 sensor so it reads a different number of bytes. You have to change that, everything else should be the same..
Keep wondering if there's a way of being able to test the 2nd sensor in
a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one.
Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V or ground to select one or the other. But disconnect the GPIO pin when you do that.
Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file.
Sounds like the multiplexer isn't working right. Do you have a photo of your setup? Can you confirm that the GPIO pin switches?
Martin
It looks like you're confused about the GPIO pin. SENSOR_SELECT_PIN should be 17 because that's what the ARM chip calls it. The fact that it is on pin 11 of the header is irrelevant to the program. The next confusing thing is that GPIO17 on pin 11 of the header connects to pin 11 of the 4051. If you want to see if the pin is working you can put an LED from pin 11 of the header to ground and see if it flashes when you run the program. I had to run it as sudo because regular users don't have permission to access the GPIO pins.
Martin
On 2013-05-17 10:50, Julian Brooks wrote:
Sorry meant to attach the code (doh!).
My compadre has all the photo's on his phone so will give him a nudge now and get back to you when I hear from him...
(hey George:)
Thanks for the testing tip - of course, seems so obvious now that you've said it.
And I guess we can't definitely confirm that the pin switches although the last big problem we had was that I'd set the switch to pin 17 rather than pin 11 (gpio 17). What would happen then is that we would get one reading from the 1st sensor and then it would stall/quit-out.
More soon hopefully,
Julian
On 17 May 2013 15:14, Martin Peach <martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca> wrote:
On 2013-05-17 09:39, Julian Brooks wrote: Hey Martin, Can I please peck your head hopefully one last time? Sure. We're so close, got the hardware for the installation up and running, box made etc etc. Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't\-see\-it!! You need to show me your code... The file I sent was to read two sensors. The second was the 1X8 sensor so it reads a different number of bytes. You have to change that, everything else should be the same.. Keep wondering if there's a way of being able to test the 2nd sensor in a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one. Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V or ground to select one or the other. But disconnect the GPIO pin when you do that. Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file. Sounds like the multiplexer isn't working right. Do you have a photo of your setup? Can you confirm that the GPIO pin switches? Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Aargh - you're right, I am confused (so very)...
So, to be clear #define SENSOR_SELECT_PIN 11 should be #define SENSOR_SELECT_PIN 17 After all?
It is then going to pin 11 on the 4051.
Running as root so need for sudo (yes I know)
As Max Romeo said: "One step forwards, two steps backwards" :)
J
Will try the led test and the updated code when I can get back to it in a couple of days or so.
On 17 May 2013 16:20, Martin Peach martin.peach@sympatico.ca wrote:
It looks like you're confused about the GPIO pin. SENSOR_SELECT_PIN should be 17 because that's what the ARM chip calls it. The fact that it is on pin 11 of the header is irrelevant to the program. The next confusing thing is that GPIO17 on pin 11 of the header connects to pin 11 of the 4051. If you want to see if the pin is working you can put an LED from pin 11 of the header to ground and see if it flashes when you run the program. I had to run it as sudo because regular users don't have permission to access the GPIO pins.
Martin
On 2013-05-17 10:50, Julian Brooks wrote:
Sorry meant to attach the code (doh!).
My compadre has all the photo's on his phone so will give him a nudge now and get back to you when I hear from him...
(hey George:)
Thanks for the testing tip - of course, seems so obvious now that you've said it.
And I guess we can't definitely confirm that the pin switches although the last big problem we had was that I'd set the switch to pin 17 rather than pin 11 (gpio 17). What would happen then is that we would get one reading from the 1st sensor and then it would stall/quit-out.
More soon hopefully,
Julian
On 17 May 2013 15:14, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@**sympatico.ca martin.peach@sympatico.ca>> wrote:
On 2013-05-17 09:39, Julian Brooks wrote: Hey Martin, Can I please peck your head hopefully one last time? Sure. We're so close, got the hardware for the installation up and running, box made etc etc. Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't\-see\-it!! You need to show me your code... The file I sent was to read two sensors. The second was the 1X8 sensor so it reads a different number of bytes. You have to change that, everything else should be the same.. Keep wondering if there's a way of being able to test the 2nd sensor in a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one. Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V or ground to select one or the other. But disconnect the GPIO pin when you do that. Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file. Sounds like the multiplexer isn't working right. Do you have a photo of your setup? Can you confirm that the GPIO pin switches? Martin
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Yep. Here's a diagram that shows the wiring.
Martin
On 2013-05-17 11:42, Julian Brooks wrote:
Aargh - you're right, I am confused (so very)...
So, to be clear #define SENSOR_SELECT_PIN 11 should be #define SENSOR_SELECT_PIN 17 After all?
It is then going to pin 11 on the 4051.
Running as root so need for sudo (yes I know)
As Max Romeo said: "One step forwards, two steps backwards" :)
J
Will try the led test and the updated code when I can get back to it in a couple of days or so.
On 17 May 2013 16:20, Martin Peach <martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca> wrote:
It looks like you're confused about the GPIO pin. SENSOR_SELECT_PIN should be 17 because that's what the ARM chip calls it. The fact that it is on pin 11 of the header is irrelevant to the program. The next confusing thing is that GPIO17 on pin 11 of the header connects to pin 11 of the 4051. If you want to see if the pin is working you can put an LED from pin 11 of the header to ground and see if it flashes when you run the program. I had to run it as sudo because regular users don't have permission to access the GPIO pins. Martin On 2013-05-17 10:50, Julian Brooks wrote: Sorry meant to attach the code (doh!). My compadre has all the photo's on his phone so will give him a nudge now and get back to you when I hear from him... (hey George:) Thanks for the testing tip - of course, seems so obvious now that you've said it. And I guess we can't definitely confirm that the pin switches although the last big problem we had was that I'd set the switch to pin 17 rather than pin 11 (gpio 17). What would happen then is that we would get one reading from the 1st sensor and then it would stall/quit-out. More soon hopefully, Julian On 17 May 2013 15:14, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca> <mailto:martin.peach@__sympatico.ca <mailto:martin.peach@sympatico.ca>>> wrote: On 2013-05-17 09:39, Julian Brooks wrote: Hey Martin, Can I please peck your head hopefully one last time? Sure. We're so close, got the hardware for the installation up and running, box made etc etc. Could you have a once-over of our code: Still only seeing one sensor though all of our multimeter testing says sensor 2 is fine and ready to go. I think it has to be a code problem in the C file but I just_can't\-see\-it!! You need to show me your code... The file I sent was to read two sensors. The second was the 1X8 sensor so it reads a different number of bytes. You have to change that, everything else should be the same.. Keep wondering if there's a way of being able to test the 2nd sensor in a similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC switcher so it would allow us to run the test on the 2nd one. Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V or ground to select one or the other. But disconnect the GPIO pin when you do that. Pd is receiving on both sends (44l & 44l2) but all we have is one sensors readings - same in the prints from the C file. Sounds like the multiplexer isn't working right. Do you have a photo of your setup? Can you confirm that the GPIO pin switches? Martin _________________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Hey Martin,
Many thanks for the extra wiring diagram.
We managed to confirm both sensors are working via pin11 from the IC going between earth & 3v with gpio17 disconnected and running i2cdetect.
That was really useful as it was the first definite confirmation that both sensors are working correctly.
In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all!
To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working.
This is also after spending a half hour this morning checking and double checking all the various lines and connections.
So working now - blimey.
OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput.
The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with.
So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/ and works really well so far-which is good. Didn't get my patching done though:)
Long way of saying that I've updated my C file to reflect this and all working lovely.
Thank you thank you thank you.
Been much fun,
Julian
P.S. Will give this thread a nudge when I've documented it all (it's a whopper)
Just checked it again and noticeably in comparison to all our previous testing there is now (as good as) zero errors from the sensors. Rock solid. Joy.
On 23 May 2013 13:16, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
Many thanks for the extra wiring diagram.
We managed to confirm both sensors are working via pin11 from the IC going between earth & 3v with gpio17 disconnected and running i2cdetect.
That was really useful as it was the first definite confirmation that both sensors are working correctly.
In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all!
To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working.
This is also after spending a half hour this morning checking and double checking all the various lines and connections.
So working now - blimey.
OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput.
The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with.
So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/ and works really well so far-which is good. Didn't get my patching done though:)
Long way of saying that I've updated my C file to reflect this and all working lovely.
Thank you thank you thank you.
Been much fun,
Julian
P.S. Will give this thread a nudge when I've documented it all (it's a whopper)
Joining late to the discussion--is there now a native Pd external that allows direct connection to RPi pins or is there still a need to use middleware to access the data steam? If former, where can one get their hands on the source--I would love to include it in the next pd-l2ork RPi release?
Please advise. On May 23, 2013 8:20 AM, "Julian Brooks" jbeezez@gmail.com wrote:
Just checked it again and noticeably in comparison to all our previous testing there is now (as good as) zero errors from the sensors. Rock solid. Joy.
On 23 May 2013 13:16, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
Many thanks for the extra wiring diagram.
We managed to confirm both sensors are working via pin11 from the IC going between earth & 3v with gpio17 disconnected and running i2cdetect.
That was really useful as it was the first definite confirmation that both sensors are working correctly.
In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all!
To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working.
This is also after spending a half hour this morning checking and double checking all the various lines and connections.
So working now - blimey.
OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput.
The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with.
So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/ and works really well so far-which is good. Didn't get my patching done though:)
Long way of saying that I've updated my C file to reflect this and all working lovely.
Thank you thank you thank you.
Been much fun,
Julian
P.S. Will give this thread a nudge when I've documented it all (it's a whopper)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Ivica,
All the info is on this thread: http://www.mail-archive.com/pd-list@iem.at/msg57752.html
The object is [gpio] and whilst working fine, is pretty basic. Jaime's helpfile is very useful and recommended.
OAN - Had a quick look at your site for the RPI version of pd-l2ork - really excellent documentation, looks great, hats off to you.
Should have more time next month to properly engage with pd-l2ork - looking forward to it.
Cheers, Julian
On 3 June 2013 05:42, Ivica Bukvic ico@vt.edu wrote:
Joining late to the discussion--is there now a native Pd external that allows direct connection to RPi pins or is there still a need to use middleware to access the data steam? If former, where can one get their hands on the source--I would love to include it in the next pd-l2ork RPi release?
Please advise. On May 23, 2013 8:20 AM, "Julian Brooks" jbeezez@gmail.com wrote:
Just checked it again and noticeably in comparison to all our previous testing there is now (as good as) zero errors from the sensors. Rock solid. Joy.
On 23 May 2013 13:16, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
Many thanks for the extra wiring diagram.
We managed to confirm both sensors are working via pin11 from the IC going between earth & 3v with gpio17 disconnected and running i2cdetect.
That was really useful as it was the first definite confirmation that both sensors are working correctly.
In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all!
To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working.
This is also after spending a half hour this morning checking and double checking all the various lines and connections.
So working now - blimey.
OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput.
The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with.
So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/ and works really well so far-which is good. Didn't get my patching done though:)
Long way of saying that I've updated my C file to reflect this and all working lovely.
Thank you thank you thank you.
Been much fun,
Julian
P.S. Will give this thread a nudge when I've documented it all (it's a whopper)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thank you very much!
From: Julian Brooks [mailto:jbeezez@gmail.com] Sent: Monday, June 03, 2013 6:11 AM To: Ivica Bukvic Cc: pd-list; Martin Peach; George Naylor Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
Hey Ivica,
All the info is on this thread: http://www.mail-archive.com/pd-list@iem.at/msg57752.html
The object is [gpio] and whilst working fine, is pretty basic. Jaime's helpfile is very useful and recommended.
OAN - Had a quick look at your site for the RPI version of pd-l2ork - really excellent documentation, looks great, hats off to you.
Should have more time next month to properly engage with pd-l2ork - looking forward to it.
Cheers,
Julian
On 3 June 2013 05:42, Ivica Bukvic ico@vt.edu wrote:
Joining late to the discussion--is there now a native Pd external that allows direct connection to RPi pins or is there still a need to use middleware to access the data steam? If former, where can one get their hands on the source--I would love to include it in the next pd-l2ork RPi release?
Please advise.
On May 23, 2013 8:20 AM, "Julian Brooks" jbeezez@gmail.com wrote:
Just checked it again and noticeably in comparison to all our previous testing there is now (as good as) zero errors from the sensors. Rock solid. Joy.
On 23 May 2013 13:16, Julian Brooks jbeezez@gmail.com wrote:
Hey Martin,
Many thanks for the extra wiring diagram.
We managed to confirm both sensors are working via pin11 from the IC going between earth & 3v with gpio17 disconnected and running i2cdetect.
That was really useful as it was the first definite confirmation that both sensors are working correctly.
In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all!
To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working.
This is also after spending a half hour this morning checking and double checking all the various lines and connections.
So working now - blimey.
OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput.
The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with.
So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/
and works really well so far-which is good. Didn't get my patching done though:)
Long way of saying that I've updated my C file to reflect this and all working lovely.
Thank you thank you thank you.
Been much fun,
Julian
P.S. Will give this thread a nudge when I've documented it all (it's a whopper)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2013-04-23 04:42, Julian Brooks 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.... "
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.
Seems Digikey stopped selling the part, Mouser has it now (http://ca.mouser.com/ProductDetail/Omron/D6T-44L-06/?qs=%2fha2pyFaduiRuNG9v%...), and there's a document there that has something about using multiple sensors on one bus: http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.p...
We've still got 2 of these doing nothing currently if they could be brought into action: http://adafruit.com/products/757
That will only convert levels, it's not a multiplexer. I found that the sensor works fine with the pullups to 3.3V on the RPi. Seems to me the easiest way to multiplex them would be to put a CD4051 on the clock line and use up to 3 GPIO pins to select which of up to 8 sensors receives the clock. The only tricky bit would be making sure the clock is at the right level when the switching tales place, you might need ~10k pullups to 3.3V on the sensor clock pins.
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?
Yes that's what happens already. I was getting errors at first because the crc calculation was being done over both the write and read packets. I found that calculating only the read packet gives the correct value almost always. If the PEC is wrong, the code simply asks for another packet. At the moment I'm getting almost no errors.
Still delighted though - the sensors great!
Yes, it even works as an icecube detector!
Martin
Cheers,
Julian
On 22 April 2013 00:20, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@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@sympatico.ca <mailto:martin.peach@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
and there's a document there that has something about using multiple
sensors on one bus:
http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.p...
That's a much better doc.
Seems to me the easiest way to multiplex them would be to put a CD4051 on
the clock line and use up to 3 GPIO pins to select which of up to 8 sensors receives the clock. The only tricky bit would be making sure the clock is at the right level when the switching tales place, you might need ~10k pullups to 3.3V on the sensor clock pins.
(did you spot my previous post with this and if so would that work?)
Yes that's what happens already. I was getting errors at first because the crc calculation was being done over both the write and read packets. I found that calculating only the read packet gives the correct value almost always. If the PEC is wrong, the code simply asks for another packet. At the moment I'm getting almost no errors
Maybe there's something I'm missing here then:
The average temp that comes out of [unpack 1] is way higher than the rest of the readings. At the moment [unpack 1] says '212' yet a quick averaging of the other 16 readings is around '180'?
Yes, it even works as an icecube detector!
:D
On 2013-04-23 09:32, Julian Brooks wrote: ...
Maybe there's something I'm missing here then:
The average temp that comes out of [unpack 1] is way higher than the rest of the readings. At the moment [unpack 1] says '212' yet a quick averaging of the other 16 readings is around '180'?
That's right. The first reading is of an internal reference, it's usually a few degrees warmer than the environment.
Martin
Quick edit for archives: sudo modprobe i2c)bcn2708 baudrate=90000 should be sudo modprobe i2c_bcm2708 baudrate=90000
I tried changing the baud rate with
sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=90000 but it works fine at the default 100000.