In general we learned a lot in this class. The overall ability to use the AT Mega 328PB allowed us to understand another embedded system of an Arduino. This ability to focus on what is needed, as we already learned how to effectively program one board, helped us quickly and effectively solve the other board. Not only did we do one board, but we did two Arduino board integration with the AT Mega to solve the problem we had at hand. A more powerful micro-controller was needed as we ran out of IO pins on the Arduino, but the foundation would be the same if we switched to a PI or used a more detailed AT mega board with larger IO Pins. The foundation of Assembly in this source built the code awareness to understand libraries and even begin able to make our own on our computer to effectively create a unique system or objects.
The code used in the Arduino outlet was not overly complicated as the foundations were similar except with a different IDE and the C programming was easier to use. The ATmega was used as a motor controlled allowing for a simple call then react(slave action) operation for us to effectively use a motor to cool an area that was above the ambient conditions in the surrounding area per the DHT temperature sensor.
Lastly, the project gave us the ability to start from scratch of an embedded system. We created the functions of needing a temperature sensor/motor to cool, LCD to play a game with buttons, and a ultrasonic sensor to say if something was nearby. We used our resources to determine we needed a micro-controller as all of the sensors were able to have built or easily updated libraries in Arduino. The functionality was built like the rest of our projects as we integrated with the AT mega as a motor controller to help finalize our last task and communicate through a simple slave operation. More detailed communication of serial or I2C may have been optimal, but for our functionality and timing requirements, it was not needed.
In starting this project we wanted to achieve a higher learning of smart controls for the business and home. The Fun Box we developed had 3 separate stations of controls. The first station consisted of a temperature sensor that would activate a fan once a desired temperature was sensed. The second controls consisted of a LCD screen and two push buttons. The screen was a gaming console with preprogrammed trivia questions and answers. The last station of controls consisted of an optic sensor and a light. It was to represent the auto light controls that many commercial applications and some residential home incorporate today for energy efficiency.
The controls and micro controllers we used were interesting to learn about. The mentioned optic sensor was an HC-SR04 ultrasonic Sensor. It used sonar technology to determine distance to an object similar to how bats perceive distance. It’s ranges were from 1” to 13 feet depending on how we programmed it. To better explain though the sensor sends out sound waves from the transmitter and when these sound waves bounce back after making contact with an object; the distance is easily calculated by the amount of time that process happens. The next control we used was the DHT11 Temperature and Humidity Sensor. This sensor ranges from -32 to 122 degrees Fahrenheit. It can be used for a variety of reasons depending on the programming application. The other controls used were a fan(DC motor acting as a fan), an LCD screen, 2 Arduino Uno microcontrollers, and the AT mega 328PB microcontroller.
The two arduinos were used to control the overall projects of game sensor and ultrasonic sensor. The AT Mega was used to control the fan and LED’s while the Ardunos were used for the brain of the temperature sensor. The Arduinos were originally used to communicate using Serial, but to simplify the process we used a simple IO port that would be high if the LED and motor needed to be turned on and low if they needed to be low.
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.
We planned to use the I2C interface to serve as a means of communication for each candle. Two data lines are used: a clock line and and data line. These two line are shared with every device including the master and slave boards. The master board can request to write or read data to each slave board. The signal consists of multiple sets of two bytes of date. The first seven bits in the first byte is the address of the slave board that is being addressed. The last bit is signaling whether it is requesting for the following data to be written or read. The second byte is the data the master is trying send. If the slave successfully received the data bit then it will send an acknowledgment bit to the master board.
We ran in to difficulties trying to simultaneously interface with P and PB variant boards because they require different address name schemes.
For the Hardware portion of the prototype, we used a variety of objects.The largest of these was a standard bicycle that we used as a base for the odometer and the speedometer to sit upon. Next we used two breadboards to start, however this was later slimed to one breadboard to hold the wiring and transistors for the project. We also used an ATMEGA328P Xplained mini board to process the inputs and outputs we needed for the project. Miscellaneous electrical components include some resistors, wires, potentiometer, an LED display and a capacitor. The most unique component used would be the Hall effect sensor, which is in layman’s term a magnet sensor. As a magnetic field gets in range of the sensor, the total output voltage of the Hall effect will be changed due to the strength of said field.
The chosen task by Team 14 was to create a bicycle odometer & speedometer for use in everyday life. This would allow the hard working men and women of America to stop getting into accidents while calculating the velocity they are traveling with rate and distance. This could potentially save many lives and it is the honor of Team 14 to do this great work. Team 14 hoped that by creating this project, they would learn more about real world applications for the material learnt in the class. The project was performed by first creating the code for the odometer and speedometer, and next was the task of creating a stable mount for attaching the components to the bicycle itself. Lastly was field testing to guarantee it works. The equipment used by Team 14 for the project includes: A bicycle, an ATMEGA328P Xplained Mini, a Hall effect sensor, an LCD display, as well as a few miscellaneous electrical components such as resistors.
As for the technical components, the hardware was very similar to previous lab work in which we modified to obtain our project. For instance, the corresponding lab (#4) had the output be delivered to an LCD, which ours was adjusted to go to an external speakers. In addition, the major component was a “Guwoops” light sensor which helped to make the conversion.
From our project, the interesting thing about our code is how the output signals are converted into realistic musical notes. The original approach we were going to use the received signals as a corresponding output using a speakers. But, we actually decided to create a realistic version which takes in the signal and translates them into real-world musical notes; therefore that is the most interesting portion of our code. The above photo only portray the first few conversion because including more would just be repetitive. Also, all the code is a series of if statements which tells certain signals to convert to particular musical notes.