This code was intended for an ATMega328p and was coded using Atmel Studio 7. The purpose of the code is to detect if the microcontroller gets a shock and if it does send a signal to the buzzer to let the user know the won. We accomplished this by creating a while-true loop that goes on continuously until it detects a signal from the shock sensor, that is set as an input in PIN 5 of Port B, if it detects a shock it will generate a random integer between 0 and 5. If the integer that was generated is the same as the one specified in the code, in this case a 3, it will activate and deactivate the buzzer, set as an output on PIN 5 of Port C, letting the user know if they have won or not.
The concept of this project is a carnival arm that can set off a buzzer if a user can drop a ball into a cup. The project uses two Atmega328PB boards. One board has a servo motor that that works by connecting it to ground, 5v, and to PB1. The second board is connected to a passive buzzer at 5v, ground, and PD1 as well as a shock sensor at 5v, ground and PB2.
For our teams final project, four LED candles with ATmega328P(B) boards are programmed to display a creative light show. Each candle is identically hand-built and connected to an ATmega328P or ATmega328PB microcontroller. These four devices are all then connected to a single ATmega328PB that serves as the master controller. The master board is programmed with all of the light routines and signals the individual boards to turn the LEDs on or off at different brightnesses. In order for the master controller to communicate with the slave boards, the I2C interface is utilized. The purpose of this project is to develop a simple prototype for a future, larger candlelight display that can be wirelessly programmed to display more complex light shows.
The initial goal of this project was to build a standard Alarm Clock. To do this we would have to interface with an RTC chip using the I2C interface. A RTC Chip is a real time clock that can retain time data even after the power main power has been cycled. This function is performed through the use of a small battery. Unfortunately, we were never able to find the battery needed to operate this chip. This means that we would have to approach our project differently.
This is when we came up with the idea for a sleep timer. The user could set the desired amount of time, default 8 hours, and after the time ran out the alarm would sound. After the alarm was sounded, the user could choose to snooze or let the alarm run. If the alarm runs to completion, the LCD is updated with a “report” of the time slept, including snoozes. Below is a flowchart of the program:
In a portion of our code we needed to look for a button press to change a variable. To do this we used a while loop that incremented a counter when the button was not pressed and changed the value when the button was pressed. This allowed for the user to edit the value for a set amount of time and then move on to the next portion of the code. Below is the code
For our project we used the schematic from Lab 4 and then added on to it. The piezo buzzer took a while for us to integrate because we weren’t sending the correct waveform from PC0. In the end we used a waveform of 75ms at 2khz.
The goal of this project was to create a smart house that could be controlled using a smartphone, which was achieved using Assembly, C, and Arduino Languages. In this project both the Atmega328PB and Arduino Uno R3 boards were used in conjunction. This was done to show how different languages can be used alongside each other by connecting inputs and outputs. The Arduino was used to connect our circuit to an app via Bluetooth to control the lights and door lock of the house. The ATmega328PB board was used along with an LCD to display when the door was locked or unlocked.
We wrote code for the project for both the Atmel Xplained board in Atmel Studio and an Arduino Uno (has the same processor as the Xplained Board). Originally, the Arduino was used just for proof-of-concept testing and for a user friendly testing platform to iron out any unforeseen kinks with the program flow or mathematical computations. Once that was completed, development switched to Atmel Xplained board. The end functionality of the code written for both boards is fairly comparable except for the speedometer module. A critical component to the speed calculation is the elapsed time between the voltage drops of the Hall effect sensor. For the Arduino Uno this was no problem as an external clock source separate from the Atmega 328p is integrated into the board. In addition to build in functions that make interfacing with the clock extremely easy. On the other hand, the Atmel Xplained board has no external clock source. So all timing had to be done utilizing timers based off the CPU clock speed. Overall, this created a more complex piece of code with worse functionality.
The basis of the project was to utilize Inter-Integrated Circuit (I2C) protocol to send lighting animation commands from a central control board to other boards. Here is our schematic of the lighting display.
In a broad description, I2C protocol allows for a master board to communicate to other boards in the form of read and write requests. Each of these boards can be assigned a unique address, allowing for the master to specify destinations for its commands. This protocol requires the use of inbuilt hardware, specifically the Twin Wire Interface (TWI) module on the atmel328p, to operate.
The above figure and following paragraph describes an ideal master to slave write transmission. First the master would send a start command onto the data bus. Each board on the bus then automatically acknowledges the master with an acknowledge bit. Then the master loads one of the boards’ address into the TWI data register and then sends that onto the data line. If a board has an address that matches, that board sends an acknowledge bit. Then the master would load a data byte into the TWI data register, followed by sending that byte onto the data bus. This data is then loaded by the target board into its own TWI data register. The master then can repeatedly send data bytes to same address, send another start command to specify a new board address, or send a stop command to relinquish control of the data bus.
Being able to utilize I2C protocol can be extremely powerful in the right circumstances. Certain sensors rely on I2C protocol. And given that a single bus can support up to 127 boards, you could connect that many chips or sensors, greatly expanding the capabilities of the central board with only two pins. It also is able to support multiple masters on a single data bus. Finally, the communication requires little resources from the sensor boards especially during a master write demonstrated above.
I2C does have its drawbacks. It is meant for communication between chips on the same board. Trying to communicate on a data bus longer than 2-3 feet results in misreads. The protocol does have an in-depth description within the data sheet, but when trying to implement we faced a lot of issues with the sensor board not sending acknowledgement bits.
If you want to learn more about how to implement I2C in your project, first check out a tutorial to wrap your head around the protocol. Then consult the documentation for your board to gain a specific understanding of I2C protocol for your board. It should be located under Twin Wire Interface (TWI). Your micro controller may even have multiple TWI modules, like the atmel328pb. Then I would recommend checking out this library to help with implementing your own I2C functions.
This is the schematic of the LED maze. The implementation of the shift registers can be seen here. 3 inputs are passed to each shift register: clock, clear, and serial data in. Serial data in is used to decide which LED to activate, by using a binary representation of which LED to light. To light the 2nd and 5th led, for example, 01001000 will be passed to the serial in. Then,the clock is used to shift the serial data to it’s required position on each clock pulse. This is what results in the very dim LEDs showing up, as they are actually turning on for an extremely small amount of time compared to the LEDs that are meant to be on. Then finally, clear is used to make LEDs turn off again. This cycle repeats fast enough so that the LEDs meant to be on appear constantly on, and the other LEDs appear off (or are actually off).
This combination of inputs allows the control of each individual LED within the maze.