0

I have a simple method that simply waits for an input, computes a response, and sends it:

void loop() { 
  if (Serial.available() > 0){
    input = Serial.read();

    if (input == 10){
      digitalWrite(trigPin, LOW);
      delayMicroseconds(2);
    
      digitalWrite(trigPin, HIGH);
      delayMicroseconds(10);
      digitalWrite(trigPin, LOW);
    
      duration = PulseDuration(echoPin, HIGH, 6000);
      distance = duration * 0.00034/2;  // 0.00034 m/us is speed of sound

      Serial.println(distance, 4);
      }
  }
}

My question: What happens to the arduino if I close the serial connection from the receiving end while it's printing out data (in the last line of the loop)?

Context and motivation:

The program works well most times. I can open a python program that sends the requests and prints out the reply using pyserial. After I close the python side and reopen it, connection is set and I can start listening on the side nicely just like the first time. Sometimes, however, when I try to restart the python program, I get a connection error saying that the port is already opened (I'm running in Windows.. there are tons of posts about this problem, but none of them have been helpful). Some other times, when connecting with the python program (which connects with connection = serial.Serial(self.arduino_port, 9600, timeout=0) it just blocks and doesn't connect, it doesn't give the "port already opened" error, and it doesn't advance to the next statement. I am confident I did close the previous python run before attempting a new one (process explorer shows no active python programs running, it also shows no open processes using a serial handler). I'm not here to solve that problem directly, though, just to ask a related question.

I'm also confident running connection.close() does not terminate the arduino program, as I have been able to restart my python program without having to reset the arduino or anything, suggesting the arduino kept running its loop after I closed the connection on the python side.

All that to say that my latest hypothesis is that these issues arise when I close the serial connection connection.close() while the arduino is printing, but because the port is closed, that Arduino is stuck and cannot do the Serial.println(), as the USB never asks to flush the data in its buffer. Is this possible/does it make sense? What happens to the arduino if I close the serial connection while it's printing out data?

I'm not posting my python program here as it's not directly relevant to the question and I can't seem to make a minimum reproducible program that doesn't expose confidential code.

5
  • Which Arduino? Please tag your question with that information. There are lots of Arduino models, and some have different ways of interfacing with USB than others.
    – Nick Gammon
    Apr 13, 2021 at 7:42
  • the question is not about Arduino
    – Juraj
    Apr 13, 2021 at 7:46
  • @NickGammon It's an Arduino/Genuino 101
    – polortiz4
    Apr 13, 2021 at 7:49
  • @Juraj He is asking what the Arduino does if the serial connection is closed so I think that is a relevant question. However the bulk of the question appears to be about the behaviour of Windows.
    – Nick Gammon
    Apr 13, 2021 at 7:52
  • Yeah, I wanted to explain why I wanted to know what the arduino did, and perhaps got too much into the weeds of my overall problem (sorry), when all I wanted is to know what happens when the arduino tries Serial.println(..) while the other end is disconnecting.
    – polortiz4
    Apr 13, 2021 at 7:53

1 Answer 1

0

That's some strange Intel monstrosity. It's impossible to know what it does or how. Intel's foray into the Arduinosphere was brief and somewhat abortive.

In general though (for most cores) the DTR signal (and sometimes the RTS signal too) of the CDC/ACM protocol is used to "gate" the serial data - if it's asserted then serial data gets sent through to the host PC. If it's not asserted then it just gets thrown away.

I have seen cores where if DTR is not asserted the data gets buffered until the TX buffer is full and then blocks, but that is rare.

You might find your answer if you delve into the core's source code, but you may find that big chunks of it are hidden away in closed source pre-compiled libraries, and the fact it seems to run some custom RTOS means it'll be even more obfuscated. YMMV...

5
  • or try it .....
    – Juraj
    Apr 13, 2021 at 12:00
  • Thank you @Majenko, that is helpful.
    – polortiz4
    Apr 13, 2021 at 17:32
  • @Juraj, try what? I already am trying something (described in the post) and observing some behavior. I asked this question to see if my reasoning for said observation made sense. If you have suggestions for lower level tests to understand the behavior in this scenario, I’m all ears. I don’t know how to go lower level than what I’m doing now. How can I see the result of the arduino code if the test itself is to disconnect its serial communication? How can I tell whether the arduino is blocking or running its loop if I can’t re-connect to it?
    – polortiz4
    Apr 13, 2021 at 17:41
  • 1
    @polortiz4, add Serial printing to the Blink sketch.
    – Juraj
    Apr 13, 2021 at 17:49
  • Hmm that’s a good and simple idea. Thanks
    – polortiz4
    Apr 13, 2021 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.