[time-nuts] time-nuts Digest, Vol 189, Issue 32

[Tim S]

I think the point was missed about "losing some of the low power
benefits".  I also got an off-list reply that I'll address here keeping
the sender private.

I understand that "everything can be fixed with software", but as a
hardware engineer, I prefer to save my power at the hardware level for true
low-power solutions.  There is a huge difference in power draw between
updating a few registers for a counter, versus powering up an external IO
interface, toggling an interrupt to wake up an entire power domain,
having a microprocessor come out of sleep, reading the UNIX time register
over the high energy IO bus, reading the standard time registers over the
high energy IO bus, doing some math for a few hundred cycles, the writing
out the corrected UNIX values over the high energy IO bus, then putting the
microprocessor to sleep.  It's probably several orders of magnitude more
energy to fix it with software, then just having a better hardware design.

I understand from reading the datasheet that it's not a "true" 32-bit UNIX
time stamp in that it is not signed, and I'm aware that there are user
registers provided in the part that can be used to expand the UNIX time
counter - but that again requires an external part to talk over an IO bus
that must be powered (I2C needs pull-ups to idle the bus - moving current
on a trace uses a lot of power), and software time to "fix" a shortcoming
(my opinion) that was designed into a brand new part that probably had the
space.  A counter running at 1Hz doesn't need to be fast, even if it was
constrained to settling before a latch edge on a half cycle - 500mSec is an
eternity in silicon time - so even using a simple low-gate-count ripple
counter to fill 48 or 64-bits would have been better IMHO.

Software has a power cost, and in what is advertised as an ultra-low power
part, it seems to be a deficiency that the data is will require external
conversion/manipulation so soon to a well known epoch issue.  Spade =
spade, even 40-bits would have been better than 32.

All my opinion BTW, to each their own.

-Tim

Message: 6
> Date: Sun, 19 Apr 2020 18:15:26 -0700
> From: Hal Murray <hmurray at megapathdsl.net>
> Subject: Re: [time-nuts] A look inside the DS3231
>
> [TRUNCATED]
>
> Not a problem.  It's 2 lines of code.
>
> It's the same problem as the GPS week number roll over (WNRO).  If the
> reading
> is less than the build time of the software, add in the overflow bit.
>
> That's good for 136 years.  I wonder if any gear using those chips will
> still
> be running 100 years from now.
>
> --
> These are my opinions.  I hate spam.
>
>