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

Groups > comp.lang.forth > #39007 > unrolled thread

A Little Help Here?

Back to article view | Back to comp.lang.forth

Contents

  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

Page 1 of 2  [1] 2  Next page →

#39007 — A Little Help Here?

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.

First I read the three bits that indicate which digit is being displayed 
and when that is on a new digit the word exits returning the three bit 
one-hot code (1, 2, 4) to indicate which bit.  For some reason I see 
this routine returning the same digit on two successive calls which it 
is supposed to not do.

Perhaps someone else can spot something I am missing...

: newdigit@ ( c1 -- c2 ) \ sync to new digit
   begin digits@ 2dup = over 0= or key? not and while
   drop delay repeat nip ;

c1 is the last digit code read and c2 should be a different one.  The 
digits@ reads the port with the three bits, one-hot encoded.  The loop 
exits when either the code changes but not if it goes to zero or a key 
is pressed.  Here is the routine that calls this code.

: poll_loop ( -- ) \ read and display succesive digits from LED
   LED_Init
   0 begin
     newdigit@ segments@ conv7segtodec digit. dup 4 =
     if 13 emit cr then 	\ Mecrisp sends LF from CR word
     key? until key drop ;

This word is just reading, repeatedly displaying the digits until it 
gets the last one and starts a new line, nothing complex here.

The only way I can see to debug this problem is with a logic analyzer 
which is going to be a PITA.  Or I can just code around it.  I know 
which digit is returned from the 7 seg > decimal conversion, so if I get 
the same one twice I can ignore it.  I just hate having bugs I don't 
understand.  You never know if they might bite you later.

I am viewing this data on a raspberry Pi running e4thcom which is 
connected to the target via a USB serial interface at 115200 bps.  The 
error always appears to be an isolated double read of different digits, 
so I don't suspect the data path is dropping characters which would 
produce more random stuff.

It is late and I guess I'm getting tried.  I'll hit this again in the 
AM.  Sometimes I think by writing down the problem, but nothing came to 
me this time other than the work around.

-- 

Rick

[toc] | [next] | [standalone]

#39008

Nevermind.  I spent a little more time on it and found there was some 
overlap of the different digits on the select lines.  So I ignore any 
digit selects that aren't one-hot and it is working fine now.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39009

On 5/12/2015 3:51 AM, rickman wrote:
> Nevermind.  I spent a little more time on it and found there was some
> overlap of the different digits on the select lines.  So I ignore any
> digit selects that aren't one-hot and it is working fine now.

The interactivity of Forth made this so much easier to probe and solve.  :)

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39010

On Tue, 12 May 2015 03:51:06 -0400, rickman <gnuarm@gmail.com> wrote:

> Nevermind.  I spent a little more time on it and found there was some  
> overlap of the different digits on the select lines.  So I ignore any  
> digit selects that aren't one-hot and it is working fine now.
>

So, the one-hot digit selects weren't actually one-hot, but two- or
three-hot ... ?

Was the data being latched?  So, this was just some sampling jitter?

You didn't post your Forth fix, so I'm left wondering if an adjustment
to 'delay' in newdigit@ would've fixed this issue or not.


Rod Pemberton

-- 
If fewer guns reduced murders, how does one
explain Moscow, Chicago, and South Africa?

[toc] | [prev] | [next] | [standalone]

#39023

Op dinsdag 12 mei 2015 10:08:51 UTC+2 schreef Rod Pemberton:

> 
> > Nevermind.  I spent a little more time on it and found there was some  
> > overlap of the different digits on the select lines.  So I ignore any  
> > digit selects that aren't one-hot and it is working fine now.
> >
> 
> So, the one-hot digit selects weren't actually one-hot, but two- or
> three-hot ... ?
> 
> Was the data being latched?  So, this was just some sampling jitter?
> 
> You didn't post your Forth fix, so I'm left wondering if an adjustment
> to 'delay' in newdigit@ would've fixed this issue or not.
> 
> 
> Rod Pemberton
> 

When I was programming for digital readout systems, like AtoD converters,
I allways used to swith the display of by writing a all segments off
to the display post, change the digit number and afther a little delay
the new digit segment info to the proper port.
This just to get rid of aftherclow of the prefious to the next digit.
Thats why there is a possibility to read a double change.
Succes, Tessa

[toc] | [prev] | [next] | [standalone]

#39037

On 5/12/2015 10:48 AM, Tessa Bonting wrote:
> Op dinsdag 12 mei 2015 10:08:51 UTC+2 schreef Rod Pemberton:
>
>>
>>> Nevermind.  I spent a little more time on it and found there was some
>>> overlap of the different digits on the select lines.  So I ignore any
>>> digit selects that aren't one-hot and it is working fine now.
>>>
>>
>> So, the one-hot digit selects weren't actually one-hot, but two- or
>> three-hot ... ?
>>
>> Was the data being latched?  So, this was just some sampling jitter?
>>
>> You didn't post your Forth fix, so I'm left wondering if an adjustment
>> to 'delay' in newdigit@ would've fixed this issue or not.

The fix was to reject anything that wasn't a one-hot value.  The delay 
was only inserted to allow viewing of the debug data on the output 
without being overrun.  I don't have the old code, but here is the new 
code, actually *very* new.  I just rewrote some of it for simplification 
and I no longer have the code I tested last night.  So this is untested 
and may have Jeff Fox counting bugs (as in, "it proves you can't count").

: one-hot ( n1 -- n2 ) \ return value if exactly one bit set
   case
     1 of 1 endof
     2 of 2 endof
     4 of 3 endof
     0 ( default )
     endcase ;

: newdigit@ ( c1 -- c2 ) \ sync to new digit
   begin digits@ one-hot 2dup = over 0= or key? not and while
     drop delay repeat nip ;

This code should work fine without the delay.  If you would like I'll 
test it without the delay.


> When I was programming for digital readout systems, like AtoD converters,
> I allways used to swith the display of by writing a all segments off
> to the display post, change the digit number and afther a little delay
> the new digit segment info to the proper port.
> This just to get rid of aftherclow of the prefious to the next digit.
> Thats why there is a possibility to read a double change.
> Succes, Tessa

The LEDs are being driven by an MCU.  I expect they are changing the 
digit selects and the segment drives at the same time.  Still, that 
would be a very low likelyhood that my MCU would see them both set at 
the same time (a few nanoseconds every 5 milliseconds).  I think it is 
likely that there is some slowness to the voltage transitions.  The 
anodes are pulled up hard by the outputs and tristated for a low which 
means they are pulled down passively so the transitions are relatively 
slow.  Actually I have seen this on the scope and didn't give it much 
attention.  The only reason the undriven anodes pull down at all is the 
10 kohm voltage dividers I added for 5v > 3v on the MCU inputs.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39038

on 12/05/2015 18:51:50, rickman wrote:

> 
>: one-hot ( n1 -- n2 ) \ return value if exactly one bit set
> case
> 1 of 1 endof
> 2 of 2 endof
> 4 of 3 endof
> 0 ( default )
> endcase ;

Without branches;

create one-bit 0 c, 1 c, 2 c, 0 c, 3 c, 0 c, 0 c, 0 c,
: one-hot ( n1 -- n2 ) 7 and one-bit c@ ;

[toc] | [prev] | [next] | [standalone]

#39039

on 12/05/2015 19:46:42, "Alex McDonald" wrote:

>: one-hot ( n1 -- n2 ) 7 and one-bit c@ ;

: one-hot ( n1 -- n2 ) 7 and one-bit + c@ ;

[toc] | [prev] | [next] | [standalone]

#39051

On 5/12/2015 2:53 PM, Alex McDonald wrote:
> on 12/05/2015 19:46:42, "Alex McDonald" wrote:
>
>> : one-hot ( n1 -- n2 ) 7 and one-bit c@ ;
>
> : one-hot ( n1 -- n2 ) 7 and one-bit + c@ ;

Thanks.  The 7 and is not really needed as the input value is already 
masked off.

I really need to get a better handle on creates and <builds.  I seem to 
have forgotten everything I ever knew about the dictionary structure.  I 
think I used to have some idea, but it was based on the implementations 
I knew.  The forth standard uses rather generic descriptions to permit 
multiple types of implementations and it just doesn't stir the 
recollections.

I'll get there eventually.  I just need to focus on it a while and then 
take some notes so that I can remember again when I return to it.

I have been very confused by Matthais's comments that create in his 
forth gives the word defined a "default action which cannot be changed 
later".  Not at all clear on what that means.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39064

On 5/12/15 2:15 PM, rickman wrote:
> On 5/12/2015 2:53 PM, Alex McDonald wrote:
>> on 12/05/2015 19:46:42, "Alex McDonald" wrote:
>>
>>> : one-hot ( n1 -- n2 ) 7 and one-bit c@ ;
>>
>> : one-hot ( n1 -- n2 ) 7 and one-bit + c@ ;
>
> Thanks.  The 7 and is not really needed as the input value is already
> masked off.
>
> I really need to get a better handle on creates and <builds.  I seem to
> have forgotten everything I ever knew about the dictionary structure.  I
> think I used to have some idea, but it was based on the implementations
> I knew.  The forth standard uses rather generic descriptions to permit
> multiple types of implementations and it just doesn't stir the
> recollections.
>
> I'll get there eventually.  I just need to focus on it a while and then
> take some notes so that I can remember again when I return to it.
>
> I have been very confused by Matthais's comments that create in his
> forth gives the word defined a "default action which cannot be changed
> later".  Not at all clear on what that means.

CREATE foo 0 ,
...defines a word which, when executed, returns the address of the next 
cell in data space, which in the case of foo contains zero. "Returns the 
address..." is the default behavior assigned by CREATE; it's compiled 
somehow in the definition of foo (an address of code or some other form).

: ARRAY ( n -- ) CREATE CELLS ALLOT
    DOES> ( i -- a ) CELLS + ;
100 ARRAY STUFF

When ARRAY is executed, it has to *replace* the default behavior 
assigned by CREATE with the behavior following the DOES>.

In contrast, <BUILDS constructs a definition with *no* default behavior. 
Whereas CREATE can be used with or without DOES> <BUILDS actually 
requires DOES> to provide a runtime behavior.

Hope that helps!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#39054

On 5/12/2015 2:46 PM, Alex McDonald wrote:
> on 12/05/2015 18:51:50, rickman wrote:
>
>>
>> : one-hot ( n1 -- n2 ) \ return value if exactly one bit set
>> case
>> 1 of 1 endof
>> 2 of 2 endof
>> 4 of 3 endof
>> 0 ( default )
>> endcase ;
>
> Without branches;
>
> create one-bit 0 c, 1 c, 2 c, 0 c, 3 c, 0 c, 0 c, 0 c,
> : one-hot ( n1 -- n2 ) 7 and one-bit c@ ;
>


Looks like my case statement wasn't even correct.  I have to swap the 
case value and the return value or my default value gets dropped. 
Again, learned and forgotten.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39044

 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.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#39052

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.

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.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39058

 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.

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.


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#39068

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

[toc] | [prev] | [next] | [standalone]

#39073

 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.

[...]


>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.

[...]

>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.



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


>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

-- 
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#39087

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

[toc] | [prev] | [next] | [standalone]

#39092

 On 13 May 15 at group /comp/lang/forth in article mj0d69$6kh$1@dont-email.me
 <gnuarm@gmail.com>  (rickman)  wrote:

>On 5/13/2015 6:32 AM, Wolfgang Allinger wrote:
>>>>>>     wrote:

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

You reported, that you see 2 digits selected at (a short) time, that  
tells me, reading while changing data, therefore assure that the digit  
select is stable.

>>> 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.

I know, its another face of the problem. But before you were discussing  
about find out, why there were problems with 2 selected digits.

Your approach assumes, that there are consective decreasing values.  
That`s ok for a down counter. But not all data is consecutive.


>>> 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.

No, I understand it very well. Many years ago I developed a System,  
which reads the 7seg codes from hundreds of Multimeters transfering as  
binary to very long line (slow) bus which end up in a PC... All these  
meters were unsynchronisized and I managed never read/report glitches :)

I am an electronic engineer, developing some 200 products in 45yrs with  
Minicompters and uC HW & SW for industrial control, nuclear power  
plants, steel mills, traffic control, medical equipment, aerospace,  
MIL...

---8X--- snipping baits on Germans. :(

I have also one for you, because you asked for it:

Amerikaner reifen bis 14, danach wachsen sie bloss noch.
Q.E.D.  :]

>> Saludos (an alle Vernünftigen, Rest sh. sig)

>"Greetings to all sensible people"  Am I close?

"Greetings (to all reasonable people, others see my sig)"

>"Saludos" doesn't
>show up in any German > English web sites I use.  Shows up as Spanish.

I`m living in Paraguay (PY) now.
and you should try to understand my sig.

Anyhow, I will stop the discussion here, remember you asked for help not  
me! I`m not longer waste my time.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#39095

On 5/13/2015 4:48 PM, Wolfgang Allinger wrote:
>
>   On 13 May 15 at group /comp/lang/forth in article mj0d69$6kh$1@dont-email.me
>   <gnuarm@gmail.com>  (rickman)  wrote:
>
>> On 5/13/2015 6:32 AM, Wolfgang Allinger wrote:
>>>>>>>      wrote:
>
>> There is no reason for you to suspect a problem in the reading of the
>> segments.
>
> You reported, that you see 2 digits selected at (a short) time, that
> tells me, reading while changing data, therefore assure that the digit
> select is stable.

I think we are not communicating on this.  I see some overlap in the 
digit select lines.  That issue is resolved by only accepting values 
that are one hot.  The timing of reading the segment lines is controlled 
by the digit lines.  When the digit selected changes the segment is 
read.  I have not seen any failures of any kind once I got the bugs out 
of the code and looked at the results in detail.


>>>> 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.
>
> I know, its another face of the problem. But before you were discussing
> about find out, why there were problems with 2 selected digits.

Yes, exactly.  There are several issues and each has a separate fix in 
place.


> Your approach assumes, that there are consective decreasing values.
> That`s ok for a down counter. But not all data is consecutive.

My approach for reading the data does not make any assumptions about the 
data other than that it will be stable for three readings.


>>>> 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.
>
> No, I understand it very well. Many years ago I developed a System,
> which reads the 7seg codes from hundreds of Multimeters transfering as
> binary to very long line (slow) bus which end up in a PC... All these
> meters were unsynchronisized and I managed never read/report glitches :)
>
> I am an electronic engineer, developing some 200 products in 45yrs with
> Minicompters and uC HW & SW for industrial control, nuclear power
> plants, steel mills, traffic control, medical equipment, aerospace,
> MIL...

Wonderful.  But when you repeatedly claim that I am doing it wrong in 
spite of repeated attempts to explain why my approach works just fine, I 
have to assume that you are missing something in my explanation.


> ---8X--- snipping baits on Germans. :(

I assume this means you didn't appreciate my comments.  Sorry, they were 
not intended to bait anyone.  I was simply explaining that I might well 
be much more conversant in German if I had been born 5 years earlier.  I 
thought the chemistry info would be a complement actually.  It is no 
joke that at one time nearly all the top chemists were German with 
little competition.  I'm not sure how this is "bait", but sorry.


> I have also one for you, because you asked for it:
>
> Amerikaner reifen bis 14, danach wachsen sie bloss noch.
> Q.E.D.  :]
>
>>> Saludos (an alle Vernünftigen, Rest sh. sig)
>
>> "Greetings to all sensible people"  Am I close?
>
> "Greetings (to all reasonable people, others see my sig)"
>
>> "Saludos" doesn't
>> show up in any German > English web sites I use.  Shows up as Spanish.
>
> I`m living in Paraguay (PY) now.
> and you should try to understand my sig.
>
> Anyhow, I will stop the discussion here, remember you asked for help not
> me! I`m not longer waste my time.

Yes, I did ask and I appreciate all help.  Sorry you didn't enjoy it more.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39074

Op dinsdag 12 mei 2015 06:53:06 UTC+2 schreef rickman:
> 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.
> 
> First I read the three bits that indicate which digit is being displayed 
> and when that is on a new digit the word exits returning the three bit 
> one-hot code (1, 2, 4) to indicate which bit.  For some reason I see 
> this routine returning the same digit on two successive calls which it 
> is supposed to not do.
> 
> Perhaps someone else can spot something I am missing...
> 
> : newdigit@ ( c1 -- c2 ) \ sync to new digit
>    begin digits@ 2dup = over 0= or key? not and while
>    drop delay repeat nip ;
> 
> c1 is the last digit code read and c2 should be a different one.  The 
> digits@ reads the port with the three bits, one-hot encoded.  The loop 
> exits when either the code changes but not if it goes to zero or a key 
> is pressed.  Here is the routine that calls this code.
> 
> : poll_loop ( -- ) \ read and display succesive digits from LED
>    LED_Init
>    0 begin
>      newdigit@ segments@ conv7segtodec digit. dup 4 =
>      if 13 emit cr then 	\ Mecrisp sends LF from CR word
>      key? until key drop ;
> 
> This word is just reading, repeatedly displaying the digits until it 
> gets the last one and starts a new line, nothing complex here.
> 
> The only way I can see to debug this problem is with a logic analyzer 
> which is going to be a PITA.  Or I can just code around it.  I know 
> which digit is returned from the 7 seg > decimal conversion, so if I get 
> the same one twice I can ignore it.  I just hate having bugs I don't 
> understand.  You never know if they might bite you later.
> 
> I am viewing this data on a raspberry Pi running e4thcom which is 
> connected to the target via a USB serial interface at 115200 bps.  The 
> error always appears to be an isolated double read of different digits, 
> so I don't suspect the data path is dropping characters which would 
> produce more random stuff.
> 
> It is late and I guess I'm getting tried.  I'll hit this again in the 
> AM.  Sometimes I think by writing down the problem, but nothing came to 
> me this time other than the work around.
> 
> -- 
> 
> Rick

Sorry for my intrusion, but my first responce was one of the ways you
gan drive a led digit.
To get rid of, what I call the shadowing, you first disable the display by 
writing an higher then digits there number to the digit post and then wait a while, 10 usec, and then write the segment port, and then the proper digit port.
This is just as you have seen as the delay problem of the transisters 
switching of. Due to that you would get an afther glow if there was no
delay.
So the digits lines change to a "off state" number and then the segments
change afther, for the common computers a long, 10 usec delay and then
the digit lines change again to the proper digit.
If you want to capture the info, just react on the inroper digit codes
with a wait for a proper code and then read the segments.
What you do now is fine the problem is just with the much higher speed 
of the processor reading the digit then the processor handling the display.

Succes, Tessa

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web