Characterization of I2C? Based Network Implementation

0 Mirror Page

Due to a problem with TWiki I cannot seem to be able to upload any file. Hence, I have created a mirror page under my own web site which can be accessed here. It is password protected. The u$ername is "risetelecon" and the pa$$word is the same with that of the rhextelecon.

1 Introduction

This page summarizes the results of an evaluation study aiming to characterize the limitations of I2C? as a link layer interface. We introduce a prototype benchtop setup in Section 2 followed by a detailed investigation of bandwidth limitations in Section 3.

2 Benchtop Evaluation Setup

The prototype RiseBus is composed of 8 network nodes: 1 master; and 7 slaves. The slave nodes are implemented using the protoERiSE-300 boards utilizing Cygnal C8051F300? MCU while the master node is an evaluation board from Cygnal Integrated Products. Both of these systems are electrically identical. Figure 1 illustrates a picture of this setting.

• Figure 1. Prototype RiseBus setting for benchtop evaluations.

The data (SDA) and clock (SCL) lines of the I2C? bus are passively terminated by pull-up resistors of 220 ohms. The physical bus is a 4-wire flat cable of 50cm length. Along the bus at equal distance socket connectors are installed to attach nodes.

3 Bandwidth

The bandwidth of the data network is determined by the maximum clock frequency of the I2C? peripheral interface. According to C8051F30x? datasheet SCL rate can be set to 1/10th of the system clock whose maximum is 25MHz. However, in experiments I observed that the clock vanishes if the clock rate is set above ~1.5MHz. Figure 2. shows a typical SCL clock operating at 1.34 MHz.

• Figure 2. Typical SCL signal. Clock rate is 1.34 MHz.

There are two types of overhead that reduces the effective bandwidth of the bus: 1) the I2C? protocol signaling (ACK, NACK, STA, STO) overhead; and 2) ISR execution overhead. For the following explanations we will refer to Figure 3-6 where the top plot is the IC2 clock (SCL) and the bottom plot is a debugging signal indicating the start and end of a particular sections of the ISR routine. Refer to the individual captions to determine debugging signal assignment.

• Figure 3. Master-to-Slave transmission. Debugging signal goes high when the master receives acknowledgement from the slave and goes low when the master transmits the next byte to in the outgoing buffer.
• Figure 4. Slave-to-Master. Debugging signal goes high when the master receives a new data byte from slave and goes low when the master buffers the data and sends out the acknowledgement.
• Figure 5. Slave-to-Master. Debugging signal goes high when the slave receives an acknowledgement from the master and goes low when the slave transmits the next byte in the outgoing buffer.
• Figure 6. Master-to-Slave. Debugging signal goes high when the slave receives a new data byte and goes low when the slave buffers the data and sends out an acknowledgement.

The I2C? link layer protocol hand shaking method introduces a one bit per byte overhead which is an ACK (byte acknowledged) and/or a NACK (data not acknowledged) signal following each byte transmission. This can be seen in Figure 3-6 as the single clock in between transmission of two bytes.

The I2C? peripheral interrupt service routine (ISR) of a node requires some time to process the incoming byte and/or signal and send out the proper response. You can download the flow diagram of the ISR and the the source code for detailed information. A rough calculation based on the flow diagram yields the number of clock cycles required by the four main modes of ISR execution as listed in Table 1. Direct measurments for the same intervals from experimental data shown in Figure 3-6 can also be found in the same table. The number of cycles is given as a sum of the basic ISR overhead (32 cycles) and additional process required by each mode. The system clock is assumed to be the factory default, 24.5MHz.

Table 1. Execution time for the basic modes of the I2C? ISR

Based on the figures in Table 1 there is a roughly 4usec overhead per byte. Note that independent of the I2C? clock rate the ISR overhead delay will stay constant. At 1.5MHz SCA rate a 9-bits I2C? packet takes 6usec which leads to a 60% channel utilization when all the software overhead is taken into account.

The raw bit rate of the bus under these conditions is roughly 800Kbits/sec. Increasing the SCA rate will improve the raw bandwidth but the incremental improvement will decrease as the SCA rate increases since the channel utilization will be decreasing due to the constant ISR overhead.

Figure 7 illustrates a measurement from the evaluation setup where a 3 byte package is being transmitted from the master to the slave. Diving the total number of bits in this package (24) by the total time it takes (29.4 usec) yields roughly 816Kbits/sec.

• Figure 7. An I2C? package containing: 1 address R/W byte; and two data bytes. The total transmission time is indicated on the lower right corner.