I'm trying to duplicate the boot behavior of a Thingy91 on a custom board, i.e. SW4:BOOT and SW3:BUTTON on power up, but the switches available use different IO. I'm wondering where and how to modify the configuration.
Thanks,
JT
I'm trying to duplicate the boot behavior of a Thingy91 on a custom board, i.e. SW4:BOOT and SW3:BUTTON on power up, but the switches available use different IO. I'm wondering where and how to modify the configuration.
Thanks,
JT
Hello John,
Are you writing your application with a basis or dependency on Nordic Semi's sdk-nrf code base? I may not be developing with the most commonly used set of tools (Linux command line, Python, west, cmake and the 'set up manually' stuff). But this has given me an insight early on to the Device Tree Source or 'dts' files for Zephyr supported boards. Are you familiar with the dts files for the Thingy91_nrf9160? In my build environment I find these files in [west_workspace]/nrf/boards/arm/thingy91_nrf9160.
There are several files in this Nordic board provided directory, both dts and Kconfig files, and a couple more. Can be a little overwhelming, but one thing I have learned is that a larger or 'parent' .dts file can have just small parts amended to it, or over-written, by creating a file in your application's area, with the extension ".overlay".
Forgive me if I offer info you already know. Dot overlay files are themselves written in Device Tree Source. I've managed to achieve changes simple as moving one I/O pin assignment over, or change the sample app's default I2C clock rate on a particular I2C peripheral instance, by creating along side my app sources a directory named `boards`, and within it a file named `thingy91_nrf9160.overlay`.
If by chance your application requires you to build in a non-secure way -- several Nordic sample apps require this -- you will want to create a file with your board name followed by 'ns' in the basename, e.g.: `thingy91_nrf9160ns.overlay`. DTS files have a syntax for including other .dts and .overlay files, so when you have a pin assignment or other hardware change you would like to effect in both secure and non-secure board configurations, you can create a file with a basename of your choosing, and have the board-name-specific overlays include the common one. There is already an example of this practice in Nordic Semi sdk-nrf v1.6.1 `nrf/boards/arm/thingy91_nrf9160` directory.
I think I shared this Nordic Youtube video tutorial link in a prior post where I had questions, but this gave me some good initial understanding and help on which questions to ask next:
* www.youtube.com/watch?v=sWaxQyIgEBY
I happen to be developing with Zephyr RTOS' 2.6.0 release, not the cutting edge, so this documentation at the Zephyr Project site has also helped me grasp how to connect more traditional C code with device tree nodes:
* https://docs.zephyrproject.org/2.6.0/reference/devicetree/api.html
Still working to wrap my mind around these programming languages and Zephyr design features -- DTS and Kconfig -- but am also now able to build some stuff beyond the basics. If I can do so there must be hope!
- Ted
Hello John,
Are you writing your application with a basis or dependency on Nordic Semi's sdk-nrf code base? I may not be developing with the most commonly used set of tools (Linux command line, Python, west, cmake and the 'set up manually' stuff). But this has given me an insight early on to the Device Tree Source or 'dts' files for Zephyr supported boards. Are you familiar with the dts files for the Thingy91_nrf9160? In my build environment I find these files in [west_workspace]/nrf/boards/arm/thingy91_nrf9160.
There are several files in this Nordic board provided directory, both dts and Kconfig files, and a couple more. Can be a little overwhelming, but one thing I have learned is that a larger or 'parent' .dts file can have just small parts amended to it, or over-written, by creating a file in your application's area, with the extension ".overlay".
Forgive me if I offer info you already know. Dot overlay files are themselves written in Device Tree Source. I've managed to achieve changes simple as moving one I/O pin assignment over, or change the sample app's default I2C clock rate on a particular I2C peripheral instance, by creating along side my app sources a directory named `boards`, and within it a file named `thingy91_nrf9160.overlay`.
If by chance your application requires you to build in a non-secure way -- several Nordic sample apps require this -- you will want to create a file with your board name followed by 'ns' in the basename, e.g.: `thingy91_nrf9160ns.overlay`. DTS files have a syntax for including other .dts and .overlay files, so when you have a pin assignment or other hardware change you would like to effect in both secure and non-secure board configurations, you can create a file with a basename of your choosing, and have the board-name-specific overlays include the common one. There is already an example of this practice in Nordic Semi sdk-nrf v1.6.1 `nrf/boards/arm/thingy91_nrf9160` directory.
I think I shared this Nordic Youtube video tutorial link in a prior post where I had questions, but this gave me some good initial understanding and help on which questions to ask next:
* www.youtube.com/watch?v=sWaxQyIgEBY
I happen to be developing with Zephyr RTOS' 2.6.0 release, not the cutting edge, so this documentation at the Zephyr Project site has also helped me grasp how to connect more traditional C code with device tree nodes:
* https://docs.zephyrproject.org/2.6.0/reference/devicetree/api.html
Still working to wrap my mind around these programming languages and Zephyr design features -- DTS and Kconfig -- but am also now able to build some stuff beyond the basics. If I can do so there must be hope!
- Ted
