hmmm - both files: ./hello-2 Segmentation fault Try again...
On 19 April 2013 21:51, Julian Brooks <[email protected]> wrote: > Ok -found I had to remove 'libi2c-dev'. > > Then builds. > > More soon... > > > On 19 April 2013 21:28, Julian Brooks <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Message resent for thread archives with smaller picture size. >>>>> >>>>> Julian >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: *Julian Brooks* <[email protected] <mailto: >>>>> [email protected]>> >>>>> Date: 11 April 2013 19:24 >>>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd >>>>> To: Martin Peach <[email protected] >>>>> <mailto:martin.peach@**sympatico.ca<[email protected]> >>>>> >> >>>>> Cc: PD List <[email protected] <mailto:[email protected]>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/** >>>>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> >>>>> >>>>> >>>> >>> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
