i/o extenders

Graham Stabler

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

lairdt

Why not run an MCP23016 i2c 16 pin IO expander? Sample code already in the Prop examples...

BTX

Graham.
Are you taking about LATCHes ? like HC373,374,etc etc, paralel, or serial input like HC595.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

T&E Engineer

I like the 8255 chip approach (24 outputs / inputs). Dennis F. has already written spin code for it.

Graham Stabler

BTX, serial. Sorry I was not clear. The HC595 looks absolutely perfect for my needs, thanks!

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

Dennis Ferron

One thing to note with the 8255 - it has 3 ports, A, B, and C, but if you change the input/output direction of A or B, it clears your port C outputs to all zeros!

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.

T Chap

I just used the I2C PCF8575 16 i/o expander, vey simple to use. 8 of them can be addressed on 2 pins. I have some code if you want to try it out.

bambino

Dennis,

Working on the 8255?

Does this mean your back from your little trip?

Graham Stabler

I need to be able to make the whole port float and switch it from its floating to set state at high speed. The states will not change most of the time. Essentially it is to replace a set of dip switches and an open collector buffer.

Graham

T Chap

May or may not possible with the PCF8575 depending, it requires pullups if any real current is required, so you are stuck with either a high or a low with pullups. If your outputs were ONLY going to require a LOW or FLOAT, then it is fine, it could switch that rather quickly. Depending on what you are driving, the high output power may actually be enough to hold other logic chips up, in which case you could get tri state without the pullups, output= low, output = weak high, and input. The IC is extremely easy to use, and I could send you the code and it would be plug and play. All you do is send it 3 bytes. You can put 8 x 16 i'os on two pins.

device type + 1 address + i/o state byte
data byte 1
data byte 2

Graham Stabler

I need them to switch instantly not after communications, the HC595 is perfect for what I want, that or the 596 and is even simpler to drive requiring no I2C. Not to mention it will be part of an assembly program.

Graham

mahjongg

Graham, if I may give you a tip, its possible to drive both the SRCK (shift register clock, pin 11) and the RCK (latch clock, pin 12) with the same output I/O bit, so you need only two control bits, one connected to the serial input bit (pin 14), and one control bit that controls both the SRCK and RCK clocks.
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

hinv

Why not just tie in another propeller chip. I know they are expensive for large runs to have more than 1, but it solves a lot of problems. You get more IO lines, 32KB memory, more cogs, etc. It keeps things simple also because you really only have to learn 1 IO interface.
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

rokicki

I was just thinking the same thing on the way home tonight. They aren't cheap, but they are *super* flexible, and
they are smart. I'm thinking of how we can come up with the minimal circuitry to boot another prop from a
"master" prop.

Mike Green

Chip posted a Spin program some time ago that would do just this. It involves using 3 I/O pins on the "master" to connect to reset and I/O pins 30/31 on the "slave". The program to transfer gets incorporated using the "FILE" declaration, but you could read it off an SD card or from extra EEPROM on the "master".

JTC

· Here is a nice interface chip that works on 3.3v.

A6833
DABiC-5 32-Bit Serial Input Latched Sink Drivers

from Allegro Microsystems Inc.

Jim