i2c communication speed and a Basic Stamp
AlexMunro
Posts: 7
I am working on a robot project that will use a 3 axis accelerometer and a 3 axis compass (LSM303DLM).
the program loop will have to read 6 I2C registers. in order to respond to the readings in real time the loop will have to read the registers, perform calculations, and produce some out put within about 10 milliseconds or 100 times every second.
I am attaching the test code for the I2C communication that is reading only 4 registers and not doing any computations. I am also attaching a screen shot of the PropScope logic analyzer The communication in this test seems to require about 80ms.
Shiftin and Shiftout transmit at 42KBits/s. The accelerometer and compass (LSM303DLM) communicate at 400Khz (about 8 times faster than Shiftin).
by rough estimate 4 registers requires about 288 bits of I2C data. To be conservative and allow for overhead I would allow for 600bits which should require about 14 Ms.
As you can see my calculations don't even come close to the graphed result of 80 Ms and will never be able to achieve <10ms for 8 registers.
My Question is, should the Basic Stamp be able to handle the 8 register I2C communication in less than 10ms (which means my code needs to be corrected) or do I need to go back and redesign based on a different processor (which means my estimates are way out to lunch)?
the program loop will have to read 6 I2C registers. in order to respond to the readings in real time the loop will have to read the registers, perform calculations, and produce some out put within about 10 milliseconds or 100 times every second.
I am attaching the test code for the I2C communication that is reading only 4 registers and not doing any computations. I am also attaching a screen shot of the PropScope logic analyzer The communication in this test seems to require about 80ms.
Shiftin and Shiftout transmit at 42KBits/s. The accelerometer and compass (LSM303DLM) communicate at 400Khz (about 8 times faster than Shiftin).
by rough estimate 4 registers requires about 288 bits of I2C data. To be conservative and allow for overhead I would allow for 600bits which should require about 14 Ms.
As you can see my calculations don't even come close to the graphed result of 80 Ms and will never be able to achieve <10ms for 8 registers.
My Question is, should the Basic Stamp be able to handle the 8 register I2C communication in less than 10ms (which means my code needs to be corrected) or do I need to go back and redesign based on a different processor (which means my estimates are way out to lunch)?
1024 x 576 - 58K
Comments
Which Basic Stamp are you using? (BS2, BS2pe, etc.)
The BS2 does not have built-in I2C statements and has to handle the I2C protocol using some subroutines. That's a lot of code to execute. BS2 statements take on the order of hundreds of microseconds to execute and this adds up very quickly to several times the 10ms cycle. There are some tables of execution times for various statements here. Click on the App Notes link on the bottom of the page. Note that other Stamp models are not necessarily speed demons with I2C even with the built-in statements, but they are much faster than the BS2 for this.
Consider using a Propeller. It's much faster and can do I2C at full speed (400KHz) easily using existing library code (Propeller Object Exchange - OBEX).
The best chance of doing this would be with one of the multislot Stamps, the BS2P or BS2PX. They have built-in fast i2c commands (I2CIN and I2COUT) and operate in turbo mode.
Here is a screen shot from the Saleae logic analyzer of how the BS2pe handles a native i2c exchange.
The i2c clock runs at 50kHz, and the transfers occur at around 200 microseconds per byte. The BS2p runs 2.5 times faster. A lot would have to do with how much overhead there needs to be in your program. Reading out the 8 bytes in one i2c transaction is task one, calculations and resulting actions will take a lot more time. The Stamp is great for some things, but I agree with Mike on this about how the Propeller would have a lot more power for real time kinematics.
After reading up on the prop it does look like the right hardware, more power, more speed, more everything.
I'll pick up a dev board and start learning Spin!.