Re: [libusb] USB Data gets scrambled ...

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

Günther Sohler wrote:
>> You're never going to miss anything.  The device can't send anything
>> until you send a read request.
> Yes, basically I  agree on your point.
>
> Its just the fact, that my firmware is based on a HID Mouse Sample code from CMX
> In the Main loop, this function is called:
> ...
>   
>   for(x=0; x<sizeof(reports)/sizeof(reports[0]); x++)
>   {
>     if(reports[x].used 
>        && reports[x].pending     
>        && reports[x].type==rpt_in)
>     {
>       usb_send(HID_IT_EP_NDX, (void *)0
>                , reports[x].buffer
>                , reports[x].size
>                , reports[x].size);
>       while(usb_ep_is_busy(HID_IT_EP_NDX))
>         ;
>       reports[x].pending=0;
>       break;
>     }
>   }         
> }
>
>
> This function sends HID Report IN Data to the host IRRESPECTIVE if the host asked the device to send it before.

No, it doesn't.  This function will only be called when the device has
received a "GetReport" request.  "usb_send" blocks until the transfer is
complete.  If you call this on your own, outside of the normal
processing, it will block until a read request is received.

I'm surprised this microprocessor works this way.  Most microprocessors
are WAY too slow to handle USB transfers in real-time like this.


> In my firmware I want to get rid of this code section, but without it just does not work.

How do you expect to send the reports, then?  You could certainly use
your own buffer to hold the pending outgoing reports, but you still need
something at interrupt time to call usb_send to do the physical transfer.


> Using "SimpleHidWrite" from the Web page of Jan Axelson I understand there are to distinct types of IN Reports:
> Those which are requested by the "Read" button, and those which come in automatically.

No.  There is only one kind of IN request.  The operating system HID
driver typically queues up a couple of IN requests at startup.  When one
is completed, it sends the report up and resubmits the request.  What
happens to those reports after they are in the host is beyond the scope
of USB.


> OK the two "tasks" happening are
>
> * the host learns about the connected device by reading all its attributes(proprietary information)
> * the device indicates a changed value and sends a notice. this triggers another task , so the host is interested in the new value and reads it.

Again, the device cannot send a notice unless the host asks for it.  Are
you mixing non-HID transfers with HID?  Or is that "proprietary
information" being sent as another input report?

 
> Of course these two tasks are not simultaniuosly, but their messages are somehow interleaved on the "channel"

OK, but that's almost certainly happening in the device, not in the
host.  The USB driver stack is quite competent at keeping multiple
transfers separate.

 
> For sake of completeness, find attached the write code:

Output reports are sent on a different endpoint.  What does your device
do with these output reports?  Are you generating another input report? 
Do you have enough buffer space to hold those until the next call to
hid_process?

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