1st stage loader for IMSAI - need ascii to binary conversion
ard at p850ug1.demon.co.uk
Thu Feb 28 13:12:01 CST 2008
> > '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
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_
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.
More information about the cctech