Simple Clockable Decoder Chip
in [Embedded]
|
Prev: Loss of synchronisation: Are the chips reliable?
Next: AVR Assembler (Mega8) - Test if a value has changed more than a given amount
From: rickman on 4 May 2008 15:20 On May 4, 11:24 am, Hans-Bernhard Bröker <HBBroe...(a)t-online.de> wrote: > rickman wrote: > > Let's face it, if this were a commercial project, you would just pick > > a larger MCU and be done with it. > > I wouldn't, and precisely _because_ it's a commercial project. Hobbyist > or one-off in-house projects often have virtually no cost constraints. > It's the commercial ones that do. > > > Of course if you are making a > > million of them a larger CPU is likely more expensive than a 4000 > > series chip. > > Exactly. And below a million pieces, some might not consider it a > commercial project ;-) Obviously you only work on one type of commercial project. Mine are mostly space constrained. I don't have the luxury of using large package devices where I can do the job in a much smaller part, no matter how many I am building.
From: Tomás Ó hÉilidhe on 6 May 2008 14:18 On May 6, 5:27 pm, linnix <m...(a)linnix.info-for.us> wrote: > > Only one pin is needed from the microcontroller. > > > With the shift register setup, two pins are needed (one for clock, one > > for data input). > > If you did it right for the display, you can free up more than one pin > for the shift register. Please elaborate, I haven't a clue what you're on about.
From: Tomás Ó hÉilidhe on 6 May 2008 14:21 On May 6, 5:48 pm, cs_post...(a)hotmail.com wrote: > No, if you do it right only one pin is needed to clock the pair of > shifters. Yes but you need to get a 1 onto it somehow. You can use an RC to do this, but it's messy. I used an RC in my final project board for college, but I won't be doing it again. > However, with either this scheme or the binary counter and decoder you > proposed, > you may find you need a reset or an input back to the uC to > synchronize the software with the display ;-) People advised me about this. They said stuff like "if a bit of noise gets onto...". The way I see it though, if I can't rely on electronics then there's no point in me even trying to get things to work. I've left my current board on overnight for three nights in a row and it was still synchronised. Actually do you know what, I think I'm better off starting another thread about this.
From: Eric Smith on 6 May 2008 15:04 Tomás Ó hÉilidhe wrote: >>> As I said elsethread, I've decided to run a 4-Bit counter into a 4- >>> to-16 decoder. I wrote: >> That will work fine, as long as you don't mind the decoding glitches. Tomás Ó hÉilidhe wrote: > Decoding glitches? Please explain. Example: your four bit counter transitions between 7 and 8, which are of course 0111 and 1000 in binary. Note that all four bits of the output have to change. They don't change simultaneously. This is most evident with a ripple counter, where there will be a non-trivial propogation delay between successive bits changing. With a ripple counter, your actual sequence of events will be: time event ---- ---------------- output is 0111 t0 input clock edge t1 output is 0110 t2 output is 0100 t3 output is 0000 t4 output is 1000 What you expect is that originally output 7 of the decoder is active, and after the clock edge, output 8 of the decoder is active. What actually happens is that you get pulses on outputs 6, 4, and 0 as well. For example, with a 74HC93 counter at 5V and 25C, you'll see those three intermediate values for about 10 ns each. With a synchronous counter, the outputs all change at approximately the same time, rather than sequentially, but it is still the case that due to variations in propogation delay they don't actually change simultaneously. With the 74HC163 at 5V and 25C, the variation seems to be typically under 5 ns, so you might see incorrect values for 5 ns total on a transition. The actual part specifications potentially allow for much more variation than that. They given an upper bound of CP to Qn of 37 ns at 4.5V 25C, but you won't see 37 ns glitches because they don't specify the minimum prop delay, which is significant. Also, due to variations in propogation delay within the decoder itself, there can be very brief periods when two outputs are active simultaneously, or neither, even if the inputs do change simultaneously. I haven't tried to measure it, but I expect that this would typically be under 5 ns. Again, the actual specifications potentially allow for more. These sorts of issues may or may not be a problem in your design, but you should keep them in mind. The shift register approach you started with would only have the variation in propogation delays between the outputs.
From: Jim Granville on 3 May 2008 22:55
rickman wrote: > On May 3, 4:00 pm, Jim Granville <no.s...(a)designtools.maps.co.nz> > wrote: > >>Tom�s � h�ilidhe wrote: >> >>>The only problem though is that I need a chip that will count to 16 >>>instead of 10. Does anyone know of a similar chip that will cycle thru >>>16 different outputs? >> >>>Then again I could always just use two of these chips, but I just >>>thought I'd check to see whether there was a more suitable chip out >>>there. >> >>Just use two of them. They date from DIP package days, and 16 OP >>would not fit into a small DIP (DIP24). >>Or, you can put this into a CPLD. - then you could move to a >>one-wire PWM protocol if you wanted to get much smarter... >> >>-jg > > > But why use a CPLD along with a CPU when you can just use two CPUs? > One input and 16 outputs, heck that can be done in a CPU in a 24 pin > package. The program is about as simple as writing the HDL for the > counter. If you already have an MCU in your system this is like > falling off a log. Only a masochist would want to add obsolete 4000 > series CMOS parts, RC timing or PLDs to such an otherwise simple and > elegant design. This was a project, so normal commercial yardsticks do not apply. However, even when they DO, do not dismiss the 4017 so quickly. It has VERY low static power, cannot crash, and costs 15c for 10 op pins. Show me a Micro that even comes close! If that is ALL you need, using a Micro actually makes little sense. CPLDs also compete reasonably well in a cents/IO function, with a uC, and if you need highish drive current, they can outclass a uC, as most uC have single GND pins, vs commonly 4+ on a CPLD. ie a Micro is not always the best solution. We still use PLD and 4000 cmos in active designs, because they are the best parts for the task. (and uC too, of course!) -jg |