Real-Time Software

A common misconception is that real-time software must be extremely fast.  By definition, real-time software is simply code which must operate within a set of time constraints derived from the real world.  In many cases, this can mean something as simple as a requirement that a sensor be checked once per hour plus or minus one minute.  A more typical requirement might be that the computer respond to user input within 5 seconds.  With today's computers, both of these constraints are generally trivial to meet, so they are rarely thought of as "real-time".  Usually when people refer to real-time today, they are talking about timing constraints which are measured in intervals of less than a second.  For these types of timing constraints on a heavily loaded processor, it can become much more difficult to guarantee that all events are processed in accordance with their "real-time" requirements.  It is in this area where it can be critical to the success of your project to use an experienced real-time programmer.

Some of our past projects have dealt with real-time constraints so tight that we were forced to compute the execution timings for every possible path through each of the interrupt handling routines.  In a few cases, we have been forced to optimize each interrupt handler so that it's efficiency increased as the system loading increased, reaching maximum efficiency at maximum load, and once this was done, further "tuning" the interaction of the interrupt routines in order to minimize thrashing between the different interrupts.  Fortunately, it is fairly rare for a project to require such extreme measures, usually it is only necessary in a few cases where a new set of requirements are created for a system that is already in the field.  In the most difficult example of this type of programming problem that we have ever encountered, the final software had a margin of less than one microsecond per byte of data processed during peak load (not much by today's standards, but extremely tight at the time this was done).  Since on this particular system, the CPU cycle was greater than one microsecond, it could not have tolerated even one additional instruction per byte processed!  While the functionality being performed by these interrupt service routines was not particularly complex, the micro-controller being used was completely inadequate for the performance requirements (this was required to be a field installable upgrade to an existing system), so it was necessary to use every possible optimization trick including:

• Loop unrolling
• Dedicating separate processor registers to each interrupt
• Creating custom algorithms that were "tuned" to the processor architecture
• Optimizing execution paths so that throughput efficiency increased as the system load increased
• Merging interrupt service routines in order to eliminate processor overhead caused by the context switch between interrupt and non-interrupt operation.

If your project has difficult real-time requirements, DeaTech Research Inc. can provide you with the skills necessary to deal with them.