Using 74xx574 D FF to expand PIC outputs

[Peter S. May]

Oops, sorry. That was corrected in rev B of the datasheet and ofcourse I was looking at rev A.

Mike

Easy mistake. Only reason I have rev C is because it bugged me that the
sheet I had previously said "Preliminary" at the bottom.

 

[Mike Silva]

I'm afraid to make it too much more complicated than it already
is...some dedicated shift registers could be suitable, but a micro on
each breakout would be overkill. The output data rate isn't
particularly extreme; it should be sufficient as long as it is
architecturally capable of running 128 one-bit outputs at a refresh rate
of about 60Hz--it's lights, after all. The _input_, actually, will be
RS-232, because (at least in this incarnation) it's a
computer-controlled LED lighting rig. I'm looking at running it with an
11.0592MHz crystal to keep the timing serial-compatible, and I already
have the MAX232 on hand.

The 16F88 just happens to have a built-in SPI port. Are there any sort
of "dumb-terminal"-style external registers that use something like
this, or would I need another micro at the far end? (There are cheaper
micros that could be exploited as dedicated bit-bangers for this
purpose, but I'd like to avoid clunking it up like that...)

I think you could definitely use the SPI port and some MSI shift
registers on the receiving end. Put 16 shift registers in series,
shift out 128 bits at a time (16 loads of the SPI output module), then
strobe the new bits to the outputs. Should take much less than 1ms.
Make sure your clock and strobe buffers can drive 16 chips at once.
Just a quick look at what's available in shift registers turned up
e.g. the 74HC(T)594, 8-bit serial-to-parallel with latched output
register. There may be others as well.

 

[Robert Latest]

Of course, in all this one must mind animals and their audio range. Even
where they are normally not allowed guide dogs, for example, could still
be present.

Wasn't this for an optical display?

robert

 

[Peter S. May]

I think you could definitely use the SPI port and some MSI shift
registers on the receiving end. Put 16 shift registers in series,
shift out 128 bits at a time (16 loads of the SPI output module), then
strobe the new bits to the outputs. Should take much less than 1ms.
Make sure your clock and strobe buffers can drive 16 chips at once.
Just a quick look at what's available in shift registers turned up
e.g. the 74HC(T)594, 8-bit serial-to-parallel with latched output
register. There may be others as well.

All right, so I'm not very clear-headed at the moment... I tried to
read something about SPI. All the "TM" signs around it spooked me into
thinking that there's some specific protocol associated with it. It
does seem to be just a clock/signal pair. I had assumed that there'd be
some meta-stuff around it like there is with RS-232 (e.g. start/stop
bit). Are you saying that this is not the case and that I could pretty
much just wire up the signal and clock lines to a 74HC594 (which I'd
stumbled upon previously investigating shift registers) and it would work?

Another question: If my D FFs were having trouble distinguishing
signals, what reason do I have to believe that a serial connection would
fare any better? I mean, I know it would just from having seen it work,
but I don't know why.

Also, come to think of it, I'm not sure how this new configuration would
look topologically. Would the SIPO shift registers need to be on the
main board, or could they be on the breakouts? If I'm connecting the
registers in series, am I right in guessing that the breakouts would
have to be physically daisy-chained instead of having a star topology?

Please excuse me for being easily confused this morning. It's a wonder
I made it out of bed...

Thanks
PSM

 

[Peter S. May]

Dumb question: What does MSI stand for in this context? It seems to
appear on some data sheets for this register but not others, and
Googling it is giving confusing results.

Thanks
PSM

 

[Joerg]

Joerg wrote:




Wasn't this for an optical display?

Sure. But it sounded like "light show" and that's often done in
conjunction with some kind of concert. Meaning long cables, rolled out
by people who don't have the foggiest idea about EMI, stuff coupling
over into the audio gear and so on.

 

[krw]

Dumb question: What does MSI stand for in this context? It seems to
appear on some data sheets for this register but not others, and
Googling it is giving confusing results.

Medium-Scale Integration.

 

[SP]

Dumb question: What does MSI stand for in this context? It seems to
appear on some data sheets for this register but not others, and
Googling it is giving confusing results.

Thanks
PSM

Medium-Scale Integration. As opposed to SSI or LSI. It doesn't mean
much these days except "simple"... IIRC it meant transistor counts in
the hundreds or something like that.

 

[Peter S. May]

Sure. But it sounded like "light show" and that's often done in
conjunction with some kind of concert. Meaning long cables, rolled out
by people who don't have the foggiest idea about EMI, stuff coupling
over into the audio gear and so on.

Though it's not for a "light show" per se, it will be attached to (and
controlled by) a PC that is also producing sound, and the roadies I
imagine you're talking about are really just home PC users (equally
clueless about EMI), so this is in fact something that will probably
require consideration...

 

[Joerg]

Though it's not for a "light show" per se, it will be attached to (and
controlled by) a PC that is also producing sound, and the roadies I
imagine you're talking about are really just home PC users (equally
clueless about EMI), so this is in fact something that will probably
require consideration...

Many of them sure are blissfully unaware. I tried several times to
convince a guy who had lots of noise in his audio to invest a few bucks
in an audio transformer, explaining that the switcher of his laptop was
causing the noise. Weeks later he was still wrestling with the problem,
trying to get by using the battery. Did he go to Radio Shack and buy a
transformer? Nope.

 

[Peter S. May]

I've now been able to read and mostly understand some material about
using SPI to interface with shift registers. ON Semiconductor's app
notes AND8144 and AND8148 seem to describe my application largely,
except in reverse (using parallel-ins for input instead of parallel-outs
for output). But I _still_ have questions...

At this point it's become more or less clear to me that the SPI
interface is the intuitive wiring job (data out to data in, clock out to
clock in). One of the app notes has a spiel about disambiguating the
low/high crossover point between chips by filtering the clock line with
74xx14 Schmitt triggers.

Now, I think I'm still going to do the smart thing and convert my whole
design to the more serially-oriented method (being a little harder to
program but a lot easier to wire), but I have to ask: Is this the gist
of the answer to de-noising the signal lines to the main board when said
lines get longer than a foot? If so, is there any reason it wouldn't
work with the parallel method (despite the pain of having to add a
Schmitt inverter to every line)?

Or is there some other reason that running serial lines is better?

Once everything's a little clearer in my head, I'd like to put together
a sample schematic and ask if anything's egregiously wrong with it.
There's a lot I can't get done without experimenting, but I can't
experiment without parts, and I can't order parts until I have some idea
what I'm doing...

Thanks, once again
PSM

 

[Rich Grise]

PORTA and PORTB, according to what I've read, are latched--I don't think
they go hi-Z for a read. I could be wrong, but I'm having some degree
of success with adding decoupling caps and shortening the ground lines,
so I think that's more likely where the problem is.

I agree here too - whenever I use a protoboard, I load it up with caps.
If there's a chip I can't straddle with a cap, I'll put one at each
end, from Vcc to Gnd:

---------+---------------+-------------- <- protoboard Vcc bus
+ +
+ +
+ +
+--+ +
| -------------- |
[C] | | [C]
| -------------- |
+ +--+
+ +
+ +
+ +
------+---------------+------------------- <- protoboard Vee bus

I hope you appreciate this - I just now drew it by hand. ;-)

Cheers!
Rich

 

[Peter S. May]

I agree here too - whenever I use a protoboard, I load it up with caps.
If there's a chip I can't straddle with a cap, I'll put one at each
end, from Vcc to Gnd:

---------+---------------+-------------- <- protoboard Vcc bus
+ +
+ +
+ +
+--+ +
| -------------- |
[C] | | [C]
| -------------- |
+ +--+
+ +
+ +
+ +
------+---------------+------------------- <- protoboard Vee bus

I hope you appreciate this - I just now drew it by hand. ;-)

Good to know! I got lucky this time: The PIC's Vdd/Vss are directly
across from each other, and the 574s have an active low enable pin
directly across from Vcc, which I then jumped to ground. But I'll
probably do what you've done once I get around to ordering that
veritable bucket of .1uF ceramic caps...

Thanks
PSM

 

[Rich Grise]

.

Now, I think I'm still going to do the smart thing and convert my whole
design to the more serially-oriented method (being a little harder to
program but a lot easier to wire), but I have to ask: Is this the gist
of the answer to de-noising the signal lines to the main board when said
lines get longer than a foot? If so, is there any reason it wouldn't
work with the parallel method (despite the pain of having to add a
Schmitt inverter to every line)?

I've run ribbon cable 2 or 3 feet with no problems, albeit from a 4.77 MHz
PC to a ROM emulator pod; I didn't use any schmitt triggers - as long as
the lines are driven and terminated properly, and you use the right trick
in the ribbon cable: alternate signal wires with ground.

Have Fun!
Rich

 

[Peter S. May]

I've run ribbon cable 2 or 3 feet with no problems, albeit from a 4.77 MHz
PC to a ROM emulator pod; I didn't use any schmitt triggers - as long as
the lines are driven and terminated properly, and you use the right trick
in the ribbon cable: alternate signal wires with ground.

Have Fun!
Rich

Don't have so much ribbon cable handy, but some years ago a kind
electrician gave me what was left of a big spool of CAT-5 (i.e., four
twisted pairs). I figured I might be able to do some noise reduction by
either using all the white lines for ground or even going to the trouble
of running a differential signal...subject to experimentation.

PSM

 

[Peter S. May]

At this point it's become more or less clear to me that the SPI
interface is the intuitive wiring job (data out to data in, clock out to
clock in). One of the app notes has a spiel about disambiguating the
low/high crossover point between chips by filtering the clock line with
74xx14 Schmitt triggers.

I've just realized a dumb mistake: The PIC shares its SPI pins with its
USART pins, so the intended output would be mutually exclusive with the
intended input! :-(

I suppose this means I should resort to bit banging...though, with the
easiest method of doing so being loading one of the 8-bit out registers
and rrfing the value eight times, shouldn't I just be using a
parallel-in/serial-out shift register for this part instead?

Ech, I don't know. Just frustrated at the moment.

Thanks
PSM

 

[linnix]

Dumb question: What does MSI stand for in this context? It seems to
appear on some data sheets for this register but not others, and
Googling it is giving confusing results.

Dumb answer: MSI is smaller than LSI, and LSI is smaller than VLSI

 

[Mike Silva]

All right, so I'm not very clear-headed at the moment... I tried to
read something about SPI. All the "TM" signs around it spooked me into
thinking that there's some specific protocol associated with it. It
does seem to be just a clock/signal pair. I had assumed that there'd be
some meta-stuff around it like there is with RS-232 (e.g. start/stop
bit). Are you saying that this is not the case and that I could pretty
much just wire up the signal and clock lines to a 74HC594 (which I'd
stumbled upon previously investigating shift registers) and it would work?

Yes. I've done exactly the same thing, both for inputs and outputs.

Another question: If my D FFs were having trouble distinguishing
signals, what reason do I have to believe that a serial connection would
fare any better? I mean, I know it would just from having seen it work,
but I don't know why.

That's why I suggested using RS-485 drivers at the PIC end and
receivers at the breakout end - very noise-resistant. That along with
a slower logic family and all the usual anti-noise precautions.

Also, come to think of it, I'm not sure how this new configuration would
look topologically. Would the SIPO shift registers need to be on the
main board, or could they be on the breakouts? If I'm connecting the
registers in series, am I right in guessing that the breakouts would
have to be physically daisy-chained instead of having a star topology?

What do you mean by a "breakout"? One 8-bit register, or an entire
128-bit device, or something in between? I'm assuming the latter.

Anyway, I'd put the shift registers on the same board as the devices
they are driving. That is to say, where you have dozens of data bits
passing between chips, keep those chips on the same board (or at the
very least, in the same box).

If you wanted to drive multiple 128-bit breakouts, you could do it by
daisy-chaining but that would be a very brittle arrangement, since any
time your breakout configuration changed you'd have to alter the
entire data-transmission sequence. Much better to (similar to what
you were trying originally) use a star configuration with the same
serial clock and data (and reset?) signal being fed to each breakout,
but a separate latch strobe to each breakout.

 

[Eeyore]

Greetings. I'm having a problem that reaches beyond my basic knowledge
of digital logic and electronics, and so I'm hoping an expert eye can
spot the mistake. (Also, please suggest a more appropriate group if I'm
in the wrong place.)

I'm working on a seemingly straightforward means of expanding the
limited outputs of a PIC 16F88 to 32 pins by way of four 74ABT574 octal
D-type flip-flops and a 2-to-4 decoder. The way the trivial design is
supposed to work is that each RBn pin of the PIC is attached to a
corresponding Dn pin on each of the four 574s. The program would assign
their data round-robin style, assigning one word to PORTB and then
clocking the destination DFFs using the demuxer. The outputs in this
experiment are LEDs run via 1K resistors (3 or 4mA).

I've had some problems, though, and they're somewhat spurious.
Sometimes, the outputs of the first 574 always echo PORTB; other times,
one or more of the 574s read correctly except for a split second of
flicker, which I'm guessing is a momentary read intended for another
output, but I have no idea why.

I've seen this kind of behaviour on some kit built by another company that we
were programming that itself generated high level of EMI. We 'fixed' it
kludgily (as it wasn't in our remit to redesign the hardware) by constantly
re-writing the data so that if any latch got corrupted it wasn't for very long.

Your clock lines aren't by any chance going Hi-Z when inactive are they ? I'd
use a serious pull-up on them. You might even want to filter them with an RC and
use a Schmitt at the far end if it's a very electrically noisy environment.

Graham

 

[Eeyore]

Hello Peter,


No idea what the outputs have to do. However, check out serial to
parallel converters such as the 74HC164. That's how I do that. There is
also another variety that can update the outputs in a controlled fashion
so you don't get glitches, and can be cascaded to a few miles of bits.
But so far the HC164 was good enough for us.

Yup, they work OK.

Also see PCF8574 ( I2C interface).

I'm curious too why an ABT574 is being used.

Graham