Dear Nordic Team,
I've been working extensively on creating a custom sensor driver building on Zephyr's sensor API. Throughout this process, I've utilized many available resources, including:
-
The Zephyr driver's tutorial video YouTube
-
Example repositories like teslabs' driver app, the Zephyr example-application, and ncs-example-application
-
The Zephyr documentation on device tree and driver development (Zephyr docs)
However, despite following these resources, I struggled for quite some time with an undefined reference to __device_dts_ord_<N> error during linking. While trying to debug, I referred to the official troubleshooting documentation (troubleshooting guide), but the issue persisted. It took a while for me to finally understand the root cause: the way Nordic suggests structuring applications through the VS Code extension leads to what are essentially freestanding or out-of-tree applications, and it appears that the available documentation doesn’t address this approach very well (I was lucky to stumble over this forum entry)
In particular, I realized that the Nordic VS Code extension, with its focus on keeping the nRF Connect SDK (ncs) and Zephyr centralized while keeping applications in a separate folder, introduces some nuances for integrating custom drivers. This freestanding setup makes sense from a storage and maintenance perspective, as it avoids having multiple redundant copies of ncs/Zephyr. However, this leads to challenges when trying to implement custom drivers, and there seems to be a lack of clear documentation or consistent examples for how to properly set up and link such drivers in this specific freestanding context.
Furthermore, I noticed that the official ncs-sample-application doesn't follow the same freestanding structure that the VS Code extension nudges developers towards. This inconsistency is confusing, and it led me to misunderstand how to properly integrate a custom driver for quite some time.
My Suggestions:
-
Documentation Update: Please consider adding specific sections to the documentation that cover how to create and use custom drivers with the freestanding application structure, especially focusing on how to integrate them as modules.
-
Consistent Sample Applications: It would be immensely helpful if you could update the ncs-sample-application to follow the same structure suggested by the VS Code extension (i.e., a freestanding application setup). Alternatively, adding a dedicated sample that demonstrates integrating a custom driver in a freestanding app would be very valuable.
-
Practical Examples with Custom Drivers: Given that many developers need to implement custom hardware solutions, providing a sample with a custom driver included would save a lot of time and reduce the learning curve for those following the freestanding model.
I believe these changes would make the experience of working with nRF Connect SDK significantly smoother for those of us building applications that require custom drivers, and align better with the approach promoted through your tooling.
Thank you for your consideration, and for the great work you do on the SDK.
Best regards,
Simon
