I have recently switched to using SEGGER embedded studio (SES) which seems to be advocated by Nordic. I have arrived from Eclipse which though extremely flexible is complex in the extreme. So I greeted SES with joyful anticipation. I should mention here that I dallied briefly with PlatformIO which doesn't seem well (at all) intergated with the nRF DK.
Yearning for a clean IDE, I have persevered with SES, but I have become increasingly confused by the variety of (implied) ways to structure my new projects, and the various tools and veneers that seem to offer more options than clarity. I'd really like to get some advice, or a pointer to a document describing the options best practices, and the rationale behind choices. Too much to ask?
From my perspective there are several major challenges in deciding how to organize and manage a new SES project:.
- Deciding where to place my project code base in relation to the SDK code base. Because some of the SDK path names are very long, there can be obscure build issues. It is advocated (somewhere) that the SDK should be placed close to the file-system root. On the other hand my own development code might live in my "user" file hierarchy where source control systems can manage it, along with related. hardware designs, enclosure designs.
- When a bit of code fails to compile because it references code from the SDK, it is often a challenge to figure out:
- where the relevant components reside for my particular configuration;
- what defined constants have to be set to cause it to be compiled. GREP revealed that there are 33 SDK files that contain a unique definition of the form *_ENABLED. e.g. NRF_LOG_ENABLED. That in itself is to be expected, but there is (AFAIK) no single place where the 297 "_ENABLED" definitions are defined.
- Actually communicating what files I want included by SES seems to involve a hodge-podge of overlapping techniques. To include ".c" or ".h" files from the SDK, I can:
- edit an sdk_config.h header file directly
- add preprocessor-includes into the project options form;
- copy files into my development directory. The latter is clearly a pain if I take a new SDK release
- Setting defintions presents another smorgasbord of options:
- use the CMSIS wizard
- add pre-processor definitions in the option form
- create my own app.config.h
Those very useful example files generated by Nordic are of course embedded in the release, and observe a structure that allows them to be compiled by a number of different IDEs (Cheer).. Creating an example using the SES "New" facility creates a completely different structure though, and seems to copy in a lot of files that some might argue are better left in the SDK release structure. The program compiles and runs right away, but when you try to embellish it the puzzle begins.
Now I understand that I am viewing the results of several years of excellent code evolution at Nordic, and that this is unlikely to be harmonious with the excellent SES system. So perhaps that's why I have found it so hard to find a "best practice" document/video that provides some reasoned guidance on project structure. Of course there is no "best practice", and every developer will have their own predilectons, but for someone new to SES it is really hard to get a running start at SES.
