> I will need three 74HC595s if I go this route (6xABCD, 8 registers per 595 > IC). The techniques I had come across on the Arduino consisted of serially > feed bits to the 595 until all 8 registers per chip were full. It would seem > like I need to send 24 bits each second as the clock ticks. The fact that I > have to do this serially one bit at a time seems like a pain in the neck. Am > I missing something (I'm sure I probably am) in terms of being able to set > all 24 in parallel?
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 neonixie-l@googlegroups.com. > To unsubscribe from this group, send email to > neonixie-l+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/neonixie-l?hl=en-GB. -- You received this message because you are subscribed to the Google Groups "neonixie-l" group. To post to this group, send an email to neonixie-l@googlegroups.com. To unsubscribe from this group, send email to neonixie-l+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/neonixie-l?hl=en-GB.
