RE: nRF environment coding suggestions

FormerMember — Thu, 22 Jun 2017 10:55:29 GMT

1) If some processing is continuously being done in the main loop (for(;;) ), it will not be possible to have some power management. If you want some power management (power saving), I would recommend you to run the application "interrupt driven". If you run the application "interrupt driven", the chip does only need to wake up upon events, BLE events, TWI (I2C) events, and UART events, and go back to sleep (system ON) when the processing of those events is finished.

If you have interrupts that require some processing time (the 1000 samples), you can push processing of those samples to a separate interrupt, running on lower priority than UART/TWI/BLE, so that you don't miss any interrupts when doing the processing, and the chip can go to sleep when the processing has finished.

The following example shows how to push processing to another interrupt: ble_app_uart_test_throughput_irq.zip (SDK 12.0.0, S132 v.3.0.0) The relevant part is everything related to DATA_SEND_IRQ. The interrupt is borrowed from an unused peripheral.

2) The purpose of the drivers is to make it easier to use a given peripheral. Whether or not you want to use the drivers is up to you. The ideal thought is that it should not be necessary to modify the drivers, however, if you need/want to modify them, you are free to do so.

3) When the softdevice is enabled, the LFCLK will run continuously. The softdevice specification explains how the softdevice work. The HFCLK will be controlled by the softdevice, so if your application needs the HFLCK, the sd_clock_hfclk_xxx() API should be used.

sd_app_wait() puts the chip in system ON.

4) Related to the questions above, it would not make any difference if the chip is a BLE peripheral, central, or both.

The two latest versions of S140, S140 v.5.0.0-2.alpha and S140 v. 5.0.0-3-alpha, both support up to 20 concurrent connections.

A range of 20 m is not so much, and it should normally be quite easy to obtain that.