I2C Multi-Mastering the SX28...trying to understand...
Sens-a-Dat
Posts: 44
Gents,
I need to work on how to successfully multi-master SX28 chips for I2C. While I2C is not an absolute must for multi-mastering, I am trying to learn my way through various abilities of the SX28 so I can better gain understanding what works best and what does not for a particular task.
I have seen in various posts the recommendation to use the i2cmm_vp written by Scenix Semiconductor Inc. I have downloaded the file and have tested it. The file version is 1.06b with a revision date of June 26, 2000. I have not been successful in using this program as a lone master communicating with a EEPROM (24LC16B). I can easily communicate with that chip with a code written in SXB, so I know what the expected data should be within the EEPROM. But running the i2cmm_vp, the program basically goes into a wait-state for the i2c bus to become free. Yet, it should be free as there is nothing but the SX28 connected to the EEPROM.
I have noticed that the authors of the i2cmm_vp code had to move two routines to a different page (address at $500) as there was insufficient page memory with the state-routines. But this caused an error in execution and the routines were never executed due to the distance. So, I moved the routines to $400 and the jumps worked fine.
Has anyone really tested the i2cmm_vp and did it work fine for you? If it worked fine, did you have to modify things to get it to work properly? Or did it work fine for you right away?
I am running the device in DEBUG mode at 4 MHZ to test the program.
I also noticed there is an example and code in the 'Programming the SX Microcontroller, A complete Guide' wherein multiple masters can be on the I2C line. The code is listed as APP025.SRC. The overall design looks similar to what I want, but I cannot understand from the code which master will take precedence over another if two begin to talk at the same time to the control unit.
I appreciate any comments or suggestions you might have.
Thanks,
Gary
Post Edited (Sens-a-Dat) : 2/23/2008 10:47:00 AM GMT
I need to work on how to successfully multi-master SX28 chips for I2C. While I2C is not an absolute must for multi-mastering, I am trying to learn my way through various abilities of the SX28 so I can better gain understanding what works best and what does not for a particular task.
I have seen in various posts the recommendation to use the i2cmm_vp written by Scenix Semiconductor Inc. I have downloaded the file and have tested it. The file version is 1.06b with a revision date of June 26, 2000. I have not been successful in using this program as a lone master communicating with a EEPROM (24LC16B). I can easily communicate with that chip with a code written in SXB, so I know what the expected data should be within the EEPROM. But running the i2cmm_vp, the program basically goes into a wait-state for the i2c bus to become free. Yet, it should be free as there is nothing but the SX28 connected to the EEPROM.
I have noticed that the authors of the i2cmm_vp code had to move two routines to a different page (address at $500) as there was insufficient page memory with the state-routines. But this caused an error in execution and the routines were never executed due to the distance. So, I moved the routines to $400 and the jumps worked fine.
Has anyone really tested the i2cmm_vp and did it work fine for you? If it worked fine, did you have to modify things to get it to work properly? Or did it work fine for you right away?
I am running the device in DEBUG mode at 4 MHZ to test the program.
I also noticed there is an example and code in the 'Programming the SX Microcontroller, A complete Guide' wherein multiple masters can be on the I2C line. The code is listed as APP025.SRC. The overall design looks similar to what I want, but I cannot understand from the code which master will take precedence over another if two begin to talk at the same time to the control unit.
I appreciate any comments or suggestions you might have.
Thanks,
Gary
Post Edited (Sens-a-Dat) : 2/23/2008 10:47:00 AM GMT
Comments
For what it is worth, here's some observations.
Multi-mastering can be a bit tricky as different chips will and will not support it. So chips have less address choices available, and some require lengthy intialization. And even if the feature is supported, it is easier to stay with one manufacture's chips than to try to combine two. You might consider SPI, rather than I2C if it meets your needs.
So, it would be best to first investigate whose multi-master, multi-slave chips you want to use and verify they will work together. Generally, it seems to be a choice between German chip development and American. 1-wire is another selection issue as it is probably the most ambitions at trying to get multi-master, multi-slave onto less wire and with further transmission distances.
Another option is to use a CANbus interface [noparse][[/noparse]likethe MCP2515 and MCP2551 chip set] that allows long distances [noparse][[/noparse]1000 meters] of transmission and multi-master, multi-slave systems with bus arbitration. You can attach a BasicStamp, a Propeller, or an Sx to each node to handle local microprocessing while the CANbus manages all the communications. I2C is not intended from connections more than a few feet apart and really prefer being within the same chassis if not on the same board. 1-wire claims 100 feet or so is reasonable and has had some success with networks mutiple thermal sensors in grain elevations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
what do you mean with "different chips will not support multi-mastering"?
Usually, I2C chips, like EEPROMS, Clocks, Thermometers, ADCs, and DACs act as slave devices, so it is no problem to use them in a mult-master environment.
Gary,
As long as there is only one master is on the bus, things are simple and easy, as this one master controls the events on the bus, i.e. it generates the SCL clock signal, and controls the SDA line for the Start- and Stop conditions, sending out the device addresses for reading and writing, and finally to handle reading and writing from and to the slave devices.
When two or more masters are attached to the bus, each master can handle the same tasks a single master can do. The magic word here is "bus arbitration", and it is also important to know that the I2C lines, SCL and SDA both are pulled up to high via resistors, and all devices attached to the bus are only allowed to pull these lines low. No device is allowed to actively pull a line up to high level.
Let's assume, we have two masters on the bus, and both start communication at exactly the same time. Let's further assume that one master wants to read from a device with address 1010 000x, and the other master wants to write to the same device. So the first master will send the address with the R/W bit set, i.e. 1010 0001, and the second master will send 1010 0000. As both masters start at the same time (and we also assume with the same clock speed), they pull low and release the SCL and SDA lines for the start condition, and for the first seven address bits completely synchronized. When the eight bit is sent, the first master releases SDA as it wants this line to go high, where the second master pulls it low. In this case, the second master has "won arbitration".
So, how do the masters know that they are winners or loosers? This is pretty simple: Whenever a master releases a line for high (SCL or SDA) it reads that line after a short delay to verify if it has actually gone high. Should this read result in low, the master "knows" that some other master has pulled the line low, so the other master has won arbitration. It must stop any more communication immediately in this case. Normally, the loosing master then keeps monitoring the bus until it is idle (SDA, SCL both high, or for a stop condition (SDA going high while SCL is high), and then does a retry until its communication was successful.
Please note that the APP025.SRC example in my book is a bit specific as it describes units on an I2C but that can act as masters and slaves, like the pushbutton/LED unit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
At some point, one may want an SPI chip due to easier availablity or special features that Phillips doesn't have. At that point, one either has a Master with two buses or a Slave that converts the SPI to an I2C convention. This occurs mostly with sensor technologies - light, humidity, and temperature. Though Phillips RTC features are also different than other vendors.
The permutations start to increase and it generally means that one should carefully shop for an all I2C choice ore look at SXes for being a supporting role. Since the distances are short, I began to wonder why bother with a Multi-master scheme in either 1-wire, SPI, or I2C. CANbus seemed to be a more appropriate system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Post Edited (Kramer) : 2/25/2008 7:14:35 AM GMT
Bus arbitration is solely handled by the masters, transparent to the slaves.
In the example I gave in my last post, I made the assumption that two masters start communication at exactly the same time, and with exactly the same speed. In a real system, this is not typical. Usually, one master is already in the middle of a communication when another master wants to establish communication. Nevertheless, this does not change the concept. As long as each master checks if a bus line has really gone high after it has released the line, and ceases further communication immediately when this is not the case, arbitration will be handled corretly, and the slaves do not even recognize it.
When a specific I²C (slave) chip allows for more or less address selection bits, this simply limits the number of chips of this type that can be attached to the bus but this has nothing to do with multi-master environments. IMO, there also is no difference between German and other I²C technologies. To be fair, I need to say that Phillips is a Dutch company, and not a German one. For example, MAXIM - a US company - offers some I²C chips with a very tricky address selection concept, where selection pins may be low, high, or floating, i.e. they allow for three states per address pin which remarkably increases the number of possible addresses within one system.
The I2C specification describes the basic protocol that is valid for all types of I²C components, no matter how compley they are. There are chips around, like a simple thermometer, that can only be read, i.e. the master sends the device address for read, and the device returns one or two bytes representing the current temperature. Other devices may be much more complex with a number of internal registers that must be addressed or initialized before specific information can be read or written. Nevertheless, the basic protocol is always the same, and it is absolutely no problem to combine simple and complex I²C components on one bus as long as each device has its own, unique base device address. Typically, the device address consists of four leading bits that specify the device type plus three bits to select between 8 devices of the same type, and finally the lowest bit indicating the operation (0 = write, 1 = read).
With a powerful device, like the SX we have a nice part on hand that is always good to act as an I²C master (or multi-master) but it also allows us to create any kind of I²C slave.
I have successfully used the I²C protocol in many of my SX-based applications, not only for inter-chip communication on one board but also for communication with components located several meters away from the master. Although this is not covered by the I²C standard, it worked fine for me when I used an adequate speed, and the right cables.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
The "Bus Synchronization" chapter describes how masters in a multi-master environment must handle SCL. It is pretty similar to handling SDA: When a master has finished its low clock period, it relases SCL, and then waits until SCL actually goes high. This way, other (slower) masters can catch up. Even in a single-master environment, a master might handle the SCL like this, as it would allow slow slaves to do what is called "Clock Stretching", i.e. they hold low SCL until they are ready for the next data bit.
I agree with you regarding the AVRs - I had some trouble with their implementation of the two-wire interface in the past. This is why I like the SX so much because it is fully controlled by software. So you can have it handle standard, or non-standard I²C-alike protocols.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Examples given are mostly ADC sampling situations, but high speed ADCs are nearly exclusively equipped with some SPI variant...
Maybe I really have to try an AVR micro proprammed in slave mode
The datasheet only shows it occuring after the ACK bit, but it doesn't say it cannot happen elsewhere.
I ask because I want to enhance the I2C commands in SX/B to allow the slave to stretch the clock. For exactly the reason Gunther suggested. To make I2C slave devices with the SX.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com
·
the I²C specs read as follows:
On the byte level, a device may be able to receive bytes of
data at a fast rate, but needs more time to store a received
byte or prepare another byte to be transmitted. Slaves can
then hold the SCL line LOW after reception and
acknowledgment of a byte to force the master into a wait
state until the slave is ready for the next byte transfer in a
type of handshake procedure (see Fig.6).
On the bit level, a device such as a microcontroller with or
without limited hardware for the I2C-bus, can slow down
the bus clock by extending each clock LOW period. The
speed of any master is thereby adapted to the internal
operating rate of this device.
In Hs-mode, this handshake feature can only be used on
byte level (see Section 13).
So generic I²C code should allow for clock-stretching on bit level, and it is pretty easy to implement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
It should be a simple modification.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com
·