Home

Introduction
The Hardware
Protocol Overview
Addressing
Prompts
Commands
Parameters
Ctrl Characters
Data Transfer
Flow Control
Errors
System Commands
Software Tips

Mini SB-Bus

Data transfer can work both ways, which means that the Master can send data to the Slave or the Slave can send data to the Master.
The most usual way of transferring data from the Master to the Slave is by means of parameters which follow the command on the same line. Slaves may send small amounts of data in a single line in response to a query Command.

But there may be times when the above mentioned methods are not suitable anymore. For instance if you want to transfer a binary file from Master to Slave or visa versa. That's where the real Data Transfer kicks in.
Data transfers can be equivalent to file transfers, but that is not necessarily so. A good example is the system Command *CATALOG?, which sends a list of all the Commands known to that particular Slave to the Master. This list consists of one Command per line.

Normally a Slave wakes up in Command mode, which means that all characters it receives from the SB-Bus are interpreted as commands and parameters. Some Commands however can select the Data transfer mode, in which all received characters are interpreted as data instead of Commands. It is up to the used protocol how to terminate the Data transfer mode which makes the Slave switch back to Command mode again.
Each Slave may set its own rules to the way in which data is interpreted and how the end of the transfer is signalled. This applies as long as only 7-bit ASCII characters are used for the transfer.

In any way, a possible transfer is always terminated when the Slave receives an Address byte!

The 7-bit ASCII limitation does imply that you can not simply send a binary file as legal data. Other Slaves will interpret values above 127 as addresses, and act accordingly and results are unpredictably.
Should you have to send binary data over the SB-Bus you may want to use one of the many different standard file formats. Most major electronics companies like Intel, Motorola, Tektronix and many others have defined their own file format. I've described the most important ones in my knowledge base.
One advantage of most of those formats is that they use checksums to verify the validity of the received data. Together with Acknowledge Flow Control you may ask the sender to repeat the last line if its checksum doesn't match.
Another advantage is the fact that most file formats provide a way of signalling the end of the file, which will switch the Slave back to Command mode after the transfer is complete.

Other types of data may require a different approach. I don't want to prescribe any fixed rules to such transfers, I shall only give some suggestions.

Define a unique way in which a transfer is ended. For instance end the transfer when an empty line is sent, or when a line is sent which only contains a period. Sending an ASCII EOT ($04) character is also a possibility.
All this only applies to Master to Slave transfers, because a Slave to Master transfer ends when a new line starting with a => or !> Prompt is received.

Strange characters may have to be escaped by a special character. Common practise is to use for instance the back slash as escape character, which is then followed by the ASCII code of the special character to send. For instance \130 would send a character with the value 130. While \013 would send a CR character, without ending the line like a real CR would have done!
In case you want to send the back slash itself you may enter \092, which happens to be the ASCII code of the back slash. Or you may send \\ which actually will send just one back slash. Or you could set a rule that a back slash which is not followed by 3 digits is not interpreted as an escape character.

As a rule of thumb you should always terminate the transfer of data when one of the parties sends an ESC character. When a Slave receives an ESC character from the Master during a transfer it replies by sending an !> Prompt.