nRFConnect SDK - samples

RE: nRFConnect SDK - samples

TigerD — Thu, 09 Sep 2021 12:33:57 GMT

Hi Vham,

First thank you for your opinion and input with your expertise on this subject.

I switch from nRF52 SDK to nRFConnect SDK, because Nordic is not planning to enhance nRF SDK, and I found some useful features such as extended adv (periodic adv) implemented in nRFConnect.

Best Regards,

David Zhou

RE: nRFConnect SDK - samples

vham — Thu, 09 Sep 2021 04:06:53 GMT

Hi David,

If by "your team" you are suggesting I work for NordicSemi, I don't. I'm just an embedded systems engineer that has used, over the years, multiple tools and chips from Nordic, building proof of concept firmware prototypes to production grade firmware.

In my opinion, the nRF5 SDK is good enough to do everything you might need. If you don't have anything defined yet in terms of software needs, this is a good place to start. In my experience the nRF5 SDK provides the most flexibility and it provides more than enough examples to explore all the functions you could possibly use in the nRF5 series.

On the other hand, I have found that using the connect SDK or the Zephyr project lets us develop our applications a little bit faster since it provides a few extra advantages (under the RTOS principles). Also, some functions are easier to use, implement or they are simplified (or the complexity is hidden) when compared with the nRF5 SDK.

All the SDKs provide ways to optimize for power consumption, but you might need to work very closely with HW engineers to further optimize this. Software alone can only help with a part of this. For example, you might need to put your nRF5x chip to sleep but other components in your board might still be on, draining power from batteries. In terms of performance, all SDKs are well optimized, and with every SDK release Nordic publishes, they provide further optimizations, bugs fixes or add extra functionality. For OTA DFU, all of them provide this capability.

At the end of the day, programmers/firmware designers choose whichever SDK they feel comfortable using or the one they feel provides the more functionality for their end goal. If you have the time and resources, give all a try before starting a huge project. Self-discovery of knowledge is a very powerful tool when you start working on something new. See the pros and cons of each yourself, because only you know how everything is going to be implemented at the end and the requirements of it.

One last thing to take into account is how frequently these tools update and for how long they are going to be supported. Also, take a look into the requirement of your projects and see if you need stuff related to RTOS vs a more simple monolitic firmware. I don't want to get too technical here because we could keep writing for hours or days on these subjects.

Remember that this is only my opinion based on my personal experience. Probably if you ask someone else, they might give you another point of view of this.

Best regards,

Vham.

RE: nRFConnect SDK - samples

TigerD — Wed, 08 Sep 2021 13:27:29 GMT

Hi Vham,

Thank you for your reply.

I was using SoftDevice nRF52 SDK all-along. But your team suggested to me to use nRF Connect SDK. For nRF devices, such as nRF52840/832, which way is better (nRF Connect SDK, vs Zephyr RTOS) , in terms of power consumption, performance, Bootloader (OTA DFU), ? Please advise?

Thank you,

David Zhou

RE: nRFConnect SDK - samples

vham — Wed, 08 Sep 2021 02:31:45 GMT

1.

The ncs\nrf\samples\bluetooth uses the API and source files for the nRF Connect SDK.
The ncs\zephyr\samples\bluetooth uses the API and source files from the zephyr RTOS which is different from the Connect SDK.

Only a few chips from the nRF52 series are direction finding capable. According to the nordic website: nRF52811, nRF52820 and the nRF52833 have that capability. For a DK that support direction finding, see the nRF52833 DK.

Hope this answers your questions.