Everything works as it should on my Nano, but I need more Arduinos and I found some UNO boards cheaper than Nanos.
I've uploaded the blink Sketch and it works fine, but I can't seem to make the MIDI signal communicate with the board. I've swapped the boards with each other and the Nano works on both circuits. I've tried all the UNO boards with no luck. The serial activity LEDs aren't even flashing, but the midi does interfere with sketch uploading.
Am I missing something in the code that's UNO-specific?
We need to see what you have actually built for the two processors. That means good quality photographs. Also please post your schematic, not links to it.
#include <MIDI.h>
MIDI_CREATE_DEFAULT_INSTANCE();
#define MIDI_LED LED_BUILTIN
void setup() {
pinMode(MIDI_LED, OUTPUT);
digitalWrite(MIDI_LED,LOW);
MIDI.begin(MIDI_CHANNEL_OMNI);
MIDI.turnThruOff();
}
void loop() {
if (MIDI.read()) // Is there a MIDI message incoming ?
{
//Pass through system commands, uninterrupted
if (MIDI.getChannel() == 0) {
digitalWrite(MIDI_LED, HIGH);
MIDI.send(MIDI.getType(), MIDI.getData1(), MIDI.getData2(), 0);
digitalWrite(MIDI_LED, LOW);
}
//Remaps channel 2 to channel 16 in the midi universe
if (MIDI.getChannel() == 2) {
digitalWrite(MIDI_LED, HIGH);
MIDI.send(MIDI.getType(), MIDI.getData1(), MIDI.getData2(), 16);
digitalWrite(MIDI_LED, LOW);
}
//Remaps channel 3 to channel 1 in the midi universe
if (MIDI.getChannel() == 3) {
digitalWrite(MIDI_LED, HIGH);
MIDI.send(MIDI.getType(), MIDI.getData1(), MIDI.getData2(), 1);
digitalWrite(MIDI_LED, LOW);
}
//Remaps channel 6 to channel 2 in the midi universe
if (MIDI.getChannel() == 6) {
digitalWrite(MIDI_LED, HIGH);
MIDI.send(MIDI.getType(), MIDI.getData1(), MIDI.getData2(), 2);
digitalWrite(MIDI_LED, LOW);
}
}
}
On the Nano, the RX and TX LEDs flash when data is read and written respectively, as well as the LED_BUILTIN flashing with each piece of data being remapped. Uploading to the board is blocked (as it should be, caused by the MIDI stream over serial)
Thanks for posting the pictures. It is a bit difficult to see what is going on.
What I noticed on the one of your Uno clone, is that you have the ground connected to the red bus bar of your bread board. Not in itself a problem but it could be confusing later on. Conventionally red is for positive and black is negative. I know from teaching international students that this is not always as deeply engrained as it is in the West.
I notice that your Nano and Uno do not use the same solderless bread boards for the peripheral circuits, so maybe there is a mistake on the Uno one. Or something is not making a good connection on the solderless bread board?
It looks like the Uno clone uses a CH340 serial to USB chip, is the Nano also a clone with this same chip? As I said both Uno and Nano use the same processor chip.
As to the software:-
This is wrong, there is no channel 16 on a MIDI channel. Channels, in software go from 0 to 15 only. So you will never get a MIDI signal with 16 in it.
I also don't see any
It is not wrong. The MIDI spec defines that user-facing channel numbers are 1-based, not 0-based. The MIDI library does this correctly, and gives the unused channel 0 a special meaning.
The official UNO uses the Atmega16U2 for serial communications.
The official nano uses the FT232 for serial communications.
Almost if not all UNO clones use the CH340G for serial communications.
The big difference with the CH340 implementation is that the serial activity LEDs are connected directly to the TX and RX (DO, D1) lines whereas the FT232 and 16U2 have dedicated pins for the LEDs.
I'm sure that the LEDs and current limiting resistors would interfere with the MIDI connections.
Using the MIDI library by FortySevenEffects switches things to a common understanding for midi channels instead of the standard hexadecimal format for channels 1-16.
Based on my understanding, channel '0' is where SystemExclusive messages exist, allowing for song Start/Stop messages to pass through, in this context.
I know my software works, it's been doing its job for over 6 months without an issue. But as soon as I changed to the UNO format it is no longer functioning as I would expect it to.
This is done strictly for ergonomic reasons and to avoid fatiguing the front plate pins while keeping it as a grounding point. When removing the DIN-5 plug from the port it tends to pry up from the back so it's easier to keep the edge of the port flush with the side of the breadboard.
When I tested with the Nano before on both circuits, it functioned as it should, I've checked for continuity with my multimeter at all points and I can't find any open spots in the circuits.
That actually makes a lot of sense. When I was looking at the schematics for the genuine UNO pinouts and schematics it lists the RX and TX LEDs on P4 and P5, respectively, which confused me.
I'll keep poking around and figure out if there's a discrepancy between the two builds that I'm missing.
Funny but I have never come across this effect of that library before, is it a new version that I haven't used before?
If it indeed mucks about as you say it is appalling. The fact is that user-facing channel numbers are only for idiots who can't cope with the concept of zero as a number. The most significant four bytes of all messages define the real channel number, with the exception of system message which all start with '0xF' in the most significant number.
Just look at the messages sent, you can't fit 16 into four bytes. This is something that can't be sent in a MIDI message.
This has always been the case, “Channel 0” was never a thing. See e.g. the original 1996 MIDI 1.0 specification. The channels are numbered 1 through 16, and encoded using 0h through Fh.
Not idiots. Just musicians, for which the MIDI protocol is intended.
Yes. I understand that.
But to put that model into a program language is just for people who are intellectually challenged by the concept of adding one when displaying a channel and subtraction one when talking a channel request from a musician.
This is at odds with the way every other MIDI library works in any other language or indeed any other library used on the Arduino.
It is educationally a dead end and deserves to be condemned in the strongest terms.. see how it has confused the OP already.
