My current project has both Serial and Ethernet "consoles" on a Due. There is always information spewing to Serial.print, whether there is a device listening or not. Problem is, if there is no application (i.e. HyperTerm or similar) listening to the Programming Port on the PC, the sketch hangs until I start an application.
How can I prevent this? Is it a Windows configuration problem, or something I need to change in the sketch?
Regards,
Ray L.
RayLivingston:
::::SNIP::::How can I prevent this? Is it a Windows configuration problem, or something I need to change in the sketch?
RayLivingston,
please post your code. Please use the "code" markup.
Like this:
[code]
// Put your code here
[/code ] // <<== and remove the space
Ummmm..... My code is probably 20,000 lines of code spread over dozens of modules and libraries. The object code is almost 150 Kbytes. So not at all practical to post. The only issue is using Serial.print on the Due when the Programming Port is connected to the PC, but no application is connected to the corresponding COM port causes the Due program to eventually hang. Open a terminal application on the PC, and suddenly all is well. All I can figure is it has to be a buffer-full condition on the Due Serial causing the problem. This does not happen on, for example, a Pro Mini. If I re-direct the Serial accesses to Ethernet (accessing both as Stream devices), and the problem does not occur.
What does Serial do when its buffer fills up? Does it know if/when there is anyone "listening" on the PC. On the Pro Mini, the serial data just goes into the ether, but on the Due perhaps it knows there is no other device listening, so does not actually transmit the data, and the transmit buffer fills up and subsequent print call block?
I will try to put together a small test program that demonstrates the problem...
Regards,
Ray L.
I have no proof but the way you describe it to work sounds reasonable for the programming port. I would guess that this behavior ensures that you don't miss anything when using this port. One thing I do know for sure is that the behavior of the native port is totally different. You can feel free to send as much to the serial port there as you want and it'll just dump the data if it can't send it. My suggestion would be to use SerialUSB instead of Serial.
Collin80:
I have no proof but the way you describe it to work sounds reasonable for the programming port. I would guess that this behavior ensures that you don't miss anything when using this port. One thing I do know for sure is that the behavior of the native port is totally different. You can feel free to send as much to the serial port there as you want and it'll just dump the data if it can't send it. My suggestion would be to use SerialUSB instead of Serial.
Sooooo.... Using SerialUSB instead of Serial is how one accesses the second USB port? I've never looked into using that one yet but that would be a perfectly acceptable solution for this application.
Regards,
Ray L.
Yes, you can replace Serial with SerialUSB and it will use the native port instead of the programming port. The biggest difference here is that it will not wait for the SerialUSB port ever so immediately upon start up the sketch will go and you can connect and disconnect as the sketch is running. You will only get the data sent while you are connected (and perhaps shortly before you connected).
Collin80:
Yes, you can replace Serial with SerialUSB and it will use the native port instead of the programming port. The biggest difference here is that it will not wait for the SerialUSB port ever so immediately upon start up the sketch will go and you can connect and disconnect as the sketch is running. You will only get the data sent while you are connected (and perhaps shortly before you connected).
Great! I'll give it a shot. Thanks!
Regards,
Ray L.
Hmmmm.... Can't get SerialUSB to work right. Granted, it's a very complex program 
:
#include <arduino.h>
void setup()
{
Serial.begin(115200);
SerialUSB.begin(9600);
}
void loop()
{
while (Serial.available())
{
char c = Serial.read();
Serial.print(c);
SerialUSB.print(c);
}
while (SerialUSB.available())
{
char c = SerialUSB.read();
SerialUSB.print(c);
Serial.print(c);
}
delay(1000);
}
Programs fine, I open a Serial monitor window on COM5 (== Due programming port), and another on COM8 (== Due native port). Whatever I type into the COM5 monitor is echoed back correctly to both monitors. Whatever I type into the COM8 monitor disappears into the ether.
Also seems odd I can't program the Due when the native port is connected. It complains there is no device on COM5.
Regards,
Ray L.