OCCRA
Go to Post The engineer mentors ARE part of the team, equals with the students in every aspect - KenWittlief [more]
Home
Go Back   Chief Delphi > Technical > Control System > FRC Control System
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 03-24-2012, 08:06 PM
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 Send a message via Skype™ 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
  #2   Spotlight this post!  
Unread 03-31-2012, 04:13 AM
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 Send a message via Skype™ to kamocat
Re: I2C implementation on the cRIO

Well, folks, I'm getting funny results.
I'm still not sure if the cRIO writes 8 bytes and reads 8 bytes every time. I suspect that it only writes and reads as much as it needs to.

The I2C driver I wrote for the tiny26 works when I test it by hand. (I use pushbuttons to generate the signal, and LEDs to display the signal. There's some stuff in there for debouncing as well.) However, when I hook it up to the cRIO, it works intermittently. Sometimes the cRIO even reads a bit or two offset from what the microcontroller is sending. Sometimes it gives me gibberish (aka does something else I don't yet understand). Most of the time it fails and returns an error.

Unfortunately, until I have access to a newer oscope and more than one set of leads, I can't really look at the signal. Unless I monitor the signal using two GPIO on the digital sidecar. I haven't looked into that yet, but if the digital module is fast enough to output this, then it should be fast enough to input it as well.

My best guess of what is happening is that the cRIO is running the I2C clock a bit too fast for the tiny26, and so most of the time it doesn't work.

Any other guesses?
Does anyone have info on how fast the bus is (as implemented here), and what options like "I2C register" and "compatibility mode" actually do?
I think "compatibility mode" means it deals with ACK and NACK. I have no clue why you WOULDN'T want these features - they are your error checking.
The I2C register input - and I'm only guessing here - might be a message that is sent immediately prior to the read request. I don't know it's actually two messages, or some hybrid form of read and write that isn't in the I2C spec. Maybe this is something from SMBus?
__________________
-- Marshal Horn
Reply With Quote
  #3   Spotlight this post!  
Unread 03-31-2012, 11:08 AM
EricVanWyk EricVanWyk is offline
Registered User
no team
 
Join Date: Jan 2007
Rookie Year: 2000
Location: Boston
Posts: 1,596
EricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond repute
Send a message via AIM to EricVanWyk
Re: I2C implementation on the cRIO

Joe Hershberger can give you better details that I can, but I'll take a whack at it until he finds this thread.

The short of it is that the I2C implementation is limited by the speed of the digital IO and the bi-directional nature of the protocol.

A 100% compliant implementation requires the master to check whether the slave is holding the bus low on every single bit. Checking for clock stretching like this takes a few extra IO cycles, and is usually unnecessary. For speed, it is by default omitted. Compatibility mode checks for stretching in more places.

What I'm not clear on is where stretching is checked in which mode.
Reply With Quote
  #4   Spotlight this post!  
Unread 04-06-2012, 01:13 AM
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 Send a message via Skype™ to kamocat
Re: I2C implementation on the cRIO

Well that could certainly cause some issues.
I haven't checked yet what the response time is of my program.
I thought that it was implemented in the FPGA, so it could use a transparent latch on a shift register, so the processor can deal with things four bytes at a time.
__________________
-- Marshal Horn
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:29 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi