RE: porting from SDK 11

TY — Wed, 06 Dec 2017 15:52:23 GMT

Thank you very much, the hint with DEBUG_NRF could have saved my some days of debugging. Should have asked before :-)

Cheers Timur

RE: porting from SDK 11

MartinBL — Wed, 06 Dec 2017 15:22:47 GMT

Hi,

In general, there is a difference between configuring, enabling/disabling, and starting/stopping a peripheral. Initializing a driver with some nrf_drv_xx_init() function is yet another thing.

When configuring a peripheral you tell it which pins to use, how fast to sample a signal, how much data to transfer, etc. dependent on the peripheral.
When Enabled, peripherals override the PINDIR and PORT values set in the GPIO module. In other words, it is at this moment that the peripheral takes control over the GPIOs that you want to use.
Starting a peripheral with the START task makes the peripheral perform its actual task. Like transferring data over a serial interface or measure a voltage with the comparator. It is at this moment the peripheral requests the necessary resources like clocks, and starts to draw current.
When initiating a driver you tell your application which particular peripheral to use. And if applicable, you also tell it which instance of the peripheral (TWI0, TWI1, etc,) you want. You also tell it which pins to use and a bunch of different stuff specific to the peripheral.

When using a peripheral the general rule of thumb is: Configure -> Enable -> Start. When you want to turn off the peripheral you should: Stop -> Disable -> (Enter sleep mode, reconfigure, etc.). This will make sure that you won't see any weird glitches on the GPIOs when preparing the peripheral.

So typically, in the nrf_drv_peripheral_init() functions we configure pins, etc., and enable the peripheral. Some drivers also have separate enable functions. Then in the end, you most likely call some sort of nrf_drv_peripheral_start() function to start the actual measurements or transfers. You should never use the low level hardware abstraction layers (HAL) in e.g. nrf_comp.h. At least not when you use one of our drivers. Then they should only be used by the drivers themselves. So when using drivers the rule of thumb is: init() -> (enable()) -> start(). To disable the peripheral you should: stop() -> (disable()) -> uninit().

The ASSERT macro was added to the driver to simplify debugging and make it easier to pinpoint exactly where an error occurs. It should be possible though, to "disable" the ASSERT macro by making sure not to define DEBUG_NRF or DEBUG_NRF_USER. As you can see in nrf_assert.h, these two defines decide whether the ASSERT macro sends your application into a system reset or endless while loop or if it just ignores the ASSERT and moves on.