EE 477 Final Report
ECE 477 Final Report
Spring 2007
[pic]
Jay Doyle Tom Germon Ryan Schroeder Dave Canada
Team Code Name: ______BatteryMAX___________________________ Team ID: __8__
Team Members (#1 is Team Leader):
#1: _Ryan Schroeder_____________ Signature: ____________________ Date: _________
#2: _Dave Canada_______________ Signature: ____________________ Date: _________
#3: _Jay Doyle__________________ Signature: ____________________ Date: _________
#4: _Tom Germon_______________ 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: 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 8 | |
|CD of Project Website |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |
| |TOTAL | |
TABLE OF CONTENTS
|Abstract |1 |
| 1.0 Project Overview and Block Diagram |2 |
| 2.0 Team Success Criteria and Fulfillment |4 |
| 3.0 Constraint Analysis and Component Selection |5 |
| 4.0 Patent Liability Analysis |7 |
| 5.0 Reliability and Safety Analysis |11 |
| 6.0 Ethical and Environmental Impact Analysis |13 |
| 7.0 Packaging Design Considerations |16 |
| 8.0 Schematic Design Considerations |19 |
| 9.0 PCB Layout Design Considerations |21 |
|10.0 Software Design Considerations |23 |
|11.0 Version 2 Changes |26 |
|12.0 Summary and Conclusions |27 |
|13.0 References |30 |
|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: FMECA Worksheet |G-1 |
Abstract
BatteryMax is a universal battery charger capable of recharging the four major varieties of rechargeable batteries, up to 25 volts. BatteryMax is controlled through both an on-board interface as well as through an embedded web server. BatteryMax will track individual batteries, building up a history of voltage and current over time that it can report to the user. A detailed account of the design, assembly, programming and testing of the BatteryMax universal battery charger is contained in this document.
1. Project Overview and Block Diagram
[pic]
Figure 1.1 – BatteryMax Block Diagram
To charge a battery through a normal wall outlet, a few things need to be done. Firstly, the 110V AC signal coming into the battery charger goes through a transformer to drop it down to a 33V AC signal, which then goes through a rectifier to smooth it into a 25V DC voltage.
The DC signal then goes into the liner regulators which produce 30V, 12V, 5V and 3.3V, with an adjustable regulator producing 0.5V to 25V. The 3.3V signal powers the digital potentiometers, adjustable regulator, EEPROMs, the relay, the temperature sensor and the microcontroller. The 5V signal powers the current sensor and the 12V power signal powers the LCD. The 30V acts as a reference line for the digital potentiometers.
The microcontroller communicates to the LCD through serial port zero (SCI0). Serial port one (SCI1) is reserved for the background debug module (BDM). The embedded web server connects to a computer or a network through PHY. The analog to digital converter communicates with the voltage, current and temperature sensor. The microcontroller’s I2C interface is used to communicate with the EEPROM and the relay. Finally, the SPI interface is used to control the adjustable regulator and digital potentiometers.
[pic]
Figure 1.2 – BatteryMax Completed PCB
[pic]
Figure 1.3 – BatteryMax Completed Project
2. Team Success Criteria and Fulfillment
In order to consider BatteryMax a success, certain success criteria were outlined at project inception. These five criteria served as a guideline towards completion of the project throughout the semester. To make the BatteryMax truly universal, it had to be compatible with the various rechargeable battery technologies on the market today. To be usable, it must be easily controlled by the user and be able to relay information back to the user.
The project specific success criteria (PSSC) defined at the beginning of the semester:
1) An ability to intelligently recharge multiple battery technologies.
This outcome was met completely.
2) An ability to display and modify settings through a user interface (LCD and keypad).
This outcome was met completely.
3) An ability to display and modify settings through an embedded web page.
This outcome was met completely.
4) An ability to perform technology-specific diagnostic tests on a battery.
This outcome was met completely.
5) An ability to track individual battery statistics via battery identification numbers.
This outcome was met completely.
Each of the five PSSC’s was fulfilled. The first PSSC required that the battery charger be able to output a voltage greater than the max voltage of the battery, forcing the battery to charge. Each battery technology has a specific charging algorithm to achieve maximum efficiency;, however basic charging can be accomplished just by applying an appropriate voltage across the battery terminals. BatteryMax is able to determine what voltage is appropriate at each instant throughout the charging process to ensure that each battery is intelligently charged.
The BatteryMax communicates back to the user through an LCD display mounted on the front side of the case. This LCD panel also has a built in keypad, which allows the user to control the device.
The battery charger has a built in web page which serves two purposes. The user can retrieve information about the last 5 battery charges and the user can control the device via a control page.
BatteryMax is capable of performing battery testing. The device will act as a voltage meter which allows the user to make sure the battery is outputting the correct voltage. The device will also perform a quick discharge on the battery, which will facilitate longer battery life in some rechargeable battery technologies.
The BatteryMax is capable of remembering five batteries by battery identification number. There was no more room in the microcontroller’s main memory for more than five batteries. While this fulfils the outcome, this is not large enough for a commercial version. Some solutions to this might include storing the information on a remote device, such as the user’s personal computer or using an external flash chip on the printed circuit board.
Constraint Analysis and Component Selection
BatteryMax is not meant to be portable or battery powered. This allows the focus of the design to shift from portability and small packaging to functionality. The device will draw a sizeable amount of power at times and must have the ability to dissipate heat appropriately.
The main design challenge with BatteryMax is interfacing the many external components to the microcontroller. Initial plans call for an LCD, keypad, external memory, temperature sensor, current sensor, voltage sensor, and digital potentiometers. Additionally, Ethernet capability must be provided by the microcontroller to serve the embedded web page.
Computation Requirements
The microcontroller for BatteryMax does not need much in terms of raw computational power. No special math functions are needed nor is it necessary that the microcontroller have any specialized instructions. Since no floating point will be used, the microcontroller should be 16 bit to allow proper scaling when doing calculations. The microcontroller’s main function will be to read in values from the analog-to-digital converter and make decisions based on these values. 8-bit resolution on the analog-to-digital values will provide sufficient accuracy to effectively control charging process. The microcontroller will also need to refresh the LCD based on current status and user input, as well as handle requests made on the Ethernet port.
The memory requirements of the microcontroller are were also an important factor. BatteryMAX will makes use of an embedded web page, which has the potential to take up a substantial amount of memory space. Also, the storage of data points will required additional memory. Assuming a maximum rate of three 8-bit data points every fifteen seconds, each hour of charge time will require 720 bytes of storage space. This can quickly use up the onboard memory of a microcontroller, so external memory will probably bewas required to support enough data points to be useful.
Interface Requirements
General purpose I/O waswill be used within BatteryMax as chip selects for the various peripherals and to control status LEDs on the front of the packaging. Three outputs werewill be used to control a red, orange, and green LED. These will indicate various status conditions during the charging process. These output pins will drive the base of an NPN transistor, such that when the pin is in the high state, current will flow in the transistor and the LED will illuminate. Six additional outputs werewill be used as chip selects for the digital potentiometers. All six digital potentiometers communicate via the SPI bus. The wiper levels will be are sent to the appropriate device based on which chip is selected. One output will bewas used to control the relay connecting the power supply to the battery. The output pin is connected to the gate of a MOSFET, such that when the pin is in the high state, current will flow and the relay will connect the two circuits.
On-Chip Peripheral Requirements
A large number of on-chip peripherals arewill be used. Four 8-bit analog-to-digital converter inputs will be used to monitor the voltage of the battery, the temperature of the battery, the current being delivered to the battery, as well as the internal temperature of the unit. Two SCI channels will be used. One will communicate to a computer terminal for debugging purposes and the other will communicate with the LCD. One SPI channel will be used to set the levels of the digital potentiometers. Serial EEPROM will interface with the microcontroller via the IIC channel.
Power Constraints
BatteryMax is designed for use in a home or on a workbench. As such, the device will be powered via standard 110V AC power. AC to DC power conversion will take place within the unit. In order to provide power for the electronic components and still have the flexibility to charge batteries at a high current rating, the transformer will need to be able to provide 24 33 VAC at 4 A. This allows up to 1 A for the microcontroller and other circuitry, while still being able to provide a maximum of 3 A to the battery. The 3324VAC will be rectified and reduced in order to supply voltages of 3.3V, 5V, 12V, and 30V DC to the various parts of the circuit.
Microcontroller
Many different microcontrollers were available which fit within the design constraints of the project. Those considered were the Rabbit RCM4200, the PIC18F97J60, and the Freescale MC9S12NE64. Table 3.2.1 summarizes the key features of each microcontroller.
The Rabbit microcontroller was eliminated because it did not have enough SCI channels to fit within the design constraints. It also did not have IIC communications. The lack of IIC could have been dismissed because of the large amounts of on-chip memory, as this was the sole purpose of the IIC. The PIC microcontroller was also considered, but was eliminated because of the small amount of on-chip RAM. It is also only an 8 bit microcontroller. The Freescale microcontroller meets all of the needs laid out in the constraint analysis. It has the necessary peripherals, as well as sufficient RAM and flash to store the main program. The on-chip Ethernet is also nicea benifit, which helps to reduce the complexity of the overall design. An added benefit of the Freescale microcontroller is the excellent manufacturer support. Application notes describe in detail how to get a web server up and running quickly.
|Manufacturer |Rabbit |PIC |Freescale |
|Model |RCM 4200 |PIC18F97J60 |MC9S12NE64 |
|Bits |16 |8 |16 |
|Max Clock |58.98 MHz |41.667 MHz |25 MHz |
|Pins |60 (headers) |100 |112 |
|SCI |1 |2 |2 |
|SPI |4 |1 |1 |
|IIC |0 |1 |1 |
|ATD |Yes |Yes |Yes |
|Ethernet |Yes |Yes |Yes |
|RAM |1 MB |3808 |8 KB |
|Flash |8 MB |128 KB |64 KB |
Table 3.1 – Microcontroller Comparison
3. Patent Liability Analysis
BatteryMax is a universal battery charger with a focus on compatibility, safety, interactivity, and usability. It is an intelligent, microcontroller-driven device controlled by a keypad and an LCD display. It connects to a cradle for each type of battery that it supports. The Each cradle will havehas a temperature sensor to monitor the temperature of the battery for safety reasons. The built-in web server helps the user track an individual battery’s life cycle or charging progress. There are thousands of different battery- charging products on the market. Some of these products do charge multiple types of batteries, but none have the level of interactivity of the BatteryMax.
Results of Patent and Product Search
In order to analyze potential patent conflicts, multiple searches of the United States Patent and Trademark Office were conducted. Attempts were made to uncover existing patented technologies that resembled major functions or features of the BatteryMax. The initial search for the phrase “recharge AND battery” turned up numerous irrelevant patents, but also found some potential conflicts. One patent, recently awarded to the Milwaukee Electric Tool Corporation, seems to cover a very broad range of battery charging technologies. Details of this patent follow.
United States Patent: 7157883
Title: Method and system for battery protection employing averaging of measurements [9]
Filing Date: December 30, 2005
Abstract: A system and method for battery protection. In some aspects, a method for operating a battery pack. The battery pack having a battery pack condition, and the battery pack condition having a range. The method including the acts of conducting an operation including the battery pack, measuring a first measurement of the battery pack condition, measuring a second measurement of the battery pack condition, averaging the first measurement and the second measurement to provide an average measurement and if the average measurement is within the range, continuing the operation including the battery pack.
Key Claims:
1. A method for operating a battery pack safely when the average of two measured conditions is within a specified range.
2. The method as set forth in claim 1 wherein the battery pack condition is a voltage.
3. The method as set forth in claim 1 wherein the battery pack condition is a temperature.
4. The method as set forth in claim 1 and further comprising the act of discontinuing the operation if the average measurement is outside of the range.
Intersil Americas Inc. holds the following patent for a technology for charging Li-ion batteries.
United States Patent: 7141954
Title: Li-ion/Li-polymer battery charger configured to be DC-powered from multiple types of wall adapters [11]
Filing Date: November 30, 2005
Abstract: A battery charger controller is coupled to DC output terminals of an AC-DC (or DC-DC) adapter containing an AC-DC (or DC-DC) converter. A controlled current flow path between input and output terminals of the battery charger controller circuit is controlled to provide a substantially constant current to charge the battery to a nominal battery voltage. When a constant voltage output of the said adapter transitions to a value that limits available charging current to a value less than programmed constant charging current, current flow drive for the controlled current flow path is increased for a limited time interval. Thereafter, the controlled current flow path gradually reduces charging current as the battery voltage remains at its nominal battery voltage until the charge is complete or otherwise terminated.
Key Claims:
1. An apparatus for charging a battery comprising: power source-coupling input terminals arranged to be coupled to any of a plurality of different types of DC power sources, each of which is capable of providing power sufficient to charge said battery using controlled current flow.
2. The apparatus according to claim 1, wherein said controlled current flow control circuit comprises a controlled electronic circuit device having an input-output current flow path coupled between one of said power source-coupling input terminals and said second output terminal, and a control terminal arranged to receive a control input from a control circuit that controls current throughput of said input-output current flow path of said controlled electronic circuit device.
One commercial product that is very similar to the BatteryMax is the Maha MH-C777Plus-II [10]. This device has an LCD which is used for displaying voltages and currents of a battery while the device is in operation. BatteryMax also uses an LCD for this purpose. It has an adjustable battery bay which fits many special types of battery packs, like what you might find used in a camcorder. Digital camera and camcorder batteries are the targeted technologies. The MH-C777Plus-II attempts to guess the intended voltage of the battery. BatteryMax requires the user to specify battery parameters before charging begins. It supports Lithium Ion, NiCad, and NiMH and lead-acid battery types. Maha does not appear to have filed for patents for this device. Perhaps they realized how difficult it would be to convince people that they were the first to ever make a battery charger.
Analysis of Patent Liability
Each of the above patents claimclaims to cover some of the features of the BatteryMax. The first patent, owned by Milwaukee Electric Tool Corporation, may literally conflict with our ability to implement voltage and temperature sensors on the BatteryMax. This patent also claims rights to the technology which disables the circuit as soon as unacceptable temperatures or voltages are discovered. Another facet of this patent is a specific design of the connectors which physically prevents a battery pack from being connected improperly to its charger. The primary goal of this patent seems to be to obtain exclusive rights to a certain battery pack design for use in power tools. The BatteryMax does not utilize battery packs though it would have to emulate the connector for this specific battery pack in order to charge it.
The patent held by Intersil Americas Inc. covering Li-ion charging techniques includes a voltage stepping technique which is claimed to reduce power dissipation as compared to a linear charging schedule. The priority of BatteryMax is not to reduce power dissipation so it may simply use the linear charging algorithm for Li-ion batteries. The name of the patent implies that the most important part of the patent is the ability of the device to accept multiple types of wall adapters as input. BatteryMax only needs one type of adapter. If our charging algorithm was identical to theirs, we would be committing a literal patent infringement. If our device accepted multiple types of wall adapters, it could be considered an infringement under the doctrine of equivalents, though this could easily be disputed since there are so many other devices already doing this.
Action Recommended
In order to minimize the risk of infringing on the patent owned by Milwaukee Electric Tool Corporation, we should choose not to support its battery pack design. We should not release a connector intended for use with the patented battery pack. To further reduce the semblance, BatteryMax should use a standard connector that is not covered by a patent.
The third patent appears to prohibit BatteryMax from utilizing the advanced voltage stepping charging schedule outlined in the patent. Thus, BatteryMax must avoid duplicating this technique for Li-ion batteries.
Since the battery charger from Maha is not protected by any patents, there is no risk of patent violation if the BatteryMax has features similar to the Maha device.
Summary
This report contains the results of a search conducted on the United States Patent and Trademarks Office website for patents which our project could potentially infringe upon. Similarities and differences between the patents and the BatteryMax were described. A similar commercial product was also compared. Finally, Suggestions were made for ways to avoid infringing upon these patents through design changes. No major changes to the BatteryMax were found to be necessary, but it will be important to avoid using existing components or techniques such as connectors from a battery pack to make the design easier as this could cause a patent infringement.
4. Reliability and Safety Analysis
The BatteryMax project is designed to be operated on a flat surface in a well ventilated room, with the fan holes exposed and free from obstruction. The voltage regulators get hot, and so must be cooled. If they are not cooled, they fail, on average, quicker than their cooled counterparts. This is a critical component to our design, and failure minimization is very important we want to minimize failures. The voltage regulators, along with the microcontroller, the temperature sensor, and the digital potentiometer were allwill all be examined for failure rate, and the entire circuit wwill beas examined to see what happens if any major part fails. In the BatteryMax project, failure of a part could mean an overload of the battery which could lead to an explosion that could injure a user.
Reliability Analysis
The BatteryMax project has a microcontroller, a temperature sensor, and two digital potentiometers. All of these parts have the ability to fail, and they were chosen to be examined to determine the respective approximate failure rates. The failure rates were calculated using the procedures outlined in [12] using the numbers from their respective data sheets.
The [pic] for each one of the items listed in Table 1 represents the number of failures per 106 hours. It wasis calculated using the equation [pic] Failures/106 hours, where[pic] is the part failure rate, [pic] is the die complexity failure rate, [pic] is the temperature factor, [pic] is the package failure rate, [pic] is the environmental factor, [pic] is the quality factor, and [pic] is the learning factor. The MTTF (mean time to failure) wasis then calculated by taking the inverse of [pic].
[pic]Table 5.1: [pic] and MTTF for 4 devices in circuit
The Mil-Hdbk-217F document did not have specific values for every part chosen, so some assumptions were made. These included [pic] = 2 which corresponded to the parts being ground fixed and [pic] = 1.2 for the digital potentiometer because the datasheet was dated 2005.
Predictably, the least reliable part is the microcontroller which is the most complicated IC on the circuit. For reliable mass-production of the product, the [pic] for the microcontroller would have to be brought into the 109 failures/hour range, since it affects the safety of the users. This could be accomplished by adding checking hardware to ground the output if it goes out of range. This would stop the battery from being overloaded, and make the design much safer. Also, the numbers calculated from the Mil-Hdbk-217F document gavegive a conservative estimate of the MTTF, so some error is acceptable for the calculation.
Failure Mode, Effects, and Criticality Analysis (FMECA)
The circuit was split into four categories to assist in finding the failure mode, effects, and criticality analysis (FMECA). These were the power supply circuit, the charge supply circuit, the sensor circuit, and the logic circuit. Two criticality levels were suitable for the design. The “high” level corresponds to any failure that could cause the battery to be overloaded or a part on the circuit to be overloaded. The “high” level’s acceptable failure rate wasis on the order of 10-9 failures per hour. The “low” level corresponds to a failure that would cause loss of functionality or information, but would not pose any threat to the user. The “low” level’s acceptable failure rate wasis on the order of 10-6 failures per hour. The design does not currently meet these requirements; however the Mil-Hdbk-217F document gavegives a conservative estimate.
The FMECA worksheet (appendix BG) outlines the possible failures in the circuit and their outcomes. Each failure is was given one of the two ratings above, as well as what could cause the failures. The devices involved in some of the failures had to fail a specific way for the particular outcome to occur. A2 could not cause damage unless the battery was being charged at the time of failure. It is was also assumed that since the circuit is housed inside a case, that any part failure would not cause injury to the user.
Summary
The device in the system that is the most likely to fail is the microcontroller. Unfortunately it is the most crucial part of the circuit to ensure functionality. Battery charging cannot be accomplished without it. If the microcontroller fails, the battery will not charge, and if it fails in the middle of charging, there is a chance that the battery will be overloaded. The design has many failures that are “high” levels of criticality. Some of them are made safe with software checks from the microcontroller, but others are not. Unfortunately, some of the failures are expected to occur every 104 to 106 hours. However, that is was a conservative estimate.
5. Ethical and Environmental Impact Analysis
There are were numerous challenges that go into designing a product that is both reliable and safe. Before being released to market, the universal battery charger will undergounderwent numerous tests to ensure that it can operate anywhere a user might need it. The charger will was also also be tested to make sure that if and when it fails, it will fail in a manner that will not harm the user. In addition to making it as safe as possible, the universal battery charger will havehas explicit warnings and instructions to facilitate safe operation.
Operational Environment Tests
Prior to release, the universal battery charger will undergounderwent numerous operational and environment tests. If undesirable operation occurs within normal operational conditions, measures will beare taken the remedy the situation.
Since this device can charge high voltage batteries, it is capable of pulling a lot of power from the wall outlet. One of the most critical tests that will be performed is the overvolt and undervolt tests. In case of an out of spec voltage, the charger will not operate. An overvolt condition should cause the built in fuse to break. An undervolt may not be as much of a problem, as the device is not likely to have enough power to operate.
One potential use of the universal battery charger is the charging of automobile and marine batteries. Garages and marinas are often not heated or air conditioned, therefore temperature testing is critical. Maximum and minimum operational temperatures will be determined as well as maximum and minimum storage temperatures. A fan inside the charger should helphelped with the maximum temperature. Garages are often rough places for digital equipment. Vibration and shock testing is a must if the universal battery charger is to be well suited for the garage environment. A rugged housing and durable PCB mounting are critical to the reliability of the device. If the universal battery charger is to be used in a marina setting it must be able to work in high humidity situations. Since the internal components will need to be cooled via good ventilation and a cooling fan, water damage will be very hard to prevent.
Altitude is not a major concern since the battery charger will need an AC outlet to function. The theoretical maximum altitude will be calculated from the maximum altitude listed in the reference manual for each integrated circuit and other major components. The theoretical maximum will be placed in the user manual.
If the universal battery charger is to be sold in the United States it must comply with all FCC regulations, specifically 47-CFR-15 [20][23]. This regulation states that any device used in the United States, it may not radiate radio frequency energy. It is anticipated that this device will comply with the FCC regulations but it will be tested regardless.
Warnings to the User
The universal battery charger will be capable of recharging batteries of up to 30 25 volts. The power supply is capable of sourcing just over three amperes at the max voltage, with increasing current sourcing potential with a reduced required voltage. This large amount of power inside the device, and the potential for injury, need to be conveyed to the user. A sticker informing the user of a potential for electric shock will be placed at the battery connection. In addition, the AC wall plug will have a sticker warning the user to only plug the device into a 120110V 60Hz power outlet.
A simple warning message outlining the dangers of improper use of the device will be given in the user manual. The device’s operational tolerances will be presented to the user in the user manual.
Safety Mechanisms
The universal battery charger will have several built in safety mechanisms. First and foremost, the battery parameters, voltage, current and temperature, are constantly measured during charging. If the voltage or current are outside of the charging scheme the digital potentiometer array will be adjusted to achieve the correct voltage and current. If the temperature is too great the microcontroller will stop charging, notifying the user of the error.
To prevent harm from a power surge or other overvolt conditions, a fuse is built into the power supply. Should too much power go through the power supply, possibly because the user is being shocked, the fuse will trip. This should theoretically prevent serious injury to the user,; however there is always risk due to faulty equipment.
Environmental Impact Analysis
Digital devices can have a large impact on the environment throughout their lifetime. Numerous chemicals are used in the production of most digital devices and most digital devices will require a complex recycling process before they can be disposed of.
Environmental Impact of the Manufacturing Process
The universal battery charger will contain several integrated circuit chips, various resistors and capacitors, and an LCD panel. All these elements will reside on one of two printed circuit boards (PCBs). The LCD panel itself has its own PCB on which is mounted the control logic for the panel.
The manufacture of printed circuit boards is, historically, extremely hazardous for the environment. The modern process includes various steps to minimize the chemical waste that leaves the factory. Pollution associated with the manufacture of PCBs comes in two main forms: liquid waste containing heavy metals, and air pollutants which contain acidic particles. [21]
In a modern PCB manufacturing process, acid fumes stemming from the acid cleaning process are collected via a ventilation hood and sent into a scrubber that removes the hazardous fumes. The acidic waste is now a liquid and can be neutralized before being released for treatment. [21]
Waste water from the cleaning process, water from the plating bath and excess copper from the etching process is often treated and pH-balanced before being released. Chemicals are used to balance the pH of the solution and to remove solid waste (copper, lead and other suspended solids). The solid waste is filtered and is sent off to the landfill. [21]
Environmental Impact of Normal Use
The universal battery charger does not produce any pollutants or a large amount of electro-magnetic energy. It does however use electricity. The universal battery charger will be designed to use as little electricity as possible. It is intended to charge batteries, which means at times it will be drawing large amounts of power, but some steps can be taken to reduce power consumption during idle times.
After a certain amount of inactivity, the universal battery charger will shut off the backlight to the LCD panel, regardless of charging status. This will cut down on electricity use.
Environmental Impact of Disposal
All printed circuit boards contain hazardous, and sometimes valuable, metals. All PCBs contain lead and copper components; some PCBs will have gold connections. These heavy metals necessitate recycling. Elution of these metals into the ground may pollute bodies of water and can contaminate drinking water. [22]
The universal battery charger will contain multiple PCBs. The universal battery charger has a central component responsible for charging any type of battery. To allow the charger to accept the various sized batteries, the main module will have a port which will accept the various battery housings. Each battery housing will contain a simple PCB containing a temperature sensor. Both the main module and all battery housing modules contain PCBs. Both must be recycled.
6. Packaging Design Considerations
BatteryMax, by Power4 is an intelligent, universal battery charger whose purpose is to reduce the production of waste from disposable batteries and to provide a convenient way for its owners to maintain a collection of usable power sources. The latest electronics technologies usually create a buzz about what’s inside. Take Sony’s PlayStation®3 for example; this powerful device boasts a processor containing eight processing units [23]. If nothing more than the raw power of a game console affected consumer’s decisions, then there would be no competition. In fact, other features of a product can have a huge affect on its desirability. Other game consoles are competing quite well with the PlayStation®3 by costing less, having a larger set of games, and even by having well designed packaging. One of the biggest selling points of the Nintendo Wii® is its well-designed controller.
BatteryMax is a product with powerful features housed within a professional package. Its design allows a user to easily connect multiple types of batteries to the BatteryMax. It is large enough to contain the necessary circuit board and power supply as well as temperature and voltage sensors for safety. Another important thing to consider is placement of components. For example, the keypad should be placed in such a way that both a right handed and a left handed user are able to use it without obstructing the display.
Commercial Product Packaging
Product #1
[pic]
Product one is the Vanson V-75 Lithium Ion Battery Charger [24]. This is specialized for charging a single type of battery; model CR-123, often used in digital cameras. The device itself does not enclose the power supply. Instead, it relies either on a car’s cigarette lighter or a 12-volt DC wall adapter. One benefit of keeping the power supply separate from the battery is that their temperatures do not affect each other. It is important for a battery to not get too hot while charging or it will likely be permanently damaged. There is a gap around the battery in this design to allow airflow to cool the battery. This is an extremely important feature that will also be present in the BatteryMax. Unlike the BatteryMax, the V-75 is only able to charge lithium ion batteries. This device lacks any sort of interactivity. It has only LEDs to give a binary indication of the charging status. The charging cycle is not intelligent; instead, it simply relies on a timer to control how long the battery is charged. This could result in batteries being overcharged or undercharged. Lack of a microcontroller and its reliance on an external power supply allow this device to be very small and lightweight. The BatteryMax will keep the battery holder separate from the power supply similar to this product. In order to support multiple battery types and to make the process more interactive, BatteryMax will need to be larger.
Product #2
[pic]
The second product is the Tenergy T6278 Universal Smart Fast Charger [25]. This device is quite different from the previous Device in its scope of features and its packaging. On the top of the case is a simple LCD display. This display offers little more interactivity than the charger from Vanson did. Tenergy’s device only shows a battery symbol with up to four bars representing the charging progress. One good thing about the packaging used in this device is its compact design. It has rounded edges and a smooth shape which would make less awkward to transport. While there are ventilation holes at the base, the battery compartment is fully enclosed. Heat generated by the batteries during the charge cycle cannot easily escape. BatteryMax does not make this mistake. The Tenergy package is well suited for table-top use;, this is what BatteryMax will also be intended for.
Project Packaging Specifications
For its enclosure, BatteryMax uses an 12”x7”x4” aluminum Project Box purchased from Digi-key. The top panel of the box holds the LCD display with its keypad in the center. There is a plug on the side of the box for different types of batteries are plugged in for charging. There are two fans which will circulate air within the case to keep internal components cool. An on/off switch will be placed on the side of the box as well. Inside the box, the LCD is mounted to the top cover while the PCB and the transformer are fastened to the bottom. The external battery cradle encourages heat dissipation from the battery itself and facilitates compatibility with numerous battery types. The weight is estimated to be around 941g. While this may seem heavy, it is important to consider that the device will be used on a tabletop. Alternative packaging could be considered if we chose to use an external power supply. The enclosure could be reduced in size significantly since the PCB and LCD together are much thinner than the transformer is. Future revisions may add stylistic details like rounded corners or more balanced weight distribution.
PCB Footprint Layout
The main component of the PCB, our microcontroller, is approximately 16mm x 16mm [26]. Also on the PCB are three 1MB memory chips measuring 10mm x 6mm [27]. Both components are available in QFP surface mount packages and these are what will be used on our PCB. In order to facilitate debugging, each pin of our microcontroller is connected one of three sets of headers measuring 50mm x 5mm. Perhaps the largest piece on the circuit board is the Ethernet connector at 16mm x 21mm. The overall PCB measures 9” x 6.6”. This PCB size fits snugly within the project box when the transformer is also in place.
Summary
In section 2.0, two products similar to BatteryMax were analyzed. Both products had useful and innovative features; however, both also had flaws. It is our goal to avoid these flaws in BatteryMax to produce a product that does its job very well. Important considerations for the products size, weight, design, and overall cost were considered. Initial layouts for the PCB imply a final PCB size that will fit perfectly into the device. Parts chosen will be easily mounted to the PCB or the project box. Decisions made in this stage will help following steps proceed more smoothly.
7. Schematic Design Considerations
All of the systems of BatteryMax were designed with their primary function in mind. Operating modes were selected that would provide the best results for each application. Where possible, design choices were made to facilitate interfacing and communication of components in order to keep the need for additional circuitry at a minimum.
Microcontroller Operation
The Freescale MC9S12NE64 microcontroller will control the operation of the entire design. The NE64 requires a 3.3 V supply voltage and can operate at a frequency anywhere from 0.5 MHz to 25 MHz [26]. An operating frequency of 25 MHz was selected in order for the on-chip Ethernet controller to run at full 100 Mbps speeds. The ATD sampling period was set at 7μs, which is the maximum allowed for the device. The communications to the LCD will happen over the SCI at a baud rate of 57600, which is the maximum for the display. A lot of information will be transferred to the display during normal operation and the faster this information gets there, the better response time will be experienced by the user. The SCI data will need to be translated to RS-232 levels. The SPI clock will be set at 4 MHz, which is the maximum supported by the digital potentiometers.
Power Supply Operation
A standard 110 VAC wall outlet will be used to supply power to the device. A transformer will convert the 110 VAC to 24 33 VAC. It will then be rectified and filtered to produce a 34 V DC output. This will be stepped down to 30 V to power the digital potentiometers. The digital potentiometers require that the supply voltage must be greater than the voltage difference across the wipers. Since that can theoretically be as high as 30 V, a 30 V supply was created to power the potentiometers. The 30 V output is stepped down to 12 V in order to power the LCD and fans, as well as the status LEDs on the exterior of the case. The 12 V supply is stepped down to 3.3 V and 5 V. The 5 V output will power the current sensor, level translator, and relay. The 3.3 V output will power the microcontroller and external memory.
Adjustable Regulator Operation
The LM350 was chosen to deliver the adjustable voltage to the battery. The LM350 has a minimum output voltage of 1.2 V, and a maximum output voltage of 33 V. The guaranteed output current is at least 3 A. Two LM350s will be connected in series, one driving the other. This was done to allow more heat to be dissipated than is possible with just one. Each regulator will be adjustable by a combination of two digital potentiometers, a 10 kΩ and 100 kΩ in parallel. This configuration of resistors will allow the output voltage to be highly adjustable. Changes made on the 100 kΩ resistor will produce small changes on the output, while changes made on the 10 kΩ resistor will produce larger changes on the output.
Sensor Operation
Various sensors will be used to monitor the charging process. A voltage sensor will be connected in parallel with the battery to monitor the battery voltage. Since the battery being charged could have a voltage greater than 3.3 V, the sensed voltage will need to be stepped down before going to the ATD pin. A digital potentiometer will be used to provide a variable divider. This allows lower voltage batteries to have a higher resolution for the voltage sensing, while still providing the ability to charge high voltage batteries. A current sensor will be placed in series with the battery and will measure the current being delivered to the battery. The current sensor outputs 5 V at its maximum, so it will also need to be divided down before connecting to the ATD pin. A temperature sensor will be mounted in close proximity to the battery. This will monitor the temperature of the battery to ensure it does not overheat. The temperature sensor will be able to connect directly to the ATD pin.
LCD/Keypad Operation
A 128x64 pixel LCD will provide feedback to the user. The LCD will communicate with the microcontroller through the SCI port. A RS-232 level translator will sit between the LCD and SCI port, converting the voltages to the appropriate levels. The LCD has a keypad module which can be connected to it. The LCD interprets the keypad presses and sends the data via SCI to the microcontroller.
8. PCB Layout Design Considerations
The main components of the BatteryMax include a microcontroller, an LCD display, a power supply, and a set of sensors. These are all attached to the PCB, whether directly, or through cables, and all have their respective considerations when placing them and routing the wires on the PCB. For example, the LCD display draws 190mA when the backlight is on and 32mA when it is off, whereas the battery charging line has to go up to 3A, so the trace widths need to be vastly different [35].
PCB Layout Design Considerations – Overall
There are were a lot of potential issues to taketaken into consideration and avoided with the device design. The largest consideration is was minimizing EMI within the device. The power supply for the device is was separated from the rest of the circuit to minimize EMI. Since the device uses large currents, if any of those lines are were put in parallel with the digital or analog lines, mutual inductance could cause signals to appear on the lines, resulting in undesirable functionality in the device. All the traces on the PCB are were routed with 45 degree angles at the joints, to reduce transmission reflections and minimize the amount of over-etching in the corners. The trace widths were calculated [32] with a trace width calculator. Please see Table 2.1 for trace width values.
|Current |Minimum Trace Width |Example Traces |
|3 A |140 mil |Battery charging lines |
|1 A |31 mil |Power lines |
|500 mA |12 mil |Power lines |
|100 mA |5 mil |Data lines |
Table 9.1: Trace width values, using 1oz/ft2 thickness
The power and ground lines for the PCB were a large concern as well. The design has no trace loops, and the power supply is connected at only one point to the digital and analog parts of the circuit. This is was done to minimize the noise associated with the power supply circuit.
The components are were placed on the board either to ensure separation for EMI avoidance, or to ensure proximity for signal quality. The Ethernet jack and the oscillator are were required to be close to the microcontroller, so they are were placed as close as they can could be. The components in the power supply are were arranged so that there is was very little complex trace routing between components. There are were also headers for the power going to the fan and the LCD, since they are were not mounted on the PCB.
Decoupling capacitors are were needed for all ICs across the power and ground terminals. These axial glass or multi-layer ceramic capacitors are were chosen because the microcontroller is running at 25MHz. These are to provide instantaneous current to the ICs during transistor switching. In addition to the decoupling capacitors, a bulk decoupling capacitor is was needed for the whole circuit. This metalized polycarbonate or tantalum electrolytic capacitor will support the decoupling capacitors if they deplete their charge reservoirs [33]. The value of the bulk decoupling capacitor wasis 20 times the size of the IC decoupling capacitor. It wasis placed at the PCB power terminals. There wasis also a ceramic disk capacitor placed in parallel with the bulk capacitor, to filter high-frequency noise coming into the circuit [33].
|Capacitor |Capacitor Value |
|IC Decoupling Capacitor |0.01uF |
|Bulk Decoupling Capacitor |0.2uF |
|Circuit Noise Capacitor |0.1uF |
Table 9.2: Capacitor Values
Where possible, the components are were mounted on the top of the PCB, and the traces are were routed on the bottom. This is was done to make soldering easier, as well as ensure there wereare no heat-generating components below the PCB. Where possible, no traces run underneath components. This is was to avoid noise generated by the lines, which could produce undesirable output in the circuit.
PCB Layout Design Considerations – Microcontroller
The microcontroller used in the BatteryMax is was the Freescale MC9S12NE64. One of the major requirements for this microcontroller is the need for a decoupling capacitor on each power input [34]. These capacitors are were mounted on the underside of the PCB where possible, to ensure the closest possible distance to the microcontroller. Some other requirements given in the documentation are were the Ethernet jack must be within 1 inch of the microcontroller, to avoid vias and layer changes between the Ethernet plug and the microcontroller, and the oscillator must be as close as possible to the microcontroller [34]. The power traces for the microcontroller are were run next to it, not under it, to avoid noise problems. The central point for the ground star for the microcontroller should be the VSSX pin [34].
PCB Layout Design Considerations – Power Supply
The power supply contains contained a lot of components, and a lot of heat is dissipated as the power is stepped down from 110V AC to 3025V DC, 12V DC, 5V DC and 3.3V DC. Since the step-down process is fairly linear, it mademakes sense to lay it out on the board in a linear fashion, and keep it isolated from the other portions of the circuit, to reduce noise. The power traces are were much wider than the data traces (140mil compared to 5 mil), because of the higher current. These were calculated [32] with the trace width calculator. The adjustable regulators are were placed close to the edge of the PCB because they are were the hottest parts of the circuit and require required cooling with fans. The adjustable regulators also require required heat sinks, so empty areas are were placed on the PCB to account for them. Headers are werepresent placed on the power lines for the fans.
9. Software Design Considerations
The Motorola MC9S12NE64 contains an on-chip 8KB SRAM and 64KB flash memory [35]. Because of the volatility of the SRAM, the program must reside in the 64KB flash module. This leaves the SRAM free for program variables and the stack. According to the MC9S12NE64 datasheet, the memory mapping for the SRAM is $0400 through $1FFF [1]. Accordingly, the address for the start of program’s RAM will be mapped to $0400 while the stack pointer will be mapped to address $2000. (Remember, when something is pushed onto the stack that the address is decremented before information is stored, therefore the first address used by the stack will be $1FFF.) The program itself will be stored in the on-chip flash. This is nonvolatile memory, meaning it will retain the executable code and stored data after power is disconnected from the chip.
|Addresses |Module |Device |
|$0080 – $009F |Analog to Digital Converter (ATD0) |Battery Voltage Sensor |
|$0080 – $009F |Analog to Digital Converter (ATD1) |Battery Current Sensor |
|$0080 – $009F |Analog to Digital Converter (ATD2) |Battery Temp. Sensor |
|$00C8 – $00CF |Serial Communications Interface (SCI0) |16x2 LCD Display |
|$00D8 - $00DF |Serial Peripheral Interface (SPI) |Digital Potentiometer |
|$0120 – $0123 |Ethernet Physical Interface (EPHY) |Ethernet Adapter |
Table 10.1 Mapping of External Interfaces [35]
The microcontroller will need to interface with multiple devices, through multiple communication standards for the battery charger to function correctly. Firstly, the voltage, current and temperature of the battery will be monitored by devices which communicate to the microcontroller though the analog to digital converter. Each ATD channel will have a range of 0 to 255, accordingly the input from the monitors will need to be scaled according to some constant and possibly offset to account for negative values. The LCD display communicates through the SCI. This device is not only a screen, but it also has seven debounced pushbuttons, requiring two-way communication between the display and the microcontroller. The digital potentiometers are controlled through the SPI interface. As with all Ethernet capable NE64 microcontrollers, EPHY is used for Ethernet communications.
The main program loop will be organized in a continuous polling fashion. None of the external devices need interrupt driven polling, nor do they have any specific timing parameters. Additionally, the enclosure will have a full time fan, so heat is not a concern. Therefore a continuous polling loop is acceptable in this situation. The loop will check the status of the battery monitoring devices (voltage, current and temperature) to ensure the battery is still charging normally; within the charging profile for that specific battery type. If it is not operating properly, a service routine will handle the irregularity by making changes to the DC-DC converter and updating the LCD and web-based information outputs. The loop will also check the status of two of the Ethernet port and handle and HTTP requests if necessary. The only device which is interrupt- driven is serial communications. The LCD display communicates back to the microcontroller when a pushbutton is pressed or released via the SCI0 port, meaning that the buttons are interrupt- driven input. If any of the buttons are pressed, a service routine will be called to handle any updating that needs to occur. The CMX-MicroNet TCP/IP Stack written for Freescale for use with the NE64 will be used to handle the Ethernet interface [36].
No consideration has been given to self-tests at this time. However, on initialization, every device will be initialized to safe values. For example, the output of the DC-DC converter will be disconnected from the battery charging terminal output by the relay to minimize the risk of damage to the device and the user. There is a BDM port on the PCB of the device used for debugging and testing, but this will not be accessible to the user.
At startup, before the battery charger can perform any of its functional duties, it must go through the setup phase. In setup, the microcontroller writes blank characters to the screen to clear any garbage data that may be there at boot time. Once the screen has been cleared, the microcontroller will send it the commands needed to draw the BatteryMax logo to the screen as well as the root menu at the bottom of the screen. Also during initialization, all the charging circuitry is initialized to safe values. The digital potentiometers are adjusted such that the lowest possible voltage (1.5V) will appear across the terminals. The relay is also switched to the off position, disconnecting the external battery plug from the charging circuit.
Once the battery charger has completed the initialization, it enters into the main program loop. In the main program loop, the microcontroller will check the three analog to digital channels, making sure that the values are close to what is expected. If the values are out of range, then the microcontroller will take corrective measures. After checking the A-to-D channels, it will call the OpenTCP function, which responds to an HTTP request if one is pending. As mentioned previously communication with the screen and pushbuttons is interrupt based, so no polling is necessary for those units.
The menu system implemented on the battery charger has four “soft” buttons, up and down buttons and an enter button. Users will be required to enter parameters such as voltage and capacity for each battery they wish to charge. To make this easier on the user, the up and down buttons are used to input numbers while the four “soft” buttons will perform variable functions depending on what menu the user is currently in. The bottom line of the screen is used for displaying the function of each of the soft buttons at a given time.
10. Version 2.0 Changes
Having successfully designed and built BatteryMax, if it could be done again, some changes would be made. These changes are merely improvements to the design which were realized at a time when it was too late to implement them. The overall project is still a success, but these changes would further enhance the design.
The first change would involve the power supply components, including the adjustable regulators. Currently, linear regulators were used which are quite inefficient. With the experience of one design behind us, I would like to look at using switching power supplies. They are much more efficient at providing power. This would have the benefit of not only producing less waste, but we could possibly reduce the size of the PCB because all of the heatsinksheat sinks may not be necessary.
The second change would involve the layout of the PCB. Not only would some footprint errors be fixed, but a lot more helpful things would have been done to aid in assembly and debugging. A power indicator light would have been put on the board. More vias and probe points would have been placed on the board, allowing easier access when trying to measure specific signals. More silkscreen hints would have been applied to the surface to label key nets and pins. Also, the traces themselves would have been done in a different fashion to decrease the amount of noise. Noise errors were a big problem in the ATD readings made by the microcontroller.
The third change would involve the current sensor. After the layout was complete and the board was sent for manufacturing, a closer look at the datasheet revealed an application which would increase the gain on the current sensor. The default gain is 185 mV/A. Using a single supply op-amp as described in the datasheet, the gain could be increased to 610 mV/A. This would have allowed greater sensitivity when trying to detect the current being delivered to the battery.
The fourth change would have been to add a supervisory circuit to control when the microcontroller was in and out of reset. With the large capacitors on the input to the power supplies, they store quite a bit of charge once the main power is shut off. This residual power continues to supply the microcontroller enough to operate. It slowly is used up, but the microcontroller eventually goes in to a brown out condition every time the power is turned off. A supervisory circuit would be able to pull the reset pin low to send the microcontroller into the reset state while the remaining power is being dissipated.
The final change would have involved the use of the external EEPROM. It was not utilized in the initial version. It was installed but never used. It would have been nice to use the external memory to store more data points, as well as have the option to update the firmware of the microcontroller in case new battery technologies are introduced.
11. Summary and Conclusions
At the end of last semester, BatteryMax began as nothing more than an idea, but over the course of a single semester it was transformed into reality through a logical sequence of steps where every aspect of the project was analyzed in detail. The design process began with the formulation of a block diagram and the outlining of five project specific success criteria (PSSC) for the final design proposal by the end of the second week. In order to come up with viable PSSCs, much time was spent thinking about what exactly would be possible. Restrained by a limited amount of time, and a limited budget, it was clear that not all goals could be met. The PSSCs were selected to be challenging, yet still achievable. With an approved proposal in hand, work started on constraints analysis and component selection. Major components such as the microcontroller and power supply components were researched and selected during this stage. Other parts were chosen to complement the main components such as external EEPROM memory to provide more storage space for recorded statistical data. It was important for this step to be completed early since all subsequent steps depended on the decisions made at this time. The lack of an electrical engineer in the group made early hardware design steps difficult. There was a lot of helpful information given in lectures, so lecture slides were a very valuable resource.
Once the basic design was settled on, some time was spent ensuring that the design would be a complete success. First, a search was conducted for patents which the BatteryMax risked violating. Luckily, battery charging is such a common practice that there was little risk. Next, the reliability of the device was estimated using FMECA. The high voltages with which BatteryMax operates were a safety concern, so steps were taken to improve the safety and reliability. For example, a relay was added to the charging circuit to make disconnecting the battery in the event of a failure easier and a fuse was added to protect sensitive circuits from being damaged by too much current. Also during this stage, the importance of heat sinks and proper ventilation were realized. Before the design process could continue, one final consideration had to be analyzed; the impact of the device on the environment and any ethical implications. Battery recharging technology is a significant benefit to the environment since less waste is produced as a result. This benefit far outweighs the costs of lost energy due to the imperfect efficiency of the recharging process. The optimal operating environment of the device was also found. The main requirement is that the surrounding environment be cool enough to keep the components from overheating.
Design resumed with the decision of how to package BatteryMax. This was a simple choice, the enclosure needed to be large to accommodate the power supply, and it needed to be able to withstand heat. An aluminum box was chosen for its heat resistance and light weight. During the time when the packaging was being worked out, the schematic was finalized and presented. This required quite a bit of time since it required intimate knowledge of Orcad software, something that Computer Engineers don’t often have. Once the schematic was finished, it was time to begin the layout process. This was even more difficult since the layout design tools were not taught in any previous course. The final PCB turned out well, in the end there were only a few footprint errors which were easily corrected by rotating parts or with strategically placed solder. With hardware in hand, software development began. This turned out to be far more difficult than was anticipated. It would have been wise to begin software development sooner using a development board. Unfortunately, there would have been no way to make significant progress without being able to actually test the LCD and the charging circuitry of the BatteryMax PCB. While debugging the software, it was tempting to be quick to blame any problems on faulty components, but in many instances, through careful hardware debugging, the problem was found to be caused by improper usage of the component. Review of the datasheet often unearthed new, useful information.
As the semester comes to an end, the impressive scope of what was accomplished by this project is finally becoming clear. An intelligent, universal battery charger was completed meeting all PSSCs. The entire process, from objectives to evaluation, follows the development process which occurs in industry where many ECE477 students will soon be. Along the way, design review sessions provided valuable feedback from both students and instructors which led to improvements in the device. This course has taught many useful skills including the importance of documenting work as it progresses, the necessity of pre-planning stages, and the benefits of good teamwork. Knowledge gained through lectures, the lessons learned through hands on experience, and interaction with experts are all critical components of a complete ECE education.
12. References
1] Freescale, “MC9S12NE64 Data Sheet,” [Online Document], January 2007, .
2] Rabbit, “RCM4200 Data Sheet,” [Online Document], January 2007,
3] Microchip, “PIC18F97J60 Data Sheet,” [Online Document], January 2007,
4] Crystalfontz, “CFA633 Data Sheet,” [Online Document], January 2007,
5] Fairchild, “MM74C922 Data Sheet,” [Online Document], January 2007,
6] Microchip, “24FC1025 Data Sheet,” [Online Document], January 2007,
7] Analog Devices, “AD5231 Data Sheet,” [Online Document], January 2007,
8] National Semiconductor, “LM117A Data Sheet,” [Online Document], January 2007,
9] United States Patent: 7157883; Method and system for battery protection employing averaging of measurements; January 2, 2007; [INTERNET] (recharge+AND+battery)&OS=recharge+AND+battery&RS=(recharge+AND+battery)
10] United States Patent: 7152168; Recharging power storage devices with power over a network; December 19, 2006; [INTERNET] (recharge+AND+battery)&OS=recharge+AND+battery&RS=(recharge+AND+battery)
11] United States Patent: 7141954; Li-ion/Li-polymer battery charger configured to be DC-powered from multiple types of wall adapters; November 28, 2006; [INTERNET] (recharge+AND+battery)&OS=recharge+AND+battery&RS=(recharge+AND+battery)
12] Department of Defense, “Military Handbook Reliablity Prediction of Electronic Equipment”, [Online Document], accessed February 2007,
13] Freescale, “MC9S12NE64 Data Sheet,” [Online Document], accessed February 2007,
14] National Semiconductor, “LM150 3-Amp Adjustable Regulators,” [Online Document], accessed February 2007,
15] Analog Devices, “Low Voltage Temperature Sensors,” [Online Document], accessed February 2007,
16] Analog Devices, “Digital Potentiometer AD5290,” [Online Document], accessed February 2007,
17] Environmental Protection Agency, “Household Batteries Facts,” [Online Document], accessed February 2007,
18] The Mail, “Toyota Factory Turns Landscape to Arid Wilderness,” [Online Document], accessed February 2007,
19] Cell Power, “Battery Charging Tips,” [Online Document], accessed February 2007,
20] Wikipedia, “Part 15 (FCC Rules),” [Online Document], accessed February 2007,
21] Internation Network for Environmental Compliance and Enforcement, “Printed Circuit Board Manufacturing,” [Online Document], accessed February 2007,
22] NEC Corporation, “Recycling of Printed Circuit Boards,” [Online Document], accessed February 2007,
23] “SONY COMPUTER ENTERTAINMENT INC. TO LAUNCH ITS NEXT GENERATION COMPUTER ENTERTAINMENT SYSTEM, PLAYSTATION 3 IN SPRING 2006,” [Online document] 2005 May 16, [cited 2007 Jan 24], Available HTTP:
24] “Welcome to Quo Vadis Vanson Charger V-8000,” [Online document] 2005 [cited 2007 Jan 24], Available HTTP:
25] “Free Shipping: T6278 Universal Smart Fast Charger with 26-cell package (8AA/8AAA/4C/4D/2 9V)-New!!,” [Online document] 2005 [cited 2007 Jan 24], Available HTTP:
26] Freescale, “MC9S12NE64 Data Sheet,” [Online Document], accessed February 2007, .
27] Crystalfontz, “CFA633 Data Sheet,” [Online Document], accessed February 2007,
28] Analog Devices, “AD5290 Data Sheet,” [Online Document], accessed February 2007,
29] National Semiconductor, “LM150 Data Sheet,” [Online Document], accessed February 2007,
30] National Semiconductor, “Battery Charging,” [Online Document], accessed February 2007,
31] Analog Devices, “TMP37 Data Sheet,” [Online Document], accessed February 2007,
32] “PCB Trace Width Calculator”, [Online Document], accessed February 2007, .
33] Motorola, “Semiconductor Application Note”, [Online Document], accessed February 2007,
34] Freescale, “MC9S12NE64 Data Sheet,” [Online Document], accessed February 2007,
35] Freescale, “MC9S12NE64 Data Sheet,” [Online Document], accessed February 2007, .
36] Freescale, “Basic Web Server Development with MC9S12NE64 and CMX-MicroNet TCP/IP Stack”, [Online Document], accessed February 2007,
Appendix A: Individual Contributions
A.1 Contributions of Ryan Schroeder:
As the team leader, I contributed a lot to the overall project. Early on, I was mainly responsible for coming up with the idea to do a battery charger. I was the main person in charge of forming the group. Once the semester began, I was in charge of both the initial project description homework and final project description homework. In the final project description homework, the team came up with areas of expertise for each person. Since the group consisted of all computer engineers, nobody was really comfortable with the area of expertise that dealt with circuit design. I chose to take on that responsibility because I felt I had a better idea of what the project needed in terms of circuit design.
I began by identifying what circuit components would be necessary to charge a battery. An adjustable voltage would be applied to a battery, which in turn would control how much current would be delivered. A collection of sensors would monitor the voltage, current, and temperature at the battery. The microcontroller would control both of these components, as well as act as the server for the on-chip web page. I selected an adjustable linear regulator to deliver the voltage to the battery because I felt the details of such a circuit would be easier than a switching power supply. A current sensor was also an important component selection that I made. As a team, we all agreed that we would prefer to stick with a Freescale microcontroller because we had all had experience with them. As for the other components, the group weighed in their opinions, but I ended up making the final decision about all of the components.
Since I had selected all of the components, I completed Homework 3 on the component selection. The overall schematic for the circuit was the next step. Once again, having done most of the thought process associated with the circuit design, I felt it was natural for me to create the schematic. Using OrCad, I created a schematic that was basically broken down into five major areas: power supply, adjustable regulator, sensors, microcontroller, and communications. I completed Homework 5 which covered the details of how the circuit operated and specific features of the schematic.
With the schematic complete, the next major step in the design process was the layout of the printed circuit board (PCB). I worked closely with Tom on the initial phases of the layout. Some of our biggest considerations involved heat dissipation while trying to keep the functional blocks of the circuit separated. I created custom footprints for the Ethernet jack, terminal block, reset switch, 8 mH inductor, relay, and trimmer potentiometers.
In preparation for the design review, I put together the slides associated with the Schematic and Theory of Operation. This was also the section that I presented during the design review. After the design review, some key issues were brought to our attention which needed addressing. The discharge circuit had to be modified in order to function properly. I updated the schematic to reflect the changes. The PCB layout also had to be modified. Much of the original layout was carried over to the final version, but I had to make a lot of changes in order to get everything to fit properly. Seven heatsinks were used in the design, which caused a lot of space issues when laying out the PCB. Having selected the parts that would be used in the design, I also felt it a good idea to order them myself through Digi-key. This was done to ensure the correct part was ordered. I even found it difficult because of the sheer number of choices available, even between parts of the same model number.
When we were waiting for the circuit board to be completed, we began working on the programming for the microcontroller. As a help to Dave, I went through the NE64 datasheet and found all of the registers that were relevant to the different peripherals that we would be using. This really helped to speed up the software development process.
When the circuit board arrived, I worked with Tom to start populating the board. We decided to do the assembly in modules, so that we could ensure proper functionality as each module was completed. I began with the power supply components and ensured the incoming AC voltage was properly rectified and stepped down to the appropriate levels. After Tom installed the microcontroller and associated bypass capacitors, I finished off the board by installing the adjustable regulators. They were actually installed rather late in the process. This was done to ensure we had the proper programming in place to control them before they were installed.
With the team mostly going separate ways for the Easter weekend, I decided to take the project home to work on packaging. None of us had any knowledge of CAD programs, so it would have been difficult for us to come up with a diagram that could be used for the machine shop. I also did not have access to very many tools at Purdue. By taking the project home, I was able to complete a good portion of the packaging. A large hole was cut in the top of the box for the LCD and additional holes were cut in the sides for the fans, fuse holder, and power switch. I also created the small modules for the different battery types that we were going to prototype.
With the packaging complete, I turned my focus back to the programming. I experimented with some battery charging algorithms. I had to go back to the design to verify what could and could not be done. I also needed to identify the proper state that the program should start up in to keep the user safe, should a battery already be attached. These functions were written in such a way that they could be slipped in the existing flow of the program.
Once the unit was operational, time was running out in order to get a video demonstration completed to present for bonus credit. After polling the group, nobody had any experience in editing video besides me. Once the footage was collected, I put together the video that we used for the bonus presentation for ECE 362.
Overall, I had a great experience serving as team leader and working with Dave, Jay and Tom. We worked really well together as a team and this project would not have been a success without everyone’s hard work.
A.2 Contributions of Jay Doyle:
At the beginning of the semester, the group gathered our thoughts on what would be required to make a universal battery charger. We came up with four major components, breaking the project into what we thought were four roughly equal sections. As it turned out, it is nearly impossible to determine how much work something is going to be ahead of time, which lead to an unbalanced workload for the four team members of BatteryMax.
I was responsible for the embedded web site on the microcontroller. The embedded web site would need to convey information to the user about individual battery statistics, and also allow the user to control the device through a web browser. To accomplish the first part, I wrote a JavaScript graphing script which would take the data provided by the microcontroller and present it to the user in a readable graph. The second part was achieved by a control page on the embedded web site. This control page was a direct mapping of the physical pushbuttons.
The embedded website alone did not prove to be a large enough portion of the project; the graphing function was mostly completed before spring break. Controlling the device over the web was a different matter, though. Dave and I got that working near the end of the project, as it required a physically working battery charger to built and test. It was a simple matter of requesting webpages from the microcontroller and allowing the web server to parse the requests into commands. Because of the small portion of the total project work I had gotten, I decided to take on most of the documentation for the end of the semester.
At the beginning of the semester, the homework assignments were assigned to various group members. I chose to work on Homework 10 – Software Design and Narrative and Homework 12 – Ethical Environmental Impact. The software design document was a major part of the design for the project. It laid out a diagram of how the software would be written and how it would operate. The ethical and environmental impact analysis was less crucial to the project in terms of design, but was useful in terms of education. I had not previously considered much of the impact of printed circuit boards and integrated circuits.
As the semester came to an end, I started working on the final documentation we would need to submit. I finished most of Homework 13 – User Manual, but handed it off to Dave for completion after I read that each team member should have a hand in writing it. I also did Homework 17 – Group Poster for the team. The parts of Homework 16 – Final Report which were not condensed homework assignments were written by me, apart from the last two sections.
In addition to the writing of documents, I was mainly responsible for the images seen in the reports. I have some experience with Flash, and it proved to be an invaluable tool for making diagrams and charts needed for the documentation and presentations. The User manual especially needed accurate diagrams of the project, which Flash was able to produce easily. (Though making the images was time consuming.) I also made and maintained the group website throughout the semester.
When looking back on the project after graduation, I will remember it as an overall fun and rewarding project. Seeing something come to life in the way our project did is always fulfilling. Though if I had to do it all over again, I would put more work into the programming of the project. I enjoy programming, and was disappointed that I couldn’t play more of a role in programming our device. Overall I feel my contribution was fair, but that our project may have been too simple for four people.
A.3 Contributions of Dave Canada:
Though a battery charger may sound like a simple project, BatteryMax was anything but simple. Designing and constructing any embedded system will always be a time consuming and challenging process, but with the help of a dedicated team, anything is possible. My role in the group was the primary software developer.
At the start of the semester, my contributions were primarily related to completing homework assignments. Working with the rest of the team, I helped write the Team Building and Project Idea homework and the Final Project Proposal in the first two weeks. After that, I researched online and in local electronics stores for good and bad examples of packaging used in existing devices. I used these examples for the Packaging Specifications and Design homework in which I proposed a design for BatteryMax which included a main enclosure which housed the massive power supply circuit along with an external battery holder which would separate the battery being charged from the heat generated by the power regulation circuit. I was extremely concerned by the risk of BatteryMax overheating and damaging itself or injuring myself or a teammate so I worked to make sure that there was ample room within the enclosure for heat sinks and I placed fans on the case to help circulate air. Immediately after the packaging homework was complete, I moved on to the Patent Liability Analysis homework. I found that there was little risk of the BatteryMax violating any existing patents since battery technology is so widespread now. When it came time to begin designing the schematic, I worked with Jay to re-familiarize ourselves with Orcad’s software. I found that many of our parts were missing from Orcad’s part database so I designed parts for our microcontroller, temperature sensor, and regulators. At this time, the Freescale MC9S12NE64 microcontroller had been selected, so I began reading up on its datasheet and support documentation in anticipation of the long software development process ahead.
Once we obtained the NE64 development board from Freescale along with the CodeWarrior software, I began to write simple programs which I thought would be useful for our final code. Ryan and I implemented a program which would detect when buttons were pressed and would light up a corresponding LCD. After that, I moved on to working with OpenTCP code which would be the basis of Battery Max’s built-in web server. Early on, it was clear that the RAM space available on the NE64 would be a significant hindrance of our goal of tracking battery statistics over time. Since there was no way to add external memory to the dev board, I came up with a plan for how to make battery statistics data available through the website. We decided to build a JavaScript file which contained empty data arrays that the microcontroller would be able to populate and serve to the user through the web server. The JavaScript file would then be processed at the client side to create a graph of the statistic data over time. Jay wrote this JavaScript graphing page. I also got the SCI sending code working in preparation for controlling our LCD. Not much more programming could be done on the dev board without our LCD and charging circuit, so once our PCB and components arrived, I brushed up my soldering skills on the practice boards, but in the end, Tom and Ryan soldered most of the components to our PCB. The first section of the board to be populated was the microcontroller. Once the PCB was ready for our LCD I began to code some wrapper functions for the various commands supported by our LCD which would make it easy to display text or draw shapes on the LCD. With a working LCD, I developed a menu system for controlling the BatteryMax. This involved writing an SCI Receive function using interrupts to get keypress responses from the LCDs keypad and developing a state machine to track the current menu state so that the next menu state could be determined. Once the menu system was working, I developed a scheme for controlling the device through the web server. Instead of adding large UDP code to our project and developing a client-side software control solution, I chose to modify the hashing function which the web server uses to find what data to return for an HTTP GET request so that it would recognize certain requests and perform special actions. One of the biggest challenges I faced was developing a method of manipulating the data within the existing JavaScript data file described earlier. The data positions are known, and the microcontroller modifies one position at a time. If the array fills up, previous data points are all moved back and the current data is placed in the last spot of the array. I also incorporated battery charging code developed by Ryan into our main project.
I am proud of what I have accomplished as an individual and as a member of such an excellent team. I look forward to more digital systems design experiences like this one in my future.
A.4 Contributions of Tom Germon:
We built the BatteryMax Universal Battery Charger as a team, but the work was divided among the team members. Wwhen designing and building the BatteryMax, I worked on the initial circuit design. I helped make the original considerations for the project into a working circuit. I helped do the research on the charging curves for the different battery types. I designed some parts for the circuit design that were not in the existing libraries, and I built a library to hold those parts. I designed some of the PCB layout footprints for several parts that were not in the existing database. I created a library to hold those parts. I ordered some extra sample parts to be used in our project, just in case we permanently damaged our existing ones, specifically microcontrollers. I soldered the microcontroller and the peripherals for the microcontroller onto the PCB. The first time I soldered the microcontroller, I ended up damaging it and had to remove it. The second time went much better than the first. The peripherals I soldered included the bypass capacitors, the oscillator, the Ethernet module and the resistors that are required to make the microcontroller work. I also soldered most of the surface mount parts on the PCB. I tested the parts that I put on the board to ensure functionality and connectivity.
I created one of the layout versions for the PCB. ; sSpecifically the one that was given in the midterm design review. I made the PowerPoint and gave the presentation for TCSP2. I made the slides for my part of the midterm design review, as well as talked about it in the review itself. I made the PowerPoint for the bonus presentation for ECE362, and talked about my slide during the presentation.
I assisted with homework 1: the Team Building and Project Idea. I assisted with homework 2: the Final Project Proposal. I assisted with homework 3: the Design Constraint Analysis. I assisted with homework 4: the Packaging Specifications and Design. I completed the initial homework 6: the Printed Circuit Board Layout Narrative, and revised it to be included with the final report. I completed the initial homework 11: the Reliability and Safety Analysis, and revised it to be included with the final report. I completed homework 15: the ECE Senior Design Report.
Appendix B: Packaging
[pic]
Figure B1 – Front Panel with LCD Display
[pic]
Figure B2 – Side Panel with Power Connection
[pic]
Figure B3 – Side Panel with Ethernet Port
[pic]
Figure B4 – Back Panel with Cooling Fans
[pic]
Figure B5 – AA Battery Holder
[pic]
Figure B6 – Isometric Product View
Appendix C: Schematic
[pic]
Figure C1 – Microcontroller and Supporting Circuitry
[pic]
Figure C2 – Power Supply and Linear Regulators
[pic]
Figure C3 – Digital Potentiometers
[pic]
Figure C4 – Serial Ports and Flash Memory Modules
[pic]
Figure C5 – Relay, Battery Connector, Current Sensor, Voltage Sensor, Discharge Circuit, Fans
Appendix D: PCB Layout Top and Bottom Copper
[pic]
Figure D1 – PCB Top Copper Layer with Silk Screen
[pic]
Figure D2 – PCB Bottom Copper Layer with Silk Screen
Appendix E: Parts List Spreadsheet
|Vendor |Manufacturer |Part No. |Description |Unit Cost |Qty |Total Cost |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|TOTAL |$289.90 |
Appendix F: Software Listing
////////////////////////////////////////////////
// system.h
// Contains Constants and global variables used
// among different files.
////////////////////////////////////////////////
#ifndef SYSTEM_H_INCLUDE
#define SYSTEM_H_INCLUDE
#include "os.h"
#include "ne64api.h"
#include "datatypes.h"
#include "globalvariables.h"
/** \def OPENTCP_VERSION
* \brief OpenTCP major version number
*
* This define represents OpenTCP version information. Version
* is in the format MAJOR.MINOR.PATCH.
*/
#define OPENTCP_VERSION "1.0.4"
/* Boolean values*/
#define TRUE 1 /**< Boolean TRUE value as used in the OpenTCP */
#define FALSE 0 /**< Boolean FALSE value as used in the OpenTCP */
/** \def NETWORK_TX_BUFFER_SIZE
* \ingroup opentcp_config
* \brief Transmit buffer size
*
* NETWORK_TX_BUFFER_SIZE defines the size of the network buffer
* used for data transmission by ICMP as well as TCP and UDP applications.
*
* See net_buf documentation for more reference on the shared transmit
* buffer.
*/
//#define NETWORK_TX_BUFFER_SIZE 1518
//#define NETWORK_TX_BUFFER_SIZE 1024
#define NETWORK_TX_BUFFER_SIZE 128
/** \struct netif system.h
* \brief Network Interface declaration
*
* This structure holds information about the network interface. This means
* that all of the network-related information are stored in this kind
* of structure.
*/
struct netif
{
/** \brief IP address of a device
*
* IP address of a happy device using OpenTCP :-). This must hold
* proper-value IP address in order for the networking stuff to work.
*
* Possible scenarios for filling this field are:
* \li By assigning static IP address to a device always after reset
* \li By allowing user to choose IP address by some tool (e.g. through
* serial communication, storing that information to some external
* flash,...)
* \li By using BOOTP or DHCP clients for obtaining dynamically
* assigned address
* \li By obtaining the IP address from the first ICMP packet
* the device receives
*
* First three approaches can also be used for obtaining gateway
* and subnet-mask information.
*/
LWORD localip;
/** \brief Ethernet address given to a device
*
* This array holds an Ethernet address assigned to a device. Note that
* these must be unique so if you're shipping your product to outside
* world you must purchase sufficient address range.
*
*/
BYTE localHW[6];
/** \brief Default network gateway
*
* IP address of a default network gateway. This is needed if the
* device is to communicate with the outside network (Internet) and
* not only intranet.
*/
LWORD defgw;
/** \brief Network submask
*
* Network submask. Also needed if the the device is to communicate
* with the outside network. Used when determining whether the
* host we're sending some data to is on the local network (send
* data directly) or not (send through gateway).
*/
LWORD netmask;
};
/* System variable definitions */
#define MASTER_MS_CLOCK base_timer /**< Interrupt driven msec free-running clock */
#define TXBUF net_buf /**< TXBUF points to transmit network buffer */
/* System macros */
/** \def RESET_SYSTEM
* \brief Macro used to reset the MCU
*
* By default this macro is only an infinite loop and the system is
* reset by the (presumably) running watchdog timer.
*
* Change this if another form of reset is desired/needed.
*/
#define RESET_SYSTEM() for(;;) {} /* Let the watchdog bite */
/** \def OS_EnterCritical
* \brief Macro used to enter critical sections
* \todo
* \li Move this to other arch-dependant place
*
* This is highly dependant on the architecture that is used and/or
* possible operating system beeing used so it will be moved to some
* other place in the future.
*
* Usually disabling globally interrupts works just fine :-)
*/
#define OS_EnterCritical OS_ENTER_CRITICAL
/** \def OS_ExitCritical
* \brief Macro used to exit critical sections
* \todo
* \li Move this to other arch-dependant place
*
* This is highly dependant on the architecture that is used and/or
* possible operating system beeing used so it will be moved to some
* other place in the future.
*
* For now this only globally enables interrupts
*/
#define OS_ExitCritical OS_EXIT_CRITICAL
/** \def RECEIVE_NETWORK_B
* \brief Use this macro to read data from Ethernet controller
*
* This macro should be used to read data from the Ethernet
* controller. Procedure for doing this would be as follows:
* \li Initialize reading of data from certain address in the
* Ethernet controller (usually you will do that based on buf_index
* value of ip_frame, udp_frame or tcp_frame type of variables;
* in certain special situations you can also use buf_index from
* ethernet_frame type of var.
* \li Keep invoking RECEIVE_NETWORK_B() to read one byte at a time from
* the ethernet controller. Take care not to read more data than
* actually received
* \li If needed, reinitialize reading of data again and start all
* over again
* \li When finished discard the current frame in the Ethernet
* controller by invoking NETWORK_RECEIVE_END() macro
*
*/
#define RECEIVE_NETWORK_B() NE64ReadByte()
/** \def RECEIVE_NETWORK_W
* \brief Use this macro to read data from Ethernet controller
*
* This macro should be used to read data from the Ethernet
* controller. Procedure for doing this would be as follows:
* \li Initialize reading of data from certain address in the
* Ethernet controller (usually you will do that based on buf_index
* value of ip_frame, udp_frame or tcp_frame type of variables;
* in certain special situations you can also use buf_index from
* ethernet_frame type of var.
* \li Keep invoking RECEIVE_NETWORK_W() to read one word at a time from
* the ethernet controller. Take care not to read more data than
* actually received
* \li If needed, reinitialize reading of data again and start all
* over again
* \li When finished discard the current frame in the Ethernet
* controller by invoking NETWORK_RECEIVE_END() macro
*
*/
#define RECEIVE_NETWORK_W() NE64ReadWord()
/** \def RECEIVE_NETWORK_BUF
* \brief Use this macro to read data from Ethernet controller to a buffer
*
* This macro should be used to read data from the Ethernet
* controller to a buffer in memory. Procedure for using this macro
* is the same as for using RECEIVE_NETWORK_B() macro.
*
*/
#define RECEIVE_NETWORK_BUF(c,d) NE64ReadBytes(c,d)
/** \def SEND_NETWORK_B
* \brief Use this macro to write data to Ethernet controller
*
* This macro should be used to write data to Ethernet
* controller. Procedure for doing this would be as follows:
* \li Initialize writing of data to certain address in the
* Ethernet controller. Buffer space in Ethernet controller is
* divided among the protocols in the following way:
* \li 256 byte Tx for ARP (see ARP_BUFFER )
* \li 1536 byte Tx for ICMP (see ICMP_BUF)
* \li 1536 byte Tx for TCP (see TCP_BUF)
* \li 1536 byte Tx for UDP (see UDP_BUF)
* \li Write the data by using SEND_NETWORK_B() macro
* \li When all of the data is written instruct the Ethernet controller
* to send the data by calling the NETWORK_COMPLETE_SEND() macro with
* number of bytes to send as a parameter
*
*/
#define SEND_NETWORK_B(c) NE64WriteByte(c)
/** \def SEND_NETWORK_W
* \brief Use this macro to write data to Ethernet controller
*
* This macro should be used to write data to Ethernet
* controller. Procedure for doing this would be as follows:
* \li Initialize writing of data to certain address in the
* Ethernet controller. Buffer space in Ethernet controller is
* divided among the protocols in the following way:
* \li 256 byte Tx for ARP (see ARP_BUFFER )
* \li 1536 byte Tx for ICMP (see ICMP_BUF)
* \li 1536 byte Tx for TCP (see TCP_BUF)
* \li 1536 byte Tx for UDP (see UDP_BUF)
* \li Write the data by using SEND_NETWORK_W() macro
* \li When all of the data is written instruct the Ethernet controller
* to send the data by calling the NETWORK_COMPLETE_SEND() macro with
* number of bytes to send as a parameter
*
*/
#define SEND_NETWORK_W(c) NE64WriteWord(c)
/** \def SEND_NETWORK_BUF
* \brief Use this macro to write data from buffer to Ethernet controller
*
* This macro should be used to write data from a buffer to Ethernet
* controller. Usage is the same as for the SEND_NETWORK_B() macro.
*/
#define SEND_NETWORK_BUF(c,d) NE64WriteBytes(c,d)
/** \def NETWORK_CHECK_IF_RECEIVED
* \ingroup periodic_functions
* \brief Use this macro to check if there is recieved data in Ethernet controller
*
* Invoke this macro periodically (see main_demo.c for example) to check
* if there is new data in the Ethernet controller.
*
* If there is new data in the Ethernet controller, this macro (function
* that it points to that is) will return a value of TRUE and fill in
* the appropriate values in the received_frame variable. Otherwise it
* returns FALSE.
*/
#define NETWORK_CHECK_IF_RECEIVED() NE64ValidFrameReception()
/** \def NETWORK_RECEIVE_INITIALIZE
* \brief Initialize reading from a given address
*
* This macro initializes reading of the received Ethernet frame from
* a given address in the Ethernet controller.
*/
#define NETWORK_RECEIVE_INITIALIZE(c) NE64InitializeOffsetToReadRxBuffer(c)
/** \def NETWORK_RECEIVE_END
* \ingroup periodic_functions
* \brief Dump received packet in the Ethernet controller
*
* Invoke this macro when the received Ethernet packet is not needed
* any more and can be discarded.
*/
#define NETWORK_RECEIVE_END() NE64FreeReceiveBuffer()
/** \def NETWORK_COMPLETE_SEND
* \brief Send the Ethernet packet that was formed in the Ethernet controller
*
* After the data has been written to the Ethernet controller, use this
* function to instruct the Ethernet controller that data is in it's
* internal buffer and should be sent.
*/
#define NETWORK_COMPLETE_SEND(c) NE64StartFrameTransmission(c)
/** \def NETWORK_SEND_INITIALIZE
* \brief Initialize sending of Ethernet packet from a given address
*
* Use this function to initialize sending (or creating) of an Ethernet
* packet from a given address in the Ethernet controller.
*/
#define NETWORK_SEND_INITIALIZE(c) NE64InitializeTransmissionBuffer(c)
/** \def NETWORK_ADD_DATALINK
* \brief Add lower-level datalink information
*
* This implementation adds Ethernet data-link information by
* invoking WriteEthernetHeader() function that writes Ethernet
* header based on information provided (destination and source ethernet
* address and protocol field).
*/
#define NETWORK_ADD_DATALINK(c) NE64WriteEthernetHeaderToTxBuffer((struct TEthernetFrame*)c)
/* System functions */
extern void kick_WD (void);
extern void wait (INT16);
extern void enter_power_save (void);
extern void exit_power_save (void);
extern INT16 __strlen (UINT8*, UINT16);
extern INT16 bufsearch (UINT8*, UINT16, UINT8*);
extern UINT16 hextoascii (UINT8);
extern void __itoa (UINT16, UINT8*);
extern void __ltoa (UINT32, UINT8*);
extern INT16 __atoi (UINT8*, UINT8);
extern UINT8 asciitohex (UINT8);
extern UINT8 isnumeric (UINT8);
extern void mputs (INT8*);
void mputhex (UINT8);
extern UINT32 random (void);
extern void dummy (void);
extern UINT8 __tolower (UINT8);
extern UINT8 __toupper (UINT8);
/* External functions */
extern void init(void);
extern void WriteToSCI0(const char *);
extern void WriteToSCI1(const char *);
//extern uint8 ReadSCI1(void);
//extern void SCI1Interrupt(void);
/* LCD Functions */
extern void LCDPixel(int8,int8,int8);
extern void LCDLine(int8,int8,int8,int8,int8);
extern void LCDCircle(int8,int8,int8,int8);
extern void SetBacklight(int8);
extern void LCDClear(uint8);
extern void LCDPrint(int8,int8,int8,int8,int8,char *);
extern void LCDTone(int16,int8);
extern void LCDGraphic(int8,int8,int8);
extern void LCDBox(int8,int8,int8,int8,int8);
extern void LCDMenu(void);
extern void LCDMenuText(char *);
//mainwebserver.c
#define MAX_CAPACITY 5000
#define MAX_VOLTAGE 250
#define MAX_BATTERY_ID 4 // 0-4
#define NUM_TECHS 4
#define NUM_DATA_POINTS 20
extern void StartCharging(void);
extern void StartTesting(void);
extern void StartDraining(void);
extern void Stop(void);
extern void StartCharging(void);
//extern void DoCharging(void);
//extern void CheckStatus(void);
//extern void SetBatteryType(enum BatteryTypes);
extern void SetBatteryTech(enum BatteryTechnologies);
extern void SetKeypress(uint8 button);
//Menu
enum LCDmenu {Main,New,Charge,Drain,Status,Setup,SelID,List,Add,SetupT,SetupV,SetupC};
//enum BatteryTypes {AAA,AA,C,D,NineV,noType};
enum BatteryTechnologies {NiCad=0,NiMH,LiIon,LeadAcid,noTech};
//extern enum BatteryTypes selectedType;
struct batteryProfile {
unsigned int voltage;
unsigned int currentCapacity;
enum BatteryTechnologies selectedTech;
};
extern struct batteryProfile batteries[MAX_BATTERY_ID+1];
//extern enum BatteryTechnologies selectedTech;
extern uint8 scrollMenuSelected; //Starts at the 4th menu item
extern uint8 isCharging;
extern uint8 isDraining;
extern uint8 buttonPressed;
//Flag which is set only if the menu is changed.
//This allows us to avoid spamming the LCD with commands which slow our loop considerably
extern uint8 menuchanged; //Set initially so that the menu gets displayed on reset
extern const char battTechs[][9];
//extern unsigned int voltage; // Last digit is one decimal place
//extern unsigned int currentCapacity; //mAh
extern uint8 batteryID;
//charging.c
#define BM_ATD_CTL2 0xC0 //11000000
#define BM_ATD_CTL3 0x20 //00100000
#define BM_ATD_CTL4 0x73 //01110011
#define BM_ATD_START ATDCTL5
#define BM_ATD_READ_ALL 0x10
#define BM_ATD_DONE ATDSTAT0_SCF
#define BM_ATD_VOLTAGE ATDDR0H
#define BM_ATD_CURRENT ATDDR1H
#define BM_ATD_BTEMP ATDDR2H
#define BM_ATD_UTEMP ATDDR3H
#define BM_SPI_BAUD 0x40
#define BM_SPI_CR1 0x50
#define BM_SPI_CR2 0x00
#define BM_SPI_DONE SPISR_SPTEF
#define BM_POT_DATA SPIDR
#define BM_POT_SELECT PORTB
#define BM_POT_NONE 0xFF
#define BM_POT_FINE1 0xFD
#define BM_POT_COURSE1 0xFE
#define BM_POT_FINE2 0xF7
#define BM_POT_COURSE2 0xFB
#define BM_POT_VSENSE 0xEF
#define BM_POT_DISCHARGE 0xDF
#define BM_POT_ALL 0xC0
#define BM_OP_IDLE 0
#define BM_OP_CHARGING 1
#define BM_OP_DISCHARGING 2
#define BM_OP_TESTING 3
#define BM_OP_COMPLETE 4
#define BM_CURRENT_MULTIPLIER 70
#define BM_VOLTAGE_MULTIPLIER 330
#define BM_TEMP_MULTIPLIER 180 / 255
#define BM_NIMH_MAX_DELTA_T 255
#define BM_NICAD_MAX_DELTA_T 255
#define BM_LEAD_MAX_DELTA_T 255
#define BM_LIION_MAX_DELTA_T 255
#define rlyRelay PTG_PTG0
#define ON 1;
#define OFF 0;
enum chargeState {initialize=0,rampup,constantcurrent,constantvoltage,terminate,complete};
extern enum chargeState bmOperationState;
extern void InitATD(void);
extern void InitSPI(void);
extern void InitIIC(void);
extern void InitRelay(void);
extern void ReadATD(void);
extern void SetPOT(uint8, uint8);
extern void ChargeVoltageInit(uint8);
extern void ChargeVoltageIncrease(void);
extern void ChargeVoltageDecrease(void);
extern void ChargeCircuitOn(void);
extern void ChargeCircuitOff(void);
extern void ChargeBattery(void);
extern void DischargeBattery(void);
extern void TestBattery(void);
extern void ChargeNIMH(void);
extern void ChargeNICAD(void);
extern void ChargeLIION(void);
extern void ChargeLEAD(void);
extern void DischargeNIMH(void);
extern void DischargeNICAD(void);
extern void DischargeLEAD(void);
extern void DischargeLIION(void);
extern uint8 atdVoltage;
extern uint8 atdCurrent;
extern uint8 atdBTemp;
extern uint8 atdUTemp;
//extern uint8 bmOperationState;
extern uint8 spiDPot1Fine;
extern uint8 spiDPot1Course;
extern uint8 spiDPot2Fine;
extern uint8 spiDPot2Course;
extern uint8 spiDPotVSense;
extern int bmChargeCurrent;
extern int bmChargeVoltage;
extern int bmChargeBTemp;
extern int bmChargeUTemp;
#endif
////////////////////////////////////////////////
// http_server.c
// OpenTCP http server code with some modifications
// done to the hash function to allow control
// through the web.
////////////////////////////////////////////////
#include"datatypes.h"
#include"globalvariables.h"
#include"debug.h"
#include"system.h"
#include"tcp_ip.h"
#include"http_server.h"
UINT8 https_enabled = 0; /**< Defines whether https_init has already been invoked or not */
/** \brief Used for storing state information about different HTTP sessions
*
* This is an array of http_server_state structures holding various state
* information about the HTTP sessions. HTTP server uses this information
* to determine actions that need to be taken on sockets.
*/
struct http_server_state https [NO_OF_HTTP_SESSIONS];
/** \brief Initialize HTTP server variables
* \author
* \li Jari Lahti (jari.lahti@)
* \date 13.10.2002
*
* This function should be called before the HTTP Server application
* is used to set the operating parameters of it
*/
INT8 https_init(void)
{
UINT8 i;
INT8 soch;
for( i=0; i= https[ses].flen)
{
(void)tcp_close(https[ses].ownersocket);
(void)tcp_abort(https[ses].ownersocket);
https_deletesession(ses);
ses++;
return;
}
/* More data to send */
len = https_loadbuffer(ses, &net_buf[TCP_APP_OFFSET], NETWORK_TX_BUFFER_SIZE - TCP_APP_OFFSET);
if(len> 8) & 0x0F ); //26-4095 (1A-FFF) Three Digit ASCII Hex. Freq of 0 turns off any tone
command[3] = hextoascii( (frequency >> 4) & 0x0F );
command[4] = hextoascii(frequency & 0x00F);
command[5] = hextoascii(duration >> 4); //Duration 0-255 Two Digit ASCII Hex. Fiftieths of a second
command[6] = hextoascii(duration & 0x0F);
command[7] = 0x03; //
command[8] = '\0'; //null terminate the command
LCDSendCommand(command);
}
/*
void LCDGraphic(int8 row,int8 column,int8 data) {
command[0] = 0x01; //
command[1] = 'G';
command[2] = hextoascii(row >> 4); //Row 0-255 bit mask
command[3] = hextoascii(row & 0x0F);
command[4] = hextoascii(column >> 4); //Column 0-127 bit mask
command[5] = hextoascii(column & 0x0F);
command[6] = hextoascii(data >> 4); //Data 0-255 binary pattern
command[7] = hextoascii(data & 0x0F);
command[8] = 0x03; //
command[9] = '\0'; //null terminate the command
LCDSendCommand(command);
}
*/
void LCDBox(int8 tlx,int8 tly,int8 brx,int8 bry,int8 color) {
command[0] = 0x01; //
command[1] = 'B';
command[2] = hextoascii(tlx >> 4); //Top Left X 0-127
command[3] = hextoascii(tlx & 0x0F);
command[4] = hextoascii(tly >> 4); //Top Left Y 0-63
command[5] = hextoascii(tly & 0x0F);
command[6] = hextoascii(brx >> 4); //Bottom Right X 0-127
command[7] = hextoascii(brx & 0x0F);
command[8] = hextoascii(bry >> 4); //Bottom Right Y 0-63
command[9] = hextoascii(bry & 0x0F);
command[10] = hextoascii(color & 0x01);
command[11] = 0x03; //
command[12] = '\0'; //null terminate the command
LCDSendCommand(command);
}
void LCDMenu(void) {
char buff[5];
char sendstring[30];
uint8 i;
uint8 sendstringpos;
LCDClear(127); //Clear all rows except last
LCDBox(26,4,92,42,1);
LCDBox(92,19,96,28,1);
LCDPrint(1, 0, 4, 1, 1, "BatteryMAX"); //Normal text
LCDPrint(2, 0, 4, 1, 1, "Universal"); //Normal text
LCDPrint(3, 0, 4, 1, 1, "Battery"); //Normal text
LCDPrint(4, 0, 4, 1, 1, "Charger"); //Normal text
__itoa(batteries[batteryID].voltage/10,(UINT8*)buff);
sendstringpos=0;
sendstring[sendstringpos++] = hextoascii(batteryID);
sendstring[sendstringpos++] = ':';
sendstring[sendstringpos++] = ' ';
i=0;
while(buff[i] != '\0') {
sendstring[sendstringpos++] = buff[i++];
}
sendstring[sendstringpos++] = '.';
sendstring[sendstringpos++] = hextoascii(batteries[batteryID].voltage%10);
sendstring[sendstringpos++] = 'V';
sendstring[sendstringpos++] = ' ';
i=0;
while(battTechs[batteries[batteryID].selectedTech][i] != '\0') {
sendstring[sendstringpos++] = battTechs[batteries[batteryID].selectedTech][i++];
}
sendstring[sendstringpos++] = ' ';
__itoa(batteries[batteryID].currentCapacity,(UINT8*)buff);
i=0;
while(buff[i] != '\0') {
sendstring[sendstringpos++] = buff[i++];
}
sendstring[sendstringpos++] = 'm';
sendstring[sendstringpos++] = 'A';
sendstring[sendstringpos++] = 'h';
sendstring[sendstringpos] = '\0';
LCDPrint(6, 0, 2, 1, 1, sendstring);
LCDLine(0,55,127,55,1); //Bar above menu text
}
//LCDPrint(row,column,font,type,justification,char *text) {
void LCDMenuText(char *text) {
// LCDPrint(7, 0, 2, 2, 1, text); //Inverse text
LCDClear(128);
LCDLine(0,55,127,55,1); //Bar above menu text
LCDPrint(7, 0, 2, 1, 1, text); //Normal text
}
////////////////////////////////////////////////
// Init.c
// Contains initialization routines and functions
// for sending data through SCI0 and SCI1
////////////////////////////////////////////////
#include "ne64debug.h"
#include "datatypes.h"
#include "MC9S12NE64.h"
//BE SURE TO ADD PROTOTYPES TO SYSTEM.H
extern uint8 buttonPressed;
//===================================================
/* send string via SCI */
//===================================================
void sendtext(tS08 * s)
{
while (*s != 0) {
while (!(SCI0SR1 & 0x80));
SCI0DRL =*s;
s++;
}
}
void WriteToSCI0(const char *text){
while (*text != '\0'){
while (!(SCI0SR1 & 0x80)); // wait for output buffer empty
SCI0DRL = *text++;
}
//while (!(SCI0SR1 & 0x80)); // wait for output buffer empty
//SCI0DRL = '\r';
//while (!(SCI0SR1 & 0x80)); // wait for output buffer empty
//SCI0DRL = '\n';
}
//LCD is SCI1
void WriteToSCI1(const char *text){
while (*text != '\0'){
// wait for output buffer empty
while (!(SCI1SR1 & 0x80)); //TDRE Transmit Data Register Empty
SCI1DRL = *text++;
}
}
interrupt void SCI1Interrupt(void) {
char command[10];
int i;
i=0;
command[i] = SCI1SR1;
while(i < 5) {
if(SCI1SR1 & 0x20) {
command[i] = SCI1DRL;
i++;
}
}
command[i] = '\0';
buttonPressed = command[3]-'0';
// WriteToSCI0("Received:");
// WriteToSCI0(command);
}
/******************************************************************************
*
*
******************************************************************************/
void init (void)
{
#define BAUD_RATE 9600
//#define BAUD_RATE 57600
#define ECLK 25000000 /**< this is BUSCLK */
#define BAUD_DIV ECLK/16/BAUD_RATE
//Debug Inits
_INIT_DEBUG();
SCI0BD= BAUD_DIV;
//Clearing the M bit in SCICR1 = 8-bit
SCI0CR1= 0;
SCI0CR2= SCI1CR2_TE_MASK | SCI1CR2_RE_MASK | SCI1CR2_RWU_MASK ;
// SCI1BDL = (unsigned char)((25000000UL /* OSC freq */ / 2) / 9600 /* baud rate */ / 16 /*factor*/);
// SCI1CR2 = 0x2C;
SCI1BD= BAUD_DIV;
SCI1CR1= 0;
SCI1CR2= SCI1CR2_RIE_MASK | SCI1CR2_TE_MASK | SCI1CR2_RE_MASK | SCI1CR2_RWU_MASK ;
}
////////////////////////////////////////////////
// charging.c
// Contains functions for charging and discharging
// batteries. Also contains initialization routines
// for SPI, ATD, I2C, and the relay circuit.
////////////////////////////////////////////////
#include /* common defines and macros */
#include /* derivative information */
// Added to system.h
uint8 atdVoltage;
uint8 atdCurrent;
uint8 atdBTemp;
uint8 atdUTemp;
enum chargeState bmOperationState;
uint8 spiDPot1Fine;
uint8 spiDPot1Course;
uint8 spiDPot2Fine;
uint8 spiDPot2Course;
uint8 spiDPotVSense;
int bmChargeCurrent;
int bmChargeVoltage;
int bmChargeBTemp;
int bmChargeUTemp;
//
char spiDischarge;
char sciKey;
char fNewBattery;
char fKeypad;
char fTimeToSave;
char bmOperation;
char bmID;
char bmProfile;
//char bmType;
char bmDeltaT;
char bmChargeTimeD;
char bmChargeTimeH;
char bmChargeTimeM;
char bmChargeTimeS;
char bmTotalTimeD;
char bmTotalTimeH;
char bmTotalTimeM;
char bmTotalTimeS;
char bmSaveInterval;
char bmSaveVoltage;
char bmSaveCurrent;
char bmSaveTemp;
char bmSaveCount;
//char bmSavedData[128];
char bmSavedDataCount;
char sysTime;
void InitATD()
{
ATDCTL2 = BM_ATD_CTL2;
ATDCTL3 = BM_ATD_CTL3;
ATDCTL4 = BM_ATD_CTL4;
}
void InitSPI(void)
{
DDRB = 0xFF;
PORTB = 0xFF;
SPIBR = BM_SPI_BAUD;
SPICR1 = BM_SPI_CR1;
SPICR2 = BM_SPI_CR2;
}
void InitIIC(void)
{
IBAD = 0xFF;
IBFD = 0xBF;
IBCR = 0x80;
}
void InitRelay(void)
{
NETCTL = 0x00;
DDRG = 0x01;
RDRG = 0x00;
PERG = 0x00;
PPSG = 0x00;
}
void ReadATD(void)
{
BM_ATD_START = BM_ATD_READ_ALL;
while(!BM_ATD_DONE);
atdVoltage = BM_ATD_VOLTAGE;
atdCurrent = BM_ATD_CURRENT;
atdBTemp = BM_ATD_BTEMP;
atdUTemp = BM_ATD_UTEMP;
bmChargeCurrent = (atdCurrent-127) * BM_CURRENT_MULTIPLIER;
bmChargeVoltage = atdVoltage * BM_VOLTAGE_MULTIPLIER / spiDPotVSense;
bmChargeBTemp = (atdBTemp * BM_TEMP_MULTIPLIER + 32) * 10;
bmChargeUTemp = (atdUTemp * BM_TEMP_MULTIPLIER + 32) * 10;
}
void SetPOT(uint8 chip, uint8 value)
{
byte temp = SPISR;
BM_POT_SELECT = chip;
WriteToSCI0(" \b \b \b \b \b");
BM_POT_DATA = value;
WriteToSCI0(" \b \b \b \b \b");
while(!BM_SPI_DONE);
BM_POT_SELECT = BM_POT_NONE;
}
void ChargeVoltageInit(uint8 v)
{
//int temp;
//temp = ((MAX_VOLTAGE - v) / 2) + v;
//spiDPot1Course = VTable[temp];
//spiDPot1Fine = VTable[temp];
//spiDPot2Course = VTable[v];
//spiDPot2Fine = 0;
int temp = 123;
temp = temp + v;
if (temp > 255) {
temp = 255;
}
spiDPot1Fine = temp;
spiDPot1Course = temp;
spiDPot2Fine = 127;
spiDPot2Course = 0;
SetPOT(BM_POT_FINE1, spiDPot1Fine);
SetPOT(BM_POT_COURSE1, spiDPot1Course);
SetPOT(BM_POT_FINE2, spiDPot2Fine);
SetPOT(BM_POT_COURSE2, spiDPot2Course);
}
void ChargeVoltageIncrease(void)
{
if (spiDPot2Fine == 255)
{
if (spiDPot2Course == 255) {
return;
}
spiDPot2Course++;
spiDPot2Fine = 127;
} else {
spiDPot2Fine++;
}
SetPOT(BM_POT_FINE2, spiDPot2Fine);
SetPOT(BM_POT_COURSE2, spiDPot2Course);
}
void ChargeVoltageDecrease(void)
{
if (spiDPot2Fine != 0) {
spiDPot2Fine--;
}
if (spiDPot2Course != 0) {
spiDPot2Course--;
}
SetPOT(BM_POT_COURSE2, spiDPot2Course);
SetPOT(BM_POT_FINE2, spiDPot2Fine);
}
void ChargeCircuitOn(void) {
unsigned int temp;
temp = 255 * 33 / (batteries[batteryID].voltage * 5 / 4);
if (temp > 255) {
temp = 255;
}
spiDPotVSense = temp;
SetPOT(BM_POT_VSENSE, spiDPotVSense);
rlyRelay = 1;
}
void ChargeCircuitOff(void) {
spiDPotVSense = 255;
SetPOT(BM_POT_VSENSE, spiDPotVSense);
rlyRelay = 0;
}
void ChargeBattery(void) {
switch (batteries[batteryID].selectedTech)
{
case NiMH:
ChargeNIMH();
break;
case NiCad:
ChargeNICAD();
break;
case LiIon:
ChargeLIION();
break;
case LeadAcid:
ChargeLEAD();
break;
default:
break;
}
}
void DischargeBattery(void)
{
switch (batteries[batteryID].selectedTech)
{
case NiMH:
DischargeNIMH();
break;
case NiCad:
DischargeNICAD();
break;
case LiIon:
DischargeLIION();
break;
case LeadAcid:
DischargeLEAD();
break;
default:
break;
}
}
void TestBattery(void)
{
switch (batteries[batteryID].selectedTech)
{
case NiMH:
TestNIMH();
break;
case NiCad:
TestNICAD();
break;
case LiIon:
TestLIION();
break;
case LeadAcid:
TestLEAD();
break;
default:
break;
}
}
void ChargeNIMH(void)
{
char buff[20];
buff[0] = atdVoltage/100+'0';
buff[1] = (atdVoltage%100)/10+'0';
buff[2] = atdVoltage%10+'0';
buff[3] = '\0';
WriteToSCI0(buff);
switch (bmOperationState)
{
case initialize:
ChargeVoltageInit(batteries[batteryID].voltage);
ChargeCircuitOn();
bmOperationState = rampup;
break;
case rampup:
if (bmChargeVoltage > batteries[batteryID].voltage * 5 / 4) {
ChargeVoltageDecrease();
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else
{
bmOperationState = constantcurrent;
}
break;
case constantcurrent:
if (bmDeltaT > BM_NIMH_MAX_DELTA_T)
{
bmOperationState = terminate;
break;
}
if (bmChargeVoltage > batteries[batteryID].voltage * 5 / 4) {
ChargeVoltageDecrease();
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else if (bmChargeCurrent > batteries[batteryID].currentCapacity)
{
ChargeVoltageDecrease();
}
break;
case terminate:
ChargeCircuitOff();
bmOperationState = complete;
// break;
case complete:
// break;
default:
break;
}
}
void ChargeNICAD(void)
{
switch (bmOperationState)
{
case initialize:
ChargeVoltageInit(batteries[batteryID].voltage);
ChargeCircuitOn();
bmOperationState = rampup;
break;
case rampup:
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else
{
bmOperationState = constantcurrent;
}
break;
case constantcurrent:
if (bmDeltaT > BM_NICAD_MAX_DELTA_T)
{
bmOperationState = terminate;
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else if (bmChargeCurrent > batteries[batteryID].currentCapacity)
{
ChargeVoltageDecrease();
}
break;
case terminate:
ChargeCircuitOff();
bmOperationState = complete;
// break;
case complete:
// break;
default:
break;
}
}
void ChargeLIION(void)
{
switch (bmOperationState)
{
case initialize:
ChargeVoltageInit(batteries[batteryID].voltage);
ChargeCircuitOn();
bmOperationState = rampup;
break;
case rampup:
if (bmChargeVoltage > batteries[batteryID].voltage * 5 / 4) {
ChargeVoltageDecrease();
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else
{
bmOperationState = constantcurrent;
}
break;
case constantcurrent:
if (bmChargeVoltage > batteries[batteryID].voltage * 5 / 4) {
ChargeVoltageDecrease();
break;
}
if (bmChargeVoltage >= batteries[batteryID].voltage)
{
bmOperationState = constantvoltage;
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else if (bmChargeCurrent > batteries[batteryID].currentCapacity)
{
ChargeVoltageDecrease();
}
break;
case constantvoltage:
if (bmChargeCurrent < (batteries[batteryID].currentCapacity / 10))
{
bmOperationState = terminate;
break;
}
case terminate:
ChargeCircuitOff();
bmOperationState = complete;
// break;
case complete:
// break;
default:
break;
}
}
void ChargeLEAD(void)
{
switch (bmOperationState)
{
//enum chargeState {initialize=0,rampup,constantcurrent,constantvoltage,terminate,complete};
case initialize:
ChargeVoltageInit(batteries[batteryID].voltage);
ChargeCircuitOn();
bmOperationState = rampup;
break;
case rampup:
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else
{
bmOperationState = constantcurrent;
}
break;
case constantcurrent:
if (bmDeltaT > BM_LEAD_MAX_DELTA_T)
{
bmOperationState = terminate;
break;
}
if (bmChargeCurrent < batteries[batteryID].currentCapacity)
{
ChargeVoltageIncrease();
}
else if (bmChargeCurrent > batteries[batteryID].currentCapacity)
{
ChargeVoltageDecrease();
}
break;
case terminate:
ChargeCircuitOff();
bmOperationState = complete;
// break;
case complete:
// break;
default:
break;
}
}
void DischargeNIMH(void) {
}
void DischargeNICAD(void) {
}
void DischargeLEAD(void) {
}
void DischargeLIION(void) {
}
/******************************************************************************
*
* (c) Freescale Inc. 2004 All rights reserved
*
* File Name :Vectors.c
* Description : Interrupt table which points to interrupt handling functions
*
* Version : 1.0
* Date : Jun/22/2004
*
******************************************************************************/
#include "MC9S12NE64.h"
//ISR STUFF ON PAGE 62
extern void near _Startup(void); /* Startup routine */
extern void near RealTimeInterrupt(void);
extern void near emac_ec_isr(void);
extern void near emac_lc_isr(void);
extern void near emac_b_rx_error_isr(void);
extern void near emac_rx_b_b_o_isr(void);
extern void near emac_rx_b_a_o_isr(void);
extern void near emac_rx_error_isr(void);
extern void near emac_mii_mtc_isr(void);
extern void near emac_rx_fc_isr(void);
extern void near emac_f_tx_c_isr(void);
extern void near emac_rx_b_b_c_isr(void);
extern void near emac_rx_b_a_c_isr(void);
extern void near ephy_isr(void);
extern void near PortHInterrupt(void);
extern void near SCI1Interrupt(void);
//************************************************************************
// SOFTWARE TRAP FUNCTION
// DESCRIPTION:
// Function that traps all unexpected interrupts. Used for debugging
// software to find runaway code.
//************************************************************************
#pragma CODE_SEG __NEAR_SEG NON_BANKED /* Interrupt section for this module. Placement will be in NON_BANKED area. */
__interrupt void software_trap(void){ for(;;); }
#pragma CODE_SEG DEFAULT /* Change code section to DEFAULT. */
//************************************************************************
typedef void (*near tIsrFunc)(void);
const tIsrFunc _vect[] @0xFF80 = { /* Interrupt table */
software_trap, /* 63 Default (unused) interrupt */
software_trap, /* 62 Default (unused) interrupt */
software_trap, /* 61 Default (unused) interrupt */
software_trap, /* 60 Default (unused) interrupt */
software_trap, /* 59 Default (unused) interrupt */
software_trap, /* 58 Default (unused) interrupt */
software_trap, /* 57 Default (unused) interrupt */
software_trap, /* 56 Default (unused) interrupt */
software_trap, /* 55 Default (unused) interrupt */
software_trap, /* 54 Default (unused) interrupt */
software_trap, /* 53 Default (unused) interrupt */
software_trap, /* 52 Default (unused) interrupt */
software_trap, /* 51 Default (unused) interrupt */
software_trap, /* 50 Default (unused) interrupt */
software_trap, /* 49 Default (unused) interrupt */
software_trap, /* 48 Default (unused) interrupt */
emac_ec_isr, // 47
emac_lc_isr, // 46
emac_b_rx_error_isr, // 45
emac_rx_b_b_o_isr, // 44
emac_rx_b_a_o_isr, // 43
emac_rx_error_isr, // 42
emac_mii_mtc_isr, // 41
emac_rx_fc_isr, // 40
emac_f_tx_c_isr, // 39
emac_rx_b_b_c_isr, // 38
emac_rx_b_a_c_isr, // 37
ephy_isr, // 36
software_trap, /* 35 Default (unused) interrupt */
software_trap, /* 34 Default (unused) interrupt */
software_trap, /* 33 Default (unused) interrupt */
software_trap, /* 32 Default (unused) interrupt */
software_trap, /* 31 Default (unused) interrupt */
software_trap, /* 30 Default (unused) interrupt */
software_trap, /* 29 Default (unused) interrupt */
software_trap, /* 28 Default (unused) interrupt */
software_trap, /* 27 Default (unused) interrupt */
software_trap, /* 26 Default (unused) interrupt */
// PortHInterrupt, /* 25 Default (unused) interrupt */
software_trap, /* 25 Default (unused) interrupt */
software_trap, /* 24 Default (unused) interrupt */
software_trap, /* 23 Default (unused) interrupt */
software_trap, /* 22 Default (unused) interrupt */
SCI1Interrupt, /* 21 Default (unused) interrupt */
software_trap, /* 20 Default (unused) interrupt */
software_trap, /* 44 Default (unused) interrupt */
software_trap, /* 45 Default (unused) interrupt */
software_trap, /* 46 Default (unused) interrupt */
software_trap, /* 47 Default (unused) interrupt */
software_trap, /* 48 Default (unused) interrupt */
software_trap, /* 49 Default (unused) interrupt */
software_trap, /* 50 Default (unused) interrupt */
software_trap, /* 51 Default (unused) interrupt */
software_trap, /* 52 Default (unused) interrupt */
software_trap, /* 53 Default (unused) interrupt */
software_trap, /* 54 Default (unused) interrupt */
software_trap, /* 55 Default (unused) interrupt */
RealTimeInterrupt, /* 7 Default (unused) interrupt */
software_trap, /* 6 Default (unused) interrupt */
software_trap, /* 5 Default (unused) interrupt */
software_trap, /* 4 Default (unused) interrupt */
software_trap, /* 3 Default (unused) interrupt */
software_trap, /* 2 Default (unused) interrupt */
software_trap, /* 1 Default (unused) interrupt */
_Startup /* 0 Reset vector */
};
////////////////////////////////////////////////
// digijock.js
// Contains initialization routines and functions
// for sending data through SCI0 and SCI1
////////////////////////////////////////////////
var batteries=5;
//Array for tracking current statistics
var c_array = new Array(batteries);
c_array[00] = new Array(128,128,128,128,128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
c_array[01] = new Array(129,128,127,129,129,127,128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
c_array[02] = new Array(128,129,129,128,128,127,128,127,129, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
c_array[03] = new Array(129,129,128,128,127,129,128,129,128,128,128,130,129,127,130,130, 0, 0, 0, 0);
c_array[04] = new Array(128,129,127,128,128,128,128,129,128,128,129,128,129,129,128,130,129,129,129,128);
//Array for tracking voltage statistics
var v_array = new Array(batteries);
v_array[00] = new Array(000,032,033,033,032, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
v_array[01] = new Array(000,033,032,032,032,032,033, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
v_array[02] = new Array(000,031,032,032,032,032,033,032,032, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
v_array[03] = new Array(000,031,032,031,032,032,033,032,032,032,032,033,032,032,032,032, 0, 0, 0, 0);
v_array[04] = new Array(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255);
Appendix G: FMECA Worksheet
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|A1 |VAA = 0V |Transformer failure, bridge |Circuit will not operate |Observation |Low |No damage to parts, however basic |
| | |failure, or resistor failure | | | |functionality lost |
|A2 |VBB = 0V |Regulator failure |Microcontroller will not |Observation |High |Possible damage to battery, if |
| | | |operate | | |failure occurs in the middle of |
| | | | | | |charging |
|A3 |VCC = 0V |Regulator failure |Current sensor will not |Microcontroller software |Low |No damage to parts, however basic |
| | | |operate |detect | |functionality lost |
|A4 |VDD = 0V |Regulator failure |LCD will not operate |Observation |Low |User will get no output, however |
| | | | | | |circuit functionality still present |
|A5 |VEE = 0V |Regulator failure |Battery will not be charged |Microcontroller software |Low |Battery will not be charged |
| | | | |detect | | |
|A6 |VAA out of acceptable range |Transformer malfunction, regulator|Damage to circuit from high |Observation |High |Chance to damage all parts of circuit|
| | |malfunction |voltage/current | | |and overload battery, possibly |
| | | | | | |causing injury |
|A7 |VBB out of acceptable range |Divider resistor failure |Damage to circuit from high |Observation |High |Chance to damage microcontroller, |
| | | |voltage/current | | |temperature sensor, Ethernet jack, or|
| | | | | | |BDM |
|A8 |VCC out of acceptable range |Divider resistor failure |Damage to circuit from high |Observation |High |Chance to damage current sensor |
| | | |voltage/current | | | |
|A9 |VDD out of acceptable range |Divider resistor failure |Damage to circuit from high |Observation |High |Chance to damage LCD and LCD |
| | | |voltage/current | | |controller |
|A10 |VEE out of acceptable range |Divider resistor failure |Damage to circuit from high |Observation |High |Chance to damage digital |
| | | |voltage/current | | |potentiometers |
FigureG1 - Power Supply Circuit
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|B1 |VFF = 0V |Both digital potentiometer failure|Battery will not be charged |Microcontroller software |Low |Battery will not be charged |
| | |or digital potentiometer | |detect | | |
| | |malfunction | | | | |
|B2 |VFF out of acceptable range |Digital potentiometer failure or |Damage to circuit from high |Observation |High |Chance to damage current sensor and |
| | |regulator malfunction |voltage/current | | |to overload battery |
Figure G2 - Charge Supply Circuit
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|C1 |Battery overload |Current sensor malfunction or |Battery overload, with |Observation |High |Chance to overload battery and cause |
| | |resistor failure |possible injury to user | | |injury |
|C2 |Battery overheat |Temperature sensor malfunction |Battery overheat, with |Microcontroller software |High |Chance to overheat battery and cause |
| | | |possible injury to user |detect | |injury |
Figure G3 - Sensor Circuit
|Failure No. |Failure Mode |Possible Causes |Failure Effects |Method of Detection |Criticality |Remarks |
|D1 |Battery stops charging |Microcontroller failure |Battery stops charging |Observation |High |Battery stops charging, however could|
| | | | | | |be indicative of other problems, and |
| | | | | | |could cause damage |
|D2 |Bad data through RJ-45 |Microcontroller malfunction |Bad data or possible damage |Observation |Low |Web interface won’t work properly or |
| | | |to Ethernet line and remote | | |could damage lines |
| | | |computer | | | |
|D3 |Bad data on LCD |LCD controller malfunction |Bad data or possible damage |Observation |Low |“Pseudo-random” characters on LCD |
| | | |to LCD | | | |
Figure G4 - Logic Circuit
-----------------------
Comments:
................
................
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
- project final report template
- project final summary report template
- final grant report sample
- final grant report example
- final evaluation report example
- project management final report example
- project management final report template