2.0Software Design Considerations

1.0Introduction

The DigiCaddie, an add-on for a golf bag to make it “smart”, is a very software dependent device. The software is what ties all the peripherals together and most importantly allows the user to interact with the product. This report will serve as a guide to how the design team plans on mapping out the microcontroller’s internal memory as well as to the different main code modules which will be implemented.

2.0Software Design Considerations

One of the most important factors in the design and implementation of software for the DigiCaddie will be organization of the microcontroller’s memory. Since the final product is going to be utilized by a general consumer, no assumptions are going to be made with regards to whom the end user will be. This means that the product that will be produced must be reliable and be something anybody could and would use.

The first part of the software to map will be the stack pointer. On the MCx12C128, there’s 4K of RAM to use. Since the stack pointer innately moves upwards in memory, there’s a viable concern to leave a decent amount of space prior to the stack pointer without crossing over into other meaningful regions of space. For this purpose, the stack pointer is going to be initialized at 0x3800.

The next step would be to map a section for static memory. The section that has been declared as permanent variable space, starts at address 0x4000, and will be given a tentative boundary to 0x5000. Preliminary pseudo coding reveals that the DigiCaddie will need well under the allotted space, however the extreme measure that is being taken is for future safety concerns. Should a different implementation of a particular module be necessary, and require more variable space, the current setup allows for flexibility.

The DigiCaddie currently does not support dynamic memory allocation, a need or a concern for a heap or heap management is not necessary at all. All variables will be statically declared and respectively filled in, initialized, or utilized when necessary.

Additionally, the program code needs to be allocated a region of space. A general instruction will occupy roughly on average three bytes of space; 1 for the opcode, in addition to 1 and/or 2 for whatever register or memory opcode is necessary to accompany the instruction. That’s roughly three to four bytes per instruction. At the very most, this application should be no larger than 3000 lines of assembly. This estimates to roughly 12K of necessary memory, at the most. Although previous memory allocations show that all spaces past 0x5000 are available, for the sake of structure and effective memory management, the program code is going to be stored at 0x8000. There’s a 16K ROM memory that’s readily available, and on top of that there’s an additional 4K of ROM should it be necessary

As far as mapping the ports and peripherals to address space on the microcontroller, a solution has already been effectively implemented. As outlined in the Hardware Narrative (Homework 5), every pin that is necessary has already been given an assignment, in addition to already having been grouped with a respective module / specific purpose. Since that effort has been taken care of, the rest of the port assignments and addressing, fortunately enough has been handled by our compiler (Metrowerks Codewarrior.) Codewarrior attaches MC9S12C128.INC file that assigns every port to a respective address.

The overall organization of the application will be mixed mode. It will ultimately be a combination of being poll-looped, state-machined, and interrupt service driven. This is slightly counterintuitive, but this mixed mode application is necessary. The interrupt driven aspect comes into effect when picking up differences in modes of operation. From a very high level, the few actions that will trigger “events” will be when an RF signal is acquired from the push button the golf player has, or when the touch screen is effectively “touched.” Additionally, the interrupts will service the updating of the wind modules. However, the program is equally state machine and polling looped, as the flags that are set in the interrupt service routines will determine the operation of the main loop.

3.0Software Design Narrative

The software of the DigiCaddie consists of six major modules. These modules, not including the interrupt, timing, or analog to digital, are the Program Loop, Wind Vane input, LCD output, Touch Screen input, RF input, Serial output. The Program Loop is considered the top level of these modules. What happens is that the Program Loop iterates through a list of prioritized flag checks and compares the flags to see if a call to one of the other modules is necessary. These flags are set during the RTI routine which will end up being tripped something around every 2ms. When the RTI is set off, the program will break out of whatever it is currently doing to service the interrupt. Inside this routine all the necessary ports will be checked for changes or as in the case of the wind speed, an accumulation. If the expected changes are detected a flag will be set for the corresponding module. After this interrupt routine has been serviced, the program execution will return to where it was previously and continue to execute. During the Program Loop the different flags are then compared and jump to the other sub-modules as needed.

The next module is the Wind Vane module. What happens in this module is two different sub-functions. First is the wind speed, this is calculated by taking the difference of the previous accumulation from the current and then adjusting by some yet to be determined factor to convert into miles per hour units. The second function is to find the direction. This is done through comparing values from the array of photo-resistors to also, yet to be determined, values. Both the direction and speed are going to be recalculated every time an interrupt happens.

Next is the RF input from the score keeper remote. This module will determine which button was pressed and set a variable so the next time that the LCD updates, it will raise or lower the corresponding score.

The last important module is the serial module. This will handle all the communication with the PC to which one connects the DigiCaddie. This feature is the one which has been researched the least, and will most likely take a large amount of guidance from freeware or open source materials.

4.0Summary

This software narrative’s purpose was to provide the reader with an idea of where the different parts of the software will be stored in the microcontroller’s memory and what the main modules of the software entail. However one important note needs to be made, that is that since the software is the easiest aspect of the project to adapt to changes in the project or to problems, this is by no means a set in stone outline.

List of References

[1] Freescale Semiconductor, “MC9S12C - Family”, 2006. [Online]. Available: [Accessed February 05, 2007].