How to implement back-pressure Flow control with ROM driver, RegisterEpHandler(,,,) for BULK_OUT,

[lpcware]

Content originally posted in LPCWare by larsen on Wed Jan 02 09:08:12 MST 2013
I am trying to figure out how I can postpone the buffer read after the callback VCOM_bulk_out_hdlr has given a an event of type USB_EVT_OUT. I want to hold back the host until the downstream channel has room for the data, but I dont want to idle inside the callback nor to buffer-up in yet a buffer layer. The callback is running at interrupt priority. I.e. ReadEP() function should be run later (and at task priority). Is that possible?

Returning ERR_USBD_UNHANDLED in the callback. Will that hold back the host for sending new data until the present ones are read? If yes, will reading the out data using ->ReadEP(hUsb, USB_CDC_EP_BULK_OUT, &buffer) actually unblock the host (sending ACK's) when more data arrives?

By the way, in reading the code comments with the fine looking-glass I found the following surprising information:

The RegisterEpHandler() in the ROM driver assigns a callback for users application. In the typedef for this callback the comments says among other
/**
....
*  The application layer should define the custom class's <B>EP0</B> handler with function signature.
*/
Why does it say EP0 (which I translate to EndPoint_Zero)? I would expect it to read simply 'EndPoint'. Is the code comment really true in which case I dont understand how the code should operate.

Thanks for any advice you may have

[lpcware]

Content originally posted in LPCWare by larsen on Wed Jan 02 14:47:35 MST 2013
ok I think I can answer one of my own questions: <B>Yes - returning ERR_USBD_UNHANDLED in the VCOM_bulk_out_hdlr callback will hold-back further data from the host, and subsequently reading the buffer with ->ReadEP(hUsb, USB_CDC_EP_BULK_OUT, &buffer)  in the worker thread, actually works nicely</B>. So the callback just sets a semphore "Data ready" in the timecritical raised interrupt level code section, and the consumer thread reads: first the semaphore, then the data.

As to the second part of my question about the code comments, I would like to have some comments - I think accurate documentation is important.