Friday, July 31, 2009

MIDI7S - a flexible USB - MIDI interface

MIDI7S - a flexible USB - MIDI interface


This page is work in progress and will be updated with more precise documentation when that is available.

Update june 2013

All the images had vanished from the blog, thanks blogger, but now I have restored them.   My work with midi has mostly moved on to use Maple boards and STM4FDiscovery board. The Teensy 3 board have midi implemented as standard and uses Arduino IDE for coding and programming making things much simpler.

System Components


Processor board


The AT91SAM7S64 processor has 3 uarts that can be used as MIDI ports and a USB interface. The Olimex SAM7-P64 board also has header for most uP pins, power supply and mmc card connector. This makes it a cheap and powerful platform for a USB MIDI system.



This processor is a bit old, but it is still a nice processor and I had this board and did not use for anything else. Today I would probably use something like a Olimex STM32-P103 board or design my own board for a STM32F103 processor.

MIDI interface board

MIDI out is driven directly from the microprocessor uart tx pin. Only one 220Ohm resistor is used , there should be two according to reference implementations. When driving MIDI from a 3.3 V source 2x70 Ohm is probably the best, for a typical VF in the optocoupler of 1.5V and series resistance of 220 Ohms in the receiver this gives I=(3.3-1.5)/360 = 5mA. The short curcuit current, 47 mA is a little bit high but not exceptional. The MIDI receivers uses 6N137 optoisolators

MIDI 1 IN / OUT

MIDI 2 IN / OUT

Schematic (one channel):


Board layout (one channel)


The actual construction was built on a strip-board

DOG-ME Display board

This a 2x20 character LCD display using serial communications


Communication Interfaces

USBMIDI

The USBMIDI configuration uses two logical USB MIDI Cables connected to the physical MIDI ports
/* MIDI IN JACK 1 receives data from the USB interface Ep 1 */
/* MIDI IN JACK 2 receives data from the serial uartmidi[0] */
/* MIDI OUT JACK 3 transmits data to the USB interface Ep 82 */
/* MIDI OUT JACK 4 transmits data to the serial uartmidi[0] */
/* MIDI OUT JACK 8 transmits data to the serial uartmidi[1] */

The sending of USB MIDI data through MIDI OUT JACK 3 using USB IN endpoint Ep82 needs work for buffering and handling of many small write requests

Serial MIDI

The serial MIDI interfaces are connected to USART0 and DEBUGUSART. USART1 is connected to a RS232 level shifter an can be used for "standard" serial communications.


Dog-ME Display interface (SPI 3.3V)

PA13 MOSI
PA14 SPCK
PA30 IRQ1/NPCS2 DOG_LCD_SELECT_PIN
PA31 NPCS1/PCK2 DOG_LCD_RS_PIN

Code

The code is written in C++ using a minimal profile for small embedded systems, no dynamic object creation, no exceptions.


USB MIDI device descriptor

http://www.usb.org/developers/devclass_docs/midi10.pdf

USB MIDI device descriptors as C code, corresponding header file

Transmission buffers

All uart communications uses buffered DMA transactions

spi to the display should also use DMA but with a DLYBCT of 50 giving a character spacing of approximatly 33us, the serial:: transmission logic can be reused (subclassed) here.

The AT91SAM7 variable chipselects and chipselect decode mode together with 32 bit DMA SPI transmissions allows us to control both data bits and the RS line with automatic transfers to the Dog-Me display.

Testing

The system has been used as an USB to MIDI inteface betwen a Linux computer and a U220 synth module. The usb midi ports are autodetected and added as Alsa MIDI ports. Some USB communication gliches has been observed, but not frequent and not yet reproducible. Loopback tests with a standard MIDI cable connected from MIDI out to MIDI in works well.

Round trip times on PC running Linux, Fedora 10, PC(Alsa MIDI)->USB MIDI IN->MIDI OUT->MIDI IN->USB MIDI OUT->PC are 1.5 - 3 ms (/home/lundin/delad/arbete/mikrop/usbmidi/miditest.c) with processing times up to 130uS using single message pings (090531 r357)
Direct echo within the module , no serial MIDI, gives times of .8 to 2 ms



Future


With the basic USB and MIDI communications working, it is possible to expand the capabilities of the system.
The analog and digital inputs can be used to generate MIDI events from different sensors and there is spare processor capacity for MIDI processing.

TWI EEPROM For settings

Control panel

I/O Extender

MIDI file player

Sensor to midi event generation

4 comments:

head_up said...

nice work! :)

DangerRuss said...

Hi, great project and description!

One question: have you tried this circuit with many commercial synths, drum machines etc. to verify reliable operation at 3.3V on the MIDI out?

The MIDI spec is designed for 5V to the best of my knowledge, so for my project I had used a DC-DC step-up converter (NCP1400) to derive a systemwide supply of 5V from a 1.2V AAA battery.

3.3V is well within the logic 1 range of a 5V system though, so I can see why it might work fine.

If comms really are reliable at 3.3V on the MIDI out, I could eliminate the DC-DC converter and run my (AVR-based) design directly from a Li-ion 3.6V cell and get rid of lots of components, including the voltage dividers to derive 3.3V from 5V for the SD/MMC interface...

Magnus Lundin said...

I have tried it with a Roland U220 synth and it works with no problems.

The MIDI communications is current loop, the specs says that there should be 5ma through the receiver optocoupler. So its not directly about the voltage logic levels.

In the reference implementation there is 660 ohms series resistance in total (440 sender and 220 receiver). Using only 220 for a sender at 3.3 V gives a current of about 4mA, this is below spec but more than enough to drive the optocouplers used. The 220 at 3.3 V also gives a shortcurcuit current of 15mA, not too dangerous to the sender.

For private use I can recommend this, for a commercial product I would be very careful and do more testing.

The numbers given should be checked since I'm writing from memory.

Anonymous said...

It can be the source of the project? I can write to
gianpaolo.59@gmail.com
Thanks