Maker Pro
Maker Pro

Using an open collector signal as a CLOCK for PCB logic?

V

valentin tihomirov

Jan 1, 1970
0
HI,

Previews version of my device performed satisfactory. After slight
modifications, I've got a trouble. PCB dimention is 100 x 200 mm. I control
device with TUSB3210 MCU, all its GPIOs are open-collector. MCU runs at 48
MHz. Shift registers are used to extend number of inputs and outputs. 32
inputs form binary (0, 1) sensors are read via 4 x LV165A and 32 LEDs are
controlled by 4 x VHC595. In the previous version LV595A were used instead
VHC. All CLK inputs of the shift registers are controlled by single GPIO of
MCU. The problem is in wrong values the input shift registers deliver to uC.
I suppose it is because registers are D flip-flops and CLK reaches shift
regs out of sync. There are several arguments for this supposition.

I seems that values of neibghor registers are mixed. I feed 1 to the all 32
inputs and shift them into MCU, the most distant shift_in register has 0 as
input. I monitor the values at the inputs by shifting them out into 32 LEDs.
Occasionally, the most distant LED starts switching (goes state 0 and then
back into state 1). When I touch any shift_out reg by hand the switches
occur more frequently. Note, the only signal shared between shift_in and
shift_out register chains is CLK.

The oscillations are easy to explain when you know that input of the most
distant (from MCU) shift_in reg is connected to GND (stub ot the input
chain). The problem is inherent to all my boards but the oscillations are
stochastic and therefore hard to debug. Nevertheless, I've succeeded
debugging sifting in process step-by-step. The curious thing is that
previous shift_in reg in chain shifted out eight 1s but the next shifted out
seven 1s followed by 0. One of the 1s is overwritten by zero! The zero is
coming from end of the chain, it is a stub of the input chain; it follows
most distant sensor and overwrites it. The only reason for this I see is the
0 emerges at the output of shift_in reg before following register samples
correct value.

Another argument is the fact that replacing the stub from GND to VCC the
oscillation stops, i.e we cannot distinguish between input 1 and stub 1
overwriting the input.



schematic:

STUB -> shift_in chain -> MCU -> shist_out chain





How realistic my assumptions are? What are general rules for controlling
clock signal by GPIO on PCB? I could not predict this could be is a
challange for low-cost 8bit MCU. Thanks in advance.
 
F

Frank Bemelman

Jan 1, 1970
0
valentin tihomirov said:
HI,

Previews version of my device performed satisfactory. After slight
modifications, I've got a trouble. PCB dimention is 100 x 200 mm. I control
device with TUSB3210 MCU, all its GPIOs are open-collector. MCU runs at 48
MHz. Shift registers are used to extend number of inputs and outputs. 32
inputs form binary (0, 1) sensors are read via 4 x LV165A and 32 LEDs are
controlled by 4 x VHC595. In the previous version LV595A were used instead
VHC. All CLK inputs of the shift registers are controlled by single GPIO of
MCU. The problem is in wrong values the input shift registers deliver to uC.
I suppose it is because registers are D flip-flops and CLK reaches shift
regs out of sync. There are several arguments for this supposition.

I seems that values of neibghor registers are mixed. I feed 1 to the all 32
inputs and shift them into MCU, the most distant shift_in register has 0 as
input. I monitor the values at the inputs by shifting them out into 32 LEDs.
Occasionally, the most distant LED starts switching (goes state 0 and then
back into state 1). When I touch any shift_out reg by hand the switches
occur more frequently. Note, the only signal shared between shift_in and
shift_out register chains is CLK.

The oscillations are easy to explain when you know that input of the most
distant (from MCU) shift_in reg is connected to GND (stub ot the input
chain). The problem is inherent to all my boards but the oscillations are
stochastic and therefore hard to debug. Nevertheless, I've succeeded
debugging sifting in process step-by-step. The curious thing is that
previous shift_in reg in chain shifted out eight 1s but the next shifted out
seven 1s followed by 0. One of the 1s is overwritten by zero! The zero is
coming from end of the chain, it is a stub of the input chain; it follows
most distant sensor and overwrites it. The only reason for this I see is the
0 emerges at the output of shift_in reg before following register samples
correct value.

Another argument is the fact that replacing the stub from GND to VCC the
oscillation stops, i.e we cannot distinguish between input 1 and stub 1
overwriting the input.



schematic:

STUB -> shift_in chain -> MCU -> shist_out chain





How realistic my assumptions are? What are general rules for controlling
clock signal by GPIO on PCB? I could not predict this could be is a
challange for low-cost 8bit MCU. Thanks in advance.

Maybe you should try to load a pattern (0x55, 0x55, 0x55, 0x55) into
the 32 bit led drivers, and check if that is stable. If it is stable,
then the problem is with the reading of the input shift registers.

About the clock itself, if it is open-collector, add a 1K resistor to
VCC. Same applies to the data-output, if that is also open-collector.

Software: if you bitbang these shift registers, add a few NOP's after
setting the data-ouput, before you generate the clock pulse.
 
V

valentin tihomirov

Jan 1, 1970
0
Thanks,
Maybe you should try to load a pattern (0x55, 0x55, 0x55, 0x55) into
the 32 bit led drivers, and check if that is stable. If it is stable,
then the problem is with the reading of the input shift registers.
They are not stable, seems that problem is with both.
About the clock itself, if it is open-collector, add a 1K resistor to
VCC. Same applies to the data-output, if that is also open-collector.
Software: if you bitbang these shift registers, add a few NOP's after
setting the data-ouput, before you generate the clock pulse.
I've done this earlier for the rise time to keep up 48MHz.
 
V

valentin tihomirov

Jan 1, 1970
0
Merry Cristmass to everybody. Additional 1k pullup @ CLK solved the problem.
 
Top