Strobe-to-Busy timing variations

There are two Strobe-to-Busy timing variations in general usage. These two variations typically differ in which edge of the Strobe pulse is considered to be the “active” edge. The common names for these timing variations arise from the appearance of the wave forms. For Busy-while-Strobe timing, the falling (or leading) edge of the Strobe pulse is used to activate Busy. Thus, Busy is usually asserted while Strobe is asserted. For Busy-after-Strobe timing, Busy is activated by the rising (or trailing) edge of Strobe. Here, Busy is asserted only after the Strobe pulse is complete.

These two timing variations are contrasted in the following figures. Busy-while-Strobe is shown in figure C4, and Busy-after-Strobe is shown in figure C5. In both cases, the delay from the active edge of Strobe to the assertion of Busy is indicated by the time “t.” Typical values for Strobe edge to Busy active delays are listed in table C5.

These timing values illustrate the dangers of the occasional but somewhat hazardous use of Busy for data flow control.13 While Busy is asserted upon receipt of a Strobe pulse, this may not happen immediately. (In some cases, assertion of Busy may be deferred indefinitely, such as the second Busy-after-Strobe variant listed in table C5.) Host systems that rely solely on the state of Busy to determine when the next byte can be sent risk losing data. This can occur when the host writes a byte to the interface, looks at Busy and finds it not set, then writes the next byte. If, under these conditions, the printer has not yet set Busy for the first byte, the second data byte will be lost.

The Busy-while-Strobe variant attempts to address this problem by asserting Busy upon receipt of the lead-ing edge of Strobe. While this reduces the probability of encountering problems, it does not eliminate the race condition hazard introduced by hosts relying solely on the state of Busy for flow control. The original Centronics interface was designed around the concept of Strobe/Ack handshaking, and this remains the best method to ensure data transfer integrity.