Hacker News Reader

Comment by fullstop | Hacker News Reader

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.

View on HN

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.

Some skim reading material about it: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...

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.

The simple hack is a softlink to the actual SDK.

On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;)

Link issue was possibly macro craziness? The scars of sdk_config.h etc.

If you base your project off of one of the examples, the project file has relative paths back to the SDK. For example:

    <file file_name="../../../../../../components/libraries/log/src/nrf_log_backend_rtt.c" />

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.

Reply on news.ycombinator.com