To further Brian's comment: you have to keep in mind that the interrupt routine interrupts the mainline code, and not the other way around. So, you set a semaphore in your mainline code and your interrupt routine checks to see if that's set when it starts, or at least before it uses any variables you have protected by the semaphore. In my code, I just set a bit immediately before changing two critical variables, and reset it immediately afterward. If the interrupt routine finds the semaphore set, it returns and does nothing till next time. This prevents any question about whether the interrupt routine can update or even use the variables in question.
And not that it makes any difference, but I went down much the same path as Chris is going down with my non-TIC code. Maybe Chris will find something that I couldn't find. For me, there was always something just out of reach to prevent it from working properly. That "something" may just be that I was using a nav receiver instead of a timing receiver. I wound up with a very accurate counter; but it was still just a counter when all was said and done. Bob >________________________________ > From: Brian Lloyd <br...@lloyd.com> >To: Discussion of precise time and frequency measurement <time-nuts@febo.com> >Sent: Wednesday, April 9, 2014 3:17 PM >Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, >under $8 > > >On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray <hmur...@megapathdsl.net> wrote: > >> >> > But I think you over looked one point that makes this project easier: We >> > KNOW 100% for certain that the interrupts happen only once per second. >> So >> > the foreground code knows for certain it has exclusive access to shared >> > variables for a given period of time. There is zero chance of a problem >> in >> > the next .999 seconds after an interrupt. >> >> Actually, you don't know that. You know that's the way it's supposed to >> work, but there are all sorts of ways that things can (and do) screw up and >> making that sort of assumption can lead to problems that are very hard to >> debug. >> > >So create a semaphore that says who owns the variable. Or, better still, us >a message-passing executive. > >-- >Brian Lloyd, WB6RQN/J79BPL >706 Flightline Drive >Spring Branch, TX 78070 >br...@lloyd.com >+1.916.877.5067 > >_______________________________________________ >time-nuts mailing list -- time-nuts@febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. > > > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
