Microwave Simulator

NOTE: The code for this project (with the exception of the standard header files) can be found here: https://github.com/Echoskope/Microwave-Controller

Final REPORT

FOR

ENGR 3613

MICROPROCESSORS AND LAB

Microwave Oven Controller

University of Central Oklahoma

April 27th 2012

Baker, Andrew

Galloway, John

 

 

Section 1.1 Project Objectives and Introduction

The purpose of this project is to develop, test, and execute code for the Dragon12 Plus USB development board. The code will perform the functions of a typical microwave oven, including printing output to the user interface screen, accepting user input via the on board keypad, and displaying the remaining time as the system counts down. The project requires the system to accept the following type of inputs:

If “A” is pressed, the Graphical User Interface (GUI) must display “Popcorn” and immediately set the timer to 1 minute, then start counting down.

If “B” is pressed, the GUI must display “Beef Weight?” and then wait for user input. The system will then perform mathematical operations to calculate the appropriate time to cook the meat, display the weight for 2 seconds on the 7 segment LED, and clear the LCD. The timer will then be set and start to count down.

If “C” is pressed, the GUI must display “Chicken Weight?” and then wait for user input. The system will then perform mathematical operations to calculate the appropriate time to cook the meat, display the weight for 2 seconds on the 7 segment LED, and clear the LCD. The timer will then be set and start to count down.

If “D” is pressed, the GUI must display “Cooking Time?” and then wait for user input. Once the system receives the input it will clear the LCD and the system will then start counting down once the user confirms the time.

If at any time the user presses an invalid key, the GUI will display “Err” and return to the previous function.

Section 2.1 Equipment 

We were provided a Dragon 12+ USB HCS12 Freescale development board, and the Code Warrior IDE software. All components needed to perform the tasks stated in Section 1.1 are included on the Dragon12+ USB board.

 

Section 3.1 Algorithms and Flow Charts

The following flow charts show the code logic flow.

Figure_1

Figure 1: Overall program flowchart

 

Figure_2

Figure 2: Time Request Flowchart

 

Figure_3

Figure 3: User Input Flowchart

 

Figure_4

Figure 4: Simplified Data Interpretation

 

Figure_5

Figure 5: Countdown Timer Process

 

Section 3.2 Flowchart Breakdown

Figure 1 is the flowchart for the overall code process for the program. After a power cycle or reset condition, the first thing the program does is clear the LCD display. This ensures that all remaining characters from the LCD are gone and we will have a clean GUI. Once that code has executed, the I2C firmware takes over, communicating with the on board Real Time Clock (RTC) to extract the current time. The I2C communication firmware was modeled after software I2C that was coded for a Microchip PIC microcontroller. The datasheet for the RTC was needed in order to discover the address of the RTC along with what it expects from the microcontroller in order to return the correct information. Once the information has been transferred back into the microcontroller, the firmware then pushes the information out to the 7-segment display, and then enters a while loop. During the execution of the while loop the program checks the keypad to see if any key is pressed. If A, B, C, or D is pressed it then forwards the information over to another function that displays the appropriate information on the GUI. If a key is pressed that is not A, B, C, or D, the GUI will display “Err” for 2 seconds after the initial key press, and then restart the loop. If no key is pressed the time information is again extracted from the RTC and the 7-segment is updated to the most current time. Once the correct GUI is set, the firmware waits for user input, again checking to make sure the input is valid. If the user presses SW1 and SW2 at the same time, the code proceeds to the countdown section and starts the timer.

Figure 2 shows the I2C process for reading in the RTC information. This process is, for the most part, standard of any I2C communication. It starts out by initiating a start condition on the I2C lines. The code then clocks out 0xD0 on the data line, which is the address of the chip for write mode. Once the RTC has acknowledged the data transfer was a success, the code then clocks out 0x01, which sets the pointer within the RTC to the “seconds” register. The code then issues a stop command on the bus, quickly followed by an additional start command. Another 8 bits are clocked out of the microcontroller, 0xD1, which is the address of the RTC in read state. Once the RTC again acknowledges, the microcontroller oscillates the clock line, while the RTC oscillates the data line, according to the information that needs to be transferred back to the microcontroller. After 8 bits of received data, the microcontroller then must issue its own acknowledge command, so the RTC knows the transmission was a success. Finally after the time has been received, the microcontroller issues a stop condition, ending transmission and freeing up the I2C bus lines for other communications.

Figure 3 shows the process that is taken when user input is requested. Once the function is called to get user input, the code checks for the returned value. If the returned value is -1, representing no key has been pressed, the code calls to the function again. If a value other than -1 is received, the pressed key is stored into a variable, and the code calls the function again, this time waiting for the returned value to be -1 before proceeding. The reason we wrote the code this way was to prevent the code from assuming that the button was pressed multiple times, and forcing the code to wait until the button was released before going on with performing other tasks.

Figure 4 shows the Simplified Data Interpretation flowchart.  When A is pressed this is the simplest process.  It needs no other user input it simply writes “Popcorn” to the display, hardcodes the time and enters the countdown timer process.  However, B, C, and D use a different approach.  All of these modes need a user input to continue on.  For each case the LCD will print a particular string. B uses “Beef Weight?”, C uses “Chicken Weight?”, and D uses “Cooking Time”.  Then they all use the same generic code.  This code displays 0000 and waits for the user to enter time.  As the user does enters the data it is displayed in real time on the 7-segment LEDs.  If SW1 and SW2 are pressed at any time then the numbers will be sent to task specific conversions.  In the case of B and C, the input array is converted into an integer number.  This integer is converted into time (in seconds) using the conversion factor given previously.  Then the seconds are converted back into the time array and sent to the countdown sequence.  For the case of D, it is already in the perfect form and the 4 element array is sent to the countdown sequence.

Figure 5 shows the countdown sequence.  The input of this sequence is an array of four elements.  This array is first converted to a single integer of seconds for convenience of counting down.  Next, seconds is used for the length of a four loop that will subtract one each time it executes.  In the for loop the seconds are converted to a 4 element array for export to the 7-segment display. This will display for a second and then the loop will start over subtracting a second.  After the for loop the LCD will be cleared and the 7-segment display will show the time and wait.

 

Section 4.1 Results

Our system performs functions set forth by the specifications given to us in the project description.  Our system also incorporates extra features, such as displaying the user input on the 7-segment LED display. We had some trouble with the I2C code functioning properly at first, but was quickly resolved by deleting the automation and modifying the port registers directly. We also had a problem with the keypad reading in multiple values with one key pressed, which was solved by implementing the code corresponding to the flow chart in Figure 3.

 

 

Section 5.1 Timeline

Our team goal was to have the project completed and fully tested by April 2nd, 2012. We met this goal early, and completed the project on March 27th, 2012.

 

Section 6.1 Conclusions

This project taught our team a great deal about creating code with good architecture.  For the first time we were faced with writing a code that had to accomplish many types of tasks in a single executable.  At first we thought we would be forced to use interrupts to complete this task.  However, we soon learned that we could complete these same tasks with commands like goto statements and while loops.  This simplified the code a great deal.  After all the simplest way to solve a problem is often the best.  This was our goal and in conclusion we feel like we achieved our goal and completed it ahead of schedule.

 

 

You can find our PowerPoint Presentation here: Final Presentation

NOTE: The code for this project (with the exception of the standard header files) can be found here: https://github.com/Echoskope/Microwave-Controller

 

 

Leave a Reply

© 2014 - Brain Overload. All Rights Reserved. Powered by Wordpress and Design by We Create Web Designs