To test transitions across hour/day/year boundaries your counter should be pre-loadable with appropriate values that can demonstrate these transitions within a few seconds, e.g. something like "00:365:23:59:55.00" could be pre-loaded as a starting point for the "stopwatch".

1. Can this be achieved in software, without external counter hardware?
2. How many bits' counter is required?
3. One strategy would be to implement ONLY a "divide by 60", "divide by 100", "divide by 24", "divide by 365.25" routines, instead of a general "divide by an arbitrary number" arithmetic. Complete as much of this code as possible in the time allotted.
4. When the Event arrives, the final time must be displayed with full precision and the clock stopped. While counting, the running time can be updated much more slowly. What would be a good choice of a refresh rate that would allow the software counter to keep up with the 100Hz clock?
5. Can this be extended to 1us resolution? If not, why not? Can this be done using some minimal external hardware?

--------------------------------------------------------------------
From: Domenic

This PBT took much longer than expected to complete and was mostly due to me
not being able to task out the required parts to my class mates. After 2 days
of this PBT we were able to create a valid outline to base the program off and
able to task off parts, if we were able to do this on day 1 we would’ve
completed it much sooner. Having a better understanding of the PIC and the
supplied subroutines would have made this task a lot easier as a majority of
the time was spent looking in the PIC documentation. Being able to organize and
take each others ideas to help solve the problem was our weakest part of the
first tutorial and still hindered us the most for this tutorial. Another one of
our issues was communication, when we gave someone a task to do it wasn’t
communicated properly as they did not have a full understanding of how it was
supposed to work. I feel that after this tutorial all of us in the class have a
much better understanding on how the PIC works especially on a lower hardware
level.

--------------------------------------------------------------------
From: Martin

Like all PBT’s in the past, there are many ways to appraise the successes and
failures of the group as we progressed from start to end. To start I think it
is important to note the group’s persistence and continuous effort and
motivation throughout. Without fuel there is no movement, even if that movement
is in the wrong direction.  I don’t mean to speak for anyone else in the group
but I felt this PBT came at a tender time along the learning curve for
programming in assembly. I also attribute this to pushing me much harder than I
would have on my own to become more fluent with the language. However, being
unaware of nearly all aspects of program writing was the greatest obstacle
initially, and I feel that the whole group was in this space at the beginning.
It makes no sense to me what needs to be organized or how if I have no idea
what parts need to come together for this program to work. Time was needed to
build up fundamentals and was duly granted.

Round two, most members came with some of the basic tools ready to be utilized.
I felt Dom did a stellar job identifying parts of code that needed to get
built, and he gave good direction as to what it needs to look like for it to be
useful in the final draft. I felt this was the true beginning of our PBT. I had
a task that I could manage, I could see others in the group also finding their
place in the big picture. As was the case with the previous session, our
grouped lacked a general oversight as to the structure of the program that
would make it run without error. We didn’t yet have a complete understanding of
how a program is organized which stopped us from moving much further in this
session. More time was needed to explore the subtleties of good programming.

Final round, the group came together in blazing glory and put together a clock
like no other. I was proud to see our creation come to life and meet the
expectations set for us. There were sloppy pieces and shortcuts, missing
comments, better ways to do it, etc. But we had a thing that worked and we made
it.

The PBT is an intense and stressful way to learn a something new, but it works
and it gave me a strong sense to how projects in the digital world come
together with many contributors. Doing it again I would start with assessing
the groups fluency with the program language. Find tasks for each person that
are within reach. Consider the structure of the program. Which components,
macros, routines, and registers will be needed. Keep everyone updated as to
what is finished and what needs work. Update the timeline for expected
deliveries.

Many thanks to the group, was fun working on this.

--------------------------------------------------------------------
From: Christian

(Late submission) 

For the last two weeks our class has been creating a solar clock capable of
counting by milliseconds, seconds, minute, hours, days and years. This proved
to be more of an effort in dividing and conquering rather than actual problem
solving. Although there were certain problems occurred these were normally null
issues that were easily solved by using either subroutines or by using creative
work arounds.

To start I will evaluate the group. The group was not perfectly organized but
had been well led by Dominic, who had the most experience coding within the
group. Unfortunately due to Dominic’s personality and experience, I can’t help
but feel he was forced into this role. Otherwise the group worked effectively
to complete the task, maybe to some delay while many became familiar with the
demands and commands of the task. Special accommodations to Martin and Dom for
figuring out leap years and creating the code protocols used by the rest of the
group.

In a self-examination I feel myself to be a weak contributor, I was very weak
in the department of actual coding knowledge and problem solving in software. I
feel the only appreciable help I gave was in terms of grunt work where I did
what I was explicitly told to do. I feel I perhaps helped with the
brainstorming of ideas; however, this rarely translated into actual coding. 

--------------------------------------------------------------------
From: Paul

This PBT that stretched over three class time slots may not be seen as an
efficient use of time, but I still believe that useful lessons can be drawn
from our failures and our successes. The first session was rather chaotic in
the sense that we had each person looking for subroutines that would make the
problem easier to solve and had what seemed like two sub-groups trying to
create a basic clock program from two completely different approaches. This
style of approach has been proven effective in other PBT's (such as the ones
from analog), however, for this task it became apparent after the first session
that we all needed to be working on different parts of the SAME approach to the
solution. Martin and Domenic were clearly the leading PICL experts of the group
and did a great job creating a working program with the use of some key
subroutines. I think the most valuable lesson from this exercise was Professor
Sternin's  "intervention" in the form of how a program code should be
constructed by a team of individuals with the idea in mind that other members
of the team are going to be building upon what one has already written. This
was shown in the recommended layout of the code (declaration of registers to be
used, main code with detailed comments, and a list of subroutines proceeding
after the main code). It wasn't until the last session that the team started to
divide and conquer (with some precision) the final parts of the task at hand
such as creating comments for the code, troubleshooting minor errors, testing
rollover points etc.

--------------------------------------------------------------------
From: Chris

--------------------------------------------------------------------