trying to understand MegaCommand vs. MiniCommand

[yatli]

Hi @jamma!

I've been watching your repos for quite a while, and your work is both awesome and uplifting! I'm considering to make a small batch of megacommands for my elektron boxes (or Propellerheads Reason if I've got time to figure out the Remote protocol).

I surfed the repo a bit and found that most of the core code is refactored to cpp, and getting it up and running is as simple as creating a new arduino sketch and call MCL.run(). My question is, should this be compatible with the MiniCommand sketches? Those are more like bare-metal logic running on the midi library. Can I think of MCL as a mega sketch (hardened to c++)? Does MegaCommand provide extension point where I can drop my own code snippets?

[jmamma]

Hi Yatao,

The core of MCL is the MIDICTRL framework that was written by Wesen (Manuel Odendahl), almost 10 years ago now. It included a collection of libraries: MIDI, Elektron, GUI framework and other tools, which ran ontop of an Arduino/AVR style core.

The sketches/firmwares for the MiniCommand would use these libraries to interact with the Elektron machines.

The MegaCommand was designed as a hardware replacement for the Minicommand. The design was based on the Arduino MEGA which has a similar CPU to the original Minicommand. This was intentional, as I wanted to make it possible to compile and run code on the MegaCommand from the Arduino IDE, whilst still being able to use the MidiCTRL libraries.

MCL was originally written as a huge sketch for the MegaCommand. After I built the hardware, it made sense to refactor the Code in to re-usable classes, which now reside in the MCL folder.

As I developed the MCL firmware I also made several additions and enhancements to the MIDICTRL library. For example, much of the low level MIDI code has been rewritten, for performance and efficency. I rewrote the low level interrupt routines, added support for the OLED display and so forth. I’ve fixed bugs and added additional functionality to the Machinedrum Library and wrote a basic library for the Analog4,

The MIDICTRL framework has been upgraded, and the original Minicommand sketches are no longer compatible with the new code base. However, getting the functionality to work again would not be very difficult.

MCL is written in the general style that Wesen had laid out for the Minicommand. The firmware consists of a series of GUI Page objects each with different functionality. If you want to add in your own code. You can create your own GUI Page Classes and then call

GUI.setPage(&my_page);

after mcl.setup();

Alternatively, you don’t have to use any of the MCL code, you could write a sketch to use the MIDICtrl libraries directly or program the MegaCommand using Arduino libraries/functions.

• Justin

From: Yatao Li notifications@github.com Reply-To: jmamma/MIDICtrl20_MegaCommand reply@reply.github.com Date: Thursday, 7 March 2019 at 8:16 pm To: jmamma/MIDICtrl20_MegaCommand MIDICtrl20_MegaCommand@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [jmamma/MIDICtrl20_MegaCommand] trying to understand MegaCommand vs. MiniCommand (#1)

Hi @jammahttps://github.com/jamma!

I've been watching your repos for quite a while, and your work is both awesome and uplifting! I'm considering to make a small batch of megacommands for my elektron boxes (or Propellerheads Reason if I've got time to figure out the Remote protocol).

I surfed the repo a bit and found that most of the core code is refactored to cpp, and getting it up and running is as simple as creating a new arduino sketch and call MCL.run(). My question is, should this be compatible with the MiniCommand sketches? Those are more like bare-metal logic running on the midi library. Can I think of MCL as a mega sketch (hardened to c++)? Does MegaCommand provide extension point where I can drop my own code snippets?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/jmamma/MIDICtrl20_MegaCommand/issues/1, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AICKoQDnsTseXG8XHGgqGP15e3UiLT5iks5vUNjzgaJpZM4bitDH.

[yatli]

thanks, that clarifies things.

I rewrote the low level interrupt routines, added support for the OLED display and so forth.

yeah I was watching and felt really happy about this.

... and wrote a basic library for the Analog4,

didn't know this. I do have a MD + A4 setup! Just compiled the docs and gladly found MC supports 16 + 4 tracks...

GUI.setPage(&my_page);

that explains. I also used this kind of mini-app framework to build midi controller stuff (here: https://github.com/v-yadli/PAW-01/tree/master/PAW-01-controller)

pre-made

It's very kind of you. I do want to get hands-on quickly. I'm based in China so shipping might be an issue (could take months). I'll send the BOM to a local dealer and wait for their input.. So thanks, and if I'm blocked during assembly I'll let you know if I need to "cheat" ;)

such a good project to kick start 2019 Spring.

offtopic: and, you're the maker of MD-808/909? :O

[jmamma]

No worries,

I just saw your pull request and replied with a comment.

Which board are you intending to build? There are two versions. The earlier revision supports both the HD44780 and OLED display, whilst the later revision only supported the OLED.

---

From: Yatao Li notifications@github.com Sent: Friday, March 8, 2019 12:02 AM To: jmamma/MIDICtrl20_MegaCommand Cc: Justin Mammarella; Comment Subject: Re: [jmamma/MIDICtrl20_MegaCommand] trying to understand MegaCommand vs. MiniCommand (#1)

thanks, that clarifies things.

I rewrote the low level interrupt routines, added support for the OLED display and so forth.

yeah I was watching and felt really happy about this.

... and wrote a basic library for the Analog4,

didn't know this. I do have a MD + A4 setup! Just compiled the docs and gladly found MC supports 16 + 4 tracks...

GUI.setPage(&my_page);

that explains. I also used this kind of mini-app framework to build midi controller stuff (here: https://github.com/v-yadli/PAW-01/tree/master/PAW-01-controller)

pre-made

It's very kind of you. I do want to get hands-on quickly. I'm based in China so shipping might be an issue (could take months). I'll send the BOM to a local dealer and wait for their input.. So thanks, and if I'm blocked during assembly I'll let you know if I need to "cheat" ;)

such a good project to kick start 2019 Spring.

offtopic: and, you're the maker of MD-808/909? :O

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/jmamma/MIDICtrl20_MegaCommand/issues/1#issuecomment-470516855, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AICKoflbCrR_s75DoRQ4w84h_i-tq1zPks5vUQ4CgaJpZM4bitDH.

[yatli]

1.02 is a nobrainer for me because of 20 expansion pins:D

[yatli]

About the buttons: The closest button switch I can find around here is MEC 3FTH9+1T16 -- quite expensive (4xbuttons, the most expensive part in the BOM list other than the LED screen)

How does it feel like? I see it's "tactile button" so does it feel like a very short key travel "clicky" button? I would prefer elektron-style switches :D

[jmamma]

Yes the button switches have a short travel with a loud click, they are quite firm.

Elektron style switches might be a better choice.

If you find something better let me know.

From: Yatao Li notifications@github.com Reply-To: jmamma/MIDICtrl20_MegaCommand reply@reply.github.com Date: Friday, 8 March 2019 at 7:12 pm To: jmamma/MIDICtrl20_MegaCommand MIDICtrl20_MegaCommand@noreply.github.com Cc: Justin Mammarella justin.mammarella@unimelb.edu.au, Comment comment@noreply.github.com Subject: Re: [jmamma/MIDICtrl20_MegaCommand] trying to understand MegaCommand vs. MiniCommand (#1)

About the buttons: The closest button switch I can find around here is MEC 3FTH9+1T16 -- quite expensive (4xbuttons, the most expensive part in the BOM list other than the LED screen)

How does it feel like? I see it's "tactile button" so does it feel like a very short key travel "clicky" button? I would prefer elektron-style switches :D

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/jmamma/MIDICtrl20_MegaCommand/issues/1#issuecomment-470843128, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AICKoYxT-LtLcdJe43dSTIxiauFyTLf5ks5vUhtigaJpZM4bitDH.

[yatli]

I decided to buy enough 3FTH9 as fallback. The PCBs have arrived and it might be possible to make a few "adapters" to try. Cherry switches may be a good idea..

And only if we have access to cheap elektron spare buttons..

[yatli]

Ok I'm half way there. Passed sram & button tests. Then I proceed to install a socket for OLED (pluggable) and wrote some tests for it. The results are puzzling:

1. arduino talks to oled with SPI -- good, both soft-SPI and hw-spi
2. I begin sending commands to oled -- good, draw commands working
3. the oled becomes unstable if I draw more than ~800 pixels (either randomly or sequentially, or draw text) on screen. I tried this step incrementally -- at the critical boundary the screen first flickers and then die out. arduino continues to run fine, serial monitor working, but the screen remains dead. oscilloscope shows that arduino continues to transfer data, but the signal appears distorted somehow..
4. This is where it gets weird. The oled is powered by the 3v3 pin from arduino. I measured arduino standalone and the voltage is fine. Once I plug in MegaCommand, the voltage raises to 4.4v... The voltage keeps dropping when I add more pixels on screen (...because they draw power?), and when the screen dies out, the reading bounces back to 4.3v. Doesn't look good for the oled module.
5. Even with the oled module removed, I still measure 4.4v on the 3v3 pin.. If I unplug arduino, the reading is fine.

There are only a few components connected to 3v3 -- the 220uF cap, HC4050, and OLED vcc. With the screen removed we only have a cap and a blocky bug down there.

@jmamma any chance you could shed some light into this?

edit: the board is not 100% complete. sdcard slot hasn't arrived yet, so one less component connected to 3v3. cannot risk frying sdcards anyway so I'm going to keep the board until I sort this out..

[jmamma]

You don't need to "complete" the board to test out the subsystems. As you've discovered there's not much running off the 3v3 rail.

The 220uF Cap is there to stabilise the voltage from the Arduino Regulator for the OLED

I would recommend:

1) Test the OLED display independently of the MegaCommand board. You can wire it directly to your Arduino MEGA following these instructions: https://learn.adafruit.com/2-3-monochrome-128x32-oled-display-module

If this test reveals the same behaviour, then there is either a problem with your Arduino Mega's regulator circuit, or the OLED display is bad.

2) With the OLED display removed, check all traces on MegaCommand board's OLED circuit. Do point to point measurement and make sure you're reading ~ 0Ohms resistance on each trace.

3) Replace the 220uF capacitor. (If I had to guess, I would say the problem might be here)

This Adafruit page has a few more details about the display and power requirements. https://www.adafruit.com/product/2675

[jmamma]

I didn't realise there were no tests for the OLED display.

Here's one that uses the MegaCommand core.

#include "OLED.h"

/* The screen should turn completely white for 2 seconds and then completely black for 2 seconds 
No flickering or dead pixels should be visible. Some small amount of tearing might be seen.
*/

void setup() {
   oled_display.begin();
   oled_display.clearDisplay();
   oled_display.invertDisplay(0);
   oled_display.setRotation(2);

   while (1) {
   oled_display.fillRect(0,0, 128,32, WHITE);
   oled_display.display();
   delay(2000);
   oled_display.fillRect(0,0, 128,32, BLACK);
   oled_display.display();
   delay(2000);

   }
}

void loop() {
  // put your main code here, to run repeatedly:

}

[yatli]

will submit a PR for my OLED test firmware. also I think we'd better make a note that the test sketches should be run against standard arduino core.

[jmamma]

The sketch descriptions should say with core to run against. But I understand it can be easily overlooked.

[yatli]

I've done some tests with a breadboard, got the same behavior.

pulled off HC4050 and connects everything directly to 5v, and now it works like a charm. O.o

[jmamma]

So on the 3v3 rail it's not working (with HC4050 removed). But attaching to the 5v rail it works?

[yatli]

yes. aggregating the test results, and to minimize hacks on MegaCommand, I'm now trying to add back the level shifter, but cut 3v3 power supply to OLED -- instead give it 5v -- while still passing the signals through HC4050.

I suspect that the OLED module works fine with 3v3, but it's too power hungry.

[jmamma]

Do you have a link to the OLED you purchased?

For reference, i've built over 30 of these boards. None of which had this OLED problem. I had one dead OLED on arrival, but it still powered on.

There could also be a problem with the 3v3 regulator on your ArduinoMega

[yatli]

here's the link:

https://item.taobao.com/item.htm?spm=a1z09.2.0.0.11e92e8d1NyZQG&id=564748067500&_u=g1j65cac743

the specs inform that the logic pins tolerates up to 3v3, but power source can be 3.3~5v.

I tried the method (only re-wire the power source of oled, let signals pass through the level shifter), it works fine.

[jmamma]

Cool. Well you've found a solution 👍

You should be able rewire the power easily.

Out of interest, does the display hum or buzz under 5V ?

[yatli]

thanks a lot! I think I'm getting close! :)

no, the display is quiet. I can hear slight "zzzz" sound (switched regulator?) when I stick it to my ear :D

[yatli]

my sdcard arrived -- it does not initialize at SPI full speed -- setting it to half speed and it would initialize, but encounters errors when creating a project.

here's the log:

Welcome to MegaCommand Live
2021
func_call: sd_init
Initializing SD Card
SD Init okay
Config file open: success
Config file read: success
Current Page is NULL
Pushing page
New project page
tempo:
125.00
mcl actions setup
0
0
0
0
func_call: cfg_ports
Track sizes:
1742
1382
410
501
6
6
7
7
4
4
5
5
5
5
4
4
6
6
7
7
0
/project000.mcl
func_call: new_project
Creating new project
Attempting to extend project file
extension succeeded, trying to close
Initializing project.. please wait
func_call: clear_slot
Clear grid failed: 
36
0
func_call: clear_slot
Clear grid failed: 
36
1
func_call: clear_slot
Clear grid failed: 
36
2
func_call: clear_slot
Clear grid failed: 
36
3
func_call: clear_slot
Clear grid failed: 
36
4
func_call: clear_slot
Clear grid failed: 
36
5
func_call: clear_slot
Clear grid failed: 
36
6
func_call: clear_slot
Clear grid failed: 
36
7
func_call: clear_slot
Clear grid failed: 
36
8
func_call: clear_slot
Clear grid failed: 
36
9
func_call: clear_slot
Clear grid failed: 
36
10
func_call: clear_slot
Clear grid failed: 
36
11
func_call: clear_slot
Clear grid failed: 
36
12
func_call: clear_slot
Clear grid failed: 
36
13
func_call: clear_slot
Clear grid failed: 
36
14
func_call: clear_slot
Clear grid failed: 
36
15
func_call: clear_slot
Clear grid failed: 
36
16
func_call: clear_slot
Clear grid failed: 
36
17
func_call: clear_slot
Clear grid failed: 
36
18
func_call: clear_slot
Clear grid failed: 
36
19
func_call: write
write row header fail; 
coud not clear row
0

[jmamma]

Have you tested the SDCard subsystem using the SDCard test firmware.

That would be my first check.

[yatli]

Here's the test result:

Initializing SD card...initialization failed!
initialization done.
error opening test.txt
error opening test.txt
SDCard test Success!. Files contents matches bytes written and size matches

but...

  if (!SD.begin(5)) { // should be 53?

[yatli]

the sdcard test is fixed. see https://github.com/jmamma/MegaCommand_Design/pull/2

The write test finishes, but then the read test cannot open the file:

23:32:59.169 -> Initializing SD card...initialization done.
23:32:59.310 -> Writing to test.txt...
23:32:59.357 -> Writing iteration 0...
23:32:59.544 -> Writing iteration 1...
23:32:59.734 -> Writing iteration 2...
23:32:59.921 -> Writing iteration 3...
23:33:00.108 -> Writing iteration 4...
23:33:00.294 -> Writing iteration 5...
23:33:00.481 -> Writing iteration 6...
23:33:00.713 -> Writing iteration 7...
23:33:01.228 -> Writing iteration 8...
23:33:01.697 -> Writing iteration 9...
23:33:02.166 -> Writing iteration 10...
23:33:02.587 -> Writing iteration 11...
23:33:03.057 -> Writing iteration 12...
23:33:03.513 -> Writing iteration 13...
23:33:03.979 -> Writing iteration 14...
23:33:04.436 -> Writing iteration 15...
23:33:04.882 -> Wrote: 29184 bytes.
23:33:04.882 -> 
23:33:04.882 -> read test: error opening test.txt

[jmamma]

Thanks for patching that. I've tested your changes here:

Initializing SD card...initialization done. Writing to test.txt...Wrote: 1048576 bytes done. Reading contents from test.txt: SDCard read data matches RAM.

File Size: 1048576 Wrote: 1048576 SDCard test Success!. Files contents matches bytes written and size matches

[jmamma]

Regarding your SDCard issue.

First of all, are you using the Yamaichi Micro SD card slot? The MegaCommand board has the facility to use the Yamaichi slot directly (the sd card is level shifted via the HC4050). Or alternatively you can use an SD Card breakout board, like the one sold by Adafruit, these should run off a 5V supply and have their own level shifter built in.

If you're using the Yamaichi slot, I would carefully check your soldering using mangificaiton, for any small contact between pins. The spacing is quite tight and in the units I built where SD Card tests failed, some of those pins had shorts.

Finally, I am still skeptical about the 3v3 supply on your Mega, this seems to be the common denominator for your issues.

How are you powering the Mega, via USB or DC ?

[yatli]

reporting back after the weekend rush:

First of all, are you using the Yamaichi Micro SD card slot?

Yes.

for any small contact between pins.

double checked.

There's evidence the regulator problem is from the board. I hooked up a diode right after the regulator, and measure 3.3v on anode, but 4.1v on cathode. There's voltage flowing back from 5v.

There are shorts on the board after peek and poke around so I built the 2nd and 3rd... Same issue.

The sdcard test does have higher chance of success at slower SPI speed (e.g, 500Khz, but it's very slow in real MCL firmware)

I think a breakout board may be a better choice for me.

btw I tried some alternative switches. there's one with proper spring feedback, quite like the elektron switches. I'll report back on the experience when I get it in action :)

[yatli]

could it be an issue if I use SDHC?

[yatli]

the stability issue is quite similar to earlier oled issue -- it's not "all or nothing" -- I can make it as far as creating a MCL project half way.

[jmamma]

I use 8GB Sandisk SDHC cards.

I would try and get a replacement Arduino Mega compatible board. Probably going to be cheaper than buying the adafruit sd card breakout. And you'll have a spare mega for testing.

[yatli]

When I (mistakenly) connect an external power supply to the RESET pin on the MC shiled, I measure ~4v on 3.3v rail (3.3v rail not connected!)

Same happens on IOREF.

hmmmmmmmm..... bad PCB?

[jmamma]

There's no trace on the RESET pin.

[jmamma]

With ArduinoMega disconnected. do you measure 0Ohm (short circuit) between RESET pin and 3v3. ?

[yatli]

There's no trace on the RESET pin.

Exactly..

With ArduinoMega disconnected. do you measure 0Ohm (short circuit) between RESET pin and 3v3. ?

Yes.

[jmamma]

Oh no :-(.

With Mega disconnected:

Is there isolation between the 3v3 and 5V pin? What about 3v3 to GND

You could cut the unrouted pins off the power connector.

[yatli]

ah, sorry, my mistake..

I measure \inf on RESET vs. 3v3 (it says 0 on the meter :p)

I'm cutting off the offending pins, and set configurable nc pins to OUTPUT-LOW

[yatli]

With an empty board, 5v/3v3/gnd connected, I measure 4v somewhere from the sram pins.. That basically draws the conclusion—bad pcb, and a significant draw from 5v to 3v3 (so it “averages” to 4v somehow)

I’m getting the picture now; Lucky it’s not a huge batch.

I’m thinking that maybe I can scrap it up and isolate the 3v3 rail

[jmamma]

Bummer.

Shame to hear you've had so much trouble because of a bad pcb.

Hopefully the supplier will compensate. Did you use PCBway or someone else?

[yatli]

I'm using a local pcb fab here, will try to contact them.

given that I've soldered a lot of components onto the boards, I'd like to figure out how to rescue these.

[yatli]

Sometimes just have to do things the hard way. my idea is, if the problem is simple (but bad), there should be only one shorted pin. so, connect arduino gnd, 3v3 &5v to the mega. measure 3v3. then:

foreach(var pin in shield_connectors) { connect pin; observe; }

I iterated through ALL the pins and found pin #42 the offending one -- once I plug it in, the reading turns 4.2v instead of 3.3v!

so unless there's butterfly effect if I plug in more than 1 pin, I have a solution! :D

[jmamma]

Pin 42 should be PL7 which is the CS pin for the OLED. This is routed to the HC4050 and is level shifted from 5v -> 3v3

The SD Card and OLED display share the SPI bus. When CS for a particular device is HIGH, the device stops listening on the bus.

So in this instance, when accessing the SD Card, CS for the OLED must be set high.

---

Have you found a way to mitigate the pcb defect?

[jmamma]

I just took another close look at your board.

The image is blurry, but some of the soldering looks suspicious to me.

For instance this spot here:

[yatli]

thanks for checking out. the picture is from the first (damaged) board. last night I tried the "foreach pin" method but it did not generalize well -- out of the three boards I've already soldered, I observe different "shorting" pins. it may indeed be a soldering problem.

To minimize the chance of breaking a (working but vulnerable) board, I'm starting from another direction, mount the sdcard first and run the test firmware:

It did not work, and I measure 4.5v on 3v3 rail.

edit:

absolutely clean this time:

[jmamma]

Okay soldering looks good and part orientation is okay. I use electrolytic for c7 but i dont think that will make a difference.

[jmamma]

Have you double checked the isolation between these points.

3v3 -> 5v 5v -> GND 3v3 - > GND

[jmamma]

Can you check this spot here. Looks like a bit of solder below the pin. I believe the SPI bus trace passes underneath it.

Can you confirm it's not sitting on any copper below.

[yatli]

it's not solder, just flux. the isolation looks good.

I remove CD4050BE and the voltage drops back to 3.3v instead of 4.5v.

I double checked the measuring of the empty board, it turns out the 4v measuring is because my 5v power source was only outputting 4v (duh!)

[jmamma]

"I double checked the measuring of the empty board, it turns out the 4v measuring is because my 5v power source was only outputting 4v (duh!)"

Arduino powered at 4v ?

[yatli]

Arduino powered at 4v ?

nope, months ago I mounted AMS1117-based little power source to the wall:

it didn't last too well :/

[jmamma]

😱

[yatli]

sorry! <( )>