There were a few problems with I2C on the cRIO that caused people problems.
- The cRIO software expected an 8 bit address, whereas most people were used to a 7 bit address. The roboRIO now uses a 7 bit address.
- The cRIO's clock skewing behavior caused problems for some devices. It always supported a "compatibility" mode to solve those issues, and was enabled by default in 2014. This is no longer necessary on the roboRIO.
- If the device stopped communicating in the middle of a transaction, the cRIO software would be stuck in an infinite loop waiting for data. http://firstforge.wpi.edu/sf/go/artf1726 This is not present on the roboRIO.
Quote:
Originally Posted by Chadfrom308
Well I've always heard of hangs and program crashes because of bad i2c code., never CAN.
|
I think many people have complained about the CAN implementation on the cRIO.
Quote:
Originally Posted by RufflesRidge
Speculation and FUD seems unhelpful. Perhaps we should stick to actual data and not hearsay? Especially when it comes to a system that's still in Beta, in the hands of 90 teams, and which has no current bugs filed against the I2C software from a quick glance at the Beta tracker.
|
To be fair, only 3 of the 90 teams have reported testing I2C.