8XC751/752 83C751/87C751 80C51 83C752 87C752 S8XC751/752 83C751 8XC751 AN422 - Datasheet Archive

 

Application note Using the 8XC751/752 in multimaster I2C applications function ICs in the I2C family the on-board interface

 

Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications function ICs in the I2C family the on-board interface facilitates I/O and RAM expansion, access to EEPROM, and processor-to-processor communications. INTRODUCTION The Philips Semiconductors 83C751/87C751 83C751/87C751 offers the advantages of the 80C51 80C51 architecture in a small package and at a low cost. It combines the benefits of a high performance microcontroller with on-board hardware supporting the Inter Integrated Circuit (I2C) bus interface. The 83C752 83C752 and its EPROM version, 87C752 87C752, are essentially the 83C751/87C751 83C751/87C751 with the addition of a five channel multiplexed 8-bit A/D converter and an 8-bit PWM output. As the I2C bus interface is identical, the programming example and the discussion relates to both processors. The multimaster capability of the I2C bus allows easy integration and expansion of relatively complex systems, in which different devices can independently initiate data transfers. Integration of a multimaster system is easy as a Master on the bus does not have to coordinate its data transfer with other potential Master devices-arbitration and synchronization are taken care of by the hardware and bus protocols. Expanding a system with a new device is trivial-it is "clipped" onto the two serial bus lines, and the new device may act as a Master without any modification to the other devices (see Figure 1). Microcontrollers like the S8XC751/752 S8XC751/752 on the I2C bus are extremely powerful, as they can be programmed to be both Masters and Slaves in the same system. This way the microcontroller may initiate communication on the bus, and when requested, will respond to a data transfer request by another device. The Inter IC (I2C) bus developed by Philips allows integrated circuits to communicate directly with each other via a simple bidirectional 2-wire bus. The comprehensive family of CMOS and bipolar ICs incorporating the on-chip I2C interface offers many advantages to designers of digital control for industrial, consumer and telecommunications equipment. Interfacing the devices in an I2C based system is very simple as they connect directly to the two bus lines: a serial data line (SDA) and a serial clock line (SCL). System design can rapidly progress from block diagram to final schematics, as there is no need to design bus interfaces. In addition, functional blocks on the block diagram correspond to actual ICs. A prototype system or a final product version can be easily modified or upgraded by `clipping' or `unclipping' ICs to or from the bus. The simplicity of designing with the I2C bus does not reduce its effectiveness: it is a reliable, multimaster bus with integrated addressing and data-transfer protocols. The I2C-bus compatible ICs give cost reduction benefits through smaller IC packages and a minimization of PCB traces and glue logic. In this Application Note we shall discuss the most important technical features of the I2C bus and describe the special I2C hardware interface of the 8XC751/752 8XC751/752. We shall demonstrate with an example how the microcontroller can be programmed for a multimaster environment. The communications routines of the example are quite general, and can be ported to many applications-so we shall discuss in detail the software interface to these routines. The availability of microcontrollers, like the 83C751 83C751, with on-board I2C interface is a very powerful tool for system designers. The integrated protocols allow systems to be completely software defined. Software development time of different products can be reduced by assembling a library of re-usable software modules. In addition, the multimaster capability allows rapid testing and alignment of end-products via external connections to an assembly-line computer. The description of the 8XC751 8XC751 I2C interface hardware and part of the general discussion of the I2C bus is similar to Application Note AN422 AN422 which dealt with the microcontroller in a single-master environment. Most of the added discussions relate to the multimaster aspects of the bus. Additional information for the I2C bus and the 83C751/752 83C751/752 Microcontroller can be found in the Philips Semiconductors Microcontroller Data Handbook (IC20). The mask programmable 83C751 83C751 and its EPROM version, 87C751 87C751, can operate as a master or a slave device on the I2C small area network. In addition to the efficient interface to the dedicated MICROCONTROLLER A AN430 AN430 LCD DRIVER STATIC RAM OR EEPROM SDA SCL GATE ARRAY ADC MICROCONTROLLER B SU00385 SU00385 Figure 1. Example of an I2C-bus Configuration 1992 Jun 26 4-40 Revision date: June 1993 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications AN430 AN430 +VDD PULL-UP RESISTORS RP RP SDA (SERIAL DATA LINE) SCL (SERIAL CLOCK LINE SCLK SCLK SCLKN1 OUT DATAN1 OUT SCLK IN SCLKN2 OUT DATA IN DATAN2 OUT SCLK IN DEVICE 1 DATA IN DEVICE 2 SU00386 SU00386 Figure 2. Connection of I2C-bus Devices to the I2C-bus THE I2C BUS then be the slave for another transfer, initiated by another processor on the network. The master/slave relationships on the bus are not permanent, and exist per transfer. The two lines of the I2C bus are a serial data line (SDA) and a serial clock line (SCL). A typical system configuration is shown in Figure 2. Each device is recognized by a unique address-whether it is a microcomputer, LCD driver, memory or keyboard interface-and can operate as either a transmitter or a receiver, depending on the function of the device. A device generating a message or data is a transmitter, and a device receiving the message or data is a receiver. Obviously, a passive function like an LCD driver could only be a receiver, while a microcontroller or a memory can both transmit and receive data. As more than one master may be connected to the bus it is possible that two devices will try to initiate transfer at the same time. Obviously, in order to eliminate bus collisions and communications chaos, an arbitration procedure is necessary. The I2C design has an inherent arbitration and clock synchronization procedure relying on the wired-AND connection of the devices on the bus. In a typical multimaster system, a microcontroller program should allow it to gracefully switch between master and slave modes and preserve data integrity upon loss of arbitration. Every device connected to the bus must have an open-drain or an open-collector output for both the data (SDA) and the clock (SCL) lines. Each one of the lines is connected to the positive supply via a common pull-up resistor (see Figure 2). This implements a wired-AND function, and each of the bus lines which will have the HIGH level only if all the output transistors tied to it are switched off. DATA TRANSFERS One data bit is transferred during each clock pulse (Figure 3). The data on the SDA line must remain stable during the HIGH period of the clock pulse in order to be valid. Changes in the data line at this time will be interpreted as control signals. A HIGH-to-LOW transition of the data line (SDA) while the clock signal (SCL) is HIGH indicates a Start condition, and a LOW-to-HIGH transition of the SDA while SCL is HIGH defines a Stop condition (Figure 4). The bus is considered to be busy after the Start condition and free again a certain time after the Stop condition. The Start and Stop conditions are always generated by the master. Data on the I2C bus can be transferred at a rate up to 100kbit/s. The number of devices connected to the bus is limited only by the maximum bus capacitance of 400pF. As different technology devices can be connected to the I2C bus, the levels of the logical 0 (Low) and logical 1 (High) are not fixed and depend on the appropriate level of VDD. The number of data bytes transferred between the Start and Stop condition from transmitter to receiver is not limited. Each byte, which must be eight bits long, is transferred serially with the most significant bit first, and is followed by an acknowledge bit (Figure 5). The clock pulse related to the acknowledge bit is generated by the master. The device that acknowledges has to pull down the SDA line during the acknowledge clock pulse, while the transmitting device releases the SDA line (HIGH) during this pulse (Figure 6). MASTERS AND SLAVES When a data transfer takes place on the bus, a device can be either a master or a slave. The device which initiates the transfer, and generates the clock signals for this transfer is the master. At that time any device addressed is considered a slave. It is important to note that a master could be either a transmitter or a receiver: a master microcontroller may send data to a RAM acting as a transmitter, and then interrogate the RAM for its contents acting as a receiver-in both cases being the master initiating the transfer. In the same manner, a slave could be both a receiver and a transmitter. A slave receiver must generate an acknowledge after the reception of each byte, and a master must generate one after the reception of each byte clocked out of the slave transmitter. If a receiving device cannot receive the data byte immediately, it can force the transmitter into a wait state by holding the clock line (SCL) LOW. When designing a system it is necessary to take into account cases when The I2C is a multimaster bus. It is possible to have in one system more than one device capable of initiating transfers and controlling the bus. A microcontroller may act as a master for one transfer, and 1992 Jun 26 4-41 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications acknowledge is not received. This happens, for example, when the addressed device is busy in a real time operation. In such a case the master, after an appropriate "time-out", should abort the transfer by generating a Stop condition, allowing other transfers to take place. These "other transfers" could be initiated by other masters in a multimaster system or by this same master. AN430 AN430 SDA SCL An exception to the "acknowledge after every byte" rule occurs when a master is a receiver: it must signal an end of data to the transmitter by NOT signalling an acknowledge on the last byte that has been clocked out of the slave. The acknowledge related clock, generated by the master, should still take place but the SDA line will not be pulled down. In order to indicate that this is an active and intentional lack of acknowledgement, we shall term this special condition as a "Negative ACK". DATA LINE STABLE: DATA VALID CHANGE OF DATA ALLOWED SU00361 SU00361 Figure 3. Bit Transfer on the I2C Bus The bus design includes special provisions for interfacing to microprocessors which implement all the I2C communications in software only-it is called "Slow Mode". When all the devices on the network have built-in I2C hardware support the Slow Mode is irrelevant. SDA SDA SCL SCL S P START CONDITION STOP CONDITION SU00362 SU00362 Figure 4. Start and Stop Conditions SDA MSB SCL S 1 ACKNOWLEDGEMENT SIGNAL FROM RECEIVER 2 7 8 ACKNOWLEDGEMENT SIGNAL FROM RECEIVER 9 1 2 3­8 9 ACK START CONDITION P ACK BYTE COMPLETE, INTERRUPT WITHIN RECEIVER CLOCK LINE HELD LOW WHILE INTERRUPTS ARE SERVICED STOP CONDITION SU00363 SU00363 Figure 5. Data Transfer on the I2 C Bus DATA OUTPUT BY TRANSMITTER DATA OUTPUT BY RECEIVER SCL FROM MASTER S 1 2 7 8 9 START CONDITION CLOCK PULSE FOR ACKNOWLEDGMENT Figure 6. Acknowledge on the I2C Bus 1992 Jun 26 4-42 SU00387 SU00387 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications AN430 AN430 SDA SCL 1­7 8 9 ADDRESS R/W 1­7 ACK 8 9 1­7 9 8 S P DATA ACK DATA ACK START CONDITION STOP CONDITION SU00365 SU00365 Figure 7. A Complete Data Transfer on the I2C-Bus DATA TRANSFERRED (n BYTES + ACKNOWLEDGE) MASTER WRITE: S SLAVE ADDRESS W A DATA A DATA A P NA P DATA TRANSFERRED (n BYTES + ACKNOWLEDGE) MASTER READ: S SLAVE ADDRESS R A DATA A DATA (n BYTES + ACKNOWLEDGE) (n BYTES + ACKNOWLEDGE) COMBINED FORMATS: S S= P= W= R= R/W = A= NA = SLAVE ADDRESS R/W A DATA A S SLAVE ADDRESS R/W A DATA A P DIRECTION OF TRANSFER MAY CHANGE AT THIS POINT START STOP WRITE READ READ OR WRITE ACKNOWLEDGE NEGATIVE ACKNOWLEDGE SU00366 SU00366 Figure 8. I2C Data Formats portions. In addition to the "standard" addressing discussed here, the I2C bus protocol allows for "general call" addressing and interfacing to CBUS devices. ADDRESSING AND TRANSFER FORMATS Each device on the bus has its own unique address. Before any data is transmitted on the bus, the master transmits on the bus the address of the slave of this transaction. A well-behaved slave, if it exists on the network, should of course acknowledge the master's addressing. The addressing is done with the first byte transmitted by the master after the Start condition. When the master is communicating with one device only, data transfers follow the format of Figure 8 where the R/W bit could indicate either direction. After completing the transfer and issuing a Stop condition, if a master would like to address some other device on the network, it could start another transaction by issuing a new Start. An address on the network is seven bits long, appearing as the most significant bits of the address byte. The last bit is a direction (R/W) bit. A zero indicates that the master is transmitting (WRITE) and a one indicates that the master requests data (READ). A complete data transfer, comprised of an address byte indicating a WRITE and two data bytes is shown in Figure 7. Another way for a master to communicate with several different devices would be by using a "repeated start". After the last byte of the transaction was transferred, including its acknowledge (or Negative ACK), the master issues again a Start, followed by address byte and data, without effecting a Stop. The master may communicate with a number of different devices, combining READS and WRITES. Only after the transfer with the last slave took place, the master issues a Stop and releases the bus. Possible data formats are demonstrated in Figure 8. Note that the repeated start allows for both change of a slave and a change of direction, without releasing the bus. We shall see later on that the change of direction feature can come in handy even when dealing with a single device. When an address is sent, each device in the system compares the first seven bits after the Start with its own address. If there is a match, the device will consider itself addressed by the master and will send an acknowledge. The device could also determine if in this transaction it is assigned the role of a slave receiver or slave transmitter, depending on the R/W bit. Each node of the I2C network has a unique seven bit address. The address of a microcontroller is, of course, fully programmable, while peripheral devices usually have fixed and programmable address 1992 Jun 26 4-43 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications beginning of a sequence of locations for a multi-byte transfer. A sub-address is an eight bit byte, unlike the device address it does not contain a direction (R/W) bit, and like any byte transferred on the bus it must be followed by an acknowledge. In a single master system the repeated start mechanism is more efficient than terminating each transfer with a Stop and starting again. In a multimaster environment the determination of which format is more efficient could be more complicated, as when a master is using repeated starts it occupies the bus for a long time and prevents other devices from initiating transfers. A memory write cycle is shown in Figure 9(a). The Start is followed by a slave byte with the direction bit set to WRITE, a sub-address byte, a number of data bytes and a Stop signal. The sub-address is loaded into the word address memory. The data bytes which follow will be written one after the other starting with the sub-address location and the register is incremented automatically. USE OF SUB-ADDRESSES For some ICs on the I2C bus the device address alone is not sufficient for effective communications and a mechanism for addressing the internals of the device is necessary. A typical example is addressing memories, when we want to access a specific word inside the device or a sequence of memory locations starting at a specific internal address. The memory read cycle (Figure 9(b) commences in a similar manner with the master sending a slave address with the direction bit set to WRITE with a following sub-address. Then, in order to reverse the direction of the transfer, the master issues a repeated Start followed again by the memory device address, but this time with the direction bit set to READ. The data bytes starting at the internal sub-address will be clocked out of the device with each followed by a master-generated acknowledge. The last byte of the read cycle will be followed by a Negative ACK, signalling the end of transfer. The cycle is terminated by a Stop signal. A typical I2C memory device like the PCF8570 PCF8570 RAM contains a built-in word address register that is incremented automatically after each read or written data byte. When a master communicates with the PCF8570 PCF8570 it must send a sub-address in the byte following the slave address byte. This sub-address is the internal address of the word the master wants to access for a single byte transfer or the ACKNOWLEDGE FROM SLAVE S SLAVE ADDRESS 0 A AN430 AN430 ACKNOWLEDGE FROM SLAVE ACKNOWLEDGE FROM SLAVE WORD ADDRESS A DATA A P n BYTES R/W AUTO-INCREMENT MEMORY WORD ADDRESS MASTER TRANSMITS TO SLAVE RECEIVER (a) ACKNOWLEDGE FROM SLAVE S SLAVE ADDRESS 0 A ACKNOWLEDGE FROM SLAVE ACKNOWLEDGE FROM SLAVE WORD ADDRESS A S SLAVE ADDRESS 1 A AUTO-INCREMENT MEMORY WORD ADDRESS R/W NO ACKNOWLEDGE FROM MASTER DATA MASTER TRANSMITTER BECOMES MASTER RECEIVER AND SLAVE RECEIVER BECOMES SLAVE TRANSMITTER A DATA n BYTES 1 P LAST BYTE AUTO-INCREMENT MEMORY WORD ADDRESS MASTER READS AFTER SETTING WORD ADDRESS (WRITE WORD ADDRESS; READ DATA) (b) SU00367 SU00367 Figure 9. I2C Sub-Address Usage 1992 Jun 26 4-44 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications WAIT STATE AN430 AN430 START COUNTING HIGH PERIOD CLK 1 COUNTER RESET CLK 2 SCL SU00388 SU00388 Figure 10. Clock Synchronization During the Arbitration Procedure Transmitter 1 Loses Arbitration DATA 1 SDA DATA 1 DATA 2 SDA SCL S SU00389 SU00389 Figure 11. Arbitration Procedure of Two Masters continuously monitor the clock line, and reset their internal clock counter to start counting their own Low clock period. This way, the first falling edge will synchronize all clock generators to the beginning of the Low time. ARBITRATION IN A MULTIMASTER SYSTEM The decision about which master has control over the I2C bus is based solely on the address and data sent by competing masters, and there is no central master or any order of device priority on the bus. Any device connected to the I2C bus is allowed to become a master, but devices are not supposed to "steal" the bus from other devices when a transfer is in process. If a device wishing to be a Master is aware that a transaction (initiated by another master) is taking place, it will wait until the transfer is concluded with a Stop condition on the bus-and only then try to seize it by sending its own Start. It is possible, however, that two or more masters may want to start a transfer at exactly the same moment. A scenario that may happen quite frequently in a loaded system: two devices are waiting for a long transaction to be completed, and simultaneously try to get the bus when detecting the Stop condition. An arbitration procedure synchronizes the different clocks, ensuring that the data is not corrupted, and causes all masters except one to withdraw from the bus, so only one master will control the transfer. This procedure applies only when masters initiate transfers simultaneously. Once a device clock has gone Low it will hold the SCL line in this state until its internal clock High state is reached, and then will release the line. The Low to High change in this device will not change the state of the SCL line if another device, which is still within its Low period, is pulling down the line. This way, SCL will be held Low by the device with the longest Low period. A master that has finished its Low time earlier will enter a wait state until SCL is released by the slowest master and goes high. Upon the rising edge of SCL all masters start counting their High period, the first device to complete its High period will pull the SCL Low. In this way a single, synchronized clock is generated on the bus where the rising edge is being defined by the slowest master and the falling edge by the fastest master. Arbitration between masters takes place on the SDA line. A master which tries to transmit a High while another device transmits a Low will withdraw, shutting off its data output stage and not interfering with the transfer until a Stop condition is detected. Due to the wired-AND property of the SDA line, a device "knows" that it lost arbitration by the fact that the Low SDA is different than its desired High output. Arbitration starts by comparing the address bits. When masters transmit different addresses the one transmitting the address with the lowest binary value wins. If all masters in arbitration transmit to the same address, arbitration continues into The clock synchronization, illustrated in Figure 10, ensures that only one defined clock is generated on the bus. It occurs naturally, as a result of the wired-AND property of the SCL line. Suppose two masters want to initiate a transfer on the bus. Clk1 and Clk2 in Figure 10 illustrate the desired clock outputs of each device, which would actually occur on the bus if each were the only master. The SCL waveform is the resulting wired-AND of the two clocks. The device that pulls the SCL down first will succeed. The other masters 1992 Jun 26 4-45 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications I2C Status (I2STA). The register addresses are shown in the 8XC751 8XC751 section of the Philips Semiconductors Microcontroller Data Handbook (IC20). Although the following discussion of the hardware and register details is not complete, it should give a better understanding of the programming examples. the comparison of data. Figure 11 illustrates the arbitration process between two masters. By definition, the transfer that forces the wired-AND result is the one that wins the arbitration, so the address and data of a winning device are not corrupted and no information is lost in the arbitration process. A master losing arbitration may generate clock pulses until the end of the byte. Thus it may affect the clock speed, but not the data on the bus. Timer I In I2C applications, Timer I is dedicated to the port timing generation and bus monitoring. In non-I2C applications, it is available for use as a fixed rate timer. If a master loses arbitration during the addressing stage it is possible that the winning master is trying to address it. In an efficient design, the losing master should switch immediately to its slave receiver mode, receive the data transmitted and acknowledge it-otherwise the message will have to be re-transmitted or is lost. A well designed master will take into account "illegal" protocol situations and will determine that it lost arbitration when it detects a Stop or a Start which are not synchronized with its own transmission. Electrical interference or a malfunctioning device may cause such a situation which actually corrupts the message transfer. For the bus monitoring function, Timer I is being used as a "watchdog timer" for bus hang-ups. It creates an interrupt when the SCL line stays in one state for an extended period of time between a Start condition and a following Stop condition. SCL "stuck low" indicates a faulty master or slave. SCL "stuck high" may mean a faulty device or that noise induced into the I2C caused all masters to withdraw from the I2C arbitration. The time-out interval of Timer I is fixed: it carries out and interrupts (if enabled) when about 1024 machine cycles have elapsed since a change on SCL within a frame. In other words, whenever I2C is active we let Timer I run, but clear it whenever a frame is not in progress (reset or Stop occurred more recently than the last Start condition) or SCL changes within a frame. (Note: we wrote "about 1024 machine cycles" for the sake of accuracy-this number may slightly change according to the setting of the CT0 and CT1 bits mentioned below. In any case, the exact number of cycles for a time out does not have any practical significance). HANDSHAKE BY CLOCK SYNCHRONIZATION The clock synchronization mechanism as described above actually implements a handshake mechanism, enabling receiving devices to "slow down" fast transfers when necessary. On the bit level, a slow slave device like a microcontroller that does not have hardware I2C interface port, can extend each clock period and slow down the bus clock. The speed of any master is adapted to the operating rate of this device as long as it is active on the bus. In addition to the interrupt upon Timer I overflow, the I2C port hardware is reset. This is useful for multiple master systems in situations where this same 8XC751 8XC751 caused the bus hang-up due to a lack of software response. SCL will be released and I2C operation between other devices could continue. On the byte level the synchronization mechanism takes effect as a "handshake" mechanism when a slave device that was fast enough to receive or transmit a byte still needs extra time to store the received byte or prepare the next byte for transmission. The slave can hold the SCL line low after the reception and acknowledge of a byte, thus forcing the Master into a wait state-until the slave is ready for the next transfer. 8XC751 8XC751 I2C I2CON Register The I2C Control register can be read or written to (see Figure 12). When writing to the I2CON register one should use bit masks as demonstrated in the examples. Trying to clear or set the bits in the register using the bit addressing capabilities of the 8XC751 8XC751 may lead to undesirable results. The reason is that a command like CLRB reads the register, sets the bit and writes it back-and the write-back may affect other bits. HARDWARE The on-chip I2C bus hardware support of the 8XC751 8XC751 allows operation on the bus at full speed and simplifies the software needed for effective communications on the network. The hardware activates and monitors the SDA and SCL lines, performs the necessary arbitration and framing error checks, and takes care of clock stretching and synchronization. The hardware support includes a bus timeout timer, called Timer I. The hardware is synchronized to the software either through polled loops or interrupts. I2CFG Register The configuration register is a read/write register (see Figure 13). I2DAT Register The I2C data register is a read/write register, where the msb represents the data received or data to be sent. The other seven bits are read as 0 (see Figure 14). Two of the port 0 pins are multi-functional. When the I2C is active, the pin associated with P0.0 functions as SCL, and the pin associated with P0.1 functions as SDA. These pins have an open drain output. I2CSTA Register The I2C STAtus Register is a read-only register reflecting the internal status of the I2C interface hardware (see Figure 15). Two of the five interrupt sources may be used for I2C support. The I2C interrupt is enabled by the EI2 flag of the interrupt enable register, and its service routine should start at address 023h. An I2C interrupt is usually requested (if enabled) when a rising edge of SCL indicates new data on the bus or a special condition occurs: Start, Stop or arbitration loss. The interrupt is induced by the ATN flag, (see below for the conditions for setting this flag). The Timer I overflow interrupt is enabled by the ETI flag, and the service routine starts at 01Bh. Transmit Active State The transmit active state-Xmit Active-is an internal state in the I2C interface that is affected by the I2C registers as explained above. The I2C interface will only drive the SDA line low when Xmit Active is set. Xmit Active is set by writing the I2DAT register or by writing I2CON with XSTR = 1 or XSTP = 1. The ARL bit will be set to 1 only when Xmit Active is set-in such a case Xmit Active will be automatically reset upon ARL. Xmit Active is cleared by writing 1 to CXA at I2CON register or by reading the I2DAT register. The I2C port is controlled through four special function registers: I2C Control (I2CON), I2C Configuration (I2CFG), I2C Data (I2DAT) and 1992 Jun 26 AN430 AN430 4-46 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications I2CON READ RDAT ATN DRDY RDAT ATN DRDY ARL STR STP AN430 AN430 MASTER ­­­ Received DATa bit. The value of SDA latched by the rising edge of SCL. Its contents is identical to RDAT in the I2DAT register. Reading the received data here allows doing so without clearing DRDY and releasing SCL. An "ATteNtion" flag, set when any one of DRDY, ARL, STR or STP is set. This flag allows a single bit testing for terminating "wait loops", indicating a meaningful event on the bus. This flag also activates the I2C interrupt request. Data ReaDY flag. Set by a rising edge of SCL when I2C is active, except at an idle slave. This flag is cleared by reading or writing the I2DAT register, or by writing a 1 to CDR (at the same address, when I2CON is written). ARL ARbitration Loss flag. Indicates that this device lost arbitration while trying to take control of the bus. STR STaRt flag. Set when a Start condition is detected, except at an idle slave. STP SToP flag. Set when a Stop condition is detected, except at an idle slave. MASTER This flag is set when the controller is a bus master (or a potential master, prior to arbitration). I2CON WRITE CXA IDLE CDR CARL CSTR CSTP XSTR XSTP CXA "Clear Xmit Active". Writing a 1 to CXA clears the internal transmit-active state. IDLE Setting this bit will cause a slave to enter idle mode and ignore the I2C bus until the next Start is detected. If the software sets the MASTRQ flag, the device may stop idling by turning into a master. CDR Clear Data Ready. Clears the DRDY flag. CARL Clear Arbitration Lost. Clears the ARL flag. CSTR Clear STaRt. Clears the STR flag. CSTP Clear STop. Clears the STP flag. XSTR "Xmit repeated STaRt". Writing a 1 to this bit causes the hardware to issue a Repeated Start signal. A side effect will be setting the internal Xmit Active state. This should be used only when the device is a master. XSTP "Xmit SToP". Issues a Stop condition. The Xmit active state is set. SU00368 SU00368 Figure 12. I2CON Register SLAVEN SLAVEN MASTRQ MASTRQ CLRTI TIRUN - - CT1 CT0 Writing a 1 to this flag enables the slave functions of the I2C interface. Request control of the bus as a master. CLRTI Clear the Timer I interrupt flag. This bit is always read as 0. TIRUN Writing a 1 will let Timer I run. When I2C is active, it will run only inside frames, and will be cleared by SCL transitions, Start and Stop. Writing a 0 will stop and clear the timer. CT1, CT0 These bits should be programmed according to the frequency of the crystal oscillator used in the hardware. They determine the minimum high and low times for SCL, and are used to optimized performance at different oscillator speeds. SU00369 SU00369 Figure 13. I2CFG Register 1992 Jun 26 4-47 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications I2DAT READ RDAT - - - - - - - Received DATa bit, captured from SDA every rising edge of SCL. Reading I2CAT clears DRDY and the Xmit Active state. If it is necessary to read the data without affecting the flags, it can be read out of RDAT in the I2CON register. I2DAT WRITE XDAT RDAT AN430 AN430 XDAT - - - - - - - Xmit DATa bit. Writing XDAT determines the data for the next bit to be transmitted on the I2C bus. Writing I2DAT also clears DRDY and sets the Xmit Active state. SU00370 SU00370 Figure 14. I2DAT Register I2CSTA READ IDLE IDLE XDATA XACTV MAKSTR MAKSTP XSTR XSTP - Indicates when the I2C hardware is in the Idle mode. XDATA Reflects the contents of the I2C transmitter buffer. XACTV Indicates that the I2C transmitter is active. MAKSTR Indicates that the hardware is effecting a Start. MAKSTP Indicates that the hardware is effecting a Stop. XSTR Hardware effecting a Repeated Start. XSTP Hardware effecting a Stop. SU00390 SU00390 Figure 15. I2CSTA Register I2C COMMUNICATIONS SOFTWARE For Slave operation the microcontroller must be interrupt driven relative to an I2C frame Start, as any Master on the bus could request a transaction at any moment, not synchronized to the application program executing on the controller. An interrupt service routine monitors the address transmitted on the bus. When the microcontroller is addressed it takes care to either read the data from the bus into a buffer or write buffer data onto the bus. When such a transaction is successfully completed, one of several "Slave Event Routines" is called prior to returning to the main application program. Such an "Event Routine" is a part of the application, allowing an immediate response to the data received, or the fact that data was transmitted to a requesting Master. This allows "synchronization" of the application to a "slave" bus transaction. Typical uses of the Event Routine mechanism will be a computation based on new data, or re-loading the transmit buffer with new data getting ready for the next random request. The actual Event Routines will be programmed differently for different applications, but the names and the calls will remain the same as long as the communications routines are left unmodified. The software listing demonstrates programming the 8XC751/752 8XC751/752 for a multimaster I2C environment where the device can be both a Master or a Slave responding to other Masters on the I2C network. The bulk of the software is communications routines which are not only for demonstration but could be ported to other user programs with minimal or no modifications. The routines are quite general and could be useful in most applications. We have tried to design a well-defined software interface, enabling most users to copy the routines as they are, modifying only the pre-defined interface elements to fit the specific applications. We encourage users to use the routines without modifications whenever possible, as the lower levels of the hardware-software integration could be quite involved. The rest of this application note will relate to the programming example. We shall discuss the general operation of the routines and how they are integrated into an application. Then we shall describe in detail all the software interface elements and how to use them. A transaction as a Master is initiated by the application program. Our implementation uses the interrupt mechanism for the Master communications as well. The application issues a request for the bus by setting the MASTRQ bit of the I2C port control, and when the bus is available an interrupt occurs. This way, if the bus is free there will be an immediate response. If the bus is busy, the application may go on executing (if so programmed) until this controller can get control of the bus. When the microcontroller gets mastership of the bus it initiates a bus transaction according to "directives" set by the I2C COMMUNICATIONS ROUTINES-OVERVIEW In order to function well in a multimaster environment the microcontroller must be able to take control of the I2C bus as a Master, "tolerate" message transactions between other Masters and other devices, and respond efficiently as a Slave to other bus Masters. The communications routines should allow a Master "graceful" recovery from an arbitration loss and other situations when a message transaction is not completed, allowing for communication re-tries. 1992 Jun 26 4-48 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications application program. The most important directives are the address (and subaddress if relevant) of the slave device addressed, and the length of the message to be transmitted or received. BUS WATCHDOG AND ERROR RECOVERY A malfunctioning device (in hardware or software) may hold the SCL line low, thus causing the bus to be "stuck". It might even be possible that a transient protocol violation (due to hardware interference, such as a device turning on) may cause some devices (non programmable, or even microcontrollers which were not carefully programmed) to hold the bus. Since within a frame the bus is software-polled, a "stuck" bus might cause the application software to "hang forever". Here the TIMERI watchdog comes to the rescue, interrupting when there is no bus activity for a long period of time. When a Master transaction is concluded, a Master Event Routine (called MastNext) is called to perform whatever task the application demands. As with the Slave Event Routines it will typically respond to a successful transmission or reception of data. In addition, it could handle situations where a slave does not respond at all, or does not acknowledge a data byte (thus causing data transfer to terminate). A program might react to the fact that a slave does not respond by re-trying to communicate at a later time, by issuing a message to another peripheral device or just ignoring it. The handling of such cases is application dependent, and should be programmed into the routine called "MastNext". The MastNext routine is invoked when the Master terminates the transaction "willingly", but not upon arbitration loss. When the I2C service routine is interrupted by the watchdog timer, the processing of the current frame is not completed and the event routines are not called. The software returns to execute the mainline application, and will be interrupted again for the next frame (next Start, received as a slave or induced as a Master). A status flag and a counter report on the watchdog interrupt, so the application program can be made to inhibit the I2C port if there are too many occurrences of a "hanging" bus. The microcontroller operating as a bus Master may lose arbitration to another Master which happens when two Masters transmit in synchronization, commencing with the same Start signal. If arbitration is lost while transmitting or receiving data, our processor withdraws from the bus and turns itself into a slave-an active Slave upon a Start, or returning to the calling program as an idle slave. When the arbitration loss occurs while transmitting an address, our processor turns itself immediately into an active slave, "listening" to the rest of the address transmitted by the new Master. If our processor reads its own address from the bus (as transmitted by the new Master) our processor responds as a willful slave. If this mechanism would not have been implemented, there could be potential inefficiency when a device that happened to be synchronized to another Master loses arbitration, but is not able to respond to the winning device. Bus protocol errors and "hangups" might be an issue in systems which are susceptible to noise, temporary bus line shorts, "hot plug in" of devices or even erroneously programmed devices-and a "fail safe" controller program should be able to detect bus problems and possibly assist in resolving them. The RECOVER routine resets the I2C interface of the microcontroller, and attempts to release some other devices on the bus by toggling the clock line. The I2C interface of the 8XC751 8XC751 is reset by letting TimerI run and expire, since this circuitry does not feature a software controlled reset. This "extreme" measure is needed in some cases of bus protocol violation. The bus and interface circuit recovery routine can be automatically invoked whenever TimerI detects a timeout. In addition, for systems where potential bus failures are a concern and reliability is an issue, one may implement mechanisms to invoke bus and interface recovery from the application code. This may help in cases where the bus gets "stuck" when there is no I2C frame in progress. In such an instance the watchdog timer will not give any timeout indications, as it has not been activated. Another case emanates from a design peculiarity of the interface circuitry on the 8XC751 8XC751: if the SCL line is externally grounded when there is a Start condition, this Start might be ignored, and the watchdog may not be activated. Our programming example deals with potential failures by testing for transaction completion and retrying transmissions when necessary (these are explicit retries, in addition to an "automatic" retry after a Master's arbitration loss, invoked by the MASTRQ bit). Too many transmission failures activate the RECOVER routine. Another situation for arbitration loss could be a bus exception resulting from a device operating not according to the bus protocol or interference on the bus lines. In addition to "regular" arbitration loss detected with the ARL hardware flag, such a situation may occur with detecting a Start or a Stop in the middle of transmitting an address or data byte. In such a situation the microcontroller withdraws from the bus as well-active Slave upon a Start detection, or returning as an idle slave in other cases. When a Master transaction is terminated by an arbitration loss, the Master Request flag (MASTRQ) of the hardware I2C port remains in effect. As a result when the bus gets free, our device will take control, issue a Start, and the transaction that was cut will start again. This restart will happen automatically, without any application involvement (unlike non-acknowledgement, where the MastNext routine determines what shall be done). The I2C communications routines are structured as an interrupt service routine responding to an I2C port interrupt upon a frame Start. Within a frame the I2C processing is continuous, where the I2C port is polled for hardware response, and the I2C interrupts are disabled. Other interrupts are enabled during the service routine. The set-up requirements from the mainline program are minimal, and interfacing is done via RAM buffers and some pre defined RAM locations. The lower level interface with the hardware is done inside the service routine, and can typically be ignored by the application programmer. 1992 Jun 26 AN430 AN430 4-49 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications I2C COMMUNICATIONS ROUTINES-INTERFACE There could be many applications that will not need to use MSGSTAT contents, as the very fact of calling a certain event routine implies completion of a processing stage. The I2C service routine deals with the transmission and reception of messages, without any concern for the contents of the message. In order to provide a general interface for different applications the data is transferred via buffers. The service routine does not have to "know" where the data goes to or comes from-as long as the application program specifies the required pointers for these buffers. The interface to the actual application (which "cares" about message contents, timing, addressing and so forth) is done in a well defined manner, allowing usage of the same service routine with different application programs. For Master transactions, in addition to the data buffer MasBuf, there are several RAM locations into which the application inserts Master message "directives". These directives provide the service routine with the information necessary to carry out the next Master transaction. The one byte RAM locations used for directives are DESTADRW, DESSUBAD, MASTCNT and MASCMD. DESTADRW contains the destination slave address in bits 7-1, while bit 0 is the R/W bit. Bit 0 contains 0 for a Write operation (the message is to be transmitted to the salve) and 1 for a Read operation (message is being read from the slave and received by this Master). The interface is carried out with the use of buffers, pre-defined names for Application Event Routines, interface RAM locations for transferring parameters, pointers and flags, and constants. A more detailed discussion of the interface follows. DESSUBAD contains the 8 bit sub-address of the slave, if necessary. For transactions without a sub-address, the contents of DESSUBAD is ignored. Buffers There are three buffers for data transfers between the I2C bus and the application program. MASTCNT contains the number of data bytes in the message to be sent from or received into MasBuf. This number should not be bigger than the length of MasBuf. MasBuf is used for Master transmission and reception. The number of data bytes for each Master message-reception or transmission, is specified by the memory location MASTCNT. The value in MASTCNT should be less than the length of MasBuf. For Master transmission the message is placed in MasBuf before the transmission is initiated. In Master reception, the received message will be contained in the same buffer. There is only one Master message transaction occurring at the same time, so we may use the same buffer both for transmission and reception. MASCMD byte contains the bit flags SUBADD, RPSTRT and SETMRQ. SUBADD is 0 (cleared) for a message with a regular address, and 1 (set) when a subaddress is required. When SUBADD is set, the service routine takes care of all the protocol required for sub-addressing, which includes a Repeated Start for Read operations. A message with a subaddress is considered to be a single message, even if it includes a Repeated Start. For Slave operation we must accommodate data transfers which may come randomly, asynchronous to each other or to possible operation of the same device as a Master. Therefore it is necessary to allocate additional RAM area as buffers dedicated to Slave operation: SRcvBuf for receiving data, STxBuf for transmission. The RPSTRT and SETMRQ are kept cleared in regular applications, and will be used only for "tailoring" the bus transfers in special cases. When RPSTRT is cleared the message will terminate, as usually required, with a Stop. When RPSTRT is set a Repeated Start will be sent on the bus, and Master operation will resume. The RPSTRT directive relates to terminating the message after all the data was transferred, and not to the mandatory Repeated Start in the middle of sub-addressed Read operation. A single message with a subaddress will typically have RPSTRT cleared. SETMRQ indicates what will be loaded into the MASTRQ flag of the hardware when Stop is transmitted. Typically it will be cleared. When SETMRQ is 1, MASTRQ will be set, thus trying to issue a new Start immediately following the Stop. In such a case the service routine will not return upon Stop, but will continue as a Master. The length of the Slave receive buffer is defined by the symbol RBufLen. It is used by the code for protection, avoiding overwriting RAM beyond the allocated buffer size in case a Master sends a message which is too long. There is no need for RAM protection for transmission, but the Master should not request more data than STxBuf can supply. Interface RAM Locations RAM location MyAddr contains the address of this processor. Status flag MSGSTAT is used for reporting to the application on I2C communications status-mainly on the successful, or unsuccessful, completion of a message transaction. The contents of MSGSTAT may be used by the mainline application code or by the Event Routines. The different codes that could be placed by the I2C service routine are described later in the text. When the message processing commences, a code indicating Slave or Master processing is inserted to MSGSTAT, and is updated as we go along. 1992 Jun 26 AN430 AN430 TITOCNT is used to count time-outs of the watchdog timer. Whenever such a timeout invokes the TIMER I interrupt service routine the contents of the location TITOCNT are incremented, and the timeout is reported in MSGSTAT. The count is saturated at 0FFh. This mechanism may be used in an application that is very much "concerned" with potential bus failures, allowing some type of "failure monitoring" by the application even for Slave transactions. 4-50 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications AN430 AN430 INITIALIZE AND SET UP I2C COMMUNICATIONS INTERRUPT RUN APPLICATION TRANSACTION NOT COMPLETED I2C INTERRUPT ROUTINE (ISR)-SLAVE APPLICATION INITIATES MASTER TRANSACTION TRANSACTION SUCCESSFULLY COMPLETED INTERRUPT SLAVE EVENT ROUTINE STxedR/ScvdR/SLnRcvdR I2C INTERRUPT ROUTINE (ISR)-MASTER TRANSACTION SUCCESSFULLY COMPLETED MASTER ROUTINE Mastnext TRANSACTION NOT COMPLETED CONTINUE APPLICATION NOTE: This is a simplified diagram to assist the text. It is not a flow chart. SU00391 SU00391 Figure 16. Typical Communications Scenario-A Simplified Diagram application which is constantly busy doing another task, in an environment where the communication requests on the I2C bus are frequent. If there is a new message request shortly after the current message is completed, having to wait for the application until it "has time" may result in not reacting, or sending the same data again, or overwriting the received data in the buffer. Another obvious case demanding event routine calls is a Master sending different messages with a Repeated Start-the new data for the following message must be prepared in the interrupt service routine as the current message is completed (there is no return from interrupt prior to the new data transmission). APPLICATION EVENT ROUTINES The service routine calls Event Routines with pre-defined names (Figure 16), and these routines must be provided by the application program. The actual code of the routines will differ from application to application, but the routine names are being kept the same. These routines are being called when successful processing of a message (send or receive) is completed. The routines may perform whatever action the application was designed for, which is not necessarily related to the I2C communications mechanism. In addition, the routines may perform the data interface tasks for the I2C port, like emptying buffers from received data or preparing the next message by setting up the buffers. The programmer has the flexibility to decide where to prepare the next message according to the requirements of the application. This can be done after return from the event routine, in the application code after the return from interrupt, or a combination of both, where the time critical events are performed in the event routines. The application may monitor the MSGSTAT flag for message processing completion. If the event routines are not used, it is recommended to simply code them as a "RET" instruction, thus turning them into dummy routines (this an easier and better practice than changing the service routine itself, eliminating the calls). The mechanism of calling the event routines out of the service routine allows an immediate reaction to the event of message processing completion, before any new activity happens on the bus. In some simple applications this may not be necessary. For example, one may have a main program for a slave which is just a wait loop monitoring a flag set by the service routine when a message transfer, initiated by some master, is completed. In such a case the application could react to the message completion after the interrupt service routine returns. However, in the general case this will not be sufficient. An example could be a slave with an 1992 Jun 26 4-51 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications If the program is supposed to react to a too long a message the same way as to a message that can be contained in the buffer, one may code SLnRcvdR simply as a call to SRcvdR. Master Event Routine: MastNext This routine is called by the service routine when the processing of the current Master message is completed. For an indication on the type of message processing completion, MastNext may inspect the contents of MSGSTAT RAM location. STXedR: Called by the service routine when data has been transmitted out of the slave STxBuf buffer according to a master's request. This routine may insert new data into the buffer, preparing it for the next slave transmission. When MastNext is called, MSGSTAT will contain one of the following codes for message processing completion: The equivalent MSGSTAT indication for this event is STXED ( = 13h). MRCVED ( = 21h)-a complete message (with number of data bytes indicated by MASTCNT) was received from the slave. Note that we do not have a separate routine for the case that the master requested too many bytes-more than STxBuf length-and we sent out meaningless bytes. It is the master's responsibility to specify the message length, and it should be able to request messages with the appropriate length from each slave on the bus. MTXED ( = 22h)-the number of data bytes indicated by MASTCNT were successfully sent and acknowledged by the slave. MTXNAK ( = 23h)-the slave did not acknowledge a data byte of the message, even though it had acknowledged its address. The message transmission was terminated upon the NAK. SRErrR: This routine relates more to bus communications than to the application itself. It can be called when we positively detect a bus error upon reception as a slave, in case the application is supposed to know about it. In most cases this call will not be used, as dealing with bus communications difficulties is usually left to the Master. MTXNOSLV ( = 24h)-no slave acknowledged the address indicated by memory location DESTADDR. The MastNext routine may perform any task(s) necessary for the application. Data handling tasks will typically be dependent on the MSGSTAT indication. One possible task could be setting the directives for the next message. The necessity for executing this task here (versus the main-line code initiating the transfer) is of course application dependent. Just prior to calling SRErrR, the code SRERR (= 14h) is placed in MSGSTAT. 0Completion Routine: I2CDONE This routine is called every time, before returning from the I2C interrupt service routine, whether the transaction was successful or not. It can be used to "safely" monitor MSGSTAT without any risk of a new interrupt modifying the current indication. Simple application programs will not make use of this routine. A more sophisticated application implementing a fail-safe communications protocol may use it to count errors of a certain type in order to determine a recovery scheme. In our programming example, I2CDONE inhibits I2C interrupts when it is evident that as a result of protocol errors interrupts are not caused by legitimate Starts. Slave Event Routines: These routines are called when a message transaction as a slave has been completed. In many cases it could be important to utilize the calls to such routines as the requests for message transactions as a slave can come randomly, asynchronous to the application program. The application may demand that new data coming in should immediately initiate some tasks (e.g. control an output port)-and the event routine can be used to process the result of the slave interrupt. In most cases it will be necessary for a slave to react immediately to a message received simply in order not to lose the data. As a new message may come randomly, it may overwrite the reception buffer before the data has been transferred out of it or acted upon. CONSTANTS RBufLen-the length of SRcvBuf, the slave receive buffer. This constant may be used both by the I2C routines and the application program, and it is the responsibility of the application programmer to define the correct buffer length. For applications in which the reaction for slave events is performed after the return from the service routine, the event is reported by placing an appropriate code in the MSGSTAT flag. The programmer may use event routines, other mainline routines inspecting MSGSTAT, or both. If the event routines are not used, it is recommended to code them as a "RET" instruction. MYNUM-This ROM constant is dependent on the application environment. It is a small integer defining a "serial number" of the node, out of all the processors running the same code. This constant is used only when recovering from a timeout, in order to "de-synchronize" masters from each other when trying to recover the bus. SRcvdR: Called by the service routine when a new, complete message has been received into SRcvBuf. When SRcvdR is called, R1 points to the address of the last byte received into the buffer. In a typical application SRcvdR will transfer the new data out of SRcvBuf, so it will not be written over by a subsequent slave reception. CTVAL1 is a constant defined in ROM. It is used by the application code portion which initializes the I2C, for loading CT0 and CT1 with a value appropriate for the crystal being used. The equivalent MSGSTAT indication for this event is SRCVD ( = 11h). MYADDR1 is a ROM constant containing the address of the processor's I2C node. This value is used by the application demo to load the RAM location MyAddr. SLnRcvdR: Called when a slave message has been received into SRcvBuf, but the message was longer than the SRcvBuf buffer (as specified by RbufLen). The equivalent MSGSTAT indication for this event is SRLNG ( = 12h). 1992 Jun 26 AN430 AN430 4-52 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications AN430 AN430 USING THE COMMUNICATIONS SUBROUTINES PROGRAMMING EXAMPLE In order to use the I2C Communications Routines an application program should take care of the following: ­ Upon initialization, load bits CT1, CT0 of I2CFG register according to the clock crystal used (refer to the table of CT1, CT0 values in the 8XC751 8XC751 section of the Philips Semiconductors Microcontroller Data Handbook (IC20). The assembler listing includes the I2C Communications Routines and a demo application exercising these routines. In most real-life applications the code of the routines could be used without modifications. For those who follow the coding of the routines, one should note that in many instances code speed and program space have been slightly compromised in order to improve readability. The almost "general purpose" interface to the routines affects efficiency as well, and it is possible to write more compact and somewhat faster code for specific applications. The reader is encouraged, though, to use the code "as is" whenever possible. ­ Load MyAddr RAM location with the address of this node. ­ For Slave operation, load STxBuf with the initial data to be transmitted. ­ For slave operation, set the SLAVEN bit in the I2CFG register. ­ Enable I2C and watchdog interrupts by setting the ETI, EI2 and EA bits of the interrupt enable register. The "application" demo is simple-two microcontrollers exchange messages in a "ping-pong" game. In addition to trivial message exchange, the code demonstrates recovery mechanisms from communications errors and bus "hangups". We tried this code with two pairs of controllers exchanging messages on the same bus. The message exchange could repeatedly recover and restart when the SCL and SDA lines were temporarily shorted to ground or between themselves. Simpler versions, without the "protection" mechanisms, could "hang up" under such conditions. ­ For Master operation, set up the next transaction by loading the appropriate directives into MASCMD, DESTADRW, DESSUBAD (if applicable) and MASTCNT, and load MasBuf with the appropriate data if it is a Write message. ­ For Master operation, initiate the next transaction by setting MASTRQ bit in I2CFG. ­ For both Master and Slave operation, handle data transmission and reception via the buffers in main-line code or the Event Routines. 1992 Jun 26 Source Code Available On BBS The source code file for this program is available for download from the Philips computer bulletin board system. This system is open to all callers, operates 24 hours a day, and can be accessed with modems at 2400, 1200, and 300 baud. The telephone numbers for the BBS are: (800) 451-6644 (in the U.S. only) or (408) 991-2406. 4-53 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 0010 0040 0080 0040 0020 0010 0008 0004 0002 0001 0010 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 AN430 AN430 4/14/1992 PAGE 1 ; ;* ; Multimaster Code for 83C751/83C752 83C751/83C752 ; 4/14/1992 ;* ; This code was written to accompany an application note. The I2C routines ; are intended to be demonstrative and transportable into different ; application scenarios, and were NOT optimized for speed and/or memory ; utilization. ; ; Yoram Arbel $TITLE(83C751 83C751 Multi Master I2C Routines) $DATE(4/14/1992) $MOD751 MOD751 $DEBUG ;* ; 8XC751 8XC751 MULTIMASTER I2C COMMUNICATIONS ROUTINES ; Symbols and RAM definitions ;* ; Symbols (masks) for I2CFG bits. BTIR BMRQ EQU EQU 10h 40h ; TIRUN bit. ; MASTRQ bit. ; Symbols (masks) for I2CON bits. BCXA BIDLE BCDR BCARL BCSTR BCSTP BXSTR BXSTP EQU EQU EQU EQU EQU EQU EQU EQU 80h 40h 20h 10h 08h 04h 02h 01h ; CXA bit. ; IDLE bit. ; CDR bit. ; CARL bit. ; CSTR bit. ; CSTP bit. ; XSTR bit. ; XSTP bit. ; Note: ; ; Specific bits of the I2CON register are set by writing into this register a ; combination of the masks defined above using the MOV command. ; The SETB command should not be used with I2CON, as it is implemented by ; reading the contents of the register, setting the appropriate bit and ; writing it back into the register. As the functionality of the Read and ; Write portions of the I2CON register is different, using SETB may cause ; unwanted results. ; Message transaction status indications in MSGSTAT: SGO EQU 10h ; Started Slave message processing. 4-54 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 0011 0012 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 0013 0014 0020 0021 0022 0023 0024 0030 0032 0020 0000 0001 0002 0024 0024 0025 0026 0027 0028 0029 002A 002B 002F 0033 0004 1992 Jun 26 AN430 AN430 4/14/1992 SRCVD SRLNG EQU EQU 11h 12h STXED SRERR EQU EQU 13h 14h MGO MRCVED EQU EQU 20h 21h MTXED EQU 22h MTXNAK EQU 23h MTXNOSLV EQU 24h TIMOUT NOTSTR EQU EQU 30h 32h PAGE 2 ; as a slave, received a new message ; received as slave a message which is too ; long for the buffer ; as slave, completed message transmission. ; bus error detected when operating as a slave. ; Started Master message processing. ; As Master, received complete message from ; slave. ; As Master, completed successful message ; transmission (slave acknowledged all data ; bytes). ; As Master, truncated message since slave did ; not acknowledge a data byte. ; AS Master, did not receive an acknowledgement ; for the specified slave address. ; TIMERI Timed out. ; Master did not recognize Start. ; RAM locations used by I2C interrupt service routines. MASCMD SUBADD RPSTRT SETMRQ DATA BIT BIT BIT 20h MASCMD.0 MASCMD.1 MASCMD.2 DSEG AT 24h MSGSTAT: MYADDR: DESTADRW: DESSUBAD: MASTCNT: DS DS DS DS DS 1 1 1 1 1 ; I2C communications status. ; Address of this I2C node. ; Destination address + R/W (for Master). ; Destination subaddress. ; Number of data bytes in message (Master, ; send or receive). TITOCNT: StackSave: DS DS 1 1 ; Timer I bus watchdog timeouts counter. ; SP save location (used when returning from ; bus recovery routine). MasBuf: SRcvBuf: STxBuf: DS DS DS 4 4 4 ; Master receive/transmit buffer, 8 bytes. ; Slave receive buffer, 8 bytes. ; Slave transmit buffer, 8 bytes. RBufLen EQU 4h ; The length of SRcvBuf 4-55 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 0090 0091 0093 0021 0008 0009 0037 0038 ­­­­ 0000 4178 001B 001B D2DD 001D 4111 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 AN430 AN430 4/14/1992 PAGE 3 ;* ; APPLICATION output pins and RAM definitions ;* ; Outputs used by the application: TogLED BIT P1.0 ErrLED BIT P1.1 ; Toggling output pin, to confirm ; that the ping­pong game proceeds fine. ; Error indication. OnLED BIT P1.3 ; ; Application RAM APPFLAGS DATA 21h TRQFLAG BIT APPFLAGS.0 ; Flag for monitoring I2C transmission success. SErrFLAG BIT APPFLAGS.1 FAILCNT: DS 1 TOGCNT: DS 1 ; Toggle counter. ;* ; ; Program Start ; ;* CSEG ; Reset and interrupt vectors. AJMP Reset ;Reset vector at address 0. ; A timer I timeout usually indicates a 'hung' bus. ORG TimerI: AJMP 1Bh SETB TIISR ; Timer I (I2C timeout) interrupt. CLRTI ; Go to Interrupt Service Routine. ;* ; I2C Interrupt Service Routine ;* ; ; Notes on the interrupt mechanism: ; ; Other interrupts are enabled during this ISR upon return from XRETI. ; Limitations imposed on other ISR's: 4-56 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 0023 0023 C2AC 0025 114C 0027 C0D0 0029 C0E0 002B E8 002C C0E0 002E E9 002F C0E0 0031 EA 0032 C0E0 0034 85812A 0037 C2DC 0039 D2DC 003B 209A09 209A09 003E 30990C 30990C 0041 752420 0044 209B76 209B76 0047 752432 004A 21AE 004C 32 004D 752410 0050 31E2 0052 309D5E 309D5E 0055 A2E0 0057 C2E0 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 AN430 AN430 4/14/1992 PAGE 4 ; ­ Should not be long (close to 1000 clock cycles). A long ISR will cause ;the I2C bus to 'hang", and a TIMERI interrupt to occur. ; ­ Other interrupts either do not use the same mechanism for allowing ;further interrupts, or if they do ­ disable TIMERI interrupt beforehand. ; ; The 751 hardware allows only one level of interrupts. We simulate an ; additional level by software: by performing a RETI instruction (at location ; XRETI) the interrupt­in­progress flip­flop is cleared, and other interrupts ; are enabled. The second level of interrupt is a must in our implementation, ; enabling timeout interrupts to occur during "stuck" wait loops in the I2C ; interrupt service routine. ORG 23h I2CISR: ACALL PUSH PUSH MOV PUSH MOV PUSH MOV PUSH CLR XRETI PSW ACC A,R0 ACC A,R1 ACC A,R2 ACC MOV CLR SETB StackSave, SP TIRUN TIRUN JB JNB MOV JB NoGo: AJMP STP,NoGo MASTER, GoSlave MSGSTAT,#MGO STR,GoMaster MOV MSGSTAT,#NOTSTR Dismiss ; Not a valid Start. XRETI: RETI EI2 ; Disable I2C interrupt. ; Allow other interrupts to occur. ;* ; Main Transmit and Receive Routines ;* ; ; SLAVE CODE ­ GET THE ADDRESS GoSlave: AddrRcv: JNB MOV MSGSTAT,#SGO ACALL ClsRcv8 DRDY, SMsgEnd ; Must be some strange Start or Stop ; before the address byte was completed. ; Not a valid address. MOV C,ACC.0 ; Save R/W~ bit in carry. ACC.0 ; Clear that bit, leaving "raw" address STstRW: CLR 4-57 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 0059 6060 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 005B 4027 005D B5255B B5255B 0060 792F 0062 7A05 0064 8002 0066 F7 0067 09 0068 31ED 006A 309D09 309D09 006D DAF7 006F 752412 0072 7110 0074 8045 0076 B8072E B8072E 0079 752411 007C E9 007D C3 007E 942F 0080 51EF 0082 802F 1992 Jun 26 JZ GoIdle AN430 AN430 4/14/1992 PAGE 5 ; If it is a General Address ; ­ ignore it. ; NOTE: ; One may insert here a different ; treatment for general calls, if ; these are relevant. JC SlvTx ; It's a Read ­ (requesting slave ; transmit). ; It is a Write (slave should receive the message). ; Check if message is for us SRcv2: CJNE MOV MOV SJMP R1,#SRcvBuf R2,#RbufLen+1 SRcv3 SRcvSto: Inc SRcv3: JNB DJNZ MOV @R1,A ; Store the byte R1 ; Step address. ACALL AckRcv8 DRDY,SRcvEnd ; Exit loop ­end reception. R2,SRcvSto ; Go to store byte if buffer not full. MOV ACALL SJMP A,MYADDR,GoIdle ; If not my address ­ ignore the ; message. ; Set receive buffer address. ; ; Too many bytes received ­ do not acknowledge. MSGSTAT,#SRLNG ; Notify main that (as slave) we ; have received too long a message. SLnRCvdR ; Handle new data ­ slave event routine. GoIdle ; Received a byte, but not DRDY ­ check if a legitimate message end. SRcvEnd: CJNE R0,#7,SRcvErr ; If bit count not 7, it was not ; a Start or a Stop. ; Received a complete message MOV MSGSTAT,#SRCVD MOV CLR SUBB ACALL SJMP A,R1 C A,#SRcvBuf SRCvdR SMsgEnd ; Calculate number of bytes received ; number of bytes in ACC ; Handle new data ­ slave event routine. 4-58 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 0084 00 0085 B52533 B52533 0088 759900 008B 309EFD 309EFD 008E 309D22 309D22 0091 7933 0093 E7 0094 09 0095 31CE 0097 309D19 309D19 009A 309FF6 309FF6 009D 759860 00A0 752413 00A3 7110 00A5 21AE 00A7 752414 00AA 7110 00AC 8005 00AE 752414 00B1 7110 00B3 209903 00B6 209B94 209B94 00B9 00B9 21AE 00BB 00BB 21AE 00BD 00BD 792B 00BF AA28 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 AN430 AN430 4/14/1992 PAGE 6 ; It is a Read message, check if for us. SlvTx: NOP STx2: MOV JNB JNB MOV STxlp: INC ACALL JNB JNB MOV MOV ACALL AJMP CJNE A,MYADDR,GoIdle ; Not for us. I2DAT,#0 ; Acknowledge the address. ATN,$ ; Wait for attention flag. DRDY,SMsgEnd ; Exception ­ unexpected Start ; or Stop before the Ack got out. R1,#STxBuf ; Start address of transmit buffer. MOV A,@R1 ; Get byte from buffer R1 XmByte DRDY,SMsgEnd ; Byte Tx not completed. RDAT,STxlp ; Byte acknowledge, proceed trans. I2CON,#BCDR+BIDLE ; Master Nak'ed for msg end. MSGSTAT,#STXED STXedR ; Slave transmitted event routine. Dismiss SRcvErr: ACALL SJMP StxErr: ACALL MOV MSGSTAT,#SRERR SRErrR SMsgEnd MOV MSGSTAT,#SRERR SRErrR SMsgEnd: JB SMsgEnd2: AJMP JB MASTER,SMsgEnd2 STR,GoSlave ; Flag bus/protocol error ; Slave error event routine. ; Flag bus/protocol error ; If it was a Start, be Slave Dismiss ; End of Slave message processing GoIdle: AJMP Dismiss ; ; GoMaster: ; Send address & R/W~ byte MOV MOV R1,#MasBuf R2,MASTCNT ; Master buffer address ; # of bytes, to send or rcv 4-59 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 00C1 E526 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 00C3 200012 00C6 31C5 00C8 309D03 309D03 00CB 309C02 309C02 00CE 2186 00D0 209F5C 209F5C 00D3 20E063 20E063 00D6 211A 00D8 00 00D9 C2E0 00DB 31C5 00DD 309D03 309D03 00E0 309C02 309C02 00E3 2186 00E5 209F47 209F47 00E8 E527 00EA 31CE 00EC 309DCA 309DCA 00EF 209CC7 209CC7 00F2 209F3F 209F3F 00F5 E526 00F7 30E020 30E020 00FA 759822 00FD 309EFD 309EFD 0100 759820 0103 309EFD 309EFD 0106 309C02 309C02 0109 2182 010B 31C5 010D 309D03 309D03 0110 309C02 309C02 0113 2186 0115 209F17 209F17 0118 801F 1992 Jun 26 AN430 AN430 4/14/1992 MOV A,DESTADRW JB SUBADD,GoMas2 ACALL XmAddr JNB JNB GM2: DRDY,GM2 ARL,GM3 AJMP AdTxArl GM3: JB AJMP JB RDAT,Noslave ACC.0, MRcv MTx PAGE 7 ; Destination address (including ; R/W~ byte). ; Branch if subaddress is needed. ; Arbitration loss while transmitting ; the address. ; No Ack for address transmission. ; Check R/W~ bit ; Handling subaddress case: GoMas2: CLR ACALL JNB JNB GM4: NOP ACC.0 XmAddr DRDY,GM4 ARL,GM5 AJMP AdTxArl ; the address. ; Subaddress needed. Address in ACC. ; Force a Write bit with address. GM5: MOV ACALL JNB JB JB MOV JNB JB RDAT,Noslave A,DESSUBAD XmByte DRDY,SMsgEnd2 ARL,SMsgEnd2 RDAT,NoAck A,DESTADRW ACC.0, MTx ; by sending the data. ; No Ack for address transmission. ; Arbitration loss while transmitting ; Transmit subaddress. ; Arbitration loss (by Start or Stop) ; Arbitration loss occurred. ; Subaddress transmission was not ack'ed. ; Reload ACC with address. ; It's a Write, so proceed ; Read message, needs rp. Start and add. retransmit. MOV JNB MOV I2CON,#BCDR+BXSTR ATN,$ I2CON,#BCDR JNB JNB AJMP GM6: ATN,$ ARL,GM6 MArlEnd ACALL XmAddr JNB JNB GM7: DRDY,GM7 ARL,GM8 AJMP AdTxArl GM8: SJMP JB MRcv ; A Write message. RDAT,Noslave ; Send Repeated Start. ; Clear useless DRDY while preparing ; for Repeated Start. ; expecting an STR. ; oops ­ lost arbitration. ; Retransmit address, this time with the ; Read bit set. ; Arbitration loss while transmitting ; the address. ; No Ack ­ the slave disappeared. ; Proceed receiving slave's data. Master transmits the data. 4-60 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 011A 00 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 011B E7 011C 09 011D 31CE 011F 309D97 309D97 0122 209C94 209C94 0125 209F0C 209F0C 0128 DAF1 012A 752422 012D 8025 012F 752424 0132 8020 0134 752423 0137 801B 0139 31F6 013B 8002 013D 31ED 013F 309D39 309D39 0142 F7 0143 09 0144 DAF7 0146 759980 0149 309EFD 309EFD 014C 309D2C 309D2C 014F 752421 0152 8000 0154 300105 0157 759822 015A 8007 015C A202 015E 92DE 0160 759821 1992 Jun 26 AN430 AN430 4/14/1992 MTx: NOP MTxLoop: INC ACALL JNB JB JB DJNZ MOV A,@R1 R1 XmByte DRDY,SMsgEnd2 ARL,SMsgEnd2 RDAT,NoAck R2,MTxLoop ; Get byte from buffer. ; Step the address. MOV MSGSTAT,#MTXED ; Report completion of buffer ; transmission. SJMP NoSlave: SJMP NoAck: SJMP PAGE 8 MTxStop MOV MSGSTAT,#MTXNOSLV MTxStop MOV MSGSTAT,#MTXNAK MTxStop ; Arbitration loss (by Start or Stop) ; Arbitration loss. ; Loop if more bytes to send. ; Master receive ­ a Read frame MRcv: SJMP MRcvLoop: MRcv2: MOV INC DJNZ ACALL ClaRcv8 MRcv2 ACALL AckRcv8 JNB DRDY,MArl @R1,A R1 R2,MRcvLoop ; Receive a byte. ; Other's Start or Stop. ; Store received byte. ; Advance address. ; Received the desired number of bytes ­ send Nack. MOV JNB JNB MOV SJMP I2DAT,#80h ATN,$ DRDY,MArl MSGSTAT,#MRCVED MTxStop ; Go to send Stop or Repeated Start. ; Conclude this Master message: ; Send Stop, or a Repeated Start MTxStop: JNB RPSTRT,MTxStop2 MOV SJMP MTxStop2: MOV I2CON,#BCDR+BXSTR MTxStop3 MOV C,SETMRQ MASTRQ,C MOV I2CON,#BCDR+BXSTP 4-61 ; Check if Repeated Start needed ; Around if not RPSTRT. ; Send Repeated Start. ; Set new Master Request if demanded ; by SETMRQ bit of MASCMD. ; Request the HW to send a Stop. Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 0163 309EFD 309EFD 0166 759820 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 0169 309EFD 309EFD 016C 209C13 209C13 016F 7112 0171 30DE05 30DE05 0174 309B02 309B02 0177 01BD 0179 0179 8033 017B 017B 309B02 309B02 017E 014D 0180 0180 21AE 0182 0182 D2DE 1992 Jun 26 MTxStop3: MOV 4/14/1992 JNB ATN,$ I2CON,#BCDR JNB JB ATN,$ ARL,MarlEnd ; Wait for Attention ; Clear the useless DRDY, generated ; by SCL going high in preparation ; for thr Stop or Repeated Start. ; Wait for ARL, STP or STR. ; Lost arbitration trying to send ; Stop or a ReStart. ; Master is done with this message. ; or exit. ACALL AN430 AN430 May proceed with new messages, if any, MastNext ; Master Event Routine. May Prepare ; the pointers and data for the next Master message. ; JNB MASTRQ,MMsgEnd ; Go end service routine if MASTRQ ; does not indicate that the master ; should continue (was set according ; to SETMRQ bit, or by MastNext). JNB STR,MMsgEnd AJMP GoMaster ; ; Return from the ISR, unless Start ; (avoid danger if we do not return: ; if there was a Stop, the watchdog ; is inactive until next Start). ; Loop for another Master message MMsgEnd: SJMP ; End of Master messages, Dismiss ; Terminate mastership due to an arbitration loss: MArl: JNB STR,MArl2 AJMP GoSlave Marl2: AJMP ; If lost arbitration due to other ; Master's Start, go be a slave. Dismiss ; Switch from Master to Slave due to arbitration loss after completing ; transmission of a message. The MASTRQ bit was cleared trying to write a ; Stop, and we need to set it again on order to retry transmission when the ; bus gets free again. MArlEnd: SETB MASTRQ ; Set Master Request ­ which will get ; into effect when we are done as a ; slave. 4-62 PAGE 9 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 0184 217B 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 0186 209BF2 209BF2 0189 209AEF 209AEF 018C B80003 B80003 018F 14 0190 8012 0192 0192 03 0193 F9 0194 E8 0195 9001A6 9001A6 0198 93 0199 59 019A 759890 019D 5108 019F 209D02 209D02 01A2 01B3 01A4 0155 01A6 FF7E3E1E 01AA 0E060200 0E060200 01AE 711E 01B0 7598F4 7598F4 01B3 C2DC 01B5 D0E0 01B7 FA 01B8 D0E0 1992 Jun 26 517 518 519 520 521 522 523 524 525 526 AJMP AN430 AN430 4/14/1992 MArl ; Handling arbitration loss while transmitting an address AdTxArl: JB JB STR,MArl STP,MArl ; Non­synchronous Start or Stop. ; Switch from Master to Slave due to arbitration loss while transmitting ; an address ­ complete receiving the address transmitted by the new Master. CJNE R0,#0,AdTxArl2 ; Arl on last bit of address ; (R0 is 0 on exit from XmAddr). ; The lsb sent, in which arl occured ; must have been 1. By decrementing ; A we get the address that won. DEC A SJMP AdAr3 AdTxArl2: RR MOV MOV MOV MOVC ANL A R1,A A,R0 DPTR,#MaskTable A,@A+DPTR A,R1 ; Realign partially Tx'ed ACC ; and save it in R1 ; Pointer for lookup table MOV I2CON,#BCXA+BCARL ; Clear flags and release the clock. ACALL RBit3 JB AJMP DRDY,AdAr3 SMsgEnd AdAr3: AJMP STstRW ; Complete the address using reception ; subroutine. ; Around if received address OK ; Unexpected Start or Stop ­ end ; as a slave. ; Proceed to check the address ; as a slave. MaskTable: DB 0ffh,7Eh,3Eh,1Eh,0Eh,06h,02h,00h, ; 0ffh is dummy ; Set address bits to be received, ; and the bit on which we lost ; arbitration to 0 ; Now we are ready to receive the rest ; of the address. ; End I2C Interrupt Service Routine: Dismiss: ACALL I2CDONE MOV CLR POP MOV POP I2CON,#BCARL+BCSTP+BCDR+BCXA+BIDLE TIRUN ACC R2,A ACC 4-63 PAGE 10 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 01BA F9 01BB D0E0 01BD F8 01BE D0E0 01C0 D0D0 01C2 D2AC 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 01C4 22 01C5 F599 01C7 75981C 75981C 01CA 7808 01CC 8004 01CE 7808 01D0 F599 01D2 23 01D3 309EFD 309EFD 01D6 309D08 309D08 01D9 D8F5 01DB 7598A0 7598A0 01DE 309EFD 309EFD 01E1 22 01E2 75989C 75989C 01E5 309EFD 309EFD 01E8 309D22 309D22 1992 Jun 26 AN430 AN430 4/14/1992 MOV POP MOV POP POP SETB R1,A ACC R0,A ACC PSW EI2 RET PAGE 11 ; Return from I2C interrupt Service Routine ;* ; Byte Transmit and Receive Subroutines ;* ; ; XmAddr: Transmit Address and R/W~ XmByte: Transmit a byte XmAddr: MOV MOV I2DAT,A I2CON,#BCARL+BCSTR+BCSTP MOV SJMP XmByte: XmBit: XmBit2: JNB JNB DJNZ MOV JNB R0,#8 XmBit2 MOV R0,#8 MOV I2DAT,A RL A ATN,$ DRDY,XmBex R0,XmBit I2CON,#BCDR+BCXA ATN,$ XmBex: RET ; Send first bit, clears DRDY. ; Clear status, release SCL. ; Set R0 as bit counter ; Send the first bit. ; Get next bit. ; Wait for bit sent. ; Should be data ready. ; Repeat until all bits sent. ; Switch to receive mode. ; Wait for acknowledge bit. ; flag cleared. ; ; Byte receive routines. ; ; ClsRcv8 clears the status register (from Start condition) ; and then receives a byte. ; AckRcv8 Sends an acknowledge, and then receives a new byte. ; If a Start or Stop is encountered immediately after the ; ack, AckRcv8 returns with 7 in R0. ; ClaRcv8 clears the transmit active state and releases clock ; (from the acknowledge). ; ; A contains the received byte upon return. ; R0 is being used as a bit counter. ; ClsRcv8: MOV I2CON,#BCARL+BCSTR+BCSTP+BCXA ;Clear status register. JNB ATN,$ JNB DRDY,RCVex 4-64 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 01EB 800F 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 01ED 759900 01F0 309EFD 309EFD 01F3 309D18 309D18 01F6 7598A0 7598A0 01F9 309EFD 309EFD 01FC 7807 01FE E4 01FF 4599 0201 23 0202 309EFD 309EFD 0205 309D05 309D05 0208 D8F5 020A A29F 020C 33 020D 22 020E 7809 0210 22 0211 C2DE 0213 759801 0216 7598BC 7598BC 0219 752430 021C 74FF 021E B52902 B52902 0221 8002 0223 0529 0225 5130 0227 D2DD 0229 114C 022B 852A81 852A81 1992 Jun 26 AN430 AN430 4/14/1992 SJMP Rcv8 AckRcv8: JNB JNB ClaRcv8: MOV I2DAT,#0 ATN,$ DRDY,RCVerr MOV I2CON,#BCDR+BCXA JNB ATN,$ Rcv8: MOV CLR RBit: RBit2: JNB JNB A ORL A,I2DAT RL A ATN,$ DRDY,RCVex RBit3: MOV RLC RCVex: DJNZ C,RDAT A RET R0,RBit RCVerr: RET MOV R0,#9 PAGE 12 R0,#7 ; Send Ack (low) ; Bus exception ­ exit. ; clear status, release clock ;from writing the Ack. ; Set bit counter for the first seven ; bits. ; Init received byte to 0. ; Get bit, clear ATN. ; Shift data. ; Wait for next bit. ; Exit if not a data bit (could be Start/ ; Stop, or bus/protocol error) ; Repeat until 7 bits are in. ; Get last bit, don't clear ATN. ; Form full data byte. ; Return non legitimate bit count ;* ; Timer I Interrupt Service Routine ; I2C us Timeout ;* ; In addition to reporting the timeout in MSGSTAT, we update a failure ; counter, TITOCNT. This allows different types of timeout handling by the ; main program. TIISR: MOV MOV CLR MASTRQ ; "Manual" reset. I2CON,#BXSTP ; I2CON,#BCXA+BCDR+BCARL+BCSTR+BCSTP TI1: TI2: CJNE SJMP TI3: MOV MSGSTAT,#TIMOUT MOV A,#0FFh A,TITOCNT,TI3 TI4 INC TITOCNT TI4: ACALL SETB ACALL CLRTI XRETI MOV SP,StackSave ; Status Flag for Main. ; Increment TITOCNT, saturating ; at FFh. RECOVER ; Clear TI interrupt flag. ; Clear interrupt pending flag (in ; order to re­enable interrupts). ; Realign stack pointer, re­doing ; possible stack changes during ; the I2C interrupt service routine. 4-65 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 022E 21AE 0230 C2AF 0232 C2DE 0234 7598FC 7598FC 0237 C2DF 0239 D2DC 023B 79FF 023D 00 023E 00 023F 00 0240 D9FB 0242 C2DC 0244 D2DD 0246 D280 0248 D281 024A 7908 024C C280 024E 00000000 0252 00 0253 D280 0255 00000000 0259 00 025A D9F0 025C C280 025E 0000 0260 C281 0262 0000 0264 D280 0266 00000000 026A 00 026B D281 026D 00000000 0271 00 0272 7598BC 7598BC 0275 D2AF 0277 22 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 AJMP AN430 AN430 4/14/1992 PAGE 13 ; TimerI interrupts in other ISR's ; were not allowed ! Dismiss ; Go back to the I2C service routine, ; in order to return to the (main) ; program interrupted. ;* ; Bus recovery attempt subroutine ;* RECOVER: CLR MOV CLR SETB MOV DLY5: NOP NOP DJNZ CLR SETB CLR EA MASTRQ ; "Manual" reset. I2CON,#BCXA+BIDLE+BCDR+BCARL+BCSTR+BCSTP SLAVEN ; Non I2C TimerI mode TIRUN ; Fire up TimerI. When it overflows, it ; will cause I2C interface hardware reset. R1,#0ffh NOP R1,DLY5 TIRUN CLRTI SETB SETB MOV RC7: DB SCL SDA R1,#08h CLR 0,0,0,0,0 663 664 SETB DB SCL 0,0,0,0,0 665 666 667 668 669 670 671 DJNZ CLR DB CLR DB SETB DB R1,RC7 SCL 0,0 SDA 0,0 SCL 0,0,0,0,0 672 673 SETB DB SDA 0,0,0,0,0 674 675 676 677 678 Rex: SETB RET MOV EA ; Issue clocks to help release other devices. SCL ; Issue a Stop. I2CON,#BCXA+BCDR+BCARL+BCSTR+BCSTP ; clear flags 4-66 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 0278 758107 027B E4 027C 90032D 90032D 027F 93 0280 F5D8 0282 E4 0283 90032C 90032C 0286 93 0287 F525 0289 C293 028B C291 028D 51E6 1992 Jun 26 83C751 83C751 Multimaster I2C Routines 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 AN430 AN430 4/14/1992 PAGE 14 ;* ; ; Main Program ; ;* ; Message ping pong game. Each message is transmitted by ; a processor that is a master on the I2C bus, and it contains one byte ; of data. A processor that receives this data byte as a slave increments ; the data by one and transmits it back as a master. The data received is ; confirmed to be a one increment of the data formerly sent, unless ; it is a "reset" value, chosen to be 00h. ; The two participating processors have similar code, where the node ; address of the second processor is the destination address of this ; one, and vice versa. ; The first data byte each processor tries to send is 00h. One of the ; processors will acquire the bus first, and the second processor that will ; receive this "resetting" 00h will not attempt to confirm it against an ; expected value. It will simply increment and transmit it. Subsequent ; receptions will be confirmed against the expected value, until 0ffh data ; bytes are sent and the game is effectively reset by the 00h resulting from ; the next increment. ; A toggling output (TogLED) tells the outer world that the "ping pong" ; proceeds well. If something unexpected happens we temporarily activate ; another output, ErrLED. ; The different tasks of the code are performed in a combination of main­ ; line program and event routines called from the I2C interrupt service ; routine. ; Initial set­ups: ; Load CT1,CT0 bits of I2CFG register, according to the clock ; crystal used. ; Load RAM location MYADDR with the I2C address of this processor. ; We load these values out of ROM table locations (R_CTVAL and R_MYADDR). ; One may, instead, load with a MOV command. Reset: CLR MOV MOVC MOV CLR MOV MOVC MOV MOV SP,#07h ;Set stack location. A DPTR,#R_CTVAL A,@A+DPTR I2CFG,A ; Load CT1,CT0 (I2C timing, crystal ; dependent). A DPTR,#R_MYADDR A,@A+DPTR ; Get this node's address from ROM table MYADDR,A ; into MYADDR RAM location. CLR OnLED Reset2: ACALL CLR ErrLED ; Flash LED. LDELAY 4-67 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 028F D291 0291 C209 0293 C208 0295 753750 0298 D290 029A 753850 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 029D 759840 02A0 D2DF 02A2 D2AB 02A4 D2AC 02A6 D2AF 02A8 752000 02AB 90032E 90032E 02AE E4 02AF 93 02B0 F526 02B2 752801 02B5 02B5 752B00 752B00 02B8 02B8 D208 02BA D2DE 02BC 79FF 02BE 300809 02C1 D9FB 02C3 D537F2 D537F2 02C6 5130 02C8 80C1 02CA 78FF 02CC 79FF 02CE 2008E7 2008E7 02D1 200908 02D4 D9F8 02D6 D8F4 02D8 5130 1992 Jun 26 SETB CLR CLR MOV SETB MOV ErrLED SErrFLAG TRQFLAG FAILCNT,#50h TogLED TOGCNT,#050h AN430 AN430 4/14/1992 ; Initialize pin­toggling counter ; Enable slave operation. ; The Idle bit is set here for a restart situation ­ in normal ; operation this is redundant, as this bit is set upon power_up reset. MOV I2CON,#BIDLE ; Slave will idle till next Start. SETB SLAVEN ; Enable slave operation. ; Enable interrupts. ; This is necessary for both Slave and Master operations. SETB ETI ; Enable timer I interrupts. SETB EI2 ; Enable I2C port interrupts. SETB EA ; Enable global interrupts. ; Set up Master operation. MOV MOV CLR MOVC MOV MOV MASCMD,#0h ; "Regular" master transmissions. DPTR,#PongADDR A A,@A+DPTR DESTADRW,A ; The partner address. The LSB is ; low, for a Write transaction. MASTCNT,#01h ; Message length ­ a single byte. PPSTART: MOV MasBuf,#00h ; "Ping" transmission: PP2: SETB SETB MOV PP22: DJNZ MFAIL1: ACALL SJMP TRQFLAG MASTRQ R1,#0ffh JNB TRQFLAG,PP3 R1,PP22 DJNZ FAILCNT,PP2 RECOVER Reset2 ; Transmitted OK ; "Pong" reception: PP3: PP31: PP32: JB DJNZ DJNZ PPTO: MOV R0,#0ffh MOV R1,#0ffh JB TRQFLAG,PP2 SErrFLAG,PP5 R1,PP32 R0,PP31 ACALL RECOVER 4-68 ; Software timeout loop count. ; Rcvd ok as slave, go transmit. ; Software timeout. PAGE 15 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 02DA 418B 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 02DC C291 02DE 51E6 02E0 D291 02E2 C209 02E4 41B5 02E6 7A30 02E8 79FF 02EA D9FE 02EC DAFA 02EE 22 02EF 00 02F0 E52F 02F2 7005 02F4 752B01 752B01 02F7 800F 02F9 052B 02FB B52B0F B52B0F 02FE 052B 1992 Jun 26 AN430 AN430 4/14/1992 AJMP Reset2 PP5: ACALL SETB CLR AJMP CLR ErrLED ; Receive error. LDELAY ErrLED SErrFLAG PPSTART LDELAY: LDELAY1: DJNZ DJNZ RET PAGE 16 MOV R2,#030h MOV R1,#0ffh R1,$ R2,LDELAY1 ;* ; Slave and Master Event Routines. ;* ; ;Invoked upon completion of a message transaction. ;This is the part of the application program actually dealing ;with the data communicated on the I2C bus, by responding to ;new data received and/or preparing the next transaction. ; Slave Event Routines ; ; These routines are invoked by the I2C interrupt service routine when a ; message transaction as a slave has been completed. Our "application" ; reacts to a message received as a slave with the routine SRCvdR. ; The calls that indicate erroneous reception are treated the same way as ; erroneous data reception in the "ping pong" game. ;SRcvdR ;Invoked when a new message has been received as a Slave. SRcvdR: MOV JNZ MOV SJMP NOP A,SRcvBuf SR2 MasBuf,#01h SR3 SR2: CJNE INC INC MasBuf ; The expected data. A,MasBuf,ErrSR MasBuf ; Data for next transmission ­ the data ; received incremented by 1. ; It was ping­pong reset value ;A successful two way data exchange. Let the outside world know by ;toggling an output pin driving a LED. We actually toggle only ;when a number of such exchanges is completed, in order to ;slow down the changes for a good visual indication. 4-69 Philips Semiconductors Application note Using the 8XC751/752 8XC751/752 in multimaster I2C applications PPCODE1 83C751 83C751 Multimaster I2C Routines 0300 D53805 D53805 0303 B290 0305 753850 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 0308 C209 030A D208 030C 22 030D D209 030F 22 0310 0310 0310 80FB 0312 0312 E524 0314 B42206 B42206 0317 753750 031A C208 031C 22 031D 031D 22 1992 Jun 26 4/14/1992 DJNZ CPL MOV TOGCNT,SR3 TogLED TOGCNT,#050h SR3: SETB RET CLR SErrFLAG TRQFLAG ; Request main to transmit ErrSR: RET SETB ; Toggle output ; SErrFLAG ;SLnRcvdR ;Invoked when a message received as a Slave is too long ;for the receive buffer. ;STXedR ;Invoked when a Slave completed transmission of its buffer. ;We do not expect to get here, since we do not plan to have ;in our system a master that will request data from this node. ; ;SRErrR ;Slave error event subroutine. ;In most applications it will not be used. ; SLnRcvdR: STXedR: SRErrR: JMP ErrSR ; ;MastNext ­ Master Event Routine. ; ;Invoked when a Master transaction is