Due2Due Native USB port null modem

I would like to connect the Native USB port on one DUE to the Native USB port on a second DUE to form a Due2Due USB null modem bridge. I like the operational properties of DUE’s USB as it utilizes DMA, its non-blocking and its fast.

I’m thinking of initially testing FTDI’s USB to USB Null Modem Cable adapted to Micro-b male adapters on each end.

Another possibility might be using 2 Microchip MCP2200s on a PCB with RX/TX connected in null modem fashion.

I’ve started by testing some operational capabilities of the Native port using Arduino 1.54.

  1. KeyboardController example works OK with either a regular type USB cable (Device Mode) or an OTG type USB cable (pins 4-5 jumpered, Host Mode).

  2. MouseController example works OK with an older Logitech optical mouse and also with a newer wireless type with 30ft range. Both Regular or OTG type cable interface works.

  3. Serial CDC communication with PC: Here I’ve tested the maximum packet size that can be sent to the PC using SerialUSB.write without causing overflow or error. Its 255 bytes (verified using a small LabVIEW program I wrote). I would send back one byte at a time and monitor the SerialUSB.available on the Due to check its maximum size. Here, it would max out at 511 bytes. The 512th and 513th byte sent would cause no error on the LabVIEW program…the Due’s serial monitor showing SerialUSB.available would still read 511. The 514th byte would cause LabVIEW to report a timeout error and stop the program.

So on the Due end, it looks like the maximum packet size for writes is 255 bytes and for reads is 511 bytes.

Here’s the sketch I used on the DUE to test max packet size:

void setup()

void loop()
  byte i=0;
  for (i=0; i<255; i++){
  Serial.print("SerialUSB bytes available(): ");


Has anyone tried using the Native port for Due to Due communication?

Presumably, if you have one Due's Native USB in Host mode, and the other in Client mode (the normal mode for using SerialUSB. print) you do not need a null modem, just a normal USB cable?

Yes, that would be ideal. From my understanding, a regular cable would leave both Due's in Client mode. If using an USB OTG cable, the end with pins 4-5 shorted would place that Due in host mode while the other end with pins 4-5 isolated would leave that Due in Client mode. I have the cables, but haven't tried it yet ... doing more research into the USB header files, cpp files etc.

What is strange to me, is that from an operational standpoint, there is no difference what cable type is used for my earlier keyboard, mouse, or CDC serial to PC tests (both types work). I don't think USB OTG is fully implemented on the Due - not sure - (it might not matter for a Due2Due connection).

Pardon me for raising an old thread up from the past, however I am also trying to achieve Due to Due communications via USB.

Thank you for sharing all this information, did you happen to get this working at all?

Many thanks.