| links | |
|
[home] [high level design] [task distribution] [hardware design] [software design] [design results] [conclusions] [media] [links] |
The Automated Beverage DispenserTeam Members:Michael Everhart David Castellani Software design: Many critical features of our design were handled in software or were handled using the built-in hardware of the MPC823. They are detailed below: 1) Real Time Clock (RTC): The RTC was used to generate once per second interrupts. Every time the RTC interrupted the processor, we checked to see if a cup had been inserted. If there was no cup present, the main code resumed executing. When a cup was inserted, the status bits were updated accordingly, and the sonic ranger was signaled to check the liquid level. On each subsequent interrupt, the sonic ranger was signaled to theck the liquid level, resulting in a check of the level approximately every second. 2) Timers 1 and 2: Though configured differently and responsible for different devices, the purpose of both timers was to generate the PWM signal needed to drive the two control servos. During each interrupt for a given timer, the timer was reconfigured to interrupt at a different interval, depending on whether the signal needed to be high or low, and what position the servo needed to be in. By alternating between two different timer durations, a PWM signal could be generated that would hold the servo in a fixed position. When the position of the servo needed to be changed, the active-high duration of the timer was adjusted. 3) External IRQ 1: IRQ1 was connected to the control module for the sonic ranger. When the data register on the Xilinx board had been updated with a new value from the sonic ranger, the processor was interrupted and the liquid level was read from the control register. The interrupt code then adjusted the position of the cup accordingly, and ended the cycle (and closed the valve) when the cup was full. 4) External IRQ 7: IRQ7 was connected to the delay timer for the character display. As noted in the hardware section, we could not read the status bit from the display, and instead waited an appropriate time before sending the next part of the data. The interrupts from the delay timer were used to increment a software counter, and when the appropriate value had been reached, the next data segment was sent. Code Overview: Our code was primarily interrupt driven, and as such is very difficult to diagram with a flow chart. The basic flow of execution was: Initialize the registers for interrupts, timers, RTC, etc -> Initialize the display -> Write the initial data to the display -> (Loop) Update the display if instructed to do so by the interrupt code. Once in the final loop, the code would continuously check to see if a display update was needed. If it was, the display was updated. If not, the code would continue to loop. All of the interrupts to the code are as described above. All material copyright 2005 Michael Everhart and David Castellani. |