nrfx confusion and the state of documentation and examples

RE: nrfx confusion and the state of documentation and examples

Jan Rychter — Sat, 24 Oct 2020 15:21:22 GMT

Thank you, Eirik, that is helpful information.

So, given that I am starting a new project and that I will be doing several more (one with Bluetooth Mesh), are you recommending that I immediately start using nRF Connect instead of nRF5 SDK? That is what you seem to be saying ("NCS is now at a level where we recommend it for new designs").

I did a quick dive and apart from everything being much larger and more complex, it also seems that the examples and documentation specific to Nordic chips are even more limited than with nRF5 SDK. But, if this is the way forward, I will go ahead and go through the learning curve. I'd much rather do that than begin development with something that is (slowly) on its way out.

RE: nrfx confusion and the state of documentation and examples

Eirik Midttun — Thu, 22 Oct 2020 14:55:56 GMT

Hi Jan,

Thanks for your feedback. We are aware that we are not where we need to be regarding the nRF Connect SDK and nrfx, and working to improve it. Detailed and honest feedback is vital for this. I cannot promise a quick fix, but I hope it will be reassuring that some of your concerns are addressed.

First, we don't plan to do frequent changes in our software platform. nRF5 SDK and SoftDevice has been around since 2013, and is still maintained, but since our product portfolio is getting more diverse we need to offer a different solution. I can understand the change seems quite radical now, but having a stable solution has been one of the main goals for NCS, which means we also need to consider what is coming in the future. This is mainly about the moment, not what should be expected for the future.

From your description it seems you are working on a new project, in which case I would suggest nrfx drivers. Those are in active development. The legacy drivers are primarily for customer with an existing code base built on these driver APIs. Likewise, the nRF5 SDK have been maintained it for customer depending on it - as is, and until recently offered as the stable solution. NCS is now at a level where we recommend it for new designs.

Supporting different architectures is something that is done well with the tools in NCS and Zephyr. That is the reason for the Python installation and related tools. The learning curve can be steep, but the result is flexible solution to adapt application to different targets. And this isn't limited to Nordic. As application code get more complex this will be of increasing importance.

I cannot speak for everyone, but I get the impression that NCS seems more scary than it actually is. I hope you will give it a second try, and I thank you for your patience.

RE: nrfx confusion and the state of documentation and examples

Kenneth — Thu, 22 Oct 2020 07:57:55 GMT

I honestly believe this will improve, even though I don't see a quick fix for the nrfx/sdk_config in nRF5 SDK. I have forwarded your feedback to the key persons that can best address this, and I know your bullet points will be discussed. Recurring issues like this should not occur. I can only say thank you for your feedback for now!

Best regards,
Kenneth

RE: nrfx confusion and the state of documentation and examples

Jan Rychter — Wed, 21 Oct 2020 13:49:05 GMT

Kenneth — if describing the drivers as "legacy" is misleading, then I would suggest not doing it.

Thanks for the explanation, but I'm not sure if you realize how unclear it all sounds to people from the outside. I now understand *why* Nordic did the whole nrfx thing, but I still do not understand what the path forward is for me.

Zephyr scares me with its complexity. I will have to use it one day because of the nRF9160, but I'm holding off for as long as I can.

What I think vendors do not understand is that for us, designers and developers, "transitions" and "migrations" are the worst things ever. Taking the example of Freescale/NXP, their Kinetis software was going through "transitions" all the time, and the transitions were never "done", they just overlapped. From a developer point of view, the software was always either "legacy/obsolete" or "being transitioned", with the documentation never being up to date. And projects had a roughly two-year lifetime.

Now I'm looking at Nordic and I'm beginning to see the same thing: an incomplete nrf_drv -> nrfx "transition" (which isn't really a transition, except the old drivers are "legacy" and you should use the new ones, except you don't have to, but only the new drivers have new features, etc). And on top of that there is the nRF5 SDK -> nRF Connect "transition" (sure, you can use the "old" SDK, but Zephyr is the way forward, but the old SDK is supported, but new features… etc). This creates confusion, uncertainty and doubt.

I think my "here's what I would do right now if I were Nordic" points still stand (*especially* the first four!).

Also, you wrote "good input, and something that I hope we can improve on" — so, has any specific action been taken? Is there somebody tasked today with fixing the documentation? Writing nrfx examples? I'm asking, because I'm looking through these forums, and I see posts from TWO YEARS ago about insufficient nrfx examples and nrfx confusion. If nothing has been done so far, it doesn't bode well for the future.

RE: nrfx confusion and the state of documentation and examples

Kenneth — Tue, 20 Oct 2020 14:24:29 GMT

Not sure I have a good answer for you here, but nrfx was introduced (or a requirement if you like) when Nordic started supporting zephyr RTOS. In the process it was decided that our nrf drivers should use the nrfx hardware abstraction layer also, and the drivers from that point have been described as legacy. That is though misleading, since the drivers in many cases can provide a slightly higher abstraction layer (that at least in some case) may be easier to work with, also there is no problem to continue to use the drivers in any way. There is no plans to obsolete or deprecate them from what I know, but if you are planning to transition to zephyr RTOS (part of the nRF Connect SDK) then the legacy drivers you are familiar from the nRF5 SDK is not availble there (instead there are many other libraries that can be used if you don't want to use the nrfx directly).

Best regards,
Kenneth

RE: nrfx confusion and the state of documentation and examples

Jan Rychter — Tue, 20 Oct 2020 11:46:07 GMT

Kenneth — I did read that page, and it didn't clarify much for me. The next paragraph after the one you quoted says:

"If you want to continue using the nrf_drv drivers, no changes are required. You can use the drivers as before, but without taking advantage of any new functionalities introduced to the nrfx drivers."

But I do want the "new functionalities"! (I think) — I am now beginning development of code that I will need to extend and maintain for years. As I have to go through a learning curve anyway, I'd much rather do it for the Officially Strategically Future-Proof API. And that web page does not clarify which API it is.

Looking at the TWI driver, it seems for example that the nrfx one has a function that can recover a stalled bus, and the "legacy" one does not.

I wanted to quickly check that, but I can't even find the right place in the documentation: going into "Software Development Kit > nRF5 SDK v17.0.2 > Hardware Drivers > Drivers descriptions" and choosing "TWI master" lands me in a page which describes the "legacy" nrf_drv API. To confuse things even more, this page also says:

"The driver layer provides APIs on a higher level than the HAL. See the API documentation for the TWI driver - legacy layer for details."

So, which layer is the "legacy" layer again?

If you search the forums, you will find many posts from users confused about nrfx. Some of the posts are from more than two years ago, and the confusion still remains.

RE: nrfx confusion and the state of documentation and examples

Kenneth — Mon, 19 Oct 2020 12:21:51 GMT

I think some of your input have been taken into account in the latest nRF5 SDK:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/nrfx_migration_user_guide.html

"The migration process is not required and often results in exactly the same functionality. Consider migration only if you want to take advantage of the new features offered by nrfx."

In terms of DMA or not to DMA; I would consider using DMA for all transactions where you don't need or want to analyze data during the transaction.

More examples, tutorials and blog posts on best practices is good input, and something that I hope we can improve on.