I noticed that since I use the MIDI library from 47effects, I cannot use the print(ln) for the serial port for debugging purposes, neither I can find it in the documentation.

It states that the MIDI library uses the serial port, but I really miss the serial port now for debugging.

Update: so my question: The MIDI library uses the RX (pin 0) and TX (pin 1) on my Arduino One. However, I think the internal Serial.print/println also uses these same pins, so I was wondering how I can use Serial.print and Serial.println statements being visible on the Arduino IDE Terminal (emulator) while using the MIDI library.

1 Answer 1


I assume you have one or more Arduinos, are trying to do MIDI control, and want to know how to debug with the MIDI library having commandeered the hardware serial port.

One approach is to use I2C or SPI to communicate with a second Arduino, which uses its serial port to deliver debugging data to a host system. See Nick Gammon's excellent page Debugging using SPI/I2C and a second processor (gammon.com.au forum id=11329), which illustrates communication between two Arduinos, using one of them as a slave to forward information sent by I2C or SPI from a system being debugged.

Another approach might be to use a serial bridge. I don't know the ins and outs of this or exactly what it does but have read that, for example, the Hairless bridge (which is an open-sourced software package) can display both sides of MIDI communication, possibly depending on use of Serial.write vs Serial.print. You could designate certain note sequences as standing for various debugging cases.

A third approach is use of Arduino software serial to send debugging data to a serial port on your host system. This would use some Arduino pins other than the hardware Rx, Tx pins.

Edit 1: Pin Usage –

For approach 1, using I2C ties up two specific pins, SDA and SCK. These are shared with other I2C devices, if any. SPI typically shares three signals – SCLK, MOSI, and MISO – among all SPI devices, and generates one SS signal per device. For pinout and protocol details, see Nick Gammon's well-organized and clearly-illustrated I2C and SPI pages.

Approach 2 would use no extra pins.

Approach 3 would use one or two extra pins: one for half-duplex or output-only communication (which may be adequate for debugging), two for separate Rx, Tx lines. Compared to hardware serial, software serial is CPU-intensive, does not support as-high data rates, and has a higher error rate. It should work ok for light-weight debugging output, such as occasional text to show what tests succeeded or failed or what branch was taken, or values of a few variables.

  • Thanks for all the possibilities ... A second Arduino seems a bit like overkill (but if it works, it works, just have one so far, I'm a beginner). The second sounds a bit troublesome, since my program might be rather complicated in time. However, the third seems very good and exactly what I need. Can I also ask one additional question? I'm intending in time maybe also to use SRAM, SD and/or an extra EEPROM ... will I get similar problems again (that the SD /SRAM/EEPROM (SPI) also uses hardware RX/TX ?) Mar 13, 2017 at 11:27
  • 1
    @MichelKeijzers, see edit 1 Mar 13, 2017 at 18:08
  • Thank you (again ) for the extra explanation ... it seems the CPU might be a problem if I would go debugging by approach 3. Maybe an extra Arduino is not so bad idea after all. At least it will give many more things to try (still in 'learning' mode). Mar 13, 2017 at 22:02
  • 1
    All of the approaches are easy to try – if you have time to experiment and if you have a serial port on your host computer – and you can take debugging out after using it. Anyway, if you have a serial port or a USB-serial device, it's probably worth trying out software serial, since the extra bit of CPU usage for debugging might be not a problem. Mar 13, 2017 at 22:14
  • Yes I will go for the software solution first, probably for debugging, timing is not so much a problem. Mar 13, 2017 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.