-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Welcome to the miChronos wiki! I hope the README is sufficient for general operation. So this wiki can be used for more specific information, along with some general how to information. Index shows all the wiki pages.
I looked into the openchronos and ng projects, and found the compiler a little difficult to install. Along with the slow pace of development on the ng project, I came to the conclusion that the limited CCS eclipse based development environment was the best way forward. I stripped out all of the BlueRobin (TM) code from the Control Center, as I was not intending to keep any of the medical or sports features. I was interested in some of the mouse control and sync possibilities though, and so I started with what I wanted the Control Center to look like. I also added a sync computer time from the fetched watch time (needs sudo permission) as the Raspberry Pi would be the target and it has no RTC.
The source is built using some libraries in the Limited profile of CCS (free edition). I spent quite a bit of time deleting things, only to find the linker complained. There appear to be some strange dependencies in the libraries from TI. After removing all the unwanted modes I was left with about 3.4KB of memory for my own programs. I looked into where possible savings could be made, to lift this number. One idea was to use library delegate functions, and make each module specific to a line on the display. This actually saved quite a bit of memory. The strange case was the stopwatch callback to update the hundredths of a second. The duplicate or missing symbol error message was not helpful in proclaiming "the whole program" as the location for the error. The source could be shrunk even further by factoring SET ON out of many of the display calls, but this would use more battery, and coding pressure was not that high.
I'm just a maths freak. So I decided on a slide rule application as a test. I started with integer fixed point code, and it worked fine. I then looked into what functions were being linked in by the linker, and saw that the altimeter driver was using floating point (luckily no division by variables). I then tried to delegate fixed point versions of these driver functions, but found the library still linked in a large amount of code. This made me redesign the slide rule to use floating point (except division by variables). The integer division is built in as the display driver uses it to format numbers. Thus it was possible to make a slide rule and a day of week using very little memory. Especially as I converted the temperature and altitude applications to use more optimally linked maths, and slightly modified the filter functions to use shifts, and got rid of some times minus one stuff.
I got worried about excessive button pushes on the bottom row. So I created a utility menu which took little space, and does save quite a bit of button pushing for general watch usage. I added a random number generator to the battery display just because I could and it could prove useful. With over 3.7KB of space I was not too worried, given that it would take a few bytes. I added in the option to display temperature and altitude in either units, and that filled up all the button press options nicely.
I decided a simple tune alarm would be nice, and so worked out the simplest thing was to set TA1CCR0 to the pitch value after calling the main alarm start buzzer function. There is a strange effect returning the alarm to a duration of 10s after the first use of a longer alarm, and I have not investigated it's origin. So the alarm plays a tune in pairs of notes using a pointer to u16 as the tune selection value. This allows for individual day tunes, and a stopwatch reminder every five minutes.
I though about better using the second functions of the date and time. Seconds display is useless to me, as is displaying the year. A sync zero seconds on time set was better. I found adding a second function to calculate relative sidereal time easy enough. I also made the date second function be a moon phase day calculation. The number wraps on the new moon. I noticed some size optimizations to make in the code, and so made both these functions take less than 300 extra bytes. I am now left with about as much space as what I thought I had, before optimizing some of the code.
As many library routines are available without increasing the code size, a lot can be done in this amount of space. The biggest problem is deciding what to do. It is about the same space as I had left by stripping the source back to the needed features. It goes to show that features do not always cost space, and on average very little extra power is used for the standard date time. (A tiny amount per day when the day changes, more than offset by less parameter stacking).