Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
projekte:usb-midi-controller [2014-12-02 00:55] root [Wiring] |
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, all clients are I2C masters | * The host device acts as a slave and has address 1, all clients are I2C masters | ||
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. | + | * 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. |