Small question about HID USB device

In above post, the first packet is passed to IN EP using USB_WriteEP() in the OUT EP ISR.
This scheme is fine when it doesn't take so much time to generate the input report. But if it takes so long, waiting in the ISR is not a good idea. In such case, USB_WriteEP() moves to elsewhere, at the place where the report generation finishes.

Suppose that the request orders 64 x 2 bytes samples from ADC, starting at the arrival of the request.
- The parser on the OUT EP ISR starts ADC. The ISR just finishes.
- In the ADC ISR, the report buffer is filled one sample by one.
- In the ADC ISR, USB_WriteEP() is called for the first packet, when the 64th sample is filled to the buffer.
- The second packet is sent in the IN EP ISR, like above.

In this way, you can move USB_WriteEP() to anywhere, on the place it fits best.

Similarly, USB_ReadEP() is placed on anywhere.
Suppose that your firmware doesn't want to be disturbed by the next request, until current process finishes.
- In the OUT EP ISR, just raise a flog, without calling USB_ReadEP().
- The flag is checked in timer-ed polling or main-loop polling, when current process finishes. In this polling routine, USB_ReadEP() is called to starts next process.

While the OUT endpoint is occupied by the last packet, the USB engine returns NAK (not ready) to the host. Host waits until the endpoint becomes empty (NAK flow control). No packet is lost.



When you move USB_ReadEP() and/or USB_WriteEP() out of the endpoint ISR, you have to care of atomic access of these functions, so as not to re-enter to these routines each other. USB_ReadEP() and USB_WriteEP() are used in the several part of USB ISR in the USB stack.

In above post, the first packet is passed to IN EP using USB_WriteEP() in the OUT EP ISR.
This scheme is fine when it doesn't take so much time to generate the input report. But if it takes so long, waiting in the ISR is not a good idea. In such case, USB_WriteEP() moves to elsewhere, at the place where the report generation finishes.

Suppose that the request orders 64 x 2 bytes samples from ADC, starting at the arrival of the request.
- The parser on the OUT EP ISR starts ADC. The ISR just finishes.
- In the ADC ISR, the report buffer is filled one sample by one.
- In the ADC ISR, USB_WriteEP() is called for the first packet, when the 64th sample is filled to the buffer.
- The second packet is sent in the IN EP ISR, like above.

In this way, you can move USB_WriteEP() to anywhere, on the place it fits best.

Similarly, USB_ReadEP() is placed on anywhere.
Suppose that your firmware doesn't want to be disturbed by the next request, until current process finishes.
- In the OUT EP ISR, just raise a flog, without calling USB_ReadEP().
- The flag is checked in timer-ed polling or main-loop polling, when current process finishes. In this polling routine, USB_ReadEP() is called to starts next process.

While the OUT endpoint is occupied by the last packet, the USB engine returns NAK (not ready) to the host. Host waits until the endpoint becomes empty (NAK flow control). No packet is lost.



When you move USB_ReadEP() and/or USB_WriteEP() out of the endpoint ISR, you have to care of atomic access of these functions, so as not to re-enter to these routines each other. USB_ReadEP() and USB_WriteEP() are used in the several part of USB ISR in the USB stack.