Getting up to speed tutorial

[mark waldin]

I feel defeated. Programming nrf52 uses libraries that rely on libraries that rely on libraries and on. Loading a new project into Segger Embedded Studio loads none of the libraries used by the SDK. I don't know where to find the full set of libraries and don't know what libraries a certain function requires.

I think perhaps I am too much of a novice to get over the hump. All documentation I can find starts assuming more knowledge than I have. Does anyone know of a good tutorial, book, etc that could get me up to speed by any chance?

Thanks,

[UnicycleBloke]

I have recently started with this SDK. I found the most productive approach was to duplicate one of the examples. I converted the makefile to cmake, which was very instructive on the compiler options and so on, and then removed any files and include directories for which doing this did not break the build. It's amazing how few of the libraries you actually need.

Aside from which files you need, it's worth looking for the blog describing the Observer pattern. I regards the SDK's implementation as horrible, but it does work. I wasted a lot of time trawling the SDK trying to understand this and other features.

Personally, I would not use the nrf/nrfx peripheral drivers. The code is overly complex. It is much simpler to just deal with the registers directly. The NRF peripherals have a simple, consistent and logical design, and you can easily write application specific drivers which do just what you need. 

[mark waldin]

Much appreciated reply.  I've been trying to translate the GPIOTE example to one using inputs instead of outputs (no input examples that I can find).  I will try to dissect the example for what it is instead of what I want it to be.  Understood on by-passing nrf drivers but I am confusing myself well enough using their abstraction.  Going one level lower will just make it worse I fear. 

I learn very quickly and if there were a ground up tutorial I know I would grasp it very fast.  It is so easy to get hung up on one line of code and spend hours looking for references it is maddening.  For example, GPIOTE example links to timers and not I/O pins. I see in the api that I can initialize a pin as output and it one of the inputs is 'pin' but then I have to find out where the definition of 'pin' is and what values it takes.  Lots of documentation to look through to try to find it and Internet search is less than useful to try to do that.

I think if I had an example that was close to doing something that I am looking to do it might be easy.  Trying to bring something up from scratch with no framework on how things work and where to find them is difficult for me.

Thanks for your recommendation but I think I am a couple steps short of doing that!

[Einar Thorsrud]

Hi mark waldin,

Which example are you looking for? The Pin Change Interrupt Example is a simple GPIOTE input example. In addition to the SDK examples there is also a lot of SDK documentation. For instance you can find documentation for the GPIOTE driver here. Regarding the driver, I somewhat disagree with UnicycleBloke regarding the drivers. Yes, the nRF peripherals are quite easy to use directly, but here are some good reasons for using the drivers:

• I see little reason for implementing low-level stuff yourself, when you have tested driver code available free of charge in the SDK.
• The drivers incorporate errata workarounds that you may otherwise forget.
• In many cases the drivers will handle additional complexities with the SoftDevice for you (for instance for peripherals that are protected by the SoftDevice).
• In many cases the drivers will provide you resource sharing out of the box.
• Using the drivers allow you to abstract away low level details of the peripheral, making the code more readable and maintainable.

[UnicycleBloke]

Fair enough. Don't think I didn't consider those things. :)  On your first point, I would only comment that there ain't no such thing as a free lunch.

Whenever I start using new hardware, my first port of call is always the datasheet (in this case the Product Specification): know your enemy, so to speak. I have generally found that the hardware is much better and much more reliably documented than the vendor software, and that the software is often of questionable quality. And I really like that there are no abstractions between me and the hardware. That being said, once I have a grasp of how it all fits together, I've typically gone on to use the vendor library. In this case, I don't think I'll be doing that.

As a ground up type, I really wanted to understand how the processor works. I found that the NRFX stuff massively obfuscated the exercise, much more so than other vendor libraries I have used. I have learned the hard way not to trust code I don't understand. My primary concern in rolling my own is the errata, of which these devices seem to have rather a lot, but they also seem pretty well documented.

Of the hardware, I have no such complaints. The NRF52 peripherals are the simplest to use of any Cortex-M device I have tried. The way tasks, events, interrupts and PPI all fit together is excellent. And EasyDMA! Compared to other devices, the I2C is particularly simple to use.... I have found it straightforward to implement UARTE, PWM, SPIM, and TWIM drivers directly in terms of registers. All my driver interfaces are hardware-agnostic abstract C++ classes, which will make testing the application with mocks pretty simple when the time comes. The code is short, simple, and does exactly what I need.

[Einar Thorsrud]

Hi,

I see your point, and I am glad to hear you are happy with the hardware itself. It was also interesting to read your other thoughts, and they make full sense. I agree that the SDK drivers are a bit complex (perhaps too complex some times), but in most cases using them is simple.

[mark waldin]

I understand Unicycle's comments as well as yours.  Both have valid points.  I will look at pin change interrupt as it sounds like it might be close.  Thanks!