jmamma / megacommand_design Goto Github PK

MegaCommand MIDI Controller

License: Other

C++ 100.00%

megacommand_design's Introduction

MegaCommand

Description:

The MegaCommand is an open-source MIDI controller that runs the MCL firmware for use with the Elektron Machinedrum. It is is based around the Arduino Mega 2560.

The printed cicuit board is a through-hole design (no SMD soldering skills required).

4 x MIDI ports (2 in, 2 out)
4 x Rotary Encoders + Push button
4 x Buttons
1 x OLED display
SD Card
128KBytes of SRAM (0-63KB accessible natively, 64-128KB accessible with bank selection)
2 x 10pin Expansion ports

Stack is 8KB in size. 56KB of SRAM reserved for global objects, variables. (bank switchable)

The MCL respository contains the software component of this project. https://github.com/jmamma/MCL

Project Status:

Board revision: 1_0_2a12

ALL INFORMATION BELOW IS PROVIDED AS A CONVENIENCE AND COULD BE SUBJECT TO ERROR OR CHANGE.

Bill of Materials:

1.0.2a: https://github.com/jmamma/MegaCommand_Design/blob/master/1_0_2/bill_of_materials

Display

OLED 128x32, it uses the SPI bus.

Important: OLED display requires resistor position changes to enable SPI mode as per adafruit documentation https://learn.adafruit.com/2-3-monochrome-128x32-oled-display-module/assembly-1):

PCB Fabrication:

You can easily get your own PCBs made.

PCBWay.com fabrication options

Gerber files (pcb layout diagrams used for fabrication) are included in the ./gerber/ directory above.

Download gerbers and submit to PCB manufacturer.

Circuit Schematic and Board Layout is present in Eagle files.

Enclosure:

1.0.2a:

The enclosure can be 3D printed. The design files and variations are located in:

https://github.com/jmamma/MegaCommand_Design/tree/master/Enclosure/OLED/3D

Optionally print 4 spacers and superglue to the screw holes on the OLED to ease installation of the screen at the proper height.

Build Instructions

The build is organised in to multiple stages. You must follow the order sequentially. At the end of each stage there is a test checkpoint. It is important that you perform these tests to ensure each stage is working before proceeding to the next, failing to do so will make troubleshooting any problems much harder.

VERIFY CHIP ORIENTATION BEFORE SOLDERING.

OLED display must be installed last.

Take care in making sure the ICs are inserted the correct way around.

## Build Order: 

  1. ICS: RAM, Octal Latch, Shift Registers
  2. Arduino male headers. 
  3. Capacitors. (Make sure the 220uF electrolytic cap fits when the arduino is connected)
                 (10uF +ve terminal is soldered to pad closest to SD card holder.
                 
TEST POINT: Run the SRAM firmware test.

  4. MEC switches (Make sure these sit completely flush with the board and are not leaning to one side)
  5. Resistor arrays
  6. Encoders (Make sure these sit completely flush with the board and are not leaning to one side)  
  
TEST POINT: Run the button and encoder test firmware.
  7. ICS: MIDI Optocouplers. 
  8. Resistors + diodes
  9. MIDI DIN ports.
 
TEST POINT: Run the MIDIPort test firmware.

 10. Power Jack (+9V tip)
 11. Yamaichi SD card holder.
     
TEST POINT: Insert SD Card, Run the SDCARD test firmware
 
OLED Display:
 12. Oled display requires correct resistor poisiton in order to be configured for SPI mode. (See documentation above to confirm the resistor placement)
 13. Male header to be soldered to OLED board. Header is then soldered on to MegaCommand PCB. The height of the OLED display is important. The distance between the mainboard pcb, and the bottom on the OLED pcb should be 5mm when soldered.
 
 14. LEDs (+ anode pin nearest to the bottom of the board for both LEDs. ). When soldered, the tip of the LED should measure 11mm above mainboard pcb.
 
 15. Power switch. (optional, you can solder a short between the two right most pins on EG1212B  
 
 Expansion Headers:
 
 16. These are short 5mm headers. It might not be possible to buy them at the right length so you'll need to cut them down to 10 pin.
 
TEST POINT: Run the LCD and LED test firmware.

## Important

OLED Display must be installed last.

5) To install the male headers that connect to the MegaCommand to the ArduinoMega, insert the headers in to the ArduinoMega then solder with the arduino attached to the headers. This will ensure perfect alignment.

Firmware

Once you've built a MegaCommand you can upload the latest version of the MCL firmware located here: https://github.com/jmamma/MCL/releases

If you're familiar with coding you can write sketches within the Arduino IDE to test the hardware and run custom firmwware. Before you start coding you need to decide which core you are going to use.

Arduino Cores

In ArduinoIDE, a Core is a collection of initialisation functions and associated libraries, used for configuring the underlying hardware; it is analogous to an Operating System kernel.

The cores availabile in the Arduino IDE are listed under Tools -> Boards.

Arduino Mega or Mega 2560:

This is the standard core that comes installed default with the Arduino IDE. If you use this core with the MegaCommand you can program the MegaCommand like an ordinary arduino shield. The built in arduino functions can be used to control the hardware using the pin assignement detailed below.

MCL Core:

This was built on top of Manuel Odendahl's core for the MiniCommand. By using this core you can take advantage of the powerful MIDI libraries and GUI functionality.

For example, the MegaCommand core is necessary for running the MCL firmware, and controlling the Elektron instrument range.

Installing the MCL core.

(Instructions for OSX, should be similar for Windows)

Download the Arduino IDE https://www.arduino.cc/en/Main/Software (1.8.5 tested)
Get the MIDICtrl library and MegaCommand Core (same repo):

   cd /Applications/Arduino.app/Contents/Java/hardware/
   git clone https://github.com/jmamma/MCL

Selecting the Core

Open the Arduino IDE, Under the Tools menu, select the core you wish to use from the "Board:" menu

The default Arduino core is named "Arduino/Genuino Mega or Mega 2560"

The MegaCommand core will be listed at the bottom.

MegaCommand vs MiniCommand

The MegaCommand shield was designed to be backwards compatible with the original MiniCommand hardware.

However, there are notable differences between the two systems, including new pin assignments which must be taken account for when using the original MidiCtrl libraries.

The original MiniCommand used the ATMega64 microprocessor whilst the MegaCommand Shield is built on top of ArduinoMega which uses the ATMega2560 processor. The ATMega2560 shares most of the IO functionality of the ATMega64 but has additional pins, and a different pin-to-port layout.

The MegaCommand Shield accesses the ATMega2560 processor on board the ArduinoMega through the exposed headers, not all pins on the ATMega2560 are exposed through this Arduino interface.

Incorporating the differences between both processors and subsequent pin availability the following pin assignment has been made as the best possible substitutes for the original hardware layout.

4 Midi Ports vs 3
256k ROM vs 64K
USB vs No USB

--

MegaCommand pin changes from original MiniCommand are as followed:

MicroSD board:

CS = PB0

SRAM

BankSel = PL6

Key Scanning (Shift Register Circuit):

PL0 = OUT
PL1 = SHIFT
PL2 = CLK

HD44780 LCD Circuit:

E = PL4
R/S = PL3

LEDs:

PE5 = LED0
PE4 = LED1

MIDI:

TXD0 and RXD0 (USART0) are reserved for Arduino USB interface.

Therefore we shift midi ports by 1.

MIDI Port 1:

RXD1 = MIDI Port 1 IN.
TXD1 = MIDI Port 1 OUT

Midi Port 2:

RXD2 = MIDI Port 2 IN
TXD2 = MIDI Port 2 OUT ( New port, not available on original Minicommand)

megacommand_design's People

Contributors

Stargazers

Watchers

Forkers

yatli dar2dar2 tiretrak jwakely joseraulmail saqua defalutz beepetc gauthierroumagne tumes noluntas

megacommand_design's Issues

Alternative Chassis Design (migrated)

I'm working on a metal chassis design.

Basically, I'd like to make it low-cost, durable and mountable. The current design consists of two parts, each can be produced with sheetmetal (304, 6061 etc.)

Potential problems:

The screw tap hole "ears" are less than optimal. May consider bend the whole edge instead of cutting those 6 ears.
Screen height?
No power switch hole...

Peering issue

Hi :),

I’m just flagging up that my megacommand keeps getting stuck on peering when it’s connected to the MD mk2. This is despite all tests passing and the MD and MegaCommand both being updated to the latest firmwares. I’ve tried a few different MIDI cables but it’s the same still, and the ports all pass the MIDI tests.

Thanks for your help!

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.

Board file: Arduino male headers base profile should be printed on the other side

The second time I tooke an empty board, solder all the pins only to find I've done it on the wrong side (facepalm)

sram test fails

Hi, opening this issue after asking for help over at elektronauts after running into some issues as a possible consequence of the (classic?) mistake of soldering the oled before the sd-card holder.

Before desoldering the oled screen all test firmwares ran successfully. After desoldering the sram test fails instantly, led, sd-card and encoder/button tests all still successful. Ram test gives the following error:

Megank0 mismatch
2200
MegaCommand SRAM Test
2200
SRAM Test Failed bank0 mismatch
2200

Tried several times, tried reseating the board just in case but the same error occurs.
Before replacing the ram it would be great if anyone could shed any light on other possible causes than a damaged/faulty ram chip.

Here are pictures of my build:

Leftmost encoder SW1 not working, INS0 not connecting with res.matrix R2

I had trouble with odd behaviour from the module, after looking over it a few times for the most obvious faults i found the problem.

The inner (R2) of the two resistor matrices was oriented the wrong way around, so it had the text pointing into center of the board instead of outwards as the outer one was/is.

I had a little trouble removing it so i worried (not without cause, it seems) that it would come with a large bill in the end.

Result:

The first encoder (SW1 in eagle), the leftmost, does not work at all. I cannot more the cursor or do anything, change values and so on.

After testing the connectors, one after another:

ins8 har conn to end destination = OK
ins1 as above = OK
ins0 connects to the next to last point, which is on IC2 but not after that!

The next and last connection for INS0 is with the the third point on R2. This is not happening.

I have tried with the multimeter on the bottom side and on the top side between the yellow "sausage" of the matrix itself - both tries without success.

I must have f*cked something up when desoldering it or it didnt work from the start, who knows?

I am no master at desoldering so it walways gives me the shivers when i have multiple points i have to desolder to remove something. It´s 50/50 to succeed.
I forgot that i have a hot air soldering/desoldering station i could have used instead but now it´s probably too late. Or that do you think, should i try again ?

I´m not sure it will work even if i do it better next time because there might be some broken trace or something that is the cause. Of maybe one of the other solder joints to the matrix is fudged, who knows?

I could try it of course and will do if i cant figure out something else.

But i wonder uf there is anything else i can do instead of drastic things. Or any other drastic things i can try? How can i get INS0 to connect even if the solder joint is gone? Can i solder a small cable or jumper from the topside closest to the "sausage" to somewhere else? It´s not clear to me where it goes next or how the matrix even works?

Any ideas? Thanks!

A little Bug in OLED enclosure model.

Hello, there are not enough data in STL model for 3d printing the case.

MEC Switch + LED?

Didn't know that the switch is designed to host an LED in there:

So in theory we should be able to get 4xLEDs on the board but maintain compatibility with the current one.

Enclosure & knobs, {tall,short}/material recommendation?

I'd like to print a few official cases and knobs, any recommendations here? I see there are two versions (tall/short).
Also, very cool to see the knob getting modeled! Wonder if I could print rubber-like knobs?

Shift1 not working

Justin advised me to make an issue here so here goes..

I´ve built about 50+ MCL´s, many thanks to the group buy i organized a while ago, word spread - suddenly i had orders to build to a whole bunch of longing MD users - which was fun and it paid for my own unit plus i like to build and solder stuff, and since this being TH it was a bit easier than i normally build. So most of the units worked great. I think i have had until now maybe 3 with bugs needing to be fixed. Simple stuff, just me being sloppy doing bad solder joints, and one being a memcard not working.

BUT everything has an end! And suddenly i have two issues being tricky for me to fix without help, this is one of them.

The issue is with the lower left pushbutton (Shift1); the one that opens the menu. It´s doesn´t do anything at all, no reaction.

To fix it, I tried these things:

re-soldering the ICs, the button itself and in general cheking for bad soldering, which i didn´t find
ran the SRAM test without any trouble
tried swapping between three different arduino boards, that is not the issue, when i out any of them in my own unit, the one i have used the longest, everything works with no trouble
ran the button and encoder test = FAIL on just the button i have problem with, obviously

What have i done that MIGHT affect the function of the button?
The only thing that i MIGHT have changed is that instead of the 220 ohm resistors i put 221 ohm ones instead, possibly. I was out of 220´s and figured it shouldn´t matter, not with so little difference.. :)
Also, i have another 9v on/off switch than the EG1218 thats recommended but it works fine in the other machiens that use it, and i have the problem both when running on 9v power and usb so.. shouldn´t be that. Besides it be a little cramped for space and the switch casing are about 1mm or less from three of the SRAM legs i can´t see any problem with it.

I attach some pics of the front and back. Any ideas what to do; replace the button? Or some testpoint that i should check? I´m not super-good at Eagle, i can manage but far from an expert.

If you could give me some pointers i would be very grateful. I´m about to remove the button and test with another one but atm i don´t have one, but waiting for delivery from mouser next week, early to middle

Front:

Back:

Thanks in advance! //Marcus

MCL / button and encoder test fail

Hello Justin and Yatao,

I create this issue after having a conversation with Justin on the elektronaut forum.

At first I had a problem with the sram test, but now after reflowing the ic everything is fine.
I then tried the button and encoder test and I got nothing from the serial monitor, so I checked the SN74LS165AN chips and I got those results (those are in volt of course, even tho I didn't specify it) :

I maybe have to check again and de-solder again the male headers as I don't get the same results from those now, 0v all across apart for 47 and +5. Maybe it's just due to the amount of solder, my voltmeter is not that great. Isn't it strange the sram test is still working ?

Here are the pics of my pcb (I replaced one 0,1uf capacitor missing by another ceramic one I had left) :

Thanks for your help, and great great work you doing here !

Trouble with sram test and unit not working

Hi,
i have a unit that has given me a lot of headache, Sold it to a guy who cotacted me since he had trouble. It was working perfect when unit was tested here, and then i sent it. He contacted me, long story short but said he had "sd card error" message.

I got it back, saw that the arduino board had just about got unstuck so i put it back in place properly, also put a distance between the ard board and the lid som it was locked into place. Unit worked fine afaik.

Ok, got the same email again, decided i will have a look again and will let him buy it back after a while. But when i get it i have "sd card error" when i boot it up.
Just in case i reinstall latest firmware (whch is one step later than before). Boot it, everything works. Shut it down. Boot it. "Sd card error."

Weird, right?

I try a tip i read somewhere, test the voltage and ground, and all the IC circuits have 4.98 or 4.99volt in the right places, and 3.3 volt where it should be.

Ok, so i decide to run the test firmwares. The SD card firmware runs without ANY problems. Also the screen flashes black/white
Buttons work great. Midi i decide not to bother with. But the i try the sram test firmware nd all i get is this:

"Megacommand SRAM test
2200"

.. and nore more.. And that´s all. Tried a lot of things, reflowed solder joints and so on and forth, even got so far as to order replacement SRAMs.
Managed to desolder the old pretty niceliy.. Result? the S A M E!

Now i test with other units i am building, one so far has been tested this way (it´s missing screen, 9v switch, knobs and stuff, leds and resistors for leds, but should work the the testst i want to run. Ir runs great on the ones i used before but get the same result for SRAM test, 2200 and then STOP.

What the heck am i doing wrong? Any ideas? I have never had any customer get this issue before and i have built a LOT of MCL´s for people...

SRAM Addressing issue?

Hello, i was handed a "broken" MegaCommand device and just started to do some basic reflowing of the solder joints.

After running a few of the testing firmwares successfully, it finally failed on the SRAM one, i modified it a bit to print out what it reads from which address and that's when i saw an interesting pattern, it seems like the two lowest address bits are high which means it reads a slightly higher address than expected, every fourth read is correct.

Address 22F7 (10001011110111)  correct F7 (11110111) 
Address 22F8 (10001011111000)  read FB (11111011)  expected F8 (11111000) 
Address 22F9 (10001011111001)  read FB (11111011)  expected F9 (11111001) 
Address 22FA (10001011111010)  read FB (11111011)  expected FA (11111010) 
Address 22FB (10001011111011)  correct FB (11111011) 
Address 22FC (10001011111100)  read FF (11111111)  expected FC (11111100) 
Address 22FD (10001011111101)  read FF (11111111)  expected FD (11111101) 
Address 22FE (10001011111110)  read FF (11111111)  expected FE (11111110) 
Address 22FF (10001011111111)  correct FF (11111111) 
Address 2300 (10001100000000)  read 3 (11)  expected 0 (0) 
Address 2301 (10001100000001)  read 3 (11)  expected 1 (1) 
Address 2302 (10001100000010)  read 3 (11)  expected 2 (10) 
Address 2303 (10001100000011)  correct 3 (11) 
Address 2304 (10001100000100)  read 7 (111)  expected 4 (100) 
Address 2305 (10001100000101)  read 7 (111)  expected 5 (101) 
Address 2306 (10001100000110)  read 7 (111)  expected 6 (110) 
Address 2307 (10001100000111)  correct 7 (111)

I checked the traces between the Arduino data pins and the sram and latch, and they seem correct and no crosstalk.

I'm suspecting that the latch is broken, but it seems weird that only a few bits of the latch is broken, and i haven't been able to run it through a scope yet so i'm not sure if they're actually high or low.

I'm just curious if anyone have seen something like this before?

Too much peering for comfort!

Hi,

i have a unit that does an unusual large amount of peering. It still works but especially when i from the grid enter the settings menu, it shows up at every step and takes some additional time that feels too long.
Of all the units i have built before, this is the first i notice this excessive peering.
It behaves fine besides that afaik.
I have 3.10d installed, as long as X.04 on the MD.
I have run the ram test without issue.
What do you recommend checking?
In the MCL thread at elektronauts Justin recommended taking a look at midi communication on port 1. Anything else that i should be looking for?

Thanks in advance!

MIDI send/receive firmware test fail

Hi Justin-

I have moved this issue over from the Elektronauts forum. I posted there last week about having issues with the MIDI ins and outs of my MegaCommand build.

Summary - I've been building my MegaCommand as per the instructions on GitHub. Passed the SRAM and button/encoder tests and have now hit a wall at the MIDI out/in firmware tests.

My setup: I have a MOTU MIDI Express XT connected to my PC and Ableton. I’m using the front panel MIDI ports (channel 8) to send/receive. With my Machinedrum connected, I can play sounds from the machinedrum with my keyboard, and when I play a pattern on the machinedrum I see MIDI note info lighting up on the MIDI interface (as well as in Ableton). So I confirmed that the MIDI setup is working as it should.

Here is the latest update on what I have done as far as troubleshooting: I am only working on the MIDI out circuit since it is so simple - but I did confirm the optoisolators are installed correctly for the input circuits.

Confirmed the Arduino is functioning properly. I was able to recreate the MIDI out circuit on a breadboard to confirm my Arduino is working:

With this setup I ran the MegaCommand MIDI-out test firmware and confirmed note data being received by my MIDI interface.
(side note - I was working with an older cheap arduino clone that had the rx1/tx1 pins either mislabeled or miswired, so I bought another clone and confirmed the pins are correct and functional)
Checked continuity between all the points of the MIDI send/receive circuitry on the pcb between from the arduino headers all the way to the MIDI connectors - everything looks good.
Cleaned the PCB with 99% Isopropyl Alcohol
Checked another PCB from my order (I had the minimum of 5 made) by connecting only the MIDI out connections and resistors for TX1 output (see picture) - and WAS able to produce MIDI out notes that I confirmed on my interface:
Visual inspection of solder joints (looks OK to my untrained eyes)
Used a multimeter to confirm the resistors are 220Ohm - check

I'm really confused about this! I really would appreciate any insight / guidance on how to proceed at this point. Also here are pics of the build so far for reference.

Thanks for your time Justin, I really appreciate it.
-Jonathan

PROG NOT COMPATIBLE

Hi,
All was fine with my MCL 3.10d until the SD card has been broken in use. Can't repair it with disk utility.
Since i have a new SD card 16go FAT 32 formated, i try to create empty project just to check if it's working (without the MD connected to). Some of the project created are working some others are "NOT COMPATIBLE" project. For this kind of files, during the creation process, MCL shut down and restart before the end of the process.
I think i have a problem around the SD card somewhere, before this all was working good...