LeafLabs Garden

A place to share, learn, and grow...

1. 

   SevenW
   Member

   I have a small application that on request can echo the content of a log file through SerialUSB to a Raspberry Pi. The problem is that I loose some of the lines sent. Before diving too deep into linux cdc-acm drivers or the node.js serialport implementation I want to see whether the issue is on the maple side of things.

   Is HW handshaking always handled by the USB layer, or do I take care of it in my applicaiton program? Now I loop over the file, and per line I call:

   SerialUSB.println(msg);

   I loose about 12 lines of 140 lines per second, which BTW is due to a periodic task performed at the receiver side.

   Should I check on RTS myself?

   if SerialUSB.getRTS()
   SerialUSB.println(msg);

   Posted 2 years ago #
2. 

   mlundinse
   Member

   The low level USB has hardware handshaking on both host and device as part of the basic USB protocol. The host, your Pi, will only request the next USB IN packet when the USB drivers are ready to receive them.

   The receiving application must be able to handle the incoming packets from the kernel USB drivers, or the serial buffers can overflow and data will get lost.

   On the Maple side data can get lost if the host doesn't ask for IN packets, then the USBSerial::write() will timeout and silently drop the data. On Maple you can use SerialUSB.pending() to check that the IN buffers are empty and ready to receive more data.
   This will not help if the USB serial kernel drivers on the host overflows before your application can handle the data.

   It is possible to use the virtual RTS line to implement serial protocol handshaking. On the host it is controlled in the same way as a hardware RTS line, on Maple you can check the status of RTS with SerialUSB.getRTS() before sending any more data.

   Posted 2 years ago #
3. 

   SevenW
   Member

   @mlundinse: Thanks for the pointers. After a lot of experimenting I concluded that RTS was not laying a role, but the pending state did. It looks like I have the connection reliably working. There might be issues on the maple side, but I am not sure.

   This works:
   

   while (SerialUSB.pending()) delayMicroseconds(50);
   SerialUSB.print(buffer); // or SerialUSB.write(buffer);
   while (SerialUSB.pending()) delayMicroseconds(50);
   SerialUSB.write('\n');

   This does not work:
   

   while (SerialUSB.pending()) delayMicroseconds(50);
   SerialUSB.println(buffer);

   The SerialUSB.pending() is essential. I did not experiment a lot with the delay.

   The newline thing is very strange. It differs in that println sends \r\n, where I send \n only.

   Posted 2 years ago #
4. 

   ala42
   Member

   >The newline thing is very strange. It differs in that println sends \r\n, where I send \n only.
   While this is a difference, it is not important. The main difference is that println sends three data blocks, the buffer, CR, LF. Each block write has a timeout of 50ms, after which the data is lost.
   To increase the timeout of currently 50ms change the line
   #define USB_TIMEOUT 50
   in usb_serial.cpp

   Posted 2 years ago #
5. 

   SevenW
   Member

   OK, println() resutls in three calls to write. Despite testing on SerialUSB.pending(), for the second or third call to write(), pending() may have become true. In usbserial.cpp this has resulted in a timeout. So besides increasing the timeout in usbserial, I could handle the CRLF myself and do a single call to write.

   buffer[i++]='\r';   //append '\r'
   buffer[i++]='\n';   //append '\n'
   buffer[i]=(char)0;  //write c-style string termination
   
   while (SerialUSB.pending()) delayMicroseconds(50);
   SerialUSB.write(buffer);

   Actually my test is a little more elaborate. The nice (int) cast is to avoid the millis overflow issue every fifty days. Ser = SerialUSB:

   #define SER_TIMEOUT 10000 //10s timeout for USB communication
   
   uint32 start = millis();
   while ((Ser.pending() || !Ser.getRTS() || !Ser.getDTR()) &&
          ((int)(millis() - start) < SER_TIMEOUT)) delayMicroseconds(50);
   Ser.write(buffer);

   Posted 2 years ago #
6. 

   mlundinse
   Member

   The major problem as ala points out is that every print command can be turned into
   several low level usb write commands. And every low level command is sent as a separate
   transaction and if the previous transaction is not sent in time it silently fails.

   There is a new experimental usb_serial code (http://forums.leaflabs.com/topic.php?id=13461)
   that has a 64 byte buffer that can be filled while the previous transaction is beeing sent, or is waiting for the host to get ready.

   At the moment the pending call reflects the number of bytes in the PMA (hardware) buffer and not the number of bytes in the write buffer. But it might help and testing is welcome.

   Regards
   Magnus

   Posted 2 years ago #
7. 

   ala42
   Member

   > The nice (int) cast is to avoid the millis overflow issue every fifty days.
   No, it makes no change at all. Subtracting two unsigned values just works out of the box.
   As an example 0x10 - 0xfffffff0 is 0x20, no matter to what you cast this result later.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.