From: VaibhavGhadiok <vai...@gm...> - 2010-12-16 08:08:39
|
I tried to interface the Wii IR Camera (from Pixart) to the gumstix. The problem I am facing is that I am able to write to the registers but not read from them. As detailed on numerous sites there is a configuration sequence that I follow to setup the camera. http://letsmakerobots.com/node/7752 http://www.instructables.com/id/Wii-Remote-IR-Camera-Hack/ i2c 0x58 wb 0x30 0x01 (This works) i2c 0x58 rb 0x30 (Reading the configuration register gives back 0x40) Reading any register gives back 0x40. It takes a long time to return the 0x40 value and messes up the i2c line. I have to do a #modprobe -r i2c-pxa #modprobe -r i2c-dev #modprobe i2c-pxa #modprobe i2c-dev If I don't do this and try to read or write again I get: ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: I2cWriteBytes failed: -1 I o-scoped the signals. When the gumstix writes I see that the slave acknowledges and the master (gumstix) sends it the register address and then the value to be written to it. While reading, the gumstix sends it the address appended with the read bit but there is no acknowledge. The camera works at 400Khz (Fast Mode) i2c as discovered by probing the signals on the Wii Controller. I am also able to get the camera to work if I use my supporting circuitry (clock and a pullup for camera enable) with the SCL and SDA routed to the Wii Controller (with a common ground between the wii controller and my circuit) that sends the readings from the camera over bluetooth to my computer. I also tried connecting the camera directly to the 3.3 V lines on the gumstix (with appropriate pull-ups) so that I don't need to do the 5V to 3.3 V conversion. Although I do have other slave devices on the bus and they all work fine with the Voltage Converter. Thanks Vaibhav -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30470724p30470724.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-15 19:30:07
|
Hi Dave, Sorry for posting this as a new message. The mailing list was refusing to accept my message for some reason. I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C converter from sparkfun and the camera worked fine. The code for the Arduino is actually much simpler than what I posted which was for a different processor setup, the code I used is below. I took pictures of the SDA lines on an oscilloscope (best I had at the moment) for both reads and writes using the Arduino and the Gumstix. Device address - 0x58. The read command is for register 0x37, with value meant to be 0xFF 0xFF 0xFF (3 registers read at once). Write command is for address 0x30, value of 0x01 to write. It looks like there's some clock skewing going on for both processors, so it's hard to really tell how many same bits there are in a row, but I can't seem to find anything suspect with the Gumstix read except that it doesn't get an ack. http://dl.dropbox.com/u/16369427/Arduino%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20DSC01143.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20Success%20-%20DSC01149.JPG >From the attached photos, it looks like the Arduino and the Gumstix have identical write patterns: 0x58, 0 for write, 0 for ack ---- 0x30 for register, 0 for ack ------- 0x01 for write value, 0 for ack http://dl.dropbox.com/u/16369427/Arduino%20Read%20of%20Wii%20-%200x58%200x30%200xFF%200xFF%200xFF%20-%20DSC01144.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Wii%200x58%200x37%20-%20Fail%20-%20DSC01150.JPG The photos show that the reads are obviously not the same: Arduino: [0x58, (no read bit or ack?)] --- [0x37 for register, 0 for ack] ----- [??? Not sure what this is here] then [0x58 address again?, 1 for read, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack] Gumstix: [0x58, (no read bit or ack? or is it read back and no ack?)] --- [0x37 for register, 0 for ack] ----- then [0x58 address again?, 1 for read, 1 for no ack] I'm definitely not clear on what is going on with the reads - it seems like there is an ack in the middle with the gumstix, but then not after that. Do you have an insight into what is happening? It seems the gumstix can work over i2c with the camera but there is something going wrong during the read. Thanks, Vaibhav Arduino code used: // Wii Remote IR sensor test sample code by kako #include <Wire.h> int IRsensorAddress = 0xB0; int slaveAddress; int ledPin = 13; boolean ledState = false; byte data_buf[3]; int i; int Ix1,Iy1,Ix2,Iy2; int Ix3,Iy3,Ix4,Iy4; int s; void Write_2bytes(byte d1, byte d2) { Wire.beginTransmission(slaveAddress); Wire.send(d1); Wire.send(d2); Wire.endTransmission(); } void setup() { slaveAddress = IRsensorAddress >> 1; // This results in 0x21 as the address to pass to TWI Serial.begin(9600); pinMode(ledPin, OUTPUT); // Set the LED pin as output Wire.begin(); // IR sensor initialize Write_2bytes(0x30,0x01); delay(10); Write_2bytes(0x30,0x08); delay(10); Write_2bytes(0x06,0x90); delay(10); Write_2bytes(0x08,0xC0); delay(10); Write_2bytes(0x1A,0x40); delay(10); Write_2bytes(0x33,0x33); delay(10); delay(100); } void loop() { ledState = !ledState; if (ledState) { digitalWrite(ledPin,HIGH); } else { digitalWrite(ledPin,LOW); } //IR sensor read Wire.beginTransmission(slaveAddress); Wire.send(0x37); Wire.endTransmission(); Wire.requestFrom(slaveAddress, 3); // Request the 2 byte heading (MSB comes first) for (i=0;i<3;i++) { data_buf[i]=0; } i=0; while(Wire.available() && i < 3) { data_buf[i] = Wire.receive(); i++; } Ix1 = data_buf[0]; Iy1 = data_buf[1]; s = data_buf[2]; Ix1 += (s & 0x30) <<4; Iy1 += (s & 0xC0) <<2; Serial.print(" Ix1: "); Serial.print( int(Ix1) ); Serial.print(" , Iy1: "); Serial.print( int(Iy1) ); Serial.println(""); delay(100); } -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30676129.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Jason C. M. <jas...@am...> - 2011-01-17 17:40:22
|
a couple of questions. 1.) What are you using on the Gumstix to communicate to the Sensor? Personally I've used i2cget and i2cset and they seem to work fine. So if you're not using them I would suggest trying them. 2.) Have you tried adjusting the i2c speed within the kernel? 3.) Why are you posting only one channel? It's hard to see what's going on without posting both the scl and sda lines. 4.) What chip are using to translate the 1.8V to 3.3V? You might have said in a previous post, but I didn't catch it. 5.) Have you tried using a 600pF capacitor to ground on both the Clock line and the data line? I'm also having issues with I2C communication except in my case the omap->Sensor (an image sensor) is working fine, but the Channel Link 3 Device I'm using fails miserably in getting an Ack back from the Sensor. Noise issues are causing havoc. I'm trying to sort out the source of the noise, but in the mean time a 600pF cap on both lines have corrected the problem. On Jan 15, 2011, at 11:30 AM, VaibhavGhadiok wrote: > > Hi Dave, > > Sorry for posting this as a new message. The mailing list was refusing to > accept my message for some reason. > > I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C converter > from sparkfun and the camera worked fine. The code for the Arduino is > actually much simpler than what I posted which was for a different processor > setup, the code I used is below. I took pictures of the SDA lines on an > oscilloscope (best I had at the moment) for both reads and writes using the > Arduino and the Gumstix. > > Device address - 0x58. > The read command is for register 0x37, with value meant to be 0xFF 0xFF 0xFF > (3 registers read at once). > Write command is for address 0x30, value of 0x01 to write. > > It looks like there's some clock skewing going on for both processors, so > it's hard to really tell how many same bits there are in a row, but I can't > seem to find anything suspect with the Gumstix read except that it doesn't > get an ack. > > http://dl.dropbox.com/u/16369427/Arduino%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20DSC01143.JPG > > http://dl.dropbox.com/u/16369427/Gumstix%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20Success%20-%20DSC01149.JPG > >> From the attached photos, it looks like the Arduino and the Gumstix have > identical write patterns: > 0x58, 0 for write, 0 for ack ---- 0x30 for register, 0 for ack ------- 0x01 > for write value, 0 for ack > > http://dl.dropbox.com/u/16369427/Arduino%20Read%20of%20Wii%20-%200x58%200x30%200xFF%200xFF%200xFF%20-%20DSC01144.JPG > > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Wii%200x58%200x37%20-%20Fail%20-%20DSC01150.JPG > > The photos show that the reads are obviously not the same: > Arduino: > [0x58, (no read bit or ack?)] --- [0x37 for register, 0 for ack] ----- [??? > Not sure what this is here] > then [0x58 address again?, 1 for read, 0 for ack], [0xFF, 0 for ack], [0xFF, > 0 for ack], [0xFF, 0 for ack] > > Gumstix: > [0x58, (no read bit or ack? or is it read back and no ack?)] --- [0x37 for > register, 0 for ack] ----- then [0x58 address again?, 1 for read, 1 for no > ack] > > I'm definitely not clear on what is going on with the reads - it seems like > there is an ack in the middle with the gumstix, but then not after that. Do > you have an insight into what is happening? It seems the gumstix can work > over i2c with the camera but there is something going wrong during the read. > > Thanks, > > Vaibhav > > Arduino code used: > // Wii Remote IR sensor test sample code by kako > > #include <Wire.h> > > int IRsensorAddress = 0xB0; > int slaveAddress; > int ledPin = 13; > boolean ledState = false; > byte data_buf[3]; > int i; > > int Ix1,Iy1,Ix2,Iy2; > int Ix3,Iy3,Ix4,Iy4; > int s; > > void Write_2bytes(byte d1, byte d2) > { > Wire.beginTransmission(slaveAddress); > Wire.send(d1); Wire.send(d2); > Wire.endTransmission(); > } > > void setup() > { > slaveAddress = IRsensorAddress >> 1; // This results in 0x21 as the > address to pass to TWI > Serial.begin(9600); > pinMode(ledPin, OUTPUT); // Set the LED pin as output > Wire.begin(); > // IR sensor initialize > Write_2bytes(0x30,0x01); delay(10); > Write_2bytes(0x30,0x08); delay(10); > Write_2bytes(0x06,0x90); delay(10); > Write_2bytes(0x08,0xC0); delay(10); > Write_2bytes(0x1A,0x40); delay(10); > Write_2bytes(0x33,0x33); delay(10); > delay(100); > } > void loop() > { > ledState = !ledState; > if (ledState) { digitalWrite(ledPin,HIGH); } else { > digitalWrite(ledPin,LOW); } > > //IR sensor read > Wire.beginTransmission(slaveAddress); > Wire.send(0x37); > Wire.endTransmission(); > > Wire.requestFrom(slaveAddress, 3); // Request the 2 byte heading > (MSB comes first) > for (i=0;i<3;i++) { data_buf[i]=0; } > i=0; > while(Wire.available() && i < 3) { > data_buf[i] = Wire.receive(); > i++; > } > > Ix1 = data_buf[0]; > Iy1 = data_buf[1]; > s = data_buf[2]; > Ix1 += (s & 0x30) <<4; > Iy1 += (s & 0xC0) <<2; > > Serial.print(" Ix1: "); Serial.print( int(Ix1) ); > Serial.print(" , Iy1: "); Serial.print( int(Iy1) ); > Serial.println(""); > delay(100); > } > > -- > View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30676129.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-20 01:31:58
|
Hi Dave, I've attached the reads and writes with both the SCL and SDA lines for better understanding. From the pictures below, the Arduino is able to both write and read, while the Gumstix is only able to write. It does look like the Camera is sending back ACKs. The Gumstix write and the Arduino write are exactly the same. The Gumstix read fails for some reason compared to the Arduino. They both start out the same with: the address of the device, a write command, an Ack, the register to read from, an ACK, then the address of the device again *** Here they differ, the Arduino gives a read command and gets an ACK and then the read bytes follow. But with the Gumstix it sends a write command for the second device address and then at that point it just fails. Is this failure because the protocol is expecting a read at this point not a write and there's no bytes being sent to write so it just messes up the whole line? I took pictures of reading using the gumstix from a different sensor, and it behaves just like the Arduino does when reading from the camera. Image in two parts: http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%201%20-%200x69%200x1C%200x83.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%202%20-%200x69%200x1C%200x83.JPG The read from the gyro sensor is: address 0x69, Write bit, Ack, 0x1C, Ack, address 0x69, Read bit, Ack, 0x83, Stop bit. For the camera, it's the same (with different byte values) up until the second address sending, for some reason when I work with the camera, the gumstix sends another write bit instead of a read. Both reads (camera and gyro sensor) are done from the command line with i2c 0x-- rb 0x--, so the code is exactly the same. Why might the camera reading not send correctly? The write works just fine and it gets ACKs as necessary, but the i2c just doesn't execute the read command correctly with the camera, by not sending an actual read bit after the addressing the second time. Hi Jason, 1.) I'm using a Verdex and couldn't find i2cget/i2cset packages. 2.) Yes, I've tried both 100Khz and 400KHz. 3.) Sorry, only had access to one lead - new pictures below have both lines. Write: Arduino: http://dl.dropbox.com/u/16369427/Arduino%20Write%20-%200x58%200x30%200x01.JPG Gumstix: http://dl.dropbox.com/u/16369427/Gumstix%20Write%20-%200x58%200x30%200x01.JPG As shown here, both the Arduino and the Gumstix behave exactly the same, with an ACK after each byte Read: Arduino: Full view (wide) first, then 3 parts closer view. http://dl.dropbox.com/u/16369427/Arduino%20Read%200x58%200x36%200x00%200xFF%200xFF%200xFF%20-%20full%20view.JPG http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%201%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%202%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%203%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG Gumstix: Full view (wide) first, then 2 parts closer view. http://dl.dropbox.com/u/16369427/Gumstix%20Read%20-%200x37.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%201%20-%200x37.JPG 4) The Verdex is a 3.3V Gumstix, but I have to take I2C lines from the robostix, which is 5V, so I use Sparkfun's logic converter to step down from 5 to 3.3v. It works fine with 2 other i2c sensors I have. http://www.sparkfun.com/products/8745 5) Haven't tried a capacitor, but with all the devices plus adding a capacitor on the line I'm worried I might get close to the capacitance limit for the i2c lines. Jason C. Mecham wrote: > > a couple of questions. > > 1.) What are you using on the Gumstix to communicate to the Sensor? > Personally I've used i2cget and i2cset and they seem to work fine. So if > you're not using them I would suggest trying them. > > 2.) Have you tried adjusting the i2c speed within the kernel? > > 3.) Why are you posting only one channel? It's hard to see what's going on > without posting both the scl and sda lines. > > 4.) What chip are using to translate the 1.8V to 3.3V? You might have said > in a previous post, but I didn't catch it. > > 5.) Have you tried using a 600pF capacitor to ground on both the Clock > line and the data line? I'm also having issues with I2C communication > except in my case the omap->Sensor (an image sensor) is working fine, but > the Channel Link 3 Device I'm using fails miserably in getting an Ack back > from the Sensor. Noise issues are causing havoc. I'm trying to sort out > the source of the noise, but in the mean time a 600pF cap on both lines > have corrected the problem. > > > > > > On Jan 15, 2011, at 11:30 AM, VaibhavGhadiok wrote: > >> >> Hi Dave, >> >> Sorry for posting this as a new message. The mailing list was refusing to >> accept my message for some reason. >> >> I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C converter >> from sparkfun and the camera worked fine. The code for the Arduino is >> actually much simpler than what I posted which was for a different >> processor >> setup, the code I used is below. I took pictures of the SDA lines on an >> oscilloscope (best I had at the moment) for both reads and writes using >> the >> Arduino and the Gumstix. >> >> Device address - 0x58. >> The read command is for register 0x37, with value meant to be 0xFF 0xFF >> 0xFF >> (3 registers read at once). >> Write command is for address 0x30, value of 0x01 to write. >> >> It looks like there's some clock skewing going on for both processors, so >> it's hard to really tell how many same bits there are in a row, but I >> can't >> seem to find anything suspect with the Gumstix read except that it >> doesn't >> get an ack. >> >> http://dl.dropbox.com/u/16369427/Arduino%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20DSC01143.JPG >> >> http://dl.dropbox.com/u/16369427/Gumstix%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20Success%20-%20DSC01149.JPG >> >>> From the attached photos, it looks like the Arduino and the Gumstix have >> identical write patterns: >> 0x58, 0 for write, 0 for ack ---- 0x30 for register, 0 for ack ------- >> 0x01 >> for write value, 0 for ack >> >> http://dl.dropbox.com/u/16369427/Arduino%20Read%20of%20Wii%20-%200x58%200x30%200xFF%200xFF%200xFF%20-%20DSC01144.JPG >> >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Wii%200x58%200x37%20-%20Fail%20-%20DSC01150.JPG >> >> The photos show that the reads are obviously not the same: >> Arduino: >> [0x58, (no read bit or ack?)] --- [0x37 for register, 0 for ack] ----- >> [??? >> Not sure what this is here] >> then [0x58 address again?, 1 for read, 0 for ack], [0xFF, 0 for ack], >> [0xFF, >> 0 for ack], [0xFF, 0 for ack] >> >> Gumstix: >> [0x58, (no read bit or ack? or is it read back and no ack?)] --- [0x37 >> for >> register, 0 for ack] ----- then [0x58 address again?, 1 for read, 1 for >> no >> ack] >> >> I'm definitely not clear on what is going on with the reads - it seems >> like >> there is an ack in the middle with the gumstix, but then not after that. >> Do >> you have an insight into what is happening? It seems the gumstix can work >> over i2c with the camera but there is something going wrong during the >> read. >> >> Thanks, >> >> Vaibhav >> >> Arduino code used: >> // Wii Remote IR sensor test sample code by kako >> >> #include <Wire.h> >> >> int IRsensorAddress = 0xB0; >> int slaveAddress; >> int ledPin = 13; >> boolean ledState = false; >> byte data_buf[3]; >> int i; >> >> int Ix1,Iy1,Ix2,Iy2; >> int Ix3,Iy3,Ix4,Iy4; >> int s; >> >> void Write_2bytes(byte d1, byte d2) >> { >> Wire.beginTransmission(slaveAddress); >> Wire.send(d1); Wire.send(d2); >> Wire.endTransmission(); >> } >> >> void setup() >> { >> slaveAddress = IRsensorAddress >> 1; // This results in 0x21 as the >> address to pass to TWI >> Serial.begin(9600); >> pinMode(ledPin, OUTPUT); // Set the LED pin as output >> Wire.begin(); >> // IR sensor initialize >> Write_2bytes(0x30,0x01); delay(10); >> Write_2bytes(0x30,0x08); delay(10); >> Write_2bytes(0x06,0x90); delay(10); >> Write_2bytes(0x08,0xC0); delay(10); >> Write_2bytes(0x1A,0x40); delay(10); >> Write_2bytes(0x33,0x33); delay(10); >> delay(100); >> } >> void loop() >> { >> ledState = !ledState; >> if (ledState) { digitalWrite(ledPin,HIGH); } else { >> digitalWrite(ledPin,LOW); } >> >> //IR sensor read >> Wire.beginTransmission(slaveAddress); >> Wire.send(0x37); >> Wire.endTransmission(); >> >> Wire.requestFrom(slaveAddress, 3); // Request the 2 byte >> heading >> (MSB comes first) >> for (i=0;i<3;i++) { data_buf[i]=0; } >> i=0; >> while(Wire.available() && i < 3) { >> data_buf[i] = Wire.receive(); >> i++; >> } >> >> Ix1 = data_buf[0]; >> Iy1 = data_buf[1]; >> s = data_buf[2]; >> Ix1 += (s & 0x30) <<4; >> Iy1 += (s & 0xC0) <<2; >> >> Serial.print(" Ix1: "); Serial.print( int(Ix1) ); >> Serial.print(" , Iy1: "); Serial.print( int(Iy1) ); >> Serial.println(""); >> delay(100); >> } >> >> -- >> View this message in context: >> http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30676129.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30715568.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-01-20 04:17:01
|
Hi Vaibhav, On Wed, Jan 19, 2011 at 5:31 PM, VaibhavGhadiok <vai...@gm...> wrote: > > Hi Dave, > > I've attached the reads and writes with both the SCL and SDA lines for > better understanding. From the pictures below, the Arduino is able to both > write and read, while the Gumstix is only able to write. It does look like > the Camera is sending back ACKs. > > The Gumstix write and the Arduino write are exactly the same. The Gumstix > read fails for some reason compared to the Arduino. > > They both start out the same with: > the address of the device, a write command, an Ack, > the register to read from, an ACK, > then the address of the device again *** > Here they differ, the Arduino gives a read command and gets an ACK and then > the read bytes follow. > > But with the Gumstix it sends a write command for the second device address > and then at that point it just fails. So the correct sequence for the read of a register should be (see page 30 of http://smbus.org/specs/smbus20.pdf titled "Read Byte Protocol) Send a START (SDA falls while SCL is high) Send the slave address, with the R/W bit clear (write) Receive an ACK Send the register to read from Receive an ACK Send a repeated START (SDA falls while SCL is high) Send the slave address, with the R/W bit set (read) Receive an ACK Receive the data to be read Send an ACK Send a STOP (SDA rises while SCL is high) > Is this failure because the protocol is expecting a read at this point not a > write and there's no bytes being sent to write so it just messes up the > whole line? > > I took pictures of reading using the gumstix from a different sensor, and it > behaves just like the Arduino does when reading from the camera. > Image in two parts: > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%201%20-%200x69%200x1C%200x83.JPG > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%202%20-%200x69%200x1C%200x83.JPG > The read from the gyro sensor is: address 0x69, Write bit, Ack, 0x1C, Ack, > address 0x69, Read bit, Ack, 0x83, Stop bit. > > For the camera, it's the same (with different byte values) up until the > second address sending, for some reason when I work with the camera, the > gumstix sends another write bit instead of a read. The gumstix should only be sending a write if its told to. > Both reads (camera and gyro sensor) are done from the command line with i2c > 0x-- rb 0x--, so the code is exactly the same. > > Why might the camera reading not send correctly? The write works just fine > and it gets ACKs as necessary, but the i2c just doesn't execute the read > command correctly with the camera, by not sending an actual read bit after > the addressing the second time. > > > Hi Jason, > > 1.) I'm using a Verdex and couldn't find i2cget/i2cset packages. > > 2.) Yes, I've tried both 100Khz and 400KHz. > > 3.) Sorry, only had access to one lead - new pictures below have both lines. > Write: > Arduino: > http://dl.dropbox.com/u/16369427/Arduino%20Write%20-%200x58%200x30%200x01.JPG > Gumstix: > http://dl.dropbox.com/u/16369427/Gumstix%20Write%20-%200x58%200x30%200x01.JPG > As shown here, both the Arduino and the Gumstix behave exactly the same, > with an ACK after each byte > > Read: > Arduino: > Full view (wide) first, then 3 parts closer view. > http://dl.dropbox.com/u/16369427/Arduino%20Read%200x58%200x36%200x00%200xFF%200xFF%200xFF%20-%20full%20view.JPG > http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%201%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG > http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%202%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG > http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%203%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG > > Gumstix: > Full view (wide) first, then 2 parts closer view. > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20-%200x37.JPG > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%201%20-%200x37.JPG So, you'll notice that when the gumstix drive the line low, the voltage is slightly high than when the camera drives the line low (which is actually good we can tell who is actually driving the line). When you look at the scope trace (Part 2) it looks like the camera is sending the ACK bit one bit early. This essentially means that the ack bit (low) sent from the camera is obliterating the Read bit (one) being sent from the gumstix. The gumstix then waits for the ACK and doesn't get it (SDA is back high again). I see the same thing happen with the Arduino trace as well, but it just ignores it and keeps going. > 4) The Verdex is a 3.3V Gumstix, but I have to take I2C lines from the > robostix, which is 5V, so I use Sparkfun's logic converter to step down from > 5 to 3.3v. It works fine with 2 other i2c sensors I have. > http://www.sparkfun.com/products/8745 That could be a problem. I know that the data sheet for the voltage converter on the robostix explicitly states that using two of them in a row doesn't work. I don't know about using the robostix voltage converter followed by the sparkfun converter. If you could tap into the 3.3v signals that would be better. > 5) Haven't tried a capacitor, but with all the devices plus adding a > capacitor on the line I'm worried I might get close to the capacitance limit > for the i2c lines. Dave Hylands |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-20 05:51:18
|
Hi Dave, I see what you mean about the voltage difference between the two devices and the camera wiping out the read bit from the gumstix, but what I don't understand is why the read part of the gumstix sending only has 8 clocks, when it should have 9. If it did think it sent a 1 for a read during that clock high, it should generate another clock to look at the SDA line for the ACK before quitting or having issues. Why are there only 8 clock highs in that last sending? i.e. only 8 opportunities to read bits on the SDA. http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG >From looking at the Arduino plots, it looks to me like there is a high value shown for the read sending and then there's the ACK from the camera, so I don't see the part where it ignores the ACK issue that the gumstix has problems with. http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%202%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG I tried tapping into the Gumstix 3.3V lines earlier, but there were no differences (it had the added benefit of also being the only device on the i2c line in case that was an issue, but it still wasn't able to read - writing worked). Thanks, Vaibhav Dave Hylands wrote: > > Hi Vaibhav, > > On Wed, Jan 19, 2011 at 5:31 PM, VaibhavGhadiok > <vai...@gm...> wrote: >> >> Hi Dave, >> >> I've attached the reads and writes with both the SCL and SDA lines for >> better understanding. From the pictures below, the Arduino is able to >> both >> write and read, while the Gumstix is only able to write. It does look >> like >> the Camera is sending back ACKs. >> >> The Gumstix write and the Arduino write are exactly the same. The Gumstix >> read fails for some reason compared to the Arduino. >> >> They both start out the same with: >> the address of the device, a write command, an Ack, >> the register to read from, an ACK, >> then the address of the device again *** >> Here they differ, the Arduino gives a read command and gets an ACK and >> then >> the read bytes follow. >> >> But with the Gumstix it sends a write command for the second device >> address >> and then at that point it just fails. > > So the correct sequence for the read of a register should be (see page > 30 of http://smbus.org/specs/smbus20.pdf titled "Read Byte Protocol) > > Send a START (SDA falls while SCL is high) > Send the slave address, with the R/W bit clear (write) > Receive an ACK > Send the register to read from > Receive an ACK > Send a repeated START (SDA falls while SCL is high) > Send the slave address, with the R/W bit set (read) > Receive an ACK > Receive the data to be read > Send an ACK > Send a STOP (SDA rises while SCL is high) > >> Is this failure because the protocol is expecting a read at this point >> not a >> write and there's no bytes being sent to write so it just messes up the >> whole line? >> >> I took pictures of reading using the gumstix from a different sensor, and >> it >> behaves just like the Arduino does when reading from the camera. >> Image in two parts: >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%201%20-%200x69%200x1C%200x83.JPG >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Gyro%20Part%202%20-%200x69%200x1C%200x83.JPG >> The read from the gyro sensor is: address 0x69, Write bit, Ack, 0x1C, >> Ack, >> address 0x69, Read bit, Ack, 0x83, Stop bit. >> >> For the camera, it's the same (with different byte values) up until the >> second address sending, for some reason when I work with the camera, the >> gumstix sends another write bit instead of a read. > > The gumstix should only be sending a write if its told to. > >> Both reads (camera and gyro sensor) are done from the command line with >> i2c >> 0x-- rb 0x--, so the code is exactly the same. >> >> Why might the camera reading not send correctly? The write works just >> fine >> and it gets ACKs as necessary, but the i2c just doesn't execute the read >> command correctly with the camera, by not sending an actual read bit >> after >> the addressing the second time. >> >> >> Hi Jason, >> >> 1.) I'm using a Verdex and couldn't find i2cget/i2cset packages. >> >> 2.) Yes, I've tried both 100Khz and 400KHz. >> >> 3.) Sorry, only had access to one lead - new pictures below have both >> lines. >> Write: >> Arduino: >> http://dl.dropbox.com/u/16369427/Arduino%20Write%20-%200x58%200x30%200x01.JPG >> Gumstix: >> http://dl.dropbox.com/u/16369427/Gumstix%20Write%20-%200x58%200x30%200x01.JPG >> As shown here, both the Arduino and the Gumstix behave exactly the same, >> with an ACK after each byte >> >> Read: >> Arduino: >> Full view (wide) first, then 3 parts closer view. >> http://dl.dropbox.com/u/16369427/Arduino%20Read%200x58%200x36%200x00%200xFF%200xFF%200xFF%20-%20full%20view.JPG >> http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%201%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG >> http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%202%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG >> http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%203%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG >> >> Gumstix: >> Full view (wide) first, then 2 parts closer view. >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20-%200x37.JPG >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%201%20-%200x37.JPG > > So, you'll notice that when the gumstix drive the line low, the > voltage is slightly high than when the camera drives the line low > (which is actually good we can tell who is actually driving the line). > > When you look at the scope trace (Part 2) it looks like the camera is > sending the ACK bit one bit early. This essentially means that the ack > bit (low) sent from the camera is obliterating the Read bit (one) > being sent from the gumstix. > > The gumstix then waits for the ACK and doesn't get it (SDA is back high > again). > > I see the same thing happen with the Arduino trace as well, but it > just ignores it and keeps going. > >> 4) The Verdex is a 3.3V Gumstix, but I have to take I2C lines from the >> robostix, which is 5V, so I use Sparkfun's logic converter to step down >> from >> 5 to 3.3v. It works fine with 2 other i2c sensors I have. >> http://www.sparkfun.com/products/8745 > > That could be a problem. I know that the data sheet for the voltage > converter on the robostix explicitly states that using two of them in > a row doesn't work. I don't know about using the robostix voltage > converter followed by the sparkfun converter. > > If you could tap into the 3.3v signals that would be better. > >> 5) Haven't tried a capacitor, but with all the devices plus adding a >> capacitor on the line I'm worried I might get close to the capacitance >> limit >> for the i2c lines. > > Dave Hylands > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30716476.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-01-20 07:14:30
|
Hi Vaibhav, On Wed, Jan 19, 2011 at 9:51 PM, VaibhavGhadiok <vai...@gm...> wrote: > > Hi Dave, > > I see what you mean about the voltage difference between the two devices and > the camera wiping out the read bit from the gumstix, but what I don't > understand is why the read part of the gumstix sending only has 8 clocks, > when it should have 9. If it did think it sent a 1 for a read during that > clock high, it should generate another clock to look at the SDA line for the > ACK before quitting or having issues. > > Why are there only 8 clock highs in that last sending? i.e. only 8 > opportunities to read bits on the SDA. > http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG The level of the clock doesn't matter, it's the rising edge that counts. The data line isn't allowed to change while the clock is high, so the value at the rising edge is typically what's used. For multiple master arbitration, the gumstix knew it wrote a 1 but read a zero, so it stopped assuming that the other master was driving the bus. If you detect a difference (which can only happen when you write a 1 and detect a zero), then you're supposed to back off and wait for the other master to finish (when you detect the STOP condition). Since there was no other master, this effectively hangs the bus. (see page 21 of smbus20.pdf titled "Arbitration"). > >From looking at the Arduino plots, it looks to me like there is a high value > shown for the read sending and then there's the ACK from the camera, so I > don't see the part where it ignores the ACK issue that the gumstix has > problems with. I'm not seeing it now either - so I don't know what I was looking at. I did notice that in the gumstix trace, it seems to be running at 400 kHz. I thought I read somewhere that it had to be at 100 kHz for the WiiCamera. Dave Hylands |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-21 04:57:57
|
Hi Dave, It's Working!!!! Thank you very much for your help, it allowed me to figure out the problem. The only difference I could see between the Arduino traces and the Gumstix, were at the read part, after the write of the register (from which to read from). This is where the Gumstix does a repeated start. But if you look at the Arduino trace at this point, it actually sends a stop bit first, and then a start bit again before sending the address with the read command. Repeated Start of Gumstix before sending second 0x58 address: http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG Arduino sends stop then sends start before second 0x58 address: http://dl.dropbox.com/u/16369427/Arduino%20Read%20pt%201%20-%200x58%200x36%200x00%200xFF%200xFF%200xFF.JPG So instead of using the repeated start of the rdwr code (1 big message, so makes a repeated start between the write and read), I send the two bytes to write (0x58 0x36) as one message (so there's a stop bit) then I send the read command (0x58 with read) so there's a start again. Gumstix Successful Read with Stop and Start between write and read: http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Success%20pt%201%20-%200x58%200x36%200x58%200x00%200xFF%200xFF%200xFF.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Success%20pt%202%20-%200x58%200x36%200x58%200x00%200xFF%200xFF%200xFF.JPG There is an 80usec delay between the two ioctl messages as opposed to almost nothing with the repeated start and about 12usec with the Arduino, but at least it works. Not sure why the camera, which works with i2c, won't recognize a repeated start. Do you have an idea why? The code is below: int I2cReadRegisterCamera ( int i2cDev, ///< Handle to i2c-dev file uint16_t DeviceAddress, //0x58 char wrData, //Register Address uint8_t *rdData, uint8_t rdLen // How much data to expect back ) { struct i2c_msg msgs[1]; struct i2c_rdwr_ioctl_data rdwr; msgs[0].addr = DeviceAddress; msgs[0].flags = 0; msgs[0].buf = &wrData; msgs[0].len = 1; rdwr.msgs = msgs; rdwr.nmsgs = 1; ioctl( i2cDev, I2C_RDWR, &rdwr ); msgs[0].addr = DeviceAddress; msgs[0].flags = I2C_M_RD; msgs[0].buf = (char *)rdData; msgs[0].len = rdLen; rdwr.msgs = msgs; rdwr.nmsgs = 1; if(ioctl( i2cDev, I2C_RDWR, &rdwr ) < 0) {printf("Howl error\n");} return 0; } //I2cReadRegisterCamera I had scoped the camera when it was attached to the Wii Controller Board and it was working at 400 Khz. Thanks very much again, Vaibhav Dave Hylands wrote: > > Hi Vaibhav, > > On Wed, Jan 19, 2011 at 9:51 PM, VaibhavGhadiok > <vai...@gm...> wrote: >> >> Why are there only 8 clock highs in that last sending? i.e. only 8 >> opportunities to read bits on the SDA. >> http://dl.dropbox.com/u/16369427/Gumstix%20Read%20Part%202%20-%200x37.JPG > > The level of the clock doesn't matter, it's the rising edge that > counts. The data line isn't allowed to change while the clock is high, > so the value at the rising edge is typically what's used. For multiple > master arbitration, the gumstix knew it wrote a 1 but read a zero, so > it stopped assuming that the other master was driving the bus. If you > detect a difference (which can only happen when you write a 1 and > detect a zero), then you're supposed to back off and wait for the > other master to finish (when you detect the STOP condition). > > Since there was no other master, this effectively hangs the bus. (see > page 21 of smbus20.pdf titled "Arbitration"). > > Dave Hylands > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30676129p30725816.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-10 23:16:56
|
Hi Dave, I'm hoping you can help with my issue detailed below - I've still not been able to think of what is wrong and would really appreciate your perspective. Thanks. VaibhavGhadiok wrote: > > I tried to interface the Wii IR Camera (from Pixart) to the gumstix. > > The problem I am facing is that I am able to write to the registers but > not read from them. As detailed on numerous sites there is a configuration > sequence that I follow to setup the camera. > > http://letsmakerobots.com/node/7752 > http://www.instructables.com/id/Wii-Remote-IR-Camera-Hack/ > > i2c 0x58 wb 0x30 0x01 (This works) > i2c 0x58 rb 0x30 (Reading the configuration register gives back 0x40) > Reading any register gives back 0x40. > > It takes a long time to return the 0x40 value and messes up the i2c line. > I have to do a > #modprobe -r i2c-pxa > #modprobe -r i2c-dev > #modprobe i2c-pxa > #modprobe i2c-dev > > If I don't do this and try to read or write again I get: > ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) > ERROR: I2cWriteBytes failed: -1 > > I o-scoped the signals. When the gumstix writes I see that the slave > acknowledges and the master (gumstix) sends it the register address and > then the value to be written to it. While reading, the gumstix sends it > the address appended with the read bit but there is no acknowledge. > > The camera works at 400Khz (Fast Mode) i2c as discovered by probing the > signals on the Wii Controller. I am also able to get the camera to work if > I use my supporting circuitry (clock and a pullup for camera enable) with > the SCL and SDA routed to the Wii Controller (with a common ground between > the wii controller and my circuit) that sends the readings from the camera > over bluetooth to my computer. > > I also tried connecting the camera directly to the 3.3 V lines on the > gumstix (with appropriate pull-ups) so that I don't need to do the 5V to > 3.3 V conversion. Although I do have other slave devices on the bus and > they all work fine with the Voltage Converter. > > Thanks > Vaibhav > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30470724p30637069.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-01-11 07:45:00
|
Hi Vaibhav, On Mon, Jan 10, 2011 at 3:16 PM, VaibhavGhadiok <vai...@gm...> wrote: > > Hi Dave, > > I'm hoping you can help with my issue detailed below - I've still not been > able to think of what is wrong and would really appreciate your perspective. So it seems that many cameras use SCCB protocol which has some subtle differences from i2c. For example: <http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6092/22821.aspx> If this is in fact the case, then you'll probably need to use a bit-banged interface rather than relying on the i2c pins provided on the gumstix. Dave Hylands |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-12 01:10:39
|
hi Dave Thanks for your quick response. I checked multiple sources and I can confirm that the pixart camera does use I2C (SMBUS). SCCB was mainly used for camera that actually return an image. The pixart camera is a little special since it only returns the position and size of infrared blobs. I have pasted some code from an adruino implementation that works. Is there any difference between the gumstix implementation and that on a microcontroller. I noticed some people doing this: Anything that I could try. write(hex): B0 37 //prepare for reading wait 25 us write(hex): B1 //read request read 8 bytes wait 380us write(hex): B1 //read request read 4 bytes #include <compat/twi.h> #define I2C_WRITE_MODE 0 #define I2C_READ_MODE 1 #define I2C_READ_WITH_NACK 0 #define I2C_READ_WITH_ACK 1 #define SET_TWCR(x) {TWCR=(x)|_BV(TWINT)|_BV(TWEN);}while(0) #define TWI_START SET_TWCR(_BV(TWSTA)) #define TWI_ACK SET_TWCR(_BV(TWEA)) #define TWI_NACK SET_TWCR(0) #define TWI_NEXT SET_TWCR(0) #define TWI_STOP SET_TWCR(_BV(TWSTO)) #define TWI_END SET_TWCR(0) #define WAIT_TWINT loop_until_bit_is_set(TWCR,TWINT) #define F_SCL (100000L) /*100kHz*/ #define TWBR_VALUE ((F_CPU/F_SCL-16)/2) #define TWI_RATE_20K 0x00 #define TWI_RATE_50K 0x01 #define TWI_RATE_100K 0x02 #define TWI_RATE_400K 0x03 #define TWI_RATE_700K 0x04 #include "i2c_master.h" void i2c_master_init(void) { // twi_init(TWI_RATE_20K); // I2C clock == 20kHz twi_init(TWI_RATE_400K); // I2C clock == 400kHz } int i2c_start(int address, int rw) { int ret; ret = sla_set( address + rw ); // rw==1 ... Read / rw==0 ... Write if (ret==0x18) { return 0; } // ACK (Write) if (ret==0x40) { return 0; } // ACK (Read) return 1; // 1 ... Error: no ACK or some other error } void i2c_write(int data) { TWI_write(data); } int i2c_read(int ack_mode) { return TWI_read(ack_mode); // ack_mode==1 ... read with ACK / ack_mode==0 ... with NACK } void i2c_stop() { TWI_STOP; } /********************* TWI Rate Table *********************/ const char twi_tbl[] = {2,30 ,1,48, 0,92,0,17,0,6 }; //20khz,50khz,100khz,400khz,650khz void twi_init(unsigned char twi_rate) { TWCR = 0; // TWI Disable TWSR = twi_tbl[twi_rate * 2]; // TWI prescaler TWBR = twi_tbl[twi_rate * 2+1]; // TWBR setting TWCR = _BV(TWEN); // TWI Enable } uint8_t TWI_wait(void) { int8_t r; int retry_cu = 0; while (1) { // wait TWCR:TWINT bit --> High if ((TWCR & 0x80) == 0x80) { break; } retry_cu++; if (retry_cu > 500) { break; } // to much retry count } r = TW_STATUS; return r; } char sla_set(uint8_t sla_rw) { char r; TWI_START; r = TWI_wait(); if ((r != TW_REP_START)&&(r != TW_START)) { return r; } r = TWI_write(sla_rw); if (r == TW_MT_ARB_LOST) { return r; } if (r == TW_MT_SLA_ACK) { return r; } // if OK,return TW_MT_SLA_ACK. if (r == TW_MR_SLA_ACK) { return r; } TWI_STOP; return r; } uint8_t TWI_write(uint8_t x) { TWDR = x; TWI_NEXT; return TWI_wait(); } uint8_t TWI_read(char ack) { uint8_t r; if (ack) { TWI_ACK; } else { TWI_NACK; } TWI_wait(); r = TWDR; return r; } //EXAMPLE OF A READ CALL TO THESE FUNCTIONS r=i2c_start(I2C_ADR,I2C_WRITE_MODE); i2c_write( 0x36 ); i2c_stop(); if (r!=0) { rs_puts("Error: no ACK\n"); } r=i2c_start(I2C_ADR,I2C_READ_MODE); for (i=0;i<16;i++) { data_buf[i]=0; } for (i=0;i<16;i++) { if (i!=15) { data_buf[i] = i2c_read(I2C_READ_WITH_ACK); } else { data_buf[i] = i2c_read(I2C_READ_WITH_NACK); } } i2c_stop(); Dave Hylands wrote: > > Hi Vaibhav, > > On Mon, Jan 10, 2011 at 3:16 PM, VaibhavGhadiok > <vai...@gm...> wrote: >> >> Hi Dave, >> >> I'm hoping you can help with my issue detailed below - I've still not >> been >> able to think of what is wrong and would really appreciate your >> perspective. > > So it seems that many cameras use SCCB protocol which has some subtle > differences from i2c. > > For example: > <http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6092/22821.aspx> > > If this is in fact the case, then you'll probably need to use a > bit-banged interface rather than relying on the i2c pins provided on > the gumstix. > > Dave Hylands > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how > to > best implement a security strategy that keeps consumers' information > secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30470724p30649540.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-01-12 07:18:47
|
Hi Vaibhav, On Tue, Jan 11, 2011 at 5:10 PM, VaibhavGhadiok <vai...@gm...> wrote: > > hi Dave > > Thanks for your quick response. I checked multiple sources and I can confirm > that the pixart camera does use I2C (SMBUS). SCCB was mainly used for camera > that actually return an image. The pixart camera is a little special since > it only returns the position and size of infrared blobs. I have pasted some > code from an adruino implementation that works. > Is there any difference between the gumstix implementation and that on a > microcontroller. I noticed some people doing this: Anything that I could > try. Probably the best thing to do is to hook up an AVR and look at the signals on a logic analyzer, and then look at the signals when using the gumstix and see where the differences are. Dave Hylands |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-15 18:59:03
|
Hi Dave, I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C converter from sparkfun and the camera worked fine. The code for the Arduino is actually much simpler than what I posted which was for a different processor setup, the code I used is below. I took pictures of the SDA lines on an oscilloscope (best I had at the moment) for both reads and writes using the Arduino and the Gumstix. Device address - 0x58. The read command is for register 0x37, with value meant to be 0xFF 0xFF 0xFF (3 registers read at once). Write command is for address 0x30, value of 0x01 to write. It looks like there's some clock skewing going on for both processors, so it's hard to really tell how many same bits there are in a row, but I can't seem to find anything suspect with the Gumstix read except that it doesn't get an ack. http://dl.dropbox.com/u/16369427/Arduino%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20DSC01143.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20Success%20-%20DSC01149.JPG >From the attached photos, it looks like the Arduino and the Gumstix have identical write patterns: 0x58, 0 for write, 0 for ack ---- 0x30 for register, 0 for ack ------- 0x01 for write value, 0 for ack http://dl.dropbox.com/u/16369427/Arduino%20Read%20of%20Wii%20-%200x58%200x30%200xFF%200xFF%200xFF%20-%20DSC01144.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Wii%200x58%200x37%20-%20Fail%20-%20DSC01150.JPG The photos show that the reads are obviously not the same: Arduino: [0x58, (no read bit or ack?)] --- [0x37 for register, 0 for ack] ----- [??? Not sure what this is here] then [0x58 address again?, 1 for read, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack] Gumstix: [0x58, (no read bit or ack? or is it read back and no ack?)] --- [0x37 for register, 0 for ack] ----- then [0x58 address again?, 1 for read, 1 for no ack] I'm definitely not clear on what is going on with the reads - it seems like there is an ack in the middle with the gumstix, but then not after that. Do you have an insight into what is happening? It seems the gumstix can work over i2c with the camera but there is something going wrong during the read. Thanks, Vaibhav Dave Hylands wrote: > > Hi Vaibhav, > > On Tue, Jan 11, 2011 at 5:10 PM, VaibhavGhadiok > <vai...@gm...> wrote: >> >> hi Dave >> >> Thanks for your quick response. I checked multiple sources and I can >> confirm >> that the pixart camera does use I2C (SMBUS). SCCB was mainly used for >> camera >> that actually return an image. The pixart camera is a little special >> since >> it only returns the position and size of infrared blobs. I have pasted >> some >> code from an adruino implementation that works. >> Is there any difference between the gumstix implementation and that on a >> microcontroller. I noticed some people doing this: Anything that I could >> try. > > Probably the best thing to do is to hook up an AVR and look at the > signals on a logic analyzer, and then look at the signals when using > the gumstix and see where the differences are. > > Dave Hylands > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30470724p30676127.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: VaibhavGhadiok <vai...@gm...> - 2011-01-15 04:04:00
|
Hi Dave, I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C converter from sparkfun and the camera worked fine. The code for the Arduino is actually much simpler than what I posted which was for a different processor setup, the code I used is below. I took pictures of the SDA lines on an oscilloscope (best I had at the moment) for both reads and writes using the Arduino and the Gumstix. Device address - 0x58. The read command is for register 0x37, with value meant to be 0xFF 0xFF 0xFF (3 registers read at once). Write command is for address 0x30, value of 0x01 to write. It looks like there's some clock skewing going on for both processors, so it's hard to really tell how many same bits there are in a row, but I can't seem to find anything suspect with the Gumstix read except that it doesn't get an ack. http://dl.dropbox.com/u/16369427/Arduino%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20DSC01143.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Write%20of%20Wii%20-%200x58%200x30%200x01%20-%20Success%20-%20DSC01149.JPG >From the attached photos, it looks like the Arduino and the Gumstix have identical write patterns: 0x58, 0 for write, 0 for ack ---- 0x30 for register, 0 for ack ------- 0x01 for write value, 0 for ack http://dl.dropbox.com/u/16369427/Arduino%20Read%20of%20Wii%20-%200x58%200x30%200xFF%200xFF%200xFF%20-%20DSC01144.JPG http://dl.dropbox.com/u/16369427/Gumstix%20Read%20of%20Wii%200x58%200x37%20-%20Fail%20-%20DSC01150.JPG The photos show that the reads are obviously not the same: Arduino: [0x58, (no read bit or ack?)] --- [0x37 for register, 0 for ack] ----- [??? Not sure what this is here] then [0x58 address again?, 1 for read, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack], [0xFF, 0 for ack] Gumstix: [0x58, (no read bit or ack? or is it read back and no ack?)] --- [0x37 for register, 0 for ack] ----- then [0x58 address again?, 1 for read, 1 for no ack] I'm definitely not clear on what is going on with the reads - it seems like there is an ack in the middle with the gumstix, but then not after that. Do you have an insight into what is happening? It seems the gumstix can work over i2c with the camera but there is something going wrong during the read. Thanks, Vaibhav Adruino code used: // Wii Remote IR sensor test sample code by kako #include int IRsensorAddress = 0xB0; int slaveAddress; int ledPin = 13; boolean ledState = false; byte data_buf[3]; int i; int Ix1,Iy1,Ix2,Iy2; int Ix3,Iy3,Ix4,Iy4; int s; void Write_2bytes(byte d1, byte d2) { Wire.beginTransmission(slaveAddress); Wire.send(d1); Wire.send(d2); Wire.endTransmission(); } void setup() { slaveAddress = IRsensorAddress >> 1; // This results in 0x21 as the address to pass to TWI Serial.begin(9600); pinMode(ledPin, OUTPUT); // Set the LED pin as output Wire.begin(); // IR sensor initialize Write_2bytes(0x30,0x01); delay(10); Write_2bytes(0x30,0x08); delay(10); Write_2bytes(0x06,0x90); delay(10); Write_2bytes(0x08,0xC0); delay(10); Write_2bytes(0x1A,0x40); delay(10); Write_2bytes(0x33,0x33); delay(10); delay(100); } void loop() { ledState = !ledState; if (ledState) { digitalWrite(ledPin,HIGH); } else { digitalWrite(ledPin,LOW); } //IR sensor read Wire.beginTransmission(slaveAddress); Wire.send(0x37); Wire.endTransmission(); Wire.requestFrom(slaveAddress, 3); // Request the 2 byte heading (MSB comes first) for (i=0;i<3;i++) { data_buf[i]=0; } i=0; while(Wire.available() && i < 3) { data_buf[i] = Wire.receive(); i++; } Ix1 = data_buf[0]; Iy1 = data_buf[1]; s = data_buf[2]; Ix1 += (s & 0x30) <<4; Iy1 += (s & 0xC0) <<2; Serial.print(" Ix1: "); Serial.print( int(Ix1) ); Serial.print(" , Iy1: "); Serial.print( int(Iy1) ); Serial.println(""); delay(100); } Dave Hylands wrote: > > Hi Vaibhav, > > On Tue, Jan 11, 2011 at 5:10 PM, VaibhavGhadiok > wrote: >> >> hi Dave >> >> Thanks for your quick response. I checked multiple sources and I can >> confirm >> that the pixart camera does use I2C (SMBUS). SCCB was mainly used for >> camera >> that actually return an image. The pixart camera is a little special >> since >> it only returns the position and size of infrared blobs. I have pasted >> some >> code from an adruino implementation that works. >> Is there any difference between the gumstix implementation and that on a >> microcontroller. I noticed some people doing this: Anything that I could >> try. > > Probably the best thing to do is to hook up an AVR and look at the > signals on a logic analyzer, and then look at the signals when using > the gumstix and see where the differences are. > > Dave Hylands > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/I2C-read-fails%2C-but-write-works-tp30470724p30676111.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-01-15 07:17:50
|
Hi Vaibhav, On Fri, Jan 14, 2011 at 8:03 PM, VaibhavGhadiok <vai...@gm...> wrote: > Hi Dave, I used an Arduino Diecimila w/ Atmega168, with the 5V->3.3V I2C > converter from sparkfun and the camera worked fine. The code for the Arduino > is actually much simpler than what I posted which was for a different > processor setup, the code I used is below. I took pictures of the SDA lines > on an oscilloscope (best I had at the moment) for both reads and writes > using the Arduino and the Gumstix. Device address - 0x58. The read command > is for register 0x37, with value meant to be 0xFF 0xFF 0xFF (3 registers > read at once). Write command is for address 0x30, value of 0x01 to write. It > looks like there's some clock skewing going on for both processors, so it's > hard to really tell how many same bits there are in a row, but I can't seem > to find anything suspect with the Gumstix read except that it doesn't get an > ack. Without the clock, it's hard to tell exactly where the bit transitions are. The bit widths don't have to be contant with i2c. Either side is allowed to stretch the clock. Given that the camera is not sending back ACKs suggests that the camera is in fact using SCCB rather than I2C. SCCB specifically treats the ACK bit as a don't care bit. The missing ACK is what's messing up the gumstix. You'd need to bit bang some GPIOs instead of using th i2c HW to read the registers from the camera. Dave Hylands |