Problem with 8255 PIO design

[Udo Giacomozzi]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The 8255 currently is controlled via the ISA bus of a PC/104 board.
Note we can't use an additional PC/104 doughter board because of lack
of space (and costs).

Thanks for any hint,
Udo

 

[petrus bitbyter]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The 8255 currently is controlled via the ISA bus of a PC/104 board.
Note we can't use an additional PC/104 doughter board because of lack
of space (and costs).

Thanks for any hint,
Udo

It has been quite some time I used a 8255 but I remember a port could be set
to bidirectional mode. Once you'd done so, there was no need to write to the
control register for changing input to output. Guess you have to study the
datasheet a little more carefull. Details are pretty well explained in it.

petrus bitbyter

 

[mpm]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The 8255 currently is controlled via the ISA bus of a PC/104 board.
Note we can't use an additional PC/104 doughter board because of lack
of space (and costs).

Thanks for any hint,
Udo

No similar 8-bit, 3-port PIO that I know of, but don't take my word
for it.
Maybe some of the old Z-80 / 8085 / VIC-20 stuff?

I must say I'm a bit suprised anyone would design with this part
anymore.
It is still in production? Just curious.

I do have several 8255 books at the office. (Like 20 of em collecting
dust).
Even some of the original documents from 25-30 years ago.
I'm sure this exact topic will be addressed, so I'll give it a quick
look tomorrow if that will help.
Something tells me there's a difference between the word "port" and
the actual "pins".
But I might just be thinking about writing 1's to later read the
actual pin status.

-mpm

 

[Martin Riddle]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The 8255 currently is controlled via the ISA bus of a PC/104 board.
Note we can't use an additional PC/104 doughter board because of lack
of space (and costs).

Thanks for any hint,
Udo

Yes the 8255 resets the port state if the direction is change. There is no known workaround.
Besides its an obsolete part. Your better off using a FPGA or someother programmable logic.

Cheers

 

[Kryten]

Yes the 8255 resets the port state if the direction is change.
There is no known workaround.
Besides its an obsolete part.
You're better off using a FPGA or some other programmable logic.

Perhaps the OP could use a 44-pin CPLD to work as an 8255 without the
problematic behaviour.

 

[Jamie]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The 8255 currently is controlled via the ISA bus of a PC/104 board.
Note we can't use an additional PC/104 doughter board because of lack
of space (and costs).

Thanks for any hint,
Udo

try restoring the output values right after you write the control reg.
If memory serves, I think the output retains level long enough if you
reset the output values as the next step after writing the control reg.
you most likely will only see a very short and small dip in the levels.

 

[Tony Williams]

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

Yes. I got ambushed by this. Solved it with
external hardware, but if I had used the correct
pins I think it could have been solved by running
Port A in mode 2..... see below.

So, when we want to toggle the *direction* of port A (the one
used for the bidirectional bus), all *outputs* of ports B and C
will be reset as well!

When Group A is run in mode 2 then Port A becomes
a bidirectional I/O, whose direction is controlled
and signalled externally, by some pins on Port C.

For example.

PC6: /ACK (Acknowlege). "A low on this input enables
the tristate output buffer of Port A to send out the
data. Otherwise the output buffer will be in the high
impedance state.".

PC4: /STB(A). "A low on this input loads data into
the input latch".....of Port A.

In Mode 2, PC0/1/2 are general purpose I/O so two of
them could be connected back to PC6 and PC4 to fake
the required /ACK and /STB signals to control Port A.
Note that pulldowns on PC0/1/2 and inverters to PC6/4
are required in order to make the logic sensible
during POR and Mode Writes to the control register.

Port C spare bits are suggested because any individual
o/p pin of Port C can be altered by the Bit Set/Reset
command which is a Write to the control register that
does *not* alter the state of any other output pins.

Read Mode 2 carefully and see if you come to the same
conclusions.

 

[Roger Hamlett]

Yes the 8255 resets the port state if the direction is change. There is
no
known workaround.
Besides its an obsolete part. Your better off using a FPGA or someother
programmable logic.

Cheers

Has the poster considered asking Intel, if the latter versions have this
exact behaviour?. There was a note about this behaviour in the Intel 'Q&A'
section years ago, but I seem to remember that the HC version of the chip
when it was launched (which is what you will now probably get...), had
this changed, with the behaviour only occuring on reset, not on
reprogramming. It'd be worth asking them.

Best Wishes

 

[Udo Giacomozzi]

It has been quite some time I used a 8255 but I remember a port could be set
to bidirectional mode. Once you'd done so, there was no need to write to the
control register for changing input to output. Guess you have to study the
datasheet a little more carefull. Details are pretty well explained in it.

I understand that mode 2 might solve the problem, but unfortunately I
can't sacrify any of the port B & C pins, and the mode 2 trick would
require nearly all of port C pins for handshake..

Udo

 

[Udo Giacomozzi]

Yes the 8255 resets the port state if the direction is change. There is no known workaround.
Besides its an obsolete part. Your better off using a FPGA or someother programmable logic.

We can't program FPGAs and unfortunately I know no alternative to the
8255 chip. Do you perhaps?

Udo

 

[Udo Giacomozzi]

Perhaps the OP could use a 44-pin CPLD to work as an 8255 without the
problematic behaviour.

You mean an FPGA? Yes, that would be interesting, but we can't do that
ourselves (and had bad experiences with those)..

Udo

 

[Udo Giacomozzi]

Has the poster considered asking Intel, if the latter versions have this
exact behaviour?.

We're not even using an Intel chip. Our model is made by Intersil. But
anyway all datasheets (no matter if Intersil, Philips or Intel)
describe this detail (actually the text is mostly identical).

There was a note about this behaviour in the Intel 'Q&A'
section years ago, but I seem to remember that the HC version of the chip
when it was launched (which is what you will now probably get...), had
this changed, with the behaviour only occuring on reset, not on
reprogramming. It'd be worth asking them.

I'll try to contact them and hope they will respond. Perhaps you
remember where you found that Q&A section?

Thanks,
Udo

 

[Udo Giacomozzi]

try restoring the output values right after you write the control reg.
If memory serves, I think the output retains level long enough if you
reset the output values as the next step after writing the control reg.
you most likely will only see a very short and small dip in the levels.

Ok, I'll try that. I really hope the output levels don't drop
completely as it controls some fast logic.

Thanks,
Udo

 

[Joel Kolstad]

You mean an FPGA?

CPLDs are relatives of FPGAs (both are programmable "logic," CPLDs are usually
big AND-OR arrays whereas FPGAs are usually "seas of look-up tables and
registers" in a more "fine-grained" arrangement). Also, most CPLDs tend to be
non-volatile whereas most FPGAs aren't, but there are plenty of exceptions.

Yes, that would be interesting, but we can't do that
ourselves (and had bad experiences with those)..

If you want I'm sure we could point you to someone who could design an 8255 in
a CPLD for you and just sell you the programmed parts. Would that work?

Implementing an 8255 in programmable logic is very much an undergraduate's
school exercise these days -- it's not at all difficult.

---Joel

 

[Joel Kolstad]

If you want I'm sure we could point you to someone who could design an 8255
in a CPLD for you and just sell you the programmed parts. Would that work?

What I really mean here is that they could design you an 8255 without the
"data port resets to zero on data direction register change" "feature."

How much are you paying for 8255s now? And what quantities? There are folks
here who'll be able to tell you immediately if a CPLD would be competitive
price-wise.

---Joel

 

[Martin Riddle]

Has the poster considered asking Intel, if the latter versions have this exact behaviour?. There was a note about this
behaviour in the Intel 'Q&A' section years ago, but I seem to remember that the HC version of the chip when it was launched
(which is what you will now probably get...), had this changed, with the behaviour only occuring on reset, not on
reprogramming. It'd be worth asking them.

Best Wishes

Intel does not make them anymore. But there are 3rd party vendors that do. Beware the 3rd party chips are not exact
replacements.

Cheers

 

[petrus bitbyter]

I understand that mode 2 might solve the problem, but unfortunately I
can't sacrify any of the port B & C pins, and the mode 2 trick would
require nearly all of port C pins for handshake..

Udo

Can't but say that your requirements are apparently beyond the capabilities
of the old 8255. So you will need either additional hardware or other
hardware. What funtionallity do you really need? Can hardly be all of the
8255s as several setups are mutual exclusive. Once you have a good
specification, it will be easier to look for possibilities.

petrus bitbyter

 

[Chris Jones]

Hi,

we wanted to use the 8255 for a relatively simple design. It seemed
that the 8255 has three independent 8bit I/O ports so we used one port
for a (slow) bi-directional bus and the other ports for other
purposes. We already have the prototype but the design is invalid
because of this one little sentence in the whole data sheet:

"Any port programmed as an output port is initialized to all zeros
when the control word is written."

So, when we want to toggle the *direction* of port A (the one used for
the bidirectional bus), all *outputs* of ports B and C will be reset
as well! This makes the 8255 completely useless for our purposes (we
need the other outputs to stay unchanged).

Any can propose a workaround for this? Since we want to avoid adding
much additional logic: Is there a similar near-24 bit I/O chip that
would be useful for our needs?

The closest I can think of is the old 6522, as used for the printer and user
ports of the BBC microcomputer.
http://en.wikipedia.org/wiki/MOS_Technology_6522
Apparently it has bugs too, and has only 16 bits of IO.

Chris

 

[Udo Giacomozzi]

If you want I'm sure we could point you to someone who could design an 8255 in
a CPLD for you and just sell you the programmed parts. Would that work?

Yes, that would be an interesting option. Unfortunately we're on a
tight time line and redesigning the circuit would make us loose 1-2
weeks.

We found a different solution that does not require electronic
modifications.

Port A, which we need to be bidirectional, is set to output all the
time. According to Intel (and 3rd party clones seem to match) the
"read" operation on that port always returns the physical state on
these pins, not any internal shadow register or similar. So, when
pulling the pins to high or to low, the state returned by the "read"
operation will follow it instead of the voltage applied by the 8255
itself. With other words, we just have to "read" or "write" to the
port without changing it's direction.

It may be more clear to you if you look at the "schematic" for the
pins on port A. See http://www.dsi.unifi.it/~nesi/8255.pdf at page 4.

I'm a software engineer, not a electronics specialist, (and the idea
wasn't mine) but you probably will see immediately how the components
will play together in the described configuration.

We tried this trick and it works well.

Of course we might change the schematics design for the next version
for which we have a couple of additional weeks to prepare. I like the
FPGA idea but we don't have neither the tools nor the knowledge to
program a FPGA. Our partner company which designs our boards doesn't
either. Once a engineer designed a FPGA for us (different project) but
it was a nightmare and didn't work as expected.

Udo

 

[Udo Giacomozzi]

try restoring the output values right after you write the control reg.
If memory serves, I think the output retains level long enough if you
reset the output values as the next step after writing the control reg.
you most likely will only see a very short and small dip in the levels.

We tried it, but the voltage drops for about 3 µs and our logic
notices this, unfortunately.

Udo