NimBLE controller: timer mapping for nrf51

[Hauke Petersen <ha...@fu-berlin.de>]

Dear community,

I am not fully confident, if this is the right place to ask, so let me 
know if there is a better place :-)

We were recently trying to run the NimBLE controller on nrf51-based 
platforms using RIOT. We found that that the NimBLE controller has a 
hardcoded dependency on the nrf51 NRF_TIMER0. The same timer is per 
default also used as base for the RIOT system timer (xtimer). Although 
its a simple workaround to map RIOT to use some other timer, it is 
sub-optimal in terms of energy usage, as the other timers are all only 
16-bit. So my question: does the NimBLE controller need a >16-bit timer, 
and would it be feasible to make the used hw-timer configurable for the 
NimBLE nrf51-related controller code?

Cheers,
Hauke

Re: NimBLE controller: timer mapping for nrf51

[Hauke Petersen <ha...@fu-berlin.de>]

Hej Andrzej,

thanks for the details, it does indeed not make sense to remap that 
timer. So I will need to push the redesign of RIOTs system timer some 
more, so we don't have any drawbacks using 16-bit timers there anymore :-)

Thanks and cheers,
Hauke


On 6/6/19 4:04 PM, Andrzej Kaczmarek wrote:
> Hi Hauke,
>
> On Tue, Jun 4, 2019 at 12:28 PM Hauke Petersen <ha...@fu-berlin.de>
> wrote:
>
>> Dear community,
>>
>> I am not fully confident, if this is the right place to ask, so let me
>> know if there is a better place :-)
>>
>> We were recently trying to run the NimBLE controller on nrf51-based
>> platforms using RIOT. We found that that the NimBLE controller has a
>> hardcoded dependency on the nrf51 NRF_TIMER0. The same timer is per
>> default also used as base for the RIOT system timer (xtimer). Although
>> its a simple workaround to map RIOT to use some other timer, it is
>> sub-optimal in terms of energy usage, as the other timers are all only
>> 16-bit. So my question: does the NimBLE controller need a >16-bit timer,
>> and would it be feasible to make the used hw-timer configurable for the
>> NimBLE nrf51-related controller code?
>>
> That won't work unfortunately.
> The reason we use TIMER0 is that on nRF5x there are pre-programmed PPI
> channels that link TIMER0 with RTC0 and RADIO to provide timing for radio
> operations. To use other timer we would need to use 7 programmable PPI
> channels which is doable, but IMO it would make code unnecessarily
> complicated and would not work on 16-bit timers anyway (so ony nRF52). In
> particular, TIMER0 is used to timestamp received packets so 16-bit timer
> running at 1 MHz would roll-over every 65ms which is way too short for
> scanning to work properly.
>
>
>> Cheers,
>> Hauke
>>
> Best,
> Andrzej
>

Re: NimBLE controller: timer mapping for nrf51

[Andrzej Kaczmarek <an...@codecoup.pl>]

Hi Hauke,

On Tue, Jun 4, 2019 at 12:28 PM Hauke Petersen <ha...@fu-berlin.de>
wrote:

> Dear community,
>
> I am not fully confident, if this is the right place to ask, so let me
> know if there is a better place :-)
>
> We were recently trying to run the NimBLE controller on nrf51-based
> platforms using RIOT. We found that that the NimBLE controller has a
> hardcoded dependency on the nrf51 NRF_TIMER0. The same timer is per
> default also used as base for the RIOT system timer (xtimer). Although
> its a simple workaround to map RIOT to use some other timer, it is
> sub-optimal in terms of energy usage, as the other timers are all only
> 16-bit. So my question: does the NimBLE controller need a >16-bit timer,
> and would it be feasible to make the used hw-timer configurable for the
> NimBLE nrf51-related controller code?
>

That won't work unfortunately.
The reason we use TIMER0 is that on nRF5x there are pre-programmed PPI
channels that link TIMER0 with RTC0 and RADIO to provide timing for radio
operations. To use other timer we would need to use 7 programmable PPI
channels which is doable, but IMO it would make code unnecessarily
complicated and would not work on 16-bit timers anyway (so ony nRF52). In
particular, TIMER0 is used to timestamp received packets so 16-bit timer
running at 1 MHz would roll-over every 65ms which is way too short for
scanning to work properly.


> Cheers,
> Hauke
>

Best,
Andrzej