On Sunday, October 20, 2013 9:40:24 AM UTC-7, Don Y wrote:
[on squeezing performance from small CPUs]
I particularly favor good counter/timer modules. With just a few
"little" features you can enhance a tiny processor's capabilities
far beyond what a larger, "bloated" processor could do...
Speaking of which, what IS available in off-the-shelf counter/timer
support? I've still got a few DAQ cards with AMD's 9513 counter
chips, which I KNOW are obsolete, but what's the modern replacement?
I don't think there is a "free-standing" counter/timer "chip".
Nowadays, most MCUs have counters of varying degrees of
capability/buginess built in. So, we're supposed to learn
to live with said:
The 9513 had five 16-bit counters, lots of modes, and topped out
at 10 MHz; you could make an 80-bit counter, and test it once
during the next many-lifetimes-of-the-universe.
But many of its modes were silly. I.e., configuring it as a
time-of-day clock/calendar? Sheesh! What idiot decided that
a MICROPROCESSOR PERIPHERAL needed that capability? Can you
spell "software"?
It also had some funky bugs, was a *huge* die (for its time
and functionality), etc.
A lot of counter/timers are really "uninspired" designs, lately.
Its as if the designer had *one* idea about how it should be
used and that's how you're going to use it!
The Z80's CTC, crippled as it was (not bad for that era), could
be coaxed to add significant value -- if you thought carefully
about how you *used* it!
E.g., you could set it up to "count down once armed", initialize the
"count" to 1 (so, it "times out" almost immediately after being
armed), set it to arm on a rising (or falling) edge AND PRELOAD
THE NEXT COUNT VALUE AS '00' (along with picking an appropriate
prescaler and enabling that interrupt source)
As a result, when the desired edge comes along, the timer arms
at that instant (neglecting synchronization issues). Then, "one"
cycle (depends on prescaler) later, it times out and generates an
interrupt. I.e., you now effectively have an edge triggered interrupt
input -- but one that has a FIXED, built-in latency before it is
signalled to the processor.
The magic happens when the counter reloads on this timeout and, instead
of reloading with '1', uses that nice *big* number that you preloaded
in the "reload register". AND, STARTS COUNTING that very same timebase!
So, when your ISR comes along, it can read the current count and know
exactly how long ago (to the precision of the timebase) the actual
edge event occurred. EVEN IF THE PROCESSOR HAD INTERRUPTS DISABLED
for a big portion of this time! (or, was busy serving a competing
ISR, etc.).
The naive way of doing this would configure the device as a COUNTER,
preload the count at '1' and program the input to the desired polarity.
One edge comes along, counter hits '0'/terminal_count and generates
IRQ. Then, *hopes* you get around to noticing it promptly (or, at
least *consistently*).
The "smarter" approach lets you actually measure events with some
degree of precision without having to stand on your head trying to
keep interrupt latencies down to <nothing>.
