I assume you are doing this for fun.  That means you get to do whatever you
think will be fun.

The DS3231 is pretty crappy by time nuts standards.  If you can also measure
the temperature, you should be able to make neat graphs.  If you watch it as
the temperature ramps up slowly, you should see a sawtooth pattern.  The
crystal will track the normal freq/temp curve until the temperature changes
enough for the correction logic to add in another step.

Have you looked at tvb's PICPET and friends?
http://www.leapsecond.com/pic/picpet.htm
http://www.leapsecond.com/pic/picdiv.htm

I think he has one that turns 32KHz into PPS.  You could feed that PPS into a
picPET running off your Thunderbolt.

If you have a spare counter, you can run that in frequency mode and feed that
to a PC.

Where are you going to collect the data?

The PPS input on a PC may be be useful.

pete@heypete.com said:

...

Use one of the counters to divide things down to a rate that is easier to
handle.

--
These are my opinions.  I hate spam.

pete@heypete.com said:

Huh?

Instruction cycle time is 62.5nS for almost all instructions at that clock.
That’s a pretty long ISR by my standards.

1: Reserve a couple of registers for handling data inside ISRs, avoiding push and pop.
2: Reserve a register for holding SREG during the ISR.

ISR:  in STEMP,SREG
At this point you can fearlessly trash SREG and ITEMP and ITEMP2
Do Stuff using ITEMP and ITEMP2.
Do as little as practical in the ISR, letting the non-isr code do the heavy lifting.
Out SREG,STEMP
RETI

Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 bit operations.
Keep data you need FAST in registers in the low page, rather than in RAM.

On 6/27/2016 1:51 PM, Hal Murray wrote:

Maybe, but simply by adjusting mine by measuring the 32 kHz output with
an accurate counter I can get them to keep to within about one second a
month.  I have two incorporated in homebrew HF transceivers that I built
and find that their performance is actually pretty impressive, /for what
they are/.  Being able to set time zones and UTC offset from the radio's
front panel is also handy.  After all they only claim to be a fairly
accurate clock.  I doubt that any of the fancy schemes being proposed
for measurement will improve the basic accuracy much.

Dan

On Mon, Jun 27, 2016 at 10:51 PM, Hal Murray hmurray@megapathdsl.net wrote:

Indeed, this is strictly for fun. I have strange values for "fun".

Oh, I know the DS3231 isn't terribly great. The datasheet calling it
an "Extremely Accurate...RTC/TCXO/Crystal" makes me laugh, as it's
tooting its own horn.

For more precise stuff timing, I have a Thunderbolt and other goodies.
(Speaking of which, I really need to figure out how to use the
Thunderbolt as an external clock source for my Arduinos.)

Still, the DS3231 is a reasonably accurate RTC, inexpensively priced,
is easy to interface with my Raspberry Pis, Arduinos, etc., and
provides a handy 32kHz output. It also has an internal temperature
sensor that it checks every 64 seconds, the output of which is also
accessible. Your idea of plotting the temperature vs. frequency is a
good one; I'll add it to the project list.

I have seen those, but I have little experience with PICs and the Wife
Acceptance Factor of buying more stuff for a one-off measurement is
low.

Alas, I'm ashamed to say I have no frequency counter at all.

My plan was to have the ATmega328 simply output the data over a serial
connection so I can put it in a spreadsheet or something.

Indeed. I normally use it for NTP.

Thanks for the advice!

Cheers!
-Pete

--
Pete Stephenson

On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
david.vanhorn@backcountryaccess.com wrote:

According to the "How long does it take to execute an ISR?" part of
http://www.gammon.com.au/interrupts, it takes 82 cycles total to
service an external interrupt (i.e. one triggered by an interrupt
pin), including the time needed to enter the ISR and to leave it after
it's done whatever you needed it to do. At 62.5nS for each clock
cycle, that's 5.125uS just to process the interrupt. That doesn't
include the time needed to execute whatever code you want it to do.

Thanks! I think that may be a bit beyond my ken for the time being,
but I'll definitely keep it in mind for when I know more.

Cheers!
-Pete

--
Pete Stephenson

Hi

That all assumes you have turned interrupts off for some reason. Common
reasons  could be that you are in another interrupt service routine or that
you are executing interrupt related code.

Bob

What I saw in their interrupt routine was a "full boat" implementation, pretty typical for C code, saving registers without regard for what happens in the ISR, but nothing about the interrupts being turned off.
If you mean not having re-enabled ints during the ISR, then yes, and that is how I would urge anyone to write an ISR.  The reason that you would re-enable ints during an ISR is that your ISR takes too long.
Making the ISR take even longer isn't really a solution.  Write faster ISRs.

The key is to do absolutely as little housekeeping as needed, and have the ISR do as little as possible.

I have had cases where I didn't even preserve SREG because what I was doing in the ISR didn't alter SREG.

Don't blame the hardware for poor implementation of software.

There really is no actual minimum code in an ISR.  In one case, I had a useful ISR that had actually no code in it!.  A very special case, but they happen.
What I showed is my typical intro and outro code for probably 90% of what I write.  I avoid pushing and popping because it wastes time.  Copying SREG into a dedicated register is faster. Using dedicated ISR registers is faster than pushing and popping to free up registers.

All this pushing and popping causes deep stack usage, which isn't even an option on some processors.  When your stack collides with your data, you're toast. It is to your significant advantage to minimize stack usage.

I will typically put a stack guard below where I expect the stack to live, and monitor that in the "sanity check" routine for any changes.  The sanity check routine looks at this and other things that I know should never change, and if they are not the correct values, then the watchdog won't be reset.  The sanity check routine is also the only place that the watchdog gets reset.    WDRs scattered through the code are symptomatic of poorly written code.

I don’t think you can do it for an Arduino without hardware changes. The CLKI pin is shared with XTAL1. But you can clock almost any AVR from an external clock source as long as the Vcc vs frequency “safe operating area” is respected (see the datasheet for your particular device). Note that if you fuse the device for an external clock source of any kind, that source must be present during (non-HV) programming as well as operation.

I use a DC blocking cap and self-biased inverter nowadays as an input conditioner for external clock inputs. It allows me to accept sine as well as square inputs if necessary. My principle use for this is my Crazy Clock calibrator, which I clock from one of my GPSDOs. It’s not 100% reliable, and I’m not sure why. Every once in a while, the AVR will lock up, even with the watchdog turned on. The square wave on CLKI looks perfect. I can only guess that there’s a glitch every once in a while that screws something up, but I haven’t figured it out yet.

Hi David:

I built a number of clocks based on PIC uC and using interrupts. The idea is to use the output from a frequency standard
as the heart beat of the clock.
Depending on what the PIC was doing when interrupted the delay can different by one cycle and a simple test corrects
that.  Clock settable to 1ms and keeps perfect time.
http://www.prc68.com/I/PRC68COM.shtml#07092006
I wrote this directly using the Microchip assembler.  I'm not a fan of C.

My first uC was the SWTP kit that came with no software.  I learned to write directly in hex machine language.  The
problem with that is every time code is changed inside a loop the target address needs to be recomputed.  Later I got a
copy of the Motorola assembler and editor which was a big help.
http://www.prc68.com/I/comp.shtml#SWTP

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------