This protocol is primarily designed to allow multiple PICs to communicate with each other over a single shared line. These PICs are intended to be used to control a DCC rail layout. Although DCC allows control of accessories, its feedback mechanism is rudimentary. Besides devices like throttles are not appropriate on the DCC bus. Commercially, this problem has been solved by having a separate bus for other devices to communicate. The Pecan bus, though not based on any of the existing ones, is built along similar lines. The existing bus standards have not been used as it is not easy to implement a multi-master bus protocol around a PIC 16C84. The CAN standard looked particularly suitable - one of the DCC manufacturers' does use CAN for its bus - but it would place too much overhead on the PIC and looked difficult to implement. So I just put together a protocol which borrows a little from CAN.
One of the good features about CAN is its multi-master capability and its non-destructive arbitration mechanism. The Pecan protocol also uses such a mechanism. It uses normal serial transmission at 1200 baud except that the high level is not active i.e. it is driven by an open collector output.
A packet without any data byte allows the transmission of a minimum size packet which is 4 bytes long and contains 4 bits of data. This will be followed by 1 1/2 bytes of idle state making the whole packet last 5 1/2 bytes. The single byte for arbitration allows 256 devices. If this is found insufficient, a second byte may be employed. This will allow a generous 65,536 devices. Unlike CAN, the ids. are associated with a unit rather than a message. This should simplify the system design. The largest packet possible will contain 15 data bytes - the whole packet will be 18 1/2 bytes long including the idle state.
The PIC routines are based on existing RS 232 send/receive routines designed to run based on an interrupt received every 208 us or four interrupts for bit duration. This is not expected to cause any problems as all PICs will operate at the same frequency or will at least have the same interrupt period. The skew during the all important arbitration byte is not expected to be large - a couple of us at most. The current sampling frequency can easily detect any collision.
This multi-PIC system is also expected to interface to a PC on a serial port. Although the timing is not a problem, the PC cannot participate in the arbitration protocol without some hardware support. This is expected to be provided by a PIC based unit interfacing the Pecan bus to the PC serial port.
