MegaCommand peripheral bus

[yatli]

I propose we standardize the extension port communication protocol.

These are the pins exposed through the two expansion ports:

• Power
• Two serial ports (UART0, UART3)
• SPI MOSI
• I2c, or SOFT-SPI (can be MISO)
• GPIO

The two serial ports can enable a daisy chain configuration, and multiple expansion parts can be mix-and-matched.

UART0 is configured as the master, and keeps sending out active sensing commands at intervals.
UART3 is configured as the slave. When active sensing command is received, it reports back the presence.

The hardware SPI doesn't expose MISO and is not suitable as a bus. The I2c is only present on one side of the board, and harder to program. So they are better treated as private expansion ports only visible to the current host.

[jmamma]

Yeah, I think this sums up what I was aiming for.

For a "light weight" + low power expansion board without it's own CPU/, you can use one of the digital pins to supply, 5V power @ 40mA (MAX).

[yatli]

There should be a mechanism for identifying a MCU-less expansion.
Some kind of ADC or digital level encoding would do.

And then we can number our expansion parts, e.g. TRIGGERS-1, KEYBOARD-2, OPTICSFADER-3 etc.

[jmamma]

Yeah I had that Idea as well. Some binary sequence that could be read back. The CLK, SHIFT, LATCH was supposed to facilitate this in addition to reading additional switch input.

[yatli]

A host with MCU, during presence reporting, should also reveal the private resources that it is willing to expose.

For example, if we build a sampler module with additional pads, it can decide whether to show/hide the resource to the master.

Then, a chain-of-responsibility model can be applied so we decide who takes that resource by their priorities.

[jmamma]

Then, a chain-of-responsibility model can be applied so we decide who takes that resource by their priorities.

How many MCs are you planning to link together 😉

[yatli]

That's probably overengineering at the moment. XD

But I do have some ideas. One for MNM and OT, and another for Reason Remote (the Reason sequencer is just not as good).

[yatli]

If we re-program the 16u2 on the arduino board, we can make a USB-MIDI interface, or USB-MIDI host. As 16u2 is connected to UART0, it can only be the rightmost MC in the chain.

[yatli]

🤔🤔🤔 getting a bit curious what'll happen if I hook up a USB keyboard.
plenty of keys, at least.
vim key-bindings for step editing?

[jmamma]

Yes thought about makingn it class compliant.
FYI: Some of the chinese boards dont have the 16u2.

Also if the 16u2 is re-programmed then it cant be used to upload firmwares anymore.
So you'd probably want to write a new bootloader that uploads firmware via MIDI, like the Minicommand.

[yatli]

There's a custom firmware that functions as the arduino programmer only when a jumper is added to the 16u2 ISP headers

[jmamma]

didnt know that!

[yatli]

This one: https://github.com/kuwatay/mocolufa

[jmamma]

Ah, very cool.

Can the Mega/16U2 function as a USB host for attaching peripheral USB devices?

[yatli]

Can the Mega/16U2 function as a USB host for attaching peripheral USB devices?

I was really hoping for that, but after some searching it seems 16u2 is a usb device, not host

[yatli]

A USB host chip + arduino nano should do it nicely. Then we can use the bus protocol to probe its capabilities.