* I worry about the simple constructors here though. I believe that
causes things to be instantiated on the stack which is then blown
away. That would mean that I would need to rely on the heap with
the new keyword, but if I do that I will need to deallocate later.
* Digging into DS3232RTC, it looks like it has no deallocator, and I
kind of suspect the same for Rtc_Pcf8563. Either way, we will want
to ensure that we can delete those classes where we need to. I
would hate to introduce a memory leak somewhere on something so
small
* My current understanding of the WatchyRTC class is that it came about
due to the need to ship Watchys with new RTC chips. The class here is
designed to accomodate both chips
* This class is a good way of doing just that--a single spot that
hides the implementation details of both chips. The downside to this
approach in the moment is that we have a bunch of conditionals that
check if we have this or that chip, and if we ever need to support
yet another chip, we will have an even more complex WatchyRTC class
* I am going to refactor this to simplify it so that way we will not
have to worry about modifying this much if we need to support a new
chip, or if someone else wants to support a new chip
* Some pins otherwise are left as output
And their value is kept in deep sleep
This can cause power usage in deep sleep
* From my measurements 0.13mA
Or, 3mAh / day extra usage
* Hibernate should only be called before deep sleep
* Init should only be called once and notify the last init
* Set up init properly with 10ms reset and pulldown
* Use GxEDP2 1.4.0 library new busy callback
to trigger a lightsleep in the mean time
Saving 600ms of CPU time per update, (12mAs/minute)
That is -4mAh per day savings