RE: Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK

The_C_Advocate — Mon, 22 Jan 2024 11:31:54 GMT

Thank for the well -written article.

RE: Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK

Induthings — Tue, 11 Apr 2023 16:47:10 GMT

After several migration jobs, we have concluded that it is necessary to have more FLASH/RAM memory. Our products/projects under nRF5 fitted well on nRF52820, but with Zephyr nRF52833 is needed as minimum. We reported some topics related with it:

[mention:5b4f7af208f34e3a96e7a73dcfabe092:46448885d0e64133bbfbf0cd7b0fd6f7]

RE: Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK

Griffin — Thu, 06 Apr 2023 11:12:54 GMT

I have been developing on nRF51, nRF52 and nRF53. Used both SDK5 and now nRF Connect SDK on the nRF52840; nRF5340 only on the nRF Connect SDK. Real-world projects with actual product results that do something.

It is hard to discuss these numbers with such small examples. IMHO, it doesn't make sense to use these minimal "applications" as a reference. Take a real project and then compare. My observations:

- For a multi-core system, there is no viable alternative to using an RTOS. The way Zephyr handles multi-core however leaves to be desired.

- The use of Zephyr device drivers is limited. A lot of the nice things available in the nRF silicon can only partly be used since they are too specific to Nordic. Example: the Zephyr PWM implementation does not allow strings of values to be sent which cripples the device significantly. Use of the nrfx library solves this partly (but be aware: these big warnings all over the library when using them in a multitasking environment are there for good reason!). Things get really interesting when you mix nrfx and zephyr drivers for the same type of peripherals by the way ;).

- When using RTOS features like the event bus (which is a very useful thing!) means the kernel runs through time consuming looping mechanisms all the time. That overhead is not to be ignored. Same for device drivers and many other parts. Pretty inefficient, but there often is no other way.

- When using an RTOS, one is inclined to start new tasks for many parts of the software. Each task requires its own stack which really eats through RAM like my cat plows through his food in the morning.

- The use of device driver structures with functionpointers as used in Zephyr means the compiler cannot optimize away unused parts of the device drivers. Optimization is sub-par in gcc anyway and with nRF Connect SDK you realistically have no choice.

- There's a lot going on pre-main. Devices are (at least partially) initialized pre-main for example. If you need your code to initialize software before initialization of the device, you are in for quite some trickery. These are hard to optimize this way.

- All negative? No, don't get me wrong. Once you get used to the runtime environment and you do not run into resource limits, Zephyr is quite nice. It allows you to design and implement your software development in nice and organized modules which is a lot harder when writing "on the naked iron". In our last project, we run some async protocols; you simply cannot beat a good multitasking architecture here. Maybe the code is not as compact compared to a cold metal solution, maybe it uses more RAM. But the convenience of having an RTOS available in such a case is unbeatable.