Back to Main page
Last updated: March 21,2007
KisBus (Keep It Simple Bus)
Why?
The more I think about robotics, the more I realize the need for very inexpensive way to control multiple actuators and read many sensors. They all have to be interconnected somehow. Serial/Parallel ports or 32 pin io on MCUs are not enough. (It is possible to use parallel port to do SPI.) This brings about a need for a bus. Most Hobbyists interconnect ICs directly and do not use addressable buses. This limits the complexity of the projects greatly and limits the reusability of the components.
To minimize the price of the components, PIC12 MCUs are the best choice. The downside is that PIC12 do not have a hardware UART. Having low pin and a small package size count could be an advantage or a disadvantage also. Presence of a built-in oscillator is essential for a low-cost device. On-chip ADC is one of the most important reasons for choosing this PIC. Another pic that seems even better is pic16F690 since it has a hardware EUART, 12 channel ADC, 4 channel PWM, internal oscillator etc... it comes in a 20 pin package. If I were to do it over, I would base the project around a pic with a hardware UART. Basing it on the chip with a hardware UART would simplify programming greatly and increase the number of reads/writes per second on the bus. At 19200 baud maximum theoretical throughput is (19200/10)/3 = 640 reads/writes per second. 10 bits per byte of transmission is assumed to take start/end bit into account and 3 bytes per packet.
Why not use an existing bus specification?
We could rule out use of any parallel buses right away since the low pin count mcus will not be a good option. Many buses rely on high speed hardware to do it's work. That means emulating it in software will not be an option. If an external chip is used (usb etc...) our simple mcu needs a way to communicate with it. Usually this communication would be a synchronous (SPI) or asynchronous serial communication. Synchronous com port is not available on a PCs, PDAs and other devices that might be a good candidate to be a Master. All that remains is an Asynchronous serial communication. Some buses provide advanced functionality such as device discovery etc. This functionality is not available through kisBus. A robot designer should configure the devices with their IDs prior to putting them into network.
Other similar projects:
There are other projects which attempt to reach similar goals. Ferrettronics (bought by "E-Lab Digital Engineering, Inc.") has a series of chips that utilize a 2400 baud serial to do PPM,Stepmotor control and digital io. ANother project is robo-brick it is aimed at lego mindstorm and aims at providing electronics based on lego pieces. Robo-brick 2 utilizes hardware based uarts. Having an on-chip and not board-based controller can be very advantageous. They are easy to bread-board. Easy to share new device code. Can utilize various physical layers (hadrware signal layer).
read/write philosophy:
Many protocols rely on the fact that packet size is a multiple of N bits. Existing 8 bit serial ports and 8 bit per byte computer architectures makes 8 bit a good candidate. Since our devices only read or write and perform a single function, a packet should consist of an individual read or write. Given that the packet should contain an address and a CRC, it should be at least 2 bytes long. Taking into account that bit 7 is reserved to indicate an address byte, if a packet were to be 2 bytes long, only 4 bits of data could be transmitted. It is common for hardware such as ADCs, PWM generators etc. to utilize 10 or 8 bit values. By making the packet 3 bytes long we provide 11 bits of data during each read or write which turns out to be sufficient for many devices. If a more than 11 bit transmission is required, 2 consequitive read or write can be done.
Protocol:
Each PIC chip will be classified as a transmitter or a receiver. Receivers control actuators and other processes and transmitters read sensors and other input. Communications utilize a single pin on a PIC to send data. Receivers based on PIC12F683 will utilize GPIO3 and transmitters will use GPIO3+GPIO5 pins. All communications will be done at 19200 baud 8N1 half duplex.
This is a master/slave setup. The protocol will utilize a push/pull concept similar to existing buses however classification in transmitter/receiver will illiminate the need for additional commands. Each packet will consist of 3 bytes:
byte 0 - 7 bit address of the device ( always broadcasted by the master )
byte 1 - payload (7 bits)
byte 2 = 4 bit payload + 3 bit checksum
Special address FF is reserved and will be used to "program" the PIC with a new address. In the case of a receiver, master broadcasts all 3 bytes and the receiver after checking the 4 bit checksum parses the 12 bits of payload by it's application layer. In the case of a transmitter, master broadcasts the first byte (address) and right away switches to high impedance mode. All the devices hear the broadcast. The device with the right address, switches it's pin to output and sends out 2 bytes ( 12 bit payload + 4 bit crc).
Physical layer:
There are hundreds of bus specifications. Some of them have hardware specs and some include protocol specifications. Many buses use RS485 for electrical specifications. Many IC to IC buses utilize duplex multiline connections for communication. KisBus only specifies NRZ serial protocol interface and does not say anything about physical layer. For devices that read and do not transmit on the bus simple TTL/CMOS serial might do. Give that the devices are not very far appart, R/C of the bus line does not create problems and power supply is stable fanout for TTL/CMOS could accomodate many devices (on the order of 50?) since TTL/CMOS logic have high impedance.
???Due to "IC to IC" nature of the bus, high impedances of the PICs and the fact that distances will be small, i assume there will not be a need for a separate bus driver ic for devices that do not write to the bus. Given this, why would you need a physical layer? Transmitters rely on the fact that when it is idle, each transmitter tri-states the line or has a very high resistance (impedance?) to ground. Furthermore differential encoding such as in RS485 and CAN bus revents signal errors over long distances or when power levels are unstable.
Software:
In the heart of each device is kisBios.asm It is written for PIC 12F683 mcu. Bios makes sure each device is able to respond to communication events as well as providing time slices for device dependent code. kisBios.asm takes care of checking and reprogramming device address, computing CRC when a packet is received or transmitted and transmit functionality. Since devices can be of 2 types: Receiver and transmitter it is implemented by using macros so that everything can be under one code base. Each device provides an include file that defines macros for responding to "read request"/write by the master and doing useful work during time slices. Devices allocate needed memory and define EQUs inside the "inc" file. There is a dependency on macro683.inc file. It contains macros used in kisBios.asm and device include files.
MAJOR PROBLEM???: Code needs to be reqritten to shadow GPIO reg to avoid Read/Modify/Write race conditions common to PIC MCUs.
PC Software:
Assuming the Master is a PC, a library written in C++ will provide an ability to interface to any device on the bus. PC library will consist of layers: Com port, bus, device. Com port provides initialization and read/write access to the PC's serial port. Bus will provide read/write functionality to a device given it's ID and 11 bits supplied as a short or ability to reprogram the device's ID. Any device specific code can use the bus API to send and receive commands and data. Interfacing a device to a PC requires a RS232 TTL serial bus converter.
Device pinouts:
Since we are basing the design around pic12F683, pinout of the devices can be predetermined by the fact that GPIO bit3 can only be an input. Since all of the devices receive serial, this pin can be made an input. Furthermore most of the "receivers" (not all) will need output pins and not inputs. Transmit devices could use GPIO bit 5 for input and output, however since output devices might require tristating or high impedance to ground during the times when they are not transmitting, it might be wise to separate input and output pins for easier interface to a physical layer. GP5 and GP4 equally could be used, but using GP4 for device specific input/output is better since a single rrf/rlf could be used on the lower nibble to set bits etc... Using GP0-GP2 are not recommended since it might be beneficial for a device to do a single read/write to those 3 bits from one nibble. Therefore GP5 is our best choice for serial out on transmitters, which is what the bios utilizes.
Types of devices already implemented by pic12:
2 channel PWM H-bridge drivers (receiver)
5 channel PPM servo drivers (receiver)
1 channel stepper motor controller [normal/half/wave drive] (receiver)
4 channel ADC converter (transmitter)
Devices connected using 4 channel ADC converters:
3 axis Accelerometer ($9 STMicroelectronics E-LIS3L02AS4)
Devices that could be implemented:
4 channel Digital Input (reads 4 pins)
5 channel Digital Output (writes 5 pins)
IR Remote control decoder
IR Proximity sensor (using ADC?)
Gyroscope (using ADC?)
Compas (using ADC?)
Sonar (using ADC?)
PPM Servo controller implementation notes:
There are 2 timers running. When timer rollover flag is set, a channel pin is set hi. Another timer measures how long the pin stays hi. When second timer interrupts, pins are bcf on GPIO in ISR without saving the state since bcf does not affect status.
How to write fast software based serial comm programs for pics:
Use this a serial receive procedure with a delay. Use a state machine during the delay that always takes N CPU cycles. If you are running out of CPU cycles, just increment the state and continue in the next state. When you need to keep track of timing, use timers, but instead of interrupts, poll timer flags this way the delay will always take the same number of cycles.
Originally I wanted to name the bus PICBus, but www.melabs.com claims that PICBus is a registered trade mark.
Download Code Here This is work-in-progress. If code is not available yet, please be patient.