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:
If your project has difficult real-time requirements, DeaTech Research Inc. can provide you with the skills necessary to deal with them.
Return to our Software Home Page
Solar powered hosting (from our cob office building)
provided by:
DeaTech Research Inc.
using
Debian Linux based servers.
We highly recommend, use, and provide support services for
Debian Linux.
If you should have any problems with this page or website, please send email describing the problem(s) to: webmaster@deatech.com
Last Modified: April 12, 2007
If you wish to be permanently blocked from ever being able to send email to this domain, send your SPAM messages to: blackhole@deatech.com