How to properly use a 74259 (addressable latch)

[sryth]

I am thinking of connecting a 74259 (8-bit addressable latch) to a
USBMOD4 device to ultimately control 8 mosfets. The data sheet for the
latch said that you should hold pin G high while changing address lines
to avoid mangling your stored values, and I'm trying to come up with an
elegant solution.

My device sets all 8 data lines "simultaneously"; I need to ensure that
the line connected to the enable doesn't drop until the address/data
lines are set up.

I was thinking of a simple RC circuit sent into an schmitt inverter to
delay the dropping of G for ~100ms...would this work reliably? Are
there better ways of doing this?

 

[Bradley1234]

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




"sryth" <sryth@yahoo.com> wrote in message
news:1106707934.008771.32480@c13g2000cwb.googlegroups.com...

I am thinking of connecting a 74259 (8-bit addressable latch) to a
USBMOD4 device to ultimately control 8 mosfets. The data sheet for the
latch said that you should hold pin G high while changing address lines
to avoid mangling your stored values, and I'm trying to come up with an
elegant solution.

My device sets all 8 data lines "simultaneously"; I need to ensure that
the line connected to the enable doesn't drop until the address/data
lines are set up.

I was thinking of a simple RC circuit sent into an schmitt inverter to
delay the dropping of G for ~100ms...would this work reliably? Are
there better ways of doing this?

 

[sryth]

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.

 

[Fred Bloggs]

sryth wrote:

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.

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

 

[Fred Bloggs]

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.

 

[Si Ballenger]

On 27 Jan 2005 02:34:02 -0800, "sryth" <sryth@yahoo.com> wrote:

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.

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.

http://www.geocities.com/zoomkat/output.htm

 

[sryth]

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.

 

[Rich Grise]

On Thu, 27 Jan 2005 18:30:17 -0800, sryth wrote:

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

Can you afford a latch, to capture the lines _during_ the write, then
hold them until the next write?

Good Luck!
Rich

 

[sryth]

I have been tinkering with the USBMOD4 device and found a bit-bang
mode; this basically gives me access to the 8 data lines in the same
fashion as the parallel port. The datasheet for the FT245BM chip says
that it will hold lines that don't change. It looks like I'm going
with the two-write method.
Thank you all for your help! I truely appreciate it.

 

[Fred Bloggs]

sryth wrote:

Fred Bloggs wrote:

sryth wrote:

Fred Bloggs wrote:


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.


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.


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 <-
| | |
+-------------+ | |-------. .--
| | | | |
| | --- | <--- | | |
| | | | | --
|<--- | | | +--+----+---
| |-- | T0 T0+TD
| +--+---- |
| T0 |
| +--ONE SHOT-+ |
| | | |
+--/\/\-+---->TRIG |---+
| | |
=== +--74HCT123-+
|
GND



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?

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