software delays (was: LINT won't do your debugging for you)
John Woods
john at frog.UUCP
Tue Jul 18 08:28:00 AEST 1989
In article <12724 at bloom-beacon.MIT.EDU>, scs at adam.pika.mit.edu (Steve Summit) writes:
> In article <3588 at cps3xx.UUCP> usenet at cps3xx.UUCP (Usenet file owner) writes:
> >When implementing some very low level code in C under MSDOS, an if
> >with a null body provides a very handy slight delay.
> Pure software constructs are one of the worst ways of trying to
> create real-time delays. Among other things, when a faster
> processor comes along, which ought to be an unqualified
> improvement, programs stop working because the delays are no
> longer long enough.
True, but sometimes they are the only way of creating a delay (thus making
them simultaneously the worst AND the best :-). Case in point: our serial I/O
Processor uses the ubiquitous G*DD*MN*D 8530 SCC chip, the one that needs about
a microsecond of delay time after each operation and whose data sheets are
dusted with a virus that destroys the brains of hardware engineers, causing
them to stubbornly refuse to put that microsecond interlock in hardware.
Achieving a microsecond delay is real hard to efficiently do with programmable
hardware (since it may take well over a microsecond to set it up). The
solution we use is this: accesses to the SCC are followed by a macro called
STALL (as in
scc->scw_cmd = SELECT5;
STALL;
). The slowest IOP version has a null STALL macro because its cycle time is
slow enough as is. The faster IOP version uses
#define STALL waste++
which is sufficient. With a little cooperation from the compiler, this
can be elaborated to a noxious degree, yet requires only another ifdef in a
header file, with no change to the actual code.
Of course, some day the compiler is likely to notice that all of those
increments can be bundled up into a "waste += 32" at the end of the function
and then we'll be stuck... :-)
--
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu
People...How you gonna FIGURE 'em?
Don't bother, S.L.--Just stand back and enjoy the EVOLUTIONARY PROCESS...
More information about the Comp.lang.c
mailing list