1

How does one set the DS3231 with microsecond precision? I2C doesn't really seem to lend itself to precision.

My guess is that the RST pin is used, but I can't seem to decipher spec PDF's description of it. And it too seems like it might imprecise if it has 250ms response time as listed on the spec

I know I must be missing something that's right in front of me

NewEndian
  • 111
  • 2
  • DS3231 seems to only have 1 second smallest resolution over I2C and through the INTn output, 1/8192 second smallest resolution through the SQW output, and 1/32768 second resolution through the 32kHz output. I can't see anything about microsecond precision -- one note is that "μP reset" in the IC description refers to a microprocessor reset, not microsecond precision. – Stephen B Jul 01 '23 at 03:41
  • See [this related question](https://stackoverflow.com/questions/44644383/how-to-get-millisecond-resolution-from-ds3231-rtc) and [general answers about microsecond resolution through external real time clocks](https://electronics.stackexchange.com/questions/60676/is-there-any-real-time-clock-rtc-which-provides-time-resolution-in-microsecond) – Stephen B Jul 01 '23 at 03:41
  • Even if you could set it that accurately, it will drift a microsecond or two every second with 1 or 2 ppm accuracy, cumulatively. Internal capture-compare timers in your MCU are typically well suited for sub-microsecond timing resolution but to synchronize with a real time timing source you might have to use something like PTP. – Spehro Pefhany Jul 01 '23 at 08:16

2 Answers2

1

You're right, this IC is not designed for sub-second time keeping. You have no control over any of the sub-second counters (either for reading or writing). Correction: I have been informed in the comments that writing the seconds register will clear the sub-second counter.

The 32kHz internal clock is used for all timing functions, with a resolution of at best \$\frac{1}{32kHz}\approx 30\mu s\$, and since the beginning of each cycle is utterly out of your control, that's the best precision (30μs) you could hope to achieve.

Even if you knew the latency between the successful receipt of an I2C write command and the actual, physical register write, and you timed the I2C command accordingly, you still wouldn't know the exact current place within a single 30μs cycle.

The RST pin won't help, for the above reason, and because (to the best of my knowledge) it doesn't actually clear any time counter registers.

I suppose the INT pin could be useful in this respect, because it does alert you to the rolling over of the seconds register, which will have some coherent relationship with the 32kHz clock. However, the datasheet doesn't go into enough detail, and you'd have to do a lot of experimentation to find the required "formula". The circuitry and software required to coincide your register updates over I2C with an INT event would be hellish.

Even if you did manage to do all that, the fact that you have no access to the IC's internal sub-second counters means that you can't even read back the time with sub-second precision, and you would have to refer to INT as an indicator. You'd need an additional external 1MHz counter, phase locked somehow to the IC's INT signal to ascertain the elapsed number of microseconds since INT.

It's not just the I2C bus that makes microsecond, or even only millisecond precision impractical; pretty much everything about this IC makes it unsuitable.

Simon Fitch
  • 27,759
  • 2
  • 16
  • 87
  • 1
    The user does have control over the sub-second counters - they get zeroed on seconds write. – Justme Jul 01 '23 at 10:07
1

To start, the chip uses 32768 Hz clock for any timekeeping, so using it normally as you would through the I2C interface, you cannot know the phase of 32768 Hz clock so even if you restart timekeeping from zero seconds, the time is ticking inside the RTC in 30.5 microsecond periods. So when you write the time, it gets written only in 30.5 uS precision and who knows how much latency there is from internal synchronization.

As per datasheet, the chip resets the timekeeping divider chain on writing data to the seconds register, and on I2C bus it means the transfer of ACK bit from the DS3231.

This means that the 1 HZ square wave output will transition 500ms afterwards from the write.

And I2C bus can be used as slowly and as accurately as you want, nothing prevents from bit-banging the bus manually and reading some sort of microseconds or better timestamp from an MCU timer during the transfer of the ACK bit when writing the seconds register.

And nothing prevents from verifying the RTC 1 Hz output signal as the 1 Hz counter is reset by writing the seconds.

However, even if the chip itself has up to 400 kHz I2C bus, and even chip registers would work asynchronously regarding the I2C bus, the chip timebase is still the 32768 Hz crystal, meaning, whatever you do to the chip to read or write the registers or examining the chip output pins, the chip can't keep track of time at any better resolution than 32768 Hz, or about 30.5 microseconds.

Which means, whenever you write the seconds register, it will restart the 1 Hz counter, but you might not know the phase of 32768 Hz clock so it might take 0 to 30.5 microseconds to the next clock tick. Of course this could be again examined and timestamped through the 32kHz output pin.

Justme
  • 127,425
  • 3
  • 97
  • 261