Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #39068

Re: A Little Help Here?

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: A Little Help Here?
Date 2015-05-13 03:31 -0400
Organization A noiseless patient Spider
Message-ID <miuuid$o95$1@dont-email.me> (permalink)
References <DGiFzBTjQoB@allinger-307049.user.uni-berlin> <miu55v$osm$2@dont-email.me> <DGiGONwjQoB@allinger-307049.user.uni-berlin>

Show all headers | View raw


On 5/12/2015 10:08 PM, Wolfgang Allinger wrote:
>
>   On 12 May 15 at group /comp/lang/forth in article miu55v$osm$2@dont-email.me
>   <gnuarm@gmail.com>  (rickman)  wrote:
>
>> On 5/12/2015 7:37 AM, Wolfgang Allinger wrote:
>>>    On 12 May 15 at group /comp/lang/forth in article
>>>    mis0te$p1v$1@dont-email.me <gnuarm@gmail.com>  (rickman)  wrote:
>>>
>>>> I am reading a multiplexed, 3 digit, 7 segment LED display and
>>>> converting it to a number.  I have the code working pretty well
>>>> except that maybe once in a couple of hundred reads it glitches.  I
>>>> would believe I missed something in my code or that the hardware is
>>>> not perfect, but the symptoms don't point to anything I can pin
>>>> down.
>>>
>>> You should read digit segment digit, and only if digit is equal,
>>> then process segment, otherwise you are not shure, if digit belongs
>>> to the segment reading.
>>>
>>> Or find out which edge of digit is valid while segment is stable. A
>>> 2 channel osci would be helpfull. And just wait for the right flank,
>>> then read segment.
>
>> I'm not totally sure what you are saying, but I think I am doing what
>> you suggest.  I wait for the digit marker to change, then I sample the
>> segment which should be stable.
>
> Thats not, what I sugested.
>>
>> I found the source of the problem, I was seeing the digit marker with
>> two bits set right at the transition.  I am rejecting that now.
>
> Thats not the whole thing what happened! When the digit marker changes,
> you might have an incorrect segment, you have to find out, with an osci,
> if there is a correlation between one of the edges of the digit marker
> change and a stable segment. That marks the point of stable segment.
> I can`t believe that the segment changes while the digit marker is
> stable.

Yes, there are many possibilities of how the signals change.  But this 
is just a multiplexed LED and there is no reason why the designers would 
have gotten fancy with it.  They have to drive 8 segments and 3 digit 
lines.  They very likely write them using just a few simple instructions 
so that without something like a logic analyzer or oscilloscope (btw, I 
read your post a number of times before I realized what "an osci" meant) 
it would be hard to tell.  What I am saying is that in their app, it 
would not matter one whit if there were some number of ns between the 
segments changing and the digits changing.  I just have to not read them 
so fast that I get wrong data which doesn't seem to happen, partly 
because I added logic to read the same value three times before I 
consider it valid.  It seems to be working perfectly now.

> The other way is much better, assuming that the scan frequency is fast
> enough:
>
> You must read the digit marker, then the segment and once more the digit
> marker. If both digit marker reads are equal, then the segment is valid
> and you can process it. Otherwise you have a racing condition, where you
> have nonsense data.

No, this is not needed.  As I said, I am waiting for the digit marker to 
change.  Once it changes to a valid one-hot value it won't change again 
for 5 ms.  The segments change state faster because they are driven 
harder by the LED and MCU outputs.  The digits are driven hard to the 
high state by the MCU, but only weakly to the low state by pulldown 
resistors I have added.  So once the digit lines have entered a solid, 
stable state the segments have long sense settled.

It is late and I'm tired.  So I can't be sure I am looking at this 
correctly.  But the code is working well at this point.  I prefer not to 
drag out the test equipment and the tests I have done on the display I/O 
seems to indicate the only complication I see in reading the digits and 
segments is that the digits are not one-hot at the transitions.  I was 
expecting the digits to go to zero before the next one-hot state, but 
obviously the transitions are very close together.  I think it is the 
details of the hardware that adds enough overlap for it to be detected, 
but I can't be sure their code isn't just a bit odd.

This is not a product I'm designing.  It is just a demo for a friend.  I 
need now to integrate a bluetooth module to relay the status and I'm 
done.  We'll see how good my chinglish is.  I'm using the HC-05 module 
which is very popular on eBay.  I think I have a data sheet that 
explains how to use it, but Forth will clearly be my friend in this one 
as I test it interactively.

-- 

Rick

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 00:53 -0400
  Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 03:51 -0400
    Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 03:54 -0400
    Re: A Little Help Here? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-05-12 04:09 -0400
      Re: A Little Help Here? Tessa Bonting <tessa.bonting@gmail.com> - 2015-05-12 07:48 -0700
        Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 13:51 -0400
          Re: A Little Help Here? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 19:46 +0100
            Re: A Little Help Here? "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 19:53 +0100
              Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 20:15 -0400
                Re: A Little Help Here? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-12 19:29 -1000
            Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 21:18 -0400
  Re: A Little Help Here? all2001@spambog.com (Wolfgang Allinger) - 2015-05-12 08:37 -0300
    Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-12 20:18 -0400
      Re: A Little Help Here? all2001@spambog.com (Wolfgang Allinger) - 2015-05-12 23:08 -0300
        Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-13 03:31 -0400
          Re: A Little Help Here? all2001@spambog.com (Wolfgang Allinger) - 2015-05-13 07:32 -0300
            Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-13 16:47 -0400
              Re: A Little Help Here? all2001@spambog.com (Wolfgang Allinger) - 2015-05-13 17:48 -0300
                Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-13 22:01 -0400
  Re: A Little Help Here? Tessa Bonting <tessa.bonting@gmail.com> - 2015-05-13 08:56 -0700
  Re: A Little Help Here? Tessa Bonting <tessa.bonting@gmail.com> - 2015-05-13 09:22 -0700
    Re: A Little Help Here? rickman <gnuarm@gmail.com> - 2015-05-13 16:56 -0400

csiph-web