Hi
I would like to start developing wireless and embedded solutions using Nordic Ecosystem SoCs. I will probably only need to use BLE 5.0 and maybe Bluetooth Mesh so nRF5 SDK should be just what I need. I know Nordic is a bit different from STM and Microchip as these companies have their own IDEs (STM Cube and MplabX) and Nordic only provides an SDK and a Toolchain and anyone is free to decide which IDE they want to use ( usually Segger Embedded Studio (Nordic Edition) or VS Code). However set a SDK and toolchain can sometimes be a huge headache (especially for the Linux OS users since we have to do manual installations and ensure that the environment variables are well defined etc.
I also realize that Nordic will not add any more new features to the nRF5 SDK and now everything is developed for the nRF Connect SDK, however the nRF5 SDK paradigm is much closer to the HAL APIs that people normally know from the STM32 or PICs, while nRF Connect SDK is based on Zephyr Build System (which is based on CMake) and the amount of abstraction layers are huge and the paradigm is completely different and the time needed to learn and start good and efficient daily development is much longer (understand the whole process of generating the binary file, configuration files and what they do, hardware description with devicetree data structures...).
I understand this high decoupling of the source code (*.c) and the configuration system through Kconfig (*.conf) and the hardware description system through devicetree (*.dts) makes it easy to use the same application source code on different hardware and with different configurations with minimal changes but the lack of information or informative tutorials is still a lot.
Note: Congratulations for the initiative to create introductory courses to nRF Connect SDK at Nordic Developer Academy. I already took the first course, but unfortunately it requires many more courses and exploring the various concepts proj.conf, kconfig, devicetrees, overlays and so on.
So I have several questions/doubts and I would appreciate it if someone could clear my mind a little:
- Why should I really focus on learning the nRF Connect SDK if at the moment I will only need to use BLE and the nRF5 SDK is much more similar to the HAL paradigm I know from the STM and Microchip ecosystem?
- For a person who has never used CMake, what steps should I take to start learning the nRF Connect SDK?
- Due to the amount of abstraction layers of the nRF Connect SDK due to the Zephyr Build System, how optimized is the generated programming file afterwards in terms of program memory and power energy efficiency? If I want to make a product that really needs to be very power efficient (lets say power a device from a 100mah lipo battery and that it lasts a long time while using BLE communication, etc) how do I know that the generated code is the most efficient if we are programming with a huge level of abstraction? Has anyone done this comparation? Like compare the same code/application developed with nRF5 SDK and nRF Connect SDK and analyze the differences about program memory and energy efficiency? Are there any articles/benchmarks that look into this details?
I'm a recent electronic engineering graduate and my experience so far in Embedded Systems has been programming AVR and PIC 8bits uC and some STM32 nucleo boards and I really enjoyed programming while digging through the datasheet to see what bit settings or registers I should do, understand what the hardware is doing and use the HAL as well. And probably my problem is this. Trying to use Zephyr which has a lot of layers of abstraction and not understanding what the hardware is doing or how it is implementing things and having to constantly explore the documentation about the APIs. But I know that from a market perspective, a better abstraction like nRF Connect SDK, which allows you to program almost any type of SoC without changing the source code, is beneficial.
I would like to receive a lot of constructive answers with different perspectives from different people (engineers, enthusiasts, engineers who have already been through the ecosystem of other manufacturers like STM or PIC or even Nordic internal engineers).
Best regards.
