====== USB-MIDI-Controller ====== * ATmega32u4 (Arduino Leonardo) as host device * Uses LUFA to send MIDI messages to the computer over the USB * Uses I2C to talk to one or more clients * Some ATtiny as client device * ADC to read the controller value from a potentiometer or similar * Uses the USI as I2C to communicate with the master * Possibly replace the ATtiny with some cheap ATmega or some other MCU with multi-master I2C, 1 at least 7-bit ADC, and a free GPIO pin to get around having to use USI :) * Update: The USI is an ungodly mess. "Here's a shift register and half a counter, have fun." I've probably poured 15 hours of work into this, but I'm definitely switching. Probably to the cheapest ATmega I can find. * Clients are daisy-chainable, see [[projekte:usb-midi-controller#Communication]] ===== Communication ===== * The host device acts as a slave and has address 1, all clients are I2C masters * Initialization - When a client powers on, it repeatedly (until it receives an answer) sends a message to the host, consisting of * A request code * The number ''nc'' of controls it needs allocated to itself - The host then allocates a continuous block of ''nc'' controls for the device and responds with * The response code corresponding to the request * The 7-bit address of the first control - The device then enables the next device, either by pulling its RESET line high or enabling VCC * MIDI messages are constructed by the clients and sent as-is. The host will buffer them until it has received the STOP, then forward them over USB. As all MIDI commands start with a set bit, this is an easy way to separate management and MIDI messages. * On collision, the device waits until a STOP condition has been detected and tries again. A preliminary command table, with each length including the command byte ^ Request ^ Length ^ Response ^ Length ^ Description ^ | 0b00000000 | 2 | 0b00000001 | 3 | Initialization | | 0b1xxxxxxx | According to the MIDI spec | None | 0 | MIDI message | ===== Wiring ===== * Common wires include * GND * SDA * SCL * Each device uses one pin to trigger a FET that connects its VCC to the VCC of the next client. Alternatively, it may connect to the RESET pin of the next client. * This uses four wires. A nice and simple method of connecting these would be to use 3.5mm TRRS connectors, like those commonly used for smartphone earphones that include a microphone. The variant where each client controls the next client's RESET pin could use 5-pin (mini-) DIN connectors.