Problem with 8255 PIO design

"Udo Giacomozzi" schreef in bericht news: snipped-for-privacy@g4g2000hsf.googlegroups.com...

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

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

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

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

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.

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

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.

--
Tony Williams.

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

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

known workaround.

programmable logic.

We can't program FPGAs and unfortunately I know no alternative to the

8255 chip. Do you perhaps?

Udo

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

Udo

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

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

Thanks, Udo

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

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

programmable logic.

behaviour?. There was a note about this

the HC version of the chip when it was launched

behaviour only occuring on reset, not on

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

Cheers

"Udo Giacomozzi" schreef in bericht news: snipped-for-privacy@k79g2000hse.googlegroups.com...

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

The closest I can think of is the old 6522, as used for the printer and user ports of the BBC microcomputer.

Apparently it has bugs too, and has only 16 bits of IO.

Chris

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

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

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

Udo