Hello, 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. Johannes
