[time-nuts] First success with very simple, very low cost GPSDO, under $8

Chris Albertson albertson.chris at gmail.com
Wed Apr 9 15:32:59 EDT 2014


If my one interrupt per second assumption is wrong the GPS is badly
broken and nothing I can do will make the gpsdo work.  In a final
system I should try and detect violations of the assumption and go
into hold over mode.  That said I tried a test where I took the
interrupt line in my hand and rubbed it on a piece of metal and
triggered tens of thousands of random interrupts per second.   The
code works even in this case.

What happens in this code is that inside the interrupt handler the
ONLY thing it does is with interrupts disabled, it copies data to
global variables then exits.  The copy is in effect atomic.   You
don't see all that is happening because the Aruino environment handles
some of this.  It writes about 40 bytes then sets a semaphore-like bit
that says in effect "get it now", the foreground software  spin-locks
on this bit, gets the data and resets the bit.

I've been know to make gross errors in software design and forget
stuff but I should understand this.  I've done a bit of graduate level
work in computer science and worked a few years on operating system
internals.   In general you are correct but in this case the system is
so darn simple that all the code fits on one screen and I can read the
whole thing without scrolling,  Ok I have a 27" screen but still
there is not a lot going on here.

On Wed, Apr 9, 2014 at 11:34 AM, Hal Murray <hmurray at 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.
>
>
> It would be interesting to compare the size and complexity of simple code
> that doesn't have much error checking with defensive code that checks all
> sorts of things.  Sometimes a sanity check is a good way to explain a subtle
> point.
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



-- 

Chris Albertson
Redondo Beach, California


More information about the time-nuts mailing list