From: Mark Y. <mya...@gm...> - 2006-06-28 16:21:55
|
Hmm. Well thank you for the response. I actually got it working. What was happening was that I wasn't enabling the lines of communication for the TWI on the robostix (PortD bit 0 and PortD bit 1). So I was getting a NACK on the gumstix side because the line was being held at 1... i.e the device didn't exist. Anyways, im really excited, it works almost like i would expect. There is one thing that I don't understand... what happens is I write 3 bytes to the /dev/i2c-0 channel and then I get 1 byte ahead of my three bytes that isn't my own and 1 bytes at the end of my three bytes that is also not my own. I suppose this is a warning. I think it may be start and stop codes, but I imagined that would be handled w/o reporting it as an actual byte. Mark On 6/28/06, J.P. Norair <jn...@pr...> wrote: > > Your wording is confusing, but I will try to clarify. > > The first thing you have to understand is that the whole universe of I2C > is hinged on the fact that it uses a "Wired-AND" bus. The writer of the > spec makes sure to mention this every few sentences. What it means is that > the bus will have the value of '1' only if all of the devices on the bus are > sending a '1'. If ANY device(s) on the bus are sending a '0', the value on > the bus will be '0'. This is important, because it means that any devices > that aren't engaged just throw a '1' onto the bus, and hold it there. > > Technically, there is no such thing as a "NACK," and I don't think you'll > find that term anywhere in the I2C spec. For the record, USB has NACKs, I2C > does not. The I2C bus always communicates in a master-slave fashion. If > two masters are communicating with each other, one assumes the role of > slave. An ACK is just the 9th bit of a data byte, during which > (essentially) the master sends a one and the slave sends a zero. The net > result is that the output driver on the master reads '1' but the bus reads > '0' (i.e. a data mismatch). If anything other than this happens on the > 9th bit, there is something wrong. The ACK requires both master and slave, > and there's not really any way one device can "send a NACK (or ACK)" to > another. If the slave device is putting '1' on the bus during the 9th bit, > your driver may be recording it as a "NACK," but there are a lot of things > that can lead to this behavior. For example, if you're addressing the slave > incorrectly, it will continue to hold the line at '1' because it's not > engaged. To the master (and the driver) this will look just like a failed > ACK. > > A data mismatch can also occur outside the scope of a failed ACK, notably > during arbitration on a multi-master I2C bus. But I don't think this is > something you're dealing with. > > It's worth mentioning that during a slave-to-master transmission, the > master controls the clock and the addressing. In fact, in order for a slave > to transmit data to a master, the master has to specifically tell (address) > the slave. So if you're having trouble getting a slave-to-master data > transmission to work, there are a LOT of areas where there could be a > problem, and the first place I'd check is your clocking. Despite the fact > that I2C claims that fast (400kHz) and standard (100kHz) buses are > interoperable, in this case the I2C clock synchronization mechanism will end > up generating an asymmetric waveform for the clock, and your standard device > may be choking on the 1.25us (1/400kHz * 1/2 period) high pulse. > > Anyway, it's hard to diagnose the problem. It might be much lower-level > than your drivers. It may be as simple as having two I2C devices running > different voltages into the bus. Good luck. > > Cheers, > JP Norair > > ------------------------------ > *From:* gum...@li... [mailto: > gum...@li...] *On Behalf Of *Mark Yatskar > *Sent:* Saturday, June 24, 2006 19:54 > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] I2c communication questions > > > I don't think i was very precise with my NACK question. > > In the case that the master fails to recieve a signal, a NACK will be > returned in like 8 clock cycles (Im not sure about 8 but w.e). So the > question is: is the data transmission consistent, i.e will data packets > dissapear and I will get back NACKs when I just sent a byte of data or will > it be like I sent a byte and get an ACK (if the where I am sending is > expecting data) no matter what? > > > On 6/24/06, Dave Hylands <dhy...@gm...> wrote: > > > Hi Mark, > > > > > How consistent is the bus... i.e if I send something from the robostix > side, > > will I get a bunch of NACK s or will it be enough simply send one. > > Are you talking about the NACK's that occur after each byte? The i2c > protocol says that you're supposed to send a NACK when you don't want > to receive any more data. The linux driver does this automatically. > > If you're interested in this level of detail, I suggest that you read > the i2c specification and/or the SMBus specification. > > You can find out more about i2c over here: > http://www.i2c-bus.org/I2C_Bus.15.0.html?&no_cache=1 > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ <http://www.davehylands.com/> > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |