Shields are a neat way of quickly getting some peripherals up and running on your projects. However, if you have tried using an Arduino shield on your nRF9160 DK, you have likely encountered an error along the lines of:
Error: nrf9160dk_nrf9160ns.dts.pre.tmp:647.1-13 Label or path arduino_spi not found Error: nrf9160dk_nrf9160ns.dts.pre.tmp:664.1-8 syntax error FATAL ERROR: Unable to parse input tree CMake Error at C:/ncs/v1.5.1/zephyr/cmake/dts.cmake:205 (message): command failed with return code: 1
This is because the nRF9160 DK does not support Arduino shields out of the box, but it is on its way. Since I have spent some time fiddling around with working around this missing functionality, I will briefly explain how I have worked around this.
Simply put, devicetree overlays are ways for you to overwrite properties of nodes in your board's device tree. For example, the device tree file of the nRF9160 DK can be found at ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_common.dts. If you want to change any of these properties for just one project, then you can do this in a devicetree overlay. This is well explained in the Zephyr project's docs and I recommend you check it out!
It is because support for Arduino nodes was never implemented. However, support for shields using arduino_i2c and arduino_serial are on their way. If you have received the error message in the introduction, you might have tried creating an alias to arduino_spi in a board overlay file. This does not work, however, as the current order in which overlay files are applied on top of the board device tree is:
This is intentional and is unlikely to change. As of right now, there is no way to provide an additional overlay that goes between the shield overlay and the board device tree, so we need to find a way to work around the missing node labels for arduino_spi, arduino_serial and arduino_serial like this.
cs-gpios = <&arduino_header 16 GPIO_ACTIVE_LOW>; /* D10 */
cs-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>; /* D10 */
cs-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; /* D10 */
To illustrate, I have provided a zip of a project before and after this workaround. Check it out if you wanna see this workaround in practice! If you have any feedback or if anything is unclear, please leave a comment!
An example of this workaround can be seen in my LVGL blog post.
Some forum threads have also discussed this issue:
I'm glad it helped! Our DKs often come with a lot of functionality. Of course, with extra features/functionalities comes a higher price tag too. Generally, I think a lot of people who use the nRF DKs develop it with the end goal of putting just a few components from the DK (the nRF9160 SiP, for example) inside their final product.
At its core, I'm pretty sure the nRF9160 DK uses the ARM Cortex M-33, but really the nRF9160 is a SiP (System in Package) that as a whole is so much stronger than all its parts! I suppose it would be more helpful to say that the key feature of the development kit is the nRF9160 SiP
I am new to microcontrollers, this guide helped me but I have seen small microcontrollers so far like Arduino or Pi but NRF modules are quite big sized and look too powerful.
Which microcontroller is used in this nrf board?