On 8/26/2020 7:28 AM, Gregory Nutt wrote:
A short question concerning the use of LPWORK queue in FT232R and
CDCACM USB Host drivers:
Both block one LPWORK task per opened instance permanently.
The FT232R rxdata_work USB transfer returns after each 16ms
(USBHOST_FT232R_LATENCY) but since there are always at least two
status bytes transferred it stays in the loop.
(And the worse, if I'm correct, it can happen that there are way more
than one LPWORK tasks blocked, because of race conditions.)
The CDCACM rxdata_work USB transfer doesn't even return as long there
are no bytes to transfer. At least with my connected Quectel EG25-G.
I can't imagine that this is the correct use of a shared resource
like work queues.
For the FT232R I did a rework that uses a dedicated rxdata task (and
because of "symmetry" a dedicated txdata task) per opened instance.
Does it make sense to file a PR? If that one would be accepted I
could rework the CDCACM driver accordingly.
On a side note:
I think PR #1624 is important (perhaps also for other EHCI Host
drivers), because without it, the Asynchronus Schedule can get out of
coherency in multi task accesses to EHCI.
Work queues are intended for small, brief bits of "work". If a driver
requires a dedicated thread for extended processing and for waiting,
then it should create its own dedicated thread using, perhaps, POSIX
message queues.
That said, you would work around this by declaring multiple LP work
queues so that others are available other uses. But I agree with you,
using a work queue thread as a dedicated thread is a misuse.
You must be using an STM32, right? The USB host on STM32 is garbage.
USB serial does suffer from this problem but only with STM32. Other
EHCI- and OHCI-based MCUs, it works fine; the driver does not return
until something is received on the downstream port. STM32 returns
immediately, thus hogging all of the work queue bandwidth.
Several people (including me) have tried to improve the STM32 USB host
behavior. Certainly it has improved, but it still sucks. It is just
bad IP.
