Below is a list of the most recent code changes:
- added PWRON setup option to select app to run when the clock starts up;
- compilations options (add/remove features) moved to file "UserConf.h". That is:
- Instead of editing WiseClockVer.h to select WiseClock 3 or 4, edit "UserConf.h".
- Instead of editing HT1632.h to select the number of displays, edit "UserConf.h".
- on dual display, Countdown includes days as well, in the format DD:HH:MM:SS;
- Countdown shows the correct amount of time left even if power was down for a while (this is done by saving the end time in eeprom); for this feature, the PWRON must be set to "CNTDWN";
- similar to Countdown, app Score has been extended to "remember" the numbers even after the power was out for a while; in either case, the respective app must be selected in PWRON;
- ability to display quotes randomly, if the user selects "RND" in app Quote;
- on dual display, Stopwatch is now using regular-size font (still using tiny font on single display);
- Stopwatch has a new mode, "Conventional", in addition to the previous one (called "Rattrapante"); the conventional mode accumulates the time passed between consecutive presses of the start/stop button, as a mechanical chronometer would do; "rattrapante" mode shows the amount of time passed from the moment it was first started, regardless of how many times the chronometer was stopped;
- on dual display, with "Font+" selected, Score and Stopwatch are using big font and no longer show the current time on the bottom line (they show as before with "Font-" selected);
One of the challenges in writing complex code for embedded systems is the compromise between following an Object Oriented approach and trying to minimize the amount of RAM at runtime. Let me elaborate a bit. Each C++ object, once created (at runtime), used or not, takes some RAM, storing data members and the vtable (when using virtual functions). Wise Clock software is trying to follow an OO design. Each App class is derived from an abstract base class. The base class defines 2 pure virtual functions (init and run), which must be implemented by every App class.
At runtime, each app is created as a static object. Therefore, if 12 apps are declared (through the use of ifdefs in UserConf.h), 12 objects will be created in RAM, each one storing its own data and its own vtable. That's a pretty big price to pay in the world of embedded systems with little RAM space (just a guess, based on my very limited experience).
A non OO approach would create and use variables only for the app that is in current use, as the code is being executed. Although this solution would use less RAM, the current complexity would make the code unmanageable.
So back to the compromise, how does one solve it? (This is not a rhetorical question.)