CODEWITHSUNDEEP
pythoncserial-portusbarduino
dgrat
dgrat

Reputation: 2254

Arduino serial timeouts after several serial writes

I noticed with my board from DIY drones a strange behavior when I use my custom firmware. Here is an example function which is called in my firmware running on an Arduino board:

void send_attitude(float roll, float pitch, float yaw) {
  hal.console->printf("{\"type\":\"sens_attitude\",\"roll\":%.4f,\"pitch\":%.4f,\"yaw\":%.4f}\n",
                      roll, pitch, yaw);
}

As you can see, the code just writing a message in the serial port set in setup (hal.uartA). I call this function every 0.5s:

 inline void medium_loop() {
  static int timer = 0;
  int time = hal.scheduler->millis() - timer;

  // send every 0.5 s
  if(time > 500) {  
    send_attitude(OUT_PIT, OUT_ROL, OUT_YAW);

    timer = hal.scheduler->millis();
  }
}

Now to the strange thing. If I use the serial monitor or read the board with another program or script everything is fine. Every 0.5s the proper LED is blinking and message is shown. But if I don't read it out, after appr. 10s the LED is flushing up continuously and no connection/communication is possible anymore. I have to unplug the board then. The same behavior is observed the other way round. If I send to my board over serial port (in my case USB) and don't flush the input buffer, the LED is flushing up continuously and I get a timeout. The following code works:

def send_data(line):
  # calc checksum
  chk = chksum(line)
  # concatenate msg and chksum
  output = "%s*%x\r\n" % (line, chk)
  try:
    bytes = ser.write(output)
  except serial.SerialTimeoutException as e:
    logging.error("Write timeout on serial port '{}': {}".format(com_port, e))
  # Flush input buffer, if there is still some unprocessed data left
  # Otherwise the APM 2.5 control boards stucks after some command
  ser.flush()       # Try to send old message
  ser.flushInput()  # Delete what is still inside the buffer

If I comment out this line:

ser.flushInput()  # Delete what is still inside the buffer

I don't use more settings then this. I get (depending on the message interval) a timeout sooner or later. In my case I send every 20ms a signal which results in a timeout after ~10s. Also dependent on the length of message. Bigger messages cause it faster than smaller ones.

My settings are shown in the following snippets. Client side python code:

com_port  = '/dev/ttyACM0'
baud_rate = '115200'
try:
  ser = serial.Serial(com_port, baud_rate, timeout=0.1, writeTimeout=0.1, rtscts=1)

The if these timeouts happen, then I also get one if I set the timeout to something like 2s. In my case I need a very low latency, which is indeed possible if I keep reading and flushing. Firmware code from my Arduino:

void setup() {
  // Set baud rate when connected to RPi
  hal.uartA->begin(115200);
  hal.console->printf("Setup device ..\n");
  // Followed by motor, compass, barometer initialization

My questions are:

The complete source code is @google code: https://code.google.com/p/rpicopter/source/browse/

Upvotes: 2

Views: 3197

Answers (3)

David Grayson
David Grayson

Reputation: 87476

What board are you using and what processor does it have? My guess would be that your board is based on the ATmega32U4, or some other microcontroller that has a built-in USB module. If so, I have seen similar behavior before here is what I think is happening:

There is a buffer on your microcontroller to hold serial data going to the computer. There is a buffer in the computer's USB serial driver to hold serial received from the chip. Since you are not reading bytes from the COM port, the buffer on the computer will fill up. Once the buffer on the computer fills up, it stops requesting data from the microcontroller. Therefore, the buffer on the microcontroller will eventually fill up.

Once the microcontroller's buffer is full, how do you expect printf command to behave? For simplicity, the printf you are using is probably designed to just wait in a blocking loop until buffer space is available and then send the next character, until the message is done. Since buffer space will never be available, your program gets stuck in an infinite loop.

A better strategy would be to check to see if enough buffer space is available before calling printf. The code might look something like this:

if(console_buffer_space() > 80)
{
    hal.console->printf(...);
}

I don't know if this is possible in the DIY drones firmware, and I don't know if the max buffer space can actually ever reach 80, so you will have to research this a bit.

Upvotes: 2

dgrat
dgrat

Reputation: 2254

It looks like other people have the same problem. And thanks to the Mod-Braniac who deleted my minimal example. My bet is, that's a problem with Arduino USB controller chip or the firmware on it.

Upvotes: 0

Kobi K
Kobi K

Reputation: 7931

I don't understand the use of:

ser.flush()       # Try to send old message
ser.flushInput()  # Delete what is still inside the buffer

Lets say your device is connected to PC and the python code is writing the (line, chk):

ser.flush() - why are you using it? ser.flushInput() - will "delete" the Serial input buffer at the PC

Upvotes: 0

Related Questions