I now understand the SerialUSB timeout period concept

LeafLabs Garden » Support » Maple Hardware Support

I now understand the SerialUSB timeout period concept

(5 posts) (2 voices)

Started 4 years ago by StephenFromNYC
Latest reply from gbulmer

StephenFromNYC
Moderator

Hello-

I am starting this topic to help users who are new to USB data transfers to avoid the same misunderstanding I have had for the last few months.

On the document page:

http://leaflabs.com/docs/lang/api/serialusb.html#lang-serialusb it says:

Warning: The SerialUSB functionality includes a 50 millisecond timeout for writes

For several months I believe I completely misinterpreted the word "timeout". I had assumed the word "timeout" indicated there would be some type of error generated if the Maple tried to communicate and the host did not respond within the 50 milliseconds.

A few months ago I learned that the Maple prefers to communicate in packets of 64 bytes (chars). This uses the USB buffer most efficiently.

However, it was not until yesterday that I finally understood that the Maple waits to accumulate 64 bytes (which may require several calls to the SerialUSB.print() functions), but if 50 milliseconds elapse before 64 bytes are reached then fewer than 64 bytes are sent (using a partially empty packet).

This explains why my SerialUSB.println(analogRead(0)) data transfers were so slow.

I had assumed each time I used the SerialUSB function data was sent down the USB line. However, now I understand that several calls to SerialUSB may be made before data is sent down the USB line.

For fast SerialUSB transfers, gbulmer recommends creating a 64 character (64 byte) array, using bitwise math to split data into character (one byte) size chunks, copying these chunks into the 64 character array, and then after the array is full to use SerialUSB.write(buffername, 64) to send all 64 bytes efficiently as a single USB packet.

http://forums.leaflabs.com/topic.php?id=639&page=2#post-3694

When this is done timeouts are minimized.

The 64 byte buffer can be filled with different data types (1 byte characters, 2-byte analogReads which uses only 12-bits, etc.). gbulmer's efficient approach assumes an application on the host system understands how to recombine the 64 characters of data into the original data types. If you are sending only 12-bit analogReads (which you will split each into two chars) you can send 32 datapoints per USB packet.

I do not have an accurate estimate yet of my SerialUSB.write() data transfer rates, but I believe I am reaching between 100K bytes/sec and 200K bytes/sec, which is at least 100X faster than I was getting before.

On the Teensyduino platform, there is a function called: Serial.send_now() which does not exist on the Maple.

http://pjrc.com/teensy/td_serial.html

I do not need SerialUSB.send_now() (because of gbulmer's help), but other users may find this function helpful.

Thanks again (especially to gbulmer and mbolivar) and good luck with fast USB transfers.

Stephen from NYC

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - I think that is a good analysis and summary.

There are a bunch of edge cases, and I need to read the code, but one area where I think the implementation has varied, and may change is what happens when less/more than 64 bytes are written to the SerialUSB port.
I got the impression that some versions of the maple library always blocked when in the SerialUSB.print/println/write until all the bytes were sent, but I may be misunderstanding a Leafy-explanation.
We do need to know when SerialUSB.print/println/write block, as that may distort something like data sampling frequency.

Posted 4 years ago #
StephenFromNYC
Moderator

Hello,

I want to avoid spreading misinformation. Considering my bad track record with the USB timeout period concept I am not making any assumptions now.

Can someone please give a short definition of "blocking".

Thanks!

Stephen from NYC

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC -

Can someone please give a short definition of "blocking".

Skip down to the Short Summary for a quick explanation, and here is a fuller description.

When a function or method is called, e.g. write("Hello"), it could have several implementations.
Some examples (avoiding very exotic approaches):
1. The write function doesn't return until the write has completed. This is a blocking function. This is a nice simple approach, but does mean that the user program is stuck waiting. For ordinary code, this expected, but for Input and Output (I/O) subsystems, which may do a lot of the work autonomously, it can be quite wasteful. This can be especially wasteful of processor time if the processing of each character takes very little time, but the transmission time is quite long. For example, with a serial port, it may take significantly less than 1 microsecond to load a character into the hardware and start transmission, but, if the baud rate is, say, 9600baud, it will be over a millisecond before the next character can be loaded into the hardware, so the processor might be doing useful work for only 1 uSec in each mSec (there are some hardware optimisations, but that isn't the point).

2. The write function could return very quickly, having copied the characters to a 'safe' place, for example a buffer in memory. The actual I/O will happen later, whenever the system gets around to doing it, but the write function doesn't wait for this to happen. This is non-blocking. With simple serial I/O, this could be arranged by having an interrupt function which is called when the hardware is ready to send the next character. This is in contrast to the processor waiting until all the characters are sent. With non-blocking functions, your program would be delayed for very little time, and it could carry on working.

In this example, little pieces of processor time would be 'stolen' (invisibly) to send the characters out of the serial port, but the extra processing time available (using non-blocking I/O) would likely be very large compared to the loss in a blocking function.

There are shades of grey in this, with more sophisticated schemes, and some choice over what point the I/O gets to when it is considered 'done'.
A system might set aside 1Kbytes of 'safe' buffer space, where the data to be output is copied, and allow writes to be non-blocking as long as there is space available in that buffer, but blocking a write until the buffer has enough empty space (emptied by sending the data).
Also, it may be the DMA system sending the data, so when it is not blocking, all of the processor is available for the users program.

Short Summary
With blocking output functions, the called function (e.g. write) waits until the transfer is complete.
With non-blocking output functions the called function returns very quickly, and the users program can carry on even though the output may not complete for many milliseconds, or even seconds.

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - on "blocking":

It is more subtle than I wrote (above).
Arduino analogRead blocks until the value is read from the analogue to digital converter.
Arduino analogWrite does not block until the value takes effect. So it is possible to do several analogWrite's, and lose the effect of some of the analogWrite's because the code executes more quickly than the PWM hardware updates and acts on the PWM value.
Arduino Serial.print blocks until the last character (byte) is loaded into the USART (serial port), but that character won't have reached the Arduino USB chip at that point, further the USART to USB chip can hold onto 16 characters, for a millisecond or two before sending them to the host PC.
Maple's USB hardware is capable even more complex behaviour because it implements multiple communication channels.

The point is, their are a range of behaviours in the interaction between software libraries and hardware, and the exact point in time when something become 'un-blocked' can be complex.

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.