Thanks for the lessons on Zephyr & nRF Connect SDK! Coming from register or API concepts of MCU programming I've been struggling to understand the concepts of DeviceTree and how it links to hardware resources of the device. Really appreciate your creation of this educational content!
When using SDK V2.2.0, you may find that the code for programming GPIO from the device tree doesn't work and the terminal gets stuck on *** Booting Zephyr OS build v3.2.99 ***. This is because the function device_get_binding("GPIO_0") is deprecated. To fix this, you can replace it with DEVICE_DT_GET(DT_NODELABEL(gpio0)) and the Blinky application will work correctly. The series is a superb resource to have, I greatly appreciate the knowledge you're sharing.
Yes, you are right. Before there was a special label with GPIO_0 in the device tree, but it is removed. Makes sense because it made things more confusing.
In theory it's possible with some adjustments, but I wouldn't recommend it for beginners. Might even be better to use the Seeed Xiao nrf52840 than the Nordic dongle as it has a UF2 bootloader.
I'm just starting to use Nordic parts and there's an insane amount of code, configuration and overlay files required compared to other architectures, to do the simplest things like read a GPIO pin. I mean this video is almost 30 minutes long to turn on an output and read an input. You can do that (in fact, read and write 8 pins at a time) with a couple of lines of code with say, Atmel parts in under a minute. The worst thing is that they use macros within macros within macros everywhere in the SDK. So there's often no way of telling what an error even means as you get reams and reams of errors all expanded out from various macros with names like "DT_N_S_leds_S_led_0_P_gpios_IDX_0_VAL_pin" 🤣
I have also used Atmel products before and your criticisms are quite valid. However, the approach has fundamentally changed as microcontrollers become more powerful. Nordic also previously used its own environment with the nRF5 SDK. However, this was specifically for the nRF5 series. Nordic has now switched to the free RTOS Zephyr as a development environment. With this, the source code remains largely independent of the board used and you have integrated scheduling and task handling. Nordic has only limited influence on the implementation by Zephyr. The macros are sometimes really annoying, especially at the beginning. But you get used to it with time. You wouldn't have to use many of this macros either, but then you have to generate and initialize the variables yourself, which makes the sourcode much longer. You could also continue to control the pins directly, but then you would be programming board-specific again. If you get used to the macros, understand the concept of the DeviceTree and the activation of certain modules, Zephyr becomes quite comfortable. 😉
I was struggling with getting printk to work. Thank you for giving me the answer!
You are welcome. Thank you for your positive feedback.
Thanks for the lessons on Zephyr & nRF Connect SDK! Coming from register or API concepts of MCU programming I've been struggling to understand the concepts of DeviceTree and how it links to hardware resources of the device. Really appreciate your creation of this educational content!
When using SDK V2.2.0, you may find that the code for programming GPIO from the device tree doesn't work and the terminal gets stuck on *** Booting Zephyr OS build v3.2.99 ***. This is because the function device_get_binding("GPIO_0") is deprecated. To fix this, you can replace it with DEVICE_DT_GET(DT_NODELABEL(gpio0)) and the Blinky application will work correctly.
The series is a superb resource to have, I greatly appreciate the knowledge you're sharing.
Yes, you are right. Before there was a special label with GPIO_0 in the device tree, but it is removed. Makes sense because it made things more confusing.
Thank for your video, it helped me a lot!
Thanks, really helpful.
Can we follow along this series of videos using the NRF52840 Dongle?
In theory it's possible with some adjustments, but I wouldn't recommend it for beginners. Might even be better to use the Seeed Xiao nrf52840 than the Nordic dongle as it has a UF2 bootloader.
How do you get that option where vscode already tells you the possible line of code you want to write?
I'm just starting to use Nordic parts and there's an insane amount of code, configuration and overlay files required compared to other architectures, to do the simplest things like read a GPIO pin. I mean this video is almost 30 minutes long to turn on an output and read an input. You can do that (in fact, read and write 8 pins at a time) with a couple of lines of code with say, Atmel parts in under a minute. The worst thing is that they use macros within macros within macros everywhere in the SDK. So there's often no way of telling what an error even means as you get reams and reams of errors all expanded out from various macros with names like "DT_N_S_leds_S_led_0_P_gpios_IDX_0_VAL_pin" 🤣
I have also used Atmel products before and your criticisms are quite valid. However, the approach has fundamentally changed as microcontrollers become more powerful. Nordic also previously used its own environment with the nRF5 SDK. However, this was specifically for the nRF5 series. Nordic has now switched to the free RTOS Zephyr as a development environment. With this, the source code remains largely independent of the board used and you have integrated scheduling and task handling. Nordic has only limited influence on the implementation by Zephyr. The macros are sometimes really annoying, especially at the beginning. But you get used to it with time. You wouldn't have to use many of this macros either, but then you have to generate and initialize the variables yourself, which makes the sourcode much longer. You could also continue to control the pins directly, but then you would be programming board-specific again. If you get used to the macros, understand the concept of the DeviceTree and the activation of certain modules, Zephyr becomes quite comfortable. 😉
Thanks