Find updates at www.projects.cappels.org

Distinguishing characteristics:
• Compact code and minimal hardware requirements -only two bidirectional I/O lines required
• Bidirectional byte-oriented protocol
• Designed for communication with slave processors that cannot guarantee response time or sampling frequency
• Low pin count

Also see on this site:
DS Interface test tool page
AttoBasic, which supports DS Interface on the larger chips (makes a handy test tool)
ATtiny12 based clock /calendar/alarm chip with EEPROM Interpreter and DS Interface
ATtiny12 3 Channel 8 bit EEPROM DAC with DS Interface

Sample send and receive routines for AVRs (AVR90S2313 and similar processors)

 
Overview

The DS protocol was designed to provide firmware-based bidirectional host-to-slave inter processor communications for situations in which no hardware solution is available and the host and/or the slave in incapable of tending the interface in real time. The only specialized hardware required is two bidirectional I/O ports on each chip (alternatively two input ports and two tri-statable output ports may be used).


Programmer's model:




When read, DS slaves conforming to the interface protocol appear as byte-wide two locations -one register for temporary storage of incoming data and one location for instructions.

Instructions and data are send one byte at a time with each byte preceded by a control bit, which when set, indicates and instructions. A cleared control bit indicates the following byte is data to be held in the Incoming Data Register until a later instruction byte tells the slave what to do with the data byte.

Minimum command set for full implementation

1R Write data to register R

2R Read data from register R

4A Write EEPROM data to memory location A within *current page, for devices with EEPROM.

5A Read EEPROM data from memory location A within *current page, for devices with EEPROM.

80 Read firmware version number in two bytes as [Version],[revision].

 *Note: Assumes a 16 byte page. If there is more than one page of EEPROM, a page addressing mechanism must be defined for the target device.

The use of R and A above indicate register numbers and EEPROM addresses, respectively. F or example, command $1C would write the contents of the Incoming Data Register to register $C in the register set and command $2C would read the contents of that register back to the host. Similarly commands $48 and $58 would write and read EEPROM location 8 in devices that have EEPROM.

Memory other than EEPROM or I/O may be used with the 4A and 5A commands.


Description of protocol

DS messages are sent 9 bits at a time as one byte preceded by a control bit that indicates whether the byte following is meant to be stored in the Incoming Data Register or sent to the Instruction Interpreter. In the flowcharts below, the control bit is located in the carry bit in both the sending and receiving routines. The flowcharts and code on this page were written with the Atmel AVR processors in mind, but should be easily ported to other processors. The communications routines were coded directly from these flow charts.

Sending a byte and control bit via DS.




Receiving a byte and control bit via DS.

The byte-level protocol is, if anything, simple compared to a lot of other protocols. It is included here for completeness.

 
Bit level Protocol:

A single DS bit transaction is shown in the illustration below. The two signal lines involved, Attention and Data, are roughly similar in function to I2C 's SCL and SDA lines respectively. Also similar to I2C , there are passive pull-ups on each line and each chip drives the lines with the equivalent of open-drain outputs. Some microcontrollers have the ability to provide so-called weak pull-ups on their I/O pins, and with these, discreet pull-up resistors may not be needed. Take note that with high resistance pull-up devices or some very "weak" pull-ups, capacitance on the bus might make to too slow, and in some cases, even probing the bus with a high resistance probe might place enough capacitance across it to disturb bus activity.

Data Transfer
At the start of a bit transfer, the sender puts the data bit on the data line. After the data line has been given a chance to settle, the sender pulls the attention line low for some period of time. Periodically, it releases the attention line, waits for the line to settle, then peeks at the line to see if it is being held low by the receiver. If the receiver is holding the line low, to indicate that it has received the data bit, the sender inverts the data line to acknowledge the receiver holding the attention line low. The receive, upon seeing the data line reverse, releases the attention line, and the sender, seeing the attention line being released, releases the data line. That process concludes on bit transfer.

While it is a little bit cumbersome, it is robust in that there is handshaking on each bit that is sent.

Each message is composed of a byte preceded by a flag bit. The purpose of the control bit is to indicate to the slave whether a command or data is being sent. When the flag bit is a logic 1 a command is being sent. When the control bit is a logic 0 data is being sent. This signaling system allows simple register-based interface and command structure to be used. Additional details of the data format are shown in the Data Format section of this document.
DS does not allow more than two devices to be connected to the same interface: one host and one slave. Since there is no mechanism defined for detecting and resolving collisions, the slave may only transmit when requested by the host.

Because of the sampling of the attention line by the sender, there is some uncertainty in the data transfer rate. Without delving into the theory, suffice it to say that some combinations host and slave timing will result in particularly slow data transfer rates -on the order of minutes per byte have been observed. At very high speeds on some hardware data transmission may be unreliable or fail completely. It is therefore a good idea to experiment a little bit and determine a transfer speed that proves reliable. It might be necessary to increase pull-up current in order to achieve high enough data transfer rates. Remember that this interface is intended for applications where transfer speed in not particularly important.

The details of juggling the data direction control bits on bidirectional data ports has been omitted from the flow charts to improve readability.



Data Transfer

At the start of a bit transfer, the sender puts the data bit on the data line. After the data line has been given a chance to settle, the sender pulls the attention line low for some period of time. Periodically, it releases the attention line, waits for the line to settle, then peeks at the line to see if it is being held low by the receiver. If the receiver is holding the line low, to indicate that it has received the data bit, the sender inverts the data line to acknowledge the receiver holding the attention line low. The receive, upon seeing the data line reverse, releases the attention line, and the sender, seeing the attention line being released, releases the data line. That process concludes on bit transfer.

Each message is composed of a byte preceded by a flag bit. The purpose of the control bit is to indicate to the slave whether a command or data is being sent. When the flag bit is a logic 1 a command is being sent. When the control bit is a logic 0 data is being sent. This signaling system allows simple register-based interface and command structure to be used. Additional details of the data format are shown in the Data Format section of this document.

DS does not allow more than two devices to be connected to the same interface: one host and one slave. Since there is no mechanism defined for detecting and resolving collisions, the slave may only transmit when requested by the host.

Because of the sampling of the attention line by the sender, there is some uncertainty in the data transfer rate. Without delving into the theory, suffice it to say that some combinations host and slave timing will result in particularly slow data transfer rates -on the order of minutes per byte have been observed. At very high speeds on some hardware data transmission may be unreliable or fail completely. It is therefore a good idea to experiment a little bit and determine a transfer speed that proves reliable. It might be necessary to increase pull-up current in order to achieve high enough data transfer rates. Remember that this interface is intended for applications where transfer speed in not particularly important.

Below are flow charts illustrating the coding for bit and byte transmit and receive routines. The details of juggling the data direction control bits on bidirectional data ports has been omitted to improve readability.

Sample send and receive routines for ATMs AVR90S2313 and similar processors is included here . This file is also listed at the top of this page under "Downloads".

Routine to send a bit. The code in the listing referenced on this page contains a wait loop to prevent the sending of a bit before the data line is high. That wait loop follows the loop that waits for the Attention line to be high and is not shown on this flow chart.




Routine to receive a bit.

Settling and sampling delays

A delay time is used in the bit level protocol to allow for settling of the attention and data lines and provide adequate time for the attention line to be sampled by the receiving device. Too short of a delay will result in the interface locking up. Too long of a delay will slow things down a lot. There are theoretically some "magic" delays, that depend on the clock rates of the master and salve devices that will result in very long transmission times -these are analogous to beats between harmonics of the sampling rates. The delay values are not critical. Select the delay numbers that provide the fastest robust performance.

 
Avoiding hang-ups

The DS protocol was designed as a means of communications between two integrated circuits on the same circuit board and it can lock up if the attention line is momentarily shorted to ground since both the host and the slave will see this as an attention signal by the other and will each hold the attention line low, each waiting in vain for the other change the state of the data bit. The capacitance of an oscilloscope or logic analyzer probe or even a high resistance voltmeter may be enough to trigger this situation. The chances of this situation developing may be minimized by one of the following precautions:
1. Do not probe the Attention line.

2. Insert a sufficiently large resistor in series with test points for the Attention and Data lines. (it might have to be several megohms).

3. Use sufficiently low resistance pull-up resistors, particularly on the Attention line.

4. Make the receive routines able to time out if the word transmission does not complete within a reasonable time.

In some applications it is impossible to completely protect the attention line from being affected unintentionally. In one such case, I found the solution was to maintain a counter during timed interrupts and limit the amount of time the DS routines had to wait for transitions on the Attention and Data lines.

Please let me know of your experiences with the protocol. I'm also interested in improvements and extensions that can be published here. My email address can be found on the HOME page for this site.
Possibility of Development Tool that uses PC Printer Port

It is probably possible to write a design and debug tool for the DS interface that uses the PC's parallel printer port. Personally, I lack both the requisite hardware and the skills. I would appreciate hearing from anyone who creates such a tool. My email address is projects@cappels.org.

 
No Restriction of Republication Rights
This document and protocol may be republished freely provided that proper attribution is given and notification of publication is sent to projects(@)cappels.org.
 

You can send  email to me at projects(at)cappels.org. Replace "(at)" with "@" before mailing.