Quote:
Originally Posted by Steve_Alaniz
WHOA! Excellent Dave! Ok One thing I didn't mention was that we were using Labview and our issues with the devices was almost certainly the implementation of the I2C bus within Labview or a timing issue with reading the sensors within the FIRST program.
|
I'm surprised you're having trouble... I tested talking to 3 different sensors on the same bus at the same time, using the LabVIEW examples. Are you sure you could address your second sensor at all?
Perhaps you had a wiring problem. Also, the Digital Sidecar has all the needed pull-up resistors. The devices should not have pull resistors in them.
Quote:
Originally Posted by Steve_Alaniz
The second unit addressed just didn't respond, as if it were not even connected. We didn't have much time to play around with it so we didn't explored changing which we addressed first. We decided to wait until we could consult an NI guy and, well you know that story.
|
You just didn't consult the correct NI guy. The statement that we didn't expect I2C to be used this year is completely false.
Quote:
Originally Posted by Steve_Alaniz
I looked at their vi... as much as I was allowed, and saw that they had it fixed such that you had to send data when you addressed a register. We had to send a false data byte even though we only needed to address a register and then read. We correctly guessed the compass would ignore the extra data so it worked anyway.
|
Perhaps you are misinterpreting the interface. The current API to I2C on the FPGA allows you write to one register or read from between 1 and 4 sequential registers. In either case, the device will be addressed, then the register will be addressed, and finally the data will be moved. Only when you're using a device that does not have a register-level I2C API does this scheme not work nicely. You should not use a register write when you are trying to do a register read.
The intention is that it will be more flexible in the future so that other custom API types can be easily supported as well.