Reply by Jim Granville May 8, 20082008-05-08
Grant Edwards wrote:

> On 2008-05-06, Eric Smith <eric@brouhaha.com> wrote: > >>Tom??s ?? h??ilidhe wrote: >> >>>As I said elsethread, I've decided to run a 4-Bit counter into a 4- >>>to-16 decoder. >> >>That will work fine, as long as you don't mind the decoding glitches. > > > Or as long as he uses a gray-code counter. You can buy gray > code counters, can't you?
Not as a mainstream part. Trivial in a SPLD. What you CAN do, is use a narrow clock, and feed that into the Decoder ENABLE pin, so you blank between states. With driver-delays this can help prevent ghosting effects. -jg
Reply by rickman May 7, 20082008-05-07
On May 6, 12:19 pm, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> On May 6, 4:03 pm, cs_post...@hotmail.com wrote: > > > On May 5, 5:12 pm, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote: > > > > As I said elsethread, I've decided to run a 4-Bit counter into a 4- > > > to-16 decoder. > > > In what way is that superior to daisy chaining two shift-register type > > devices? > > Only one pin is needed from the microcontroller. > > With the shift register setup, two pins are needed (one for clock, one > for data input).
We've had this conversation before. You can use an RC with one control signal, similar to the other kludge... I mean *design* you did with two RCs. The RC will stop the short pulses from reaching the data pin. So you can hold a level for a bit to allow the data pin to establish a state and then give it a fast pulse to clock the data in. I think your design used an RC to hold the input to a one or something like that so the part would set up with a single one bit and the rest zeros. Then it was clocked with feedback so the one circulated forever. But maybe I am not remembering correctly.
Reply by rickman May 7, 20082008-05-07
On May 6, 11:15 am, cs_post...@hotmail.com wrote:
> On May 6, 9:24 am, rickman <gnu...@gmail.com> wrote: > > > Is this intended to teach you something? If so, I would *require* you > > to use a CPLD if I were the instructor. There is very little value in > > learning to use chips that were designed long before the PC. Does > > your instructor also ask you to use a dial phone? Do you connect to > > your computer using a TTY? (do you know what a TTY is?) > > If there's a part available off the shelf for 10 cents, that's likely > going to > beat the programmable logic solution in most cases. > > Where it won't is if you don't have those, or don't want to stock > them, and > go through small CPLD's like jelly beans. Then the cost of > programming > the CPLDs might possibly beat the cost of inventory. > > Or if the 10 cent part (or pair of them) won't do the whole job. If > you need the > CPLD anyway, then this function is no longer the justification for it. > > But usually, if you can buy your whole solution, it's better to do > that than > make a custom one. And for that reason, a lot of old technology chips > survive, albeit in often in smaller modern packages. There's just no > reason > to drop them.
Maybe your designs are different from mine. I just did a design and the only logic part on the board is an inverter which is only there to invert a control line so it can be used to program the PLD. I literally can't remember the last design I did that didn't have a PLD of some sort. In fact, the only design I have *seen* in the last five years that used an SSI or MSI part (other than a single gate) was a controller board that used a keypad encoder. I was involved because we were told the part would be going EOL within a year. So we designed it out. When you say "a lot" of older chips survive, I think the variety is pretty limited. I can't imagine that a part like this will continue indefinitely. The buffers, counters a shift register or two and multiplexers will be about the only parts left before too long. Although there are companies that specialize in obsolete chips. I guess these parts may live on though those channels.
> Rotary dial phones? They had some real issues (finger hurt really > badly trying to > win radio station call in prizes). TTY? Well, I use software > emulation of one > almost every day... that basic idea is sound, but printing on paper > isn't usually needed.
Yeah, that's kinda the point. The concept is still relevant, but the actual TTY was extinct a long time ago. Heck I gave away an LSI terminal (completely designed out of MSI) years ago that I had paid $400 for used... along with my LSI-11 (kinda wish I had kept that one) and a bunch of other stuff. I did keep my 6502 trainer board with the hex keypad, but I haven't seen it in years. I guess I don't really have a lot of call for it. :^) I do still have an 8008 computer around here somewhere, along with documentation. I think I promised it to someone who was making a sort of museum for himself. I never got around to shipping it out, I guess I just don't really want to part with it. MSI is dead, long live MSI.
Reply by Jim Granville May 6, 20082008-05-06
rickman wrote:

> What is your cost limit? CPLDs are pretty cheap. I want to say I > have seen devices for around a dollar US. Even obsolete logic chips > aren't much cheaper than that. > > Is this intended to teach you something? If so, I would *require* you > to use a CPLD if I were the instructor. There is very little value in > learning to use chips that were designed long before the PC. Does > your instructor also ask you to use a dial phone? Do you connect to > your computer using a TTY? (do you know what a TTY is?)
The 4017 candiate is appx 15c in moderate volumes, and has uA standby power, and a small, easily handled package, and 5V operation (so can drive Power MOSFETS). It is in volume production, so is not an obsolete device. (not all 4xxx devices are obsolete) If that is ALL the functionality that is needed, then a CPLD could be a massive overkill. If the 4017 does not make it, and you need to add more chips, then a CPLD moves onto the radar. Avoid the high power ones, and for low power/low voltage designs look at ATF1502BE/XC2C32A/MACH40xxZE series. If you need to drive 5V from a low power CPLD, things get tougher... (that's one combination that has fallen-thru-the-cracks, and another reason those 4xxx / HCxx series devices still sell in volumes ! ) In fact, many 4xxx devices leave CPLD for dead, on a production life-time basis ! So, a well rained designer knows about CPLD _and_ Logic Devices, even back to 4000 series ones. -jg
Reply by Jim Granville May 6, 20082008-05-06
Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe 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).
You can make a vanilla OneWire Shift-Register interface, by using a RC on the Data pin, and pulse-width varying the clock. Assuming a Positive edge Clock : A narrow clock Low time, loads a HI on the rising edge (D Pin is still hi), a Wider clock LOW time, loads a LOW on the rising edge (D pin has had time to follow the clock Lo) Shft registers are very common, and you have a choice of drive-currents. -jg
Reply by May 6, 20082008-05-06
On May 6, 9:35=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de> wrote:

> > 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. > > That's rich, coming from you.
Not really, in fact I think it's to be expected considering I'm a novice at this stuff and I'm explicitly asking people's advice here on what to do.
> You could rely on electronics alright. =A0You would have to stop > *designing* them with such total, aggressive disregard to reliability, > though.
Hypothetically speaking, if I couldn't rely on a counter incrementing from 011 to 100, then why should I bother even trying to use it in a design? This is what I'm trying to understand.
> =A0It's become clear that you don't listen to any advice along > those lines. =A0That's your decision to make, sure, but that also makes > all advers consequences entirely your fault. =A0We did tell you so.
Well I'd hardly post entire threads here looking for advice if I was going to disregard the responses.
> > I've left my current board on overnight for three nights in a row and > > it was still synchronised. > > How do you know it's "still" synchronized, as opposed to having rebooted > and re-synchronized itself 20 times (always while you weren't looking) ove=
r? If the microcontroller were to reboot, then the LED matrix would be in a totally different state. Alas, when after the three nights, the display is exactly the way I left it.
> Anyway, a test like that proves diddly-squat. =A0You have to stress it to > expose flaws. =A0Switch on a mobile phone directly on top of your device. > =A0 Fire up a piezo lighter in different places. =A0Heat it. =A0Cool it. =
=A0Drop
> it. =A0Flex it. =A0In short: let it see some abuse.
So are you advocating using two pins to control the shift register, rather than one?
Reply by May 6, 20082008-05-06
Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe wrote:

> 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.
That's rich, coming from you. You could rely on electronics alright. You would have to stop *designing* them with such total, aggressive disregard to reliability, though. It's become clear that you don't listen to any advice along those lines. That's your decision to make, sure, but that also makes all advers consequences entirely your fault. We did tell you so.
> I've left my current board on overnight for three nights in a row and > it was still synchronised.
How do you know it's "still" synchronized, as opposed to having rebooted and re-synchronized itself 20 times (always while you weren't looking) over? Anyway, a test like that proves diddly-squat. You have to stress it to expose flaws. Switch on a mobile phone directly on top of your device. Fire up a piezo lighter in different places. Heat it. Cool it. Drop it. Flex it. In short: let it see some abuse.
Reply by Grant Edwards May 6, 20082008-05-06
On 2008-05-06, Eric Smith <eric@brouhaha.com> wrote:
> Tom??s ?? h??ilidhe wrote: >> As I said elsethread, I've decided to run a 4-Bit counter into a 4- >> to-16 decoder. > > That will work fine, as long as you don't mind the decoding glitches.
Or as long as he uses a gray-code counter. You can buy gray code counters, can't you? -- Grant Edwards grante Yow! I wish I was on a at Cincinnati street corner visi.com holding a clean dog!
Reply by Eric Smith May 6, 20082008-05-06
Tom&aacute;s &Oacute; h&Eacute;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&aacute;s &Oacute; h&Eacute;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.
Reply by May 6, 20082008-05-06
On May 6, 5:48=A0pm, cs_post...@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.