Andy, may I respond piece by piece, to your interesting, and thought provoking mail?
Most ARMs microcontrollers have the RTC on the chip. This real time clock (seconds counter ONLY)on the ARM is unlike the "standalone" realtime clocks from Maxim-ic / Dallas eg. DS1307/DS3231
Agreed.
The clock on the ARM only provides an accurate seconds counter
Not strictly true. The RTC has a 20 bit prescaler, so the clock can be divided to produce milli-seconds, or other useful things.
But I guess what you mean is it's a dumb counter, and not a clock/calendar, which I understand may be inferior for your needs.
and some battery protected RAM.
Yes! That's another part of what I want it for.
By connecting a watch crystal (32.768 KHZ) for the RTC and a backup battery source (3.0 V lithium battery) then you could have a battery backup RTC on the ARM for the seconds counter
or whatever unit of time I choose
and the battery protected RAM which holds the other time/date/alarm variables.
The code needs to know what the zero count means, and time and date would be calculated.
I would store other stuff, but not those.
The RTC alarm is stored in other RTC registers, so it doesn't take up any NV RAM.
Also, you need to have access to the clock output so you can calibrate the clock with expensive caliabration equipment.
Why would I have to calculate the correction that way? Are you talking about calibrating in manufacture?
I'd probably write a little program to coordinate with my host and calculate a correction. My Mac keeps a reasonably accurate clock using nntp.
How does the Dallas DS1307 do it? I looked at the datasheet, but I couldn't find mention of how to go about correcting it's clock.
The DS3231 is impressive, as it has a temperature compensated crystal oscillator internally which is calibrated during manufacture. The only price I found for it (digikey) was $8.40. I am very (unreasonably?) cost conscious, and that is more than the STM32F103RBT. I would like that level of accuracy, but I would like a cheaper solution. A 32KHz crystal and a couple of capacitors are under $0.80.
This has to be done per ARM microcontroller or the seconds will be way off in a years time.
Agreed.
Without using a host PC or a network time service, how else would I do it?
As I said, I couldn't see how the Dallas DS1307 addressed this issue, and I'd like to understand if there is a better way.
It is pretty clear how the DS3231 does it, but if the Digikey price is representative, I wouldn't want it built onto a board.
Believe me, I be there, done that.
Having this basic hardware is necessary but you need a lot of support software to do the following:
1. Compute from the seconds counter the minutes, hours, days, day of week, date of month, leap years and years.
Agreed.
My plan is to convert the count (knowing what zero means) to something like the UNIX epoch, and use an Open Source implementation of time(), or equivalent.
2. Compute the time when the ARM has been powered down or shutdown and then re-calculate all of the above time/date variables!
Not necessary, calculate time & date on demand. I believe all UNIX systems work this way, and I had thought Windows NT derived system do too. I am pretty sure VMS did.
3. Integrate the alarm interrupts with the ARM microcontroller.
I'm sorry I don't understand.
AFAIK, the alarm interrupts are already integrated, as is the timed wake-up mechanism. What am I missing?
This is an issue for the external RTC though. In order to accept interrupts from its alarm, it would consume another pin, as I2C devices are slave, and so it would need to be connected to three I/O pins.
I have only skimmed the datasheet, but the DS1307 doesn't seem to have a wake-up alarm, so it seems to be inferior to the on-board RTC.
4. Integrate the 1 second RTC interrupt with the Arm microcontroller. Note: You could eliminate #4 and just poll the seconds counter.
Yes, there is no need for 1 second RTC interrupts, only alarm. My plan is to get the time when I want it.
I can see why the Maple Leaf Blowers decided to not include the RTC in the Maple.
They said in one thread, board space.
Having this clock would mess up their Maple/Arduino compatible timing, functions, interrupts and commands.
Disagree. I don't currently believe it has any impact. It is a potential source of interrupts, but the user has to accept that interrupts and the clock can interact on the Arduino. The RTC could be used when waking from a power down. At that point, one might choose to re-initialise the Arduino library time function internal value from the RTC. But it isn't necessary.
It would add 4 extra connections or I/O pins to the Maple.
3 not 4. VBAT is still VBAT, and is not an I/O pin.
The other three pins are not 5V tolerant, and are limited (ST.com document 13587.pdf):
PC13, PC14 and PC15 are supplied through the power switch. Since the switch only sinks a limited amount of current
(3mA), the use of GPIOs PC13 to PC15 in output mode is limited: the speed should not eload of 30 pF and these IOs must not be used as a current source (e.g. to drive an LED).
It is not worth it - there are better and accurate "off the shelf" products that can be acquired.
I agree with you that there are more accurate off-the-shelf products.
But, I disagree on the 'not worth it".
a. If the Digikey price is representative, they cost more than the MCU, or appear to have the same accuracy problems as the on-board RTC (though I am very happy to be corrected, 'cos I don't get how the DS1307 can be otherwise).
b. The concerns about software complexity seem to be solved in Open Source software, but the devil is in the detail, so I won't claim this is irrelevant.
c. There is no need for interaction with the Arduino-library timing mechanisms unless someone wants it.
d. There is no need for for interrupt interaction unless the user wants an alarm, in which case, they are probably swapping one source of interrupts for another, so overall, no worse off.
e. When failing power is detected, there is no need to go to an external device to write the NV RAM values. I feel that has got to be quicker and easier than going to an I2C device which may be in the middle of a transaction. If the external timer is on it's own I2C bus to avoid that problem, then it has consumed two pins and an I2C interface for the gain of 3 low-current, non 5V tolerant GPIOs. I would prefer the spare I2C.
f. It is already in the chip.
We may end up agreeing to differ, though how the DS1307 can be calibrated in a better way than the on-board RTC might make me rethink, and I don't understand your point 3. about integrating interrupts with the ARM.
Thanks for the thought provoking post. High-quality stuff!
