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

Multi-master I2C shared memory

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
andrewg



Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia

View user's profile Send private message Visit poster's website

Multi-master I2C shared memory
PostPosted: Wed Aug 17, 2005 11:34 pm     Reply with quote

I'm very new to PIC programming, made a couple of simple working systems for myself, now I'm doing something "for real".

I've never done any I2C work. The application I'm working on will require sharing a bank of I2C EEPROM devices amongst one or more PICs.

I've found the I2C communication routines Multi-Master topic over in the Code Library forum. It looks more like a set of routines to allow two masters to talk to each other, while my project will not have masters talking to each other, so all I'm really interested in is contention detection (I guess?).

Also, I see some recent changes in the v3.231 compiler that talks about improved multi-master support in the I2C_START() function. The available manual does not document anything. Does anyone know what's happened there? Would that be relevant to what I'm trying to do?

TIA.
_________________
Andrew
MikeValencia



Joined: 04 Aug 2004
Posts: 238
Location: Chicago

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

PostPosted: Thu Aug 18, 2005 2:09 am     Reply with quote

When you say that you won't be having two masters talking to each other, but instead are worried about contention, then does that mean that you actually have ONE master and several slaves?

If so, then you don't have to treat it any differently than you do with one simple master and one slave pair. Remember, the slaves won't speak unless spoken to. Thus as long as your Master does the usual i2c_start() to start a session and ends it with an i2c_stop(), then you shouldn't worry about contention from different slaves.

The other nodes won't speak unless spoken to if they are slaves. They will, however, speak spontaneously if they can also become a master (thus multi-master).

*** The key is to make sure that all the slaves have different addresses.
andrewg



Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia

View user's profile Send private message Visit poster's website

PostPosted: Thu Aug 18, 2005 3:48 am     Reply with quote

I'll be having two or more PICs acting as masters talking to the same shared EEPROM slaves. The PICs are only communicating with the EEPROMs, not each other.

Naturally, I'm concerned about what happens if the two PICs start using the bus at the same time.
_________________
Andrew
Mark



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

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

PostPosted: Thu Aug 18, 2005 6:05 am     Reply with quote

andrewg wrote:
I'll be having two or more PICs acting as masters talking to the same shared EEPROM slaves. The PICs are only communicating with the EEPROMs, not each other.

Naturally, I'm concerned about what happens if the two PICs start using the bus at the same time.


You are correct. The code that I posted handles contention. Basically if you transmit a 1 and the data line is 0 then you lose and must relinquish the bus. From the code that is posted in the library, you really only need to concern yourself with the transmit portion.
andrewg



Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia

View user's profile Send private message Visit poster's website

PostPosted: Thu Aug 18, 2005 6:34 am     Reply with quote

That all sounds good. I'm feeling more confident I'll be able to get things to work.

I've also been considering a shared "bus in use" signal, and another signal that pokes each master PIC in turn to say "you can use the bus if it's not in use". It would prevent contention from occurring in the first place, but it was sounding a little ugly.

I think the contention detection is sounding like a much better idea.

Thanks!
_________________
Andrew
Mark



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

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

PostPosted: Thu Aug 18, 2005 6:40 am     Reply with quote

There is a bit in the status register that show whether a stop or start was received last. If you check this before trying to write, then that will make it even better. If I detect a start bit last, then I monitor the lines for a little bit to see if anyone is talking, if not, then I take control of the bus. Note these bits are invalid on reset.
andrewg



Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia

View user's profile Send private message Visit poster's website

PostPosted: Thu Aug 18, 2005 9:27 pm     Reply with quote

Thanks, I wasn't aware of that bit. All this I2C stuff is very new to me!

Now that I'm on the right track, it's time to fiddle for a while...

Actually, the first thing I have to do is a prototype using one PIC and its internal EEPROM, the I2C bus is the step after that.

Thanks again.
_________________
Andrew
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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