This lab is the capstone project for the class. Your team will design, implement, and demonstrate a prototype of a microprocessor-based educational toy. Your toy will run as a program on the E100 CPU that you completed in Lab 6. Your toy will interact with the user via the DE2's input devices (keyboard, mouse, microphone, camera, SD card, serial port, switches) and output devices (VGA, LCD, LEDs, serial port), using device drivers like those you wrote in Lab 7.
Each team will design its toy to meet a different educational purpose, so the features and devices used by different teams will vary widely. However, all teams will need to learn about techniques and concepts beyond those taught in lecture. The course web page discusses some of these concepts (e.g., digital audio, binary data files, and bitmapped images for the E100). You will need to learn much more on your own, just as you will throughout your career.
Your program will probably be simultaneously managing multiple devices and tasks. For example, you might want to read keyboard input at the same time as sending sound samples to the speakers. To do this, you'll need to avoid waiting indefinitely for slow input devices. Otherwise, the sound from the speakers will pause while you wait for input. You can avoid waiting for slow input devices by first checking if the input device is ready with input and only reading the device if it is ready. If the input device is not ready, you can continue with other tasks, such as sending sound samples to the speakers. This style of programming is called event-driven programming.
When writing large programs, it is essential to have consistent, clear structure. Divide your program into well-defined functions with clearly documented interfaces. Break your program up into multiple files (e.g., each device driver should be in its own file). This will help you work in parallel--different people can work on different parts without needing to understand implementation details from the other parts. Use consistent, meaningful names for variables and functions, e.g., for return addresses, constants, and instruction labels. We suggest you prefix labels with the name of the function or file in which the label occurs.
Document in your program (e.g., at the top of each file) which team member(s) worked on each component.
We strongly recommend managing your files with a revision control system. Revision control systems make it easier to coordinate between multiple people and help you manage multiple versions (e.g., if your new version has a bug, you can quickly get back to an old version).
We make it easier for you to use the git revision control system by providing a git repository for each group, hosted on GitHub. To use GitHub, you should have already:
To use the repository we provide, initialize your local repository by cloning the (empty) repository from GitHub:
git clone email@example.com:engr100/uniqnameA.uniqnameB.uniqnameC.uniqnameDwhere uniqnameA.uniqnameB.uniqnameC.uniqnameD is the sorted, dot-separated list of your group members' uniqnames.
Here is a tutorial on using git for ENGR 100.
Your project will be evaluated based on your educational toy code, your oral project presentation (which should include a demonstration of your toy), and your final report. After the demonstration, one member of your team should submit a ZIP file that contains the following:
zip -r toy.zip file1 file2 dir1 dir2 ...The ZIP file will contain the files and directories specified in the command (including files and directories contained within the specified directories). Another way to create the ZIP file is by right clicking on the directory you want to include, then selecting Create archive..., then entering an archive name ending in .zip.