3 Replies Latest reply on Mar 3, 2020 4:00 PM by MiRo_263836

    Mutiple Report IDs in the PSOC5LP USB

    MiRo_263836

      The component data sheet mentions support for multiple Report ID’s, but outside of the device configuration variables (USBFS_DEVICEx_CONFIGURATIONx_INTERFACEx_ALTERNATEx_HID_FEATURE_BUF_IDx/RPT_SCB_IDx), I can't find specific information on how to handle this.  I would like to know if each report ID has a corresponding custom report handler (which could be user defined) linked to an interrupt vector table, or if the only immediate interrupt available is via the IN/OUT endpoints of the USB, at which point we would check the Report ID. 

       

      Any clarification regarding this would be much appreciated!

       

      Thank you.

      Mike Roberts

        • 1. Re: Mutiple Report IDs in the PSOC5LP USB
          MiRo_263836

          The current implementation of the GUI enabled PSoC project relies on checking the in/out data endpoints and enabling functions by setting control fields based on data received.  My thought is that it might be more efficient to send reports of a specific ID and having these ID’ed reports be mapped to specific function calls, thus eliminating the overhead of parsing the data to enable/disable control settings.  Please let me know if you need further clarity regarding this idea.

           

           

          • 2. Re: Mutiple Report IDs in the PSOC5LP USB
            EktaN_26

            Hello MiRo_263836 ,

             

            We require multiple Report ID's when we want only one HID descriptor, one HID report and one HID endpoint but need to handle two or more functionalities of the device.

             

            For example: a keyboard with an integrated mouse could independently report “key press” data and “pointing” data over the same endpoint. Report ID items are used to indicate which data fields are represented in each report. In this case we need to have ONLY ONE report descriptor with two COLLECTION APPLICATION items, one for the keyboard and the other for the mouse. In each of these collections you have to put a REPORT ID(N) item, with N=1 for the first collection and 2 for the second. Then, the first byte of the report must be the report id, and the remaining bytes must be their report information.

            If you use the Mouse for the first collection (N=1) and the Keyboard for the second (N=2), to report the Mouse state you should send 0x01 followed by the button flags and the axis data. To report the Keyboard state, you should send 0x02 followed by the alternate keys byte and then the keycodes.

             

            A Report ID item tag assigns a 1-byte identification prefix to each report transfer. If a device has multiple report structures, all data transfers start with a 1-byte identifier prefix that indicates which report structure applies to the transfer. This allows the class driver to distinguish incoming pointer data from keyboard data by examining the transfer prefix.

             

            In case of IN transfers this byte should be appended by the user in the firmware while loading the data to the endpoint.

             

            Example of such a HID Report is given in the image below:

             

            Can you please provide more details about your application and requirement for multiple report ID's?

             

            Regards

            Ekta

            • 3. Re: Mutiple Report IDs in the PSOC5LP USB
              MiRo_263836

              Regarding the report ID that is appended to the report data fields – this does not affect the report size and count, correct?  For example, if I design a report to be 64 bytes of data, but also assign a report ID, does the ID take up space with reference to the 64 bytes of data, or is it rather a separate field which is appended and separate from the report data? If there are not multiple report ID’s, does the Host still assign an identification prefix to each transfer?

               

              Also, regarding the report ID tag from the target perspective, does PSoC have a way to tie the report ID field to an interrupt vector table?  Meaning on servicing a full OUT Endpoint, if “2” were to be the report ID stored in the register, could this automatically trigger an interrupt to call function “foo”, or does such a feature not exist and the only solution is to manually parse the report ID and make the necessary function call?  Also, does PSoC have a specific way of appending the report ID to the IN data buffer?  Or is it as simple as creating a new buffer of size IN_Data_Buffer+1, and passing that to the LoadEP function?