15

I have seen dozens of different real-time clock chips on the market, as well as a number of processors with a built-in separately-powered real-time clock module.

Nearly all of them not only store time as year-month-day-hours-minutes-seconds, but even the individual fields are stored in BCD rather than binary format.

Is there some underlying reason for this?

Are there any microprocessor applications that do anything more sophisticated than simply display a clock where the BCD format is more useful than binary, or where year-month-day-hour-minutes-seconds format would be more useful than a straight 47-bit count of oscillator state changes?

From what I can tell, it seems RTCC makers add a lot of extra circuitry to make their chips less useful; the only reason I can figure for RTCC modules in processors to behave that way is that the processor vendors use some pre-existing BCD implementation rather than producing their own.

Daniel Grillo
  • 7,659
  • 18
  • 51
  • 69
supercat
  • 45,939
  • 2
  • 84
  • 143
  • 2
    I do not know the answer but I wonder if there is any correlation to _BCD to 7-Segment Decoder's_? – Prof. Meow Meow Apr 05 '11 at 17:11
  • @Prof. Meow Meow: Nice name. The most practical method for storing numbers that are going to be displayed in hardware is BCD. There are systems that stored numbers to be displayed in other formats, but in many cases they simply used a ROM to map directly from the number to its visual representation (e.g. the arcade machine "Tank" used 6-bit score counters, and a 512 byte ROM to convert each score value to an 8x8 shape) but this was generally only workable if the maximum numerical value was fairly small. – supercat Apr 10 '11 at 16:58

6 Answers6

14

Do all RTCs use BCD encoding?

RTCs from Philips/NXP (both standalone and integrated into ARM7 or Cortex-M3 chips) do not use BCD encoding.

What's wrong with a BCD RTC?

When compared to flat counter the only operations which are more difficult with a split BCD clock are time difference calculations (adding seconds or calculating elapsed time). Time comparisons like: "is current time greater than the alarm time set by the user" are just as easy.

What's nice about BCD (and generally split-field) RTCs?

Splitting the fields is really nice when you care for the calendar date. Human calendars have funny things like months of different lengths and on top of that leap years. Try to do that in a single counter (you can get a bonus point for using almost no power). Oh and try supporting week days (quite useful in all kinds of devices meant for humans: from alarm clocks to heater controllers) with this.

The BCD approach has one additional feature: you get "every second" or "every ten seconds" interrupts for free, without having to do any calculations on times or dates.

For the record leap year calculation is a little off in the NXP RTCs since it only cares for the divisible by 4 rule and does not check the division by 100 and 400. If it kept the year counter in BCD this would be trivial and most probably done right.

Summary

  1. If you want a monotonic clock then use one. You can buy a PIC or AVR with the "RTC counter" (which is just an asynchronous counter with an autonomous 32kHz oscillator). Just keep in mind that simply displaying the date will be difficult. :)

  2. When you need to display the time and date and set alarms based on user input of times and dates then use an RTC. And remember that when the user changes the current time and date your RTC based interrupts may be inaccurate.

jpc
  • 5,302
  • 1
  • 24
  • 45
  • If a chip has the ability to ignore certain bits in its alarm function, I suppose interrupts every ten seconds, sixty seconds, ten minutes, or hour might be nicer than at power-of-two increments, but "alarm = GET_RTC_SECONDS(); alarm -= (alarm % 360)-360; SET_ALARM_SECONDS(alarm); is hardly difficult. – supercat Apr 06 '11 at 00:27
  • 1
    I've just started using the Gekko, which has a 24-bit RTC that's almost what I want except that it can't keep time when the processor's dead. I was also looking at an ST Micro ARM, which has a silly BCD RTC module which only supports interrupts on a one-second basis. If the ST chip would never be without power for more than three years, I could jinx the RTC prescalars to run at 32x speed, and then use software tricks to compensate, thus getting 1/32-sec time resolution on the wakeup events, but the times stored in the RTC would have no meaningful relation to calendar time and... – supercat Apr 06 '11 at 00:32
  • 1
    ...so the necessity of converting from the RTC's silly format to 1/32-second increments would be annoying, especially since such a conversion would be required on every sleep/wakeup cycle. I guess I'm curious how many people use RTCC readouts without converting into unified seconds. Maybe there are enough to make YMDHMS format worthwhile, but to my mind it's far more useful to reserve YMDHMS for *human* I/O, and use straight seconds (or whatever fraction thereof) for everything else. – supercat Apr 06 '11 at 00:37
  • @supercat Try that with several alarm lengths (every 10 seconds + every minute). Basically RTCs are *Real Time Clocks* and not monotonic clocks you should base your RTOS timer on. How do you cope with setting the correct time with your RTC based alarms? You may find your system sleeping for a day or a year if the user set the wrong date, you set an alarm and later the user corrects the date. – jpc Apr 06 '11 at 02:01
  • @jpc: I do it with several alarm lengths pretty nicely; it would be better if the PIC's timers had compare registers that could operate in async mode, but fortunately there are two 16-bit timers that operate off the same 16Hz clock. Timer 1 free-runs, and I keep track of the last value I observe. For Timer 3, I compute how many 16ths of a second I should sleep, and if the answer is 2-240, I load a value 0xFF10 to 0xFFFE and make sure Timer 1 hasn't moved. If only 1/16 second remains, I busy-wait, since PIC timers will take 65,537 counts to signal overflow if loaded with 0xFFFF. – supercat Apr 06 '11 at 15:14
  • @jpc: A few timing events like lockout timers, are stored in flash and are based on wall time (to prevent someone from trying a bunch of bogus combinations, power-cycling the machine or ESD-zapping it to induce a reset, trying a bunch more, etc.). Setting the wall time invalidates all such events (supervisor credentials are required to set wall time). – supercat Apr 06 '11 at 15:19
  • 1
    @jpc: My inclination would actually have been to never set the RTC-chip time, but instead keep "time since clock battery was installed", and store the difference between that and wall time. I used that approach in one generation of the product which used a separate PIC for keeping battery-backed time (the time on that PIC was read-only) and would use it on a chip with a straight counter. It seemed like a somewhat goofy idea, though, to have the machine's RTC store a meaninglessly-date-formatted value, though if I use the ST Micro chip I might just do that. – supercat Apr 06 '11 at 15:23
  • 1
    BTW, the STM32F100 series uses a 32-bit seconds RTC (not BCD), but the STM32F400 series regresses back to a BCD encoded RTC. Sigh. – Mark Lakata Nov 27 '12 at 21:43
  • The thing about months being different length is a good argument for split-field, but BCD doesn't have an advantage over binary for that. – Federico Russo Jan 15 '13 at 10:45
  • 1
    @FedericoRusso: Split field would make some sense, though it's more apt to be a hindrance than a help in most applications. The choice of BCD, though, seems downright bizarre as a choice to bundle with a CPU *that doesn't have any BCD support*. – supercat Sep 12 '16 at 17:00
3

When using clocks in the end you're more likely to be interested in minutes and tens of seconds(towards displaying them) than just the total of seconds, minutes and so on. In case you're not interested in separate digits chances are that you don't care about separate minutes or seconds values either, and that you might as well use a long binary counter like you suggested.
It's easier to convert from BCD to binary in software than the other way around. And since BCD counters don't require that much extra real estate over binary counters it makes sense to choose for BCD.

stevenvh
  • 145,145
  • 21
  • 455
  • 667
  • 2
    How often does an application want to do nothing with a date and time other than display it? It seems to me that it's far more common to want to do things like compute a time some distance in the future, or determine how much time has elapsed since some particular event, etc. Which is easier to compute: the date and time 45 seconds after 28-Feb-2000 23:59:52, or 5097582+45 (the latter value assuming midnight 01-Jan-2000 as the epoch)? How about determining whether 5 minutes have elapsed between 28-Feb-2000 23:59 and 01-Mar-2000 00:03 (vs 5097540.0 and 5184180.0) – supercat Apr 05 '11 at 17:44
  • 1
    An RTC with a 48-bit counter for 65,536ths of a second and a alarm-compare module which covered the bottom 24 bits or so would be extremely handy for low-power systems since it could be used as the basis for OS scheduling independent of processor waking and sleeping. If something's supposed to happen 4 seconds from now, the system could note the RTC value when the event should occur. If 2 seconds from now the processor finds itself with nothing to do, it could set the RTC alarm and go to sleep. When the event should occur, the system would wake up. – supercat Apr 05 '11 at 17:53
  • @supercat - for general purpose computers, let the OS keeping track of time and do "useful things" with that time info. The RTC is only consulted once to initialize the OS's time info, and then time is updated by interrupts. But for many simple embedded use, it's much more likely that – Toybuilder Apr 06 '11 at 18:31
  • ...it's much more likely that the time is not being kept by the program at all -- instead, anytime time is being used, just read/update the values on the RTC chip. – Toybuilder Apr 06 '11 at 18:32
  • @Toybuilder: In a battery-powered device, having the CPU service an interrupt hundreds or thousands of time per second when there's nothing useful to be done is a bad idea. It's much better to set a precise alarm to wake the CPU when needed. If an ARM chip had an RTC and a useful wakeup timer, both of which could run off the same 32KHz source, that'd be fine. I'd just fetch the RTC time once on startup, convert to seconds, and be done with it. None of the chips I've observed which can run the RTC off a separate battery from the CPU have a good wakeup facility, though. – supercat Apr 06 '11 at 19:53
  • @supercat - correct - the "tick" interrupt while the OS is running is different from the 32 kHz clock that feeds the RTC and the RTC's wakeup match register. There is a wide variety of BCD RTC chips - many of the ones I used to use had an alarm functionality -- just set the desired time to match to raise an interrupt which would alert the CPU. For designs that didn't need the alarm, however, you could also just only keep the RTC and the square-wave output for let the CPU keep track of ongoing time. – Toybuilder Apr 06 '11 at 20:23
  • 1
    @Toybuilder: The latter is exactly the approach I ended up using in the last few generations of electronic lock. My biggest annoyances were the lack of any pulse output choices between 32Khz and 16Hz (since I didn't trust a 1M pullup to operate reliably with a 32Khz open-collector output, the only reasonable choice was 16Hz), and the sloppiness of the PIC's timer circuitry. – supercat Apr 06 '11 at 20:43
  • @supercat: about adding 45 seconds. How about adding 1 hour, 2 minutes and 3 seconds? You have to calculate that that is 3723 seconds, add those to the binary counter and convert the binary sum back to hours, minutes, seconds. I don't see the advantage of this. – Federico Russo Jan 15 '13 at 10:50
  • 1
    @FedericoRusso: If one had a straight-binary time counter, one wouldn't have to convert back to hours, minutes, and seconds, except perhaps for human-readable display. One simply adds 3723 and that's it. When working with YMD-HMS date/time values, one needs separate code for incrementing and decrementing, daylight saving time is a nightmare for which chip makers seem to like to add broken support [like a command which subtracts one from the hour count except when it's zero, in which case it does nothing]. DST is a pain in binary too, but not quite as hideous. – supercat Jan 17 '13 at 02:44
3

I suspect several reasons:

Historical - they've been doing it this way for some time now. If you want your new part to replace some other part, then it has to more-or-less work the same. So you keep with the BCD.

Application - if someone is using an RTC from a small micro (something in the 8 bit range, like a low-end PIC), then dealing with a large number (such as your 47 bit counter) is a big pain in the neck. It's MUCH easier to deal with the BCD digits, as you don't have to work at breaking things up.

Not that hard - Doing the BCD counters isn't that hard, and in fact I think it isn't many more gates than doing them binary.

One can imagine a system where you get separate hour, minute, etc counters in binary instead of BCD (thus avoiding the 'breaking down the 47 bit number' issue), but it's not that much easier, and you're going to do some conversions when displaying the thing anyway.

Michael Kohne
  • 2,711
  • 16
  • 20
  • 1
    The 48-bit number would be a 32-bit number of seconds and a 16-bit fraction. Working with 32-bit numbers on an 8-bit micro isn't that bad. I can imagine that on something like a 6502 which could handle packed BCD nicely, the BCD format might save a few bytes in some cases, though the added complexity of handling carry between seconds-hours-minutes would offset any advantage. But surely the people who built an RTCC into ST micro's ARM chips weren't expecting someone to use a 6502 to process the data--not with a 32-bit ARM sitting right there! – supercat Apr 05 '11 at 18:20
  • 1
    @supercat - while not hard, doing the 32 bit work on the 8 bit micro is still a pain in the . And on something like a PIC (with VERY limited instruction & register & ram spaces) it's even more of a pain. As to the ARM chip - I'm going to bet that has more to do with historical precedent than anything else - everyone's used to doing it that way, so they keep doing it that way. – Michael Kohne Apr 05 '11 at 20:08
  • 1
    I wonder what fraction of the people who use RTCC peripherals don't convert dates/times into Unix-style seconds counters? – supercat Apr 05 '11 at 22:58
  • 1
    supercat: All of them? Of what use are Unix-style timestamps in a clock? OTOH your only use case is RTOS alarms which are better served with a normal timer or with a simple "second increment" interrupt from the RTC. – jpc Apr 05 '11 at 23:11
  • 1
    @jpc: What if you want to determine whether a given date is in daylight saving time, or determine whether a program that starts on a certain date/time and lasts a certain length will overlap another one? Such things are easy with straight seconds, but harder with YMDHMS. As for using a normal timer, what I use at present is a 1/16-sec tick from an RTC chip driving TMR1 and TMR3 on a PIC; that gives me a 1/16-second-accurate wakeup that works even when the main CPU clock is stopped, and I derive all my timing from that. – supercat Apr 06 '11 at 00:44
  • 1
    @supercat For daylight saving you are doomed since timezone databases are huge and change twice a year. Forget doing this on a really embedded system. The second operation you mention is easy with a second counter but then displaying the date is quite difficult. If it weren't you would not be complaining about the reverse operation. If you need to measure time periods -- use a timer and if you want dates -- use an RTC. What you did on your PIC is the best of both worlds (an RTC and a monotonic counter derived from the same reference). – jpc Apr 06 '11 at 02:08
  • Applications I've done didn't use Unix-style timestamps at all until we starting adding support for NTP. Although I'd have to say calculating time differences is easier using the Unix-style timestamps. – mjh2007 Apr 06 '11 at 02:21
  • @mjh2007 Unix timestamps (by design and implementation) completely ignore leap seconds which makes them a little problematic as an absolute frame of reference. But they are much better than ISO date strings based on local time without *proper* timezone markings. – jpc Apr 06 '11 at 02:32
  • 1
    @mjh2007: Maybe I'm odd, but the embedded system (electronic locks) I've been working on for a decade has used Unix-style timestamps from the start, even before I started using a separate RTC chip (I went to a separate RTC chip so that reboots wouldn't clobber the time). Adding daylight saving wasn't hard too bad--the rules are defined in terms of two single-byte parameters: "first_spring" and "last_fall". The next generation added a display which could actually show the date, and the one after that added an "I2C" RTC chip which couldn't use hardware I2C because it sent data LSB first. – supercat Apr 06 '11 at 14:48
  • @mjh2007: The generation after that started using a 16Hz signal from the RTC chip as a time base for most events, which allowed the CPU to go to sleep while events were pending (earlier ones used the primary crystal for all timekeeping except the real-time clock, which meant the CPU had to stay awake whenever the thing wasn't completely idle). Now I'm looking at choosing an ARM-based core for the next generation, and find it frustrating that haven't yet noticed any with a nice unified timer that's suitable for both event timing and wall time. – supercat Apr 06 '11 at 14:50
  • 1
    @jpc: What I'd like would be a long-running battery-backed timer that could provide wakeups with decent resolution (1/16 sec at absolute worst--preferably something like 1/256 or 1/4096 sec), and preferably something whose registers could be written without worrying about clock synchronization and such. Gekko has pretty much what I'm after, except that I'd like something that could keep long-term time with the CPU powered down, and I'm a little worried that synchronizing the timer-compare register with the 32Khz clock might sometimes cause trouble... – supercat Apr 06 '11 at 15:03
  • @jpc: ...in cases where I schedule a timer wakeup but get awakened by something else within 100us that requires me to schedule a different timer wakeup. I would guess that busy-waiting in such an event before re-updating the Gekko's timer-compare register shouldn't cause a problem, but I'm not sure. – supercat Apr 06 '11 at 15:06
1

I agree with Michael Kohne that there's a lot of historical momentum.

Early MCU's also had much less space for code and data (think 128 BYTES of RAM, for example). Since time information is often used for human-interfacing purposes, it made more sense to keep the data closest to the format used to display to/input from humans.

Some newer MCU's with more code and data space sometimes implement hardware real time counters -- these devices often keep binary counts of 32kHz ticks.

Toybuilder
  • 2,018
  • 1
  • 11
  • 12
  • 1
    I've coded for the Atari 2600 (128 bytes RAM), and I know the virtues of BCD. Things like scores are nearly always computed in BCD; level numbers sometimes are. Even on a 6502, though, I would expect that if I needed to determine whether two date/times were within five minutes of each other and determine whether daylight saving time was in effect, code to convert a 32-bit seconds counter into YMDHMS would be about as compact as code to do those computations without doing such conversions. As for newer CPUs, I've seen some with straight 32Khz counters that require the main CPU to be alive... – supercat Apr 05 '11 at 22:50
  • ...but the chips I've noticed which have a separately-powered RTCC use BCD YMDHMS. – supercat Apr 05 '11 at 22:51
  • The newer CPUs do this since it is cheaper and uses a little less current (especially important since the semiconductor process used is optimized for making CPUs and not RTCs). – jpc Apr 06 '11 at 14:47
  • 1
    @jpc: Why is it cheaper and lower-current to use BCD YMDHMS? I would think a 47-bit read-only counter with a comparator on the bottom 32 bits would be simpler than all the date-parsing stuff in an RTC chip. Unless there's some master film of a BCD date circuit which, because of some arcane long-forgotten magic, can be plopped into a design to achieve lower currents than are available with modern methods, I'm not clear why BCD would be cheaper or use less current? – supercat Apr 06 '11 at 15:43
  • I was thinking about @Toybuilders answer in which he stated that newer CPUs have only counters and not full-blown RPCs. – jpc Apr 06 '11 at 17:16
  • 1
    @jpc: The ones I've seen with counters, from what I've seen require that the main CPU be kept powered (which requires battery-backing the CPU and risking killing the battery if the CPU gets in a bad state while the main supply is off) and generally make it hard to keep continuous time across things like reboots or firmware updates. The only one's I've seen with separate battery-backup are YMDHMS-parsed BCD. – supercat Apr 06 '11 at 18:02
  • @supercat - there are processors with 32 kHz counters that continue running even when the CPU is halted, as long as minimum power was supplied to the appropriate power pin. – Toybuilder Apr 06 '11 at 18:27
  • @Toybuilder: A separate power pin from the main CPU power, or the main CPU power pin? And are the counters big enough to keep time for an extended period (e.g. a year) without the CPU? I've had units in the field whose clock-backup batteries died killed when the CPU got into a wonky state; having separate power for the timekeeper would seem a significant plus. – supercat Apr 06 '11 at 18:45
  • Correct - these devices have several types of power pins - I/O voltage, processing core, RTC, etc. The RTC power pin would be battery-backed, and would require very low power. At that point, it becomes a question of whether you had a big enough battery. As @jpc alluded, the semiconductor process for these high-integration MCU devices are favored for CPU performance, so even in their "off" state, they can end up being much more power hungry than dedicated external RTC chips which are optimized for low power consumption. – Toybuilder Apr 06 '11 at 20:33
  • 1
    @Toybuilder: I don't doubt that the process for making a dedicated RTC chip could yield a more power-efficient device than one for making a general-purpose CPU. On the other hand, I would think that on either type of chip, a straight counter would require no more current than a BCD YMDHMS one; I would also think that a 48 (or whatever) bit straight counter would require less current than the combination of a 24-bit straight counter and a BCD YMDHMS counter. – supercat Apr 06 '11 at 20:53
  • @supercat: The particulars are beyond me, but I believe the key fundamental difference is leakage current of the process. Dedicated RTC chips need on the order of 100's of nA while RTC blocks on a halted MCU need several uA's. That order-of-magnitude difference outweighs difference in circuit complexity. For a device where time only needs to be kept for a few weeks (a cell phone, for example) a relatively big but "leaky" battery works fine. But for a device that might be unpowered for 10+ years (access control equipment, for example) running on a long-term-stable coin battery? It matters! – Toybuilder Apr 06 '11 at 23:05
  • 1
    @Toybuilder: I can appreciate that there are advantages to standalone RTC chips. Who knows--maybe there's even one out there that's cheap and has a useful square-wave output that doesn't waste much current in a pullup resistor (e.g. a 256Hz output with a 1/65536sec low time would waste a small fraction of the current of a 16Hz output with a 1/32sec low time, despite offering a 256-fold improvement in resolution). – supercat Apr 06 '11 at 23:35
  • @supercat Maybe you should ask a question about building a ultra-low power oscillator + counter from discrete logic chips. Should be doable. – jpc Apr 07 '11 at 00:14
  • 1
    @jpc: Doing it with common discrete logic isn't likely to be terribly cost-effective or power-efficient, given the necessity of putting timer output data into physical pins. From a purely functional standpoint, a minimalist RTC would probably be three chips plus the oscillator. I'd guess a CD4517 (dual 64-bit shift register), a 74HC373 (latch), and a 74HC153 (2x4 mux). Such a system could shift out a 64-bit count every 64 cycles (provided a processor helped initialize it). Power dissipation would be crummy, though. – supercat Apr 07 '11 at 03:40
  • @jpc: A more interesting question might be why I don't see designs use quadrature-input grayscale counters? The resource cost is reasonable, and unlike a conventional ripple counter, the quadrature-input grayscale counter wouldn't mind inputs that transition through "funny" states, provided that whenever one input was fuzzy the other was solid. – supercat Apr 07 '11 at 03:46
  • [correction: graycode counters] – supercat Apr 07 '11 at 03:52
  • @supercat You are right that power efficiency may be a problem in such circuit. I searched several cheap counter but all use about 80μA at $25^\circ C$. I think I'll ask a question here. :) – jpc Apr 08 '11 at 19:40
  • @jpc: BTW, how do you like the concept of using a shift-register? That might be the minimum-circuitry way of doing it (especially if one used four phase shifting, so four transparent latches could hold three bits) though the improved usefulness of a parallel counter and comparator would IMHO be worth the extra circuitry. A graycode counter would seem the right approach, since it would avoid synchronization issues, though I'm unaware of any low-power counters using graycode. Not sure why, since graycode ripple counters should be efficient. – supercat Apr 08 '11 at 19:53
  • @supercat I have asked this [as a question](http://electronics.stackexchange.com/questions/12756/how-to-build-an-ultra-low-power-time-counter/12758#12758). The synchronization should be doable by just reading the counter value repeatedly until you get the same value twice. – jpc Apr 08 '11 at 20:59
  • @jpc: Synchronization can be an issue with wakeup events. If a counter clicks from 7F to 80, the bits may momentarily compare equal to any other value depending upon the order in which they switch. By contrast, if a graycode counter ticks from 40 to C0, or C0 to C1, there's no problem. There are other ways of avoiding false comparisons, but many such approaches have synchronization issues when changing the compare value. If one uses graycode counters, the only synchronization-ish thing one needs to do is guard the compare-match output... – supercat Apr 08 '11 at 22:11
  • @jpc: ... by holding it asynchronously in reset during a write, and passing it through a double synchronizer on the main CPU clock which will become transparent when the main clock is stopped (the double synchronizer should avoid metastability problems in the event that the counter advances just after the comparison register is written, thus creating a runt pulse on the compare output). – supercat Apr 08 '11 at 22:19
1

In case anyone is interested, I just looking at ST's 32F series and it seems that while the newer 32L series uses a BCD RTC, the 32F uses a straight 32-bit counter with configurable prescalar and provides a separate battery input for it (hooray!). I would have rather had a longer straight counter without a configurable prescalar (so I could get 1/256sec accuracy but keep time for years without having to worry about wrapping) but if I were to set the prescale for 1/64sec the timer could run two years without overflowing. Not ideal, but not too bad. A little unaesthetic that if someone powers the machine on after it's been off for too long (2.1+ years), the time/date would undetectably slip back by 2.1 years, but hardly a major problem (the counter has an overflow flag, but in many cases that wouldn't be terribly helpful. If the machine was on for two years prior to being powered off, and was powered on three months later, the timer would be expected to overflow; the question would be whether it had overflowed twice, and I don't know of any flag for that.

supercat
  • 45,939
  • 2
  • 84
  • 143
0

Maxim seems to be doing just what you want with DS1372U. It needs less than 1μA, costs 1.7 USD and is available(!) on DigiKey and Mouser. The only problem is that it does not seem to offer alarms with more than 1 second precision and the lowest output clock rate is $\approx$4kHz.

jpc
  • 5,302
  • 1
  • 24
  • 45
  • 1
    It's a little pricey, and it doesn't allow any way to read out increments smaller than a second. A 4096Hz output would be nice, though it would be far nicer if it were low for 1/65536 of a second and high for 15/65536. Open-collector outputs should be low as little as possible. – supercat Apr 08 '11 at 22:24