3 Replies Latest reply on Oct 5, 2017 3:11 PM by epr_1639216

    Making changes to the existing services

      Currently I'm working on the CY8CKIT-042-BLE with the User Data Service.

      I want to make some changes to the standard service according to out own specifications.

      When I add a new characteristic to it, it doesn't generate the same code as when a custom service is created.

      This makes it difficult to use the new characteristic because it isn't taken into the generated code.

      For now, I made an extra extension service to implement the needed functionality, but it would be preferred to be included into the UDS, as it is more complex to exchange data between the two .


      Is there a way to easily extend a service, or should other steps be taken, like the extended service that I made or making the entire service as a custom service?

        • 1. Re: Making changes to the existing services

          Standard services are pretty fixed in their behavior. Extending the service with the custom characteristic is probably your best bet if you want the data to be in the same service. The main differences between a custom and standard service/characteristic are:

          UUID size from 32bit to 128bit

          Name of the constants/variables is different when generated by the IDE for the API usage

          Doesn't get included into the standard service event handler (iirc).


          The custom characteristic should have code variables/names being generated by the IDE, they just have a slightly different naming convention than the standard characteristics.

          • 2. Re: Making changes to the existing services

            The custom characteristics are generated as can be seen in BLE_gatt.c, but no file contains the defines for the index and the handle as BLE_custom.h would have.

            It isn't included into the CYBLE_UDS_CHAR_INDEX_T, so the write commands can't be handled in the same way as the other UDS characteristics.

            When a read or write command is send to the custom characteristic, the UDS read or write callback isn't called, but the standard callback is used.


            To me, it looks like the characteristic is shown as part of the service, but is technically excluded from the service itself.

            All the implementation still needs to be handled like it is a custom service, so there is no advantage to including the characteristic to the UDS in terms of developing the software.

            • 3. Re: Making changes to the existing services

              Yeah, unfortunately I'm not really surprised by that. From what I've seen, the custom services are more of a "low-level-access" kind of implementation rather than a useful API similar to the standard/defined functions.

              There is nothing to stop you from implementing code that mimics the structure of the UDS API/code file generation however, so once you setup the constants in a file and include it, it would behave similar (less the event handling )


              For my own project, I found it easier to create a new service than to use an implemented one, but to each his own...