Deferring USB control requests reply on application thread?

[nono240]

I'm building an USB frontend to some kind of (SPI) chipset and I'm planning to implement some non standard (control) requests through EP0 to expose some chipset registers ; keeping EP1 for bulk data. Currently, from my understanding, the USB requests hook is supposed to call usbSetupTransfer() macro before returning true. Since those custom control requests are going to write (or read) a few bytes through the SPI, I'd rather do that from a "server thread" handling the I/O.

Is it possible in some way or shall I have to move those requests to non-control endpoints?

[Giovanni]

Hi,

The driver is designed to handle EP0 with a state machine, moving requests to a dedicated thread is not possible. You may use another endpoint or handle messages on EP0 using the provided callbacks.

Giovanni

[nono240]

Yes, using the provided callbacks is what I meant, but I'm assuming they're called in a ISR context, right? So I'm not able to use the synchronous message API, and doing SPI from an interrupt context (concurrently with a thread) sounds not so great

[Giovanni]

Hi,

All callbacks are called from ISR context, you cannot defer handling to a thread because the callback is supposed to decide "next step".

Giovanni