i/o extenders
Graham Stabler
Posts: 2,507
I'm looking for something to act as an IO extender. I want to load the output pins with certain values and then be able to make the all float or be low at once with another signal.
So it might go
0111011001
XXXXXXXXX
0111011001
XXXXXXXXX
etc. 8 bits would be OK, cascaded to 16 better.
Cheers,
Graham
So it might go
0111011001
XXXXXXXXX
0111011001
XXXXXXXXX
etc. 8 bits would be OK, cascaded to 16 better.
Cheers,
Graham
Comments
Are you taking about LATCHes ? like HC373,374,etc etc, paralel, or serial input like HC595.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
The other options look great but for this application I am really only expanding O not I, I should have realized I just needed a shift register.
Cheers,
Graham
Certainly this could be a bug in my 8255-driver Spin object, but I think I read somewhere that this is actually a design flaw of the 8255 itself. It has to do with the way you write control words to the chip, and the fact that Port C is not exactly the same as A and B. In two of the three types of 8255 operating modes, Port C only provides handshaking signals for Port A and Port B. The other mode, mode 0 (what my object uses) is supposed to allow Port C to be used as a third port with the same capabilities as A and B. And it does - as long as you don't change the I/O direction. Unfortunately, the control word register you must use to change the direction of one of the ports is also the same control word register you use to change from mode 0 to mode 1 or 2. Even if you don't actually ever use anything besides mode 0, I believe that when you write to the control word to change a port's I/O direction, it momentarily glitches the circuitry for mode 1 and/or mode 2, which sets Port C to the state the lines would be if you were handshaking rather than the states you previously set.
I ran into this problem just last night when trying to access RAM connected to the 8255. I would write values and then read them back. But when I changed the I/O direction from "out" to "in" so that I could read the RAM, it would change the Port C line connected to the RAM chip enable from high to low, and disable the RAM chip. I was quite unable to prevent this from happening.
Note that you would have to change a port from output to intput in order to make it tristate on the 8255, so for your application you will need to change directions.
If you use the 8255 and need to change the direction of a port while things are connected to another port, you have three options:
1) Not use Port C at all. Just use A and B.
2) Use some ports for input and some for output, and never change directions.
3) If you have more than one 8255 in the circuit, use the Port C from a different chip than the one you change I/O directions with.
Eventually I decided on "none of the above" - I took the 8255's out of my circuit completely. I feel kind of funny about it because I was the one who wrote the 8255 driver object, but I decided they were causing me more trouble than they were worth. I'm trying to do something I've never done before hooking up RAM and a 6502, and that's hard enough to do, but with the 8255's extending my I/O I was working through a second layer of indirection, and that made it that much harder to isolate where problems were.
After seeing what Mahjongg did with 74574's, I decided I'd be better off using latches. The 8255 incurs a lot of overhead to control it, and latches have the additional advantage of being simpler devices so it is easier to tell whether they are working right or not. I'm not using the same circuit for accessing RAM as Mahjongg's because I am also going to have a 6502 connected, but it definitely gave me the idea for replacing my 8255's with latches.
Other than the Port C glitch the 8255 object does work well and should not be hard to use. If you were doing something like reading a keypad matrix an 8255 would probably be fine. I've seen people drive multidigit 7 segment LED displays using the 8255. The 8255 is also designed for two microcomputers to use to communicate with parallel data, so it has special support for that. But as the person who wrote the object on the 8255, I'd say go with a latch instead.
Working on the 8255?
Does this mean your back from your little trip?
Graham
device type + 1 address + i/o state byte
data byte 1
data byte 2
Graham
You only need two inverters of a 74HC14 (hex schmitt-trigger inverter), and a resistor and capacitor, to split the control bits to drive both clocks
First, you use one inverter in between the I/O bit and the SRCK input. This makes the clock react to negative going flanks instead op positive going flanks.
Next, you also connect the output of this inverter to a resistor, of say 220 Ohm, the other end goes to one end of a capacitor (100nF) of which the other end goes to ground, with it you have created a "low pass filter".
You normally hold the output of the I/O bit high, and to clock in data into the shift register you use short low going pulses, on the low going flank of the pulse the data on the other I/O pin is clocked into the shift register, but the pulses are too short to affect the output off the low pass filter, which stays low all the time (remember, there is an inverter in between the I/O pin that is normally high and the low pass filter).
the output of the low pass filter goes to the input of the other schmitt-trigger inverter, and it's output goes to the RCK (latch clock) pin.
Because of the shortness of the SRCK clock pulses the output of the second inverter will stay high.
Now the trick is that the last of the eight SRCK clock pulses should be elongated so long that the output of the RC filter rises above the threshold of the second inverter, so on the low going pulse of this longer clock signal the last bit is shifted into the shift register, and on the rising edge of the elongated clock the byte is latched into the output latch.
So you can clock in seven bits into the shift register with short low going pulses, and clock in the eight bit in on the low going flank of a longer eight clock pulse, and latch it into the output register on the up going flank of the same longer pulse.
Mahjongg
I wonder how much slower it is than dediticated logic for things like tieing in sram, etc. A fairly common way to connect them and boot them would be handy also. Anybody done this?
Thanks,
Doug
they are smart. I'm thinking of how we can come up with the minimal circuitry to boot another prop from a
"master" prop.
A6833
DABiC-5 32-Bit Serial Input Latched Sink Drivers
from Allegro Microsystems Inc.
Jim