??? 10/17/06 21:33 Read: times |
#126611 - I'll try it, too Responding to: ???'s previous message |
Now ... keep in mind that I have never been a great advocate for the 8255 or its corresponding equivalent in the Motorola camp, the MC6821. This was, however, because these devices had such weak output that one normally had to buffer them just to do anything at all. With today's CMOS technology, that's no longer the case and these devices' CMOS incarnations can do useful work without external buffering, though it may still be required in some applications.
About Jan's subject FAQ entries ... let's look at the first part ... and pick it apart, bit by bit ... Jan's FAQ said:
How do I interface an 8255 to an 8052? Submitted By: Craig Steiner FAQ Last Modified: 12/Oct/06 9:58 am The functionality of an 8255 port can be easily duplicated. An input port can be provided by a standard 74HC244 type buffer chip. At output port can be easily implemented by using a 74HC374 type latch. If you need a port that can be set back and forth between input and output then consider using a chip like the 74HC646. All of these solutions will be particularly suitable if you are using the 8052 with an expanded external bus mode (just as you would have connected an 8255 chip) and the chips connect to the data bus AD0 to AD7 lines. The control lines for the chips are wired to a decoding circuit that combines an appropriate combination of the address lines, the RD/ and the WR/ control signals. This begins with a statement that is only partially true. The port function itself is readily reproducible, with either a tristate register such as the '374/574 type or with a totem-pole output registers such as the '273. A tristate buffer such as a 74HC244, or 'HC541, can serve very well as an input port, though one might want a tristate latch, e.g. HC573 in order to allow a remote source to write to the latch without requiring immediate service by the MCU. Each type has some benefits over the others. The inherent problem is that, once in the circuit, any of these types can operate in only one mode. While a board designer who's been given specific requirements can design a port with the specified port type, e.g. totem-pole output, tristate output, bidirectional, or input. Once the port is built, that's all it can do. The designer of a board for undefined application, e.g. a commercial controller board, in this case, using an 805x MCU, might want the additional flexibility that a versatile I/O chip provides. It's possible, certainly, to create the facilities provided in the 8255 in a number of ways, they're definitely not simple and straightforward. There's room for debate about whether they're attainable at lower cost, though. One aspect that hasn't been discussed much is the handshaking and interrupt generation capability of the 8255. The 8255 provides three ports, of which one, "Port C" can be split into two halves, and those used as handshake and interrupt signals associated with ports A and B. The Motorola parts don't have a "C" port, and just provide dedicated handshake and interrupt signals. In both cases, these signals are observable externally or through an internal register. The use of discrete registers, latches, an/or buffers for these functions forces the designer to choose in advance of deployment, how the end-user will be able to utilize the ports. This has, in some cases, been done quite effectively by means of jumpers, but some people, and I may not be among their number, prefer to configure the port with firmware. I seldom have an uninterrupted hour in which to do this sort of thing, but I'll soon post an SCH3 and SCH4 jpeg file to represent a single I/O port, i.e. one with an 8-bit data channel, configurable as input, output, with handshaking and interrupt control as they'd be implemented in discrete HC-logic components, to do probably not all of what an 8255 or 6821 will do. This type of parallel port interface addresses a class of problem that is always a bit complex, in that one frequently needs to "talk" to an I/O device that once talked to another computer that had the facility to interface with it, but that computer is no longer available, yet the data stored in it or on its media is still of interest. These typically had an 8- or 9-bit bidirectional data channel, as well as command/status signals and handshakes in both directions, and often had quite stringent data transfer timing requirements. Features such as automatic handshaking, interrupt generation and latched inputs made this interface type work smoothly despite any asynchronism between the computer and the peripheral. Since the 805x has no "wait" line to facilitate synchronization between source and destination in such transfers, auto-handshaking and interrupt generation can "save the bacon" in cases where time is critically limited. I see problems of this sort quite often, as people come to me with devices that contain data that they want, but can't retrieve because their PC can't communicate with that kind of hardware. Perhaps that's why I'm so insistent on keeping the possibility of parallel interfacing by means such as the 8255 in mind, rather than discarding it out of hand. If you use a board with 8255's on it, you can do this stuff with a minimum of wiring and circuit design. You're then free to focus on the remainder of the task. RE |