1
\$\begingroup\$

I'm trying to make a unit in which 4 digits can be updated in a small amount of time from a single-cycle microcontroller (preferably all digits updated within 5uS)

My circuit is setup in the following way, (I excluded 7 segment displays and resistors for simplicity). The shift registers are 74HC595 and the multivibrator on left is the CD4538 but I think I need to upgrade that to 74HC4538 (someone confirm this?)

I have a multivibrator because the shift registers need the register clock toggled to display the new data that is shifted in, so by adding one, I eliminated a need of a 3rd wire from the micro that only updates the value.

The resistor is 10K and the capacitor is 1nF.

If I use a lower speed micro like the AT89S52 that can only update GPIO pins at best of 1/2 a microsecond (with 22Mhz crystal), then this circuit has no problem. But if I start to use the high speed single-cycle microcontroller, then GPIO pins could update as fast as 20nS.

What can I do to improve this circuit without rearranging parts? Should I just upgrade the multivibrator and lower capacitor value?

shift register timing

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Can't you just add a few NOPs between writes to the I/O pins? \$\endgroup\$
    – Elliot Alderson
    Jan 16, 2019 at 19:30
  • \$\begingroup\$ Do you need to update the outputs every 5us, or just update all of them within 5us for a much slower refresh rate? \$\endgroup\$
    – Phil G
    Jan 16, 2019 at 20:27
  • \$\begingroup\$ Don't forget 0.1uF caps on each shift register VCC pin to Gnd. \$\endgroup\$
    – CrossRoads
    Jan 16, 2019 at 20:43
  • 3
    \$\begingroup\$ I daisychained 45 shift registers like that, and used SPI transfers from an Atmel Atmega1284P clocked at 16 MHz. SPI clock was set to 8 MHz, I was able to update them every 50uS (17 clocks each, so 1.06uS each byte that was sent out). AT89S52 also supports SPI transfers. 4 would then have taken just over 4uS at 16 MHz. With a 22MHz clock, and SPI clocked at 11 MHz , then 4 should take a touch over 3uS. \$\endgroup\$
    – CrossRoads
    Jan 16, 2019 at 20:52

1 Answer 1

Reset to default
1
\$\begingroup\$

Be aware that the 595 used in this way has a problem: The daisy chain output changes at the same clock edge as the input of the next chip samples. A chip that is really designed for this kind of use (IIRC there is one in the CD series) has a delayed daisy chain output.

You can mitigate this problem by:

  • delaying the daisy chain output data a tiny bit (RC)
  • applying the clock in reverse: wire it first to the last chip in the chain

I don't understand why you are using that 4538. If you just want to always have the last (shifting!) data on the outputs, you can just wire SCK and SLK together. You will get some ghosting, depending on your update/idle ratio.

\$\endgroup\$
2
  • \$\begingroup\$ I wanted to minimize flicker. Everytime RCK is toggled, the display is updated. If I tie the clocks together then the display will be updated for each bit shifted out which means more flicker. So what I did was create a timeout so that when data stops shifting in, the display is updated once. \$\endgroup\$
    – Mike -- No longer here
    Jan 17, 2019 at 21:34
  • \$\begingroup\$ OK. seems reasonable. \$\endgroup\$
    – Wouter van Ooijen
    Jan 18, 2019 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.