Table of Contents
Corning Community College
ENGR1050 C for Engineers
PROJECT: Simple Simon Says (SSS2)
OBJECTIVE
Create circuitry and configure software to craft a simple version of the classic “Simon Says” game of recalled repetition.
GRABIT
To assist with consistency across all implementations, data files for use with this project are available on lab46 via the grabit tool. Be sure to obtain it and ensure your implementation properly works with the provided data.
lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT
OVERVIEW
Your task is to:
- construct, on your breadboard, individual circuits containing:
- four buttons (red, green, blue, yellow)
- four LEDs (red, green, blue, yellow)
- one passive buzzer
- configure and customize, through your wiringPi-enabled C program, a “Simon Says” style game that allows for an interactive experience with the user via buttons, LEDs, and the buzzer.
Contributing to project documentation is also a core part of this project. If from reading the existing documentation or through your own exploring, you find something lacking, unclear, or outright missing, that is an opportunity to potentially contribute content.
You want the project documentation to provide you (as if coming in with no awareness of the project) with sufficient information so as to allow you to proceed. Asking questions on the discord is a great way of getting more information that you can use to add content.
EDIT
You will want to go here to edit and fill in the various sections of the document:
CIRCUITS
LED
When you pick up the LED, you will notice that one leg is longer than the other. The longer leg (known as the ‘anode’), is always connected to the positive supply of the circuit. The shorter leg (known as the ‘cathode’) is connected to the negative side of the power supply, known as ‘ground’.LED stands for Light Emitting Diode, and glows when electricity is passed through it.
LEDs will only work if power is supplied the correct way round (i.e. if the ‘polarity’ is correct). You will not break the LEDs if you connect them the wrong way round – they will just not light. If you find that they do not light in your circuit, it may be because they have been connected the wrong way round.
LEDs should be supplied power on the long leg by a GPIO pin running through a resistor. When the output of the GPIO is triggered HIGH it will light the corresponding LED.
BUTTON
connect one side of the switch to an input pin on the Raspberry Pi. The other side of the switch we connect to 3.3V on pin 1 using a resistor. The resistor is used as a current limiting resistor to protect our input pin by limiting the amount of current that can flow. There should also one pin connected to ground to complete the circuit.
The way the button works and why the button within the program is the normal idle state is just letting the voltage pass through to ground. It can be thought about like a momentary switch. When the button is pressed it completes the circuit to the input GPIO pin which can be used as a momentary trigger or held for a longer term trigger.
BUZZER
There are two main types of buzzer: active and passive.
A passive buzzer emits a tone when a voltage is applied across it. It also requires a specific signal to generate a variety of tones. The active buzzers are a lot simpler to use, so these are covered here.
In order to modulate both the frequency and operation of the buzzer, a transistor is used. A transistor can be thought of as a switch or a gate. It regulates or controls current or voltage flow. It consists of three parts, the collector, base and emitter. The collector in our case is connected to ground. The base is where the GPIO output is regulating the current traveling through the buzzer through the emitter to ground.
ACCESSING COMPONENTS
LED
The first step in our program is ensuring that the pins we are using for our LEDs are set up to be outputs. This way the pi knows it is sending a signal to something rather than looking for a signal from something.
BUTTON
The first step in our program is ensuring that the pins we are using for our buttons are set up to be inputs. This way the pi knows it is receiving a signal from the button as an input.
BUZZER
So the game has three leds. Each led corresponds to a sound that the buzzer makes. Also, the buzzer is set to tell the player if their guess was correct or incorrect. So, make the lose sound a low frequency and the win sound a high frequency.
DIAGNOSTICS
LED
The LED's will light up in correspondence to a note to help the player memorize the pattern. They will light up again when their corresponding button is pressed to play back the pattern
BUTTON
The buttons are to tell the game which leds lit up, or at least what the player thought lit up.
SIMON SAYS GAME
Simon says is basically a memory game. The led lights used are to present a pattern to a player. Initially the pattern only has one led that lights up. After each round the game adds another led to the pattern which you need to remember and present to the game through the use of buttons.
DESCRIPTION
This game requires four leds, one buzzer, and four buttons.
TONES
Overall you will need a total of 6 tones in this project. These tones in this project will indicate which color led is activated. These tones will also be indicative of whether or not you have won the game.
SUBMISSION
To be successful in this project, the following criteria (or their equivalent) must be met:
- Project must be submit on time, by the deadline.
- Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
- All code must compile cleanly (no warnings or errors)
- Compile with the -Wall and –std=gnu18 compiler flags
- all requested functionality must conform to stated requirements (either on this document or in a comment banner in source code files themselves).
- Executed programs must display in a manner similar to provided output
- output formatted, where applicable, must match that of project requirements
- Processing must be correct based on input given and output requested
- Output, if applicable, must be correct based on values input
- Code must be nicely and consistently indented
- Code must be consistently written, to strive for readability from having a consistent style throughout
- Code must be commented
- Any “to be implemented” comments MUST be removed
- these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
- Sufficient comments explaining the point of provided logic MUST be present
- No global variables (without instructor approval), no goto statements, no calling of main()!
- Track/version the source code in your lab46 semester repository
- Submit a copy of your source code to me using the submit tool (make submit on lab46 will do this) by the deadline.
Submit Tool Usage
Let's say you have completed work on the project, and are ready to submit, you would do the following:
lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.
RUBRIC
I'll be evaluating the project based on the following criteria:
91:sss2:final tally of results (91/91) *:sss2:used grabit to obtain project by the Sunday prior to duedate [13/13] *:sss2:picture of unpowered circuit to #desig for approval [13/13] *:sss2:show me or video of circuit to #desig showing results [13/13] *:sss2:clean compile, no compiler messages [7/7] *:sss2:program conforms to project specifications [32/32] *:sss2:code tracked in lab46 semester repo [13/13]
Pertaining to the collaborative authoring of project documentation
- each class member is to participate in the contribution of relevant information and formatting of the documentation
- minimal member contributions consist of:
- near the class average edits (a value of at least four productive edits)
- near the average class content change average (a value of at least 256 bytes (absolute value of data content change))
- near the class content contribution average (a value of at least 1kiB)
- no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements
- adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
- content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
- no contributions, co-efficient is 0.50
- less than minimum contributions is 0.75
- met minimum contribution threshold is 1.00
Additionally
- Solutions not abiding by spirit of project will be subject to a 50% overall deduction
- Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
- Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
- Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction