Developer Home Contents Search Contact Us Support Intel(r)



Understanding SSIO Clock Data Transmissions


Dave Boehmer
Applications Engineer
Intel Corporation

An interesting applications question recently came in which deals with the way the SSIO works. The user observed that the time from data first being placed on the SDx pin to the first clock edge on the SCx pin (data set-up time) varied from transmission to transmission. Since the most-significant bit (MSB) is not changed until the falling edge of SCx, the variable-width MSB resulted in what appeared to be a "delayed clock" as shown in Figure 1.

In order for an SSIO transmission to occur, the SCx and SDx pins must be configured properly and several other conditions must be true. First, the STE bit in the SSIOx_CON register must be set (enabled). Second, the MSB of the SSIO_BAUD register must be set (enabled) and a valid baud rate value must be programmed into the other seven bits. Finally, the user must write the byte to be transmitted to the SSIOx_BUF register -- this is what actually starts the transmission.

By writing a seven-bit value to SSIO_BAUD, the user supplies a count from which the baud rate counter will begin its down-count. On each underflow, the counter is reloaded with the value contained in the control register (SSIO_BAUD) and a flip-flop is clocked that generates the baud clock (SCx pin). When enabled, the baud rate counter is a free-running decrementer.

To initiate a transmission, the user must write to SSIOx_BUF. Since the baud rate counter is free-running, this write can take place at any point during the down-count. If the user happens to write to SSIO_BAUD early in the down-count, the first clock edge will not occur until the first underflow (a long delay). This makes the MSB bit time appear relatively long. If the user should write to SSIO_BAUD late in the down-count, the first clock edge will again not occur until the first underflow (a short delay in this case). This makes the MSB bit time appear relatively short. The "variable MSB" is due to the MSB being driven at SDx asynchronously with respect to the baud count underflow.

For example, consider that the user writes 93H (MSB = enabled, other seven bits = 100 KHz) to SSIO_BAUD. The baud count will start counting down from 13H. If the user writes to SSIOx_BUF when the counter is at 11H, the peripheral will place the MSB on the SDx pin and wait until the counter underflow occurs (generating the first clock pulse). It will take approximately 11H baud rate counter ticks (8.5 s) before the first clock edge is generated. This results in a delayed clock and the MSB being present upon SDx for a relatively long period of time.

If the user writes to SSIOx_BUF when the counter is at 03H, the peripheral will place the MSB on the SDx pin and wait until the counter underflow occurs approximately 3 baud rate counter ticks (1.5 s) later. This results in the MSB being present upon SDx for a relatively short period of time.

This "variable MSB" (or "delayed clock") condition will occur only for the MSB. Once the MSB is clocked out, the second through eighth (LSB) bits are clocked out consistently at the chosen frequency.

Work-Around Suggestion

One way to "stabilize" the time at which the first clock edge occurs (consistent MSB bit length) is to start the down-count at a fixed time whenever a transmission is to take place. This can be done using the following steps:

Using this procedure (rewriting SSIO_BAUD) will result in a MSB set-up time that is consistent due to the clock being started off at a known point prior to each transmission. Interrupts should be disabled during steps 4 and 5 to prevent interrupt servicing time from causing another variable MSB situation.



* Legal Information © 1999 Intel Corporation