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