Re: [libusb] OT problem with PIC18F45K50 homebrew USB-stack

[Tim R. <ti...@pr...>]

On 6/10/24 9:41 AM, Kustaa Nyholm wrote:

>
> The messages (reports) are not buffered on the host side either way. 
> If this is the wrong
> assumption I have to think if there is a situation in which the above 
> message counter logic
> would fail and dead lock.
>
Schemes like that are rather delicate.  You have to be very careful to 
make sure you can handle a dropped packet. Theoretically, an interrupt 
pipe should retry if there is an error, but nothing is perfect.


> On other could be if the input reports are buffered and if poll() only 
> ‘returned true’ once
> for multiple buffered messages. I don’t see how that could happen 
> either, but again this
> smells.
>
> So I guess the questions I would like to know answer to are:
> 1) Are the input/output reports buffered on the host side?
> 2) Can poll indicate that there is data to read only once for multiple 
> input reports?
>
In general, there is no buffering anywhere in the USB stack.  If there 
are no outstanding requests from applications, then the device stays 
idle and is not given a chance to transmit/receive.

With HID devices, it's a little more complicated, because things are 
optimized for keyboards.  Depending on which request you use, the HID 
subsystem can read one entry ahead and keep it for you.


> Control requestsare handled in the USB interrupt and as they involve 
> only EP0
> they should not muck up the EP2 handling in the mainloop?
>
Yes, that's how it should to work.

-- 
Tim Roberts,ti...@pr...
Providenza & Boekelheide, Inc.