USA: +1(669)289-8683 
Sign in
Use Code Composer Studio To Write The Code As The Description
ECE 2564
Project 3
Low-Power Tamagotchi
Spring 2022
April 19, Version 1
How do I read this document?
Our goal has been to provide you with as much information and tools as possible to
help you succeed with the project. Nevertheless, you might not need to read the entire
document at first. We recommend that you take a quick look at it to know the main
topics covered. Then, carefully read the Game Description and Code Quality sections,
and begin your design. Once you have made some progress with your project, carefully
study the Validation section. Whenever you have any questions, you should first try to
find your answer in this document. The Design Strategy section contains tips and advice
on completing certain parts of the project.
Version History
(Version 1) Initial project specification release
Table of Contents
(Essential sections of this document are marked with an asterisk *.)
Fundamentals
General guidelines for any assignment
Why do I have to complete this project?
Starter Code
Honor Code Policy*
Late Policy*
Golden Solution
Submission Process*
Button/LED Names
Game Description*
Introduction
The Title Screen
The Create Word Screen
The Guess Word Screen
Game End
UART Requirements
Summary of Requirements
Code Quality*
Bonus Point Opportunities
Bonus Points Grading
Design Strategy
Report
Validation*
Test Word Bank
Fundamentals
General guidelines for any assignment
● Before you start working on your assignment:
○ Skim through the entire project description and carefully read the essential
sections marked with *
○ Read the starter code carefully and in its entirety.
○ Run the provided S22_project3_golden.out on your board. This is an
executable that we call the golden solution.
● Every time you sit down to work on your assignment:
○ Before you start coding, go to Piazza, and read questions/notes related
to the assignment you are working on, even if you took a two-hour
break.
○ After you finish coding, push your changes to GitHub, even if you are
going to take a two-hour break!
Why do I have to complete this project?
TI’s MSP432P401R Launchpad is an inexpensive microcontroller which can be programmed for
a variety of different functions. The purpose of this assignment is for you to experience
developing an interrupt-driven, low-power application for the MSP432P401R.
The previous projects you have designed primarily use a polling-based architecture. While this
old approach is effective for basic games and applications, it also drains a non-trivial amount of
power when the system is idle.
Using interrupts with a processor which sleeps in low-power mode saves significant energy.
This approach is commonly found in many applications where battery life is important,
like for example your mouse and keyboard, so it’s crucial you also learn this style of
programming.
Starter Code
To get the starter code, follow the instructions for accepting assignments and importing projects
from the CCS/GitHub Integration website page. Instead of using the assignment link in the
tutorial, you need to use the below link:
https://classroom.github.com/a/kmKJxVtw
Honor Code Policy*
You are allowed to copy code from any previous program given to you as part of the course
material (HW, class examples, course website, etc.). However, copying/inheriting code from
outside/external resources constitutes plagiarism. If you have any questions whether your
research or design falls under “fair use”, do not hesitate to contact the Professor, a GTA, or a
ULA.
Late Policy*
The project has a built-in 48-hour grace period that incurs a 5% grade reduction for projects
submitted during that period. Unless you have an SSD extension or given extra time without
penalty by the professor for special situations, you will not be given any extra time. Furthermore,
late submissions do not qualify for bonus points.
Golden Solution
We are providing a golden solution executable. The purpose of this file is for you to observe the
behavior of the project in action. The executable is called S22_project3_golden.out and is
provided on Canvas. Follow the instructions here to flash the microcontroller with the executable
file. If there is any difference between the golden solution and the project description,
please follow the project description. Please also bring the issue up on Piazza so that we
are aware of it. (A “bonus” golden solution that contains some features that are considered a
bonus is provided for you. These bonus features are not required and are simply just examples.
Please read this document so you know what features are actually required.)
Submission Process*
You will have to submit your project to GitHub by the deadline. It is extremely important that
you make sure you have uploaded all your files, including custom images if any, to
GitHub.
You will submit your report to Canvas as a pdf.
If for any reason, you are not able to submit your work to GitHub, zip up your work,
upload it to google drive and email it to 2564-grading-g@vt.edu. Regardless of the method,
you will have to submit your work before the deadline.
Button/LED Names
In this project, we will use the LEDs and buttons on both boards. We will use the same naming
convention as our previous assignments as shown below. For the BoosterPack LEDs, we will
refer to the collection of all three LEDs as BLED, which can be turned into a variety of colors.
Game Description*
Introduction
In this project, you will develop a simplified version of the popular, early 2000s toy trend:
Tamagotchi. Using interrupt-driven programming, you will develop a game where you can feed
and play with your Tamagotchi by moving it. As time passes, your Tamagotchi will grow if the
player takes good care of it.
The game will be primarily controlled through GPIO buttons and hardware timers, while the LCD
on the BoosterPack is used to display game information. Unlike previous projects, this one will
use an interrupt-driven architecture. The processor will periodically go to sleep and can only
be woken up by interrupts. As such, the tools you’ve used in previous projects may need to be
adapted to work with the new, interrupt-driven scheme. Some of these tools have already been
reworked for you to use as part of the starter code.
The Title Screen
When the player first boots the game, the player should be greeted with a title screen which
should display (at minimum) the name of the game and the developer name (i.e. your name).
After three seconds pass, this screen switches to the “instructions” screen.
Title Screen (Golden Solution)
The Instructions Screen
This screen explains how to play the game, among other details that you may add for flavor.
However, you must use your own words when writing the instructions for this screen. Do not
copy the golden solution word-for-word. Pressing BB1 on this screen should advance the
program to the “game” screen.
Instruction Screen (Golden Solution)
The Game Screen
Upon entering the game screen, you should see a Tamagotchi inside a playpen indicating the
bounds of how far the Tamagotchi can move left and right. Additionally, you should see three
stats displayed for the Tamagotchi: Age, Energy, and Happiness.
Pressing BB1 will feed your Tamagotchi and increase its energy. Pressing LB1 and LB2 lets you
play with the Tamagotchi by moving it left and right, respectively. Your Tamagotchi can only
move while it has energy, and it cannot move beyond the bounds of the playpen. Playing with
your Tamagotchi increases its happiness.
As time passes, your Tamagotchi will age and lose energy and happiness. If the Tamagotchi
meets specific energy and happiness levels by the time they reach certain ages, your
Tamagotchi will advance in its life cycle. The Tamagotchi starts as a child, and by the end, it can
become an adult. If, however, your Tamagotchi’s happiness and energy both reach zero, then
the Tamagotchi will become unhappy and leave, ending the game.
Overview of Tamagotchi stats:
● Age represents how old your Tamagotchi is.
○ Age starts at a value of 0
○ There is no minimum or maximum for the age stat
○ Every three seconds, age increases by 1
● Energy represents how well-fed your Tamagotchi is.
○ Energy starts at a value of 5
○ Energy cannot be lower than 0 or higher than 5
○ Every three seconds, energy decreases by 1
○ Every two steps your Tamagotchi takes decreases energy by 1
○ Pressing BB1 feeds your Tamagotchi and increases energy by 1
○ Your Tamagotchi cannot move if it has no energy
● Happiness represents how happy your Tamagotchi is.
○
○
○
○
Happiness starts at a value of 3
Happiness cannot be lower than 0 or higher than 5
Every three seconds, happiness decreases by 1
Every two steps your Tamagotchi moves increases happiness by 1
Overview of Tamagotchi life cycle:
● Tamagotchi starts as a child
● If a child Tamagotchi’s energy level is at least 3 and happiness level is at least 4 upon
reaching age 3 or later, the Tamagotchi will become a teen
● If a teen Tamagotchi’s energy level is at least 2 and happiness level is at least 2 upon
reaching age 7 or later, the Tamagotchi will become an adult
● The Tamagotchi cannot skip stages in the life cycle, and must become a teen first
before it can become an adult. For example, if a child Tamagotchi has 4 energy and 5
happiness upon reaching age 10, it will become a teen.
● Each stage in the life cycle must be visually distinct from one another. This can be as
simple as using different colors for each stage, as long as there is some way to tell each
Tamagotchi stage apart from one another.
● At any point in the life cycle, if the Tamagotchi’s energy and happiness are both 0, then
the game will end.
Tamagotchi Life Cycle (Golden Solution)
The Game Over Screen
When the game is over, a game over message will be displayed on the screen. Additionally, the
age of the Tamagotchi will also be displayed on the screen. Pressing BB1 transitions back to
the Instruction Screen and starts a brand new game.
Game Over Screen (Golden Solution)
Design Requirements*
From a hardware perspective, your system should configure each of the following peripherals
using an interrupt-driven approach:
● All five buttons we have used so far (this includes two launchpad buttons, two
boosterpack buttons, and the joystick button)
● Timer32 (both TIMER32_0 and TIMER32_1; TIMER32_0 handles software timers and
already is preconfigured for you)
From a software implementation standpoint, this project must be interrupt-driven. Whereas in
previous projects your implementation consisted of an infinite loop that runs as fast as the
microcontroller can allow, in this project, your main loop will put the microcontroller to sleep
using PCM_gotoLPM0(). This function will sleep and block the microcontroller until an
interrupt occurs and the corresponding ISR is triggered. Once this happens, the
microcontroller will return from PCM_gotoLPM0() and execute the body of the infinite loop only a
single time. See the code snippet below for an example of this.
Interrupt-driven code structure
What this means is that your program should no longer poll the infinite loop as fast as the
processor can. In an actual embedded system, this approach reduces power consumption,
especially if the microcontroller is deployed for long periods of time. The HAL you used in
Projects 1 and Project 2 will most likely not be suitable for this project, and you will have
to write a much simpler one from scratch.
We introduce two software checks which ensure that you have followed these guidelines. The
first one should be familiar with you – the main loop function must be non-blocking. Tapping the
joystick button, JSB, at any point in this application should toggle the green Boosterpack LED,
BLG. The second check we introduce is the sleeping check. Just before you sleep the
processor, you should turn on the green launchpad LED, LLG. Just as the processor wakes
up, you should turn off the green launchpad LED. As the user uses your reflex measurer, the
launchpad’s green LED should always appear to be lit, since the processor should almost
always be asleep. See the figure below for an example.
Sleeping Check and Nonblocking Check
Code Quality*
Developing high-quality code is a very important skill for any programmer. A well-written
program can be easily tested, updated and shared with the rest of the team, whereas a
low-quality program might “work” for a short period of time but will not be practical in the long
run. In this course, you will strive to develop higher quality code to build your skills. We will focus
on the below aspects for this purpose.
Comments
You should add enough comments to your code that makes it easy to read and understand. If
you are not sure what level of documentation is enough, consult your instructor or your
ULA/GTAs. You may also consult with ULAs for suggestions on code-comments, but they are
NOT the final arbiters of your grade.
No Global Variables
Your code should not use global variables. All interactions between functions should use
parameter passing. The only exception may be a custom image (if you implement one).
Interrupt Service Routines can use global variables sparingly.
No Numeric Values
Do not use any numeric values inside your code with the exception of 1 and 0. Instead of
hardcoding values in your code, use macros to associate required values with symbolic
labels. This rule does not apply to the graphic functions, e.g. values used to change graphics
colors or position display elements. However, it is strongly recommended to use macros
whenever a value for a graphics setting is repeatedly used or if its purpose can be readily
ascertained by providing a name (e.g #define RED 0x00FF0000 is prefered to using
0x00FF0000 throughout your code).
No Long Functions
All functions including the main function should be less than 50 lines of code. This is to
encourage you to build a modular design with smaller functions that have simple, clear
objectives. Comment lines, lines with only curly braces, and empty lines do not contribute to this
50 count. Points will only be deducted for serious violations of this rule. If a function is very close
to the requirement (52, 53 lines, etc) that will be acceptable. If a single function is above 60
lines of code (with the exception of provided libraries like grlib.h and ImageReformer)
you will receive a 0/30 for this score. If you find yourself with a function above 60 lines,
extract clearly separable portions of code and encapsulate such code into new functions which
you may then call in your original over-length function, especially if such portions are used
across multiple functions. CCS provides a refactoring tool in the editor view which can assist
with and automate this process.
Using HAL
You need to have a HAL for all your low-level hardware interactions including buttons and LEDs.
You may use your code from any previous homework or project to implement your HAL.
Non-Blocking Code
Your entire application must be non-blocking: At any point during the operation of the game,
pressing LB1 must turn on LL1. Releasing LB1 must turn off LL1. This operation is to make sure
none of your code is blocking the processor from running in an infinite loop responding to user
input similar to a typical bare-metal embedded system.
Bonus Point Opportunities
Before you read about bonus opportunities, note that bonus features are supposed to build on
top of a complete or near-complete project. Please do not use the bonus points as a
substitute for completing the core functionality of this project. You want to implement
bonus features onto a game which you’ve gotten to mostly work, perhaps with a couple of bugs
that you are still working on. However, if you are unable to get your interrupts, or are unable to
move through states in your FSM with 100% reliability, please implement the rest of your project
before asking about bonus features. ULAs and GTAs will not help you with implementing
bonus features until you’ve already finished the core functionality of this project.
There are many opportunities to get extra points for this project. The bonus points are capped at
150 bonus points regardless of how many features you implement. Along with a standard
golden solution, a “bonus” golden solution file, S22_project3_bonus.out, is provided that
demonstrates working examples of some of the bonus features. You are free to pick some
features from the below list, or discuss new features with the instructor for additional bonus
opportunities.
●
(10 points) Custom Images: Add custom images to the title and game over screen for 5
bonus points each. (Implemented in the bonus solution)
●
(20 points) Spritework: Create and use custom images as sprites for your Tamagotchi.
Each stage in the Tamagotchi’s life cycle should have a unique sprite. (Implemented in
the bonus solution)
●
(15-20 points) Presets: For 15 points, add another screen after the instructions screen
that lets the user choose between different Tamagotchis. Each Tamagotchi should have
a unique appearance from the other Tamagotchis at each stage in the life cycle. This can
involve but is not limited to different colors and shapes. You can earn an additional 5
points by combining this with the Spritework bonus. You may use LB1/LB2 to select a
preset, then BB1 to confirm the choice. (Implemented in the bonus solution)
●
(30 points) Interrupt-Driven UART: Make your program compatible with UART. To keep
things simple, you may configure your UART to work at 9600 BPS, 8 data bits, 1 stop bit,
LSB first, and no parity bit. To prove that your UART implementation works, complete at
least one of the following bonuses for additional points:
○ (5 points) WASD Movement: Allow your game to be controlled using a WASD
control scheme, via UART. Although the base game only lets the Tamagotchi
move left and right, the Tamagotchi should be able to move up and down with
this bonus. You may also implement this scheme for the Presets bonus screen.
○
(15 points) Names: Before entering the game screen, prompt the player to give
the Tamagotchi a name. The player should be able to type into the UART
terminal with Backspace functionality, and pressing BB1 should lock in the name
of the Tamagotchi. The name should be displayed at the top of the game screen.
If no name is given to the Tamagotchi, generate a default name for the
Tamagotchi. (Implemented in the bonus solution)
●
(30 points) Interrupt-Driven Timer_A: Make your program compatible with Timer_A. To
prove that your Timer_A implementation works, complete at least one of the following
bonuses for additional points:
○ (30 points) Blinking LED: Play a small blinking animation on the BLED using
Timer_A whenever the Tamagotchi ages or enters a new stage in the life cycle.
When the Tamagotchi ages, have a 5% dimmed blue LED (BLB) turn on for
0.25s, off for 0.25s, on for 0.25s, and then off again. When the Tamagotchi enters
a new stage in the life cycle, use a 20% dimmed red LED (BLR) instead, but with
the same blinking pattern. (Implemented in the bonus solution)
○ (25 points) Sound Effects: Play a small sound effect or jingle using the buzzer
whenever your Tamagotchi enters a new stage in the life cycle. The sound
effect/jingle should be brief and last no longer than 2 seconds. (Note: If you also
choose to implement the Blinking LED bonus, the red LED and buzzer will
conflict since they use the same Timer_A. As such, the dimming requirements for
BLR are waived with this bonus) (Implemented in the bonus solution)
○ (Hint: Even though the MSP has two hardware timers, you only have one
hardware timer available for this project, since the other one is used for button
debouncing. However, it is likely that you will be using the remaining hardware
timer for the in-game timer. As such, you will need to be creative here with how
you implement these bonuses, since they both rely on timing. Consider that
although Timer_A is primarily used for PWM, it is still, in fact, a timer)
●
(65 points) Interrupt-Driven Light Sensor (Dark Mode): Make your program
compatible with I2C, allowing communication with the OPT3001 light sensor. To prove
that your I2C implementation works, implement a dark mode color scheme for your
project. At any moment in your game, the color palette of your game should swap to a
dark version whenever the lux measured by the light sensor goes below a specified
threshold. Covering the light sensor with your thumb should be enough to trigger dark
mode. When the lux is above a specified threshold, the color scheme should revert back
to its original form.
You are welcome to implement any other extension you are interested in. However, you need
to discuss it with your instructor and get an email confirmation of what you are intending
to implement is acceptable and how many points it is worth. You may also do this with a
Piazza post.
Bonus Points Grading
The amount of bonus points received is proportional to the amount of points received from the
code-quality section (Rounded down). In other words….
Say you received 150/150 Bonus points, but only 70/100 Code-quality points. Thus, your
resulting bonus points received would be:
== 0.70 ( 150 ) → 105 Final Bonus Points
In addition, BONUS POINTS ARE ONLY AWARDED TO SUBMISSIONS THAT ARE NOT LATE.
Design Strategy
This project requires skills unlike the previous assignments. Although the concept of the project
may be simpler than the previous ones, you may need to do research into technical documents
or example projects to understand how to use the new interfaces you will be working with. As
such, it may take several dedicated days, if not the whole two weeks, to complete the project.
Based on our experience in the past, we highly recommend you start projects in this course as
soon as possible. READ THE GAME SPECIFICATION IN ITS ENTIRETY AS SOON AS YOU
CAN, so that you can start thinking about design issues you may encounter in your
project sooner rather than later!
Despite being largely different from Project 2, we still recommend the following strategy when
designing Project 3:
1.) Get your peripherals to work (I/O and Hardware Interfacing)
2.) Design your application-level software abstractions on paper (e.g., FSM, pseudocode)
3.) Implement each feature delineated in your design outline, one at a time
4.) Use the debugging techniques we learned in earlier assignments: breakpoints, viewing
variables, using LEDs, …
As is always the case with any project involving code, always get your inputs and outputs
working first before you work on the rest of the code. Since the microcontroller will sleep on
every loop, you will need to implement interrupt handlers for each button. In the starter code,
JSB has already been set up for you. Use it as a reference for adding the other buttons!
To test your peripherals, make simple helper functions which validate output as a function of
input. The choice for how to do this is ultimately yours, but one simple example includes writing
functions to toggle launchpad and boosterpack LEDs when you receive button taps. The
HAL for the LEDs is included in the starter code. Use it to test your buttons!
Since the microcontroller goes to sleep in between loops, software timers will be largely
ineffective. You will need to use the hardware timers to generate interrupts to wake up
the microcontroller. Fortunately, one of the hardware timers is already set up for you. Use
TIMER32_0 as a reference to set up TIMER32_1!
Next, put away your code and get out a pen and some paper. The best software is designed
with a pen and paper, not by hacking away with no stops until it barely works! Reread the
project description and start jotting down some ideas for how you can implement parts of your
project. Key components you may wish to consider in your design include the following:
●
What kind of data do you need to represent your game? The starter code does not
provide anything like the application struct, but you might consider making your own. The
starter code and HAL API are completely yours to modify and extend. When you
inevitably run into a problem where you require variables to maintain their values across
many calls of your program, a struct is a good place to store some of those variables.
●
The microcontroller can only be woken up by interrupts once it is put to sleep. As such, if
you are designing an FSM, think about how to transition between different states of
the program. How will you ensure that the microcontroller is awake as you change
states?
●
ISRs are unlike typical functions, since they do not have parameters or return values.
They can only interface with your main code through variables accessible outside of the
ISR. When writing your ISR implementations, consider whether you need to declare
additional variables. Does your ISR need to pass information back to the main program
as soon as the interrupt triggers? Not every ISR needs to interface through a variable!
●
How will you draw each UI element onto your LCD? Draw a mock-up on your paper to
get a good sense of what the final product should look like, and how each state variable
in the game is represented on the LCD. However, don’t focus too much on making your
project look perfect. Get your code working first, then focus on aesthetics later.
●
Think about places in your project where it would make sense to implement an FSM, one
of the most powerful organizational tools that you have at your disposal. Review the
spec and make note of any transitions like button presses or specific inputs that cause a
radical shift in the state of your program. Sketch an FSM diagram and make note of all
the transitions. Determine which states your program might come back to and which
ones will not be revisited.
●
What are some ways in which you can incrementally develop your solution? Focus on
small objectives such as making the Tamagotchi move, making the in-game timer count
down, etc.
●
In conjunction with the tip above, try to describe the general tasks that your code
performs within specific states, under certain conditions, or on every loop. Breaking
down the code into these general tasks can help you develop functions, which keeps
your code modular and easy to understand. Give your functions descriptive names that
clearly indicate what the functions do. Thinking about the mechanics of the program at
higher levels first will help you understand the general flow of your code before you start
worrying about the low-level details.
As always, when implementing your code, practice an incremental approach. Implement each
feature you have outlined on your paper one at a time, and immediately test the new
feature you have just added so that you can detect possible bugs early!
Finally, when using Git, use your commits wisely. We recommend committing your code after
you successfully implement each new feature. This should seem obvious, but don’t commit
broken code! If you know there is a bug somewhere, fix it before you commit. Each commit you
make should be a checkpoint that you can roll your code back to if you really must.
Report
Write a short report with the following:
1. Cover page: This should include title, date, institution (Virginia Tech), and course number.
You must include your name, GitHub username, and a link to your repository on the
cover page as well. You may choose the format, but the cover page needs to be in a formal
professional form.
2. Report Summary: In less than 50 words summarize the purpose and content of the report.
3. Project Description: A short section (a paragraph or two) describing what your application
can accomplish. Ideally, this matches the Project description. However, use your own words
to describe it. State clearly which parts of the Project specification are satisfied by your
implementation. Take pictures of your game at various stages and include them in your
report. If your application cannot perform all the tasks or performs some of them
suboptimally, you need to mention them in this section.
Tip: Use the debugger to help you take screenshots!
4. Microcontroller-based embedded system architecture: To the best of your knowledge
draw a high-level architecture of the system you are using for this project. The drawing
should be done on a computer using your program of choice such as Microsoft
powerpoint, Visio, Google draw, etc. Your figure should have at least two parts: board-level
and chip-level view. In each level, only include the peripherals that are involved in this
project. Do not forget to include the interrupt controller. You do not need to draw two
boards for BoosterPack and Launchpad; a hypothetical unified board will suffice. Write a
paragraph or two describing the architecture. Your description should explain what
component on the board is connected to what peripheral on MSP432 and how they
communicate to the CPU (Hint: memory-mapped registers).
5. Code Quality: Write one or more paragraphs about various aspects of code quality you had
to meet for this project. If your code does not meet the code quality requirements describe
the reason and your challenges. Create a table or a bulleted list with all the code quality
headers in the project description with the number of points you expect to receive for
that header. Add an extra row or bullet for the sum of points you expect to get for
Code Quality.
6. Bonus: Write one or more paragraphs explaining which bonus features your application
achieves (if any), and how you implemented those. Create a table or bulleted list with the
features you have implemented and the number of points you expect to get from
those bonus features. Add a row (or bullet) for the total points you expect to get from
bonus points.
When you have finished, submit your report to Canvas as a pdf.
Validation*
Your GTA will evaluate this project using the actions as described in the table below. Please
ensure that your program follows the specification and that it passes the validation tests as best
as possible locally before submitting!
Feature
Point Values and Description
Basics
[100]
Reset the board.
[25] A splash screen is displayed for approximately three seconds. The name of
the game and the name of the student are present.
[25] After the splash screen fades away, the instruction screen is presented.
[25] Pressing BB1 in the instruction screen transitions to the game screen.
[25] The game screen displays the Tamagotchi, play-pen and the respective stats
(age, happiness, and energy)
Gameplay
Short
[200]
Check for below basic features when a new game is started without issuing any
command or button actuations for the entire game
[50] After 3 seconds, the Tamagotchi turns into a child at age 1.
[50] After 6 seconds, Energy is 3, Happy is 1, and Age is 2.
[50] After 15 seconds total, Happy and Energy are 0 and the Tamagotchi leaves.
[25] Automatically transitions to game over screen with age being displayed as 5.
[25] Pressing BB1 in the game over screen starts a fresh game taking control
back to the instruction screen.
Gameplay
Core
[250]
Features primarily based on Age:
[10] Age increments every 3 seconds.
[20] When reaching age 3 or later, if the Tamagotchi has at least 3 Energy and 4
Happy, the Tamagotchi becomes a teen. If the Tamagotchi had 3 Energy and 4
Happy at age 2 and now has 2 Energy and 3 Happy at age 3, the Tamagotchi still
becomes a teen.
[5] Teen stage must be visually distinct from the child stage.
[25] At age 3 or later, if a child Tamagotchi has insufficient Energy or Happiness, it
remains a child.
[20]When reaching age 7 or later, if the Tamagotchi has at least 2 Energy and 2
Happy, the Tamagotchi becomes an adult.
[5] Adult stage must be visually distinct from the child and teen stages.
[25] At age 7 or later, if a teen Tamagotchi has insufficient Energy or Happiness, it
remains a teen.
[25] The Tamagotchi cannot skip stages in its life cycle. (It should reach teen
stage before it transitions to the adult stage.)
Features primarily based on Energy:
[10] Energy increases when the Tamagotchi is fed (BB1 pressed).
[10] Energy decreases after every 3 seconds.
[10] Energy is capped in the inclusive range of [0, 5].
Features primarily based on Happiness:
[10] Happiness decreases after every 3 seconds.
[10] Happiness is capped in the inclusive range of [0, 5].
Features based on Movement:
[25] Moving the Tamagotchi successfully 2 times decreases Energy by 1 and
increases Happy by 1.
[25] It is impossible to move the Tamagotchi when it has no Energy.
[15] The Tamagotchi cannot move outside the play-pen and such a move is
termed invalid. An invalid move cannot not contribute to the movements required
for a Happy increase or Energy decrease.
Miscellaneous Interrupt driven code:
[250]
[100] Interrupt based implementation of all buttons (verify from source code)
[150] In the case that a purely interrupt driven code is written, the “processor is
asleep” LED will barely turn off and almost always stay ON. No points are awarded
if this LED is OFF for more than 1 second.
Code Quality
[10] Code is reasonably commented so that a TA can understand your code.
[100]
[20] #defines and constants are used instead of hard-coded numbers, with the
exception of UI/Graphics elements.
[30] No function exceeds 50 lines of code, within reason. Comment lines, lines
with only a single curly brace, and empty lines do not contribute to this total. Points
will only be deducted for egregious violations of this rule. If a function is very close
to the requirement (52, 53 lines, etc) then it is okay.
If a single function is above 60 lines of code (with the exception of provided
libraries like grlib.h and ImageReformer) you will receive a 0/30 for this
score.
[20] No global variables are used, with the exception of possibly custom images
using the Image Reformer.
[20] Your code is completely non-blocking. Holding down LB1 lights up
Launchpad LL1 at any time.
Report
[10] No grammatical or spelling errors are present.
[100]
[10] Cover Page
[10] Report Summary
[30] Project Description
[30] Architecture
[10] Code Quality
[0] Bonus (only needed if you have completed any bonus features)
Bonus
[150]
Report any bonus features and record how many bonus points were earned. In
your report, you are required to create a table or a bulleted list with a row for each
bonus feature and an extra row dedicated to the sum of points you expect to get
for bonus features.
Points received from Bonus use the following formula:
Final Bonus = [Code Quality %] * [Raw Bonus]
Final Bonus = 0 if submission is late
Total
bonus
[1000]
w/o
