WBus

• very low-cost (in fact almost zero-cost)
• daisy-chain topology
• three wire communication (Gnd, RxD, TxD)
• DB9 male/female connectors, standard DB9 extension cables
• half-duplex
• single-master, multiple-slave
• asynchronous serial transmission at 19k2 baud, 8 data bits, no parity, one stop bit (19200/8/N/1)
• character-level handshake (no buffering needed at master or slave)
• simple command format (you can use a terminal program to test a device)
• transparent passthrough feature
• not very efficient in terms of bandwidth
• uses TTL levels (hence limited distance), an optional 'level restoring' dongle can be used to get a true RS-232 level interafce

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).

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 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.

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:

• sleep
• attention
• active
• passthrough

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 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.

polling

• issue a Break to force all devices to the attention mode;
• issue a Hello to get only the intended device to active mode (all other devices will remain in attention mode).

half-duplex

no passthrough

no programmable ID

restoring the RS-232 level

• It would be nice to be able to connect more than one WISP programmer to a serial line (I'm always short on serial lines).
• It would be very convenient if I could communicate with a freshly programmed circuit without leaving my PC (preferrably without leaving the WISP tool). It would be even more convenient if I could run automated tests which include re-programmin the target (but that it just something to put in the WISP tools, it does not affect the protocol).

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.