RingIO is limited to 64kB
Description
Discussion: https://github.com/micropython/micropython/pull/9458#issuecomment-2581252345
Currently RingIO is limited to creating ring buffers of 64kB by the use of the following uint16_t variables in ringbuf.h:
typedef struct _ringbuf_t {
uint8_t *buf;
uint16_t size;
uint16_t iget;
uint16_t iput;
} ringbuf_t;
The suggestion is to change these to uint32_t to allow for >64kB ringbuffers. This would only be useful in ports with more than 64kB of heap available, so it may be worthwhile having different versions for different ports.
Or maybe the extra 6 bytes is acceptable across all ports for the sake of simplicity/consistency?
I note that other structures (like bytearray) don't have a 64kB limit, so this would seem to be some sort of precedent for changing the limit.
Code Size
This change would add 6 bytes to RAM usage whenever RingIO is invoked
Implementation
I hope the MicroPython maintainers or community will implement this feature
Code of Conduct
Yes, I agree
stm32/usb_cdc: Double data speed sending from micropython to computer
stm32/usb_cdc: Fix tx ringbuffer to remove full == size-1 limitation.
The current usb virtual serial port tx ringbuffer is 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 this is sent though, 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. So in large streaming transfers, watching the usb sniffer you basically get alternating 1023 byte packets then 1 byte packets.
By switching the ringbuffer to the different scheme that doesn't have the full limitation, we can get constant 1023 packets.
For a simple explanation of the two schemes, look at the first and last implementations discussed here: https://www.snellman.net/blog/archive/2016-12-13-ring-buffers/
Note: I have not merged this with the circular buffer from ringbuf.h due to the need to read from the buffer in chunks rather than single bytes, as well as the de-coupled copy of the read pointer.
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.