Using 74xx574 D FF to expand PIC outputs

[Peter S. May]

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 simplified the circuit to the minimum that should implement the
functionality, done away with the demuxer and three of the four 574s,
and the problem remains.

Here is the circuit:

16F88 74ABT574
---------- ---------------
| Vdd|--> +5V <-----|20 Vcc |
| Vss|--| GND |--+--|10 GND |
| | +--|1 /OE |
| | | | 1K LED
| RB0|--------------|2 D0 Q0 19|--/\/\--|>|---+--| GND
| RB1|--------------|3 D1 Q1 18|--/\/\--|>|---+
| RB2|--------------|4 D2 Q2 17|--/\/\--|>|---+
| RB3|--------------|5 D3 Q3 16|--/\/\--|>|---+
| RB4|--------------|6 D4 Q4 15|--/\/\--|>|---+
| RB5|--------------|7 D5 Q5 14|--/\/\--|>|---+
| RB6|--------------|8 D6 Q6 13|--/\/\--|>|---+
| RB7|--------------|9 D7 Q7 12|--/\/\--|>|---+
| | | |
| RA4|--------------|11 CLK |
| RA5| ---------------
| RA6|
| RA7|
----------

The same behavior is exhibited when the LEDs are reversed with cathode
on the output and anode on +5V. In theory, I should also be able to
switch the CLK of the 574 among RA4-RA7 to output any of the four
different output patterns, which would be functionally identical to the
full circuit. This does work, insofar as doing this echoes what each of
the 574s would have been doing before, but is subject to the same glitches.

I've tried adjusting the delays on the clocks (which shouldn't be
necessary; the 74ABT574 specifies a much higher clock frequency than I'm
using), not just with the nops in the version at the end of this message
but also plugging in an entire delay loop, and the problem remains. I
find myself wishing I had an oscilloscope!

The program follows. Is there anything in the program--or, more likely,
the circuit itself--that I need to try adjusting?

Thanks a zillion
PSM



The program:

errorlevel -302
include "hgt_16f88.inc"

processor 16f88

org 0
goto Start

org 4
ISR
retfie

Start

BUF0 equ 0x30 ; - 0x33
ADDRESSBUFFER equ 0x40

Setup
bsf STATUS,5 ; set bank 1
movlw b'00000000'
movwf TRISA
movlw b'00000000'
movwf TRISB
bcf STATUS,5 ; set bank 0

clrf PORTA

clrf BUF0
clrf BUF0+1
clrf BUF0+2
clrf BUF0+3

Loop
; The first two count forward and backward, respectively
incf BUF0,f
decf BUF0+1,f

; The third rolls one direction
rlf BUF0+2,f
btfsc STATUS,C
bsf BUF0+2,0

; The fourth rolls the other
rrf BUF0+3,f
btfsc STATUS,C
bsf BUF0+3,7

call SetExternalRegisters
call Delay


goto Loop

Delay
COUNTH equ 0x20
COUNTL equ 0x21
movlw 0x00
movwf COUNTH
movlw 0xDA
movwf COUNTL

Delay_Loop
; 16-bit decrement
; 9 instructions per loop
; Time taken = 9 * 4 / osc speed
; For 31.25kHz, 868 = about 1s.
decf COUNTL,f
incfsz COUNTL,w
incf COUNTH,f
decf COUNTH,f
movf COUNTL,w
iorwf COUNTH,w
btfss STATUS,Z
goto Delay_Loop
return

SetExternalRegisters
; Manual version!
movf BUF0,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,4
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,4
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+1,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,5
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,5
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+2,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,6
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,6
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+3,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,7
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,7
nop
nop
nop
nop
nop
nop
nop
nop

; Show a pattern that means "this isn't right"
movlw b'11000011'
movwf PORTB
return


org 0x2007
CONFIG1
; Use internal oscillator at 31.25kHz
dw 0x3f10
end

 

[Mike Silva]

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 simplified the circuit to the minimum that should implement the
functionality, done away with the demuxer and three of the four 574s,
and the problem remains.

Here is the circuit:

16F88 74ABT574
---------- ---------------
| Vdd|--> +5V <-----|20 Vcc |
| Vss|--| GND |--+--|10 GND |
| | +--|1 /OE |

/OE should be held low to enable the outputs. Looks like you've left
it floating. If so, that is undoubtedly your problem. If you did
actually wire it low somehow, keep reading.

Also, do you have a decoupling capacitor (~0.1uF) between power and
ground physically close to each of the chips? Is your ground good and
solid between the PIC and the latches? Proper supply voltage for each
chip?

Sure would help if you did have a scope. :-\

 

[Mike Silva]

/OE should be held low to enable the outputs. Looks like you've left
it floating. If so, that is undoubtedly your problem. If you did
actually wire it low somehow, keep reading.

Also, do you have a decoupling capacitor (~0.1uF) between power and
ground physically close to each of the chips? Is your ground good and
solid between the PIC and the latches? Proper supply voltage for each
chip?

Sure would help if you did have a scope. :-\- Hide quoted text -

I just looked at your diagram again in a fixed font and I see you do
have /OE grounded. Sorry 'bout that.

 

[Peter S. May]

/OE should be held low to enable the outputs. Looks like you've left
it floating. If so, that is undoubtedly your problem. If you did
actually wire it low somehow, keep reading.

The ASCII schematic might have been slightly ambiguous, but the pluses
are meant to indicate that GND and /OE are connected. (This was in fact
the first mistake I corrected trying to fix this problem...)

Also, do you have a decoupling capacitor (~0.1uF) between power and
ground physically close to each of the chips? Is your ground good and
solid between the PIC and the latches? Proper supply voltage for each
chip?

Decoupling was something I was wondering about; I'm new to earnest
applications of digital logic and never had to do it before. I have
several 1uF tantalums that I attached to no avail, but first of all I
didn't know whether 1uF was a decent capacitance (I don't have any 0.1uF
on hand), and secondly I wasn't sure how far was too far. The leads are
short on these things, so I wasn't able to make one straddle the chip.
The closest I was able to get without changing the arrangement of the
parts was to have one lead on the +V pin and one on the ground bus, or
one lead on the GND pin and one on the +V bus. Would it help if I were
to connect the capacitor to the breadboard row just north of 1 or just
south of (pin count divided by two) and use short jumpers for both?

All of the ground pins are connected by jumpers to a bus on my
breadboard, and all Vcc/Vdd are connected to another. The power supply
is the +5V/GND wires from a floppy connector on a PSU lifted from an ATX
computer case.

Sure would help if you did have a scope. :-\

I believe it.

Thanks
PSM

 

[petrus bitbyter]

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 simplified the circuit to the minimum that should implement the
functionality, done away with the demuxer and three of the four 574s,
and the problem remains.

Here is the circuit:

16F88 74ABT574
---------- ---------------
| Vdd|--> +5V <-----|20 Vcc |
| Vss|--| GND |--+--|10 GND |
| | +--|1 /OE |
| | | | 1K LED
| RB0|--------------|2 D0 Q0 19|--/\/\--|>|---+--| GND
| RB1|--------------|3 D1 Q1 18|--/\/\--|>|---+
| RB2|--------------|4 D2 Q2 17|--/\/\--|>|---+
| RB3|--------------|5 D3 Q3 16|--/\/\--|>|---+
| RB4|--------------|6 D4 Q4 15|--/\/\--|>|---+
| RB5|--------------|7 D5 Q5 14|--/\/\--|>|---+
| RB6|--------------|8 D6 Q6 13|--/\/\--|>|---+
| RB7|--------------|9 D7 Q7 12|--/\/\--|>|---+
| | | |
| RA4|--------------|11 CLK |
| RA5| ---------------
| RA6|
| RA7|
----------

The same behavior is exhibited when the LEDs are reversed with cathode
on the output and anode on +5V. In theory, I should also be able to
switch the CLK of the 574 among RA4-RA7 to output any of the four
different output patterns, which would be functionally identical to the
full circuit. This does work, insofar as doing this echoes what each of
the 574s would have been doing before, but is subject to the same
glitches.

I've tried adjusting the delays on the clocks (which shouldn't be
necessary; the 74ABT574 specifies a much higher clock frequency than I'm
using), not just with the nops in the version at the end of this message
but also plugging in an entire delay loop, and the problem remains. I
find myself wishing I had an oscilloscope!

The program follows. Is there anything in the program--or, more likely,
the circuit itself--that I need to try adjusting?

Thanks a zillion
PSM



The program:

errorlevel -302
include "hgt_16f88.inc"

processor 16f88

org 0
goto Start

org 4
ISR
retfie

Start

BUF0 equ 0x30 ; - 0x33
ADDRESSBUFFER equ 0x40

Setup
bsf STATUS,5 ; set bank 1
movlw b'00000000'
movwf TRISA
movlw b'00000000'
movwf TRISB
bcf STATUS,5 ; set bank 0

clrf PORTA

clrf BUF0
clrf BUF0+1
clrf BUF0+2
clrf BUF0+3

Loop
; The first two count forward and backward, respectively
incf BUF0,f
decf BUF0+1,f

; The third rolls one direction
rlf BUF0+2,f
btfsc STATUS,C
bsf BUF0+2,0

; The fourth rolls the other
rrf BUF0+3,f
btfsc STATUS,C
bsf BUF0+3,7

call SetExternalRegisters
call Delay


goto Loop

Delay
COUNTH equ 0x20
COUNTL equ 0x21
movlw 0x00
movwf COUNTH
movlw 0xDA
movwf COUNTL

Delay_Loop
; 16-bit decrement
; 9 instructions per loop
; Time taken = 9 * 4 / osc speed
; For 31.25kHz, 868 = about 1s.
decf COUNTL,f
incfsz COUNTL,w
incf COUNTH,f
decf COUNTH,f
movf COUNTL,w
iorwf COUNTH,w
btfss STATUS,Z
goto Delay_Loop
return

SetExternalRegisters
; Manual version!
movf BUF0,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,4
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,4
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+1,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,5
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,5
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+2,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,6
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,6
nop
nop
nop
nop
nop
nop
nop
nop

movf BUF0+3,w
movwf PORTB
nop
nop
nop
nop
bsf PORTA,7
nop
nop
nop
nop
nop
nop
nop
nop
bcf PORTA,7
nop
nop
nop
nop
nop
nop
nop
nop

; Show a pattern that means "this isn't right"
movlw b'11000011'
movwf PORTB
return


org 0x2007
CONFIG1
; Use internal oscillator at 31.25kHz
dw 0x3f10
end

That 74ABT574 is pretty fast a thing. To make it work reliably it requires
good grounding, careful
decoupled power supply and short, solid wiring. Wrong datatransfer is most
of the times caused by glitches or disturbances on the clock lines. Dips on
on the power pin may have the same effect. The glitches you see on the LEDS
are most likely caused by unsufficient decoupling or wrong wiring of ground
and/or power. When switching LEDs so fast, the wires are cannot be
considered shorts. They will look like coils and capacitors and the circuit
even may oscillate. (For very short times but nevertheless.) So you need the
decoupling mentioned. You'd also not power the LEDs by the same (thin)
conductor you use for the logic.

I did not check but maybe the rising edge from the PIC is not fast enough
for the 74ABT574. Especially when you have long wires. You can check by
placing pull up resistors of let's say 1k on the A-port outputs of the PIC.

Do not use a 2-to-4 decoder in the clock lines. This decoders are
combinatorial logic that will have glitches on the outputs when one or more
inputs change(s). Besides, you will always have at least one clock line
high. A 1-to-4 demultiplexer may be usefull but it requires three lines from
the PIC. (Two address lines and the clock.)

petrus bitbyter

 

[Joerg]

Hello Peter,

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).

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.


[...]

 

[Mike Silva]

Decoupling was something I was wondering about; I'm new to earnest
applications of digital logic and never had to do it before. I have
several 1uF tantalums that I attached to no avail, but first of all I
didn't know whether 1uF was a decent capacitance (I don't have any 0.1uF
on hand), and secondly I wasn't sure how far was too far. The leads are
short on these things, so I wasn't able to make one straddle the chip.
The closest I was able to get without changing the arrangement of the
parts was to have one lead on the +V pin and one on the ground bus, or
one lead on the GND pin and one on the +V bus. Would it help if I were
to connect the capacitor to the breadboard row just north of 1 or just
south of (pin count divided by two) and use short jumpers for both?

All of the ground pins are connected by jumpers to a bus on my
breadboard, and all Vcc/Vdd are connected to another. The power supply
is the +5V/GND wires from a floppy connector on a PSU lifted from an ATX
computer case.

Well, your bare-bones circuit is correct (but, as another poster
mentioned, you're going to have trouble if you use a 2-4 decoder
without an enable pulse - you _will_ get clock glitches). So, what's
left (assuming your parts are good)?

1) Power/ground issues. Your ground from PIC to latches and LEDs
needs to be substantial and low-impedance (short). Your +5 should
also be reasonably substantial and short. And you need decoupling on
every chip. And is your +5 really 5V?

2) Signal issues. Clock and data signals should be clean, with
suitably fast edges and be well within the input voltage specs for the
latches. It couldn't hurt to try the pullups mentioned, but I would
not expect them to be necessary (however, I don't know the PIC output
characteristics).

 

[Mike]

Start

BUF0 equ 0x30 ; - 0x33
ADDRESSBUFFER equ 0x40

Setup
bsf STATUS,5 ; set bank 1
movlw b'00000000'
movwf TRISA
movlw b'00000000'
movwf TRISB
bcf STATUS,5 ; set bank 0

clrf PORTA

clrf BUF0
clrf BUF0+1
clrf BUF0+2
clrf BUF0+3

Loop

I think you need to set the comparator config register (CMCON) to 0x07 (00000111) to disable the comparators.
The power on default is for the register is 0 which enables the comparators and configures A0-A3 analog
inputs.

Mike C



If there is no absolute truth then nothing can be known.

 

[Rich Grise]

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).
....
bsf PORTA,4 ....
bcf PORTA,4

....

Aren't these instructions read-modify-write? When the pin goes
high-impedance to do the read, there could be a glitch. I'd just use
the right byte, like for example (pseudocode):

lda 00000001b ; for bit 0
output A, portA
lda 00000000b ; to make the strobe go away
output A, portA

Of course, you've already written your data to port B.

If you're using port A for other stuff, keep a shadow copy in RAM.

Good Luck!
Rich

 

[Peter S. May]

I finally got home today, got out the pliers, and bent a 1uF capacitor's
leads enough to straddle the PIC. The result appears to be a lot
cleaner already! Thanks for helping a clueless boy track this down.
However, I'm not going to call a single good test a success, so I want
to talk it out.

For one specific matter, would you guess that it's a fluke that the 1uF
seems to have worked? When I place my next parts order, should I order
the .1uF just to be safe? Is there any reason not to order ceramic
instead of tantalum?

Well, your bare-bones circuit is correct (but, as another poster
mentioned, you're going to have trouble if you use a 2-4 decoder
without an enable pulse - you _will_ get clock glitches). So, what's
left (assuming your parts are good)?

Fortunately, I had the good sense to use a 2-to-4 _with_ an enable
input. The outputs are inverted (HHHH when disabled, one output low
when enabled), but the 574 is positive edge-triggered, so as long as all
outputs stay high _except_ when in use, and then are not expected to
register until the clock pulse from the processor _ends_, shouldn't that
work? Anyway, I'm not going to re-introduce the decoder until I know
everything works without it. That said, the decoder is necessary,
because I'll need the extra two pins later. It's from the HC series,
and I wouldn't guess it's altogether timing-incompatible. (But to make
sure everything works with it, I'll be sure to add up the propagation
delays and insert nops accordingly.)

1) Power/ground issues. Your ground from PIC to latches and LEDs
needs to be substantial and low-impedance (short). Your +5 should
also be reasonably substantial and short. And you need decoupling on
every chip. And is your +5 really 5V?

Once I buy some capacitors, there will be one on every chip. The supply
leads will be a more ideal length once I'm off the breadboard, I guess.
The +5V from the supply has tended to range from 5.04 to 5.15, which I
figured wasn't going to be a problem. (It's an ATX power supply, and I
figure if it's good enough for the digital logic on a motherboard...but
then, more obvious conclusions have been wrong.)

2) Signal issues. Clock and data signals should be clean, with
suitably fast edges and be well within the input voltage specs for the
latches. It couldn't hurt to try the pullups mentioned, but I would
not expect them to be necessary (however, I don't know the PIC output
characteristics).

The ABT574's spec rates the governing minimum input edge (in this case,
the clock input) at 100mV/ns. Unless I'm reading or calculating wrong,
that means the up edge must take less than 50ns at 5V. A cursory glance
at the spec for my PIC device rates the maximum I/O port output
rise/fall at 40ns, 10ns typical, so that ought to be fine, right? If it
weren't, what would I want to do? Perhaps run the pin out to some sort
of bistable, or is it simpler than that? (My background in analog
circuits is spotty.)

Speaking of these specs, when they speak of rise/fall times, are they
talking about from GND to Vdd (e.g. 0 to 5V) or simply low to high (0.8
to 2.0V, as rated for the ABT574)?

Thanks for educating a guy who didn't have the good sense to do this as
his major...
PSM

 

[Peter S. May]

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.

I've evaluated shift registers for this design and found that for this
application (which may end up having 128 outputs eventually) the bit
banging involved would slow the refresh rate to nearly human-discernible
levels. Farming it out to a parallel-in shift register outputting to
serial-in shift registers has been another thought, but I plan to wait a
while before exploring it.

Incidentally, the outputs are for driving a computer-controlled light
display, so the outs on the DFFs will connect to transistor arrays that
in turn drive several high-brightness LEDs each.

Thanks
PSM

 

[Peter S. May]

I think you need to set the comparator config register (CMCON) to 0x07 (00000111) to disable the comparators.
The power on default is for the register is 0 which enables the comparators and configures A0-A3 analog
inputs.

My copy of the 16F88 spec (rev C, page 15) says the POR value for CMCON
is 00000111, not 0.

Thanks
PSM

 

[Peter S. May]

On Mon, 16 Jul 2007 14:28:30 -0400, Peter S. May wrote:
Aren't these instructions read-modify-write? When the pin goes
high-impedance to do the read, there could be a glitch. I'd just use
the right byte, like for example (pseudocode):

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.

Thanks
PSM

 

[Mike Silva]

I finally got home today, got out the pliers, and bent a 1uF capacitor's
leads enough to straddle the PIC. The result appears to be a lot
cleaner already! Thanks for helping a clueless boy track this down.
However, I'm not going to call a single good test a success, so I want
to talk it out.

For one specific matter, would you guess that it's a fluke that the 1uF
seems to have worked? When I place my next parts order, should I order
the .1uF just to be safe? Is there any reason not to order ceramic
instead of tantalum?

The .1 ceramic are standard for each chip (more or less). The
tantalums don't have as good frequency response, but they can be used
on a per-board (not per-chip) basis.

Fortunately, I had the good sense to use a 2-to-4 _with_ an enable
input. The outputs are inverted (HHHH when disabled, one output low
when enabled), but the 574 is positive edge-triggered, so as long as all
outputs stay high _except_ when in use, and then are not expected to
register until the clock pulse from the processor _ends_, shouldn't that
work? Anyway, I'm not going to re-introduce the decoder until I know
everything works without it. That said, the decoder is necessary,
because I'll need the extra two pins later. It's from the HC series,
and I wouldn't guess it's altogether timing-incompatible. (But to make
sure everything works with it, I'll be sure to add up the propagation
delays and insert nops accordingly.)

You should be OK with an enable signal. Otherwise, due to different
propagation delays within the chip, you may find unselected outputs
getting a brief glitch. For example, switching from '0' to '2' you
may find that e.g. '3' gets a brief glitch (but quick enough for the
latch chip to respond). Use the enable pin to keep all outputs off
(high) until the chip has settled. In practice this can just be the
very next PIC instruction, since we're only talking ns or very low 10s
of ns here.

The ABT574's spec rates the governing minimum input edge (in this case,
the clock input) at 100mV/ns. Unless I'm reading or calculating wrong,
that means the up edge must take less than 50ns at 5V. A cursory glance
at the spec for my PIC device rates the maximum I/O port output
rise/fall at 40ns, 10ns typical, so that ought to be fine, right? If it
weren't, what would I want to do? Perhaps run the pin out to some sort
of bistable, or is it simpler than that? (My background in analog
circuits is spotty.)

The sheet I just looked at specified a max of 5ns/V, half of what you
quote. Your PIC will probably work, but there's no margin. The
reality is that you're using too fast a latch for the PIC. You never
want to use a faster chip than you need - that's just a recipe for
trouble, especially with sloppy breadboard wiring.

Speaking of these specs, when they speak of rise/fall times, are they
talking about from GND to Vdd (e.g. 0 to 5V) or simply low to high (0.8
to 2.0V, as rated for the ABT574)?

From the 10% point to the 90% point.

Thanks for educating a guy who didn't have the good sense to do this as
his major...
PSM

No problem. You're miles ahead of some of the stuff that gets
asked.

 

[Peter S. May]

A little update: I hooked the fourth 574 back up and found that it was
picking up the same noise as earlier, but jumping its ground directly to
the PIC's ground and decoupling it (this time with a .47uF I happened to
find in an older junk box) seems to have fixed it. I'm elated about
this fact and I really think I'm a step closer to completing my next
bill of materials for a Jameco order...

On the other hand, I think all of this means I absolutely cannot
implement the final product the same way, since it involves breakout
boxes potentially _feet_ away from the PIC, and keeping the
ground-to-ground short is simply not an option. Would I be better off
running the outs into a parallel-in shift register, then deserializing
on the other end? Or perhaps going all-out RS-232? (I don't like that
idea!) I guess just keeping the DFFs on the main board and running the
outputs to the LED driver transistors could work. The human eye is
conveniently non-timing-sensitive.

More follows; read on.

The sheet I just looked at specified a max of 5ns/V, half of what you
quote. Your PIC will probably work, but there's no margin. The
reality is that you're using too fast a latch for the PIC. You never
want to use a faster chip than you need - that's just a recipe for
trouble, especially with sloppy breadboard wiring.

I'll double-check that the sheet I have is for the manufacturer I've
got. Unfortunately, I didn't know much about the difference between
logic families _before_ I bought my last batch of stuff, and I certainly
didn't suspect that there was a _minimum_ on the input rise; I just
figured there was a threshold point unless there was a Schmitt trigger
involved, and that newer series with pin compatibility could (in
general) be used as drop-in replacements. I know better now, don't I?
:-/ From what I'm hearing here, I'd be better off downgrading to, say,
an HC-series? I don't like working without a margin. I'm already
error-prone enough...

Noted!

Thanks a zillion
PSM

 

[Joerg]

I've evaluated shift registers for this design and found that for this
application (which may end up having 128 outputs eventually) the bit
banging involved would slow the refresh rate to nearly human-discernible
levels. Farming it out to a parallel-in shift register outputting to
serial-in shift registers has been another thought, but I plan to wait a
while before exploring it.

That must be one slow uC. Imagine you would want to spring for, say, six
IO lines for the light display. That would mean you'd have to update 32
serial bits on four lines, the 5th is clock and the 6th is for
simultaneous loading in case you need that feature. Most modern uC could
pipe out at several MHz no sweat. That would still be around or above
100kHz. Even if you restrict the data piping to 25% duty cycle you'd
still be above audio. Definitely above the capabilities of the human eye.

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.

Incidentally, the outputs are for driving a computer-controlled light
display, so the outs on the DFFs will connect to transistor arrays that
in turn drive several high-brightness LEDs each.

If there aren't any inductors involved audio noise is probably not going
to matter much. Unless it electrically buzzes into a PA system or rock
concert audio gear.

 

[Mike Silva]

A little update: I hooked the fourth 574 back up and found that it was
picking up the same noise as earlier, but jumping its ground directly to
the PIC's ground and decoupling it (this time with a .47uF I happened to
find in an older junk box) seems to have fixed it. I'm elated about
this fact and I really think I'm a step closer to completing my next
bill of materials for a Jameco order...

On the other hand, I think all of this means I absolutely cannot
implement the final product the same way, since it involves breakout
boxes potentially _feet_ away from the PIC, and keeping the
ground-to-ground short is simply not an option. Would I be better off
running the outs into a parallel-in shift register, then deserializing
on the other end? Or perhaps going all-out RS-232? (I don't like that
idea!) I guess just keeping the DFFs on the main board and running the
outputs to the LED driver transistors could work. The human eye is
conveniently non-timing-sensitive.

What's the maximum data rate you will need? How many bytes/sec? It
really is starting to sound to me like you want a serial transfer
mechanism. You should have no trouble running a UART to 115 kbaud
over a few feet. That's 10kbytes/sec. You might be able to do quite
a bit faster, perhaps using RS-485 drivers and receivers. But then
you need a UART on the other end.

Or, you could do an SPI-type serial transfer, either with a built-in
SPI module or by bit-banging. Simple MSI shift registers would be
enough on the receiving end. Again, you might want to use RS-485
drivers and receivers. Making the decision really depends on how much
data you have to write out, and also how much processing you need to
do between data transmissions.

If you can avoid it, you do not want to be passing large high-
frequency currents on your cabling. So you don't want to have your
LED switching currents travelling along your cabling if you can
package the LED power supply right at the LEDs.

I'll double-check that the sheet I have is for the manufacturer I've
got. Unfortunately, I didn't know much about the difference between
logic families _before_ I bought my last batch of stuff, and I certainly
didn't suspect that there was a _minimum_ on the input rise; I just
figured there was a threshold point unless there was a Schmitt trigger
involved, and that newer series with pin compatibility could (in
general) be used as drop-in replacements. I know better now, don't I?
:-/ From what I'm hearing here, I'd be better off downgrading to, say,
an HC-series? I don't like working without a margin. I'm already
error-prone enough...

I think something like HC would be a much better match.

 

[Mike]

My copy of the 16F88 spec (rev C, page 15) says the POR value for CMCON
is 00000111, not 0.

Thanks
PSM

"The scientist is possessed by the sense of universal
causation...His religious feeling takes the form of
rapturous amazement at the harmony of natural law,
which reveals the intelligence of such superiority
that, compared with it, systematic thinking and acting
of human beings is an utterly insignificant reflection."
Albert Einstein (theoretical physicist)

 

[Mike]

My copy of the 16F88 spec (rev C, page 15) says the POR value for CMCON
is 00000111, not 0.

Thanks
PSM

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

Mike



"The scientist is possessed by the sense of universal
causation...His religious feeling takes the form of
rapturous amazement at the harmony of natural law,
which reveals the intelligence of such superiority
that, compared with it, systematic thinking and acting
of human beings is an utterly insignificant reflection."
Albert Einstein (theoretical physicist)

 

[Peter S. May]

What's the maximum data rate you will need? How many bytes/sec? It
really is starting to sound to me like you want a serial transfer
mechanism. You should have no trouble running a UART to 115 kbaud
over a few feet. That's 10kbytes/sec. You might be able to do quite
a bit faster, perhaps using RS-485 drivers and receivers. But then
you need a UART on the other end.

Or, you could do an SPI-type serial transfer, either with a built-in
SPI module or by bit-banging. Simple MSI shift registers would be
enough on the receiving end. Again, you might want to use RS-485
drivers and receivers. Making the decision really depends on how much
data you have to write out, and also how much processing you need to
do between data transmissions.

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...)

If you can avoid it, you do not want to be passing large high-
frequency currents on your cabling. So you don't want to have your
LED switching currents travelling along your cabling if you can
package the LED power supply right at the LEDs.

This can be done. What I'd planned to do is use some ULN2803A
Darlington arrays to drive the lighting. I figured that in the worst
case I could have just the array on the breakouts and everything else on
the main board. This seemed like a good match, given that the 2803
interfaces directly with TTL-compatible levels and is rated at 1.35mA
max input current (it appears to be more or less a high-current 7405
with two extra NOT gates). Then, I could use beefier supply cables to
drive the lights themselves. The PSU is rated for 300W, and I know that
ATX power ratings are for suckers, but at a pessimistic 40% estimate,
120W, it should still be a good deal more than necessary. (Cut this
hubris off now, if you must!)

Thanks again; this project may be saved yet...
PSM