PICBench consists of four elements:
Some detail of the design and implementation of these is given below.
The protocol used by PICBench is optimised to minimise the load it exerts on the PIC processor. It is designed to operate on an RS232, RS422 or RS485 link in single or multi drop mode. In multi drop mode each PIC has its own unique address which is compared with the address byte sent in the protocol frame.
The frame format is:
| Bits 0:7 | 8 | Bits 0:7 | 8 | Bits 0:7 | 8 | Bits 0:7 | 8 | Bits 0:7 | 8 |
| ADDRESS BYTE | 1 | COMMAND BYTE | 0 | DATA BYTE1 | 0 | DATA BYTE2 | 0 | CHECKSUM BYTE | 0 |
All bytes are binary not ascii to keep the frame short and the protocol routines simple.
The protocol exploits the 9-bit addressing mode of the PIC AUSART where a 9th (substitutes for parity) bit is sent for each byte. The setting of the 9th bit denotes an address byte and also the start of a new frame. The follwing four bytes have the 9th bit clear denoting a data byte. This enables multiple PICs listening on the same link to ignore data intended for other PICs correspondingly reducing wasted comms processing time. It also ensures frames stay in alignment and that data and adresses cannot be confused.
The checksum byte is a simple 8bit sum of the other 4 bytes. If this is incorrect then the frame is discarded.
The communiucations link operates with a single master - the PC. Each slave responds directly following a query frame addressed to it. Where an error is detected by a slave no response is made and the master query is timed out.
The baud rate is set to a modest 9600 to minimise the load on the PIC. Each frame has 55 bits which at 9600 baud will take 5.8ms. A query and reply will therefore take 12ms. Allowing 15ms in total for other processing delays over 60 transactions per second should be achievable.
This is implemented in PIC Assembler purely as two (send and receive) interrupt routines associated with AUSART RC and TX. Apart form an initialisation macro the driver will not impact on the coding of the main loop. The length of each call to the interrupt routine has been kept to a minimum to reduce latency in the servicing of other interrupts or polling loops.
The driver macros have been split into a protocol macro set (protocol.h) and a AUSART macro set (uartscada.h). This allows for the possibility of implementing the driver on another interface.
The assembler code for the driver can be seen by following the PIC Code link on the left.
This is implemeted as a Windows ActiveX exe control, programmed in Visual Basic 6. It has two parts a communication protocol driver with a sharable public COM interface and a scheduler. The scheduler send update events to all of the Comms Server clients to ensure they access the protocol driver in a sequential manner.
The user interface is a Windows exe again programmed in Visual Basic. The multiple instrument functionality is based upon an MDI application with the frames of the child windows supressed.