• 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 Communication

• The host device acts as a slave and has address 1, all clients are I2C masters
• Initialization
  1. 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
  2. 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
  3. 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

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