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 <jbee...@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 <jbee...@gmail.com> wrote: > >> hmmm - both files: >> ./hello-2 >> Segmentation fault >> >> Try again... >> >> >> >> On 19 April 2013 21:51, Julian Brooks <jbee...@gmail.com> wrote: >> >>> Ok -found I had to remove 'libi2c-dev'. >>> >>> Then builds. >>> >>> More soon... >>> >>> >>> On 19 April 2013 21:28, Julian Brooks <jbee...@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 <jbee...@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.pe...@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 <jbee...@gmail.com >>>>>>> <mailto:jbee...@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 <jbee...@gmail.com >>>>>>> <mailto:jbee...@gmail.com>> wrote: >>>>>>> >>>>>>> Message resent for thread archives with smaller picture size. >>>>>>> >>>>>>> Julian >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: *Julian Brooks* <jbee...@gmail.com <mailto: >>>>>>> jbee...@gmail.com>> >>>>>>> Date: 11 April 2013 19:24 >>>>>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd >>>>>>> To: Martin Peach <martin.pe...@sympatico.ca >>>>>>> <mailto:martin.peach@**sympatico.ca<martin.pe...@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<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 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