e4fcd216e0
Before this commit the USB VCP TX ring-buffer used the basic implementation where it can only be filled to a maximum of buffer size-1. For a 1024 size buffer this means the largest packet that can be sent is 1023. Once a packet of this size is sent the next byte copied in goes to the final byte in the buffer, so must be sent as a 1 byte packet before the read pointer can be wrapped around to the beginning. So in large streaming transfers, watching the USB sniffer you basically get alternating 1023 byte packets then 1 byte packets. This commit changes the ring-buffer implementation to a scheme that doesn't have the full-size limitation, and the USB VCP driver can now achieve a constant stream of full-sized packets. This scheme introduces a restriction on the size of the buffer: it must be a power of 2, and the maximum size is half of the size of the index (in this case the index is 16-bit, so the maximum size would be 32767 bytes rounded to 16384 for a power-of-2). But this is not a big limitation because the size of the ring-buffer prior to this commit was restricted to powers of 2 because it was using a mask-based method to wrap the indices. For an explanation of the new scheme see https://www.snellman.net/blog/archive/2016-12-13-ring-buffers/ The RX buffer could likely do with a similar change, though as it's not read from in chunks like the TX buffer it doesn't present the same issue, all that's lost is one byte capacity of the buffer. USB VCP TX throughput is improved by this change, potentially doubling the speed in certain cases. |
||
---|---|---|
.. | ||
bare-arm | ||
cc3200 | ||
esp32 | ||
esp8266 | ||
javascript | ||
mimxrt | ||
minimal | ||
nrf | ||
pic16bit | ||
powerpc | ||
qemu-arm | ||
samd | ||
stm32 | ||
teensy | ||
unix | ||
windows | ||
zephyr |