Student Name: Kevin Dobson

Project 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 Off

0x90 - 0x9F : Note On

0xA0 - 0xAF : Aftertouch

0xB0 - 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 Design

Q. So... What does this thing do anyhow?

A. Anything!

Concept & Preliminary Design

Q. 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 Design

STATE 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