Simple Clockable Decoder Chip

On May 6, 4:03=A0pm, 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).

On May 6, 9:19 am, 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).

If you did it right for the display, you can free up more than one pin
for the shift register.

On May 6, 12:19 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).

No, if you do it right only one pin is needed to clock the pair of
shifters.

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 ;-)

cs_posting@hotmail.com wrote:

>> With the shift register setup, two pins are needed (one for clock, one
>> for data input).
> 
> No, if you do it right only one pin is needed to clock the pair of
> shifters.
> 
> 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 ;-)

Naah, just add an RC filter on the shift signal to generate the reset. 
Short pulses for shifting, long pulse for reset. :)

On May 6, 5:27=A0pm, linnix <m...@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.

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.

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.

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!

Tom�s � h�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.

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?