Note: The WBus hardware as described here is used by the Wisp programmer but should not be used by new designs.


WBus is a daisy-chain multi-drop pseudo RS-232 bus that I use to connect a number of PIC-based lab devices to the serial port of my PC. The main features of WBus are:


WBus uses standard DB9 connectors and (extension) cables (straight-through cable, female connector at the host side, male connector at the other side). A WBus device has two DB9 connectors: one female for the upstream connection to the host and one male for the daisy-chain downstream connection to the next device. The male connector can be omitted but this limits the device to the last position in the daisy chain.

When the host does not have a male DB9 RS-232 connection a suitable conversion cable must be used, for instance a female DB25 to male DB9 cable for a host with a male DB25 serial port (as found on most older PCs).


The WBus uses the signals shown in the next table.

DB9 pin name use
2 RxD This is the serial line from the devices to the host. This line is driven low (high impedance) by each device. It is driven high (lower impedance) by a device which is transmitting.
3 TxD This is the serial line from the host to the devices. This line is driven by the host.
5 Gnd This is the ground for both serial lines.


The voltage levels on the TxD line are determined by the RS-232 driver in the host. The devices should be able to withstand these levels (unloaded up to +/- 30V). For a PIC-based device at least a resistor (100k) between the TxD line and the PIC pin will be needed to limit the current through the protection diodes, but the circuit below is to be preferred because it limits the voltage on the PIC pin to the operational range allowed by the manufacturer.

two pin circuit

The RS-232 levels on the RxD line are determined by the devices. Each device pulls this line low by a high impedance (100k) to ground, and can drive it high (to +5V) via a 330 ohm resistor and a 1n4148 diode. The diode can be omitted when the device output is high or high-impedance (never low). The resulting levels are not standard RS-232, but they are acceptable to most RS-232 receivers.

The inteface described above is non-echoing. The interface shown below uses only one pin of the PIC but echoes the characters sent by the host PC back to the host. Both echoing and non-echoing interfaces are allowed and can be used on the same daisy-chain.

one pin circuit


The devices are connected in multi-drop fashion to the serial line. Each device receives whatever the host sends to it, and the host receives whatever any device sends, plus (when at least one echoing device is connected) whatever it sends itself. The correct use of the protocol ensures that only one device sends at any time, and no device sends while the host PC sends. (Otherwise the host would probably receive garbage.)

All communication is initiated by the host (exception: the passthrough mode). To avoid communication overruns the protocol requires that

The host should assume that a character is lost when it does not receive an expected response within 1 second. All characters sent by the host (except in passthrough mode have the highest bit set. When the host receives a character with the highest bit set it ignores the character.

In most cases the protocol requires a device to echo any received character back to the host, highest bit cleared and converted to uppercase, but otherwise unchanged. The exceptions are:

This echoing must not be confused with the echoing caused by an echoing interface, which echoes the character exactly as sent.


The WBus permits a device to implement a passthrough mode in which all communication is passed along to a secondary device (which is not directly connected to the serial line). The communication to this secondary device does not need to adhere to the host communication protocol (it could even use a different baudrate). For both the host and the secondary device the passthrough is completely transparent, except for a serial line break, which is used to exit the passthrough mode.

The protocol ensures that when one device is in passthrough mode, all other devices are in sleep mode. This prevents that the other devices could (erroneously) interpret the communication between the host and the secondary device as WBus commands.


A device can be in one of four modes:

The power-up mode is attention. The mode of a device changes according to the next table:

mode serial line break HELLO command PASSTHROUGH command
sleep goto attention ignored ignored
attention remain in attention if ID matches
    then goto active
    else remain in attention
goto sleep
active goto attention if ID matches
    then remain active
    else goto attention
goto passthrough
passthrough goto attention ignored ignored


The WBus command syntax is simple: the characters G..Z are command characters, the characters 0..9 and A..F are arguments. The arguments to a command are send before the (single) command character. The characters sent by the host have their highest bit set to allow the host to distinguish an echo from an echoing device interface from an echo by the device firmware, but when a human tests a WBus device (using a terminal program) thsi is not needed. The syntax is not case sensitive (but the echo is always in uppercase).

The following commands are defined by the WBus protocol. A device will most likely define additional commands. Such additional commands should adhere to the WBus command syntax. Additional commands should only be recognised in active mode.

format name effect
"break" Break A break condition on the serial line forces the device to the attention mode.

After the break condition the host sends four 0 characters. This can be used by devices with an unreliable clock to calibrate their timing. The host should not rely on the correct reception of these 0's.

A break condition is recognised in all modes.

abcdH Hello Depending on the value of abcd the device will go to the attention or active mode:
  • When abcd is 0000 the device will always go to the active mode. This is usefull to force the one and only device on a serial line to the active mode, irrespective of its device ID.
  • When the device ID is abcd the device goes to the active mode.
  • In all other cases the device goes to the attention mode.
Note that in the attention mode a device will not echo received characters. When a device enters the active mode, it will echo the H.

A Hello command is recognised only in the attention and active modes.

N Next The device will echo (instead of the N) the next character from its buffer. There should not be any other commands between the command which has set the buffer and the N commands which retrieve the contents of the buffer.

The Next command is recognised only in the active mode.

P Passthrough A device which is in the active mode and supports passthrough will echo the P and enter the passthrough mode. A device which is in the active mode but does not support passthrough will remain in active mode and echo a ? instead of the P. A device which is in the attention mode will enter the sleep mode.

A device can define arguments to the passtrough command which select different passthrough modes. This does not affect other devices.

The Passthrough command is recognised only in the attention and active modes.

Q Query The device copies its ID to its buffer. The host can use N commands to retreive the ID.

The Query command is recognised only in the active mode.

T Type The device copies its type (4 characters) to its buffer. The host can use N commands to retreive the type. This should be used by a host program to check whether an activated device is of the type it expects.

The Type command is recognised only in the active mode.

abcdU Burn The ID abcd is burned into the device.

The Burn command is recognised only in the active mode.

V Version The device copies its version (4 characters) to its buffer. The host can use N commands to retreive the type. This should be used by a host program to check (after it has checked the device type) whether the device is of a firmware version which it can handle.

The Version command is recognised only in the active mode.



When a tool on the host wants to get the attention of particular device it must The first step (serial-line break) takes some time. It can be omitted when the host knows for sure that all devices are in active or attention mode (because the same host has previously issued a serial-line break and no passthrough, so no device can be in sleep or passthrough mode).


A device should take care that it does not start transmitting before the command character from the host is fully transmitted, including one stop bit. Likewise the host should not start transmitting the next character before the echo is fully received. This is especially important for devices which bit-bang the serial line without interrupt support.

no passthrough

A device does not need to implement the passthrough mode. (In fact, most devices will not.) But the device must still implement the sleep mode and hence recognise a serial-line break. Otherwise it could misinterpret the communication between the host and a secondary device.

no programmable ID

For a device which does not contain a permanent storage which is under firmware control it might not be practical to implement the Burn command. Instead the device could have a few dip switches to set (at least a few bits of) its id, or (less good) it could have a hardcoded ID. In the latter case the maker should assign IDs sequentially to each individual device to minimise the change that a user gets two devices with identical IDs. A device which does not implement the Burn command should of course echo a '?' instead of the 'B'.

restoring the RS-232 level

Some PC's do not accept the TTL-like levels produced by WBus devices. In such a case an
RS-232 restoring dongle can be put between the PC and the Wbus.


When I designed the communication between the WISP programmer hardware and the PC-based WISP tool I realised that These ideas determined most of the WBus aspects.

It took me a little longer to realise that a shared communication medium between my PC and a chain of little PIC-based devices could be very usefull in a (hobby) lab environment. I was thinking of a design for a low-cost PIC-based logical analyser, so why not add a ditto data logger, remote I/O, general-purpose serial-line interfaces ... Hence the Type command, so a host-based tool can determine whether it is really talking to the device it expects.

I don't like to have all kinds of different serial cables (for one thing the labeling is never clear on the straight/null-modem issue), so I decided that one type of cable should take care off all connections. DB9 connectors are very cheap, take little space, and can be soldered directly to the edge of a PCB. Using only the top row is convenient when your PCB is only single-sided. DB9 is also the established standard for serial ports on a PC, and DB9 extension cables are the cheapest cables I could find.

Wall plugs and power supplies are like serial lines: you never have enough of them, and when you have one spare it is of a wrong type. So in WBus version 1.0 I distributed power via an (otherwise unused) RS-232 line. According to the RS-232 specification this should be allowed, but it still fried the RS-232 chip on my PC's mainboard, so I removed this feature.

While designing WISP I got a PC with two USB ports. I downloaded the USB definition document to see whether I should connect WISP to those ports instead of the serial port. From the description the USB seems like a good idea, but it won't be easy to make a low-cost USB device untill really cheap USB chips become available. Until then the WBus (using PIC chips) can be considered my poor man's USB.

24-APR-2000 2.00
  • power distribution removed
  • interface circuit changed, 1-pin interface added
  • 1998 1.XX first version(s)