I am trying to confirm that digital pin 0 (RX0) does not work to receive TTL serial data.
I can successfully receive serial data on RX1, RX2, and RX3. I can also successfully send data on TX0. I am using an FTDI TTL-to-USB cable.
Neither DUE USB ports are in use or connected.
As far as I can tell there is no difference in the method I use to connect to any of the serial ports.
I don't have an oscilloscope but as far as I can tell (using a multimeter) RX0 behaves differently from RX1, 2, or 3. Whereas I can see voltage changes on the latter three pins when receiving serial data, pin 0 (RX0) holds a very steady 3.3V at all times.
I have observed this behavior on 2 separate DUEs. It seems so odd that I think I must be overlooking something obvious.
#define BAUD_RATE 38400
void setup() {
/*
* initialize serial communication on all portd
*/
Serial.begin(BAUD_RATE);
Serial1.begin(BAUD_RATE);
Serial2.begin(BAUD_RATE);
Serial3.begin(BAUD_RATE);
}
void loop() {
//Serial.println("=TX0="); // uncomment to test if the TX line is working regardless of input
if (Serial.available()) {
Serial.write(Serial.read());
Serial.print(0); // intersperse chars with a marker
}
//Serial1.println("=TX1="); // uncomment to test if the TX line is working regardless of input
if (Serial1.available()) {
Serial1.write(Serial1.read());
Serial1.print(1); // intersperse chars with a marker
}
//Serial2.println("=TX2="); // uncomment to test if the TX line is working regardless of input
if (Serial2.available()) {
Serial2.write(Serial2.read());
Serial2.print(2); // intersperse chars with a marker
}
//Serial3.println("=TX3="); // uncomment to test if the TX line is working regardless of input
if (Serial3.available()) {
Serial3.write(Serial3.read());
Serial3.print(3); // intersperse chars with a marker
}
}
The intent of this code is to echo back any received data on the same port it was received (along with a marker char to verify the origin).
I am using a simple PC based program to send the string "ABC" once per second and to output any received chars.
I am using an FTDI USB-TTL cable to connect to the DUE with three wires.
GND - GND
TX - RX (on port being tested)
RX - TX (on port being tested)
I am moving the TX and RX lines to each of the serial port pair in sequence and monitoring the output (if any).
Attached you will see a picture of my setup with the TX/RX lines attached to RX0/TX0.
This works perfectly for Serial1 (RX1/TX1), Serial2 (RX2/TX2), & Serial3 (RX3/TX3) but not for Serial (ie., pins RX0/TX0).
Uncommenting the line //Serial.println("=TX0=");
results in the "=TX0=" chars being received at the PC (assuming the FTDI cable is attached to RX0/TX0).
I have subsequently also tried this on a 3rd DUE straight out of the box with the same results.
There is some chatter on the internet regarding this issue but nothing I can see as definitive.
Some peoples issues appear to revolve around trying to use the USB programming port at the same time as RX0. This is not the case in my setup.
Other people have suggested applying either a pullup resistor or a pulldown resistor to the RX0 port. I have not tried a pullup resistor because my RX0 pin never seem to go low at all. I have tried various pulldown resistors with no effect.
Does it work if you use the serial monitor in the IDE? (without the FTDI cable attached)
Edit:
I've gone over the circuit diagram of the Due a few times and I do think this should work, but, it's not the best port to use as the RX pin could be forced low by IC6 (the AT16U2, IC10 ensures the RX pin is either 3-state or low)
@ard_newbie: I will try your code as soon as I can. Thanks for the tip on the 5th port. In my application I need 5 ports. My design uses the 4 hardware ports and one software serial port. Had I known about the 5th port when I was designing my boards I probably would have used it in preference to creating a software port. As I don't need duplex comms in all cases I have been able to use the RX line of another port to work around the RX0 problem. This is really more of an abstract question to try and understand what I am seeing and perhaps to do things differently in future if needed.
@weird_dave: yes, there is no problem with two way communications using 'Serial.xxxx' commands if I use a usb cable plugged in to the programming port.
ard_newbie:
And FYI, there is a Serial4 available if you need 5 U(S)ART(s).
Where? Not in my version of the DUE variant.h.
Arduino: 1.6.13 (Windows 10), TD: 1.35, Board: "Arduino Due (Native USB Port)"
C:\Users\username\AppData\Local\Temp\arduino_modified_sketch_834122\sketch_feb05a.ino: In function 'void setup()':
sketch_feb05a:3: error: 'Serial4' was not declared in this scope
Serial4.begin(9600);
^
exit status 1
'Serial4' was not declared in this scope
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
The USB serial can be used as a 5th serial, if the only purpose is to communicate with a PC via USB. It's not a USART.
Apologies in advance for whatever crimes I'm committing by updating this thread, but if this is where you find yourself when searching for Due RX0 then hopefully this will help...
Short answer - if you need to use the RX0/TX0 port direct to the SAM3X you can by removing IC10. This will disable programming via the 16U2 USB programming port however you can still program via the native USB port (I've seen suggestions this doesn't always work but it does in my limited experience).
Longer version - I want to be able to flash the SAM3X from a linux device without using USB and I believe the TX0/RX0 port allows use of the SAM3X rom bootloader via TTL serial. In common with others I have found that RX0 is constantly driven by the 16U2 via IC10. The reference Due schematic suggests that IC10 is intended to tri-state the 16U2 tx line but it appears most/all Due boards have IC10 ~OE tied to 0V so IC10 is just used as an unnecessary buffer.
There's a good picture showing the actual location of IC10 in this thread (covering differences between Due reference design and actual boards):
Attempt 2.