Sie sind nicht angemeldet.

Anmelden
Diese Seite kann nicht editiert werden.
 
 
 

Feature Report Protocol

Von $1

    Inhaltsverzeichnis
    Um zurückzugehen, müssen die aktuelle und die ältere Version mit Hilfe der Historie verglichen werden.

    Kombinierter Revisionsvergleich

    Vergleich der Version vom 20:40, 6 Mar 2015 von stephan mit der Version modifiziert am 18:41, 7 Mar 2015 von stephan.

    ...

    Feature Report Length & Report IDNote about Leading Zero

    All in and out feature reports are 64 bytes long, without any exception. Do not send a different number of bytes.When using the Microsoft UsbHid implementation, there is a leading zero as the first byte of each feature report. This byte

    But be aware of the Feature Report ID. On MS Windows based systems, this ID normally is simply prefixed to the actual feature report data. Therefore the feature report data actually sent/received is one byte longer than described in the command descriptions below, which don't include it, as it'sis returned with every in report and is required in every out report. This byte is not part of the payload and can not be used for anything. We did not remove it in the implementation of the Demo, to make you aware of this. But it is not documented in the Command descriptions below, as it is not part of the protocol.

    Currently we are not using the USB Feature Report In different implementations of UsbHid this will be different. IDs, therefore this byte is always 0x00.So, be aware that when using MS Windows, compared to

    To conclude:this

    • If your USB stack requires the Report ID to be included with the report data, always send 65 bytes. First byte is 0x00 and Command starts at second byte.documentation, you will additionally be receiving a leading zero in front of each in report and will be required to additionally prefix a leading zero in front of
    • Otherwise send and receive 64 each of your out reports!bytes.

    ...

    Version vom 20:40, 6 Mar 2015

    Diese Revision wurde von stephan (Sperren) verändert

    ...

    Note about Leading Zero

    When using the Microsoft UsbHid implementation, there is a leading zero as the first byte of each feature report. This byte is returned with every in report and is required in every out report. This byte is not part of the payload and can not be used for anything. We did not remove it in the implementation of the Demo, to make you aware of this. But it is not documented in the Command descriptions below, as it is not part of the protocol. In different implementations of UsbHid this will be different.

    So, be aware that when using MS Windows, compared to this documentation, you will additionally be receiving a leading zero in front of each in report and will be required to additionally prefix a leading zero in front of each of your out reports!

    ...

    Version seit 18:41, 7 Mar 2015

    Diese Revision wurde von stephan (Sperren) verändert

    ...

    Feature Report Length & Report ID

    All in and out feature reports are 64 bytes long, without any exception. Do not send a different number of bytes.

    But be aware of the Feature Report ID. On MS Windows based systems, this ID normally is simply prefixed to the actual feature report data. Therefore the feature report data actually sent/received is one byte longer than described in the command descriptions below, which don't include it, as it's not part of the protocol.

    Currently we are not using the USB Feature Report IDs, therefore this byte is always 0x00.

    To conclude:

    • If your USB stack requires the Report ID to be included with the report data, always send 65 bytes. First byte is 0x00 and Command starts at second byte.
    • Otherwise send and receive 64 bytes.

    ...

     
    © Simple Solutions  •  Impressum  •  Wiki powered by Mindtouch