Notifications
Clear all
Topic starter
I'm trying to program the SAM2695 and send it notes that are coming from an organ pedal using a keyboard scan modul PEDSCAN.
The module has a three pin outlet going to the classical DIN plug (2 - GND, 4 and 5 wired). When I connect this module to my MacbookPro I can monitor the codes that are coming out of the module using the PocketMIDI application. The codes coming out there are exclusively:
[code type=markup]
90 25 40
80 25 40
90 25 40
80 25 40
90 27 40
80 27 40
90 27 40
80 27 40
[/code]
These come from two test buttons that are connected to the keyboard scanner and simulate the notes 37 and 39 (a D and an E), and they show a note on, note off action, with vv (velocity) constantly set to 40h. All fine.
Now I would like to pass these codes through an Arduino Nanos' SoftwareSerial Port and the codes I'm receiving are being garbled by something I cannot find out at the moment. As said, in the Midi Monitor PocketMIDI all is fine and correct.
As soon as I disconnect (I understand that connecting both, the adapter and my hardware could bend the signal to unwanted levels) and connect the following converter circuit, the trouble begins.
Often the Data bytes are garbled (40 becomes FF etc.). Is the optocoupler circuit wrong?
Posted : 10/03/2023 2:14 am
I'm not familiar enough with the hardware side of things to comment on that. But when you mentioned hex FF, that reminded me of another user who recently posted about their Arduino MIDI project sometimes producing a sequence of "-1" values.
The Arduino Serial.read() function returns a -1 value to indicate there is no data available to read. If your code isn't checking if(Serial.available() > 0) before every Serial.read() call, then Serial.read() might sometimes encounter no data available and return a -1. When -1 is converted to an unsigned byte, it will show up as hex FF.
Posted : 10/03/2023 5:29 am
The optocoupler circuit is fine.
SoftwareSerial is not reliable; it will read wrong bits when its code does not manage to get executed early enough. A hardware serial port would not have this problem.
Posted : 10/03/2023 11:50 pm
Topic starter
@Bavi_H:
I have this read loop:
[code type=markup]
if(midiSerial.isListening())
if(midiSerial.available() > 0) {
c=midiSerial.read();
midiSerial.write(c);
snprintf(str,5,"\n%02x ",c);
Serial.print(str);
}
[/code]
@Clemens Ladisch:
Thanks. I'm already in the course of changing to the on chip UART.
Posted : 11/03/2023 3:11 am
Topic starter
I solved the issue meanwhile. The MCU (Mega128 in the Arduino) was too slow and the software concept was too lazy.
I moved the development to a faster MCU (STM32Fxx) and implemented interrupt handling, UART ringbuffer and multitasking.
This were reading errors from the UART, as Clemens already correctly stated.
Posted : 06/04/2023 7:56 am
Some UARTs need Pull ups on the RX/TX. When lines are floating at startup you get garbage.
Posted : 16/08/2023 8:54 am
