Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39087
| 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> |
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
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