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 <[email protected]>
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
