jmamma
trying to understand MegaCommand vs. MiniCommand
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?
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 [email protected] Reply-To: jmamma/MIDICtrl20_MegaCommand [email protected] Date: Thursday, 7 March 2019 at 8:16 pm To: jmamma/MIDICtrl20_MegaCommand [email protected] Cc: Subscribed [email protected] 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.
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
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 [email protected] 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.
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
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 [email protected] Reply-To: jmamma/MIDICtrl20_MegaCommand [email protected] Date: Friday, 8 March 2019 at 7:12 pm To: jmamma/MIDICtrl20_MegaCommand [email protected] Cc: Justin Mammarella [email protected], Comment [email protected] 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.
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..
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:
- arduino talks to oled with SPI -- good, both soft-SPI and hw-spi
- I begin sending commands to oled -- good, draw commands working
- 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..
- 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.
- 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..
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:
- 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.
-
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.
-
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
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:
}
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.
The sketch descriptions should say with core to run against. But I understand it can be easily overlooked.
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
So on the 3v3 rail it's not working (with HC4050 removed). But attaching to the 5v rail it works?
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.
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
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.
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 ?
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
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
Have you tested the SDCard subsystem using the SDCard test firmware.
That would be my first check.
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?
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
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
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 ?
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 :)
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.
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.
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?