libusb_stm32
libusb_stm32 copied to clipboard
dmitrystu
Double buffer documentation
It would be interesting to have a demo or docs for the "not real" doublebuf functionality. Currently I have no idea how to use it - it didn't work when I simply "tried switching it on"
The double-buffered feature can be applied to the bulk endpoint only. In this mode, the endpoint will not be NAKed after receive and will use a secondary buffer when core reads received data from the primary buffer. There is no any special double-buffer mode for the OTGFS. This feature is implemented 'by design'. This option just doubles TX FIFO for the bulk endpoint. With DEVFS you can configure a bulk EP as double-buffered, but you can't use the same physical endpoint for both IN and OUT. This is the limitation of the DEVFS and driver for the doublebuffered bulk or isochronous endpoints. Therefore the EP setup in the demo code is illegal for use with double-buffered bulk transfer.
// OK for the doublebuffered
#define CDC_EP0_SIZE 0x08
#define CDC_RXD_EP 0x01
#define CDC_TXD_EP 0x82
#define CDC_DATA_SZ 0x40
#define CDC_NTF_EP 0x83
#define CDC_NTF_SZ 0x08
#define HID_RIN_EP 0x84
#define HID_RIN_SZ 0x10
PS. I see no difference in the serial speed test for both configurations (single-buffered and double-buffered). Need to check transfers on the bus with the logic analyzer.
Why do you automatically double the buffer for the isochronous endpoint? It seems to me that a separate USB_EPTYPE_DBLBUF option for an isochronous endpoint would be appropriate.
According to chapter 32.5.4 "RM0367 Reference manual Ultra-low-power STM32L0x3 advanced ARM ® -based 32-bit MCUs" (same for the other DEVFS) isochronous endpoints are always doublebufered. For the OTGFS based devices, I kept this for behavioral compatibility.
@dmitrystu: Regarding the "not real" double buffered functionality... Is this a limitation of the OTGFS USB core? Is it because it is not possible to put additional data into the TX FIFO while the endpoint is transmitting?
