jmamma
MegaCommand peripheral bus
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.
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).
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.
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.
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.
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 😉
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).
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.
🤔🤔🤔 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?
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.
There's a custom firmware that functions as the arduino programmer only when a jumper is added to the 16u2 ISP headers
Ah, very cool.
Can the Mega/16U2 function as a USB host for attaching peripheral USB devices?
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
A USB host chip + arduino nano should do it nicely. Then we can use the bus protocol to probe its capabilities.
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.
FYI: Some of the chinese boards dont have the 16u2.
Last night I checked my arduino reps, no little square chips anywhere 🤦♂️
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.
- is there anywhere i can get some documentation how you are reading values from the MD, particularly trigger buttons and encoder values?
- 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!
Software side of the project is.
https://github.com/jmamma/MIDICtrl20_MegaCommand/
You can submit software related questions as new issues there ^.
Cheers,
- Justin.
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
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.
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.
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.