EE 477 Final Report - Purdue University
ECE 477 Final Report
Fall 2005
[pic]
Team Code Name: ____Drug Lords ______________________________ Team ID: __9___
Team Members (#1 is Team Leader):
#1: __Steven Kady_______________ Signature: ____________________ Date: _________
#2: __Clif Barnes _______________ Signature: ____________________ Date: _________
#3: __Tim Miller ________________ Signature: ____________________ Date: _________
#4: __Drew Heinrich_____________ Signature: ____________________ Date: _________
REPORT EVALUATION
|Component/Criterion |Score |Multiplier |Points |
|Abstract |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|Project Overview and Block Diagram |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Team Success Criteria/Fulfillment |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Constraint Analysis/Component Selection |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Patent Liability Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Reliability and Safety Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Ethical/Environmental Impact Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Packaging Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Schematic Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|PCB Layout Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Software Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Version 2 Changes |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|Summary and Conclusions |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
|References |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix A: Individual Contributions |0 1 2 3 4 5 6 7 8 9 10 |X 4 | |
|Appendix B: Packaging |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix C: Schematic |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix D: Top & Bottom Copper |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix E: Parts List Spreadsheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix F: Software Listing |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix G: User Manual |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Appendix H: FMECA Worksheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
|Technical Writing Style |0 1 2 3 4 5 6 7 8 9 10 |X 5 | |
|CD of Website Image and Reports/Poster |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |
| |TOTAL | |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |1 |
| 2.0 Team Success Criteria and Fulfillment |2 |
| 3.0 Constraint Analysis and Component Selection |3 |
| 4.0 Patent Liability Analysis |7 |
| 5.0 Reliability and Safety Analysis |11 |
| 6.0 Ethical and Environmental Impact Analysis |15 |
| 7.0 Packaging Design Considerations |19 |
| 8.0 Schematic Design Considerations |23 |
| 9.0 PCB Layout Design Considerations |26 |
|10.0 Software Design Considerations |28 |
|11.0 Version 2 Changes |34 |
|12.0 Summary and Conclusions |34 |
|13.0 References |36 |
|Appendix A: Individual Contributions |A-1 |
|Appendix B: Packaging |B-1 |
|Appendix C: Schematic |C-1 |
|Appendix D: PCB Layout Top and Bottom Copper |D-1 |
|Appendix E: Parts List Spreadsheet |E-1 |
|Appendix F: Software Listing |F-1 |
|Appendix G: User Manual |G-1 |
|Appendix H: FMECA Worksheet |H-1 |
Abstract
This is the final report for Team 9, the Drug Lords. The project is the Pill Dispenser Deluxe, an automated pill dispensing system that can be programmed remotely via an embedded web server or locally using an LCD and rotary pulse generator. In this report the overall project, design process and considerations, and implementation of the project are discussed.
1. Project Overview and Block Diagram
The Pill Dispenser Deluxe is a pill dispensing system that delivers pills based on a programmable schedule. The schedule can be programmed and monitored remotely via an on board web server. A log file is viewable in the web page to alert a caregiver whether the pills were dispensed correctly and whether they were taken. The Pill Dispenser Deluxe can also be programmed locally using the LCD and the rotary pulse generator located on the front of the device.
Figure 1-1. Block Diagram
[pic]
Figure 1-2. Picture of Completed Project
2. Team Success Criteria and Fulfillment
Listed below are the five project-specific success criteria defined by the team (and refined by the course staff), as well as brief description of the successful completion of each.
1.) Ability to dispense pills at specifically programmed times and/or intervals (programming can be done locally using a keypad/RPG, or remotely via an embedded web server).
The project can dispense pills according to its programmed schedule. The schedule can be modified locally using the RPG and LCD, or remotely via HTML forms hosted by the embedded web server.
2.) Ability to dispense pills by rotating an aperture to a specified (absolute) angular position (using a stepper motor equipped with position encoder feedback).
The project has the ability to dispense pills by rotating an aperture. The aperture is rotated to a specified relative position using a stepper motor and IR photo sensor feedback. The carousel is stopped once one of the dividers blocks the photo sensor, so error is not accumulated, as would normally be the case with relative positioning.
3.) Ability to sense release of pills (e.g., using IR LED/photo sensor pairs) and update (remotely viewable) status log accordingly.
An IR photo sensor is installed in the tray where pills are dispensed. A procedure checks this sensor every time the motors are run. Based on the state of this sensor, it is determined whether or not a pill was dispensed, and an appropriate message is recorded into the log file which is viewable over the web interface.
4.) Ability to display system status locally on an LCD (information such as month/date/time, pill doses remaining, etc.
An 8x2 character LCD displays the current day and time, pill doses remaining, as well as options and the current dispensing schedule.
5.) Ability to continue operation in the event of A.C. power failure (battery backup).
Four standard "D-Cell" batteries are used to power the device in the event of a power failure. The device is fully operational when running off of the batteries, including motor, LCD, and Ethernet operation.
Constraint Analysis and Component Selection
The goal of this design project is to create a programmable, automated pill dispensing unit. The unit will be capable of dispensing pills on a user-defined schedule, and will have an Ethernet interface and an embedded web server so that it can be programmed from a web interface. Due to the possible safety issues that could arise if the unit does not perform its function properly or on time, an accurate timing system, sensors to detect system failure, and power backups are all needed.
Computation Requirements:
The computation requirements for this project are not all that great, due to the nature of the design. The microcontroller only needs to control an LCD, several sensors, and a motor, in addition to running an embedded web-server. However, the device must interface with Ethernet, which requires that that the microcontroller have certain interfaces.
Processing Power
The pill dispensing device will not have special ALU or data bus width requirements, as it is not performing any computationally intensive algorithms. Therefore, any microcontroller with a data bus of 8 bits or greater should perform acceptably. There are no plans for memory expansion, as both chips being considered have sufficient onboard memory for a small embedded web server. The design does not require a great deal of processing power, so the chip used will be clocked down for power consumption purposes.
On-chip peripherals
The Pill Dispenser needs to correctly dispense pills at precise times, based upon a user-defined schedule. Therefore, an on-chip Timer Module is required so that an accurate clock can be maintained. As the Pill Dispenser needs to host an embedded web-server, and interface with the internet, an on-chip Ethernet controller is also desired.
Interface Requirements:
The Pill Dispenser needs to interface with several sensors and buttons, as well as an LCD and two motors, and requires sufficient I/O pins for each. Five input pins will be needed for infra-red sensors, which are used to determine how full the pill dispensers are, and whether or not the pills have been successful dispensed and taken. Ten output pins will be required for interfacing with the LCD [1] which has a parallel interface. If necessary, a data shift register can be implemented in a PLD to reduce the number of pins required for the LCD interface. Four output pins will be required for controlling motors on the device. An estimated 8 pins will be needed for the Ethernet interface. Four pins will be needed for a rotary pulse encoder, and four pins for use with determining the position of the motors. The estimated total number of I/O pins is 34 pins.
Power Supply Constraints:
Due to the safety concerns that can arise from not taking pills at the proper time, the Pill Dispenser must be able to continue working properly in the case of a power loss. This necessitates a battery backup of some sort. A 6V wall wart will be used to supply power to the system, with a battery backup of 4 D-cell batteries. In order to use an Ethernet port, neither processor being considered can be clocked down. Both microprocessors being considered have a 3.3V operating voltage [2][3], while the motors being considered, as well as many digital components, run at 5 volts [5]. Because both 3.3V and 5V systems are used, two voltage regulators will be needed to supply both voltages. The voltage regulators need to be efficient, due to the battery backup. Some noise can be tolerated, however, due to the lack of sensitive analog components. Because of this, a Low Dropout Linear Regulator will be employed.
Packaging Constraints:
The Pill Dispenser is intended to be a desktop device that is not moved regularly, hence size and weight are not major issues for the packaging of the device. Because the system could possibly be used in a health critical situation, however, the security of the device is important. The device consequently needs to be built in a relatively sturdy fashion, so that day-to-day use of the dispenser will not rapidly cause system failure. Likewise, the device may be used in a situation where the user is not capable of properly loading medicine into the dispenser, and so a way of keeping unauthorized people from accessing the pill dispensing trays is needed. With this in mind, the device will be constructed out of a sturdy plastic material, of a neutral color. The device will be built in a roughly box-like shape, and will have a receiving ramp/tray to route and hold pills that are dispensed. To ensure that unauthorized personnel do not improperly load the device, a lock will be employed on the pill dispensing trays. The device will have an Ethernet cable jack, so that it can be interfaced with a network, as well as several push buttons and a rotary pulse generator for human interface purposes. A 8x2 character LCD will be attached to the device for displaying system information. A wall-wart style power supply will be used to reduce the amount of required internal space for the device.
Cost Constraints:
The Pill Dispenser prototype’s estimated total cost for major electrical components is $83.82, under the target budget of $150. With packaging and other components, it is estimated that the final cost of the project will be approximately $200. If the product were to go into mass production, many of these extra costs will be considerably less. Likewise, the total cost of the major electrical components would drop due to quantity purchases to $45.77, plus the cost of PCB manufacturing. This would bring the price down to around $100-$150 dollars for the finished product, assuming no changes to design or high additional production costs, which is an acceptable price for this type of product.
Rational for Component Selection:
Two candidate microcontrollers have been chosen for the Pill Dispenser. One is the Freescale MC9S12NE64 microcontroller, the other is the Rabbit 3000 microcontroller. These components were chosen for several reasons. The primary reason is the need to interface with an Ethernet network so that an embedded web-server can be hosted. An on-chip Ethernet controller is therefore required, and both of these chips provide this. A large number of I/O pins are also required, and both of these chips have enough for the project’s purposes. Processing power is not a huge concern, as the embedded web-server is the most computationally intensive part of the device, however electrical power usage is a concern, as the device needs to be capable of running on a battery backup. Both microcontrollers being considered have an operating voltage of 3.3 volts, making both chips good choices [2][3]. The MC9S12NE64 is the preferred choice, as the design team is familiar with the architecture, and would not have to deal with the Rabbit microprocessor’s proprietary C libraries. Also, the MC9S12NE64 has an onboard Ethernet controller, meaning that a module would not have to be used to get Ethernet connectivity.
Size, cost and operating voltages were all taken into consideration in the choosing of the stepper motors to be used with the project. The motors need to be small enough to fit easily into a desktop package. It is also preferred that the devices have low operating voltages, so that the device will be capable of running easily on battery backup. Finally, the motors need to have a relatively low cost to keep project costs down, and still provide a fine enough degree of control to be useful. The motors chosen, the 403-1001-ND and 403-1014-ND from Digi-key, both match these requirements. Both are relatively small, with the largest being 49.5 mm across [5]. Both also operate at 5V, and are relatively inexpensive at under $17.00. The 403-1014-ND is the preferred device, as it is the more precise motor of the two and would allow for more exact control of the motor.
The Liquid Crystal Displays chosen for the project were chosen based on three criteria; their cost, the amount of text that they can display, and the visibility of the displays. In order to keep project costs down, an inexpensive LCD is desired. The LCD also needs to be able to display the time and date, and in the case of user interaction, an option and the choices for that option. Lastly, the LCD must be easily visible in night and day time conditions. These requirements led to the decision to use a LCD with a parallel interface, as this lowers the cost of the device. It was also decided that the LCD must have a minimum of 8 columns and 2 lines for text display, and that it must be trans-reflective with a backlight for ease of viewing. Both LCDs chosen meet these criteria, with the HDM20416L-1-L30S having 16 columns and two lines for text display [1], while the HDM16216L-5-E30S has 20 columns and 4 lines [4]. The HDM20416L-1-L30S is the preferred device due to its lower cost, however the HDM16216L-5-E30S will be used if 16x2 is eventually deemed insufficient for text display.
The last major component chosen for the project is the rotary pulse generator, to be employed in the user interface. This component needs to, in addition to having the rotation interface, have a push button for selecting options. It also needs to be inexpensive, and since it is to be rotated by a human for menu selection, precision is not a large concern. This led to the choice of the GH6101-ND and GH3046-ND rotary pulse generators. Each has a push button interface, and both are more than precise enough for the application [6]. The GH6101-ND is the preferred component, due to its lower price.
3. Patent Liability Analysis
A thorough patent search, using the USPTO website (), yielded many results related to an pill dispensing mechanism [7]. The main keywords were “automated,” “pill,” and “dispenser.” These words yielded a large number of patents that appeared to be close to this project. Many were remarkably similar. The majority involved a microcontroller to keep track of time and date and all used a circular holding apparatus for the pills. Table 1 shows the individual patents that are similar to the project being created. Following the table is a brief summary of each of the patents being discussed.U.S. Patent Number
| |Description |
|6,304,797 |Automated medication dispenser with remote patient monitoring system |
|6,471,087 |Remote patient monitoring system with garment and automated medication dispenser |
|5,571,258 |Semi-automated medication dispenser |
|6,848,593 |Automated portable medication radial dispensing apparatus and method using a carrier tape |
|6,021,918 |Programmable dispenser for medication |
|5,720,154 |Enhanced drug dispensing system |
|6,098,835 |Child resistant pill rotating disk dispenser |
|6,581,797 |Pill dispenser with reminder |
Table 4-1. Patent Search Results
The first patent listed in Table 1 most closely matches the project being designed. That particular patent calls for an automatic pill dispenser that uses a rotating carousel to drop pills into a tray. Also, a microcontroller is utilized to keep track of time and date and determine when pills should be dispensed. Furthermore, included in the patent is the ability to connect the unit to a computer for programming. Security precautions are taken by a locking mechanism covering the receiving tray.
The second patent listed in Table 1 includes many of the same features as the first patent except for the added ability to monitor the patient. A carousel, microcontroller, and dispensing drawer are used to dispense the medication. Additionally, a garment was designed to be worn by the patient to sense vital signs in the patient. This patent was a continuation of the first patent in Table 1.
The next patent expanded upon patents that were previously awarded to this individual. The idea is a dispensing mechanism that is controlled in a hospital by a computer. The mechanism can be used for multiple patients at the same time. The nurse has to enter a password to change any settings including dose amounts and times. Also, a password is required to access the bins for inserting the medication. This patent is a very broad idea which fails to get into any of the mechanics of the operation.
Next in the table is a patent which very closely resembles the previous patents. A microcontroller also controls a radial dispensing apparatus. This particular design adds a carrier tape to be used in holding the medication. One end of the tape would connect to the other end to form a loop. This design, however, does not call for remote monitoring or any kind of display of information on the device.
The next patent is again very similar to the previous patents. The dispensing is achieved by a central motor driven disk with openings on the bottom of each compartment. Pills drop through an opening to a delivery drawer. The dispenser includes an ability to set the delivery times for the dispensing events, a timer and various signal means to indicate dispensing including flasher, voice message, and beeper, or vibrator. However, the patent does not state how the device is programmed or what is programmed.
Next in Table 1 is a patent on a product that is a little different than the others. The objective of this device is to dispense pills into vials rather than to a patient. This dispenser counts and sorts pills into vials. Then the vial is labeled using a label from a computer controlled printer.
Following the way that many patents so far have gone, the next patent adds child proofing to the same basic concept of using a rotating disk to dispense pills. The main difference in this design is the lack of programmability. No microcontroller is present and the pills must be dispensed manually. A rotating knob is used to advance the disk and dispense the needed pills.
The final patent to be analyzed is a pill dispenser that has only a reminder. The individual would be reminded that it is time to take the pills by visual or audio means. Pills are dispensed in a removable container. The individual in this case is able to program the device. It appears that this device would be used for the convenience of the individual and not as a necessity for patients who need to be reminded and to take the correct pills.
Analysis of Patent Liability
It is apparent that many patents already exist for products that are very similar to what is being designed in this project. Many people have seen the need for such a device in a hospital or house setting. With the advancement in digital design and the availability of many different microcontrollers, this type of device has become very practical.
In the case of literal infringement, the first patent in Table 1 must be analyzed first. The automatic pill dispensing mechanism being designed and the mechanism being presented in this patent are almost identical. Both have a rotating container to dispense the pills into a tray. Both have a microcontroller to keep track of the time and date. Both have the ability to program through a port connected to a computer. The only real difference between the two is the web server and the LCD screen included in the product being designed. As stated in class, simply adding to what is already patented is not enough to avoid infringement. Because of this fact, there is clearly literal infringement on this particular patent.
Literal infringement in the rest of the patents would be based mostly on the circular dispensing behavior and the programmability of the device. Since the designs for the rest of the product are not exactly the same, literal infringement would not be an issue.
Doctrine of equivalents makes the patent analysis very complex. At the most basic level, all of the patents are dispensers and most can dispense based on a schedule. However, since all were given patents, then obviously the small differences were enough to be deemed not equivalent. This current project could be seen as being very similar to the patents involving a rotating pill container that uses gravity to dispense pills into a bin. However, this idea is very general and can be seen by many as obvious. According to class, a patent has to be non-obvious, meaning that the simple dispensing apparatus would not be infringement.
A similar product that exists commercially is from ePill [8]. The MD2 Automatic Pill Dispenser interfaces with a telephone to alert caregivers of medication not being taken or running low. This product also has an LCD interface and keeps track of time and date to dispense pills. A patent number was not found on the website, but this product is an example of a product actually being made rather than just a patent. Again, there are not enough similarities to warrant infringement.
Although quite a few patents exist for similar products, most have enough differences that there would be no obvious infringement. However, one patent stands out more than all the rest. The “Automated medication dispenser with remote patient monitoring system” has the same type of dispensing apparatus, the same ability to interface with a computer, and the same monitoring system. No one could overlook the obvious literal infringement in this particular case.
Action to Avoid Infringement
Since there exists literal infringement on one of the patents, the only action would be to pay the royalty fees associated with that particular patent. The entire project would have to be redesigned in order to avoid infringement which is not an option at this point. The fact that this design has the ability to monitor how many pills remain, whether the patient has taken the pills, and the ability to program over the internet does make it somewhat unique. This project would not be infringing on any of the other patents because of the differences in programmability and monitoring. If this product needed to be made available commercially, redesign would have to occur to change enough of the project to avoid infringement.
The best way to avoid infringement, however, would be to investigate patents during the early design stages of the product. Paying royalities is usually not the best course of action. Designing around patents from the beginning assures no patent liability or lengthy court cases to decide whether or not the product can be marketed.
4. Reliability and Safety Analysis
With a product that is capable of being used in a very malicious manner, the Pill Dispenser Deluxe (PDD) needs to have safety as a number 1 priority. There are many safety issues that need to be addressed when dealing with an automated pill dispenser, accuracy of dispensing, reliability of machine, and most of all security. The PDD needs to be very secure or the user of the product can be serious injured by the medication, and possibly killed. The main components that need to be secure are the case itself and the web server. The case must be secure so no outside or unauthorized persons can gain immediate access to the medication that is stored inside of the PDD. The web server must be secure so no malicious programming can occur when it comes to the dispensing schedule.
For the reliability analysis of this device, 5 components will be chosen that are most likely to cause a critical error that could lead to personal injury. These components are: HCS12NE64CPV Microcontroller[2], the NJM2670D2 Dual H-Bridge IC[10], the MIC39101-3.3BM[9] low dropout voltage regulator, the MIC39101-5.0BM low dropout voltage regulator, and the 74LVXC3245QSC voltage translators[11]. These components were chosen for the following reasons: the microcontroller is the nerve center of the product, and holds all data, and instructions for the product to operate, the Motor Drive ICs because they are capable of drawing more amperage than the rest of the circuit, and are extremely vital to the operation of this device, The voltage translators, because they were not designed for this purpose, and are vital in operating the LCD and the motor control circuits. Below the Mean Time To Failure (MTTF) will be calculated for each of these components, as well as the predicted number of failures in 106 hours of use.. The values calculated are done so by using values and equations taken from the MIL-HDBK-217F handbook [13].
1. Microcontroller (MC9S12NE64CPV) [2]
• λp = [C1πT + C2πE]πQπL
• C1 = 0.28 (CMOS Device)
• C2 = 0.046 (112-pin Device , interpolation of data used)
• πL = 1.8 (6 month production period)
• πQ = 10 (Commercial)
• πE = 0.5 (Ground, Benign)
• πT = 3.1 (TJ = 125° C MAX)
λp = [0.28(3.1)+0.046(0.5)](10)(1.8)
λp = 16.038
MTTF = 1/ λp
MTTF = 6.2 e-03
2. Motor Control Voltage Translator [11]
• λp = [C1πT + C2πE]πQπL
• C1 = 0.0025 (Less than 100 Gates in chip)
• C2 = 0.0087 (24-pin Device)
• πL = 1.8 (6 month production period)
• πQ = 10 (Commercial)
• πE = 0.5 (Ground, Benign)
• πT = 0.96 (TJ = 85° C MAX)
λp = [0.0025(0.96)+0.0087(0.5)](10)(1.8)
λp = 1.215e-01
MTTF = 1/ λp
MTTF = 8.23
3. 3.3 Volt LDO Voltage Regulator (MIC39101) [9]
• λp = [C1πT + C2πE]πQπL
• C1 = 0.010 (Less than 100 transistors in chip)
• C2 = 0.0026 (8-pin Device)
• πL = 1.8 (6 month production period)
• πQ = 10 (Commercial)
• πE = 0.5 (Ground, Benign)
• πT = 58 (TJ = 125° C MAX)
λp = [0.010(58)+0.0026(0.5)](10)(1.8)
λp = 10.4634
MTTF = 1/ λp
MTTF = 9.56e-03
4. 5.0 Volt LDO Voltage Regulator (MIC39101) [9]
• λp = [C1πT + C2πE]πQπL
• C1 = 0.010 (Less than 100 transistors in chip)
• C2 = 0.0026 (8-pin Device)
• πL = 1.8 (6 month production period)
• πQ = 10 (Commercial)
• πE = 0.5 (Ground, Benign)
• πT = 58 (TJ = 125° C MAX)
λp = [0.010(58)+0.0026(0.5)](10)(1.8)
λp = 10.4634
MTTF = 1/ λp
MTTF = 9.56e-03
5. Dual H-Bridge IC [10]
• λp = [C1πT + C2πE]πQπL
• C1 = 0.010 (Less than 100 transistors in chip)
• C2 = 0.0096 (22-pin Device)
• πL = 1.8 (6 month production period)
• πQ = 10 (Commercial)
• πE = 0.5 (Ground, Benign)
• πT = 0.49 (TJ = 45° C)
λp = [0.010(0.49)+0.0096(0.5)](10)(1.8)
λp = 1.7e-01
MTTF = 1/ λp
MTTF = 5.72738
As per the analysis above, it is seen that the microcontroller and the LDO voltage regulators are well above the failure rate of 10-9 that would constitute an acceptable value for a product such as the PDD. The value for the microcontroller that was calculated could be skewed due to the fact that the microcontroller circuit is designed so the processor will not be run at a temperature higher than 10% of the maximum value, under normal conditions. If the microcontroller would be to a failure mode, even if the microcontroller would not be the source of failure, the processor might be run at a higher temperature that may lead to a secondary failure. The 5.0V LDO regulator is a component that may be run at a temperature that is close to the maximum under normal operating conditions. One possible solution to this temperature problem is to attach heat sinks to each of the voltage regulator to dissipate excess heat produced by the operation of the components.
Failure modes on the Pill Dispenser Deluxe can be classified into two criticality levels. These failure levels are high criticality, and low criticality. A high criticality failure would be defined as a failure that would cause direct personal injury or death to customer from using the Pill Dispenser Deluxe. A low criticality failure would be defined as a failure that would cause at most user dissatisfaction. One example of a high criticality failure would be if the motor was to be caught in an always on state, and the entire stockpile of medication would be dispensed. This failure mode may or may not be noticed right away, because the remotely viewable log may see the dispensing of the pills as a planned event. This is the reason that this product must have safety as its number one priority. One example of a low criticality failure would be if the LCD would stop functioning. Since the local programming of the schedule is a secondary programming method, the loss of the LCD would just be an inconvenience to the local user. This failure would just lead to a loss of local status, and depending on the local user, this may not even be noticed until the primary caregiver would return to refill the pills.
A complete list of failures and the level of criticality can be seen in Appendix H: FEMCA Worksheet. For simplicity’s sake, the design of the product will be broken down into functional blocks. These functional blocks are designated as: (A) Power Supply, (B) Microcontroller Circuit, (C) Motor Control/Drive, (D) User Interface, and (E) Sensors. A failure having a high criticality will be designated as a failure having an acceptable failure rate of 10-9, and a low criticality would be defined as one having an acceptable failure rate of 10-6.
As per some of the failures in the FEMCA chart, there are many ways to improve the reliability of the product. To improve the reliability of the power supply circuit, the flag pin on the LDO voltage regulator could be used in case there is an error in the voltage output. As for the motor position, a stepper motor with absolute position feedback so the software could see and monitor the dispensing mechanism more accurately. The major safety issue is the security of the machine. A lock should be installed so the local user can not access the pills inside the machine, and the website should implement some sort of security.
.
5. Ethical and Environmental Impact Analysis
As an ethical and responsible engineer, when designing any product, it is important to consider the impacts that it may have on its users and the world around us, both in normal use, and when misused [17]. Before releasing a product onto the market, every care must be taken to ensure that it is safe for the user, that the user is warned of any potential dangers involved with using the product, and that the product is as environmentally-friendly as possible. Because the purpose of this product is basically to take over one function that a human caregiver would normally perform, it must be especially reliable.
When designing a product of this nature, one must address some very serious ethical issues, as (sick) peoples' health, and indeed, their very lives, may be dependent on the product. In addition, as with all electronic products, care must be taken to ensure that the product has minimal negative effects on the environment throughout its life cycle, from manufacturing processes, to normal use, to disposal. All of these concerns will be addressed in the report below.
Ethical Impact Analysis
When designing a new product that is to be marketed to the masses, it is extremely important to consider the product's potential for harming the user, both for liability, and ethical reasons. Extreme care must be exercised to ensure that the product will not cause injury, death, or other harm to its users.
The risk of harm to users is especially great when dealing with a product of this nature (a pill dispenser). Obviously, serious medical problems can result when doses of medication are missed, when medications are taken in the wrong combinations, when medication is taken by someone other than the person to whom it was prescribed, and when medications are taken in larger doses than prescribed [18].
Because of the potentially grave consequences that can result from the misuse of this pill dispenser, it is absolutely imperative that all potential hazards presented by the product are adequately addressed. After careful thought, the following specific ethical considerations were identified, along with a potential solution to each:
* The pill dispenser should not be used in cases where missing a dose could result in death or serious medical problems.
No electronic appliance is 100% reliable. Also, even when this appliance is working correctly, and dispensing medication, it cannot force a person to actually take the medication. For these reasons, the packaging, documentation, and advertising for the pill dispenser will clearly state that it should not be used in situations where missing a dose of medication could result in serious medical consequences. In these situations, the administration of medicine should be supervised by a human being.
* Removal of medication from the device should be very difficult for those not authorized to do so.
When dealing with prescription medication, it important to ensure that it is used only by the person to whom it was prescribed. In particular, children should not be able to easily access prescription medications. In response to this concern, a lock will be placed on the lid of the device to prevent unauthorized access.
* Under no circumstances should the pill dispenser dispense medication when it has not been scheduled by the user.
Overdosing on prescription medication can result in severe medical consequences, or even death. Extensive testing under a variety of conditions will be conducted to ensure that the device dispenses medication only when it has been programmed to do so. Optical sensors will monitor and provide feedback to the dispensing mechanisms to ensure that only the intended trays are actually dispensed. In addition, software sanity checks will be performed on the schedule entered by the user to ensure that the schedule provided at least makes sense.
* Under no circumstances should the pill dispenser fail to dispense medication when it has been scheduled by the user.
For obvious reasons, it is absolutely unacceptable for the device to fail to dispense a scheduled dose of medication. The product makes use of a battery backup in order to maintain operation in the event of a power failure. The only way to prevent this failure from happening during normal operation is by subjecting the device to rigorous testing before release, and by having several people review all critical sections of application code.
* Only those authorized to do so should be able to modify the dispensing schedule.
This ethical concern is closely related to the two listed above. Not only should the device execute the user's schedule to a “ T ”, but that schedule cannot be modified by someone other than the authorized user. This is an especially important concern when one considers that the device is programmable via the world wide web, and is intended to be connected to an always-on Internet connection. To prevent unauthorized access, username / password authentication will be required to modify the schedule via the web-interface, and can optionally be enabled for the hardware interface. User documentation will include a section emphasizing the importance of using a cryptographically secure password. Also, the HTTP web interface will not be run on the standard HTTP port (port 80).
Environmental Impact Analysis
Every year, industrial processes in the United States generate billions of tons of waste [19]. Part of being a responsible product designer (and a responsible human being) is to minimize the generation of pollution and risks to human health and the environment. Accomplishing these goals requires thought and planning not only for the manufacturing process, but for the entire life cycle of the product.
The manufacture of any electronic product is likely to bring up environmental issues. The manufacture of printed circuit boards (PCBs) involves many toxic chemicals. The traditional electrolysis copper method of producing PCBs, for example, utilizes 14 chemicals identified as possible acute health hazards, 10 chemicals identified as potential chronic health hazards, and 34 chemical products which may cause irreversible eye damage [20]. A number of newer PCB manufacturing processes aim to minimize negative impacts on the environment, by reuse of chemicals, and by entirely eliminating hazardous chemicals from steps of the process, when possible [21]. When choosing a PCB manufacturer, it is important to ascertain that they have made efforts to be environmentally friendly.
The pill dispenser poses few environmental hazards during normal use. The only environmental hazard in this stage of the product's life cycle is the backup battery. The product uses a standard 9-Volt alkaline battery for backup in the case of a power outage. Most modern alkaline batteries can be safely disposed of with normal household waste [22], but the user documentation would include a section urging users to properly dispose of these batteries once they have been removed from the product. In addition, a label could be placed on/inside the product near the battery door with a similar message.
As with all electronic products, special care must be taken in the disposal of this pill dispenser. Printed circuit boards contain lead, mercury, arsenic, and other heavy metals which can be hazardous to both people and the environment [23]. A number of technologies exist for recycling (removing metals from) PCBs. The user documentation, as well as labels on the product itself, should include warnings encouraging users to take the product to a facility which specializes in disposing of electronics, rather than throwing it out with the trash. An even better approach, if it is economically feasible, would be to offer to take the product back when the user is done with it, so that it may be properly disposed. The European Union already requires all electronic equipment manufacturers to take back equipment for recycling [24].
The device will be housed in a non-biodegradable plastic case. It seems unreasonable to expect the average user to disassemble the product to separately recycle the plastic and electronic components, so the only feasible way to recycle the plastic case would be an offer, as mentioned above, to take the product back from the user for proper disposal.
Conclusion
In conclusion, the device discussed poses few environmental concerns, mostly just those common to any product with an PCB or an LCD, but it presents significant ethical concerns. Users’ well-being is directly dependent on the operation of the device. Due to the very real possibility of harm to users, it is extremely important to ensure that the device is reliable and secure.
6. Packaging Design Considerations
The Pill Dispenser Deluxe comes packaged in a white, plastic, cube-shaped box, with an LCD, pill tray, and knob for controlling the device on the front. It makes use of two revolving carousels to dispense pills down a system of tubes to the pill tray in the device, and the carousels rest on a recessed shelf in the device with a lockable lid for security. The lid on the Pill Dispenser Deluxe is clear, allowing easy viewing of the pill compartments, making it simple to determine how many pills are left in the system. It also contains a battery backup compartment underneath that same lid, so that the system can continue to operate when power is lost.
Analysis of Similar Products:
e-pill CompuMed Pill Dispenser
[pic]
The e-pill CompuMed is an automated pill dispensing system that can automatically dispense pills up to 4 times a day[25]. It has refillable pill trays that hold a week’s supply of medication, a lockable pill chamber, and a removable tray that the medication is dispensed into. It also uses an LCD display and buttons for human interface, and has a battery backup and an audible and visible reminder that is activated when the pills are dispensed.
Discussion of packaging:
The e-pill CompuMed is a relatively compact unit, with dimensions of 7”x 6”x 11”, and weighing in at 7 pounds. It is made out of a sturdy plastic, which improves the durability of the device, and has a lock on the pill chambers, so that they can be refilled or changed only by someone with proper authorization. The transparent pill compartment is also useful, so that a visual check of the pill status can be made. The ability to hold a week’s supply of medication, with a variety of pills, is also a good packaging decision. The removable pill dispensing drawer, however, has the potential to be broken or lost. Given the dependence of the device on the drawer to determine if the pills have been taken, this would render the CompuMed useless. Likewise, the use of many buttons on the device for user interface has the potential to make usage of the device complex and difficult.
Aspects of CompuMed packaging included in Pill Dispenser Deluxe:
Like the e-pill CompuMed, the Pill Dispenser Deluxe case is made out of a sturdy plastic in a box-like shape. It is slightly larger than the CompuMed, with the dimensions of the Pill Dispenser Deluxe being 11” x 11” x 11”. The Pill dispenser also has a clear lid on top of the pill compartment so that the status of the pill trays can be ascertained, and will have a lock on the pill trays so that only someone with proper authorization can access them.
Unique Aspects of Pill Dispenser Deluxe packaging:
The Pill Dispenser Deluxe differs from the CompuMed in the arrangement of its components on the packaging, in the type of dispensing mechanisms, and in the pill receiving tray. The Pill Dispenser Deluxe uses a rotary pulse generator with a select button for human interface, in order to simplify the number of buttons that must be interacted with. More importantly, it provides an Ethernet interface so that the device can be easily programmed from the internet. The Pill Dispenser Deluxe also uses a rotating, cylindrical dispensing tray that the pills drop out of, instead of a series of trays for pills. This should simplify the mechanical aspects of the design, allowing for a lower cost. Finally, instead of a removable drawer that the pills are dispensed into, the Pill Dispenser Deluxe has an attached, open tray that the pills are dispensed into, to reduce the chances of losing or breaking a component.
e-pill MD.2 Pill Dispenser
[pic]
The e-pill MD.2 pill dispenser is an automated pill dispensing system that dispenses pre-loaded medication up to 6 times a day based upon a programmed schedule. Pills are dispensed in small solo cups, and an audible and visible reminder is activated when the medication is dispensed. The MD.2 dispenser also has a battery backup, as well as a lockable pill cabinet, and is “the size of a coffeemaker”[26].
Discussion of packaging:
The MD.2 is a very sleek, professional looking device, and is made out of a robust-looking polymer. The “coffeemaker” size is reasonable for a desktop device, and the dispensing mechanism, with the small solo cups, makes it very easy for the user to retrieve their pills and take them. The lockable pill compartment also reduces the chances of medication tampering. The dispensing mechanism that makes taking pills easy, however, also adds complexity and expense to the system. Likewise, it requires that a constant supply of solo cups be maintained for proper operation. The lack of a transparent window into the pill compartment is also a problem, as it prevents a quick visual check of the medication levels.
Aspects of MD.2 packaging included in Pill Dispenser Deluxe:
The Pill Dispenser Deluxe has a few packaging features in common with the MD.2 pill dispenser. It is made out of a sturdy, neutral colored plastic in an attempt to improve the device’s durability. It also has an LCD display and user interface easily visible on the front of the device, and will have a lockable pill cabinet to reduce the risk of medication tampering.
Unique Aspects of Pill Dispenser Deluxe packaging:
The Pill Dispenser Deluxe differs from the MD.2 system in the design and shape of the exterior casing, the pill dispensing mechanism, and in the pill receiving mechanism. The Pill Dispenser Deluxe is a large, cube-shaped device instead of the tall, cylindrical shape of the MD.2. The Pill Dispenser Deluxe also uses a different dispensing mechanism; the MD.2 dispenses pre-loaded solo-cups into a receiving ramp, while the Pill Dispenser Deluxe has rotating, cylindrical pill dispensers with pie-shaped chambers into which the pills are loaded. Finally, the Pill Dispenser deluxe makes use of a solid, attached receiving tray for the pill, as opposed to the disposable cups the MD.2 uses in an attempt to reduce mechanical complexity and operating costs.
Specifications for design of Pill Dispenser Deluxe Packaging:
The Pill Dispenser Deluxe has a box-like case, made out of plastic. Two rotating, pill dispensing carousels, and a battery backup compartment, are located in a cabinet on top of the packaging that has a hinged, transparent acrylic lid with a lock. PVC piping is used to provide paths for the pills to follow from the carousels as they are dispensed into the receiving tray. PVC piping is also used in the construction of the dispensing canisters. The receiving tray is a sloped, box shaped chamber protruding slightly from the device.
List of required Materials:
[pic]
Tooling Requirements:
The Tooling required for the Pill Dispenser Deluxe are those tools needed to modify and put together plastic sheet material, and to put together circuitry. These include:
• Soldering Iron
• Electric Saw
• Electric Drill
• Screw Driver
• Dremel Tool
Estimate of weight and cost:
The estimated weight of the unit is approximately 5 lbs, as broken down below.
• UHMW plastic sheeting: 2 lb
• Acrylic sheet: 0.5 lb
• PVC piping: 1 lb
• Motors: 1 lb
• Hinges and lock: 0.25 lb
• Electronic components: 0.25 – 0.5 lb
The estimated cost of the packaging is $34.31, and is broken down by component in the List of Required Materials.
7. Schematic Design Considerations
Microcontroller
The microcontroller that powers the PDD is the Freescale MC9S12NE64CPV. The controller is required to be clocked at 25MHz so the Ethernet controller can be run efficiently[2]. The unit runs on a 3.3VDC power supply that will be supplied through the 3.3VDC portion of the products power supply, provided by the MIC39101-3.3BM. Since the unit has to communicate with many 5VDC peripheral devices, such as the motors, and the LCD, a 3V/5V voltage translation buffer will be used in this product. The Freescale NE64 microcontroller was chosen because the processor is capable of hosting an embedded web server and communicate via the on board Ethernet controller. To accomplish communication through the TCP/IP protocol, a special magnetically isolated RJ-45 jack must be used on this product[2]. The LCD[1] is interfaced with the microcontroller through I/O Port B, pins 7-13, and I/O pins from Port J, pins 16-19. Port B on the microcontroller will serve as the data bus between the microcontroller and the LCD. Since the LCD operates on 5VDC, a 3V/5V voltage translation buffer must be used. An optical encoder rotary switch with pushbutton[6] is interfaced with the microcontroller through port pins G4-G6. This is being implanted as a method for local user interaction with the product. The motor control signals will be provided by port K, pins PK0 – PK7, and port H, pins PH1-PH4. This amount of port pins will be needed to control the motors, because there are 2 enable signals per motor, and 4 signals to energize the coils of the motor. Since the motors are being controlled by via the Dual H-Bridge ICs, and the microcontroller signals. The microcontroller will also receive input from 3 infrared sensors, 1 sensor to detect if the pills were dispensed into the dispensing bin. The other 2 will feedback when each carousel has reached a certain point, so the unit can tell where the carousel is out of startup. These sensors will be interfaced with the microcontroller using port A, pins: 77, 60-63. The microcontroller is programmed through the use of a BDM header. A diagram of the BDM header and the connections can be viewed in Appendix C: Schematic. The web server will be programmed into the SRAM on the processor, and all scheduling variables will be stored into the Flash portion of memory.
Power Supply
The unit requires 2 voltages, so the power supply must have a 3.3V, and 5V supply lines running to certain devices on the board. The microcontroller uses 3.3V, where all the peripherals such as the motor and the LCD use 5V. To create this, a 6V wall wart will be used to supply a 6VDC input to the PCB. This voltage is high enough so that the LDO regulators will function properly and output the correct voltages. To prevent voltage ripple in the input power supply a 220μF filter capacitor. Two 10μF capacitors will be used as noise reduction capacitors in the power supply circuit. The input voltage is able to be 6V because the wall wart has a regulated output, and is capable of having a 6VDC output even under load. Two MICREL39101[10] LDO regulators will be used to output a steady voltage supply, one for each respective level. Since the application of this unit is critical, and can have life threatening implications, the unit will have a battery backup, in case of AC power failure. The battery backup will be implemented using 4 standard D-Cell batteries, to create the 6VDC input voltage required by the circuit. D-Cell batteries were chosen so the product could run for a lengthy period of time in the event of an AC power failure, because it is of crucial importance for the product to have full functionality under the battery backup mode. After testing the battery backup of the system, it was found that the unit could operate for several hours normally without having to replace the batteries.
Motors
The motors required to move the dispensing carousels must have great accuracy, and must be only moved until the one and only correct chamber is above the distribution tube. To do this, very accurate stepper motors will be used. The motors[29] are from Portescap Motion, and have a step angle of 3.6o. Since the unit only has 9 chambers, the motor will perform many steps per carousel movement, and this allows for greater control and accuracy of the movement. Originally the unit was designed to have 10 slots per carousel, allowing for 10 steps per dispensing cycle. This was later changed to 9 for space constraints, and it was decided that the motor position would be monitored by a series of infrared sensors. Since the motors are bi-polar[30], and only have 2 coils, an external push-pull control circuit is needed to drive the motors correctly and accurately. This is accomplished by the use of a Dual H-Bridge IC[10]. The internal circuitry consists of 2 NPN transistors, and 2 PNP transistors. The chip also has internal flyback diodes to protect against current spikes during the coil switching process. The input signals to the dual H-bridge IC will be supplied by the microcontroller, and be buffered by a 3V/5V voltage translator.
User Interface
The user will be interfaced with the unit in two ways. These interface options are: remotely through the internet, and directly using the on board optical rotary encoder switch and pushbutton. A rotary switch was chosen for the ease of usability, since the user is not necessarily going to be the most technologically inclined person. Accessing the unit remotely will be done using the embedded web server, and the on-chip Ethernet controller. Using the Ethernet interface, the unit’s schedule will be able to be programmed remotely by an authorized individual. This is all done through the microcontroller, and implemented in software. Interfacing with the unit directly will be done using the optical rotary encoder with pushbutton[6], and the LCD[1]. The LCD is a parallel LCD, and is interfaced with the microcontroller, and will be used to display the status of the machine, the date, and time. The display will also be used to display menus, and using the rotary switch, the user can change certain settings on the unit itself.
IR Sensors
Since the application of this unit has life threatening implications, certain feedback from the peripherals to the microcontroller is necessary. Upon startup of the machine, the carousels must move to a known position to insure precise dispensing of the medications. To do this 2 IR transmitter/receiver pair[30,31] will be used , one for each carousel. Upon startup, the motor will perform a routine in which it will rotate until a tab on the top of the carousel dividers has broken the IR beam, this means that the motor has stopped at a fin, thus giving the microcontroller a known position in which to start from. Also, it is need to be known if the pills have been dispensed at the correct time, if the pills have been dispensed at an incorrect time, and if at either of these times, if the pills have been removed. This will be done by another transmitter/receiver pair of IR sensors. This sensor will be located in the dispensing bin. When broken a remotely viewable log will be updated, and the remote user can check if the local user has taken their pills at a pre-determined time. There is the option for 2 more sensors to be implemented on the product, and slots for these sensors have been integrated into the PCB, but have no actual use at this present time.
.
8. PCB Layout Design Considerations
PCB Layout Design Considerations:
In designing the PCB, consideration had to be given to a number of factors, which include: reliability, ease of debugging, mechanical stability, and size.
- Development Considerations:
In order to assist in development and debugging of the pill dispenser, the decision was made to have every pin on the microcontroller come out on a header. This allows easy access to all signals, as well as providing the option of easy fixes / modifications in future stages of development. In addition to the microcontroller headers, the stepper motors, rotary pulse generator, optical sensors, LCD, and battery are also connected to the board with headers, as this seemed the easiest and most mechanically sound way of connecting them.
The size of the board was not much of a consideration, as the target package is decent sized, and allows ample room for any size board we end up with.
- Electrical Considerations:
Special care had to be taken because of the combination of digital and analog circuitry that had to be placed on the board together. The Ethernet interface, in particular, is extremely sensitive to noise in the circuit. To minimize noise in the digital circuitry, the ground for 5 V (stepper motors) was isolated from the ground for 3.3 V (digital circuitry). In addition, as recommended in the NE64 documentation, the Ethernet transmit and receive lines were run directly beside each other.
Special care was taken to place bypass capacitors as close to the microcontroller so that they would be as effective at supplying current as possible. In most cases, the bypass capacitors are located directly beside or underneath the controller.
- Mechanical Considerations:
Thought was given to ways in which the mechanical stability and reliability of the board could be maximized. Except for resistors and capacitors (which are surface mount packages), through-hole packages of components were chosen. Through-hole components include headers, DIP packages, and diodes. The thought was that with through-hole components, much more mechanically sound connections would be made, resulting in greater reliability of the product. In addition, through-hole parts are much easier to work with than surface mount packages when debugging.
A number of the components necessary to the pill dispenser did not have footprints available in the component libraries installed with Orcad. In these cases, footprints had to be created by examining dimensions of parts and connectors available on datasheets. This situation came up with the RJ45 connector, as well as the 25 MHz oscillator necessary for Ethernet.
In summary, in designing the PCB, consideration had to be given to a number of important factors. Care was taken to minimize noise on the Ethernet interface, decoupling capacitors were placed close to the microcontroller, and a generous number of headers were included and located conveniently.
9. Software Design Considerations
1. Memory Models
The microcontroller being used in this project is the Freescale MC9S12NE64. This microcontroller contains 8k of RAM and 64k of FLASH memory [2]. Most of the software can be stored in the FLASH. About 26 KB of the FLASH is used for all of the software. However, there is not enough RAM to have the webpage run in RAM. This microcontroller has the ability to rewrite FLASH blocks to behave in a way that is similar to RAM but slower. The speed is sufficient for the webpage to run without being an annoyance to the user. Basically, everytime that the user applies the changes, the FLASH rewrites each block that contains the webpage and the new values are given to the variables controlling the schedule.
2. Memory Mapping
The memory mapping used for this design is the default memory mapping as shown below in Figure 10-1. The compiler sets up the memory mapping, so no code needs to be generated for this part. The default is sufficient because there is enough FLASH available to contain all of the code in the project. Also, the RAM is sufficient to run all of the runtime code including the interrupts and the web server.
Figure 10-1. MC9S12NE64 Memory Map [2]
3. Startup Code
The startup code is generated by CodeWarrior to initialize the stack pointer, set up memory mapping, and jump to main to start the program. Additionally, the software then loads the webpage into RAM and initializes the calender to be empty. The motor turns the carousels until each is at an initialization point which is determined by a sensor on each carousel. The clock is initialized to all zeros and the user is notified on the LCD screen, as well as the webpage, that the device has not been initialized and needs to be programmed. Notifying the user on the webpage allows a remote user to know if the device has been reset and that the pills will not be dispensed as originally scheduled.
4. Organization
The overall execution of the software will be both polled program-driven and interrupt-driven. Every second an interrupt will send the program into a state to update the clock, check the schedule, dispense pills if needed, and check that the pills made it to the receiving bin. While not in the interrupt state, the code polls the ethernet to see if any data needs to be sent, then polls the rotary pulse generator to see if the user wants to change anything locally, and finally the main loop checks the receiving bin sensor to check if the pills have been removed.
Software Narrative
The overall program is broken down into the ethernet module, the RPG module, the sensor module, and the timing and scheduling module.
The ethernet module is used to send and receive data pertaining to the webpage. This module uses the provided code for the TCP/IP stack [32]. Users connect to the ethernet module and are asked to give a user name and password. The user name and password are delivered back to the ethernet module in the URL using CGI. The user name and password are parsed from the URL and compared against the correct user name and password. If correct, the scheduling webpage is sent to the connected user. The user changes any section of the schedule and the information is again sent back in the URL. The variables are changed in the RAM according to the new schedule. When no data is needing to be sent, control is given back to the main loop.
The RPG module takes information from the rotary pulse generator that is located on the outside of the pill dispenser. The data from the RPG is sent to port pins in the microcontroller. If the user clicks the RPG, the RPG module starts a series of operations to take the user through the menu. A main menu appears first with options to change the clock, update the schedule, notify the unit of how many pills are remaining and to exit the menu. The user scrolls the RPG and pushes to select the menu item. If changing the clock is selected, rotating the RPG will change the current field, while pushing will accept the current number or day. If a schedule change is selected, the user will walk through each day and select if pills should be dispensed and at what time. The third option is used to tell the pill dispenser how many pills are remaining for the particular carousel. This number will then be decremented each time a pill is dispensed from the carousel.
The sensor module is used to determine a few things related to the dispensing of the pills. The sensors send data into port pins to determine if the there is something has activated one of the sensors. One sensor is located next to each carousel to tell whether the bins are lined up correctly so one bin is exactly over the opening. Another sensor is located in the receiving bin to determine if dispensed pills made it to the bin and that the pills were then removed. Based on the sensor in the bin, the status log on the website is updated to tell whether or not the pills were dispensed.
The timing and scheduling module keeps track of the current time and checks whether pills should be dispensed. This module utilizes the TIM modules to run an interrupt every second. This module has functions to change the current time, to increment the current time, and to check the current time against the dispensing times in the schedule. Every second an interrupt sends control to this module to increment the clock. Then the new current time is checked to see if pills should be dispensed. If it is time, then the correct carousel rotates to dispense the pill.
The motor control changes four output port pins on the microcontroller to control the motors. When the time comes to dispense a pill, the motor software goes through a state machine to switch each signal and turn the motor. When the sensor located on the carousel signals that one segment has passed, the motor stops rotating.
Software Documentation
Figure 10-2. Main Flowchart
Figure 10-3. Interrupt Flowchart
Figure 10-4. Ethernet Flowchart
10. Version 2 Changes
One of the biggest changes to make would be to make the web page more secure. Implementing SSL to send the data and to encrypt the passwords would ensure that only authorized individuals would have access to programming the device. Another enhancement would be to alter the packaging so that it is smaller and more presentable. The current pill dispenser takes up most of a desk and would definitely get in the way. Also, the box is all white with bolts sticking out of every side. A better color scheme and packaging design would make for a better looking and easier to use product.
Another change would be to increase the calendar ability of the pill dispenser. The pill dispenser is only able to keep track of seven days. A yearly calendar could be added to allow for scheduling an entire year which would make administration of the device even easier. This might be too difficult to implement on the local LCD, however, so this feature would only be implemented on the web page. The local menu could just be used for programming the current week. Along the same line, adding more capacity would help to make this a better product. If a yearly calendar was implemented, then more capacity could allow for easier administration.
Summary and Conclusions
All of the project specific success criteria were met by the due date. The web server was able to send web pages to a remote computer. The remote computer was able to change the schedule and to view the log file. The local programming was also successful. Pushing the RPG sent the user into the menu. The user could scroll through the different options and choose whether to set the time, set the schedule, or input how many pills are remaining. The battery backup successfully supplied power to the device in the event that the power cable was unplugged. The most important part, that the pills were physically dispensed also worked correctly. The pills traveled down the pipe to the receiving bin where the patient could receive the pills.
The Pill Dispenser Deluxe was an interesting and challenging project. Many things were learned in the development of this device. Some of the hard lessons learned were to start early, research, and prototype. The beginning of the project started very slowly with too little being accomplished at the beginning of the semester. This caused long nights and daily work on the project during some of the busiest weeks of the semester. More research could have saved money and time. Some parts that were ordered were never placed on the board because they were not needed. Other parts turned out to be the wrong parts and money was wasted shipping new parts overnight or second day. Prototyping could have saved a lot of time. Nothing was really tried before it was placed onto the PCB so a lot of problems were discovered when it was too late. Prototyping could have saved a lot of PCB errors and saved time later in the semester.
References
[1] Hantronix, HDM16216L-5 data sheet,
[2] Freescale Semiconductor, MC9S12NE64 datasheet,
[3] Rabbit Semiconductor, Rabbit 3000 Microprocessor,
[4] Hantronix, HDM20416L, HDM20416L-1 datasheet,
[5] Cramer Company, AC/DC Geared Motors,
[6]Grayhill, Optical Rotary Encoders series 61C,
[7]All patent information gathered from :
Patent Numbers: 6,304,797
6,471,087
5,571,258
6,848,593
6,021,918
5,720,154
6,098,835
6,581,797
[8] MD2 Automatic Pill Dispenser
[9] Micrel Inc. 39101 Data Sheet.
[10] NJR. NJM2670 Data Sheet.
[11] Fairchild Semiconductor.74LVXC3245QSC Data Sheet.
[12] US Department of Defense.MIL-HDBK-217F. December 2, 1991
[13] Novacek, George. Designing for Reliability, Maintainability, and Safety. Circuit Cellar. December 2000 pp. 68-73.
[14] Novacek, George. Designing for Reliability, Maintainability, and Safety. Circuit Cellar
January 2001 pp. 28-38.
[15] Novacek, George. A Sure Thing. Circuit Cellar. April 2001 pp. 28-35.
[16] Meyer, D.G. Module 10: Designing for Reliability, Maintainability, and Safety.
shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-mod10.pdf
[17] “Teaching Engineering Responsibility for Societal and Environmental Consequences”
[18] “Precautions in Avoiding Medication Risks”
[19] "What's Green Engineering?"
oppt/greenengineering
[20] "Connections - Design for Environment"
[21] "Pollution Prevention for Printed Circuit Board Manufacturing"
[22] "Battery Disposal"
[23] "Circuit Board Disposal"
[24] "Computer and Electronic Scrap Recycling"
[25] GigaNano, e-pill CompuMed web site, [26]
[27]
[28]
[29]Portescap Motors. 44M100D1B Stepper Motor Data Sheet.
L1=10000000&L2=10015000&L3=10100000&L4=10105000&L5=10105100&L6=1010 5101&IT=Catalogs&lang=1
[30]Fairchild Semiconductor. QEC122 Data Sheet.
[31]Fairchild Semiconductor. QSC114 Data Sheet.
[32] OpenTCP code
Appendix A: Individual Contributions
A.1 Contributions of Steven Kady:
Steven was responsible primarily for packaging and software design and development. He wrote software for the timing/scheduling of the system, worked on drivers for the motors, LCD, and rotary pulse generator, and developed the menu system used to navigate options on the unit. He also wrote the Design Constraint Analysis homework, where he laid out the constraints on the project and compared several different key parts in the design.
Steven was involved in the design of the actual packaging of the Pill Dispenser Deluxe, and wrote the packaging constraint homework. In doing the homework, he looked up several different automated pill dispensers on the market, and made an analysis of the similarities and differences between those models and the Pill Dispenser Deluxe. He also assisted in the physical construction of the unit, helping to acquire the materials and cut the plastic into the proper shapes. He then worked on drilling holes in the plastic used for construction, and placing L-brackets and bolts. Finally, he worked on mounting the internal shelf of the packaging in the unit.
Steven worked on the timing/scheduling software of the Pill Dispenser Deluxe, setting up the timer module, and developing the timer keeping functions of the unit. He set up the timer module to interrupt every millisecond, and then wrote an interrupt service routine that would count up to 1000 milliseconds, or one second, before calling a function to update the time. He also wrote this update time function, that incremented the time by one second, and if necessary incremented the minute and hour. He also wrote a function to check the current time against the scheduled dispensing times to see if it was time to dispense pills. This function was called once every second. It worked by looping through an array that held all the scheduled times, and comparing the current time to each of those scheduled times.
Steven also worked on developing the driver for LCD and motors. He assisted in setting up the port pins that needed to be used on the microcontroller, and in writing an initialization routine to set up the LCD properly. He also wrote sendstring and scopy functions that allowed strings to be sent to the LCD easily. He also worked on setting up the state machine that was needed to run the motors. The motor needed to cycle through a 4 step sequence to rotate the motors, and he helped to set this up.
Steven wrote much of the code involved in making the rotary pulse generator work, and in making the menu navigation system display properly on the LCD. He made use of a state machine that kept track of what was currently being displayed on the LCD, He wrote detection software that would listen on the input ports that the RPG connected to. If a button push was detected, his code would determine what action to carry out based upon what the current state of the LCD display was. He also wrote code for rotating through the various menus, also using a state machine. Rotating the RPG would cause the current state to increment or decrement by one, changing the text displayed on the LCD.
A.2 Contributions of Tim Miller:
Tim designed the PCB, wrote software for the web server, LCD driver, and flash memory writer, and participated in the debugging of hardware / software and construction of packaging. In addition, he wrote the Ethical / Environmental Considerations paper.
For the PCB, Tim worked closely with Drew to ensure that everything on the schematic was correct. For some of the parts to be used, OrCad did not contain appropriate footprints. Tim created or arranged to have created footprints for these parts. A lot of time was spent learning the intricacies of the layout software. After the initial revision of the layout was complete, Tim reviewed it to determine what changes and improvements could be made, as well as incorporating feedback which had been received from the course staff. The second revision turned out better, but could still be improved. He scrapped everything again and started fresh on the third and final revision of the layout. Once layout was complete, Tim submitted it for an online check to make sure it was ready for fabrication. He fixed the numerous errors returned by the online check and finally submitted the board for fabrication.
In developing the web server / interface for the project, Tim started out with an example web server provided with a Freescale application note. The example used the OpenTCP TCP/IP stack for all of the low-level networking protocols. This was a good starting point that demonstrated how to serve a web page out of flash memory, and how to get the URL requested by the remote user. Tim investigated different ways for communicating information from the user’s browser back to the web server. Java Applets were one option, but were considered to be too complicated and to consume too many resources. After some research, he settled on using CGI, which is simple to implement, lightweight, and supported by all browsers. Implementing the CGI interface was not too difficult. Tim simply wrote code that took the incoming url as an argument, and parsed out the values of any variables returned by the web page.
The project required dynamic web pages. Due to the infeasibility of dynamic memory allocation on the microcontroller, it was necessary to know the exact offsets into the HTML file that would need to be changed. To find this out, a Python script was written which reads the HTML file, and calculates the offsets of portions of the file to be changed. The Python script outputs a ‘.c’ file containing an array of bytes representing the file, and another array containing the offsets.
There was no room to store the dynamic web pages in RAM, so they would have to be stored in flash memory. Writing to flash is not a simple matter. In order to write a single word, the entire flash sector containing that word must first be erased. To do this, the flash sector being written to would first have to be backed up elsewhere, then copied back after the desired word was written. In addition, flash cannot be read while these operations are taking place (but flash is where application code is normally stored). Tim found a Freescale application note which describes how to write to flash. He modified some code provided in this note to suit the project’s purposes. The code copies a small routine onto the stack so that it does not have to read from flash to execute. This assembly routine on the stack is what actually moves the data around in flash.
Tim wrote the LCD initialization / operation code. This was relatively simple, requiring only a careful reading of the LCD’s data sheet.
Tim also participated in the physical construction of the project. He soldered some components on the board. Also, he measured, cut out, and assembled the box for the project packaging.
He also participated extensively in the debugging of both hardware and software in the later stages of the project.
A.3 Contributions of Drew Heinrich:
Since the area of expertise of Drew was Electrical Engineering and hardware design, his main role in the project was to design and debug the hardware. Since this was his role, the task of schematic design was assigned to him. He researched all the parts used, and decided in which way a certain portion of the design was to be implemented. One such example of this is the transmitter/receiver pairs of the infrared sensors. The receiver is a bipolar junction transistor, and can be implemented in 2 different methods. The method that was chosen by Drew was the implementation that when the BJT was biased, a logic low would be seen by the microcontroller pin. This was decided because a definite logic swing was needed, and since the beam would be broken for fractions of a second it was felt that this was the best method. As was stated before, the final circuit design was completed by Drew, with much of the input coming from the other group members.
Once the circuit schematic was done, parts needed to be ordered. Drew took much of this task upon himself making 50% of the entire parts order purchase. Once the PCB and all the parts came in, Drew was put in charge of populating, and testing the PCB. He soldered all the components on one functional block at a time and tested to ensure that all the components were working properly.
When a hardware problem arose, it was Drew that was in charge of debugging the problem. Many problems arose and needed to be dealt with in a very timely manner. These problems included flywiring of the power supply, the BDM circuit, the Ethernet connection, the dual H-bridge ICs, and the 3V/5V translators. This debugging sometimes was not vary obvious and took quite sometime to figure out.
Another main contribution of Drew, was in the fabrication of the final packaging. Since the packaging design was originally very precise and secure, the plan was for everyone to help in the manufacturing of the prototype. The portions of the packaging that Drew was responsible for was the fabrication of the main shelf, and cutting out holes for the LCD, and RPG out of the front. The main shelf of the unit required manufacturing of the dispensing mechanism, cutting out the dispensing holes, and fabricating the dispensing tubes. Drew also drilled and tapped out holes for the mounting of the motors.
A.4 Contributions of Clif Barnes:
Clif was primarily responsible for software design and development. He was assigned to write software having to do with the sensors, the timing/scheduling, and the web page. The sensors were used in two different places. The sensor that was located in the receiving bin was used to signal when a pill was in the bin. Clif wrote the software to read the data from the sensors and to update the web log file accordingly. If a pill had been dispensed and did not make it to the bin in ten seconds then a bad message was sent to the log. If the pill made it to the bin then a good message was sent to the log. The other sensors were located on each of the carousels. The software needed to read the information from the sensors to tell when to stop the motor from turning because one segment had passed. He was also involved in creating the state machine for the motor control. Each motor needed four lines to change in a particular order to rotate the motor. The state machine needed to walk through the order and be slow enough that the motor would turn correctly.
Clif worked on some of the design and writing of the timing/scheduling part of the software. He wrote some of the functions to handle what would happen if it was time for the motor to turn and how to turn the motor. The software needs to be able to compare the current time against all of the times in the schedule to see if it is time to dispense pills. Also, he was part of debugging and writing some of the routines to update the LCD display when a second had passed. Clif wrote the scheduling web page that is used to program the device. Twenty eight input boxed are laid out into a seven by four grid to show all of the available time slots. The user can input which times go into each slot and which carousel from which to dispense.
The homework assignments that Clif did were the Software Design Considerations and the Patent Liability Analysis. He thoroughly searched the US Patent and Trademark Office's website to try and find patents that are similar to the Pill Dispenser Deluxe. Many patents existed and needed to be analyzed. The software design homework required a lot of time planning out how the software would be organized. Flowcharts needed to be created to graphically show how the software moved through the main loop and the interrupts. Decisions needed to be made about which modules would be interrupts and which would be polled.
Clif was also involved in developing some of the packaging. He assisted in measuring, cutting and gluing together different parts of the outer casing. He also was involved in creating connectors for the sensors to connect to the PCB.
Appendix B: Packaging
[pic]
Figure B-1: To scale drawing of initial packaging concept.
[pic]
Figure B-2: Close up top view of Pill Dispenser Deluxe
[pic]
Figure B-3: Close up front view of Pill Dispenser Deluxe
[pic] [pic]
Figure B-4: Close up back view of packaging Figure B-5: Close up side view of packaging
Appendix C: Schematic
[pic]
Figure C-1 Finished Circuit Schematic
[pic]
Figure C-2: Power Supply Schematic
[pic]
Figure C-3: Motor Control Schematic
[pic]
Figure C-4: Microcontroller Circuit Schematic
[pic]
Figure C-5: Ethernet Circuit Schematic
Appendix D: PCB Layout [pic]
Figure D-1: Top Copper of PCB layout
[pic]
Figure B-2: Bottom copper of PCB layout
Appendix E: Parts List Spreadsheet
|Component |Vendor |Part Number |Unit Cost |Quantity |Total Cost |
|MC9S12NE64 microprocessor |AVNET Electronics |MC9S12NE64CPV |$13.41 |1 |$13.41 |
|Rabbit 3000 microprocessor |Rabbit Direct |668-0011 |$14.50 |1 |$14.50 |
|Stepper Motor |Digi-key |403-1001-ND |$16.20 |2 |$32.40 |
|Stepper Motor |Digi-key |403-1014-ND |$16.90 |2 |$33.80 |
|LCD |Mouser |HDM20416L-1-L30S |$16.06 |1 |$16.06 |
|LCD |Mouser |HDM16216L-5-E30S |$33.49 |1 |$33.49 |
|Rotary Pulse Generator |Digi-key |GH6101-ND |$20.55 |1 |$20.55 |
|Rotary Pulse Generator |Digi-key |GH3046-ND |$33.20 |1 |$33.20 |
Table E-1: Major Parts Considered
Appendix F: Software Listing
main.c
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Main.c – This file does all initialization, and contains the main loop of the application.
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
#include "debug.h"
#include "datatypes.h"
#include "timers.h"
#include "system.h"
#include "ethernet.h"
#include "arp.h"
#include "ip.h"
#include "tcp_ip.h"
#include "http_server.h"
#include "smtp_client.h"
#include "ne64driver.h"
#include "ne64api.h"
#include "mBuf.h"
#include "ne64config.h"
#include "address.h"
#include "MC9S12NE64.h"
#include "flash.h"
/* added by Steven 11/7*/
#include "Timer.h"
/***********************/
/* Including used modules for compiling procedure */
// Network Interface definition
struct netif localmachine;
extern void RTI_Enable (void);
extern void porth_isr_handler (void);
extern tU08 gotlink;
#if USE_SWLED
tU16 LEDcounter=0;
#endif
/***Global***/
INT16 Milliseconds = 0;
INT8 MotorTimeFlag = 0;
INT8 LCDUpdateFlag = 0;
TimerStruct CurrentTime;
ScheduleStruct ScheduleArray[28] = { {24,60},{24,60},{24,60},{24,60},
{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},
{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},
{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60},{24,60}};
INT8 RunMotorFlag = 0;
INT8 RunMotorFlag2 = 0;
INT8 DisplayState = 0;
INT8 DisplayState2 = 0;
INT8 DayNum = 0;
char *Days[7] = {"Sun","Mon","Tue","Wed","Thu","Fri","Sat"};
INT8 Hour = 0;
INT8 Minute = 0;
INT8 DispenseFlag = 0;
INT8 SinceDispense = 0;
UINT8 DisplayLevel = 0;
INT8 PillsRem1 = 0;
INT8 PillsRem2 = 0;
INT8 ScheduleNum = 0;
/***End Global***/
//============================================================
tU08 OldSwitchValue=255;
tU16 Pot=0;
tU16 OldPot=1050;
tU08 OldB1=255;
tU08 OldB2=255;
tU08 OldB3=255;
tU08 OldB4=255;
//============================================================
#pragma CODE_SEG NON_BANKED
interrupt void PortHInterrupt (void)
{
porth_isr_handler();
}
#pragma CODE_SEG DEFAULT
//============================================================
//Initialize ATD
//============================================================
void ATD_init(void)
{
ATDCTL2 = ATDCTL2_ADPU_MASK | ATDCTL2_AFFC_MASK;
ATDCTL3_S1C = 8; // 8 ch seq.
ATDCTL3_FIFO = 0; // no FIFO
ATDCTL3_FRZ = 3; // Freeze immediately in BDM
ATDCTL4 = ATDCTL4_PRS2_MASK |ATDCTL4_PRS1_MASK | ATDCTL4_PRS0_MASK;
ATDCTL4 = ATDCTL4 & ~ATDCTL4_SRES8_MASK; //10 bit
ATDCTL5 = ATDCTL5_SCAN_MASK;
}
//============================================================
/* main */
//============================================================
void main(void)
{
INT16 len;
INT8 LogFlag = 0;
INT8 ButtonFlag = 0;
INT8 rpg_pos_ret = 0;
INT8 i;
/* INT8 timDay;
INT8 timHour;
INT8 timMin;
INT8 timSec; */
/* System clock initialization */
CLKSEL=0;
CLKSEL_PLLSEL = 0; /* Select clock source from XTAL */
PLLCTL_PLLON = 0; /* Disable the PLL */
SYNR = 0; /* Set the multiplier register */
REFDV = 0; /* Set the divider register */
PLLCTL = 192;
PLLCTL_PLLON = 1; /* Enable the PLL */
while(!CRGFLG_LOCK); /* Wait */
CLKSEL_PLLSEL = 1; /* Select clock source from PLL */
INTCR_IRQEN = 0; /* Disable the IRQ interrupt. IRQ interrupt is enabled after CPU reset by default. */
/* Initialize ports for motor control output */
DDRK_BIT0 = 1;
DDRK_BIT1 = 1;
DDRK_BIT2 = 1;
DDRK_BIT3 = 1;
DDRK_BIT4 = 1;
DDRK_BIT5 = 1;
DDRK_BIT6 = 1;
DDRK_BIT7 = 1;
DDRH_DDRH1 = 1;
DDRH_DDRH2 = 1;
DDRH_DDRH3 = 1;
DDRH_DDRH4 = 1;
PORTK_BIT1 = 0;
PORTK_BIT5 = 0;
PORTK_BIT2 = 0;
PORTK_BIT0 = 0;
PORTK_BIT7 = 0;
PORTK_BIT3 = 0;
PORTK_BIT6 = 0;
PORTK_BIT4 = 1;
lcd_wait();
PORTK_BIT4 = 0;
PTH_PTH4 = 0;
PTH_PTH1 = 0;
PTH_PTH3 = 0;
PTH_PTH2 = 1;
lcd_wait();
PTH_PTH2 = 0;
/* Initialize ports for LCD */
DDRH_DDRH0 = 1;
DDRJ_DDRJ0 = 1;
DDRJ_DDRJ1 = 1;
DDRB_BIT0 = 1;
DDRB_BIT1 = 1;
DDRB_BIT2 = 1;
DDRB_BIT3 = 1;
DDRB_BIT4 = 1;
DDRB_BIT5 = 1;
DDRB_BIT6 = 1;
DDRB_BIT7 = 1;
/* Initialize ports for RPG */
DDRG = 0x00;
/* Initialize ports for sensors */
DDRA_BIT0 = 0;
DDRA_BIT1 = 0;
DDRA_BIT2 = 0;
DDRA_BIT3 = 0;
/*CurrentTime.Day = 0;
CurrentTime.Hour = 3;
CurrentTime.Minute = 0;
CurrentTime.Second = 50;
ScheduleArray[0].Hour = 3;
ScheduleArray[0].Minute = 1;
//ScheduleArray[1].Hour = 3;
//ScheduleArray[1].Minute = 2;
*/
init();
LCD_init();
//LCD_update();
demoinit();
ATD_init();
/* IP address */
localmachine.localip = *((UINT32 *)ip_address);
/* Default gateway */
localmachine.defgw = *((UINT32 *)ip_gateway);
/* Subnet mask */
mask = *((UINT32 *)ip_netmask);
/* Ethernet (MAC) address */
localmachine.localHW[0] = hard_addr[0];
localmachine.localHW[1] = hard_addr[1];
localmachine.localHW[2] = hard_addr[2];
localmachine.localHW[3] = hard_addr[3];
localmachine.localHW[4] = hard_addr[4];
localmachine.localHW[5] = hard_addr[5];
/* Init system services */
timer_pool_init();
/* Initialize all buffer descriptors */
mBufInit ();
/*interrupts can be enabled AFTER timer pool has been initialized */
/* Initialize all network layers */
EtherInit();
//Initialize required network protocols
arp_init();
(void)udp_init();
udp_demo_init();
(void)tcp_init();
(void)https_init ();
//Enable RTI
RTI_Enable ();
// setup flash to be written.
Flash_Init(25000);
/* main loop */
DisplayState = 0;
DisplayLevel = 0;
LCD_update();
RunMotorFlag = 3;
for (;;)
{
if (check_RPG_Push())
{
if (ButtonFlag == 0)
{
if (DisplayLevel == 0)
{
DisplayState = 1;
DisplayLevel = 1;
DisplayState2 = DisplayState;
LCD_update();
}
else if (DisplayState == SET_TIME_STATE)
{
DisplayState = SET_DAY_STATE;
DayNum = CurrentTime.Day;
LCD_update();
}
else if (DisplayState == EXIT_STATE)
{
DisplayState = 0;
DisplayLevel = 0;
LCD_update();
}
else if (DisplayState == SET_DAY_STATE)
{
DisplayState = SET_HOUR_STATE;
CurrentTime.Day = DayNum;
Hour = CurrentTime.Hour;
LCD_update();
}
else if (DisplayState == SET_HOUR_STATE)
{
DisplayState = SET_MIN_STATE;
CurrentTime.Hour = Hour;
Minute = CurrentTime.Minute;
LCD_update();
}
else if (DisplayState == SET_MIN_STATE)
{
DisplayState = 0;
DisplayLevel = 0;
CurrentTime.Minute = Minute;
LCD_update();
}
else if (DisplayState == SET_SCHED_STATE)
{
DisplayState = SET_SCHED2_STATE;
ScheduleNum = 0;
//DisplayLevel = 0;
LCD_update();
}
else if (DisplayState == SET_SCHED2_STATE)
{
DisplayState = SET_SCHED3_STATE;
LCD_update();
}
else if (DisplayState == SET_SCHED3_STATE)
{
DisplayState = SET_SCHED4_STATE;
LCD_update();
}
else if (DisplayState == SET_SCHED4_STATE)
{
DisplayState = 0;
DisplayLevel = 0;
LCD_update();
}
else if (DisplayState == SET_PILL1_STATE)
{
DisplayState = SET_PILL12_STATE;
LCD_update();
}
else if (DisplayState == SET_PILL2_STATE)
{
DisplayState = SET_PILL22_STATE;
//DisplayLevel = 0;
LCD_update();
}
else if (DisplayState == SET_PILL12_STATE)
{
DisplayState = 0;
DisplayLevel = 0;
LCD_update();
}
else if (DisplayState == SET_PILL22_STATE)
{
DisplayState = 0;
DisplayLevel = 0;
LCD_update();
}
}
ButtonFlag = 1;
} else
{
ButtonFlag = 0;
}
if (DisplayLevel > 0)
{
DisplayState2 = DisplayState;
if (DisplayState == SET_DAY_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DayNum = (rpg_pos_ret + DayNum);
if (DayNum < 0)
{
DayNum = 6;
}
else if (DayNum> 6)
{
DayNum = 0;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_HOUR_STATE)
{
rpg_pos_ret = check_RPG_Pos();
Hour = (rpg_pos_ret + Hour);
if (Hour < 0)
{
Hour = 23;
}
else if (Hour > 23)
{
Hour = 0;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_MIN_STATE)
{
rpg_pos_ret = check_RPG_Pos();
Minute = (rpg_pos_ret + Minute);
if (Minute < 0)
{
Minute = 59;
}
else if (Minute > 59)
{
Minute = 0;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState2 == SET_TIME_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DisplayState2 = (DisplayState2 + rpg_pos_ret);
if (DisplayState2 == 0)
{
DisplayState2 = 8;
} else if (DisplayState2 == 9)
{
DisplayState2 = 1;
}
else if (DisplayState2 == 6)
{
DisplayState2 = 3;
}
else if (DisplayState2 == 4)
{
DisplayState2 = 7;
}
if (rpg_pos_ret != 0)
{
DisplayState = DisplayState2;
DisplayState2 = 0;
LCD_update();
}
}
else if (DisplayState2 == SET_SCHED_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DisplayState2 = (DisplayState2 + rpg_pos_ret);
if (DisplayState2 == 0)
{
DisplayState2 = 8;
} else if (DisplayState2 == 9)
{
DisplayState2 = 1;
}
else if (DisplayState2 == 6)
{
DisplayState2 = 3;
}
else if (DisplayState2 == 4)
{
DisplayState2 = 7;
}
if (rpg_pos_ret != 0)
{
DisplayState = DisplayState2;
DisplayState2 = 0;
LCD_update();
}
}
else if (DisplayState2 == EXIT_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DisplayState2 = (DisplayState2 + rpg_pos_ret);
if (DisplayState2 == 0)
{
DisplayState2 = 8;
} else if (DisplayState2 == 9)
{
DisplayState2 = 1;
}
else if (DisplayState2 == 6)
{
DisplayState2 = 3;
}
else if (DisplayState2 == 4)
{
DisplayState2 = 7;
}
if (rpg_pos_ret != 0)
{
DisplayState = DisplayState2;
DisplayState2 = 0;
LCD_update();
}
}
else if (DisplayState2 == SET_PILL1_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DisplayState2 = (DisplayState2 + rpg_pos_ret);
if (DisplayState2 == 0)
{
DisplayState2 = 8;
} else if (DisplayState2 == 9)
{
DisplayState2 = 1;
}
else if (DisplayState2 == 6)
{
DisplayState2 = 3;
}
else if (DisplayState2 == 4)
{
DisplayState2 = 7;
}
if (rpg_pos_ret != 0)
{
DisplayState = DisplayState2;
DisplayState2 = 0;
LCD_update();
}
}
else if (DisplayState2 == SET_PILL2_STATE)
{
rpg_pos_ret = check_RPG_Pos();
DisplayState2 = (DisplayState2 + rpg_pos_ret);
if (DisplayState2 == 0)
{
DisplayState2 = 8;
} else if (DisplayState2 == 9)
{
DisplayState2 = 1;
}
else if (DisplayState2 == 6)
{
DisplayState2 = 3;
}
else if (DisplayState2 == 4)
{
DisplayState2 = 7;
}
if (rpg_pos_ret != 0)
{
DisplayState = DisplayState2;
DisplayState2 = 0;
LCD_update();
}
}
else if (DisplayState == SET_PILL22_STATE)
{
rpg_pos_ret = check_RPG_Pos();
PillsRem2 = (PillsRem2 + rpg_pos_ret);
if (PillsRem2 > 8)
{
PillsRem2 = 0;
}
else if (PillsRem2 < 0)
{
PillsRem2 = 8;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_PILL12_STATE)
{
rpg_pos_ret = check_RPG_Pos();
PillsRem1 = (PillsRem1 + rpg_pos_ret);
if (PillsRem1 > 8)
{
PillsRem1 = 0;
}
else if (PillsRem1 < 0)
{
PillsRem1 = 8;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_SCHED2_STATE)
{
rpg_pos_ret = check_RPG_Pos();
ScheduleNum = (ScheduleNum + rpg_pos_ret);
if (ScheduleNum > 27)
{
ScheduleNum = 0;
}
else if (ScheduleNum < 0)
{
ScheduleNum = 27;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_SCHED3_STATE)
{
rpg_pos_ret = check_RPG_Pos();
ScheduleArray[ScheduleNum].Hour = (ScheduleArray[ScheduleNum].Hour + rpg_pos_ret);
if (ScheduleArray[ScheduleNum].Hour > 24)
{
ScheduleArray[ScheduleNum].Hour = 0;
}
else if (ScheduleArray[ScheduleNum].Hour < 0)
{
ScheduleArray[ScheduleNum].Hour = 24;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
else if (DisplayState == SET_SCHED4_STATE)
{
rpg_pos_ret = check_RPG_Pos();
ScheduleArray[ScheduleNum].Minute = (ScheduleArray[ScheduleNum].Minute + rpg_pos_ret);
if (ScheduleArray[ScheduleNum].Minute > 60)
{
ScheduleArray[ScheduleNum].Minute = 0;
}
else if (ScheduleArray[ScheduleNum].Minute < 0)
{
ScheduleArray[ScheduleNum].Minute = 60;
}
if (rpg_pos_ret != 0)
{
LCD_update();
}
}
}
if (CheckPill() == 1)
{
PORTA_BIT1 = 1;
if (DispenseFlag == 1 && SinceDispense < 10 && LogFlag == 0)
{
print_log_message(1);
LogFlag = 1;
DispenseFlag = 0;
SinceDispense = 0;
} else if (DispenseFlag == 0)
{
LogFlag = 0;
}
} else
{
if (DispenseFlag == 1 && SinceDispense >= 10 && LogFlag == 0)
{
print_log_message(2);
LogFlag = 1;
DispenseFlag = 0;
SinceDispense = 0;
} else if (DispenseFlag == 0)
{
LogFlag = 0;
}
PORTA_BIT1 = 0;
}
if ((RunMotorFlag > 0) && (MotorTimeFlag == 1))
{
MotorRoutine1();
DispenseFlag = 1;
}
if ((RunMotorFlag2 > 0) && (MotorTimeFlag == 1))
{
MotorRoutine2();
DispenseFlag = 1;
}
#if USE_SWLED
UseSWLedRun();
#endif
if (gotlink) {
/* take care of watchdog stuff */
/* Try to receive Ethernet Frame */
if( NETWORK_CHECK_IF_RECEIVED() == TRUE ) {
switch( received_frame.protocol)
{
case PROTOCOL_ARP:
process_arp (&received_frame);
break;
case PROTOCOL_IP:
len = process_ip_in(&received_frame);
if(len < 0)
break;
switch (received_ip_packet.protocol)
{
case IP_ICMP:
process_icmp_in (&received_ip_packet, len);
break;
case IP_UDP:
process_udp_in (&received_ip_packet,len);
break;
case IP_TCP:
process_tcp_in (&received_ip_packet, len);
break;
default:
break;
}
break;
default:
break;
}
/* discard received frame */
NETWORK_RECEIVE_END();
}
arp_manage();
/* Application main loops */
/* TCP/IP stack Periodic tasks here... */
udp_demo_run();
tcp_poll();
https_run ();
}
else {
PTG_PTG0 = 1; //turn off LED1
PTG_PTG1 = 1; //turn off LED2
}
}
}
parse_url.c
#include "parse_url.h"
extern TimerStruct CurrentTime;
extern ScheduleStruct ScheduleArray[28];
// This array holds strings for use in printing out current day.
char *days[] = {"sun", "mon", "tue", "wed", "thu", "fri", "sat"};
// Process incoming HTTP request.
INT16 incoming_url(UINT32 len)
{
INT8 action;
INT8 return_value;
action = get_action(&len); // determine CGI 'action'
// return appropriate page based on action / process action.
if (action == LOGIN_ACTION) return_value = process_login(&len);
else if (action == SCHED_ACTION) return_value = process_schedule(&len);
else if (action == VIEW_LOG_ACTION) return_value = LOG_FILE;
else if (action == CLEAR_LOG_ACTION) {clear_log(); return_value = SCHED_FILE;}
else return_value = LOGIN_FILE; // default.
if (return_value == SCHED_FILE) put_current_time_in_web_page();
return return_value;
}
// Reads in CGI action (first 3 chars of URL).
INT8 get_action(UINT32 *len)
{
UINT8 action[4];
if (*len >= 3)
{
read_url_until('?', 3, len, action);
if (string_compare("lid", action, 0)) return LOGIN_ACTION;
else if (string_compare("se1", action, 0)) return SETTINGS1_ACTION;
else if (string_compare("log", action, 0)) return VIEW_LOG_ACTION;
else if (string_compare("clr", action, 0)) return CLEAR_LOG_ACTION;
else if (string_compare("lgo", action, 0)) return LOGOUT_ACTION;
else if (string_compare("sch", action, 0)) return SCHED_ACTION;
}
// test to see if flash erase/write works:
if (string_compare("ers", action, 0)) { Flash_Erase_Sector((unsigned int *far) 0x5000);
Flash_Write_Word((unsigned int *far) 0x5000, 0x3639);
Flash_Write_Block((unsigned int *far) 0x6BB9,
(unsigned int *far) 0x5000,
512);
return BADLOGIN_FILE;}
return DEFAULT_ACTION; // if unknown action or < 3 chars, default.
}
// Parses username and password from URL and compares them
// to login information stored internally.
INT16 process_login(UINT32 *len)
{
UINT8 username[9];
UINT8 password[9];
UINT8 field[9];
read_url_until('=', 8, len, field); //un
read_url_until('&', 8, len, username);
read_url_until('=', 8, len, field); //pwd
read_url_until('&', 8, len, password);
if ( string_compare("user", username, 0) /* &&
string_compare("pass", password, 0) */)
{
return SCHED_FILE;
}
return BADLOGIN_FILE;
}
// Reads all of the times entered into the schedule, writes
// the updated values into the web page, and updates the schedule.
INT8 process_schedule(UINT32 *len)
{
UINT8 field[5];
UINT8 value[9];
UINT8 i;
static UINT8 index;
static UINT8 hour;
static UINT8 min;
UINT8 char1, char2;
char1 = char2 = 0;
index = 0;
INTCR_IRQEN = 0;
for (i = 0; i < 28; i++)
{
read_url_until('=', 4, len, field);
read_url_until('&', 8, len, value);
if ((field[0] = (UINT8) '0')) char1 = 1;
if ((field[1] = (UINT8) '0')) char2 = 1;
if (char1 == 1 && char2 == 1)
index = 10 * (field[0] - (UINT8) '0') + (field[1] - (UINT8) '0');
else if (char1 == 1)
index = field[0] - (UINT8) '0';
else if (char2 == 1)
index = field[1] - (UINT8) '0';
hour = 10 * (value[0] - (INT8) '0') + (value[1] - (INT8) '0');
min = 10 * (value[5] - (INT8) '0') + (value[6] - (INT8) '0');
index = (index + 4) % 28;
ScheduleArray[index].Hour = hour;
ScheduleArray[index].Minute = min;
erase_web_page_block(web_offsets[i] / 512);
Flash_Write_Word((unsigned int *far) sched_file + web_offsets[i] / 2,
(INT16)((INT16) (value[0]) ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- final maturity of ee savings bonds
- final maturity date for ee bonds
- calculate ee bond final value
- ee savings bonds final maturity
- final cost report nysed
- purdue university plagiarism checker
- purdue university salaries
- project final report template
- project final summary report template
- final grant report sample
- project management final report example
- project management final report template