DPRG Events Shoptalk

Website design and hosting by NCC

Theory of Operation for SR04 System Timer

by David P. Anderson
09 March 1999

I have had a number of requests to describe the theory of operation of my current robot project, SR04. There is an HTML and PDF format document describing the basic system with a few paragraphs about the software, available from http://www.geology.smu.edu/~dpa-www/myrobots.html. Interested readers are referred to those documents for a more detailed description of the hardware, sensors, and behaviors.

This document attempts to outline the system software in a more detailed fashion, with an emphasis on the software operating environment and principles, hopefully in a generic manner that is applicable to other micro-controllers and development environments.

The micro-controller used for SR04 is a Motorola HC6811 running in an M.I.T. 6.270 board, similar to the commercially available "Handy Board". The software is written in "C" using the ImageCraft "icc11" compiler. The operating system is based on the "ic" environment created at M.I.T. for their introductory robotics course. An excellent resource is the book Mobile Robots by Jones, Flynn & Seiger.

I. The System Timer
Fundamental to most real-time robot operations is the need for timing and delay capabilities. This mechanism is at the heart of sensor sampling and response, and also forms the basis for multi-tasking and scheduling. Basically this means that a software routine does something, like reads a sensor or writes to a motor controller, waits a bit, then does it again. Hopefully while it is waiting, other software routines get a chance to run. The discussion of the SR04 Robot Operating System and Software begins here.

Free Running Timer
The system clock is a global free running timer that is updated at regular intervals. From the point of view of the software functions that use this timer, it is either a hardware register or a memory location, depending on how it is implemented, that can be read at arbitrary intervals to determine elapsed time.

B. Resolution
The resolution of this free running timer determines the granularity of all subsequent robot functions, sensor sampling rates, motor update rates, and so forth. In general faster is better, within the limits of the hardware and software. A common resolution, and the one used here, is 1000 Hz, and hence the shortest interval that can be timed is 1 millisecond.

SYSTEM_TICK = .001 second

High bandwidth sensors like sonar, audio, and video will require their own high-speed clocks, typically implemented as special purpose hardware, from a few tens of kilohertz for audio to megahertz for video.

C. Precision
An unsigned eight bit register updated at 1 kHz overflows every 2^8 = 256 milliseconds, about every 1/4 second, not long enough for our purposes. A sixteen bit register overflows every 2^16 = 65536 milliseconds, about once a minute. Better, but still not good enough to time a 10 minute run from one end of the house to the other and back.

The SR04 system uses an unsigned 32 bit integer as the basic system clock. This overflows every 2^32 = 4294967296 ticks, or:

   4294967.296 seconds
   = 71582.788 minutes
   = 1193.04 hours
   = 49.7 days

So overflow occurs about every 50 days. Fancier clocks can be implemented, including actual time-of-day/month/year schemes. In practice none of our robots have ever been left running anywhere near 50 days. One day is more typical, so the 32 bit clock has been sufficient. This is also convenient because many "C" compilers, such as the icc11 used to implement SR04, provide a 32 bit unsigned integer as a standard data type, either as an "int" or in this case as a "long".

D. Implementation
The Motorola HC6811 microprocessor which forms the basic brains of SR04 includes a set of counter/timer registers that allow the programmer to easily implement various kinds of timing functions. SR04 uses one of these timers, output compare timer 4 (TOC4) to generate a free running 1 kHz system clock. Basically the hardware is programmed to generate an interrupt every millisecond, and the interrupt routine just increments a 32 bit integer and resets the interrupt.

Higher level robotic functions that need to use the timer then simply read this integer, which is accessed like any other C variable.

The HC6811 code to produce this function is in two parts. An initialization subroutine sets up the timer whenever the system is reset. The system clock interrupt then runs continuously. Here are the initialization and interrupt code fragments, written in C:

   #include <hc11.h>              /* include file of HC11 register definitions */
   unsigned long sysclock;        /* 32 bit global 1 khz system clock variable */

   void system_service_init()     /* initialize the TOC4 interrupt */
                                  /* do this at startup */
        sysclock = 0;             /* reset the system clock */
        TMSK1 |= 0x10;            /* enable TOC4 */
        TFLG1 = 0x10;             /* clear TOC4 flag */
        TCTL1 &= 0xF3;            /* disable output pin */

   #pragma interrupt_handler system_service        /* tell c to compile rti */
                                                   /* instead of rts */
   void system_service()
        TFLG1 = 0x10;            /* reset TOC4 interrupt */
        TOC4 += 2000;            /* delay another 2000 "E" cycles */
        sysclock += 1;           /* increment the system clock */

Notice the system_service() routine is set to next interrupt after 2000 "E" cycles. This particular microprocessor runs at two megahertz, so one millisecond equals 2000 microprocessor clock cycles.

One other initialization procedure must be done in order to get this all working. The address of the system_service() routine must be plugged into the HC6811 interrupt vector table. This is located at either 0xbfd6 or 0xffd6, depending on the mode of the microprocessor. On the HC6811 a global interrupt enable instruction must also be executed to allow interrupts to function. Refer to the HC11 documentation for the specifics.

E. Testing
The simplest way to test the system clock function is to print it to your standard output device (like computer screen or micro-controller LCD) and insure that it is changing appropriately, something like this:

   void sysclock_test()
        unsigned long extern sysclock;

        while(1) {

This will produce a continuously incrementing count, depending on how long your printf() function takes to execute, which should increase by 1000 every second. When you have this working, you're in business and ready to proceed to a few utilities that simplify coding of delay and time-dependent I/O routines.

Home | I. System Timer | II. Timer Utilities
III. Multi-tasking System - Coming Soon!
09 Mar 1999, Dallas, TX, David P. Anderson

Copyright © 1984 - 2014 Dallas Personal Robotics Group. All rights reserved.