jmamma / MegaCommand_Design

MegaCommand MIDI Controller
Other
74 stars 11 forks source link

MegaCommand peripheral bus #6

Open yatli opened 5 years ago

yatli commented 5 years ago

I propose we standardize the extension port communication protocol.

These are the pins exposed through the two expansion ports:

image

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

🤔🤔🤔 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 commented 5 years ago

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 commented 5 years ago

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

jmamma commented 5 years ago

didnt know that!

yatli commented 5 years ago

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

jmamma commented 5 years ago

Ah, very cool.

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

yatli commented 5 years ago

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 commented 5 years ago

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

jmamma commented 5 years ago

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

Yeah that's what I thought.

yatli commented 5 years ago

FYI: Some of the chinese boards dont have the 16u2.

Last night I checked my arduino reps, no little square chips anywhere 🤦‍♂️

micabeza commented 4 years ago

not sure where to post my question, ut i figured here is better than the electron forum. I'm kinda a noob at all this coding/building, but i have a couple questions as I'm looking to attempt to use the expansion ports. 1) is there anywhere i can get some documentation how you are reading values from the MD, particularly trigger buttons and encoder values? 2) is there a place best suited to drop in code? i looked at the source code files, and for a noob, they are a bit overwhelming right now....

please let me know if theres a better place to post these questions. great work so far!

jmamma commented 4 years ago

Software side of the project is.

https://github.com/jmamma/MIDICtrl20_MegaCommand/

You can submit software related questions as new issues there ^.

Cheers,

yatli commented 4 years ago

The ATMega USART has a multiprocessor mode so that one can connect a master MCU to multiple slave MCUs on a single UART. It's like RS-485 for free :p

jmamma commented 4 years ago

EXP ports wouldn't work for this configuration though? As the UART RX on left exp port is not mirror'd on right exp port.

yatli commented 4 years ago

Will need a breakout board to connect more than two together, anyway

Also it's more than connecting two MCs. We can connect other MCU-based components -- WiFi, audio, USB host etc.

yatli commented 4 years ago

In this way the processors can be organized more efficiently than a daisy chain. Multiple slave devices (USB host, WIFI etc.) are connected to the master directly. This prevents, for example, TCP data to flow through a mouse :D

Slave devices additionally use one pin to indicate send request, and with a parallel to serial shifter, the master can get the requests and arbitrate.