Home > Courses > 2P32 > 2016-2017 Problem-based tutorial #2 An astronomical "stopwatch" The task is to detect (count) the time of an astronomical Event, with 10ms resolution (assuming a precise clock of 100 Hz is available externally, if necessary), and to display the time in the format "YY:DDD:HH:MM:SS.mm", where YY=0..99, DDD=0..365 (note that one year is 365.25 days), HH=0..23, MM=0..59, SS=0..59, mm=0..99. Assume you would be using the LCD display, 2x40 characters. 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". Can this be achieved in software, without external counter hardware? How many bits' counter is required? 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. 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? Can this be extended to 1us resolution? If not, why not? Can this be done using some minimal external hardware? Student feedback  -------------------------------------------------------------------- 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 --------------------------------------------------------------------