I see there are methods already discussed here on how to use an Arduino-type microcontroller to count an input and output some division of that clock. Say taking a 32kHz clock and cutting it down to 1 Hz in software. I am building a wrist watch circuit from scratch, sort of reinventing the wheel for the sake of my own interest and fun, and I have put a lot of effort into getting a really good clock signal from a 32kHz temperature compensated MEMS device. I am concerned that by simply inputting that clean clock signal and counting it with the onboard chipset, and outputting a division, that that division will be "decoupled" from my good clock and will instead be based on the sloppy resonator on the Arduino. my understanding is that any microcontroller operations must be synchronous with its internal resonator so it would seem that there is no way for it to perform any function on a better clock signal that won't degrade the timing. Maybe I could explain what I mean better, but basically I am assuming that any timing critical output will only ever be as good as the accuracy of the Arduino resonator, so any better timed input will be lost in translation. Am I resigned to using logic chips or can I work around this without a ton of effort?
you are going to sample a 32KHz clock at ~16Mhz... so missing a couple cycles on the fastest clock is probably within acceptable bounds for your slower clock isn't it ?
what accuracy do you need?
Not really; as long as the internal clock of the microcontroller is way higher than what happens in the outside world, it's not much of a concern.
For counting your 32kHz pulses you may find the timer/counters of your microcontroller of choice of use. They're called timer/counters for a reason. They allow to be triggered from an outside pulse/clock source.
The annoying answer I have is that I want to be as accurate as I can within my abilities. The clock chip I am using has +/- 3ppm accuracy, which I think is much better than the Arduino resonator
the Arduino resonator seems to be about "0.5% accurate" according to various resonator datasheets, at 16Mhz that's about 12.5ppm
So while you are totally right about there being more samples per second, those samples are still and order of magnitude less accurate than my incoming clock. So I think my original concern might be true? I just don't know enough about how microprocessors are synchronized to be confident that they won't make an attempt at an accurate clock input irrelevant.
Are these counters separate passive components on the chip? I would think that if they are at all based on the chip clock then I would have a problem, if they are simply acting like a programmable logic chip then prefect!
Connect the external 32kHz signal (I assume it's a logic level!) to an interrupt capable input pin, and set up an ISR to run a software counter. That counter will be completely independent from the CPU clock.
Not sure what you mean, but ultimately nearly everything that happens in a microcontroller depends on the main clock.
Please explain the problem, because I don't see it.
You've got an external pulse source at ~32kHz. You have a microcontroller running at, say, 16MHz. That's about 500 clock ticks of your uC for every external pulse. What problem do you foresee with this?
The counting itself won't be independent from the clock - or in fact the handling of the ISR in the first place. The closest you can come to a 'clean' input would be to use a counter and trigger an ISR on a compare match that is appropriately chosen. With a 16 bit timer it would be possible to trigger a compare match precisely every second from a 32.xxxkHz source.
I think you do not understand the simplicity of what the OP is asking for. It is not synchronous edges or anything like that. It's just to maintain time to 1/32768 of a second. Over long time periods like day, years, etc.
if I remember correctly, using an external clock input for a timer is OK up to 6.4 MHz so at 32kHz you are far from pushing this to the limits. You would be using the timer's registers to set when to trigger an interrupt and you can decide what to do in the ISR.
unfortunately not all timers have a clock pin readily available (I've tried that a long time ago on a Mega with Timer1, not sure which pin I needed to use)
Using a simple interrupt to perform the count could even be enough as your arduino can execute roughly 500 instructions before your next pulse comes in.
There will always be some sort of lag between your clock and the division of that clock since you need to process the input and that lag depends on the clock of the MCU for sure. at 16Mhz that means you'll be a few micro-second late. (if it takes 100 cycles to process the input and issue the output then we are talking ~6.25µs for a 16Mhz arduino. Of course there are faster arduinos)
My control systems knowledge is limited, but I am thinking of a systematic error rather than a sampling rate error. I see your point about there being a high enough sampling rate to capture my input signal, the issue I am foreseeing is that while my clock is slower, it has a more consistent scaling over long time periods. The 16 MHz clock is fast, but there is an "acceleration" to that clock, its speed changes by an order of magnitude greater amount over long time periods compared to my clock. So while it wouldn't miss any input pulses, its processing and output of the divided pulses would be coupled to the 16 MHz clock's drift. The Arduino clock is also not temperature compensated so there is a 13ppm timing drift and a temperature drift error that is introduced to my output which the input did not have.
I am by no means trying to argue, just presenting my assumptions, so please set me straight if needed.
But it will only be instantaneous lag, not cumulative lag.
Yes so the output signal is a bit shifted in time
Perhaps a full disclosure of the actual application would help clarify things. What is the counter actually used for?
So assume it takes 100 cycles to handle whatever you want to do. Indeed, because of the lack of precision of the arduino's resonator, those 100 cycles which should take a nominal 6,25µs to execute will be done a bit faster or slower. (ppm means parts per million)
Now plug in the drift you are talking about above and see if it does anything meaningful to the 6,25µs duration... (total error on that duration = 6,25 x 13 x 10-6 = 0,08125 nano second)
This is not cumulative, you'll get some variation for each tick. is that variation significant compared to the precision you require?
Sure, I am currently still in the planning and theory stage, but the outline is that I would like to assemble a circuit which can provide a 1 Hz, 12.5% duty cycle signal to a tiny coil as accurately as possible. This coil will actuate an escapement and keep accurate time for a wrist watch. My current design uses one SiT1566 TCXO, fed into one SN74LV8154N to divide it's signal down to 1 Hz @ 50% DC. Then this output, and the 4 Hz, and 2 Hz output are logically ANDed together with a SN74LVC2G08 to give 1 Hz 12.5% DC.
I see, with this argument then why bother at all with a clock input, why not just use the internal oscillator and have the Arduino output a clock pulse using something like "millis"? If you are saying that there is really no way to decouple the Arduino operations from the sloppier Arduino resonator then is there a point in trying to start with a clean input? I guess I am trying to get to the heart of the issue, and reduce the total chip number/board size of the project. My purpose is to simply get the most accurate 1 Hz 12.5% DC output In as small a package as I can.
Right now I have two IC's, one TCXO, and other power/ signal management components. I am not sure that a microcontroller really cuts down on my size constraint much, so this all may be a moot point.
Why not use a binary counter like a 74HC4040 or similar? It's certainly available in SMD. The "actuating the escapement" part might be easier with an MCU, if there is special pulse timing involved...
As far as the MCU goes, I don't see why you couldn't use it, and just take clock pulses from an interrupt pin as I mentioned. I had a similar setup running already, it took 1Hz pulses from a DS3231 and ran an ISR that performed time keeping. I was planning to try 32kHz from the DS3231 also, but found that I didn't need it so I didn't bother. But it would have been a simple change to some constants using the same code.
The sloppy resonator impacts timing over the long term. ie if you try to create a wall clock then at 13ppm, over a day you will have a potential error of 24 x 3600 x 3 x 10-6 = 1,12 seconds or over a month more than 30 seconds.
But over 32µs of course this has way less impact (in terms of absolute timing it's small) esp. as this is not cumulative since you react to your clean input. Your use case dictate though weather this is too much or not
Not enough division stages, I would only be able to get down to 8 Hz with a 12 bit counters, and then I'd need another IC with more flip flops to divide further. The SN74LV8154N allows me to do the full division in one chip. Unless I am missing something?
Yeah the month long time frame is what I care more about. I want to start with the highest accuracy so that the watch can maintain better long term time.
You can cascade 4040's. Or use a 4060 (I haven't checked to see whether 2^15 is brought out though...)
But if your escapement drive pulses are at all complex, the MCU is more integrated than the pile of IC's you might need to do that part.
By the way, is power consumption an issue?
This was the original plan, but since I found SN74LV8154N which does everything in one package I switched to that. overall square millimeters of board space is the most important factor, second most important is timing accuracy. The pulses are not at all critical, I could happily use the full 50% DC from the clock, I only need a short impulse though so the reduction in Dc is to save on power.