The first test programs I wrote directly in the assembly language. Then I used MPLAB to test it with. I did this in order to assure that I actually could control RC-servos with a PIC processor. This was done entirely in software without any hardware. I tested it in hardware at a later stage.
All on-board software is now written in C. Since the PIC processors have a limited amount of memory, a big challenge is to fit all functionality into the the tiny space. A consequence is that the software is not always as structured as preferred, but the code is OK considering the circumstances.
For building the code I use GNU make under Cygwin. Common code such as communication routines are compiled into a library. The library is then linked into the final executable on demand.
One important task for the hub program is to handle all internal communication on the robot. It controls all connected PCBs communication and synchronizes the usage of the nibble bus. The hub is the bus master and thus decides who should receive and transmit data on the bus. It can send a specific message to a specific PCB. It can also receive a message from a specific PCB. This is always preceded by a request message to the PCB. Immediately after the transmission, the hub and the PCB negotiates a direction change on the nibble bus with the control signals and the PCB transmits while the hub listens. Afterwards the default direction is restored. The hardware design forbids broadcasts.
Another main task is to handle RS-232 communication with the robot computer. This is done with hardware support in the PIC16F628 processor.
The hub program also offers a simple, yet efficient, interactive command interpreter. It reads ASCII character commands sent from the robot computer and reacts upon them. The user can for example command a specific servo to a certain angle position, request a foot contact status message or change servo speed. A special non-verbal command can be used to send angle streams that constitutes complex leg movements. This is a way to reproduce movement sequences of any length and complexity that may have been precalculated and stored in ordinary text files.
The main task for this program is to maintain a pulse-train in approx 50 Hz to eight standard RC-servos. The resolution for achieving 256 different angle steps within the servo range of operation is 4 microseconds. This sets high requirements on the code since the instruction time in a PIC16F84 at 4 MHz is 4 microseconds.
Another mandatory task is communication. This processor, as all other connected to the hub, must be able to communicate on the nibble bus. It is essential to the entire robot that response time is low.
The processor also controls the servo speed in order to make smooth movements. The speed is commanded through the nibble bus and currently applies to all servos. It is only the amount of RAM memory in the servo processors that stopped me from implementiong individual speeds for the servos immediately. A future feature is be to make the servo controller calculate the adequate speed for each servo to make them arrive at the commanded and angle at the same time. There are room for many fun improvements here!
An additional task is to flash the heartbeat LED to indicate that the processor is alive and kickin'. The heartbeat LED is also used for indicating a fatal error. This is done by flashing the LED a number of times corresponding to the error code. From this state there is no return except through a reset. The servo pulse train is maintained all the time though for safety reasons.
The last task is to read the two digital input pins indicating foot contact with ground when requested.
Usually each computer software unit in a distributed multi-computer system both have parts unique to the computer's task and parts general for all computers. The common parts in this particular system is not not only conceptually common but also physically shared between each software unit so it's guaranteed that all units use identical common code.
The common parts in this system is preferably the nibble bus communication code. All processors share the same message definitions and code structure. The shared code is for example functions for initalization, direction control, transmission and reception of single nibbles, bytes and entire messages.
Each software unit must configure the communication unit to fit it's hardware such as defining the IO-pins for the nibble (four pins), the bus control pins (two pins) and boolean true/false symbols. Then the unit just includes the preferred IO-parts and calls the corresponding functions. The make system will compile and build a IO-library configured for the unit.