Hey all,
Is there a difference between the output from the IDE's serial monitor, when you type things into it, and the output from an Arduino using Serial.print()?
More details: I've been struggling with this problem for several hours now. Basically, I have an Uno programmed to listen to the serial monitor and do stuff based on commands typed into the serial window. eg, I type " <0> " into the serial monitor, and the Uno does a specific command. That works fine.
Next I wanted another Arduino to be able to generate commands instead of using the serial monitor. I thought it would be trivial; simply connect the two Arduinos RX-TX and TX-RX, and use Serial.println().
void setup() {
// put your setup code here, to run once:
delay(2000);
Serial.begin(115200);
}
void loop() {
// alternate printing <0> and <1> every 3s
Serial.println("<0>");
delay(3000);
Serial.println("<1>");
delay(3000);
}
To my surprise and dismay, it does not work. I tried TX-RX and RX-TX connections first, and then I tried connecting the two USB ports (both Arduinos have onboard USB), and that doesn't work. And I tried switching to SoftwareSerial but that didn't work either.
My conclusion is that the serial window is doing something that Serial.print() doesn't... but what?
FWIW, the code for the listening Uno is "DCC++ Base Station", from GitHub - DccPlusPlus/BaseStation: DCC++ Base Station for Arduino Uno and Mega . I didn't post that code here because it's super complicated but works, so I'd rather not go in and edit it, when instead all I need to do is replicate from an Arduino what the serial window outputs.
Beside what sterretje wrote, I can think of another far fetched explanation. Suppose there is too much going on in the "DCC++ Base Station" code and the Arduino can not keep up with the high speed of incoming data. Perhaps the serial monitor of the Arduino IDE slows it down with larger gaps between the bytes.
The function process() reads the incoming data and ignored everything that is outside the '<' and '>'.
In the loop(), the function process() is called.
jeffreybrockhouse, are you sure that the Uno with the "DCC++ Base Station" did not get a new sketch ? It is possible that the Ethernet interface was selected and that turns off the serial interface.
Thanks for the replies everyone! I took another crack at it this morning and have made some progress. First though, re: the points mentioned, the sending device is a Micro, and GND is connected... the sending device gets both power and GND from the listening Uno.
I made a new sending program given the suggestions about possible line endings and timing, so this one spits out four different ways of saying the same thing.
#include <SoftwareSerial.h>
//#define interface Serial // using hardware serial
SoftwareSerial interface(2, 3); // using software serial
void setup() {
// put your setup code here, to run once:
delay(2000);
interface.begin(115200);
pinMode(13, OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
// output <0>
interface.println("<0>");
delay(1);
interface.print("<0>");
delay(1);
interface.println("<0>");
delay(1);
interface.write("<0>");
delay(1);
digitalWrite(13, LOW);
delay(4000);
// output <1>
interface.println("<1>");
delay(1);
interface.print("<1>");
delay(1);
interface.println("<1>");
delay(1);
interface.write("<1>");
delay(1); digitalWrite(13, HIGH);
delay(4000);
}
It works now, though only when using SoftwareSerial on the sender (with sender's 2 3 connected to listener's TX RX). Strangely, the same program doesn't work when switched to use hardware serial, with sender's RX TX connected to listener's TX RX.
In any case, now all I have to do is stick with software serial and try deleting some combinations of print, write, and delay, to find out which one(s) work. Thanks!
It feels as if it is a timing issue. The problem is still the same: if you transmit data at 115200 baud with a hardware serial port then it does not work.
The whole thing is nonsense, there is no timing issue or a need of slow send if correctly powered (and both are 5V) and pins correctly wired, sending and receiving through hardware serial should work, even at much faster baud rate.
the sending device gets both power and GND from the listening Uno.
what do you mean? Can you describe how they are powered?
J-M-L there is a mention of interrupts in the receiving sketch. That's what this is about.
With 115200 baud, the 64 byte buffer is also filled very quickly. That is probably not a problem, but in a very weird situation it might be possible that it causes a problem.
Now that I look at the ISR functions with the macro, it is just plain code. There are no 'while' or 'for' loops in the ISR.
Re: power, the listening Uno gets 8V to its DC jack. The sender I had it wired in a couple different configurations: Uno's 5V and GND directly to sender's Vcc and GND, and also, the same 8V supplying the listener also going to the sender's raw and GND. Didn't make a difference.
Re: serial monitor, most of the time I had only two of the three devices (serial monitor, listener, sender) connected at any one time; sender connected to serial monitor showed the correct output of <0>s and <1>s, serial monitor connected to listener allows me to type <0> and <1> and they work, yet the listener plugged into the sender does not work with hardware serial.
In any case though it's working fine using SoftwareSerial with println(), so I'm happy to call the problem solved. I dunno what I'm doing wrong with the hardware serial connection, but it'll be better this way anyways, because I'm leaving the hardware serial available for programming and monitoring without having to disconnect the two devices.
When you use software serial, you have two serial ports and can easily connect both the IDE’s monitor to one board and the board together. There is no risk of conflict.
