Pecan - A Multi-PIC Protocol
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 unit wishing to transmit listens on the bus and waits for an idle condition. It then transmits an 8 bit unique id. The start bit signals the start of transmission. The state of the bus is monitored just before the start bit. This ensures that the bit timing of any other unit transmitting at the same time overlaps almost completely. During the transmission, any high bit is monitored to sense a unit with a higher priority transmitting at the same time. If such a unit is detected, the transmitting unit slips into receive mode.
The unique id. is then followed by the data byte count. The 4 least significant bits are used. A zero byte count is valid indicating that no data bytes will follow. In such a case, the most significant bits may contain data.
The checksum is followed by an idle state. This allows any unit listening to the bus detect the end of the packet. As all bytes follow each other separated only by a stop bit, any long duration high will be detected as the idle state. The duration of the idle high state should be such that it is not confused with a data byte which is all ones. So the idle state has to be at least 10 bits long. The Pecan protocol sets the idle state at a 12 bit duration.
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.
Updated on 14 May 1999. Feedback to