View Single Post
  #1   Spotlight this post!  
Unread 24-03-2012, 21:06
kamocat's Avatar
kamocat kamocat is offline
Test Engineer
AKA: Marshal Horn
FRC #3213 (Thunder Tech)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 2008
Location: Tacoma
Posts: 894
kamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nice
Send a message via AIM to kamocat Send a message via MSN to kamocat
I2C implementation on the cRIO

Hi all,

If you're not familiar with the I2C standard, wikipedia has a good explanation here: http://en.wikipedia.org/wiki/I%C2%B2C


If you feel comfortable with the protocol, please read on.

I'm trying to get an ATtiny26 microprocessor to talk to the cRIO using I2C, the cRIO being the master. (I'm not sure if it's possible for the cRIO to be a slave, but we can get into that later.)

What I'd like to do is have the cRIO read a single byte from the ATtiny, and hold the clock low until it determines how many bytes it wants to read.

Once it determines that, it should either release the bus, or read more bytes.



I'm curious how I2C is implemented on the cRIO, so that I can make sure this works. From looking at the LabVIEW code, it appears it writes 8 bytes, then reads 8 bytes, and then throws away everything except the number of bytes you asked for.

Now, I2C is a low-speed bus. I'll probably be running it at 100khz - maybe a little faster if my ATtiny supports it. Using my understanding of how it is implemented on the cRIO, it would take over 150 clock pulses to just get one or two bytes. Reading one byte should only take 18 clock pulses from start to stop.


Anyways, I'll be doing some tests soon, but I was curios if someone with a better understanding of the WPI library and FPGA image could share some knowledge so I know what to expect.
__________________
-- Marshal Horn
Reply With Quote