CCS/LAUNCHXL-CC1352R1: ble5_simple_peripheral_oad_offchip example - all files linked

The ble project_zero also has some folders linked. I'm sure the other ble examples also suffer from this linking vs copying.

They're also missing readmes. I don't need a full formatted document, just a quick synopsis. Even some sort of "useful" comments in the source files would help.

Thanks.

My personal opinion (I obviously don't speak for everyone, but I am struggling with the web of complexities in these examples, so I cant be alone) is that any code presented in CCS should live in the workspace so that any changes (either intentional or accidental) don't corrupt other examples, or future re-importing of the examples.

ICall, OSAL, etc shouldn't need to be edited, but then they should be somehow locked, hidden, or a giant warning in the file should indicate that this is editing the "only copy" of the SDK file, and not the local file. Maybe that should be inherently obvious (it is for me now after struggling with it), but its an added complexity to an already difficult and convoluted set of examples.

Take the project_zero example. The ble_user_config.c/h files live in the linked ICallBLE folder. Just the name of those files alone indicate user editable. I was trying to integrate the DMM code which appeared to require setting a couple lines in bleStackConfig. Things broke elsewhere and I decided to start from scratch and realized I have no idea if the freshly imported project_zero code was "clean" or if I had monkeyed with something in one of those other linked files. I had to figure out how to reinstall the SDK, which itself was not entirely obvious.

The fact that the ICallBLE folder is virtual in itself is confusing because the 2 other files linked in that virtual folder do not live in the same SDK folder, so I cant just copy the ble_user_config.c/h into the local ICallBLE folder without setting off a whole chain of compiler/linker issues.

Virtual folders and linked files certainly serve a purpose, but I think they are doing far more damage and confusion by having them in the examples.

Pretty much all of the ble5stack examples in v2.10.00.48 are missing readmes, at least in resource explorer.

Sorry, I feel like I may be splitting hairs here... if the file is in project explorer in CCS, the user can edit the file. Whether they should or not is a different story. My point was that, unless there is some other mechanism to prevent the file from being edited at all, it should be copied, not linked. That way if someone does accidentally edit the file (even if they are not "supposed to"), they dont create a bigger headache that what is confined to the workspace, and easily replaced from the original SDK files by a simple delete and re-import.

Yeah, linked as a library (i.e. in the compiler/linker sense) would be the most logical. You’d have to pull out the user editable files and deal with the different requirements for each example. Or have one big library that includes all.

I’m not quite sure why they weren’t in the stack library already.

I’ll be honest that the linked project stack (or in the other examples, the linked tirtos project) are a bit confusing, but they just work, so I haven’t looked too deep into them.

Another example file that appears to contain code that should be edited is oad_image_header_app.c

#define SOFTWARE_VER            {'0', '0', '0', '1'}

(that's from the project_zero example) If you wrap these files in a library, you might want to move that declaration out to another file.