It's a pain for the microprocessor, but so what? It shouldn't take it long to shift out 24 bits, even at a low clock rate.
A modern 74HC595 can accept data at a whopping 100MHz. At that speed, it would take a quarter of a microsecond
to send 24 bits. However, with an ordinary microcontroller, you aren't likely to be sending bits that fast. But you aren't
going to have to worry about outrunning your shift registers, that's for sure!
Hey, David - I think your nixie watch runs its CPU at 8kHz - how long does it take to shift out the 20 or so bits it uses to talk
to its two nixie tube drivers? I'm guessing less than 1/20 of a second.
You don't have to worry about your digits flickering wildly while the registers are being updated. In fact, it can be a
cool effect and help avoid cathode poisoning if you wanted to intentionally clock your data slowly enough to be seen,
and strobe your latches with the clock signal. If you want to make the update process completely invisible, just wait
until you've sent all 24 bits and then strobe the latches to update the displays.
The code to shift out 24 bits is not very complicated - just call the 8-bit version, once each for 3 bytes of data. You
could even arrange the bytes sequentially in RAM and iterate through them.
Some clocks (like B7971 clocks with individually addressible 16-segment tubes, or VFD clocks with dozens of
separate segments) shift out hundreds of bits every second or even more frequently. Yeah, the processor is
doing a lot of work, but so what? It's not like your clock CPU is doing protein folding with its spare cycles.
It only starts to matter when you're really trying to conserve power, and I don't think that's a logical goal when using
six direct drive tubes with six power-hungry TTL driver chips.
Alternatively, you could drive the shift register chips individually - run one I/O pin to all three data inputs, and use
three I/O pins for the clocks - one to each shift register. That way, you could choose which chip to update, and
you'd still only need four I/O pins. Normally this is done by paralleling both the clock and data input inputs, and
using a chip select or enable input to specifiy which chip you want to talk to, but the 74HC595 doesn't have a
chip select input, so you'd have to implement that yourself by gating the clock inputs, and using more I/O pins.
> I'm hoping someone with more experience using arduinos and shift registers could provide some insights / tips. I'm also open to hearing about how to use these from a uC agnostic perspective if noone on list is doing this with arduinos, but some code snippets would be ideal from the arduino perspective.
While I've worked with several different microcontrollers over the years, and mostly use AVR these days, you're right -
the concepts aren't processor specific. Some microcontrollers have hardware support for sending serial data in various
formats, but as long as you can individually control two I/O pins, you can talk to all sorts of things. Getting the data
transmission to work at all can be annoying, but once it works, it tends to be extremely reliable, and you can safely
hide the details in a subroutine you simply call whenever you want to send something.
I've used a 36-bit DSP chip with no concept of bytes or bits, just its weird 36-bit words, to implement the Dallas
"1 wire" serial protocol. It was kind of hairy to do, but it worked.
In short, I'd just send all 24 bits once every second, updating all six driver chips. If there's a transmission glitch, one
digit will be wrong, but since all digits are updated every second, it won't be wrong for more than that second. If
you're getting frequent glitches, there's probably something wrong with the wiring or the code talking to the shift registers.
>
> Thanks,
> Dylan
>
> --
> You received this message because you are subscribed to the Google Groups "neonixie-l" group.
> To post to this group, send an email to neoni...@googlegroups.com.
> To unsubscribe from this group, send email to neonixie-l+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/neonixie-l?hl=en-GB.
Dylan,
A clever programmer will figure out how to use the Arduino's SPI port
with the 74HC595s to eliminate all the software work of banging out the
bits. I've never used an Arduino, so I don't know how it's done. I've
used this chip with the PIC SPI port, and it works.
--
David Forbes, Tucson AZ
--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To post to this group, send an email to neoni...@googlegroups.com.
To unsubscribe from this group, send email to neonixie-l+unsubscribe@googlegroups.com.
To unsubscribe from this group, send email to neonixie-l+...@googlegroups.com.
There are two aspects to using a shift register. The first is sending
the bits. This happens one at a time, no matter how you do it, because
there's only one data line.
The second aspect is when the display gets updated, which occurs when
you send a pulse on the latch enable line, which causes the contents of
the shift registers to get loaded into the output registers. That's when
the display changes.
I'm assuming that you have wired the 595s in a string, with data out
from the first going to data in to the second, and all the clocks and
latch enables and resets wired together and driven by one Arduino pin each.
Ogi lumen nixie kit (google it) is based exactly the same components you re going to use.
They also provide schema and an arduino library to drive it.
I used that library as example to build my clock based on shift register
--
Julien Noël