'Easier
maintainabilty and tweakaility'. Surely you jest here!
Not at all. Read on and I will explain my position.
It is a
lot easier to find a fault in a circuit when you can actually put the
'scope probe on a particular signal. Darn it, with a single-chip
microcontroller, you can't normally trace the firmware.
In the context of a small microcontroller like the ones we're
talking about, these things just don't have that much code space.
Almost none of them allow self-modifying code. Nearly all of them
have small, simple instruction sets. If the programmer NEEDS to
actually trace the firmware to find a bug, I'd question that
programmer's competency. Seriously.
OK, so I;m an incompetent programmer. I'm happy to agree to that. Because
I certainly deug firmware (where possible) by hanging a logic analyser
off the address lines and seeing where the code is going. If you can do
it without, great!.
Let me give you an alaogy. _I_ once tracked down a logic fault in a P850
by noticing some odd behviour of the front panel bulbs, in particular
that half were brighter than the other half. Knowing that it's really an
8 bit machine interlally made me suspect that one half of the data wasn't
being latched properly. That lead me to a missing latch strobe signal,
and so on.
On the other hand, most of the time I use a 'socpe and/or logic analyser.
I like to debug by figuring out what the unit is doing and comparing it
with what it should be doing. And I like to debug firmware the same way.
I'd
much rather change a 2-lead passive compoennt than reprogram a chip
(and
it'll be quicker...)
Well, personal preferences aside, it might be quicker and it might
not. I can type "make burn" at a shell prompt in the terminal window
to the right of this email message and squirt an entire new code
I could do much the asme thing (admittedly on a different virtual console
trather than window, but...) And a good few minutes later, I'd have the
object code (remember I _don't have_ a fast PC).
image into the Philips ARM7 chip I'm working with
in less time than
it takes my (fast Metcal) soldering iron to heat up...and that code
image has BIG stuff in it like an IP stack.
On the other hand, my sodlering iron is hot right now :-)
bodging
together off-the-shelf units, which is another thing I
dislike...
...and I dislike it as well, and I'd never do it. Not everyone
who uses a microcontroller is boding together off-the-shelf units or
Of course not...
For the record I have used, and do use, signle chip microcontrollers. In
front of me is a little interface I built. On one side is a Centronics
printer connector that links to a PC parallel port. Coming out the front
is a cable ending ia a tiny 2-pin plug. That conencts to a modified HP41
barcode wand module (!). You hook it up. run a program on the PC whcih
takes an HP41 program and effectively simulates running the wand over the
barcode version of that prrogram. Result : Download from PC to HP41
without HPIL.
Now, that interface contains a few TTL chips to handle the Centronics
handshake and a microcontroller. It's sufficiently old that it's a
PIC16C84. TO do it all in TTL would have been very complicated, difficult
to debug, and so on. I feel that a microcontroller is the _right_
solution here.
Ditto for the HP48 RS232 port to I2C interface (just a PIC and a MAX232).
However, I still feel it's not the right solution to use a microcntoller
_and tone decoders_ to decode cassette audio. Doing the whole thing in a
microcontorller might be, but I probably woudln't do it that way. But to
combine the output of the tone decoders? No, I think it's overcomplicated.
-tony
