How to properly use a 74259 (addressable latch)

Well, basically I have 8 lines that I can set to high/low...but they're set in parallel. I need a circuit that does the following:

Three of my data lines go to the ABC pins and 1 go to the D pin Drop G for some small period of time Raise G Move on with life The address/data lines need to be held while G is dropped.

How are you going to change the abc address lines?

If its done at full speed you would simply setup the timing so that G is high for probably 10 ns, maybe a really long wait of 30ns. Assuming the control logic is stable and doesnt bounce, if the enable or G line can bounce around 1.5v then all bets are off

Why is there a sudden rash of using TTL parts? 74HC259 is a far superior part for glitch-free operation.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

This used to be one of my favorite parts. I always made WR* or DS* as part of the Chip Select. You just have to be sure you end up with enough Address and Data hold time.

Tam

Yeah- well hold them then- what's your problem?

ah okay. So what should work is you do this in steps, make G high, then with G high send out the abc lines and data, then send out G low then high

The typical 259 chip can operate rather fast, so no extra delay should be needed

if done with a byte, you could assign them

b0 equ G b1 equ Data b2 equ adr a b3 equ adr b b4 equ adr c

start by or'ing b0 =1 then b0 =1, with other bits set then b0 = 0, keeping other bits set then b0 = 1

so you should not need any delay. the only exception is if the data lines are noisy

Beats me. I took 74259 as generic for 74X259. I used the HCT.

Tam

I've done some tinkering with the 74HCT259 chips (were available at Radio Shack until recently) in the multiplex mode and in the latch mode. I've been controlling them via the parallel port as well as a serial to parallel chip. I write a byte to the parallel port to set the A0, A1, A2, and D (data) lines, then write a byte that has the same lines high along with the LE (latch enable) line high. I then write another byte to the parallel port identical to the first byte. This has the effect of setting the A and D lines as desired, then clocking the LE line high and then low. This latches the chip outputs as desired. If you need to drop the latching line low before the A and D lines, then you might could put a .1mf capacitor on each of the A and D lines connected to ground, and a 10k resistor on the latch line to ground. This might allow the latch line to go low before the A and D lines. You probably could use the 3 byte method with your gizmo just as with the parallel port. Below are a couple of pages with some of the 74HCT259 tinkering I've done. Not fancy, but they work.

Ok, let me explain my situation a little better:

I have the USBMOD4 device that receives 8 bits that control 8 TTL lines (D0-D7). I am creating my own bus (to sit on top of USB) by using a comparator or a 4:16 selector (if I can find one) to decode D0-D3 as the address of each device on my bus. I'm left with D4-D6 to handle the address for the latch, and D7 to be the data for said address on the latch.

The G pin on the latch needs to stay high, only dropping when a bit is determined to go into the latch. So, I will wire D4-D6 to ABCD, and use the output of the comparator to drop G. If the comparator drops G before the ABCD lines are set up, I've mangled the data in the latch. I was thinking of using a one-shot to delay the G drop so I'm guaranteed to have ABCD set up first.

The thing to note is that I cannot change D0-D7 from the computer; the device receives a byte and sets the lines.

In the absence of any other input, you will have to do *something* to make the decoded D0-D3 change, or else, for example, you have no way of latching successive writes to the same destination. So you will have to do dummy writes to more than one destination address. Once you get this straight, then you would use the decoded D0-D3-> small RC>> worst case Tpd and settling of ABC- to trigger a one-shot with output to G. The

74HCT123 has Schmitt trigger B and /A inputs- drive B with RC time constant of 10u, this would be R=10K C=1n, /A and /CLR to GND, RT=10K, CT=220p, /Q of 123 to '259 G. Terminate unused inputs on other half of 123. If the D0-D3 decode out is active low then use /A for input and tie B to Vcc.

lines

a

as

handle

on

is

and

drops G

latch.

the

of

to

this

case

RT=10K,

of

tie

Ok, I change the data lines, but not individually. So, I can't set up D4-D7 and then strobe D0-D3 to drop G.

Sorry for the confusion.

I can't be guaranteed that the lines are held between writes, as they are 2-way. Who knows.

I'd rather find a hardware solution, anyhow.

As for the READ pulse, I saw an example of where they wired up a cap between a RD and RXE pin. It seemed to work for the author; I'll have to experiment.

Gizmos that I'm familiar with that are similar to the USBMOD4 (including the parallel port) hold output line states as is when successive writes to them have the output line in the same state. An example of this would be writing a byte to the USBMOD4 to make its D0, D1, D2, and D3 high. Then the next byte sent to the USBMOD4 makes D0, D1, D2, D3, and D4 high. Then the next byte sent to the USBMOD4 (same byte as the first) makes D0, D1, D2, and D3 high, with D4 going back low. During these byte writes, D0, D1, D2, and D3 stay high with out change, with the net effect of D4 being clocked high and then low. If this is the way the USBMOD4 actually works, then you can individually control ~120 lines hi/lo using 17 74HCT259 chips. That is what is going on at the below link. I assume your 74259 chip operates similar to the

74HCT259 chips I use.

"sryth" schreef in bericht news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

Why is that? If your dataword is D0-D7 you could do this:

D0 D1 D2 D3 D4 D5 D6 D7

0 0 0 0 1 0 1 0 -> setting up D4-D7 1 1 0 0 1 0 1 0 -> setting up D4-D7 with the same data, and D0-D3 0 0 0 0 1 0 1 0 -> setting up D4-D7 with the same data, and D0-D3

0 0 0 0 0 1 1 0 -> setting up D4-D7 with new data

1 1 0 0 0 1 1 0 -> setting up D4-D7 with the same data, and D0-D3 0 0 0 0 0 1 1 0 -> setting up D4-D7 with the same data, and D0-D3

Just use more write cycles. You can do it in two cycles, but I don't know on which edge your D0-D3 decoder/latch works.

Unless you need all the speed you can get and can't afford two write cycles.... I see that the USBMOD needs a READ pulse too, to retrieve data from the FIFO. How is that done in your circuit?

--
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)

I looked at the FTDI chips a while back, and found simple protocol info pretty much lacking. The USBMOD4 user manual sucks as far as telling how to use the device. If you already have spent $$$ for one of the devices, then connect a multimeter to the output lines and see what happens. Do a google search for USBIO24V3ds1.pdf and read the info for it. Apparently you set the lines for input or output, then either read them or write bytes to them. If you are just looking for output, then consider a simple serial to parallel output chip like below.

bit

to

way

have

The

half

and

up

1,

then

I already said that I was thinking of just using a one-shot to drop G after a small period of time. My original post asked about the reliability of using a simple RC circuit to do it. Can I get away with using an RC circuit instead of ordering more ICs?

I'm going to scale this to ~100 fets/USBMOD4 interface, so keeping the part-count down is priority.

My last post was intended for Si Ballenger, who suggested that I use two writes , assuming D3-D7 remain in their states between writes. My apologies for quoting you in my reply.

You are the one in a state of confusion. The strobe is done automatically each time you send a byte to an address for the first time. You don't have to strobe any bits within the byte. The ONESHOT produces the G strobe of width PW, the RC produces the delay TD- you don't have to do anything just send the data. You can adopt a scheme like device 1, bit1; device 2, bit 1;...device 16, bit 1; ...device 1, bit 8,...device 16, bit 8. If a device does not require updating, then rewrite a bit state it already has received anyway:

View in a fixed-width font such as Courier.

+-74259--+ D7>-------------------------|D | | | | | D6 3 | | D5 >----------/----------+ | | D4 |\ |A | |\ |B | \ |C | +-------+ | | D3 | ADDRS | | G | D2 |DECODER|--+ +--------+ D1 >--| | | | D0 +-------+ | | | | | | -> PW

You would need an RC in combination with a comparator or Schmitt trigger or it will not be reliable.

You can do this. Start with a signal that is normally a 1. Run it through an RC network to get some 50-100 ns delay and into an inverter. Put a second RC network on the output of the inverter. Now, run the INPUT signal of the inverter and the output of the second RC into a non inverting OR gate. You will get a 0 pulse out during T < t < 2T where T~RC. This will be more reliable than one shots because there is less danger of false triggereing. If you invert the input polarity, you can decode with a NAND gate.

Alternatively, you could forget about the RCs, and do the whole thing with a slow quad NAND package like a CD 4011.

Tam