Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| 
                    projekte:usb-midi-controller [2014-12-02 00:34] root angelegt  | 
                
                    projekte:usb-midi-controller [2014-12-07 00:00] (aktuell) | 
            ||
|---|---|---|---|
| Zeile 7: | Zeile 7: | ||
| * ADC to read the controller value from a potentiometer or similar | * ADC to read the controller value from a potentiometer or similar | ||
| * Uses the USI as I2C to communicate with the master | * 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]] | * Clients are daisy-chainable, see [[projekte:usb-midi-controller#Communication]] | ||
| - | |||
| ===== Communication ===== | ===== Communication ===== | ||
| - | * The host device acts as a slave and has address 1 | + | * The host device acts as a slave and has address 1, all clients are I2C masters | 
| * Initialization | * Initialization | ||
| - When a client powers on, it repeatedly (until it receives an answer) sends a message to the host, consisting of | - When a client powers on, it repeatedly (until it receives an answer) sends a message to the host, consisting of | ||
| Zeile 19: | Zeile 20: | ||
| * The 7-bit address of the first control | * 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 | - The device then enables the next device, either by pulling its RESET line high or enabling VCC | ||
| - | * Control changes: When one control of a client has changed, it constructs the corresponding MIDI packet: B0 XX YY, where XX stands for the control number and VV the new 7-bit value of the control | + | * 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 between 100 and 1000 microseconds and tries again | + | * 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 | A preliminary command table, with each length including the command byte | ||
| - | ^ Request ^ Length ^ Response ^ Length ^ Description ^ | + | ^ Request  ^ Length  ^ Response ^ Length ^ Description ^ | 
| - | | 0x01 | 2 | 0x02 | 3 | Initialization | | + | | 0b00000000  | 2 | 0b00000001  | 3 | Initialization | | 
| - | | 0xB0 | 3 | None | 0 | Control change | | + | | 0b1xxxxxxx  | According to the MIDI spec | None | 0 | MIDI message | | 
| ===== Wiring ===== | ===== Wiring ===== | ||
| Zeile 35: | Zeile 36: | ||
| * SCL | * 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. | * 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. | ||