View previous topic :: View next topic |
Author |
Message |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
Multi-master I2C shared memory |
Posted: Wed Aug 17, 2005 11:34 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
MikeValencia
Joined: 04 Aug 2004 Posts: 238 Location: Chicago
|
|
Posted: Thu Aug 18, 2005 2:09 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Thu Aug 18, 2005 3:48 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Thu Aug 18, 2005 6:05 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Thu Aug 18, 2005 6:34 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Thu Aug 18, 2005 6:40 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Thu Aug 18, 2005 9:27 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|