CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
Who wants I2C master/slave code
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
picer



Joined: 25 Jan 2005
Posts: 28
Location: Taxahoma

View user's profile Send private message

PostPosted: Thu Mar 03, 2005 11:09 am     Reply with quote
I am very very interested in making I2C work, please review http://www.ccsinfo.com/forum/viewtopic.php?t=22031

I think I'm getting into the area that your talking about with error handling, etc but not sure how to deal with it. In my case I have a very limited time to service I2C and need to send a few bytes of data, master to slave. The only slave responce i'd ever care about is if the slave didn't recieve it's data. I2C has been very frustrating so I'm looking forward to seeing a working example of I2C but almost fear that to do it properly will take too much clock time away from what the pic is supposed to be doing which is PWM in my case.
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Thu Mar 03, 2005 11:50 am     Reply with quote
valemike wrote:
Mark wrote:
If the master does not get the ACK (a 0) then it should handle what needs to be done. Most of the examples that you are going to find are pretty basic. They hope for a perfect world. Sometimes they are kludged with delays. Take a look at how many people write to an eeprom. They just stick a huge delay in there for the write to complete. The proper way is to check for an ACK on the next write.


After skimming thru Microchip's App note AN735 just now, it says that a NACK indicates a hw/sw error, or simply an overrun. Even if it's an overrun, then what should the error handler do? Is it possible to simply re-try the write? From what i get out of the app note, it says to issue a restart, or stop/start.

I think my overruns are a result of the slave's interrupt latency handling of multiple frequent interrupts from other sources. It may just well be that a slave PIC needs to be given ample time to digest things. If there was a NACK, then everything has to be aborted, and the whole start/write_address/write_etc sequence has to be re-started anyways.

So such delays liberally sprinkled all over the place, which we both feel are kludges, are probably absolutely necessary. It seems the goal is NACK avoidance rather than NACK error handling. I can't see any other way to avoid a NACK than to inject delays.


There's a section on this in Microchip's I2C eeprom data sheets (for instance, the 24LC32A).

Their recommendation is to do ack polling. The flow is like this:

1. do initial write
2. stop
3. start
4. send control byte with r/w = 0
- if device ack'ed, do the next operation. If not, go back to step 3.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Thu Mar 03, 2005 12:56 pm     Reply with quote
My systems are designed to retransmit message on detection of an error up to 10 times. I do not use delays. I keep the ISR's short and sweet. I have an I2C / ACCESS.bus monitor made by Micro Computer Control. Using this device, I can monitor the I2C messages and can say that I have very little retries on sending of messages. The 4MHz devices show this and it is usually during configuration and data is being saved to the eeprom. The messages are usually received on the second retry though. BTW, some of the messages are 40 bytes.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Mar 04, 2005 3:59 pm     Reply with quote
Here is a link to the code. I stripped out a bunch of stuff and tried to rename things to make sense to you. Orginally this was based on the ACCESS.bus protocol. I put a test program in there to blink an LED on one of my boards and the code appears to work. Let me know if something doesn't. This is meant as a base for you to build upon. That means you will have to add your own command opcodes and the actions to take when you receive one. I included one command that blinked an led on my board.

http://www.ccsinfo.com/forum/viewtopic.php?p=40688#40688
dyeatman



Joined: 06 Sep 2003
Posts: 1927
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Mar 04, 2005 4:52 pm     Reply with quote
Looks great Mark.

Thank You!
valemike
Guest
PostPosted: Fri Mar 04, 2005 8:32 pm     Reply with quote
Thanks Mark. This will help me implement my i2c master. Up to now, i've been going with the CCS libraries for the master side, but i like your extensive error checking.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group