Hacker News Reader

Comment by fullstop | Hacker News Reader

Unless things have changed recently, Nordic is still king of low power applications.

With that being said, I've worked with both the Nordic NRF SDK and the Espressif SDK and greatly preferred Espressif.

For doo-dads that I make for my home, esp32 and esp8266 are fantastic. The modules are inexpensive and the community is huge. I would not want to be in Nordic's shoes right now.

View on HN

It's easy for us hobbiests to forget that all the spare do-dads we have floating around our workbench aren't even a drop in the bucket compared to the number of chips bought by a single manufacturer for a single model of a kitchen blender.

We matter a little and can be somewhat of an indicator sometimes. Right up until we don't. A lot of times what matters to us just doesn't apply at scale.

But these kinds of things also seem to follow a tech playbook, cheap parts show up, lots of hobbyist, small companies, etc start using them in low volume applications. They work out the bugs, and the newer competitors parts keep getting better. The existing big company doesn't care because, as someone else pointed out they are maintaining a stable volume/revenue.

Only, in the tech industry that's almost always a bad sign, the competitors are winning new designs that haven't yet really started to ramp, while the existing vendor is coasting on the current device using their parts. Then what happens is they get stuck in a declining revenue/volume situation while the newer cheaper better competitor slowly eats the market, and at that point investing in a "dying" product just about never happens.

There are actually 2 Nordic SDKs, nRF5 (now in maintenance, but still in many supported products in the field) and nRF Connect (bundled with Zephyr). Later gives a lot of access to both Host and Controller part of the stack and for commercial products that are not simply flipping a lightbulb it is still a standard. ESPs are good for quick hacks and more competitive with Nordic if low power is not an imperative.

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.

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