This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/CC1352R: DMM Sample code pecularities

Part Number: CC1352R
Other Parts Discussed in Thread: SYSCONFIG

Tool/software: Code Composer Studio

Hy,

while porting my previous project from sdk_3_10_00_53 to sdk_3_30_00_03 I come across a couple of questions. In both cases I started with dmm_154sensor_remote_display_app example project. Now I try to do the same steps as I did back then with the previous SDK

- Back then, my project consisted of two projects: App and stack library. Now I only see one. Is there advantages or disadvantages in not having a stack library project?

- The sample code of remote_display contains a clkPeriodic Clock struct. It is started in RemoteDisplay_processGapMessage but I can not see it being initialized nor is there an event linked to it

- There is two calls to GapAdv_disable, but have 3 parameters. When I look in gap_advertiser.h it seems that the function has only one parameter

- There is a define for DEFAULT_ADVERTISING_INTERVAL but it is never used, instead advertising interval is defined by sysConfig

- Is there a way to switch off sysConfig in an existing project? It might be cute for the very beginning of a project, but later it seems very uncomfortable to change things in a GUI instead of in code. But the Generated Source is freshly created on any build.

- What is your recommendation on how to handle different build configurations with SysConfig? I build 5 different applications out of the same source code, each running on a different hardware, for example having different amount of ADC channels. How do I realize that with only one SysConfig file?

- Both files ti_ble_config.c and ti_ble_config.h include simple_gatt_profile.h. Why? How can I get rid of this? My application does not have simple gatt profile.

Best regards

Harald

  • Hey Harald,

    Harald Ilg said:
    - Back then, my project consisted of two projects: App and stack library. Now I only see one. Is there advantages or disadvantages in not having a stack library project?

    This was done as part of a restructure to allow a simpler work space environment. I believe it doesn't impact your ability to configure necessary BLE parameters.

    Harald Ilg said:

    - The sample code of remote_display contains a clkPeriodic Clock struct. It is started in RemoteDisplay_processGapMessage but I can not see it being initialized nor is there an event linked to it

    - There is two calls to GapAdv_disable, but have 3 parameters. When I look in gap_advertiser.h it seems that the function has only one parameter

    - There is a define for DEFAULT_ADVERTISING_INTERVAL but it is never used, instead advertising interval is defined by sysConfig

    Thank you for reporting these issues - I have filed them with our development team to hopefully be improved in a future release. We are always looking to improve our software offering so we appreciate your feedback! Please let us know if you find anything else you would like to report.

    Harald Ilg said:

    - Is there a way to switch off sysConfig in an existing project? It might be cute for the very beginning of a project, but later it seems very uncomfortable to change things in a GUI instead of in code. But the Generated Source is freshly created on any build.

    The current workaround for disabling SysConfig requires the following steps:

    1. Build the project with desired settings via the SysConfig tool.
    2. Copy all the generated .c/h SysConfig files to a new folder in the project.
    3. Exclude the SysConfig file from build.

    This will allow you to change the generated files directly.

    Harald Ilg said:
    - What is your recommendation on how to handle different build configurations with SysConfig? I build 5 different applications out of the same source code, each running on a different hardware, for example having different amount of ADC channels. How do I realize that with only one SysConfig file?

    The .syscfg files should be treated like source files, just as .c files. The easiest way to go about this is to have different .syscfg files for each build config.

    Harald Ilg said:
    - Both files ti_ble_config.c and ti_ble_config.h include simple_gatt_profile.h. Why? How can I get rid of this? My application does not have simple gatt profile.

    I've reached out to the development team and made them aware of this. The workaround in this case would be to manually remove this line after disabling SysConfig.

    Again, thank you for your feedback! Please let me know if you have any follow up questions.

  • Dear Ammar,

    thanks for you response.

    The removal of the sysConfig was possible but still not straight forward. Quite some adjustments (include paths etc) needed to be done. Now, there is only a small left-over: I can't remove the "Generated Source" folder from the project. This is more of a cosmetic issue, right?

    I do not understand how TI expects users to update from one SDK to another. For me it seems, that every SDK release brings in new ideas that are incompatible to previous versions. So far it took me about 20h to port a project from SDK 2.2 to SDK 3.3, a lot of manual chicken work included. Is this expected or do I do something wrong. Would there be an easier way?

    As Explanation: Back then I started from a given sample project (in my case dmm_154sensor_remote_display_app). I did all coding for my own application. To switch to current SDK I use the same sample project and do all changes again. Is this correct?

    Regards

    Harald

  • Harald Ilg said:
    This is more of a cosmetic issue, right?

    Yes, once SysConfig is disabled the Generated Source folder is no longer used and can be ignored.

    Harald Ilg said:
    To switch to current SDK I use the same sample project and do all changes again. Is this correct?

    I apologize for the inconvenience. We do have migration guides to make the update process for our customers as smooth as possible. 

    That being said, SDK 3.3 did include considerable core changes to DMM (see the changelog here) . In this case, the way you described would be the best way to ensure that you inherit all the many changes since SDK 2.2 was released.

    If you have any questions about this, please let me know!