The native USB port on the Due uses USB CDC drivers to enable itself to be viewed as a virtual COM port, and allow serial communications. How come then, or how infact would one go about having the Serial Monitor working with the native USB port?
Connecting the native port to my PC with the CDC drivers installated that come with the SAM-BA ISP tool, it shows up as a virtual COM port, AT91 USB to Serial Converter - and it does indeed work as I have BOSSAC manually programming the chip. However, I'd like to be able to communicate with my board using the serial monitor / terminal, via serial on the native port?
If I'm correct, it is one of the standard features of the Due. In the cases I used it, it was simply replacing Serial with SerialUSB. On the computer side I could use the same software.
The only difference I noticed, beside the higher datathroughput, is that the SerialUSB does not reset when a connection is setup, were the normal Serial does.
I see - I have compiled my software replacing Serial with SerialUSB.println etc with no problems. However, where does one find the source for SerialUSB - as i'd like to see the difference?
I would have just thought it was as as simple as outputting the serial data on the D+ and D- pins, as opposed to the UART pins used by the 16U2 chip?
Also, with the drivers installed that come with the Arduino IDE - when the device has been erased, it appears as BOSSA Programming Port in the device manager, and with the drivers that come with SAM-BA, you get AT91 USB to Serial Converter. When you load code from the Arduino IDE however, it then appears as Arduino Due in the Device Manager - how does this happen? Is the chip sending out a name over the USB port or?
The Serial.print routines send data out the Due's Programming USB
Port, and one can use the "Serial Monitor" Tool to see that output.
The difficulty here is getting this Serial Monitor window
active in time to catch the first output from the program.
In use, it appears that opening the Serial Monitor window
causes the uP to reset, starting the program over again.
Not a nice "feature" if one is trying to control some
real time process. But, handy to see the first debugging
output (from the Setup() routine.
The SerialUSB.print routines send data out the Native USB Port,
and one would use some program in the PC to "catch" the data.
One might have a custom program, or use some "dumb terminal"
program to have simple interactions with the Due.
Here, the Virtual Comm Port appears to get reset whenever the
Due gets reset, so it is difficult for a program to open the Comm
Port until a while AFTER the Due program starts running.
But, you can start the Due program running, then the virtual
Comm Port will (re) appear, the PC program can start, open the
Comm Port, and start reading the incoming data, only having
lost the initial data from the Due.
Not convenient, but that appears to be the way it works.
Otherwise, it can appear to you that no data is coming to the PC.
