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.
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-controlled 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 deciding to use the Arduino we had to do some research on the functionality. We knew how to use the AT Mega, but wanted to use Arduino because the sensor kit we bought had Arduinos and had better example. The sensor kit bought was:
The overall architecture of the project started with the three different sides of the “box”. The sides were a temperature sensor, game side, and ultrasonic sensor. The temperature sensor had the sensor being read by the Arduino with the fan to cool down an area was controlled by the AT Mega. This was done through simple digital IO pins that would be High on Arduino to the ATMEGA and low from the Arduino to AT mega if the temperature is less than 75 degrees Fahrenheit.
The other two components were controlled by an individual independent Arduino. The Arduino used a similar methodology controlling a QAPASS LCD display to ask questions. We used a random number functions in Arduino to create random math operations with a random number form 0 to ten with a math operations to 0 to ten random number. The program would call those two random numbers and create a random value leading to ask the user to click a button yes or no if it is correct. If it is correct, it will keep a continuous toll of what is correct and what is incorrect until the user resets the Arduino.
The last function of the Arduino is controlling a ultrasonic sensor and lighting a LED if the sensor in less than 6 inches. Simple Arduino function reading allowed for a conversion from time to distance allowing for a quick analog reading for the value. This allows for a major foundation and great control of a simple sensor. Using a 100k ohm resistor, a blue LED was powered to indicate that the distance detected was less than 6 inches saying something is nearby.
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 master board to various slave boards. Here is our schematic of the lighting display.
In a broad description, I2C protocol allows for a master board to communicate to slaves in the form of read and write requests. Each slave 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 slave on the bus then automatically acknowledges the master with an acknowledge bit. Then the master loads a slave address into the TWI data register and then sends that onto the data line. If a slave has an address that matches, that slave sends an acknowledge bit. Then the master would load a data byte into the TWI data register, followed by send that byte onto the data bus. This data is then loaded by the target slave into it’s own TWI data register. The master then can repeatedly send data bytes to same address, send another start command to specify a new slave 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 slave address, you could connect that many boards/chips/sensors, greatly expanding the capabilities of the chip utilizing only two pins. It also is able to support multiple masters on a single data bus. Finally, the communication requires little resources from the slave board especially during a master to slave 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 slave 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.