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


Groups > comp.lang.forth > #39087

Re: A Little Help Here?

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

Show all headers | View raw


On 5/13/2015 6:32 AM, Wolfgang Allinger wrote:
>   On 13 May 15 at group /comp/lang/forth in article miuuid$o95$1@dont-email.me
>   <gnuarm@gmail.com>  (rickman)  wrote:
>
>> 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.
>
>>> 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.
>
> Exactly thats the Problem. For some xxx nsec the digit drive is
> changing. One bit is faster than the second. Thats normal if they change
> the digit drive in the same output register with one instruction.
>
> So you should read the digit drive state, than the segment drive state
> and again the digit drive state. With forth thats easy.
>
> snippet:
>
>   drive@
>   segment@
>   drive@
>   rot
>   = IF 7decode ... ELSE drop THEN
>
>
>
>>> 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.
>
> Yes, so you must be shure, that you read the segments while drive is
> stable. drive is stable, if it is the same value before and after
> reading the segment.

I'm not going to keep reiterating this.  The digit drive changes and is 
then stable for 5 ms.  Once I detect that the digit drive has changed 
and is a valid one-hot code, I no longer need to check for it to be 
stable.  It will be stable for *5 milliseconds*!!!!

The assumption is that the segment drive is also stable.  This is backed 
by the observations (never a wrong segment value read once I fixed the 
sync code) and by the delay introduced by the digit drive being pulled 
down by resistor.

There is no reason for you to suspect a problem in the reading of the 
segments.


>> No, this is not needed.  As I said, I am waiting for the digit marker
>> to change.
>
> Thats the wrong way. You must be shure that the digit is stable when
> reading segment. Anyhow your solution by reading 3 times the same value
> is a little overkill, but works.

Verifying three successive reads of the same value fixes a different 
problem.  In this demo the display value is not static.  Turns out it 
can change other than at the end of all three digits being displayed. 
So I can get digit 1 from the first reading and digits 2 and 3 from an 
updated value.  The count starts at 200 and counts down to 0.  I have 
seen 150 > 159 > 149 clearly indicating the problem.


>> This is not a product I'm designing.
>
> Anyhow you should try to make a good code.
>
>> It is just a demo for a friend.
>
> Anyhow you should try to make a perfect code.

I'm sorry you don't like my code, but you don't understand the issues.


>> We'll see how good my chinglish is.
>
> Oh, I assumed that `rickman` is a native English speaker. I`m not, just
> a bloody old German :)

Yes, I am in the US and a lot of the documentation for Mecrisp is 
German.  I am making a lot of good use of various translation sites.  I 
would possibly be fairly fluent in written German but they changed the 
rules on me.  In high school I decided to study Chemistry in college and 
had been told German would be required.  But when I looked into it 
further that requirement was being dropped at most universities.  Seems 
some 100 years ago all the truly great chemists were German.  But over 
time the rest of the world caught up.

One of my professors said the back story was that the German chemists 
were able to crystallize compounds that others couldn't.  The half 
joking explanation was that seed crystals would fall from their great 
beards into the solutions.  lol


>> but Forth will clearly be my friend in this
>> one as I test it interactively.
>
> Thats the main reason, why forth is so excellent.
>
>
> Saludos (an alle Vernünftigen, Rest sh. sig)
> Wolfgang

"Greetings to all sensible people"  Am I close?  "Saludos" doesn't show 
up in any German > English web sites I use.  Shows up as Spanish.

-- 

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