Bug in Intel 82C55A chip?
Tom Crane
Does anybody agree with me that the following is a bug?
I have a project using an Intel 82C55A Programmable Peripheral Interface chip
on a PC card slotting into the ISA bus. I'm using the chip's PORT-A as an 8bit
input & output port to communicate with some external instruments. I'm also
using bit7 of PORT-C as a 'data valid' line to accompany the PORT-A data,
according to an in-house software protocol for driving those external
instruments. The 'data valid' line is always set to an output - ie. PC -to-
external instrument.
The 82C55A's !CS, A0, A1, !RD, !WR & RESET signals are all driven in a
conventional fashion via some glue logic from the ISA bus.
The chip is being used in its 'Mode 0'. My 'data valid' Pc7 signal is operated
using the 'Single Bit Set/Reset Feature' - that is by writing 0x0F and 0x0E to
the 'Data Bus Control' register. I initialise PORT-A and PORT-C/Hi nybble to
outputs by writing 0x81 to the 'Data Bus Control' register. Turning PORT-A to
an input while retaining PORT-C/Hi nybble as an output is achieved by writing
0x91 to the 'Data Bus Control' register. So far so good.
The problem, that is really messing up our in-house software protocol, is that
when the 0x91 command is written to change PORT-A to an input, a spurious
Lo-transition appears on the 'data valid' Pc7 line. My reading of the datasheet
is that with bit7=1 in the 0x91 being written to the 'Data Bus Control'
register, the chip has no business changing line Pc7, since the 'Single Bit
Set/Reset Feature' requires bit7=0. I have verified the behaviour is as
described by attaching a logic analyser to the 82C55A. I have also tried a
second chip and also one from different manufacturer - same results.
I've not used this particular chip before but I'd definitely label this a
bug...
Comments anybody?
Thanks
Tom.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: uha...@vms.rhbnc.ac.uk
SPAN: 19.875
Fax: 01784 472794
Richard Webb
conclusion. I studied the Intersil datasheet for this device. I have used
this IC many times on ISA cards but have never changed the data direction of
a port 'on the fly.'
The Intersil datasheet states (Page 5 - top of page) that All the output
registers, including the status flip-flops will be reset whenever the mdoe
is changed. Now, as far as I can see you are not changing the mode (your in
mode 0 all the time) but you are changing the port directions, so it can
only be presumed that the 8255 is taking this as a mode re-definition and is
reseting your Port C. You do not say if other spurious changes are occuring.
The datasheet gives no definite answer on this matter, but the datasheet
entirely presumes you will not be changing port direction often. The
simplest solution that springs to mind for me is to change to a 6522 rather
than 8255. Or even better still something with a bi-directional bus. So why
not make your own glue logic and interface directly to the ISA bata bus with
a tri-state buffer? (Chip select address decoding becoming your data
valid??)
Just some thoughts.
"Tom Crane" <uha...@alpha1.rhbnc.ac.uk> wrote in message
news:C8JbNo...@mail.rhbnc.ac.uk...
Rich Grise
>
> Dear All,
> Does anybody agree with me that the following is a bug?
>
> I have a project using an Intel 82C55A Programmable Peripheral Interface chip
> I've not used this particular chip before but I'd definitely label this a
> bug...
>
> Comments anybody?
>
> Thanks
> Tom.
It's a "feature." Buried on page 5 of the intel data sheet, paragraph
2 (or 3 or 4, depending on how you count the bullets):
82C55A OPERATIONAL DESCRIPTION
Mode Selection
There are three basic modes of operation that can
be selected by the system software:
Mode 0 Ð Basic input/output
Mode 1 Ð Strobed Input/output
Mode 2 Ð Bi-directional Bus
When the reset input goes ``high'' all ports will be set
to the input mode with all 24 port lines held at a logic
``one'' level by the internal bus hold devices (see
Figure 4 Note). After the reset is removed the
82C55A can remain in the input mode with no addi-
tional initialization required. This eliminates the need
for pullup or pulldown devices in ``all CMOS'' de-
signs. During the execution of the system program,
any of the other modes may be selected by using a
single output instruction. This allows a single
82C55A to service a variety of peripheral devices
with a simple software maintenance routine.
The modes for Port A and Port B can be separately
defined, while Port C is divided into two portions as
****** Note:
required by the Port A and Port B definitions. All of
^^^^^^
the output registers, including the status flip-flops,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
will be reset whenever the mode is changed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**********************
This is probably what's screwing you up - every time
you switch port A from input to output or back, it
resets all the control lines and everything. Good ol'
intel, eh?
Anyway, you might want to try running port A in full
bidirectional mode. A PITA, I know, but it's about
the best you can do (unless you use A for input
exclusively and B for output exclusively, which is
still a PITA.)
Hope This Helps!
Rich
Tony Williams
Rich Grise <rich...@vel.net> wrote:
[snip]
> When the reset input goes ``high'' all ports will be set
> to the input mode with all 24 port lines held at a logic
> ``one'' level by the internal bus hold devices (see
> Figure 4 Note). After the reset is removed the
> 82C55A can remain in the input mode with no addi-
> tional initialization required.
It's a murkier can of worms than that.
The original Intel 8255 had no bus hold devices.
The Intersil 82C55A does have bus hold devices.
The OKI MSM82C55A does not have.
I don't have a data sheet for the OP's Intel 82C55.
I can't imagine what went on in the mind of the
clever-clogs who 'improved' the 8255 with a pullup
default to logic-1 on Reset, versus a default to
logic-0 when the command register is written-to
(when D7=1)..... why didn't he 'improve' it with
pulldown devices?
--
Tony Williams.
Tony Williams
Tom Crane <uha...@alpha1.rhbnc.ac.uk> wrote:
> The problem, that is really messing up our in-house software
> protocol, is that when the 0x91 command is written to change
> PORT-A to an input, a spurious Lo-transition appears on the
> 'data valid' Pc7 line.
[snip]
> I've not used this particular chip before but I'd definitely
> label this a bug...
We've all been caught by it.
It's a 'design feature'. All writes to the
command register with D7=1 will cause all pins
programmed as outputs to be Reset (to 0v).
You have to put an inverter after PC7 and invert
your driving logic. Also put a pulldown resistor
on PC7, so that at POR/Reset (and before you have
configged the 82C55) it comes up safely signalling
not-data-valid.
But beware of the 'improved' Intersil 82C55A. That
one still does the 'design feature' but also has
inbuilt active pullups that are ON at POR/Reset.
The OKI Semiconductor MSM82C55A does not have those
silly pullups, does have the Reset-on-command-write
'feature', but only operating on Ports A and C.
--
Tony Williams.
Tom Crane
My thanks to all who followed up on this.
> It's a "feature." Buried on page 5 of the intel data sheet, paragraph
> 2 (or 3 or 4, depending on how you count the bullets):
> ****** Note:
> required by the Port A and Port B definitions. All of
> ^^^^^^
> the output registers, including the status flip-flops,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> will be reset whenever the mode is changed.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> **********************
>
> This is probably what's screwing you up - every time
> you switch port A from input to output or back, it
> resets all the control lines and everything. Good ol'
> intel, eh?
Absolutely! I can see now that this is indeed the source of my problems. In the
end I was able to slightly modify the S/W without violating our in-house
protocol. Thankfully, simply sending the command to change PORT-A to an input,
only when Pc7=Lo avoids the effect of the flip-flop reset.
IMO the really bad part is the datasheet. It is more than misleading but
actually wrong when is says "will be reset whenever the mode is changed.". If
it read "will be reset whenever the Control Word register is written with
Bit7=1" that would be OK.
Regards.
Richard Erlacher
port C the one intended for bidirectional use?
Maybe the device behavior won't be such a PITA if you consider what
teh designer's intent was.
Dick
On 22 Feb 01 18:53:08 GMT, uha...@alpha1.rhbnc.ac.uk (Tom Crane)
wrote: