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