LeafLabs Garden » Topic: SerialUSB flow control

LeafLabs Garden » Topic: SerialUSB flow control http://forums.leaflabs.com/topic.php?id=13641 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:43 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php ala42 on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-29456 Sat, 07 Sep 2013 09:27:08 +0000 ala42 29456@http://forums.leaflabs.com/ > 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. mlundinse on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-29130 Fri, 06 Sep 2013 18:45:30 +0000 mlundinse 29130@http://forums.leaflabs.com/ 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 (<a href="http://forums.leaflabs.com/topic.php?id=13461" rel="nofollow">http://forums.leaflabs.com/topic.php?id=13461</a>) 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 SevenW on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-29129 Fri, 06 Sep 2013 16:44:06 +0000 SevenW 29129@http://forums.leaflabs.com/ 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. <pre><code>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);</code></pre> Actually my test is a little more elaborate. The nice (int) cast is to avoid the millis overflow issue every fifty days. Ser = SerialUSB: <pre><code>#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);</code></pre> ala42 on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-28920 Thu, 05 Sep 2013 20:35:38 +0000 ala42 28920@http://forums.leaflabs.com/ >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 SevenW on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-28919 Thu, 05 Sep 2013 18:16:45 +0000 SevenW 28919@http://forums.leaflabs.com/ @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: <pre><code>while (SerialUSB.pending()) delayMicroseconds(50); SerialUSB.print(buffer); // or SerialUSB.write(buffer); while (SerialUSB.pending()) delayMicroseconds(50); SerialUSB.write('\n');</code></pre> This does not work: <pre><code>while (SerialUSB.pending()) delayMicroseconds(50); SerialUSB.println(buffer);</code></pre> 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. mlundinse on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-28918 Thu, 05 Sep 2013 13:14:02 +0000 mlundinse 28918@http://forums.leaflabs.com/ 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. SevenW on "SerialUSB flow control" http://forums.leaflabs.com/topic.php?id=13641#post-28846 Thu, 05 Sep 2013 06:46:30 +0000 SevenW 28846@http://forums.leaflabs.com/ 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);