9 Jul
2006
9 Jul
'06
2:27 p.m.
Tony Duell wrote:
[8255 POR/initialization issues]
Your external circuit has to be happy with this (it
can't assume the line
will stay high as the chip is initialised). The other parallel chips
(e.g. 68721, 6522) don't have this problem, with those, you can write to
the output port register and make outputs effectively 1 _before_ writing
to the direction register. Then if you have an exetrnal pull-up, or
assume a TTL input floats high (naughty!), you will not get a momentary
low glitch on the line.
There have been (and will undoubtedly CONTINUE to be!) lots
of "bad" peripheral chips designed with this and other SNAFUs.
It is good practice to separate the I/O's from the rest of
the system if you want a reliable product (i.e. things
that run 24/7/365 without intervention). I regularly
"or" a reset line that the processor can control into the
RESET_IO signal (not all processors have the ability
to *drive* their RESET line) for exactly this reason.
You *really* don't want something that is controlling,
for example, motors or hydraulics on a piece of industrial
equipment to *rely* on the processor powering up properly
and completing the initialization of the I/O's "correctly"
("Hey, who's FINGER is this stuck in this 15 ton press?")
Just like you don't want to rely on the processor to poll
the status of interlock/safety switches, etc.
Of course, this makes the hardware design a bit more
involved (e.g., you have to ensure you pick latches
that can be forcibly reset, etc.). Which can be an
issue on low cost products.
Does the 8251 USART also have some sort of
strange initialization problem?
It's been a long time since I've used one, but I seem to recall a gotcha.
IIRC, it's impossible in gnneral to force it into a known state. If
you're setting it up for synchronous operation and forget how many of the
initialisation bytes you've sent it, there's no software way to force it
into a known state from where you can start the initialisation again (a
hardware reset will do it, of course).