Real Time Clock

Introduction

Why RTC? Well, because it’s very useful. Especially now that I have designs for a real(ish) operating system, knowing what time it is. This will become even more important once I’m around to make a file system.

How?

The point, the main point about the RTC is power consumption. It should run from a battery and ideally should run from said battery for years. This means CMOS. I know, I pooh-poohed CMOS for its speed and inherent shoot-through, but in this case this doesn’t matter: this is a low-speed circuit, not switching all that often. What we would have is a 32.768kHz crystal, followed by a 15-bit counter/divider. This generates us a 1Hz base clock. This clock is fed into a 32-bit counter, which in turn would could UNIX-style EPOCs. The value of the counter can be queried using two I/O locations (16-bits each). Because the value is stable for a second, I will not be bothered by double-buffering and synchronous capturing of counter values. SW simply will need to double-read both values and only accept them if both readings return the same value. Crude, but functional.

Periodic interrupts can be generated from one of the bits of the 15-bit counter (we need to convert it to a pulse that can drive a sticky RS-flop), something on the order of 64 or 128Hz. This can be used for preemptive multitasking and other purposes.

The battery is going to be a 3.6V something-or-another (3.3V is not that standard) and as simple a charging circuit as possible from 5V.

The charging circuit, the I/O gates, the interrupt logic, including the interrupt acknowledge logic can be powered from regular 3.3V and implemented using my bipolar gates. Only the counters and the oscillator need to be low power affairs.

To further limit power consumption, one can contemplate increasing the Rds of the FETs (using series resistors). This slows the circuit further down of course, but does that really matter?