Zephyr and Nordic nRF Connect SDK - 02 GPIOs, Leds and DeviceTree (v2.4.2)

Sdílet
Vložit
  • čas přidán 3. 07. 2024
  • The nRF Connect SDK by Nordic Semiconductor is built upon the real-time operating system, Zephyr, which offers robust support for multithreading. Hardware configurations are seamlessly managed through a device tree, and component activation or deactivation can be controlled via a configuration file.
    In this video, we'll explore various methods to manipulate GPIO ports, creating captivating LED blinking patterns. Through this journey, we'll gain a deeper understanding of how hardware control functions within Zephyr, using the power of the DeviceTree.
    Book (english version)
    WSN & IoT (Basics, protocols and applications):
    a.co/d/5yfTIuJ
    ISBN-13: 979-8851358074
    Book (deutsche Version)
    WSN & IoT (Grundlagen, Protokolle und Anwendungen):
    amzn.eu/d/hAbTgD0
    ISBN-13: 979-8648512061
    ##Hardware###########
    Developer board nRF52840-dk:
    www.nordicsemi.com/Products/D...
    00:00 Introduction
    00:34 Creating base project
    01:38 Text output with printk
    03:29 Programm the GPIOs with nRF library
    07:23 Programm the GPIOs directly over register
    11:40 Programm the GPIOs in Zephyr over the DeviceTree
    21:44 Programming the LEDs with dt specification structure
    24:50 Outro
  • Věda a technologie

Komentáře • 11

  • @abelashenafi6291
    @abelashenafi6291 Před měsícem

    Thanks for this amazint content. What you are doing is really really really amazing. Danke

  • @BastiKlein
    @BastiKlein Před 8 měsíci +3

    I recently switched from the Arduino platform to the Nordic platform and have so much fun with the nrf52 chips. Your content is really helping me a lot - so thanks a lot for that! Would love to see a video about a bare minimum custom board with nrf52/nrf53 chip to make a single led blink and maybe talk to one sensor. I have my problems understanding how to proper config a custom board with pin selection, i2c, and so on.

  • @JackSparrow-zp3qv
    @JackSparrow-zp3qv Před 8 měsíci

    Thank you for making an update with SDK 2.4.2! Your videos are awesome for users new to nEF Connect SDK😊
    If possible would be great to have a guide on using the timer and counter resources like pressing a button and counting the positive edge event? That would be useful too. But still, awesome videos! Thank you!

  • @user-yb9yr2wu8v
    @user-yb9yr2wu8v Před 3 měsíci +1

    讲的很好, 希望多讲点,新手入门的, 毕竟zephyr 对于新手来说,学习难度太大

  • @michaeldalby1971
    @michaeldalby1971 Před 5 měsíci

    Hi Markus,
    I have a question if I may? I have a BL653 demo kit (based on an NRF52840). I tried to use pin 0.19 as a general I/O pin (for your led blinking example), but I think it is already defined to be used for UART1 in the main device tree. I am using UART1 in my project, but I only need the RX & TX lines (I do not require Hardware flow control, so 0.19 & 0.21 can be freed up for other things).
    If I look at the device tree it looks like RTS (pin 0.19 ) and CTS (pin 0.21) are already defined as part of the ‘&pinctrl’ declaration
    &pinctrl {
    uart1_default:uart1_default {
    group1 {
    psels = ,
    ,
    ,
    ;
    };
    };
    };
    How do I free up these two pins (and still keep the RX/TX functionality for UART1) by modifying the Device Tree Overlay ?
    Best regards
    Michael

  • @michaeldalby1971
    @michaeldalby1971 Před 6 měsíci +1

    great Video - I didn't realise there were so many different ways to blink an LED. So am I thinking that for portability (to change from one processor to another) you are better off using the Device Tree as a reference method?

    • @wsniot
      @wsniot  Před 6 měsíci +1

      You are right. Mostly it is better to use the Device Tree for accessing hardware components. The other methods are more for understanding what is actually happening. And in some cases, it may be better to access hardware directly for efficiency reasons or because you want a specific behaviour what a driver is not supporting. But for LEDs you should mostly better use the Device Tree.

  • @veyselaksoy3470
    @veyselaksoy3470 Před 8 měsíci

    Hi, can you do an example with RSSI

  • @isd-oj4zr
    @isd-oj4zr Před 4 měsíci

    what if the board's name is not in the list? my board has BMD340 and I chose ubx_bmd340eval_nrf52840 as my board, but I am not getting any output

    • @wsniot
      @wsniot  Před 4 měsíci

      The ubx_bmd340eval_nrf52840 has a atmel chips as j-link and usb-uart-bridge on board. If you use only a BMD340 it has actual only the nrf52840 and a few basic elements for supplying the SoC with power, oscillators and rf components. Maybe you can try using a usb dongle version works like the nrf52840-usb. The dongle will work as CDC-USB device. Or just simply connect an uart-usb-bridge to your BMD340.