I read the link above and i think i get the idea. You seem to be think of a kind of specialised 'stop watch' application. I'm not familiar with programing for the type of device you are looking at. But you have presented something very interesting. In that you will be doing a number of things here. Basically, learning to program, and also, aiming to produce something useful in the process.
The best way to learn programing, if there is a best way, but certainly the most enjoyable way, is if a person has what people like to call an 'itch'. Which it looks like you have. So half the issue is already there.
As far as the 'form' of the program is concerned, how it should be structured, whats the best language etc ... let that stuff create it self during the process. Even to let it form and then reform as it progresses. Just choose what ever feels comfortable, or is handy ... When/if changing over to another language, if that should occur, and it probably will, then that becomes a positive, as it will be an exercise in translation. And also helps to reveal the 'sameness' of different languages.
I would suggest that you treat each requirement as a separate line of experimentation. Not worring about all the accompanying repartitions. Those repartitions are a good thing as well, as they will reveal the elements that can be made common for when it's all merged into a final application. And help a person become more familiar with those elements as well.
What i'm getting at, is to just start experimenting with timer objects/components. Probably using a gui for convenience. Once started like that you will find that ideas will tend to follow on from that quite naturally.
Create a form in a gui and drop a few buttons on it and either one or a few text/edit components , or maybe just label objects. To display output. And either one or a few timer objects. Dont worry about trying to make it look to good. Just enough so that it's workable. Then use the event handler(s) that will be associated with each button to experiment with manipulating those objects.
As you say, your starting from total scratch ... then the raw experimentation process, while time consuming, will allow you to think about how these things could be combined into an over all expression. If you can find any existing source along these lines , all the better. Existing source, while it is possible to adapt such things, isn't always as directly helpful as usually thought. It can be a good way to get ideas though, on coding constructs. But as far as keeping in touch with the program as it develops goes, it is often just better to just write it your self from the ground up. Rather than trying to visualise some thing drawn up by some one else. A persons idiosyncrasies will often be reflected in their coding ... to degrees.
A lot of the experiments may appear to be unrelated. But over time you will likely stumble apone things that will just jump off the screen at you. Such as, things that will be so obvious as to what you want to use in the final program.
When something does start to gel, it doesn't matter how bulky or incomplete it may appear. The first thing is to get something that is simple, and working. It can always be reduced and made respectfully terse later on , losing its' obviousness too, in the process. It can be a right pain, when after a couple of months of just leaving it, and when you come back, it can't be figured out just wtf i was thinking of at the time
. So long hand at least will allow you to be able to read your own stuff (grin). Important when something is still trying to find its' final shape.
As you mention ... making a start. That is the hardest part. So by pass that and just start any where. By doing simple timer object experiments in a gui. Then letting the plan form while doing that. Eventually you will have a lot of separate ideas/experiments recorded in a whole bunch of subdirectories, full of repetitive elements.
It's then a matter of taking those pieces and slotting them together, so to speak.
Keeping the structure of those pieces as similar as possible, each being a very small app in themselves, should allow you to more easily add elements/things over looked, later.
I would tend to go for, in the final construction, a separate file for your main function with a separate file used for each different usage of a timer. Along with a header full of 'extern' declations included in each one. With the actual declarations being in the file holding the main function.
As far as whether it needs special stylisations for the device your thinking of, don't let that be such an issue. As in, don't let it get in the way of getting a working set together. You can alway make those adjustments later. The important thing is to get the ball rolling initially.
It sounds very interesting and should be fun. Don't be to surprised to find it taking up most of 2007 either (grin). Hope to see some further posts on this ... Good Luck