Connect with us

Problem with 8255 PIO design

Discussion in 'Electronic Design' started by Udo Giacomozzi, Aug 27, 2007.

Scroll to continue with content
  1. 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
     
  2. 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
     
  3. mpm

    mpm Guest

    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
     
  4. 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
     
  5. Kryten

    Kryten Guest

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

    Jamie Guest

    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.
     
  7. 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.
    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.
     
  8. 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
     
  9. 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
     
  10. We can't program FPGAs and unfortunately I know no alternative to the
    8255 chip. Do you perhaps?

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

    Udo
     
  12. 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).
    I'll try to contact them and hope they will respond. Perhaps you
    remember where you found that Q&A section?

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

    Thanks,
    Udo
     
  14. Joel Kolstad

    Joel Kolstad Guest

    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.
    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
     
  15. Joel Kolstad

    Joel Kolstad Guest

    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
     
  16. Intel does not make them anymore. But there are 3rd party vendors that do. Beware the 3rd party chips are not exact
    replacements.

    Cheers
     
  17. 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
     
  18. Chris Jones

    Chris Jones Guest

    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
     
  19. 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
     
  20. We tried it, but the voltage drops for about 3 µs and our logic
    notices this, unfortunately.

    Udo
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-