> -----Original Message----- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Wednesday, August 26, 2020 3:34 PM > You must be using an STM32, right? The USB host on STM32 is garbage.
No, I'm using a Kinetis K28 with EHCI, and I'm sure that problem is by design of the serial drivers: It's not a problem of bandwidth I'm encountering, it's just a problem of number of work queue threads. Both the CDC and the FT232R call DRVR_TRANSFER from a (virtual) endless loop inside the usbhost_rxdata_work function. That means they are most of the time waiting on a semaphore, but they block the work queue thread. So the workaround is increasing the number of LPWORK threads (as you mentioned). But at least for FT232R there's another problem: Since the usbhost_rxint function reschedules work regardless rx_datawork already running, I managed to eat up one work queue thread after the other by quick small reads from the fd. When rxint is called twice (disable/enable) during usbhost_rxdata_work waiting, you will have another thread blocked on a semaphore, and so on... So either we need an additional synch mechanism or we use dedicated threads. Long story short: I will file my PR for the FT232R driver in the next days. As soon as it is accepted I will rework the CDCACM as well. Johannes
