Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

Edvin — Thu, 21 Aug 2025 09:25:06 GMT

It is this one found here:

https://github.com/Protocentral/protocentral_max30001_zephyr_driver

Please read the readme.md file. The west.yml file that it describes is either the one found in:

NCS\zephyr\west.yml

NCS\nrf\west.yml.

Try both (one at the time). Just add the

- name: MAX30001
      path: modules/protocentral_max30001
      revision: main
      url: https://github.com/Protocentral/protocentral_max30001_zephyr_driver

At the end of your "projects" list, with the same indentation as the other devices in the list, and then run "west update" in the folder that the west.yml file.

Best regards,

Edvin

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

bricle — Thu, 21 Aug 2025 03:59:44 GMT

Hi, could you please provide the link to MAX30001 out of tree-zephyr driver? thanks.

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

Edvin — Mon, 10 Mar 2025 07:36:10 GMT

I am not aware of any official guides, but you can look into how it is done with the MAX30001 out of tree-zephyr driver, that I tested once. That worked out of the box. (I didn't have the sensor to test, but it built, at least).

Best regards,

Edvin

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

rrainey — Thu, 06 Mar 2025 18:43:49 GMT

I am very interested seeing this resolved this as well.

I really like working in nRF Connect / VS Code and I recently went through several Nordic training courses including the nRF Intermediate course. In Exercise 1 in that course, it seems to indicate that something changed between 2.5.0 and 2.6.0 that blocks support of device drivers in freestanding applications.

I had a go at this anyway in my own work, and -- after a very long run of trial and error -- verified that there's a fundamental problem (notes below).

As has been pointed out, this is a fundamental issue. Custom device drivers are probably the norm in real projects, not an exception. I can fall back to the west command line or inject an ugly one-off fix, but then I can't enjoy the other benefits of nRF Connect.

Please help.

Technical notes:

After creating a custom device driver as part of a standalone project, I was facing the common "undefined reference to __device_dts_ord_<N>" link error (previously cited in this article). I looked through many resources and -- for what it is worth, this Zephyr document is the best resource. In the end of my journey, I figured out that the device was correctly enabled but a bug in the CMake infrastructure was preventing the driver's library from being included in the link step.

I'm faced with a choice here: I could probably put in specific linker flags to include the library and this fix the inssure for me, but it would be far better to have the underlying issue addressed, no?

I really get a lot out of nRF Connect and would like to see this fixed.

Thanks,

Riley

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

zhaw-moss — Mon, 14 Oct 2024 04:58:00 GMT

Hi Edvin,

Thank you for your response, and I appreciate you pointing out the section in the Developer Academy.

You're correct that there is a lesson about custom drivers in the Dev Academy. However, I noticed that for it to work, they define a workspace application, which effectively creates a West workspace that redundantly downloads Zephyr and nRF Connect SDK. It also works specifically with the ncs-example-application, whereas all other samples don't follow this approach and are set up as freestanding applications.

If the intention is that all projects should be structured as workspace applications — with Zephyr and ncs redundantly downloaded each time — then it would make sense for all sample projects to be consistent with that approach. Additionally, the convenience features in the VS Code extension, such as the Manage Toolchain and Manage SDKs buttons, could potentially be streamlined, as a centralized instance of Zephyr and ncs wouldn't be necessary. (Just a joke, please don't do that!)

On the other hand, if the freestanding application structure is still an intended and valid approach, then as I mentioned before, there should be clear documentation on how to integrate custom drivers properly in this context — as a Zephyr module. It’s also a bit confusing that in the Dev Academy lesson on custom drivers, the setup involves a workspace application, while other lessons and samples consistently use freestanding applications—without explaining why this divergence exists.

Also, in the documentation on the different types of application structures, there isn't any clear information on the implications of choosing one structure over another, or why a workspace application might be preferred in specific situations.

Perhaps I've overlooked some crucial documentation, but I think my point is clear: this inconsistency is confusing, and clarifying the reasoning or standardizing the approach would go a long way in improving the developer experience.

Thank you again for considering my feedback, and I look forward to seeing how these materials evolve. If there are no further actions needed from your side, please feel free to close the ticket.

Best regards,
Simon

RE: Clarify Documentation and Example for Custom Driver Implementation in Freestanding Applications

Edvin — Fri, 11 Oct 2024 12:40:39 GMT

Hello Simon,

Thank you very much for your detailed and constructive feedback. It is very valuable for us. I will forward your feedback to some relevant stakeholders.

I believe this is somewhat covered in our Developer Academy, in the NRF Connect SDK Intermediate course, Lesson 7. So in case you are not aware of the DevAcademy portal, you may find this useful in the future.

However, I agree that this shouldn't replace documentation.

Best regards,

Edvin