I've only used the nRF5 SDK. It worked, and it worked well, but it was cumbersome to work with if you didn't want to keep your code in the same tree as the the SDK itself. This was probably an organizational issue on my part, honestly.
The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.
nRF5 is indeed inferior SDK of the 2 (thus abandoned). Also I dislike that a big chunk of the stack there is a binary blob.
Regarding the code organization, not sure what toolchain you used, but the latest recommendation for nRF5 (Segger studio) could make it fairly easy to do this, but manually opening the project config files and changing them, not through the GUI.
nRF Connect is a different world, comes with a lot more options, some really rooted in Zephyr OS, some lessons learned from the prior SDK.
And if you're familiar with Linux build configuration system, that is basically what Zephyr brings to the table (comes from Linux foundation).
But yeah all that flexibility comes as a penalty when you want simple stuff, compared to ESP32-Sx
> nRF5 is indeed inferior SDK of the 2 (thus abandoned). Also I dislike that a big chunk of the stack there is a binary blob. Regarding the code organization, not sure what toolchain you used, but the latest recommendation for nRF5 (Segger studio) could make it fairly easy to do this, but manually opening the project config files and changing them, not through the GUI.
Yes, I ended up editing the .emProject files by hand. It worked, but it felt like I was doing something wrong. I assume that you are referring to the soft device blob? Has that been abandoned in nRF Connect?
There is a Zephyr BLE stack that can be used as well as a SoftDevice stack but SoftDevice isn't a huge binary anymore, much more modular to save code space.
> I assume that you are referring to the soft device blob? Has that been abandoned in nRF Connect?
Quite, yes. They took the ZephyrOS approach, but it comes with a learning curve penalty, unless you go the easy route of nRF Connect GUI. In that case you do have some limitations of how you organize the code base (so that the GUI works), but even that is miles ahead in configuration compared with to the nRF5 SDK + Segger Studio.
I have been out of this area for almost a decade now, but I have very fond memories of the nRF5 SDK. When I was evaluating the (then new) Nordic BLE SoC's for future products it was so much nicer than the TI CC2540 we had used in our first BLE device.
No amount of symlinking can fix this, and there's a lot of these files. Maybe copying an example project is not the right way to do things.
The link issue was, I think, the result of what Nordic does with weak symbols. I don't recall the symbol name, but it was something which caused very unusual results.
Regarding LoC tallies, I often try to minimize mine. :-)
If you're using segger, a quick find-and-replace will take care of that (ditto GCC Makefiles). Must admit that when I started with nrf52 SDK, I too used thge embed-the-application-inside-the-SDK approach. Pretty soon that got cumbersome, so I switched to the softlink approach. The exact approach is to store the SDK somewhere, create a softlink to it in the project directory and have the project files/makefiles use that instead.
The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.