actually hold up a sec on that last warning.... I may have found something else.
 
Mark

 
On 6/28/06, Mark Yatskar <myatskar@gmail.com> wrote:
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 <jnorair@proximities.com > 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: gumstix-users-bounces@lists.sourceforge.net [mailto:gumstix-users-bounces@lists.sourceforge.net] 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 <dhylands@gmail.com > 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/

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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users