Student Name: Kevin DobsonProject Supervisor: Dr Lance Fung
Project Overview
“To create a device which may interpret and
modify a MIDI signal as defined my the user”
Project Objectives
• Select and Configure device hardware– Select Microcontroller for accurate operation
and optimum performance• Create Software
– Both embedded code and application software
MIDI Background Information
• The Musical Instrument Digital Interface (MIDI) is a standard allowing musical synthesizers and other electronic devices, of different makes and models, to communicate and control each other via a unidirectional link.
• For Example: A computer, or musical keyboard may control the notes played on a separate synthesizer.
MIDI History
• During the 70s the analogue synthesizer evolved from the electric organ and became popular by the end of the decade
• During this time, analogue ‘control voltages’ were used for interconnectivity. Crude and Monophonic.
• In 1982 UMI (Universal Musical Interface) was proposed• By 1983 it had been renamed to MIDI (Musical Instrument
Digital Interface)• Major contributors to the development of the standard
were Roland (Japan) and Sequential Circuits (USA)source: http://www.mtsu.edu/~dsmitche/rim419/midi/HTMLs/MIDHIS~1.HTM
The MIDI Specification
• Hardware Specification– Asynchronous Serial Interface – Current Loop (current on = logic 0)
• Optical isolation & no common ground– 31.25 Kbps (320us per byte)
The MIDI Specification
• Midi Messages (in general)– Each message can contain from 1 to 3 bytes– The first byte is always a status byte which
specifies the TYPE (and channel) of the message. This byte always has the MSB set (i.e from 0x80 - 0xFF)
– The following data bytes (if needed) contain information specific to the message type defined by the status byte
The MIDI Specification
Some Status Bytes:0x80 - 0x8F : Note Off0x90 - 0x9F : Note On0xA0 - 0xAF : Aftertouch0xB0 - 0xBF : Program Change
- where the lower nibble is the channel number
The MIDI Specification
Example:The Note On status byte is followed by two data bytes which specify the note number and velocity (defined in the specification)The following byte stream will play note C6 (0x3C) at a velocity (volume) of 100 (0x64).
0x92, 0x3C, 0x64
Now, onto the convoluted contraption...
Enter...
Concept & Preliminary DesignQ. So... What does this thing do anyhow?
A. Anything!
Concept & Preliminary DesignQ. So... What does this thing do anyhow?
A. Anything!
Keyboard Programmable
MIDI Device
MIDI OUT
PC
MIDI OUT MIDI IN MIDI IN
Concept & Preliminary Design
Why would you want it?
• Compatibility Issues• Abstract event triggering• Real-time interactive automation• Performance Aid
Concept & Preliminary Design
• Major Considerations– Ease of use– Diversity of use
• State Machine Approach– Text / Macros– Tabular– Graphical
Concept & Preliminary Design
No Action
No Action No Action
Key 1
Key 2
Key 3
START
Other Key
Other Key
Key 4
Key 5 Key 6
Action 1 -------------- Action 2
Reset Key
Action 3 Action 4 -------------- Action 5
• Device Programming Method– Download
• Separate Serial/Parallel PC interface• Sysex Data Stream (through MIDI)
– Code Generation• Configuration data interpreted by Embedded Code• Generation of instruction words of code
Concept & Preliminary Design
Project Components
• Hardware– Microcontroller Consideration– MIDI Interface Circuitry
• Software– User Application Software– Embedded ‘Firmware’
Hardware Consideration
• Microcontroller Required:– Nonvolatile Memory– Sufficient Speed & Ram– Asynchronous serial input and output
• 31.25Kbps• 1 start bit, 1 stop bit, 8 bit data byte
Hardware Consideration
• Microcontroller Chosen:– Microchip PIC16F876
• 8-bit RISC Structure (14 bit instruction word)• Onboard Flash Memory (8K 14-bit words)• 368 bytes of RAM• USART Serial Communication• 20MHz Maximum Operating Frequency
– Allowing a 5MHz CPU clock
• 13 Interrupts
Hardware Consideration
• Configuration:– 16Mhz Operating Frequency
• 4MHz CPU Clock– UART @ 31.25 Kbps
• 1 start/stop bits, 8 data bits, no interrupts enabled– Flash Memory Runtime Write Enable
Hardware Configuration
Hardware Issues
• Supply voltage must be regulated to approximately 5V at varying current draw– In this case, a 5V regulator IC was used
• Opto-isolator and hex inverter must be capable of operation @ 31.25KHz
• With CPU Clock @ 4MHz, 1280 cycles are available between bytes
Prototype
Software Production
• Software Production Phases– Begin Windows Application Software (C++)
• Basic User Interface. I.e. Menus, MDI Child Windows, Toolbars
• Drawing/Dropping routines– Create Embedded Firmware (PIC16 ASM)– Finish Windows Application Software
• Create Code Generation Routines• Tidy up File Saving/Loading
Application Software
• Written wholly in ANSI C++• Using MinGW (Minimalist GNU for
Windows)– collection of headers, libraries and compilers
for Win32 Application creation– placed in the public domain & GNU licensed
• DJGPP’s RHIDE used as editor
GUI DesignSTATE EVENT
(Transition)
TOOLS
Pointer Draw Line Delete Edit Select Start State
Actions within state
Triggers within event
GUI Design
GUI Design
GUI Design
Embedded Code
• Written wholly in PIC16 ASM• Using MPBLab IDE• DJGPP’s RHIDE used as editor
• Responsibilities– Receiving and organising MIDI bytes into messages– Calling Downloaded Code– Transmitting MIDI Output (from Output Buffer)– Allowing Downloading and Writing of State-Machine
Code to Flash Memory
Full MIDI Message?
Add byte to Message Buffer
Embedded Code
Call Downloaded Code With MIDI Message
Byte Recieved?
Transmit Next Byte (If Output buffer isn’t Empty)
Call Downloaded Code Without MIDI Message
Y
Y
N
N
Embedded Code Stats
• ROM– 493 Word Program (1st Page)– 2K Words Available for Download (2nd Page)
• RAM– Message Buffer - 4 bytes (1st Bank)– Output Buffer - 94 bytes (FIFO, 2nd Bank)
• Start Pointer, End Pointer & End Location– 3rd Bank dedicated for Downloaded Code Ram
User Code Generation
CodeGenerationAlgorithm
User’s State Diagram(s)
Machine Code
(Performed Within Windows Application Software)
User Code Generation
• Each state diagram has a variable which defines the current state
• Every time the downloaded code is called it cycles through each of the state diagrams– For each diagram it jumps to the correct
location in memory for the current state• Each state location checks inputs to see if a change
in state is necessary
User Code Generation
Action1
Action2
...
Set State to STATE1
Return to root code
STATE1A If Event1 goto STATE2A
...
Return to root code
STATE1B
If Event2 goto STATE5A
An Example for STATE 1. The root code will jump to STATE1B, but any other state will jump to STATE1A.
Resources Used
• MIDI Technical Fanatic’s Brainwashing Center
• MinGW, MPBLab & DJGPP Resources• The Forger’s Win32 API Tutorial• Microchip product documentation• MIDI Manufacturers Assoc. Homepage• Programming and Customising PICmicro
Microcontrollers– Myke Predko