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?
Deferring USB control requests reply on application thread?
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Deferring USB control requests reply on application thread?
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
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
Re: Deferring USB control requests reply on application thread?
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Deferring USB control requests reply on application thread?
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
All callbacks are called from ISR context, you cannot defer handling to a thread because the callback is supposed to decide "next step".
Giovanni
Who is online
Users browsing this forum: No registered users and 13 guests