Microprocessor Selection

Expert System For Microprocessor Selection

May05-23

Final Report

Client Senior Design

Faculty Advisors Diane Rover Zhao Zhang

Team Members Alan Raveling – Computer Engineering / Computer Science James Schatz – Computer Engineering Jeffrey Sibert – Electrical Engineering

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

Date Friday, April 1, 2005

i Table of Contents

1 LIST OF FIGURES ii

2 LIST OF TABLES iii

3 LIST OF DEFINITIONS iv

4 INTRODUCTORY MATERIALS 1 4.1 Executive Summary 1 4.2 Problem Statement 1 4.3 Operating Environment 1 4.4 Intended Users and Uses 2 4.5 Assumptions and Limitations 2 4.6 Expected End-product and Deliverables 3

5 APPROACH AND RESULTS 4 5.1 Functional Requirements 4 5.2 Design Constraints 4 5.3 Approaches 4 5.4 Detailed Design 5 5.5 Implementation 13 5.6 End-Product Testing 13 5.7 Project End Results 14

6 RESOURCES AND SCHEDULE 15 6.1 Estimated Resources 15 6.2 Schedule 16

7 CLOSURE MATERIAL 17 7.1 Project Evaluation 17 7.2 Commercialization 17 7.3 Additional Work 17 7.4 Lessons Learned 17 7.5 Risk and Risk Management 18 7.6 Team Information 18 7.7 Summary 18 7.8 References 18

i 1. LIST OF FIGURES

Figure 1, Search Frame 5

Figure 2, Results Frame 6

Figure 3, Comparison Frame 6

Figure 4, Information Frame 7

Figure 5, Add Microprocessor Frame 9

Figure 6, Project Database 10

Figure 7, Project Schedule 16

ii 2. LIST OF TABLES

Table 1, Personal Effort Requirements 15

Table 2, Resource Requirements 15

Table 3, Financial Requirements with Labor 16

Table 4, Team Information 18

iii 3. LIST OF DEFINITIONS

API: Advanced programming interface. This is a software term used to describe a software solution that allows programmers a detailed interface connection to a given software product, usually specified by the API itself.

Dialog box: A box that asks for data from the user that the program will then interpret, thus creating a dialog between the user and the computer

Drop-down list: A list of items contained in a single box, with the first item of the list being the only visible entry. Selecting to view more options presents the list, with the remaining items “dropping down” from the selected entry.

Frame: This term is a reference to the different representations of information based on the intent of the user

GUI: Graphical user interface, an event driven based piece of software which displays information in a graphical format as opposed to purely text

Java® Runtime Environment: Software which allows programs written in the Java programming language to run on any hardware for which a Java Runtime Environment exists.

Microprocessor: An integrated circuit which serves as the control unit for embedded devices such as dishwashers, microwaves, and automobile sensors.

PHP: PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.

Pop-up window: A text box that appears in front of other windows when created, giving it the appearance of “popping” onto the display.

Wizard: A series of questions posed to the user one at a time, with the options to continue the search further, or to invalidate the current question’s answer in order to view and alter the results of the previous questions that have been asked

XML: As an extensible markup language, XML is capable of describing many different kinds of data. The primary function of XML is to facilitate the sharing of structured text and information. XML documents are described in a formal manner, allowing programs to modify and validate these documents without prior knowledge of their form

iv 4 INTRODUCTORY MATERIALS This section will explain what the problem is that the project aims to solve, who will be using this project and in what context this project will be used. This section will also discuss assumptions and limitations this project has and what the team plans to deliver as a result.

4.1 Executive Summary: Many senior design teams must use a microprocessor in their project. Due to the wide variety of microprocessors available, it can be difficult to determine which ones will fit the needs of the team. Some microprocessors are expensive and more complicated than necessary, whereas others are not powerful enough for their needs. This project hopes to provide a useful program to help out future senior design teams with this daunting task.

This team has spent the past year creating a program to help future senior design teams select the appropriate microprocessor. The program contains a large database of microprocessors from a variety of companies, such as Microchip®, ARM®, and Texas Instruments®. The user can search from a variety of fields, such as CPU speed, instruction memory, interfaces, and chip packages from either a helpful wizard or from drop-down boxes. An on-screen help feature will provide information on how to use the program as well as what each of the fields stand for. The program will also have the ability to import new microprocessors into the program and view multiple processors side-by-side. The program has been coded in Java® whilst the database is in XML. Therefore this program is able to run on both Windows® and Unix machines.

4.2 Problem Statement Due to a lack of knowledge about microprocessors, many senior design teams choose a microprocessor which is not ideal for their project. Not only does the team waste money purchasing expensive chips with unnecessary features, but they also waste time trying to make the processor work to fit the team’s needs. Therefore, this team has created a program that will enable future senior design teams to search from a large database of microprocessors, selecting one that fits their needs.

4.3 Operating Environment The user search program is coded in Java® and designed to be run on any modern PC. Using Java® ensures that our software can run on any operating system that has an up-to- date Java® runtime environment. This gives other senior design teams a greater flexibility in the way they can view microprocessor information.

1 4.4 Intended Users and Uses In this section, the intended users of this program as well as the intended uses for the program are defined.

4.4.1 Intended Users The primary audience would be future senior design teams who need to use a microprocessor as part of their project. A secondary audience would be anyone who wishes to know more about the microprocessor options available to them.

4.4.2 Intended Uses The software the team is designing will allow anyone to view vital information on a wide variety of microprocessors based on certain selection criteria. By entering in required features of a microprocessor, the program will narrow down the range of microprocessors which can be used for the task. Users can compare the feature set of several different microprocessors at once which allows for better decision making. The program also allows users to add microprocessors to the database from within the program.

4.5 Assumptions and Limitations The following are the assumptions that the team will need to make in order for the customer to use the product, as well as the limitations that are beyond the designer’s control for the program.

4.5.1 Assumptions In order to for others to use the software, the team had to assume the following:  The user’s computer has a current Java® runtime environment.  The user has a rudimentary understanding of microprocessors and the vocabulary involved in describing the features of a microprocessor.  The user should have knowledge of English and metric measurements.  The user interface will be in English and currency will be in United States dollars.  Microprocessors that are added to the database are stored locally on the user’s computer. If the user wishes to share this information with other users, he or she will have to give the database files to said users.

4.5.2 Limitations These are the items that the team had to work around while working on designing and implementing the software.  The software will not contain all available microprocessors  The software may not return any desirable results based on search criteria  The software may not have data for all available fields  Some microprocessors in the database may contain outdated or inaccurate information.  The processor specifications found within the search results will only include publicly available information.  The number of chips that can easily be compared simultaneously will be limited to the size of the screen.

2 4.6 Expected End-product and Deliverables By the end of the semester, the team will have a robust, fully functional program which will allow users to search for, compare, and add microprocessors to a database. The database will have approximately three hundred microprocessors from a number of popular microprocessor vendors, including Microchip®, Intel®, Arm®, and Texas Instruments®. The program will also provide information on any uncommon terms which are used to describe the features of a particular microprocessor.

3 5 APPROACH AND RESULTS Last semester the team spent a great deal of time developing and refining the how the microprocessor selection application would be designed, used, and implemented. The approach that was followed is defined in detail below.

5.1 Functional Requirements The following are the requirements that the program must have in order to function as a useful tool for other senior design teams.  The program must be easy-to-use and should be executable on a wide variety of platforms, including Windows® and Linux®, as well as any graphical operating system which possess a current Java runtime environment.  The program will have as large of a selection of microprocessors from companies such as Arm®, Microchip®, Texas Instruments®, Intel®, and more.  The program will allow the user to search under a wide variety of fields using either dialog boxes or wizards. Either method should produce useful results that match the input given to the program. The user will then have the choice of viewing more information about a single microprocessor or listing basic information from multiple microprocessors side-by-side.  The user will be able to add new chips to the database and/or additional searchable criteria so that new microprocessors and new technologies can be added for future classes. Adding additional chips will require no code modifications, whereas adding additional search criteria will require only minor code changes.  Users will have documentation available that will explain how to use the program and the proper procedure for adding microprocessors and features to the database.  The program should return relevant results in less than 10 seconds.

5.2 Design Constraints When designing the software package, it was determined that it would be best to separate the software into two parts. These two parts would then be the database itself and the user functions. However, due to the large amount of information that would be presented to the user, the team decided to split the user functions into the graphical and non- graphical sections. Splitting the user functions into graphical and non-graphical sections allows for future implementations to pick and choose what current code and forms to use and which ones to replace.

5.3 Approaches One solution considered was to use MySQL, a free database system, and the PHP® scripting languages to make a web based solution. This solution would allow for anyone to use the system at any time and require the end user to have no more than a web browser. With such ubiquitous access, anyone would also be able to update the database as new microcontrollers came out. This solution was quickly dismissed as no one in the group was familiar with the PHP language. Also, the group would then need a web server to host the database and web pages on.

4 Another solution that was suggested was to use a Microsoft® Access database and use the C# programming language to create the graphical interface. Microsoft® has a very verbose development environment which would allow rapid development of the application. By going with this route however, users are limited to using Microsoft® based operating systems. Having a per site copy of the database would also limit updates to the database to those which the end user does by himself or herself. Both of these solutions confine the user to a rigid database layout where no new features or attributes could be added as new microcontrollers come out.

It was decided by the team that the software package will use the Java® runtime environment because of its ability to be run on many different platforms, such as Windows and Linux. The team felt that this would allow any user to use the program, since Linux and Unix operating systems are becoming more widely-used.

5.4 Detailed Design The project has been separated into three main categories to aid in the further design and implementation of the finished project. These main categories are then distributed into smaller sections and functions that will enable all the features that the clients require.

5.4.1 The User Interface One of the primary aspects of the project is an interface which will allow the client to access the information contained within the database. The interface must provide the appropriate information given decisions that are made by the end user during the period in which the software is run, but must also display this information in a manner that is easy to understand. To this effect, the user interface must provide options that allow the user to view information that will aid in the understanding of the selected microprocessor. The most current design for the user interface calls for it to be separated into multiple frames to allow for easy recognition and ease of use.

5 5.4.1.1 Search Frame The first frame shown to a user of the software, this frame will include the search criteria that the user will input in order to select a microprocessor from the lists included in the database. Search parameters will be defined by using a combination of drop-down lists and input boxes to select the importance of the search parameter in selecting the results, as well as the specific attributes. This frame will also include the options to switch to the information and add microprocessor frames.

Figure 1 - A depiction of the search frame, including the various input boxes.

6 5.4.1.2 Results Frame When the user has selected a series of search parameters and performed a search for the resulting microprocessors, the frame will be automatically changed to the results frame. In this frame the user will be able to further refine the search from a reduced set of microprocessors, add the results to the comparison list, or simply view the results.

Figure 2 - The resulting microprocessors

5.4.1.3 Comparison Frame If the user has added any microprocessors to the comparison list, they will be able to select the option to view the list in a frame that is similar to the results frame. In the comparison frame, the user will be able to view microprocessors that they have selected from previous searches and compare those results against each other. Included in this frame will be the option of saving the current listing and information of microprocessors, as well as an option to load a previously saved listing for further viewing.

Figure 3 - A comparison list with no entries

7 5.4.1.4 Information Frame The information frame takes the form of a pop-up window that contains various information that has been entered into the program. It is intended to aid in the understanding of the uses of different microprocessor interfaces and acronyms that the user may find unfamiliar. This frame will appear whenever a user clicks on the "?" boxes contained in the program and provide information on the related item.

Figure 4 - Basic view of the information frame

In addition to providing help on unfamiliar terms, these frames will be able to display relevant information concerning different aspects of various product lines, and well as provide graphical representation of the different chip packages that are used in the industry.

8 5.4.1.5 The Add Microprocessor/Database File Frame When the current view is changed to this frame, the user will be asked to input either the database entry information for a new microprocessor, or the location of a series of new database entries in a separate file. In the microprocessor entry view, the format will be similar to the view given in the results frame for a single processor. The add frame will also include options for adding additional microprocessors, adding additional files, canceling the current add operation, or beginning a new search. Upon entering a new single microprocessor entry, the information will also be placed into the comparison frame, so the user may easily view the new entry.

Figure 5 - Adding a microprocessor

5.4.2 The Microprocessor Database

All the microprocessors used by the program’s database are stored in a single XML file. Microprocessors from Texas Instruments®, Microchip®, Intel®, and ARM® are contained within the database. The searchable information within the database comes from publicly available information from the manufacturer’s website, data sheets, and other published documentation. Because product lines can change often, the database is updated regularly to include new information from each manufacturer.

The searchable features of each microprocessor are listed below.  Price per chip  Code language  Type of memory (Flash, ROM, etc)  Instruction and executable memory  EEPROM and RAM memory

9  I/O pins  Timers 2  Interfaces such as I C and USART  Processing speed  Power consumption  Package type such as PDIP, SOIC, and TQFP  Number of pins and physical dimension of the chip  Other special features such as a built-in USB interface

Not every feature, however, is published for every chip. Therefore, the user will have to be careful when searching not to be too specific. Where possible, the program will attempt to point out these problems, especially if a large number of chips lack information for a specific field. An example would be the power consumption of Microchip pics. This information is not listed for every chip; therefore the user is warned about this when selecting this feature.

The database was created in a spreadsheet before it was imported to XML. This is a sample of part of the spreadsheet.

Figure 6 – Depiction of the database

Because a spreadsheet is not easily searchable, it must be converted to another format that allows main program to read the microprocessor information. The team chose to use an XML file because the database fields are arranged into a simple hierarchical text file. This allows the information to be easily and quickly retrieved, even for a large database such as this.

Because companies release new processors quite regularly, the user may wish to add new microprocessors to the database. The program includes a function to easily add microprocessor.

5.4.3 The Program Core The central part of the software, the program core will handle all functions that deal with the manipulation of information. The core is planned to be coded in Java® to allow for cross-platform compatibility amongst all users. Contained within the core are the elements that allow the program to access the database, update information displayed on the interface, perform data sorting operations, and handle the creation and access of files stored on the computer. To accomplish these tasks, the core has been designed around the use and implementation of the open-source software package: Lucene®. By selecting

10 to use this package, the team has provided a flexible and robust system by which they can index and search a directory of files on the user’s system.

5.4.3.1 User Query Interface – Software Side The wizard for the system was designed with the intent to pose a series of questions to the end user in order to aid in the determination of an appropriate microcontroller for the implementation of a user specified project. To achieve the desired results, the user will be asked to identify, in order of importance, the top priorities they have in the selection of a microcontroller. The currently selectable options of priority include these features specified in the following list:  Project budget  Programming language  Processor speed  Physical size/package type  Program size  Connectivity/interface  Power consumption

Upon selecting one of these features, the user will then be asked to further specify their selection into a more refined choice. Once these questions have been answered in a satisfactory manner, the user is then asked to either identify the next most important feature to base the search upon, or to view the current results of a search based on their queries. The system will then generate a query string to pass on to the search engine contained within the software and based on the selection of the user, and either advance to the results viewing frame, or continue to build the query string, as based on the user’s selection.

11 5.4.3.2 Adding a New Microprocessor to the Database This function takes the information generated by the add microprocessor frame and converts it into an entry that is compatible with the entries already present in the main microprocessor database. After the entry has been generated, a copy of the microprocessor information is passed into the comparison list and the entry is inserted into the main database directory. The main database is then re-indexed to reflect the changes made by the addition of this new information.

5.4.3.3 Merging a List of Microprocessor with the Database When the user selects to merge a list of microprocessors with the main database, they are presented with a dialog box that will ask them for the location and name of the file they wish to insert. The program then performs a validity check to ascertain whether the file is of the appropriate format to insert into the database. If the file passes this check, the entries are then filtered and inserted into the main database directory, and the index is updated to reflect this addition to the database, and the user is prompted for their next action.

5.4.3.4 Performing a Search and Refining a Search If at any time a user wishes to perform a new search, or further refine a search that they have previously made, they may select to resume their search at the last query they was presented to them by the wizard, or to dismiss the previous results, and start from the beginning of the user query process. By selecting to dismiss the results, all previous data collected by the search is removed, but selections that have been added to the comparison frame will be preserved by the system. When they select to resume the search to further refine the results, the system will recall the previous query to the database, and allow the user to change their answer, or continue with that query and place further limitations on the results.

5.4.3.5 Adding a Microprocessor to the Comparison Frame When the user selects to add a microprocessor to the comparison frame, a copy of the microprocessor’s database entry is made and placed into the comparison database. If the comparison database is currently blank, a new database will be created for the program to use.

5.4.3.6 Saving and Loading a List of Microprocessors By selecting the save option, the user will be prompted with a dialog box that will ask them where they wish to save the resulting list, and the name that they wish to give to the file. File creation will follow the standard requirements for file naming on the user’s operating system. Alternatively, if the user selects to load a file, the dialog box will appear and ask them to specify a valid file in a similar manner to the way that merging an existing file works. However, the file’s database entries will be added to the comparison database instead of the main database.

12 5.5 IMPLEMENTATION To implement the software, the forms and core components were broken down into the sections listed in the previous section. The task of searching the database comprised one focal point while creating the GUI that displays the information pulled from the database being the other.

In order to construct the database, the team first constructed a list of companies that specialize in microprocessors. This list included companies such as Microchip®, Intel®, Arm®, and Texas Instruments®. Next, they looked on the respective company’s websites, finding as much information about the company’s offerings as possible. Much of this information was available within datasheets, or elsewhere on the respective web pages.

The team then compiled as much of this information into a spreadsheet, carefully picking information that would be useful to senior design teams selecting a microprocessor. The spreadsheet was then saved as an XML file for use by the program.

Finally, the team worked diligently on a help guide that defined each of the fields of the database, and provided examples of different objects. Pictures of the various package types were included for teams to look at.

For the search operations to be performed successfully, the team had to determine a manner in which data from an XML document could be read and interpreted by a Java- based program. To accomplish this, the team utilized a software solution known as SAX. SAX is the simple API for XML. By utilizing this API, the team was able to design and implement an index-based search engine for use on the database that they had previously constructed for their use in the solution.

5.6 END-PRODUCT TESTING Testing of the software will be performed in three phases.

The first phase will be to test the functionality of the database. Short test scripts will be used to ensure that the database is properly formatted and that once complete, the program will be able to retrieve the necessary information from the database.

The second phase will be to test the functionality of the program itself. During this test phase, each team member will search for several different microprocessors using a wide variety of search criteria. The program should give useful and accurate results. All the features of the programs should be working.

The final phase will be to beta test the program with other users. Feedback from the beta test will be used to further improve the program and correct any problems that the team omitted.

13 In testing the software in phases, the team ensures that the quality of the end product is as high as it can be. Problems found at the lower levels of testing can be solved before they become larger errors at the higher levels.

5.7 PROJECT END RESULTS The end project will result in a software suit that will be easy to use, verbose in information, meets the requirements of the project. By testing and retesting the software functions and features, and by having actual people test the software before its release, the team can ensure a quality product. With hundreds of microcontrollers in the database, the users of the software can expect to get relevant and current search results which will allow for users to be more successful in their projects.

14 6 RESOURCES AND SCHEDULE This section will define the amount of work that will be devoted to each task, the associated costs of creating the solution, and the schedule the team plans to follow in creating the solution.

6.1 Estimated Resources At the beginning of the project, the team made several estimations of the expected effort and costs that it would require to accomplish the project. At the completion of the project, this is an estimation of the actual effort and the associated costs that the project has required.

6.1.1 Personnel Efforts The table below provides an estimate of the amount of effort each task will require to be completed.

Original Estimate Revised Estimate Actual Contribution Task Alan James Jeff Total Alan James Jeff Total Alan James Jeff Total 1 20 19 19 58 21 25 21 67 24 28 27 79 2 7 7 8 22 2 2 2 6 3 2 3 8 3 7 8 7 22 3 3 3 9 3 4 7 14 4 8 7 7 22 1 3 3 7 1 3 2 6 5 11 12 10 33 5 7 0 12 11 10 0 21 6 20 19 20 59 0 0 0 0 0 0 0 0 7 16 16 16 48 4 6 20 30 4 5 26 35 8 4 5 5 14 2 2 2 6 2 2 2 6 9 42 42 43 127 11 14 0 25 19 20 0 39 10 8 7 6 21 4 5 0 9 5 5 0 10 11 7 6 7 20 3 3 3 9 3 1 0 4 12 10 10 10 30 4 4 4 12 4 3 1 8 13 6 7 7 20 3 3 3 9 4 3 1 8 14 15 15 14 44 6 6 8 20 4 4 12 20 15 2 2 2 6 3 3 3 9 2 2 2 6 Total 183 182 181 546 72 86 72 230 89 92 83 264

Table 1: Personal Effort Requirements

15 The tasks are as follows listed above are defined as follows:

 Task 1 - Senior Design Deliverables  Task 2 - Research Microcontroller Selection Process  Task 3 - Categorize Microcontroller Features  Task 4 - Decide Upon Database Schema  Task 5 - Learn Necessary Programming Languages  Task 6 - Design Document (included in Task 1 in revised and final estimates)  Task 7 - Prototyping Database Files  Task 8 - Demo Prototype to Customers  Task 9 - Coding End-User Program  Task 10 - Debug, Phase 1  Task 11 - User Testing, Phase 1  Task 12 - Debug, Phase 2  Task 13 - User Testing, Phase 2  Task 14 - User Documentation  Task 15 - Present Finished Product to Customer

6.1.2 Resource Requirements The table below represents the cost associated with the completion of the project.

Table 2: Resource Requirements Item Cost Poster $50.00 Software $0.00 Documentation $10.00 Total Cost: $60.00

The costs were originally projected to be $50, however this had to be adjusted to $60 to account for document binding. Despite the small added cost, the project was still completed within budget.

6.1.3 Financial Requirements If the factor of labor were included in the costs of the project, the table below would represent the final cost to the customer for the end product.

Table 3: Financial Requirements with Labor Item Cost Poster and document binding $60.00 Labor at a wage of $10.50 / hour Alan Raveling $934.00 Jeffrey Sibert $966.00 James Schatz $871.50

16 Total Cost: $2831.50 6.2 Schedule This is an estimate of how the time dedicated to each task will be spent through the year. In order to allow ourselves to catch up if the team falls behind, the entirety of winter and spring breaks have no work scheduled during that time.

Figure 7: Project Schedule

17 7 CLOSURE MATERIAL This section includes pertinent contact information and a summary of the May05-23 project.

7.1 Project Evaluation In the design and implementation of an expert system for microcontroller selection, the team feels that they have successfully met all the specifications required for the desired product. It is also their belief that the additional features that they have implemented will be useful to the prospective users of the system.

7.2 Commercialization The team has deemed that they will not be following up on the commercialization of this product, as they feel that the current market for the selection of microcontrollers is limited to students wishing to design a project for the senior design class. As this was the intended use of the software, we see no further use in maintaining or marketing the results.

7.3 Additional Work It has been suggested by the team and the advisors that the software should be made capable of providing a method of updating over an internet connection. This connection would allow the end user to have access to up-to-date information about the selection and capabilities of the microcontrollers that they are searching.

The team itself also believes that the current XML system for the software package, while currently sufficient for the tasks assigned to it, make later become to cumbersome for the uses intended. It is therefore recommended that research be done to implement a more rigid database for further use.

7.4 Lessons Learned Throughout the course of the project, the team has come to learn a few lessons about the nature of projects and project deadlines, as well as the methods in which to operate as a team. Of all the lessons learned, these are the ones that were viewed as being the most critical in the progress made.  You can never start too early  Discussing and defining functions before programming will save time during the implementation phase  Always be more descriptive in communications than you think necessary  Be prepared to handle changes and problems

18 7.5 Risk and Risk Management During the time spent in the senior design class, the team has already encountered some events that have placed the final project at risk. In these situations, the team collected together the members, and discussed how to best handle this change. The risks that the team has handled so far have included the early loss of a team member within the first month of work on the project, and the graduation of a team member at the beginning of the semester. On both occasions, the team met to discuss how to best handle them. For the first one, since the members had not yet even begun to schedule for a four person team, the alteration of a three person team from the envisioned four person team posed no direct risk. In the second case, the team discussed the various factors, and determined that the project would be able to continue, with the third member acting as a distant contributor, with the majority of the work being done offsite.

7.6 Team Information The following section includes the name, address, email, phone number, and title of all those involved in the project.

Table 4: Team Information Name Address Email Phone number Title Dr. Diane Rover 104 Marston [email protected] (515) 294-1309 Faculty Ames, IA 50011 Advisor Dr. Zhao Zhang 368 Durham [email protected] (515) 294-7940 Faculty Ames, IA 50011 Advisor Alan Raveling 614 Billy Sunday Road 107 [email protected] (515) 239-7267 CprE / Ames, IA 50010 ComS James Schatz 312 Hillcrest Drive [email protected] CprE Ames, IA 50014 Jeffrey Sibert 7427 Wilson Matterson [email protected] (515) 572-3237 EE Ames, IA 50013

7.7 Summary The expert system for microprocessor selection software designed by the team will enable users to select a microprocessor based on how well suited the processor is for the task, as opposed to choosing a controller based on personal bias or convenience. The team will produce the software with the outlined specifications and design that will allow users to search based on required microprocessor features queried from a database of microprocessors, with options for storing search results and expansion of the database.

7.8 References

Microchip® http://www.microchip.com Intel® http://www.intel.com ARM® http://www.arm.com Texas Instruments® http://www.ti.com Lucene http://lucene.apache.org/java/docs/