> Good heavens! This is a tutorial how to throw away 25%+ of your
> processing power to service only 4 servos! All that is happening
> in that 25%+ of your processing is sequentially, 4 line, one at
> a time, goes up, and come back down.
It's a tutorial on how easy it can be to write a 4-servo controller.
The point is that processor time costs next to nothing. Processor time is
only expensive when you run out of it and have to buy a bigger processor.
If 75% of a cheap processor is more than you need to run the rest of your
robot then it doesn't matter if you've thrown away the other 25%.
My programming time, on the other hand, is always expensive.
> Rather than keeping explicit state information,
> a <begin check-timer until> structure captures the processor's
> Program Counter, restricting it to a very short range of
> possible values. While the Program Counter holds those values to
> the exclusion of all others, no other processing occurs.
So what? The processor isn't an employee. I'm not paying it piece-rate. I
I looked at using timers and interrupts and found that, using the processor
I had, I could get just as accurate timing with a tight loop. And it took
less programming effort.
The accuracy I needed was determined by the granularity of the byte used to
set servo-position - not by the granularity of the timing loop. I had to
put NOPs into the timing loop to slow it down.
My programming time is more important than the processor's time. Or do you
think I should write everything in assembler so that the PIC is used more
> So we have these loops checking a thousand times
> (or more) in a row if 1.5mS has passed, and disallowing a
> thousand (or more) useful things being done.
The PIC doesn't have a thousand other useful things to do.
> Now things like 1) timing the echo time on a sonar 2) measuring
> pulse width on accelerometers/gyros 3) taking A/D conversions on
> accelerometers/gyros 4) reading GPS sentences 5) etc. can be run
> concurrently with servo updates.
Were I doing all those ther things, I'd have a PIC dedicated to controlling
the servos. (I understand you can even buy such things ;-).) And I'd
program it using whatever technique was simplest to program. What saves me
effort not what saves the PIC effort. Writing a tight timing loop takes
less time than writing this paragraph. Setting up timers and interrupts
takes a lot longer. My time matters, the PIC's doesn't.
In this particular example (my biped), what else did the PIC have to do? It
had to send the servos though a sequence of positions - which took around
1% of it's time. It checked comms with the PC (around 1% of it's time). And
it had to check the two obstacle detectors (around 60% of it's time). An
obstacle detector works like this: charge a cap, discharge it through a
phototransistor, time the discharge, turn on an LED, charge the cap,
discharge it through a phototransistor, time the discharge, turn off the
LED. I've looked at doing the timing via interrupts and via a tight loop.
The tight loop can have variable timing resolution - you need more
resolution for shorter times, the response is logarithmic. Also the
interrupt would interfere with the servo timing. The whole point of an
interrupt is that it can happen at any time. I can't use interrupts for the
servos because they would interfere with the accurate timing of the
phototransistors. I can't use interrupts for timing the phototransistors
because they would interfere with the servos. By doing it all in tight
loops, I can keep complete control of the timing of everything. Perhaps I
could start turning interrupts on and off depending on what's currently
happening but that's getting awfully complicated and has no advantage.
I certainly can't use FSMs to do everything because the housekeeping
overhead means none of the timings would be accurate enough.
> Why more people don't get the FSM concepts, is a somewhat
> interesting point. As you say, it's not all that hard to do. It
> saves bundles of processor time.
I "get it". I know exactly how to write and use FSMs. Please stop implying
that the rest of us are stupid because we don't always use them. We don't
always use them because they're not always appropriate. I don't care about
processor time. If a project manager spends his entire life worrying about
processor time, you fire him. Programing time, design time and software
maintainance time are important. That's what "structured programming" is
about. And please don't say that FSMs are as easy to program or as
efficient in programming effort. They're not. That was proved in the 1970s.
That's why everyone sensible switched to structured programming. The 1970s
weren't an era when intellectual giants bestrode the world and nowadays all
that's available are dim-witted C++ programmers. "Structured programmers"
aren't less intelligent, they're more efficient. That's why their employer
pays them to do it that way.
Look, I've been programming for decades. I've used FSMs many times, I've
used interrupts many times and I've used dedicated timing loops many
times. I've known how to do all that stuff since (at least some of) the
people on this forum were in diapers. I know how to write programs that use
the processor's time efficiently and I know how to write programs that use
my programming time efficiently.
But most importantly of all, I know when to use which technique. There is
no One Size Fits All.