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.
@@SpencerTechMelody Arduino is a piece of garbage, when the entry for baremetal, RTOS' etc. has never been this low - why would you ever subject yourself to neanderthal Arduino
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!
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?
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.
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
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.
Just what is needed to explain the device tree and the many macros. Full of excellent tips and insights. Thank you!
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.
could you tell me that why you’ll switch from Arduino to sdk(zephyr)? Is Arduino being uncomfortable programming?😮
@@SpencerTechMelody Arduino is a piece of garbage, when the entry for baremetal, RTOS' etc. has never been this low - why would you ever subject yourself to neanderthal Arduino
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!
讲的很好, 希望多讲点,新手入门的, 毕竟zephyr 对于新手来说,学习难度太大
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?
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.
Thanks for this amazint content. What you are doing is really really really amazing. Danke
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
Hi, can you do an example with RSSI
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
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.