EE 477 Final Report - Purdue University



ECE 477 Final Report

Spring 2004

[pic]

Team Code Name: MIDI Maestros______________________________ Team ID: _3____

Team Members (#1 is Team Leader):

#1: Ben Johanek__________________ Signature: ____________________ Date: _________

#2: Matt Burgess_________________ Signature: ____________________ Date: _________

#3: Chris Coy____________________ Signature: ____________________ Date: _________

#4: Ryan Denison_________________ Signature: ____________________ Date: _________

REPORT EVALUATION

|Component/Criterion |Score |Multiplier |Points |

|Abstract |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|Project Overview and Block Diagram |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Team Success Criteria/Fulfillment |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Constraint Analysis/Component Selection |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Patent Liability Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Reliability and Safety Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Ethical/Environmental Impact Analysis |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Packaging Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Schematic Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|PCB Layout Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Software Design Considerations |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Version 2 Changes |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|Summary and Conclusions |0 1 2 3 4 5 6 7 8 9 10 |X 1 | |

|References |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix A: Individual Contributions |0 1 2 3 4 5 6 7 8 9 10 |X 4 | |

|Appendix B: Packaging |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix C: Schematic |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix D: Top & Bottom Copper |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix E: Parts List Spreadsheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix F: Software Listing |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix G: User Manual |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Appendix H: FMECA Worksheet |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

|Technical Writing Style |0 1 2 3 4 5 6 7 8 9 10 |X 5 | |

|CD-R of Website Image |0 1 2 3 4 5 6 7 8 9 10 |X 2 | |

| |TOTAL | |

TABLE OF CONTENTS

|Abstract |1 |

| 1.0 Project Overview and Block Diagram |1 |

| 2.0 Team Success Criteria and Fulfillment |2 |

| 3.0 Constraint Analysis and Component Selection |3 |

| 4.0 Patent Liability Analysis |4 |

| 5.0 Reliability and Safety Analysis |7 |

| 6.0 Ethical and Environmental Impact Analysis |11 |

| 7.0 Packaging Design Considerations |13 |

| 8.0 Schematic Design Considerations |16 |

| 9.0 PCB Layout Design Considerations |17 |

|10.0 Software Design Considerations |18 |

|11.0 Version 2 Changes |29 |

|12.0 Summary and Conclusions |29 |

|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: User Manual |G-1 |

|Appendix H: FMECA Worksheet |H-1 |

Abstract

This project, cleverly named the MIDI Maestro, is a game which interfaces with a MIDI keyboard. The device has two modes of operation. The first of these is a MIDI sequencing mode which allows 2 to 6 players to take turns building successively longer key sequences one note at a time. In this mode, a player is eliminated when he can no longer reproduce the sequence of the previous player. The second mode of operation is slightly more advanced. Each player must produce a melody, and then each opponent is given a chance to try and match the melody and timing of the player’s melody. This game provided valuable experience in developing code in embedded C using the USART, SPI, and interrupt-driven inputs of an Atmel microcontroller.

1. Project Overview and Block Diagram

The MIDI Maestro is comprised of four main functional blocks. The microcontroller and software make up the processing block. The RPG, LCD, and the MIDI input and output are the major components in the user interface block. The audio output block consists of a voice-record-playback chip and an amplifier IC driving a speaker. The power block provides the various voltages required to operate the device.

[pic]

Figure 1.1: MIDI Maestro Block Diagram

Figure 1.1 shows a high-level block diagram of the project. The microcontroller is responsible for orchestrating the operation of the MIDI Maestro. It ties all of the functional blocks together, allowing them to work in unison. The USART port of the microcontroller provides an interface to the MIDI input and output of an external music keyboard. The SPI (or serial peripheral interface) communicates with the voice chip. The voice chip provides an audio signal to the amplifier which drives the MIDI Maestro’s internal speaker. Several general purpose input/output pins on ports A and C of the microcontroller are used to drive the LCD which is used for menu navigation and game status messages. The external interrupt pins of port D on the microcontroller are connected to the RPG (rotary pulse generator) which allows the user to select various options. The power block generates regulated five volts, three volts, and -10 volts, given a nine volt unregulated input supply. It utilizes two linear regulators to supply the three and five volts. The power supply block uses the output of a RS-232 level converter to supply the -10 volts. Figure 1.1 shows the completed project from the front.

[pic]

Figure 1.2 – MIDI Maestro - Front View

2. Team Success Criteria and Fulfillment

In order to define the exact functionality and provide a method of evaluating the success of the MIDI Maestro project, five “success criteria” were defined:

• Ability to communicate with LCD display to display messages

• Ability to read and send MIDI signals

• Ability to output audio signals (via speaker)

• Ability to store a significant number of MIDI messages for comparison and playback

• Ability to control tempo, volume, and game features from user input

The completed menu system provides functionality that fulfills the first success criterion. It utililizes the LCD to allow the user to choose game options. The two game modes allow the user to communicate via MIDI to a keyboard, completing the second criterion. Both modes receive user data and transmit stored data to the keyboard. The gameplay is enhanced by game messages played by the internal speaker. Various messages such as “get ready… go!” and “player one wins” were programmed into the voice chip and are played back at appropriate times. In both modes, user input is received via the MIDI cable and is stored or compared against previously stored messages. In sequence mode, these messages are played back when a player wins. In HORSE mode, the tempo of the backing rhythm is changed simply by rotating the RPG. Volume may be controlled at any time by adjusting the analog potentiometer. The user may return to the main menu at any time to change game options. This shows functionality that completes the final criterion. The MIDI Maestro functions exactly as specified by these five criteria.

Constraint Analysis and Component Selection

Analysis of Design Constraints

The microcontroller needs to receive and process the MIDI signals quickly, in addition to applying time-tags to them for comparison purposes, so both a fast clock speed and a high baud rate serial interface are necessary. However, a human can only sense time to a certain extent, thus there will be tolerance (so many milliseconds) for each note. This gives the processor more computation and I/O time, so most chips with a decent clock and baud rate (which is normally a fraction of the clock speed) will be sufficient for all computation needs.

In order to control the LCD screen and sound controller, the microcontroller needs to have 14 pins (total) dedicated for these devices. Additionally, the control knob (rotary pulse generator with a push button) needs 4 port pins. To send and receive MIDI signals, two serial ports are desired, though port pins could be used for the output. The easiest way to receive the MIDI signals from the keyboard is by way of a UART interface, so a microcontroller with this is desired. For timing and comparison purposes, a timer/counter with comparison capability would simplify the time-tagging / data logging of the MIDI signals. The only other mandatory interface requirement is a reset pin, which is pretty much standard on all microcontrollers. A feature that may prove to be useful, though not necessary, is a real-time clock, perhaps with a separate oscillator and counter mode. If that can also be used as an external clock for the other peripherals, particularly the sound controller chip, it would be very useful.

The power needed for this project will be sourced from a small AC/DC converter, so that the device can be plugged into the wall (typical 120V AC outlet). A battery-powered configuration is possible, but running the microcontroller at a high clock speed along with supplying enough current for the amplifier circuit (for sound output) and the LCD screen deems such a design impractical. The end-users’ hassle with changing the batteries coupled with an already existing requisite that the MIDI-capable keyboard be plugged in convinced the designers to use a wall-wart instead. The design of the power supply inside the device is yet to be in existence, though it is known that the LCD and microcontroller (at minimum) will require different supply voltages. A total of 1.5A should be more than enough to power the entire circuit.

Although in the market place an aesthetic, ergonomic, and compact design are highly desired, the main focus in packaging constraints is compactness in both overall size and weight. The game should be fairly portable and not burdensome to relocate. The design currently in place is fairly small, since the speaker and amplifier are just big enough to be heard clearly. The largest parts will probably be the power supply and circuit board, but with meticulously designing the layout, they should both be relatively small in comparison to the size of the keyboard. The LCD screen to be used, a CrystallFontz CFAG 12864B, is a graphical display whose dimensions are only 75 x 52.7 mm, which is just the size for displaying necessary information to the users. Unfortunately, it needs a -10V source to power it, but at a current of only 1.5mA, so it can be run off a RS232 level converter (which will only be used for debugging). [5]

The total cost of the project should not be overly expensive, since the target customers are owners of MIDI keyboards, which is not a large crowd. Also, the creators of the device have limited budgets. For this reason, an inexpensive microcontroller will be used, preferably with little to no cost in development software and hardware necessary to prototype the device. The cost of all products can be found in the spreadsheet following this report.

Rationale for Component Selection

LCD: The Crystall Fontz CFAG12864B was chosen because of its aesthetics, graphical display (instead of merely characters) and because of its robust operating conditions. It also has backlighting, which allows the user to read more clearly the perhaps time-critical messages that it will display. Many other LCD’s were considered because of price, but they lacked the desired luster of this one. [5]

Microcontroller: When looking over several possibilities for the microcontroller, the Atmel AT90S8535 seemed to best fit the requirements for this design, while remaining affordable. It has a programmable UART suitable for MIDI signals, as well as a clock speed of 8MHz. The 32 I/O lines more than suffice for the peripherals, so the remaining port pins can be used in the debugging process during prototyping. The on- chip times are well developed with separate prescalers and compare modes. The Atmel also has a real-time clock with separate oscillator and counter modes, which are useful to use to clock the peripherals, and perhaps to generate a metronome. Also, the in-circuit programmability and PDIP package make prototyping simple. [1]

The Rabbit 3000 was also highly considered due to its high clock speed of 54MHz, 6 serial ports, and 56 I/O pins. The drawbacks of this chip were that it was more expensive, the TCP/IP functionality was unnecessary, and the timers were not as great as in the Atmel chip, though they were numerous. The Rabbit did have ten 8-bit timers, but only 2 match registers. Due to its size (128 pins) there is no PDIP package, and consequently prototyping would be more difficult than with the Atmel. Basically, the chip was nice, but it had an excess of everything, and the Atmel was picked for its quality, over quantity (of I/O pins, speed, etc). [3]

If the Atmel AT90S8535 cannot be located due to availability, similar chips are currently being produced at about the same price range and functionality. The two of most interest to the designers are the ATmega32 and the AT90S4434, both of which have the 40 pin PDIP package for prototyping purposes. [19]

Sound Chip: The ISD4003, from Winbond Electronics, was the best sound chip found, with 4-minute sound recording capability and it is controlled by a SPI port. It is easy to program and has a 28-DIP package which can be prototyped easily. Other chips were more expensive or did not have serial interfacing with a DIP package option. There were other ISD chips, but they communicated via parallel addressing or had a lower sampling rate. [4]

3. Patent Liability Analysis

It is obvious in glancing at the description of this project that it is very similar to products already on the market. Milton Bradley markets a product called SIMON that has light-up buttons that the user must press in the pre-determined sequence. The storing of MIDI messages with time-stamps is not a new or novel idea. Since the invention of the MIDI specification, companies like Yamaha have developed whole products devoted to this task. Other products on the market have message recording capabilities included in their functionality. All of these products already on the market likely have at least one patent associated with them. This poses a possible problem to anyone who might want to market something like the MIDI Maestro.

Results of Patent Search

In searching the US patent and trademark office’s website and looking up patents for Milton-Bradley’s SIMON, and patents for MIDI sequencers on the market, several patents came up that are related in function to our product.

According to Simon’s manual, the patent number for the product is 4,207,087. The patent makes the claim that Simon is a game that generates “perceptible time sequence of events” and determines the correctness of the player’s response. [6] The patent also claims that the device comprises of a microprocessor in a portable or non-portable case with a number of buttons attached to the outside of the case. The device may or may not have lights or sounds associated with each event. The game produces a random sequence for the player to follow. Simon determines that a player has won if they exceed a predetermined number of correct responses. The patent also makes claim that the perceptible events may be musical notes. The game, according to the patent, has the option of speeding up after a predetermined number of correct responses. The game may also provide interaction between two participants to create a multi-player game.

Another similar game that has a patent registered for it is described by patent number 5,855,513. The game is a combination of tic-tac-toe and “SIMON”. This game has a number of spaces on the outside of a housing with an electronic controller inside. These spaces have some sort of indicator and input device associated with them. The device has an audio signal generator for playing recorded sounds in relation to the operation of the device. The sounds may be unique to each space, and may be re-assignable to different spaces by the microcontroller. The game is played by choosing a space that has not already been chosen. The next player would then press the space that the first player chose and then choose an empty space. The game would progress in this manner until a player reproduces a “match” to a predetermined game state, regardless of what player activated any space. A player would also lose if they were unable to reproduce the sequence up to that point. [6]

The third patent discovered that has similar operation to the project is a “performance recording apparatus for recording information used to control musical generation instruments.” (Patent no. 5,113,741) The device has means to record event data including multiple channels on one line and the ability to separate these channels to play different instruments simultaneously. The patent specifies that this event data may be in the form of MIDI messages. The device has the ability to store received messages to a medium for later playback. It has the ability to determine if a defective message has been sent to it and to correct the defective data. The device also has the ability to transform one channel into another and to determine if a message is on a channel that exceeds the maximum number of channels. This product effectively allows a user to have multiple devices listening on the same channel, yet receiving different information. It also allows multiple devices to be connected to it and recorded on one track rather than having multiple recording devices that need to be merged later. [6]

Analysis of Patent Liability

Literal infringement is possible for the project mostly in its similarity to the game Simon. As stated above, Simon (in single player mode) produces a sequence of events that must be followed by the player. Although not elaborated upon in the patent, it is stated that the device may be used to form a multi-player game. The possible infringement arises because the MIDI Maestro is planned to have a single-player game mode where the user must follow a pre-determined sequence of musical notes. While this is not random as in Simon, it is still a sequence of events that the player must echo. This is essentially the purpose of the patent that Simon holds.

Literal infringement is also possible for the tic-tac-toe game. The game has means for recording a sequence that a player enters, and comparing that with another sequence, which is exactly what the MIDI Maestro does. The game mode is not an issue, because it is dissimilar to the game modes of the MIDI Maestro.

Infringement under the doctrine of equivalents is mostly possible with the MIDI sequencer. It appears, upon first glance, that the sequencer performs substantially the same function of recording MIDI messages as the MIDI Maestro in substantially the same way. The MIDI Maestro, however, only stores the MIDI messages temporarily, rather than on a portable or even recoverable medium as the sequencer does. Although this does not seem to perform substantially the same function in substantially the same way, it may be close enough to infringe. The purpose of storing messages in the sequencer is to be able to recall them when a user wishes. The purpose in the MIDI Maestro is simply to be able to compare them in the near future, so storage in volatile memory is adequate.

Action Recommended to Avoid Infringement

In order for the MIDI Maestro to avoid infringement on the patent granted for Simon, licensing should be discussed with Milton-Bradley. The game mode where a recorded song is played and the player must recite it is too close to the way Simon is played.

To avoid infringement upon the patent for the tic-tac-toe game, the best way to avoid infringement would be to find another way to store messages and compare the sequence, which would be difficult. Another way to avoid infringement would be to attempt to license the concept from the owner of the patent, for a fee, of course. Obviously, another option would be just to not market the MIDI Maestro.

In the case of the doctrine of equivalents case, the MIDI Maestro should be altered so that it will no longer infringe. The game could possibly use a new and novel way of storing the MIDI data to avoid infringement.

4. Reliability and Safety Analysis

The MIDI Maestro is by no means a device that would be considered dangerous since it is used strictly as a game control mechanism, a MIDI data analyzer, and a visual and audio feedback tool. The device is not controlling anything that could hurt user and there are no high powered components. Damage of the attached MIDI keyboard is also very unlikely since it is optically isolated from the circuitry of the device (if the user hooks the keyboard up to the correct MIDI input and output jacks, both the keyboard and the MIDI Maestro circuits are isolated from each other. There is a possibility, however, that certain components could fail (which would make the device unusable) and these component failures are analyzed below.

Reliability Analysis

Four components in the MIDI Maestro stand out as components that could possibly fail. These four components are the L7805 voltage regulator, the L78L33AC voltage regulator, the MAX243 RS232 level converter, and the MAX4295 audio amplifier. These components were chosen because they are the components that could possibly rise in temperature during circuit operation and are therefore most likely to be devices that would have reliability issues. Below are calculations for [pic] and MTTF where [pic] and [pic] as stated in the Module 9 Lecture Notes for ECE477 Spring 2004 [9]:

L7805 5V Regulator:

[pic] and [pic]

[pic] 0.020

[pic] 16

[pic] 0.0012

[pic] 6.0

[pic] 10

[pic] 1

therefore, [pic] 3.272 failures per [pic] hours of operation

[pic]

Explanation: All values were chosen based on Module 9. They were verified in the Reliability Prediction of Electronic Equipment Military Handbook (MIL-HDBK-217F) [10].

L78L33AC 3V Regulator:

[pic] 0.020

[pic] 16

[pic] 0.0012

[pic] 6.0

[pic] 10

[pic] 1

therefore, [pic] 3.272 failures per [pic] hours of operation

[pic]

Explanation: The value for C1 was chosen based on the assumption that a 3V regulator has a similar number of transistors as a 5V regulator. This value was referenced in Module 9 [9]. πT is the same as the 5V regulator at TJ less than 100° C since a 3V regulator falls into the same ‘Linear’ category as a 5V regulator. C2 is also the same for a 3V regulator as a 5V regulator since the number of pins and packaging is the same in both cases. This information was verified in MIL-HDBK-217F [10]. πE, πQ, and πL are assumed to be constant throughout these calculations.

MAX243 RS232 Level Converter:

[pic] 0.040

[pic] 16

[pic] 0.0072

[pic] 6.0

[pic] 10

[pic] 1

therefore, [pic] 6.832 failures per [pic] hours of operation

[pic]

Explanation: C1 was chosen assuming that an RS232 level converter is more complex than a voltage regulator (it is comprised of more transistors). If a voltage regulator has between 101 to 300 transistors, I have assumed that an RS232 level converter would fall into the next most complex group and would be comprised of 301 to 1000 transistors. πT here is similar to the voltage regulators and C2 has increased because the number of pins has increased from 3 to 16. This data was obtained from MIL-HDBK-217F [2].

MAX4295 Mono Amplifier:

[pic] 0.020

[pic] 16

[pic] 0.0072

[pic] 6.0

[pic] 10

[pic] 1

therefore, [pic] 3.632 failures per [pic] hours of operation

[pic]

Explanation: C1 was chosen assuming that an RS232 level converter is similar in complexity to a voltage regulator. πT here is similar to the voltage regulators and C2 has remained constant because both the amplifier and the RS232 level converter have 16 pins.

Reliability

Conclusion: It appears that the reliability of electronic components decreases as complexity increases. The highest reliability levels (λp = 3.272 failures per 106 hours of operation) are those of the linear voltage regulators and the lowest reliability level (λp = 6.832 failures per 106 hours of operation) is that of the RS232 level converter (which has more pins and has been assumed to be more complex in number of transistors). These calculations may be misleading, however. The junction temperature was assumed to be less than 100° C for each component above. This assumption would suggest that all of these devices are operating in a similar temperature range. In reality, however, the 5V voltage regulator will be running at the closest temperature to 100° C (due to the fact that it will be driving multiple components and will be providing a significant amount of current). The rest of the components will be running cooler and πT could feasibly be reduced when calculating λp. If this were done, the reliabilities of the cooler running devices would be increased.

5. Ethical and Environmental Impact Analysis

Upon bringing the MIDI Maestro project to a marketable condition, there are several ethical and environmental issues that must be resolved. This section will thoroughly address each of these concerns, as they apply throughout the product’s life-cycle. Most attention will be focused on issues applying to “green engineering” and those issues that must be “…consistent with the safety, health and welfare of the public.” [11]

Ethical Impact Analysis

The MIDI Maestro has several ethical issues which must be resolved in the process of bringing the design to market. These ethical challenges most regularly fall into 4 separate categories, including: testing at a variety of operating conditions, necessary warning labels, cautionary user documentation, and safety mechanisms.

The first of the ethical challenges encountered is testing at various operating conditions. Because marketing the product means that the product will undergo shipping within its lifetime, shipping conditions must be considered. In order to account for such conditions, a “drop” test will be done on the MIDI Maestro. This test will ensure that the product is both stable and reliable, and will continue to function as intended throughout its life-cycle. A temperature test will also be performed to insure that the product does not become extremely hot after long periods of use. If the device was to reach excessive temperatures, the safety and welfare of the user could be in danger.

The placement of necessary warning labels is also an important ethical challenge to address, in order to prevent safety hazards. Several warning labels will be attached to the enclosure of the MIDI Maestro. The first of these will warn the user against disassembling the plastic enclosure of the product, due to the fact that there are no user serviceable parts inside. Another warning label that will be attached to the device is one that will set an age limit for using the device. This is necessary because there are small rotary knobs on the MIDI Maestro that could be potentially harmful to small children if removed and accidentally swallowed. To further ensure that this does not happen, the knobs will be securely fastened to the metal rotary stems of the device.

With a similar purpose as warning labels, user documentation will also provide cautions to the user that “…promptly disclose factors that might endanger the public.” [11] Thus, the user documentation will reiterate in more detail each of the warning labels included on the device. The documentation will also be responsible for explaining proper use and proper storage of the device. It will clearly state the intended uses of the MIDI Maestro, so that users will not use it in any way that could be potentially harmful. One of the concerns addressed will be that the product should only be powered by the included power supply plugged into a 120V AC, 60Hz wall plug. As with any electrical device, it should never operate in or around water, due to the risk of electrical shock.

The fourth and final ethical challenge faced in bringing the MIDI Maestro to market is application of safety mechanisms. Due to the nature of this device, there are relatively few extreme safety hazards other than risk of electrical shock. However, to ensure complete safety and satisfaction of the user, several other minor concerns will be addressed. There will be a maximum decibel level allowed for MIDI output from the MIDI Maestro to avoid extreme noise levels that could possibly damage the user’s ear drums. As mentioned previously, safety mechanisms will be implemented to ensure that the rotary knobs are very securely fastened to the device. This will prevent potential harm to young children who may attempt to put small, loose parts into their mouths. Also, a fuse will be used to prevent safety hazards if a short circuit was to occur.

Environmental Impact Analysis

As with all electronic devices, the MIDI Maestro has several environmental issues which must be considered throughout the various stages of its life cycle. There are several stages including manufacture, normal use, and disposal which must be analyzed in the process of bringing the MIDI Maestro to market. In order to follow environmental standards, the motto of the EPA, “…to protect human health, and safeguard the environment” [11] , will be kept close in mind when addressing each stage of the MIDI Maestro’s life-cycle.

The first stage to be analyzed is the manufacturing stage. During the manufacturing stage, there is one main concern to be addressed. When producing the printed circuit board (PCB) a variety of production wastes are created. “Reducing this waste generation can decrease your future liabilities, make regulatory compliance easier, and reduce disposal costs. Typical wastes generated by the PC board industry are: industrial wastewater and treatment residues, spent process baths, acids used for cleaning equipment, copper sulfate crystals, and re-flow oils.” [13] Although these wastes are an inexorable part of the manufacturing of electronics, there are many methods that can reduce the amount of waste produced. One new environmental technology that has been certified by the EPA is an “…ultrasonic aqueous cleaning system used in the electronics industry to clean various types of solder pastes from printed circuit board stencils.” [13] These new types of technology can greatly reduce the environmental harm created during the manufacturing stage of the MIDI Maestro.

The second stage of the MIDI Maestro’s life-cycle to be analyzed is the stage of normal use. The MIDI Maestro does not produce any substances that are harmful to the environment while in the normal use stage. Thus, the main concern during this stage is the use of energy. When readying the MIDI Maestro for marketing, much care will be put into giving the device a minimal rate of power dissipation. By doing so, it is ensured that the device is still friendly to the environment during normal use.

The final stage of the MIDI Maestro’s life-cycle is disposal. This is a potentially harmful stage, as the device’s PCB contains traces of lead. Because lead is a particularly harmful substance to the environment, it must be properly disposed of, or recycled. There are many organizations that will “…shield your company from liability and privacy issues to the EPA” [12], when disposing of such devices. One such company is PC Disposal, which can be found at . After disposing of these hazardous parts of the product, other parts such as the plastic connectors, knobs, and enclosure will also be recycled. The above methods will minimize any harmful side effects that the MIDI Maestro may have on the environment.

6. Packaging Design Considerations

The MIDI Maestro will be packaged in a rectangular box containing all necessary components for plug-and-play operation. The size of the packaging will be minimal, in order to allow the game to be portable. However, it must be large enough to encase such components as the microcontroller, heatsink, power supply, and a small amplifier and speaker. Other major packaging considerations include the need for a rather professional, aesthetic quality and also be lightweight.

Analysis of Commercial Products

The first product to be analyzed is the Roland Sound Canvas SC-88VL. The packaging used for the SC-88VL is a slim, silver-gray, rectangular box. An illustration of the product is shown below.

[pic] [pic]

Figure 7.1 – Roland Sound Canvas SC-88VL

Positive aspects of this packaging include its minimal height and aesthetically pleasing color and look. Also, the large LCD screen and many buttons allow for quick operation of the unit. Although the Roland SC-88VL is a well thought out design, it could still stand for improvements. The many buttons are very tiny on the front of the packaging and seem as though they would be very cumbersome to use. Also, due to the fact that the Roland has no internal speaker, the device is not easily portable.

The main aspects of this design that will be adapted to the MIDI Maestro include the size and positioning of the large LCD display on the front of the packaging. Also, the MIDI Maestro’s packaging will be of the same shape, except varying in size from that of the Roland SC-88VL. The positioning of the MIDI IN and MIDI OUT jacks on the back side of the SC-88VL will also be adapted to this design. One main aspect of the MIDI Maestro’s packaging that differentiates it from this product’s packaging is the grated area that allows for the MIDI Maestro’s internal 2.5” speaker to be clearly heard. Also, the outer interface will also be much more simplistic on the MIDI Maestro and less cumbersome to use.

The second commercial product that is to be analyzed is the classic game of Simon by Milton Bradley, from which our project idea is based. Simon was packaged in a round, black, plastic enclosure with 4 large, colorful, pressing pads on its top surface. An illustration of this packaging is shown below.

[pic]

Figure 7.2 – Simon by Milton Bradley

Positive aspects of Simon’s packaging include its large, easy to use buttons, colorful look, and durability. Simon is also very simplistic, having only 6 buttons on the top face of the device. One last positive aspect of Simon is that the unit is battery powered, allowing it to be taken almost anywhere. On the negative side, Simon is fairly large at approximately 4” deep and over 1’ in diameter, and requires 2 “D” cells and a single 9-volt battery for operation.

The positive aspects of Simon that will be adapted to the MIDI Maestro are its simplicity and ease of use. The MIDI Maestro will have two rotary knobs and an easy to use LCD display to control the different modes of the game. Several qualities will differentiate the MIDI Maestro from the classic game of Simon. First, because the game is to be used with a MIDI keyboard, an external AC power source will be used since one should be readily available anywhere a MIDI keyboard can be used. Also, the MIDI Maestro will be much smaller in size than the rather large Simon.

Specifications for Packaging

A detailed scale CAD drawing is included to illustrate the size and shape of the MIDI Maestro’s packaging. The packaging chosen is 7.8” long, 4.4” deep, and 3” in height. As seen in the illustration, there are drilled openings on the top of the enclosure to allow mounting of the 2 rotary knobs. There is also a square opening to house the LCD display. On the left side, there are 3 round holes. Two of these are used to mount MIDI connectors, and the third is for connecting external power to the device.

Materials that will be used in packaging the MIDI Maestro are the plastic molded project box in which it is encased, and 11 screws to put the lid on the enclosure and mount the speaker and LCD. Since all components are available off the shelf, no special tooling is required. Basic workshop tools such as an electric drill, screwdriver, and a sharp, utility knife are sufficient to use in the project.

Estimate of Packaging Weight and Unit Cost

The project enclosure we have chosen has dimensions of 7.8” X 4.4” X 3” and is made of molded plastic. Other parts and their approximate weights and costs are estimated below.

|Part |Approximate Weight |Approximate Cost |

|Transparent Blue Plastic Enclosure X 1 |500 grams |$10.38 |

|Screw X 11 |55 grams |Free of Charge |

|2.5” Speaker X 1 |1000 grams |$5.25 |

|MIDI Connector X 2 |20 grams |$2.76 |

|---------------------------------- |--------------------------------- |---------------------------------- |

|Totals |1575 grams |$18.39 |

Table 7. 1: Approximate Packaging Weights and Costs

7. Schematic Design Considerations

Theory of Operation

ATmega32: The function of the microprocessor is to receive MIDI signals via the USART and ultimately compare them with predetermined signals or signals that have already been received and recorded. It also receives interrupts from a rotary pulse generator, or optical encoder, for menu selection purposes. The menu is on the LCD screen, which the microcontroller controls as well. The Atmel chip will send the data to the LCD screen via Port A, and will send control signals (select lines, reset, and read/write) via Port C. The voice chip, ISD4003 from Winbond, is controlled by the ATmega32 as well, by the MOSI, SS, and SCLK pins of Port B. [19, 4]

The microcontroller will run at 8MHz which is fast enough to process the necessary information in a timely manner. The most time-critical data are the MIDI signals, since a melody consists of notes played at distinct times for a particular duration. During game play, when the MIDI signals are important, only minimal information will be sent to the graphical LCD screen. The voice chip will only be sent a signal when a mismatch in melodies has been detected. The ATmega32 will be powered by the 5V output of the power supply. Since the power supply is attached to a 120VAC outlet, 5V and 8 MHz were chosen because power dissipation is not a pressing issue.

ISD4003: The function of the voice record/playback chip is to play back various messages when called upon by the microcontroller. The SPI port (part of Port B) of the microcontroller consists of a MISO pin, MOSI pin, SS pin, and SCLK pin. Since the ISD4003 is the slave chip, the MOSI pin is used (Master Out Slave In). This pin sends the control signals and addresses to the ISD4003. The SS is just a select line for the chip, and the SCLK is the serial clock for message transfer. The ISD4003 has an internal clock running at 1MHz (for a sample rate of 8.0 kHz) which will not be changed. It runs at 3V, which is another output of the power supply circuitry.

The output of the ISD4003 is attached to the amplifier circuit, consisting mainly of the MAX4295 from Maxim. The MAX4295 is powered by the 5V output of the power supply, and is configured to output a 2W amplified signal to the speaker. A potentiometer is in place to control the volume (gain) of the amplifier. [4]

CFAG12864: The function of the LCD screen is to display necessary information to the player(s). It will have a menu to select various options and game-play modes. As described earlier, the data lines will be Port A of the microcontroller, and the control lines will consist of six pins from Port C. The supply voltage for the logic of the display is 5V, which has become pretty much standard in this design. The operating voltage, however, necessary to illuminate the display can be variable. For a clear and distinctive display a higher voltage is needed. The data sheets for the CFAG12864 are unclear and self-contradictory about the maximum operating voltage, so it was decided (by prototyping) that 8V provides a clear display while staying well within the limits. A potentiometer will be in place to adjust this voltage though, acting as a contrast control. [5]

No external clock is needed for this chip, and there is no internal clock from the information gathered. The operating frequency then only has one constraint, which is the hold time for the internal memory of 1000ns. That yields a maximum frequency of 1MHz, and this number will not be approached due to the speed of the output from the microcontroller and the fact that the LCD is not time-critical to the point of microseconds. Also, there is a backlighting chip, HV823, which is powered by the 5V supply for convenience (it can use anything from 2 to 9.5V). It contains a DC-to-DC converter, which produces a 75V signal at 380Hz used for lighting. [23]

Power Supply: The power supply circuit uses a 9V DC source (“wall wart” adapter) and then regulates it with a L78L33AC and L7805 to produce a 3V and 5V source, respectively. To create the necessary supply voltage for lighting the LCD, a RS232 level converter (MAX243) was used. This chip was chosen because it took in a 5V signal, then doubled it, then inverted it, making a perfect source of power for the LCD, since the LCD uses only 1.5mA. Also, the RS232 level converter will only be used while debugging. The -10V is in series with a potentiometer for contrast control. [21, 22]

8. PCB Layout Design Considerations

The MIDI Maestro is designed to fit inside a 3.75 by 8 inch box. This requires that the size of the PCB be no larger than 3.5 by 4.5 inches. This allows room for the speaker, which is also mounted inside the box. Component placement was therefore an important factor in the layout of this board. To reduce EMI, bypass capacitors for all digital components were included. [24, 25] To ensure that the capacitors were placed as close as possible to the components they are associated with, the components were first separated by functionality. They did not have to conform to the space requirement at this point. Then, all of the capacitors were placed immediately next to the pin that they provide protection to. The groups of components were then brought closer together to fit on the board.

Components were separated into two major categories, analog and digital. The major analog components are the amplifier IC, and the voice chip. Major digital components include the microcontroller, the RS-232 level converter, the voice chip, and the LCD. The two types of components were physically separated, with the voice chip nearby to both.

All major power and ground traces were set to 40 mils to ensure proper current handling and noise reduction. For some of the components with smaller pins, the traces had to be reduced to 12 mils when entering the pins. The power and ground systems are separated into two major supplies. This is due to the fact that there is a mixture of analog and digital components in the design. The analog and digital supplies meet at a single point near the voltage regulator to minimize noise.

Electrical constraints, noise reduction, and size limitations were not the only considerations in the PCB layout design. Another key consideration is the physical placement of certain components. The PCB is designed so that the only off-board component is the speaker. The LCD connects to the board via a header, and the optical encoder and volume potentiometer are both mounted directly to the board. This makes the overall look or the project much cleaner. To accomplish this along with allowing for easy debugging, the LCD, optical encoder, and volume potentiometer are mounted to the “back” of the board. All other components, save a few capacitors, are mounted to the front. The placement of the LCD, optical encoder, and volume potentiometer were carefully planned to present a pleasing finished look on the front of the project’s box.

Most of the components matched library footprints, so only a few custom footprints needed to be designed. The optical encoder is basically a six-pin header, which is in the standard OrCad libraries, but for ease of placement and to ensure that no component be placed in its place, a custom footprint was designed. The volume potentiometer and power connector do not match any footprints in the libraries, so they also needed custom footprints.

The final layout was printed and compared to the actual components to make sure that the physical size of the components match with the manufactured board. Everything lined up fine, so the layout was sent to and sent for manufacture.

9. Software Design Considerations

The software in the MIDI Maestro orchestrates the functionality of the device. In both modes of operation of the MIDI Maestro, the players’ input notes are recorded into a circular buffer and their timings are stored in a statically allocated array of Booleans corresponding to time ticks (divisions of measures). MIDI output (backing rhythms) are polled against a timer while MIDI input is interrupt driven. RPG movement and pushbuttons are also interrupt-driven in advanced multi-player mode and in the menu navigation system. The body of this report details these major concepts and provides an overview of the flow of embedded software in the MIDI Maestro.

Software Design Considerations

Memory Sections/Mappings:

The memory on the Atmel ATMega32 is divided up into three regions [19]. These regions are the Flash Program Memory Space, the SRAM Data Memory Space, and the EEPROM Memory Space. The flash is used to store the source code, the SRAM holds all globally declared variables and arrays, and the EEPROM stores the strings that are used in the menu system.

Flash Program Memory Space:

• $000 - $FFF (4Kx16bits)

• Boot Sector resides in upper portion of Flash Program Memory Space

SRAM Data Memory Space:

• $0000 - $001F is the 32 entry registry file

• $0020 - $005F are the I/O registers (addressed as $00 - $3F)

• $0060 - $025F is the internal SRAM (512 x 8bits)

EEPROM Memory Space:

• 1024 x 8bits addressed through I/O registers

• EEAR register 8..0 is the read/write address

• EEDR register 7..0 is the data read/written

Memory Models (Data Structures):

The primary data structures that are used in the MIDI Maestro exist to store and/or analyze MIDI data based on the current mode of game play. Since both the microcontroller generated backing rhythm and the user provided MIDI input are strongly dependant on the same real-time constraints, the MIDI streams in both cases are stored in similar ways. Both will use a statically allocated array of booleans with entries corresponding to divisions of a measure (i.e. 16 ticks per measure for 4/4 time or 12 ticks per measure for 3/3 time). In the case of the backing rhythm, if the boolean value is true for the current time tick (based on Timer 0), the next note in the statically allocated array will be played. An example of this storage scheme is shown in Figure 10.1.

[pic]

Figure 10.1: Backing Rhythm Data Storage

In advanced multi-player mode, where key sequences are compared between two users, if user input is received, the corresponding boolean will be set in the time tick array (again based on Timer 0) and the note data will be added to the midi input data array. This user data can be analyzed after it is stored.

Startup Code [3]:

The startup code initializes the correct input and output pins on ports A through D, enables the UART with a 16 character buffered interrupt driven receive and a baud rate of 31250, enables the SPI as master with a clock of 2MHz, and sets up Timer 0 with an initial value of 0. The UART is used to send and receive MIDI data, the SPI is used to communicate with the ISD4003 Voice Record/Playback Chip, and Timer 0 is used to keep track of timing of MIDI data.

Organization of Embedded Code:

The MIDI Maestro’s run-time software is broken down into the following functional blocks:

• MIDI Input

• MIDI Output

• MIDI Data Analysis

• LCD Output

• Analog Audio Message Initiation

• Menu Navigation

• Mid-Game Control

The MIDI Input Block is responsible for obtaining MIDI data and filtering unused input, the MIDI Output Block is responsible for sending the backing rhythm to the MIDI keyboard, the MIDI Data Analysis Block will either compare users’ real-time input streams or compare non-real-time sequences (dependant on game mode), the LCD Output Block is comprised of character and graphic generation routines, the Analog Audio Message Initiation Block is responsible for sending the correct audio clip request to the ISD4003 Voice Record/Playback Chip, the Menu Navigation Block is responsible for setting up initial game settings, and the Mid-Game Control Block handles user control requests during game play. These blocks are described in detail in the next section.

Software Design Narrative

MIDI Input Block [1]:

This is an interrupt generating block that reads MIDI data on the UART input of the microcontroller that is sent from the MIDI keyboard. If the input is invalid (i.e. pitchbend wheel data, MIDI control knob data), it is discarded. If the input is valid, the note data is placed in the input data array so that it can be analyzed at a later time. In multi-player advanced mode, the offensive player fills the midi input data array and in basic sequence building mode, the current sequence fills the midi input data array. In advanced multi-player mode, the tick corresponding to Timer 0’s value will be set in the tick array.

NOTE: Only MIDI start messages are recorded. MIDI stop messages need not be recorded since simultaneously requiring users to press and depress keys at the same time is not the Midi Maestro’s intention.

MIDI Output Block [2]:

This is a polled block that works closely with Timer 0 to generate the backing rhythm in multi-player advanced mode. If Timer 0’s value has not yet reached a value allowing the MIDI Output Block to move to the next tick in the tick array, nothing is done. If Timer 0 reached the value corresponding to the next tick, the MIDI Output Block resets Timer 0 and moves to the next index in the tick array. If the corresponding value is false, nothing is done. If that value is true, the next MIDI message is sent to the keyboard via the UART transmit port. This block then waits again until it can move to the next index in the tick array and repeats.

NOTE: Both MIDI start and MIDI stop messages are sent. Also, the backing rhythm data is sent on MIDI ports 2 through 16 with one instrument per channel. Data is not sent on port 1 (excluding during initializations) because this software assumes that the user’s MIDI keyboard is set with the ‘Remote Input’ option set to port 1. Any sent program change MIDI messages (instrument changes) on port 1 will then result in changing the user’s selected instrument, which is not the MIDI Maestro’s intent.

MIDI Data Analysis:

The MIDI Data Analysis Block assumes two roles based on the mode of game play. In advanced multi-player mode, after one player has provided a key sequence and the other player has attempted to duplicate it, the MIDI Data Analysis Block compares the two. It does this by stepping through both the tick arrays and the circular buffers to determine if the attempted sequence duplication is sufficient in both timing and note data. This block is slightly forgiving in its comparisons since requiring exact duplication would make game play impossible and boring. More leeway, however, is given to slight timing differences than to note differences. In basic sequence building mode, the data stored in the current buffer is compared with the data stored in the past buffer. If duplication is not exact, the sequence is considered invalid.

LCD Output:

This block is a collection of routines (character generation, graphic generation, and LCD control) that aid in displaying data on the LCD. The display can be easily turned on and off, sides of the LCD can be chosen (the LCD is divided into two halves vertically), the LCD can be cleared, and lines of characters and graphics can be generated. These routines send all required instructions to the LCD, assert all data/address clock signals, set all address/data lines, and most importantly, separate the programmer from the inner workings of the LCD.

Analog Audio Message Initiation [2]:

When user’s need to be alerted of game messages via the internal MIDI Maestro speaker, the Analog Audio Message Initiation block provides a wrapper of control for the ISD4003 Voice Record/Playback Chip. This block places the ISD4003 in play mode by sending a single ‘powerup’ instruction via the microcontroller’s SPI port, sets the play address for the desired message (based on passed parameters), and initiates playback by sending the ‘play’ instruction.

Menu Navigation:

When the MIDI Maestro is powered on, a game setup screen is displayed. The Menu Navigation Block is responsible for displaying the menus, reading interrupt driven input from the RPG, moving cursors, debouncing button presses, and selecting menu items. When information is entered by the user, the Menu Navigation block stores game data such as: number of players, game mode, game personality, number of challenges, and difficulty levels. These are stored in global variables that can be used by the rest of the software.

Mid-Game Control:

The Mid-Game Control Block is responsible for initiating game play, handling user requests during game play, invoking the Analog Audio Message Initiation Block, and ending game play. During game play, the Mid-Game Control Block handles user control requests. These can be game exit requests or tempo change requests. Game messages (played on the internal MIDI Maestro speaker) may also be initiated during game play. Finally, the Mid-Game Control Block is responsible for determining the end of game play, assigning a winner, and generating appropriate game messages. After game play is complete, this block relinquishes control to the Menu Navigation Block.

NOTE: While in basic sequence building mode, the Mid-Game Control Block retains the underlying flow of control. This is different in advanced multi-player mode where the underlying flow of control is relinquished to the MIDI Output Block.

Software Flowcharts

Basic Sequence Building Mode (3 or more players):

[pic]

Advanced Multi-Player Mode (Offense Player):

[pic]

Advanced Multi-Player Mode (Interrupt Service Offense):

[pic]

Advanced Multi-Player Mode (Defense Player):

[pic]

Advanced Multi-Player Mode (Interrupt Service Defense):

[pic]

Advanced Multi-Player Mode (End of Current Phrase Service):

[pic]

NOTE: End can be considered a path back to Game Setup Screen

10. Version 2 Changes

If the MIDI Maestro were to be redesigned, there are several things that would be done to create a more seamless, reliable project. First, the sound quality of the audio output block would be investigated and improved. More game messages and better segues between players in HORSE mode would be defined. The development headers would be removed and the fly-wiring issue with the ISD chip would be resolved. Hardware switch debouncing would be implemented to minimize the complexity of the real-time MIDI software, and enhanced software would be written to make game play smoother and more user friendly. Finally, fail-safes would be designed to maximize the MTTF (Mean Time to Failure) in order to create a more reliable device.

Summary and Conclusions

The MIDI Maestro is a great success. Given the time the group had to accomplish this project, group three has achieved much. Every success criteria was met with additional time for gold plating. For instance, there are three different selectable backing rhythms for HORSE mode. Also, time was spent adding a backlight driver for the backlight included with the LCD. An advanced menu system was developed when a simple menu system would have sufficed to meet success criteria.

In completing the various stages of this project, new knowledge was gained in the areas of schematic designs, printed circuit board layout, embedded software, soldering techniques and integration of 3rd party hardware. Also, miscellaneous professional aspects of product development such as safety and reliability, patent liability, ethics, and environmental analysis were gained. This was also the first experience in taking an idea all the way from conception to completion of a finished product.

References

Constraint and Component

1. Atmel AT90S8535

2. AT90S8515 alt chip

3. Rabbit 3000

4. ISD4003

5. Crystall Fontz CFAG12864B

Patent

6. Patent no. 4,207,087. Microcomputer controlled game

Manufacturer: Milton-Bradley, simon

7. Patent no. 5,855,513. Electronic matching and position game

Manufacturer: Tiger Electronics, Ltd.

8. Patent no. 5,113,741. Performance recording apparatus for recording information used to control music generation instruments.

Similar product:

Reliability

9. Module 9 Lecture Notes for ECE477 Spring 2004



10. Reliability Prediction of Electronic Equipment Military Handbook



Ethical

11. IEEE Code of Ethics

12. United States Environmental Protection Agency



13. Printed Circuit Board Manufacturers



14. Environmental Protection Agency



15. PC disposal

Packaging

16. Plastic Molded Project Enclosure



17. Roland Sound Canvas SC-88VL



18. Simon by Milton Bradley



Schematic

19. ATmega32

20. Grayhill RPG

21. MAX4295

22. MAX243

23. HV823

PCB Layout

24. Motorola AN1259:

25. Atmel AVR042:

Software Narrative

26. CodevisionAVR C Compiler

Version 1.23.8d Standard

Appendix A: Individual Contributions

Contributions of Ben Johanek:

Ben Johanek contributed a significant amount of time in the following areas: MIDI Input, MIDI Output, Crystalfontz LCD Exploration, ISD4003 Voice Record/Playback Chip Exploration, and Software. He also formulated the initial idea for what the project would be.

To start the MIDI interfacing, Ben worked on getting MIDI output to function and to get the Atmel microcontroller to play rhythm loops. In order to do this, Ben studied the MIDI specification and gained an understanding of the sequences of messages MIDI devices send. He also worked on getting the USART to send MIDI data at the right baud rate. When troubles were encountered here, he utilized oscilloscopes and a known working source (his PC soundcard) to determine the nature of the problem. He helped to do research to determine that the microprocessor’s internal clock was not being set correctly (therefore, data was not being transmitted at the correct baud rate) and that data was not being transmitted on the correct pins (the specification did not dictate the orientation of the MIDI DIN5 connectors). To get the Atmel microcontroller to generate loops, he devised a data storage scheme that worked in conjunction with a timer to send MIDI data at the correct times.

In order to get the MIDI Input section of the MIDI Maestro to function, Ben did research on how the USART on the Atmel microcontroller functions. He explored baud rates, input buffers, and data bit order. He also studied the MIDI spec to determine how data is received by a MIDI device and worked on getting the Atmel Microcontroller and the USART to communicate. Once data is received, it needs to be stored so it can be later analyzed and Ben devised a scheme to store both note data and rhythm input data.

Ben also spent a significant amount of time on understanding how the Crystalfontz LCD functions. He read the datasheets (multiple Crystalfontz datasheets were used to gain a complete understanding of how the device functions), gained an understanding of the instructions that the LCD uses to operate, and studied the sequence of instructions necessary to make the LCD function. He also helped in initial prototyping to verify that the group did, in fact, understand exactly how the LCD works. Finally, Ben helped to uncover some clocking issues that were introduced when the group finally got their microcontroller working at 8 MHz instead of 1 MHz. When the clock speed was increased, the display no longer functioned and he helped to discover that the microcontroller was providing data faster than the LCD could handle.

The device that gave the group the most trouble was the ISD4003 Voice Playback/Record Chip (a serial device) and Ben put a large amount of time into figuring out how to make the chip function. To start this undertaking, Ben helped to understand how the SPI on the microcontroller works and how it asserts slave select signals, serial clocks, and how it deals with timing. He did a lot of work with the ISD4003 datasheet to understand the instructions that the chip uses to operate, the sequences of instructions, the timings of instructions, and the data that the chip expects. He helped to uncover the major problem that the group had with getting the chip to work. It turns out that the datasheet listed the LSB of the data packets on the left with the MSB on the right. The only indication of the orientation of the bits was a small diagram in a completely different section of the datasheet and once this nuance was discovered, the chip finally functioned.

Ben’s final significant contribution was in the software of the MIDI Maestro. Ben designed the overall software scheme that the device would use to function. He coded the MIDI Output data buffers and used timers to generate the background loops in HORSE mode. He also coded the rest of the HORSE mode of operation which involved setting current player, offensive vs. defensive player, analyzing input data with a #defined tolerance, and keeping track of players’ scores. He also wrote two of the three user-selectable backing rhythms and coded all three into the device. Ben provided efforts to setup and code the menu system and worked on the software to control the SPI and timers. Since everything didn’t work initially, he spent a large amount of time on the debugging of the software.

Since Ben provided his help on all five of the success criteria and spent many late nights and weekends on the project, he feels that the course grade he should receive is an A.

Contributions of Ryan Denison:

Ryan Denison contributed a significant amount of time in all of these areas: Initial exploration of the CodeVisionAVR software and embedded C language, Crystalfontz LCD prototyping and exploration, packaging design, packaging construction, initial menu system layout and design, switch debouncing, writing MIDI input software, and software debugging.

Ryan began exploring the use of the CodeVisionAVR software that was used to program our entire project. He figured out how to use the available wizard to generate the necessary files and also how to use the software to access each port and pin of the microcontroller. Ryan had a small amount of experience with embedded C from his current job, which aided this process. When the Crystalfontz LCD arrived he studied the datasheets to gain an understanding of the device. He then helped with prototyping and writing several routines used to print data to the 128 X 64 pixel graphical display.

Several weeks after the final proposal of our project idea, Ryan designed the packaging for the MIDI Maestro. The packaging was designed to have several important qualities. The packaging needed to be aesthetically pleasing, professional, small, and lightweight. After Spring Break, while waiting for several parts to arrive, Ryan spent many hours in lab constructing the designed packaging. Since the available tools were not extremely helpful, an X-acto utility knife had to be used to slowly and carefully trim away the necessary plastic. The drill bit used to create holes for the MIDI jacks would not fit in the supplied drill, thus it had to be cranked by hand. He believes that his packaging design has made the MIDI Maestro be one of the best looking projects in the class.

While Matt was busy soldering, Ryan created pages of illustrations for each screen that would be included in the MIDI Maestro’s menu system. Once the PCB was populated, he single-handedly programmed the first version of each of these menus. Once the final menu system was in place, Ryan spent many hours figuring out how to debounce the push-button switch within software. This proved to be a larger task than expected.

Once the menu system had been completed, Ryan helped write the software needed to receive and store MIDI messages from the keyboard. After Matt realized that the keyboard was outputting several useless messages (Active connection signals), Ryan spent much time figuring out which of these messages needed to be filtered, in order to get meaningful data from the keyboard. Lastly, Ryan put in a significant amount of time helping Ben debug various parts of the MIDI out code and the game code.

Ryan spent countless nights in the lab, and put a significant amount of time towards each of the five project-success criteria. He feels that the course grade he deserves for this is an A.

Contributions of Matt Burgess:

Matt Burgess contributed a significant amount of time towards finishing this project in the following areas: project exploration, parts selection, prototyping, PCB layout, PCB population, packaging construction, and embedded software development.

At the beginning of the semester, the group was having a very difficult time finding a project that would be feasible, different, and most of all, interesting to the group. During this time, Matt spent countless hours exploring project options. This included talking with people in the industry to find out what sort of devices were lacking on the market. Then, after brainstorming possible projects, much time was spent determining its feasibility.

When the project had been decided upon, Matt spent much time determining what functional blocks would be necessary to realize the project. After this had been solidified, he helped research what type of components might be useful in implementing these blocks. After these parts had been ordered and received, Matt spent most of his free time working on prototyping and exploring interfacing the group’s new Atmel with each major component. Specifically, Matt had a hand in interfacing with the LCD, RPG, and ISD chip. He also helped other students understand the MIDI specification and implement it in hardware.

When the schematic had been finished, Matt worked diligently on the PCB. Much time was spent carefully placing all of the components to minimize size, noise, and debugging hassles. When the board came back from the factory, Matt spent many hours testing the layout and populating the board. He carefully placed, examined, and then tested every component to ensure full functionality.

When the board was nearly completed, the group was waiting on several critical, but small, components. Instead of simply waiting for these to arrive, Matt turned his focus to the packaging. While the design was completed by another student, the manufacture and assembly was mostly completed by Matt. This was the case mostly because the PCB determined the placement of several of the components that determine packaging requirements, such as the RPG and LCD. Several full days were spent in lab cutting away the plastic enclosure the group purchased, mounting the board, and mounting the speaker and LCD.

Before the PCB could be tackled, Matt spent much time developing routines to interface with the LCD. This involved writing his own font for use with the group’s special graphical LCD. He also wrote the routines to output these fonts as a function of the vertical ‘slices’ that represent each letter. After the board and packaging were finished, Matt turned his entire focus to the final embedded software. He spent much time helping to write the RPG interrupt service routines and the entire menu system. He single-handedly wrote the code to implement the sequence mode of operation. He also was responsible for tailoring the automatically generated USART input code to suit the group’s needs. The code needed to be augmented so that it would ignore certain MIDI messages received on the port.

Matt has spent an enormous amount of time developing many aspects of this project. He was responsible for the development of many aspects of the MIDI Maestro. Feeling that if it were not for his efforts, all of the success criteria would not have been met, and for his time and effort expended towards this project, Matt believes that he deserves an A in the class.

Contributions of Christopher Coy:

Christopher Coy contributed a great deal to several parts of the project and the design process. Most of these efforts were in the fields of research and debugging, as well as schematic design. After the group formulated an idea that was approved by the course administration, he began to research various controllers, LCD screens, and sound chips. This was done in an effort to determine which components would work best together, which components would be cheapest to purchase, and which components would be the simplest and most straightforward to implement.

Next, Chris summarized his findings and discussed with the group which parts to use, so that a finalized parts list could be created (for the major components). Then he completed the design constraint analysis and component selection rationale homework, which entailed comparing and contrasting the various choices for the microcontroller, LCD screen, and voice chip.

With the components selected, Chris began to research the datasheets and typical application notes for the microcontroller, and various other components. This was to determine which analog components would be needed to have the components functioning properly. Then Chris pieced together the functional blocks of code into a full schematic. He had a little help with some of the power supply considerations from his teammates. All in all, the schematic effort took about 30 hours, including the report.

After the schematic was completed, the design review was soon to come, so Chris began compiling information and creating PowerPoint slides. He also split up the schematic back into functional blocks, for simplicity. Then he created a block diagram to give a general illustration on how the entire system worked. Finally, the group was ready to present.

Some changes were made during the presentation, and so Chris updated the schematic to include these modifications. Then he practiced soldering surface mount components in preparation for hardware assembly phase. But then other matters were more important, so he experimented with debouncing the control knob, researched code, and designed a splash screen (that would later not be used due to space issues on the microcontroller).

Over the next couple months, Chris spent his time helping debug software and communication issues with the voice chip. Eventually, everything was completed and the group was ready for the presentation. Chris made most of the PowerPoint slides for that, and completed various final tasks, especially for the project summary. After all his effort in every aspect of the project, Chris believes he deserves an A in the class.

Appendix B: Packaging

[pic]

Figure B.1: Front, Right Side View Packaging Illustration

[pic]

Figure B.2: Rear, Left Side View Packaging Illustration

[pic]

Figure B.3: Front, Left Side View Packaging Illustration

Appendix C: Schematic

[pic]

Appendix D: PCB Layout Top and Bottom Copper

[pic]

Fig D.1: PCB Layout Top Copper

[pic]Fig D.2: PCB Layout Bottom Copper

Appendix E: Parts List Spreadsheet (Major Components)

|Component |Vendor |Part Number |Unit Cost |Quantity |

|Atmel ATmega32 |Digikey |ATMEGA32-16AC |$10.11 |1 |

|ISD Record/Playback Chip |Digikey |ISD4003-04MP-ND |$11.83 |1 |

|Grayhill RPG |Digikey |GH6101-ND |$20.55 |1 |

|Crystalfontz LCD |Crystalfontz |CFAG12864B-WGH-N |$24.13 |1 |

|5V Linear Voltage Regulator |Digikey |L7805ABD2T-TR |$0.93 |1 |

|Maxim Mono Amp |Maxim |MAX4295 |$1.00 |1 |

|RS232 Level Converter |MAXIM |MAX243 |$2.20 |1 |

|Supertex EL Backlight Driver |Mouser |HV823LG |$2.20 |1 |

|3V Linear Voltage Regulator |Mouser |IRL7833ACZ |$0.28 |1 |

|Pioneer 2.5” Speaker |PartsExpress |FD66AP45-13F |$5.25 |1 |

|MIDI DIN5 Jack |Digikey |AK304-2 |$1.38 |2 |

|Sharp Opto-isolator |Digikey |PC900V0NIZX |$1.17 |1 |

|Knobs |Lafayette |N/A |$2.00 |2 |

| |Electronics | | | |

|Blue Plastic Enclosure |Mouser |1591ETBU |$10.38 |1 |

|Volume Potentiometer/Switch |Lafayette |N/A |$2.00 |1 |

| |Electronics | | | |

| | |Total: |$98.79 | |

Table E.1: Parts Listing

Appendix F: Software Listing

/*********************************************

This program was produced by the

CodeWizardAVR V1.23.8d Standard

Automatic Program Generator

© Copyright 1998-2003 HP InfoTech s.r.l.



e-mail:office@hpinfotech.ro

Project :

Version :

Date : 4/20/2004

Author : ee473grp3

Company : Purdue University

Comments:

Chip type : ATmega32

Program type : Application

Clock frequency : 8.000000 MHz

Memory model : Small

External SRAM size : 0

Data Stack size : 512

*********************************************/

#include

#include "glcd.h" //see below

#define DATA_BUFFER_SIZE 144

#define MIDI_IN_RHYTHM_BUFFER_SIZE 128

#define RHYTHM_BUFFER_SIZE 128

#define RXB8 1

#define TXB8 0

#define UPE 2

#define OVR 3

#define FE 4

#define UDRE 5

#define RXC 7

#define FRAMING_ERROR (1= 2 && !offense && measures > 4)

{

temp1 = getchar();

temp2 = getchar();

if (rhythm_index < RHYTHM_ERROR)

for (i = 0; i < (rhythm_index + RHYTHM_ERROR); i++)

if (midi_in_rhythm[i] != 0)

if (midi_in_data[midi_in_data_index] == temp1)

defense_passed = 1;

else if (rhythm_index > (RHYTHM_SIZE - RHYTHM_ERROR) )

for (i = (rhythm_index - RHYTHM_ERROR); i 3)

{

current_player = !current_player;

offense = 0;

draw_menu();

}

measures++;

defense_passed = 0;

defense_failed = 0;

if (player1_failures == 4)

{

GICR&=0xDF;

println(p2_wins, 7, 0);

playing = 0;

// Send SETPLAY command with address XX p2 wins

PORTB.4 = 0;

delay_us(1);

spi(0x00);

spi(0x87);

delay_us(1);

PORTB.4 = 1;

delay_ms(10000);

menu_num = 1;

draw_menu();

GICR|=0x20;

}

else if (player2_failures == 4)

{

GICR&=0xDF;

println(p1_wins, 7, 0);

playing = 0;

// Send SETPLAY command with address XX p1 wins

PORTB.4 = 0;

delay_us(1);

spi(0x03);

spi(0x07);

delay_us(1);

PORTB.4 = 1;

delay_ms(10000);

menu_num = 1;

draw_menu();

GICR|=0x20;

}

}

}

void play_challenge(void)

{

unsigned int measures = 0;

while (playing && challenging && (!game_mode))

{

//putchar(0xC8); //Channel 8 gets Rock Organ

//putchar(0x12);

Reset_Counter();

rhythm_index = 0;

midi_out_data_index = 0;

midi_in_data_index = 0;

while (rhythm_index < RHYTHM_SIZE)

{

if (midi_out_rhythm[rhythm_index])

{

putchar( midi_out_data[midi_out_data_index] );

midi_out_data_index++;

putchar( midi_out_data[midi_out_data_index] );

midi_out_data_index++;

putchar( midi_out_data[midi_out_data_index] );

midi_out_data_index++;

}

if (midi_in_rhythm[rhythm_index])

{

//note on/off...

putchar( 0x90 );

//note number...

putchar( midi_in_data[midi_in_data_index] );

midi_in_data_index++;

//velocity...

putchar( midi_in_data[midi_in_data_index] );

midi_in_data_index++;

}

timer_value = Read_Counter();

while (timer_value < (256 - tempo))

{

timer_value = Read_Counter();

}

Reset_Counter();

rhythm_index++;

}

measures++;

}

}

unsigned int Read_Counter(void)

{

unsigned int i;

i = TCNT1L;

return i;

}

void Reset_Counter(void)

{

TCNT1L = 0x00;

}

void Set_Gus_Midi_Out(void)

{

unsigned int i;

for (i = 0; i < RHYTHM_BUFFER_SIZE; i++)

{

midi_out_rhythm[i] = 0;

}

putchar(0xC1); //Channel 1 gets Taiko Drum

putchar(0x74);

putchar(0xC2); //Channel 2 gets Woodblock

putchar(0x73);

putchar(0xC3); //Channel 3 gets Reverse Cymbal

putchar(0x77);

putchar(0xC4); //Channel 4 gets Helicopter

putchar(0x7D);

putchar(0xC5); //Channel 5 gets Bird Tweet

putchar(0x7B);

midi_out_rhythm[0] = 1;

midi_out_rhythm[53] = 1;

midi_out_rhythm[6] = 1;

midi_out_rhythm[29] = 1;

midi_out_rhythm[12] = 1;

midi_out_rhythm[11] = 1;

midi_out_rhythm[18] = 1;

midi_out_rhythm[41] = 1;

midi_out_rhythm[30] = 1;

midi_out_rhythm[47] = 1;

midi_out_rhythm[42] = 1;

midi_out_rhythm[83] = 1;

midi_out_rhythm[48] = 1;

midi_out_rhythm[71] = 1;

midi_out_rhythm[54] = 1;

midi_out_rhythm[107] = 1;

midi_out_rhythm[66] = 1;

midi_out_rhythm[65] = 1;

midi_out_rhythm[72] = 1;

midi_out_rhythm[89] = 1;

midi_out_rhythm[84] = 1;

midi_out_rhythm[101] = 1;

midi_out_rhythm[90] = 1;

midi_out_rhythm[5] = 1;

midi_out_rhythm[102] = 1;

midi_out_rhythm[17] = 1;

midi_out_data[0] = (0x91); //Turn on Taiko Drum 1

midi_out_data[1] = (0x3C);

midi_out_data[2] = (0x3F);

midi_out_data[3] = (0x83); //Turn off Reverse Cymbal 5

midi_out_data[4] = (0x3C);

midi_out_data[5] = (0x5F);

midi_out_data[6] = (0x93); //Turn on Reverse Cymbal 1

midi_out_data[7] = (0x3C);

midi_out_data[8] = (0x5F);

midi_out_data[9] = (0x84); //Turn off Helicopter 1

midi_out_data[10] = (0x3C);

midi_out_data[11] = (0x3F);

midi_out_data[12] = (0x94); //Turn on Helicopter 1

midi_out_data[13] = (0x3C);

midi_out_data[14] = (0x3F);

midi_out_data[15] = (0x82); //Turn off Woodblock 4

midi_out_data[16] = (0x2B);

midi_out_data[17] = (0x3F);

midi_out_data[18] = (0x92); //Turn on Woodblock 1

midi_out_data[19] = (0x2B);

midi_out_data[20] = (0x3F);

midi_out_data[21] = (0x83); //Turn off Reverse Cymbal 1

midi_out_data[22] = (0x3C);

midi_out_data[23] = (0x5F);

midi_out_data[24] = (0x93); //Turn on Reverse Cymbal 2

midi_out_data[25] = (0x3C);

midi_out_data[26] = (0x5F);

midi_out_data[27] = (0x82); //Turn off Woodblock 1

midi_out_data[28] = (0x2B);

midi_out_data[29] = (0x3F);

midi_out_data[30] = (0x92); //Turn on Woodblock 2

midi_out_data[31] = (0x2B);

midi_out_data[32] = (0x3F);

midi_out_data[33] = (0x83); //Turn off Reverse Cymbal 2

midi_out_data[34] = (0x3C);

midi_out_data[35] = (0x5F);

midi_out_data[36] = (0x93); //Turn on Reverse Cymbal 3

midi_out_data[37] = (0x3C);

midi_out_data[38] = (0x5F);

midi_out_data[39] = (0x81); //Turn off Taiko Drum 1

midi_out_data[40] = (0x3C);

midi_out_data[41] = (0x3F);

midi_out_data[42] = (0x91); //Turn on Taiko Drum 2

midi_out_data[43] = (0x37);

midi_out_data[44] = (0x3F);

midi_out_data[45] = (0x85); //Turn off Bird Tweet 1

midi_out_data[46] = (0x3C);

midi_out_data[47] = (0x1F);

midi_out_data[48] = (0x95); //Turn on Bird Tweet 1

midi_out_data[49] = (0x3C);

midi_out_data[50] = (0x1F);

midi_out_data[51] = (0x83); //Turn off Reverse Cymbal 3

midi_out_data[52] = (0x3C);

midi_out_data[53] = (0x5F);

midi_out_data[54] = (0x93); //Turn on Reverse Cymbal 4

midi_out_data[55] = (0x3C);

midi_out_data[56] = (0x3F);

midi_out_data[57] = (0x82); //Turn off Woodblock 2

midi_out_data[58] = (0x2B);

midi_out_data[59] = (0x3F);

midi_out_data[60] = (0x92); //Turn on Woodblock 3

midi_out_data[61] = (0x2B);

midi_out_data[62] = (0x3F);

midi_out_data[63] = (0x83); //Turn off Reverse Cymbal 4

midi_out_data[64] = (0x3C);

midi_out_data[65] = (0x5F);

midi_out_data[66] = (0x93); //Turn on Reverse Cymbal 5

midi_out_data[67] = (0x3C);

midi_out_data[68] = (0x5F);

midi_out_data[69] = (0x82); //Turn off Woodblock 3

midi_out_data[70] = (0x2B);

midi_out_data[71] = (0x3F);

midi_out_data[72] = (0x92); //Turn on Woodblock 4

midi_out_data[73] = (0x2B);

midi_out_data[74] = (0x3F);

midi_out_data[75] = (0x81); //Turn off Taiko Drum 2

midi_out_data[76] = (0x37);

midi_out_data[77] = (0x3F);

}

void Set_Reba_Midi_Out(void)

{

unsigned int i;

for (i = 0; i < RHYTHM_BUFFER_SIZE; i++)

{

midi_out_rhythm[i] = 0;

}

putchar(0xC0); //change instr to steel drums

putchar(0x72);

putchar(0xC1); //Channel 1 gets Taiko Drum

putchar(0x74);

putchar(0xC2); //Channel 2 gets Woodblock

putchar(0x73);

putchar(0xC3); //Channel 3 gets Reverse Cymbal

putchar(0x77);

putchar(0xC4); //Channel 4 gets Seashore

putchar(0x7A);

putchar(0xC5); //Channel 5 gets Synth Drum

putchar(0x76);

midi_out_rhythm[0] = 1;

midi_out_rhythm[31] = 1;

midi_out_rhythm[4] = 1;

midi_out_rhythm[67] = 1;

midi_out_rhythm[12] = 1;

midi_out_rhythm[19] = 1;

midi_out_rhythm[20] = 1;

midi_out_rhythm[27] = 1;

midi_out_rhythm[24] = 1;

midi_out_rhythm[55] = 1;

midi_out_rhythm[28] = 1;

midi_out_rhythm[39] = 1;

midi_out_rhythm[32] = 1;

midi_out_rhythm[63] = 1;

midi_out_rhythm[40] = 1;

midi_out_rhythm[47] = 1;

midi_out_rhythm[44] = 1;

midi_out_rhythm[107] = 1;

midi_out_rhythm[48] = 1;

midi_out_rhythm[59] = 1;

midi_out_rhythm[56] = 1;

midi_out_rhythm[119] = 1;

midi_out_rhythm[60] = 1;

midi_out_rhythm[75] = 1;

midi_out_rhythm[64] = 1;

midi_out_rhythm[95] = 1;

midi_out_rhythm[68] = 1;

midi_out_rhythm[3] = 1;

midi_out_rhythm[76] = 1;

midi_out_rhythm[83] = 1;

midi_out_rhythm[84] = 1;

midi_out_rhythm[91] = 1;

midi_out_rhythm[92] = 1;

midi_out_rhythm[103] = 1;

midi_out_rhythm[96] = 1;

midi_out_rhythm[127] = 1;

midi_out_rhythm[104] = 1;

midi_out_rhythm[115] = 1;

midi_out_rhythm[108] = 1;

midi_out_rhythm[43] = 1;

midi_out_rhythm[116] = 1;

midi_out_rhythm[123] = 1;

midi_out_rhythm[120] = 1;

midi_out_rhythm[23] = 1;

midi_out_rhythm[124] = 1;

midi_out_rhythm[11] = 1;

midi_out_data[0] = (0x91); //Turn on Taiko Drum 1

midi_out_data[1] = (0x48);//(0x3C);

midi_out_data[2] = (0x3F);

midi_out_data[3] = (0x84); //Turn off Seashore 2

midi_out_data[4] = (0x3C);

midi_out_data[5] = (0x3F);

midi_out_data[6] = (0x94); //Turn on Seashore 1

midi_out_data[7] = (0x3C);

midi_out_data[8] = (0x3F);

midi_out_data[9] = (0x82); //Turn off Woodblock 12

midi_out_data[10] = (0x3C);

midi_out_data[11] = (0x3F);

midi_out_data[12] = (0x92); //Turn on Woodblock 1

midi_out_data[13] = (0x3C);

midi_out_data[14] = (0x3F);

midi_out_data[15] = (0x82); //Turn off Woodblock 1

midi_out_data[16] = (0x3C);

midi_out_data[17] = (0x3F);

midi_out_data[18] = (0x92); //Turn on Woodblock 2

midi_out_data[19] = (0x3C);

midi_out_data[20] = (0x3F);

midi_out_data[21] = (0x85); //Turn off Synth Drum 3

midi_out_data[22] = (0x3C);

midi_out_data[23] = (0x3F);

midi_out_data[24] = (0x95); //Turn on Synth Drum 1

midi_out_data[25] = (0x3C);

midi_out_data[26] = (0x3F);

midi_out_data[27] = (0x82); //Turn off Woodblock 2

midi_out_data[28] = (0x3C);

midi_out_data[29] = (0x3F);

midi_out_data[30] = (0x92); //Turn on Woodblock 3

midi_out_data[31] = (0x3C);

midi_out_data[32] = (0x3F);

midi_out_data[33] = (0x81); //Turn off Taiko Drum 1

midi_out_data[34] = (0x48);//(0x3C);

midi_out_data[35] = (0x3F);

midi_out_data[36] = (0x91); //Turn on Taiko Drum 2

midi_out_data[37] = (0x48);//(0x3C);

midi_out_data[38] = (0x3F);

midi_out_data[39] = (0x82); //Turn off Woodblock 3

midi_out_data[40] = (0x3C);

midi_out_data[41] = (0x3F);

midi_out_data[42] = (0x92); //Turn on Woodblock 4

midi_out_data[43] = (0x3C);

midi_out_data[44] = (0x3F);

midi_out_data[45] = (0x83); //Turn off Reverse Cymbal 2

midi_out_data[46] = (0x3C);

midi_out_data[47] = (0x3F);

midi_out_data[48] = (0x93); //Turn on Reverse Cymbal 1

midi_out_data[49] = (0x3C);

midi_out_data[50] = (0x3F);

midi_out_data[51] = (0x82); //Turn off Woodblock 4

midi_out_data[52] = (0x3C);

midi_out_data[53] = (0x3F);

midi_out_data[54] = (0x92); //Turn on Woodblock 5

midi_out_data[55] = (0x3C);

midi_out_data[56] = (0x3F);

midi_out_data[57] = (0x85); //Turn off Synth Drum 1

midi_out_data[58] = (0x3C);

midi_out_data[59] = (0x3F);

midi_out_data[60] = (0x95); //Turn on Synth Drum 2

midi_out_data[61] = (0x3C);

midi_out_data[62] = (0x3F);

midi_out_data[63] = (0x82); //Turn off Woodblock 5

midi_out_data[64] = (0x3C);

midi_out_data[65] = (0x3F);

midi_out_data[66] = (0x92); //Turn on Woodblock 6

midi_out_data[67] = (0x3C);

midi_out_data[68] = (0x3F);

midi_out_data[69] = (0x81); //Turn off Taiko Drum 2

midi_out_data[70] = (0x48);//(0x3C);

midi_out_data[71] = (0x3F);

midi_out_data[72] = (0x91); //Turn on Taiko Drum 3

midi_out_data[73] = (0x48);//(0x3C);

midi_out_data[74] = (0x3F);

midi_out_data[75] = (0x84); //Turn off Seashore 1

midi_out_data[76] = (0x3C);

midi_out_data[77] = (0x3F);

midi_out_data[78] = (0x94); //Turn on Seashore 2

midi_out_data[79] = (0x3C);

midi_out_data[80] = (0x3F);

midi_out_data[81] = (0x82); //Turn off Woodblock 6

midi_out_data[82] = (0x3C);

midi_out_data[83] = (0x3F);

midi_out_data[84] = (0x92); //Turn on Woodblock 7

midi_out_data[85] = (0x3C);

midi_out_data[86] = (0x3F);

midi_out_data[87] = (0x82); //Turn off Woodblock 7

midi_out_data[88] = (0x3C);

midi_out_data[89] = (0x3F);

midi_out_data[90] = (0x92); //Turn on Woodblock 8

midi_out_data[91] = (0x3C);

midi_out_data[92] = (0x3F);

midi_out_data[93] = (0x82); //Turn off Woodblock 8

midi_out_data[94] = (0x3C);

midi_out_data[95] = (0x3F);

midi_out_data[96] = (0x92); //Turn on Woodblock 9

midi_out_data[97] = (0x3C);

midi_out_data[98] = (0x3F);

midi_out_data[99] = (0x81); //Turn off Taiko Drum 3

midi_out_data[100] = (0x48);//(0x3C);

midi_out_data[101] = (0x3F);

midi_out_data[102] = (0x91); //Turn on Taiko Drum 4

midi_out_data[103] = (0x48);//(0x3C);

midi_out_data[104] = (0x3F);

midi_out_data[105] = (0x82); //Turn off Woodblock 9

midi_out_data[106] = (0x3C);

midi_out_data[107] = (0x3F);

midi_out_data[108] = (0x92); //Turn on Woodblock 10

midi_out_data[109] = (0x3C);

midi_out_data[110] = (0x3F);

midi_out_data[111] = (0x83); //Turn off Reverse Cymbal 1

midi_out_data[112] = (0x3C);

midi_out_data[113] = (0x3F);

midi_out_data[114] = (0x93); //Turn on Reverse Cymbal 2

midi_out_data[115] = (0x3C);

midi_out_data[116] = (0x3F);

midi_out_data[117] = (0x82); //Turn off Woodblock 10

midi_out_data[118] = (0x3C);

midi_out_data[119] = (0x3F);

midi_out_data[120] = (0x92); //Turn on Woodblock 11

midi_out_data[121] = (0x3C);

midi_out_data[122] = (0x3F);

midi_out_data[123] = (0x85); //Turn off Synth Drum 2

midi_out_data[124] = (0x3C);

midi_out_data[125] = (0x3F);

midi_out_data[126] = (0x95); //Turn on Synth Drum 3

midi_out_data[127] = (0x3C);

midi_out_data[128] = (0x3F);

midi_out_data[129] = (0x82); //Turn off Woodblock 11

midi_out_data[130] = (0x3C);

midi_out_data[131] = (0x3F);

midi_out_data[132] = (0x92); //Turn on Woodblock 12

midi_out_data[133] = (0x3C);

midi_out_data[134] = (0x3F);

midi_out_data[135] = (0x81); //Turn off Taiko Drum 4

midi_out_data[136] = (0x48);//(0x3C);

midi_out_data[137] = (0x3F);

}

void Set_Jim_Midi_Out(void)

{

unsigned int i;

for (i = 0; i < RHYTHM_BUFFER_SIZE; i++)

{

midi_out_rhythm[i] = 0;

}

putchar(0xC0); //change instr to rock organ

putchar(0x12);

putchar(0xC1); //Channel 1 gets Woodblock

putchar(0x73);

putchar(0xC2); //Channel 2 gets Melodic Tom

putchar(0x75);

putchar(0xC3); //Channel 3 gets Taiko Drum

putchar(0x74);

midi_out_rhythm[0] = 1;

midi_out_rhythm[31] = 1;

midi_out_rhythm[8] = 1;

midi_out_rhythm[55] = 1;

midi_out_rhythm[16] = 1;

midi_out_rhythm[47] = 1;

midi_out_rhythm[32] = 1;

midi_out_rhythm[35] = 1;

midi_out_rhythm[36] = 1;

midi_out_rhythm[63] = 1;

midi_out_rhythm[48] = 1;

midi_out_rhythm[79] = 1;

midi_out_rhythm[56] = 1;

midi_out_rhythm[103] = 1;

midi_out_rhythm[64] = 1;

midi_out_rhythm[95] = 1;

midi_out_rhythm[80] = 1;

midi_out_rhythm[111] = 1;

midi_out_rhythm[96] = 1;

midi_out_rhythm[99] = 1;

midi_out_rhythm[100] = 1;

midi_out_rhythm[127] = 1;

midi_out_rhythm[104] = 1;

midi_out_rhythm[7] = 1;

midi_out_rhythm[112] = 1;

midi_out_rhythm[15] = 1;

midi_out_data[0] = (0x92); //Turn on Melodic Tom 1

midi_out_data[1] = (0x18);

midi_out_data[2] = (0x5F);

midi_out_data[3] = (0x82); //Turn off Melodic Tom 1

midi_out_data[4] = (0x18);

midi_out_data[5] = (0x5F);

midi_out_data[6] = (0x93); //Turn on Melodic Tom 2

midi_out_data[7] = (0x6C);

midi_out_data[8] = (0x3F);

midi_out_data[9] = (0x81); //Turn off Woodblock 4

midi_out_data[10] = (0x6C);

midi_out_data[11] = (0x7F);

midi_out_data[12] = (0x91); //Turn on Woodblock 1

midi_out_data[13] = (0x6C);

midi_out_data[14] = (0x7F);

midi_out_data[15] = (0x83); //Turn off Melodic Tom 2

midi_out_data[16] = (0x6C);

midi_out_data[17] = (0x3F);

midi_out_data[18] = (0x92); //Turn on Melodic Tom 3

midi_out_data[19] = (0x18);

midi_out_data[20] = (0x5F);

midi_out_data[21] = (0x82); //Turn off Melodic Tom 3

midi_out_data[22] = (0x18);

midi_out_data[23] = (0x5F);

midi_out_data[24] = (0x92); //Turn on Melodic Tom 4

midi_out_data[25] = (0x18);

midi_out_data[26] = (0x5F);

midi_out_data[27] = (0x81); //Turn off Woodblock 1

midi_out_data[28] = (0x6C);

midi_out_data[29] = (0x7F);

midi_out_data[30] = (0x91); //Turn on Woodblock 2

midi_out_data[31] = (0x6C);

midi_out_data[32] = (0x7F);

midi_out_data[33] = (0x82); //Turn off Melodic Tom 4

midi_out_data[34] = (0x18);

midi_out_data[35] = (0x5F);

midi_out_data[36] = (0x93); //Turn on Melodic Tom 5

midi_out_data[37] = (0x6C);

midi_out_data[38] = (0x3F);

midi_out_data[39] = (0x83); //Turn off Melodic Tom 5

midi_out_data[40] = (0x6C);

midi_out_data[41] = (0x3F);

midi_out_data[42] = (0x92); //Turn on Melodic Tom 6

midi_out_data[43] = (0x18);

midi_out_data[44] = (0x5F);

midi_out_data[45] = (0x81); //Turn off Woodblock 2

midi_out_data[46] = (0x6C);

midi_out_data[47] = (0x7F);

midi_out_data[48] = (0x91); //Turn on Woodblock 3

midi_out_data[49] = (0x6C);

midi_out_data[50] = (0x7F);

midi_out_data[51] = (0x82); //Turn off Melodic Tom 6

midi_out_data[52] = (0x18);

midi_out_data[53] = (0x5F);

midi_out_data[54] = (0x92); //Turn on Melodic Tom 7

midi_out_data[55] = (0x18);

midi_out_data[56] = (0x5F);

midi_out_data[57] = (0x82); //Turn off Melodic Tom 7

midi_out_data[58] = (0x18);

midi_out_data[59] = (0x5F);

midi_out_data[60] = (0x92); //Turn on Melodic Tom 8

midi_out_data[61] = (0x18);

midi_out_data[62] = (0x5F);

midi_out_data[63] = (0x82); //Turn off Melodic Tom 8

midi_out_data[64] = (0x18);

midi_out_data[65] = (0x5F);

midi_out_data[66] = (0x93); //Turn on Melodic Tom 9

midi_out_data[67] = (0x6C);

midi_out_data[68] = (0x3F);

midi_out_data[69] = (0x91); //Turn on Woodblock 4

midi_out_data[70] = (0x6C);

midi_out_data[71] = (0x7F);

midi_out_data[72] = (0x83); //Turn off Melodic Tom 9

midi_out_data[73] = (0x6C);

midi_out_data[74] = (0x3F);

}

void draw_menu(void)

{

//col_sel(3);

//clear_col();

col_sel(1);

//spi(0x7B); //Turn off all notes

//spi(0x00);

//offense = 1;

switch (menu_num)

{

case 0://game screen

if (pos < 2)

pos = 2;

if (pos > 3)

pos = 3;

playing = 1;

if (current_player == 0 && offense == 1)

{

println(player1_offense, 0, 1);

//int_out(player1_failures, 1, 1);

switch (player1_failures)

{

case 0: println(blank, 1, 0); break;

case 1: println(v, 1, 0); break;

case 2: println(ve, 1, 0); break;

case 3: println(vei, 1, 0); break;

case 4: println(veir, 1, 0); break;

}

}

else if (current_player == 0 && offense == 0)

{

println(player1_defense, 0, 1);

//int_out(player1_failures, 1, 1);

switch (player1_failures)

{

case 0: println(blank, 1, 0); break;

case 1: println(v, 1, 0); break;

case 2: println(ve, 1, 0); break;

case 3: println(vei, 1, 0); break;

case 4: println(veir, 1, 0); break;

}

}

else if (current_player == 1 && offense == 1)

{

println(player1_defense, 0, 0);

//int_out(player1_failures, 1, 0);

switch (player1_failures)

{

case 0: println(blank, 1, 0); break;

case 1: println(v, 1, 0); break;

case 2: println(ve, 1, 0); break;

case 3: println(vei, 1, 0); break;

case 4: println(veir, 1, 0); break;

}

}

else

{

println(player1_offense, 0, 0);

//int_out(player1_failures, 1, 0);

switch (player1_failures)

{

case 0: println(blank, 1, 0); break;

case 1: println(v, 1, 0); break;

case 2: println(ve, 1, 0); break;

case 3: println(vei, 1, 0); break;

case 4: println(veir, 1, 0); break;

}

}

println(blank, 2, 0);

if (current_player == 1 && offense == 1)

{

println(player2_offense, 3, 1);

//int_out(player2_failures, 4, 1);

switch (player2_failures)

{

case 0: println(blank, 4, 0); break;

case 1: println(v, 4, 0); break;

case 2: println(ve, 4, 0); break;

case 3: println(vei, 4, 0); break;

case 4: println(veir, 4, 0); break;

}

}

else if (current_player == 1 && offense == 0)

{

println(player2_defense, 3, 1);

//int_out(player2_failures, 4, 1);

switch (player2_failures)

{

case 0: println(blank, 4, 0); break;

case 1: println(v, 4, 0); break;

case 2: println(ve, 4, 0); break;

case 3: println(vei, 4, 0); break;

case 4: println(veir, 4, 0); break;

}

}

else if (current_player == 0 && offense == 1)

{

println(player2_defense, 3, 0);

//int_out(player2_failures, 4, 0);

switch (player2_failures)

{

case 0: println(blank, 4, 0); break;

case 1: println(v, 4, 0); break;

case 2: println(ve, 4, 0); break;

case 3: println(vei, 4, 0); break;

case 4: println(veir, 4, 0); break;

}

}

else

{

println(player2_offense, 3, 0);

//int_out(player2_failures, 4, 0);

switch (player2_failures)

{

case 0: println(blank, 4, 0); break;

case 1: println(v, 4, 0); break;

case 2: println(ve, 4, 0); break;

case 3: println(vei, 4, 0); break;

case 4: println(veir, 4, 0); break;

}

}

println(blank, 5, 0);

println(blank, 6, 0);

println(blank, 7, 0);

// println(tempo_str, 6, 0);

// int_out(tempo, 7, 1);

break;

case 1://main menu

playing = 0;

println(main_menu, 0, 0);

println(line, 1, 0);

if (pos == 2)

{

println(start_game, 2, 1);

}

else

{

println(start_game, 2, 0);

}

if (pos == 3)

{

println(options, 3, 1);

}

else

{

println(options, 3, 0);

}

println(empty, 4, 0);

println(empty, 5, 0);

println(empty, 6, 0);

println(empty, 7, 0);

break;

case 2://options

playing = 0;

println(options, 0, 0);

println(line, 1, 0);

if (pos == 2)

{

println(game_setup, 2, 1);

}

else

{

println(game_setup, 2, 0);

}

if (pos == 3) {

switch (personality)

{

case 0:println(jim, 3, 1);

RHYTHM_SIZE = 128;

tempo = 65;

Set_Jim_Midi_Out();

break;

case 1:println(reba, 3, 1);

RHYTHM_SIZE = 128;

tempo = 35;

Set_Reba_Midi_Out();

break;

case 2:println(gus, 3, 1);

RHYTHM_SIZE = 108;

tempo = 125;

Set_Gus_Midi_Out();

break;

}

}

else

{

switch (personality)

{

case 0:println(jim, 3, 0); break;

case 1:println(reba, 3, 0); break;

case 2:println(gus, 3, 0); break;

}

}

if (pos == 4)

{

if (PORTB.3)

{

println(backlight_on, 4, 1);

}

else

{

println(backlight_off, 4, 1);

}

}

else

{

if (PORTB.3)

{

println(backlight_on, 4, 0);

}

else

{

println(backlight_off, 4, 0);

}

}

if (pos == 5)

{

println(back, 5, 1);

}

else

{

println(back, 5, 0);

}

println(empty, 6, 0);

println(empty, 7, 0);

break;

case 3://game setup

playing = 0;

println(game_setup, 0, 0);

println(line, 1, 0);

if (pos == 2)

{

if (game_mode)

{

println(mode_sequence, 2, 1);

}

else

{

println(mode_horse, 2, 1);

}

}

else

{

if (game_mode)

{

println(mode_sequence, 2, 0);

}

else

{

println(mode_horse, 2, 0);

}

}

if (pos == 3)

{

switch (num_players)

{

case 2:println(two_players, 3, 1); break;

case 3:println(three_players, 3, 1); break;

case 4:println(four_players, 3, 1); break;

case 5:println(five_players, 3, 1); break;

case 6:println(six_players, 3, 1); break;

}

}

else

{

switch (num_players)

{

case 2:println(two_players, 3, 0); break;

case 3:println(three_players, 3, 0); break;

case 4:println(four_players, 3, 0); break;

case 5:println(five_players, 3, 0); break;

case 6:println(six_players, 3, 0); break;

}

}

if (pos == 4)

{

if (!game_mode)

{

switch (num_challenges)

{

case 0:println(zero_challenges, 4, 1); break;

case 1:println(one_challenge, 4, 1); break;

case 2:println(two_challenges, 4, 1); break;

case 3:println(three_challenges, 4, 1); break;

case 4:println(four_challenges, 4, 1); break;

case 5:println(five_challenges, 4, 1); break;

}

}

else

{

println(blank, 4, 1);

}

}

else

{

if (!game_mode)

{

switch (num_challenges)

{

case 0:println(zero_challenges, 4, 0); break;

case 1:println(one_challenge, 4, 0); break;

case 2:println(two_challenges, 4, 0); break;

case 3:println(three_challenges, 4, 0); break;

case 4:println(four_challenges, 4, 0); break;

case 5:println(five_challenges, 4, 0); break;

}

}

else

{

println(blank, 4, 0);

}

}

if (pos == 5)

{

println(start_game, 5, 1);

}

else

{

println(start_game, 5, 0);

}

if (pos == 6)

{

println(back, 6, 1);

}

else

{

println(back, 6, 0);

}

println(empty, 7, 0);

break;

case 4://challenge

clear_screen();

println(challenge, 0, 0);

break;

case 5: //sequence...

break;

default: playing = 0;

clear_screen();

menu_num = 1;

pos = 2;

draw_menu();

return;

break;

}

}

void move_down(void)

{

if (change_personality)

{

if (personality > 0)

{

personality--;

draw_menu();

}

return;

}

if (change_players)

{

if (num_players > 2)

{

num_players --;

draw_menu();

}

return;

}

if (change_challenge)

{

if (num_challenges > 0)

{

num_challenges--;

draw_menu();

}

return;

}

switch (menu_num)

{

case 0://game screen

if ((tempo = 25))

{

tempo-=5;

}

else

{

tempo = 20;

}

draw_menu();

break;

case 1://main menu

if (pos < 3)

{

pos ++;

}

draw_menu();

break;

case 2://options

if (pos < 5)

{

pos ++;

}

draw_menu();

break;

case 3://game setup

if (pos < 6)

{

pos ++;

}

draw_menu();

break;

case 4://challenge

break;

default: pos = 2;

draw_menu();

break;

}

}

void move_up(void)

{

if (change_personality)

{

if (personality < 2)

{

personality++;

draw_menu();

}

return;

}

if (change_players)

{

if (num_players < 6)

{

num_players ++;

draw_menu();

}

return;

}

if (change_challenge)

{

if (num_challenges < 5)

{

num_challenges++;

draw_menu();

}

return;

}

switch (menu_num)

{

case 0://game screen

if ((tempo >= 20) && (tempo 2)

{

pos --;

}

draw_menu();

break;

case 2://options

if (pos > 2)

{

pos --;

}

draw_menu();

break;

case 3://game setup

if (pos > 2)

{

pos --;

}

draw_menu();

break;

case 4://challenge

break;

default: pos = 2;

draw_menu();

break;

}

}

void irq_handle(void)

{

if ((!D2) && (!D3))

{

if ((!PIND.2) && (!PIND.3))

{

//no change

return;

}

else if ((!PIND.2) && (PIND.3))

{

//CW

//println(CW, 6);

move_down();

}

else if ((PIND.2) && (!PIND.3))

{

//CCW

//println(CCW, 6);

move_up();

}

else if ((PIND.2) && (PIND.3))

{

//error

return;

}

}

else if ((!D2) && (D3))

{

if ((!PIND.2) && (!PIND.3))

{

//CCW

//println(CCW, 6);

move_up();

}

else if ((!PIND.2) && (PIND.3))

{

//no change

return;

}

else if ((PIND.2) && (!PIND.3))

{

//error

return;

}

else if ((PIND.2) && (PIND.3))

{

//CW

//println(CW, 6);

move_down();

}

}

else if ((D2) && (!D3))

{

if ((!PIND.2) && (!PIND.3))

{

//CW

//println(CW, 6);

move_down();

}

else if ((!PIND.2) && (PIND.3))

{

//error

return;

}

else if ((PIND.2) && (!PIND.3))

{

//no change

return;

}

else if ((PIND.2) && (PIND.3))

{

//CCW

//println(CCW, 6);

move_up();

}

}

else if ((D2) && (D3))

{

if ((!PIND.2) && (!PIND.3))

{

//error

return;

}

else if ((!PIND.2) && (PIND.3))

{

//CCW

//println(CCW, 6);

move_up();

}

else if ((PIND.2) && (!PIND.3))

{

//CW

//println(CW, 6);

move_down();

}

else if ((PIND.2) && (PIND.3))

{

//no change

return;

}

}

else

{

//error!

return;

}

D2 = PIND.2;

D3 = PIND.3;

}

// Declare your global variables here

void main(void)

{

// Declare your local variables here

int i, j;

// Input/Output Ports initialization

// Port A initialization

// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out Func7=Out

// State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0 State7=0

PORTA=0x00;

DDRA=0xFF;

// Port B initialization

// Func0=In Func1=In Func2=In Func3=In Func4=Out Func5=Out Func6=In Func7=Out

// State0=T State1=T State2=T State3=T State4=0 State5=0 State6=T State7=0

PORTB=0x00;

DDRB=0xB0;

// Port C initialization

// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out Func7=Out

// State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0 State7=0

PORTC=0x00;

DDRC=0xFF;

// Port D initialization

// Func0=In Func1=Out Func2=In Func3=In Func4=In Func5=In Func6=In Func7=In

// State0=T State1=0 State2=T State3=T State4=T State5=T State6=T State7=T

PORTD=0x00;

DDRD=0x02;

// Timer/Counter 0 initialization

// Clock source: System Clock

// Clock value: Timer 0 Stopped

// Mode: Normal top=FFh

// OC0 output: Disconnected

TCCR0=0x00;

TCNT0=0x00;

OCR0=0x00;

// Timer/Counter 1 initialization

// Clock source: System Clock

// Clock value: 7.813 kHz

// Mode: Normal top=FFFFh

// OC1A output: Discon.

// OC1B output: Discon.

// Noise Canceler: Off

// Input Capture on Falling Edge

TCCR1A=0x00;

TCCR1B=0x05;

TCNT1H=0x00;

TCNT1L=0x00;

OCR1AH=0x00;

OCR1AL=0x00;

OCR1BH=0x00;

OCR1BL=0x00;

// Timer/Counter 2 initialization

// Clock source: System Clock

// Clock value: Timer 2 Stopped

// Mode: Normal top=FFh

// OC2 output: Disconnected

ASSR=0x00;

TCCR2=0x00;

TCNT2=0x00;

OCR2=0x00;

// External Interrupt(s) initialization

// INT0: On

// INT0 Mode: Any change

// INT1: On

// INT1 Mode: Any change

// INT2: On

// INT2 Mode: Falling Edge

GICR|=0xE0;

MCUCR=0x05;

MCUCSR=0x00;

GIFR=0xE0;

// Timer(s)/Counter(s) Interrupt(s) initialization

TIMSK=0x00;

// USART initialization

// Communication Parameters: 8 Data, 1 Stop, No Parity

// USART Receiver: On

// USART Transmitter: On

// USART Mode: Asynchronous

// USART Baud rate: 31250

UCSRA=0x00;

UCSRB=0x98;

UCSRC=0x86;

UBRRH=0x00;

UBRRL=0x0F;

// Analog Comparator initialization

// Analog Comparator: Off

// Analog Comparator Input Capture by Timer/Counter 1: Off

// Analog Comparator Output: Off

ACSR=0x80;

SFIOR=0x00;

// SPI initialization

// SPI Type: Master

// SPI Clock Rate: 500.000 kHz

// SPI Clock Phase: Cycle Half

// SPI Clock Polarity: Low

// SPI Data Order: LSB First

SPCR=0x53;

SPSR=0x00;

// Global enable interrupts

#asm("sei")

D2 = PIND.2;

D3 = PIND.3;

rx_counter = 0;

rx_rd_index = 0;

rx_wr_index = 0;

// Send 1 powerup to get into play mode and wait > 25ms

PORTB.4 = 0;

delay_us(1); // must be 500ns

spi(0x00); // LSB first

spi(0x04);

delay_us(1); // must be 500ns

PORTB.4 = 1;

delay_ms(30);

//shut the bitch up on bootup

for (i = 0x90; i ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download