Student Name: Kevin Dobson Project Supervisor: Dr Lance Fung

1. Programmable MIDI Device Student Name: Kevin Dobson Project Supervisor: Dr Lance Fung

2. Project Overview “To create a device which may interpret and modify a MIDI signal as defined my the user”

3. Project Objectives • Select and Configure device hardware • Select Microcontroller for accurate operation and optimum performance • Create Software • Both embedded code and application software

4. MIDI BACKGROUND

5. 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.

6. 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

7. 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)

8. 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

9. 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

10. 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...

11. Enter... THE PROGRAMMABLE MIDI DEVICE

12. Concept & Preliminary Design Q. So... What does this thing do anyhow? A. Anything!

13. Concept & Preliminary Design Q. So... What does this thing do anyhow? A. Anything!

14. Concept & Preliminary Design Why would you want it? • Compatibility Issues • Abstract event triggering • Real-time interactive automation • Performance Aid

15. Concept & Preliminary Design • Major Considerations • Ease of use • Diversity of use • State Machine Approach • Text / Macros • Tabular • Graphical

16. Concept & Preliminary Design

17. Concept & Preliminary Design • 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

18. Project Components • Hardware • Microcontroller Consideration • MIDI Interface Circuitry • Software • User Application Software • Embedded ‘Firmware’

19. Hardware

20. 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

21. 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

22. 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

23. Hardware Configuration

24. 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

25. Prototype

26. Software

27. 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

28. 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

29. GUI Design STATE EVENT (Transition) Triggers within event Actions within state TOOLS Pointer Draw Line Delete Edit Select Start State

30. GUI Design

31. GUI Design

32. GUI Design

33. 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

34. Embedded Code Transmit Next Byte (If Output buffer isn’t Empty) N Y Byte Recieved? Add byte to Message Buffer Call Downloaded Code Without MIDI Message N Full MIDI Message? Y Call Downloaded Code With MIDI Message

35. 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

36. User Code Generation (Performed Within Windows Application Software) Code Generation Algorithm User’s State Diagram(s) Machine Code

37. 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

38. User Code Generation An Example for STATE 1. The root code will jump to STATE1B, but any other state will jump to STATE1A. STATE1A Action1 STATE1B If Event1 goto STATE2A Action2 If Event2 goto STATE5A ... Set State to STATE1 ... Return to root code Return to root code

39. 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

41. ?