I can recommend you consider that the difference between the fastest speed and
the optimal speed comes down to a number of things. Consider one case, wherein
we speeded the operation of a multi-computer security system by reducing the
baud rate of the monitor terminals from 9600 to 1200. That reduced the amount
of idle (ENQ/ACK) traffic by 90%.
Moreover, lots of I/O tasks require too much speed if you have to test a flag
before fetching each byte. However, if your processor is running at a rate
synchronized with the transfer, you only have to check the flag once, then use a
loop tuned for the exact length of the transfer cycle. As Tony points out, it's
based on the externally imposed rate, and if your oscillator doesn't synchronize
with that, you have problems.
Dick
----- Original Message -----
From: "Mike Ford" <mikeford(a)socal.rr.com>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 19, 2001 12:16 AM
Subject: Re: Apple II for intro to microprocessors
Number (3) seems like really bad form, making a
circuit that depends on the
processor running at some specific rate. Much better to write code that is
"aware" of the processor speed and compensates for it.
How do you propose measuring the CPU speed? You always need _some_ timing
reference of a known frequency (for example, one way is to see how many
simple loops you can run between mains frequency interrupts, but you then
need to know the mains frequency). And it adds complexity to the system.
For embedded controllers it's very common to write the code for a
particular clock crystal frequency and be done with it. Particularly for
things like bit-banged serial I/O. A number of my listings start with
comments like 'PIC 16C84 processor clocked at 4MHz' or whatever.
That works for me, and the next line would define some constant with a
value that I interpret to be 4 MHz within my code. That way when a new chip
comes out that supports 6 or 8 mhz, and I need more processing power the
design is easily updated. All this could fall into the great grey area of
personal style, but very often when I work on a project some specific
direction seems much more "right" than others. Sometimes I can explain my
point of view, others times I just know it even if I don't have a clue
exactly why.