Hi,
On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
I think we should do it like in other BLE implementations for NRF52
(SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
There are quite a few places in the BLE protocol where we need to
count
the time in various ranges from seconds to mili-seconds.
It is not possible to achieve this with just one timer device.
I'm not sure why a TIMER would be needed. Do you mean because of the RTC
resolution?
The RTC is capable of us resolution with period of hundreds of seconds.
The point is that RTC works
while MCU is sleeping so not depending on other peripherals means
low-power mode could be entered while waiting for things eventually. I
would personally use one timer until there's a specific need for other.
There is only one watchdog instance and at least two RTC instances in
the NRF52 chips.
The watchdog timer should be left for user-specific applications.
Note that "watchdog" in NuttX context means different things: there's a
"watchdog" interface which basically allows you to set a callback to be
invoked after some duration. This works using the underlying system timer.
In other words, the "watchdog" interface in NuttX gives you access to the
system timer, whereas the oneshot is a separate interface based on a
separate harware resource.
The system timer (SysTick) is not low-power friendly, so it is not
suitable either.
Ultimately, we should use the TICK event from RTC as the system clock.
Yes, RTC0 should be used for OS. My intention is to support what Xiang
mentioned is the recommended approach for new boards, which would mean to
implement an arch_timer.c compatible interface to RTC and then you get
tick/tickless option automatically.
Another thing is that we probably don't want to use the oneshot
interface but instead work directly with the TIMER/RTC peripherals.
In a few days I'll add PR with TIMER and RTC support.
Let's try to coordinate things since I'm actually working on the same code
and I was even about to start working on RTC peripheral interface. My
intention was to do the following:
- work on clockconfig to configure the LFCLK (wait for oscillator, etc)
- expose RTC peripheral with very basic interface
The following step would be to either create a oneshot driver interface
for the RTC timer, so RTC1 could be used from Link-layer timeouts.
Otherwise I could simply use the system timer using NuttX watchdog
interface. That was my original question. Since you mention that maybe two
timers are needed, that enforces my idea that at least one oneshot timer is
needed (for the TIMER peripheral).
And FYI, I'm slowly building up a Bluetooth link-layer by defining what
would be an upper-half part that implement most of the arch-independant
parts of the low-level BLE protocol handling, next to a lower-half
interface which allows the upper-half to communicate with the
arch-dependant part. This means that besides the arch-independant
link-layer, I'm writing an implementation for the lower-half which calls
into nrf52_radio.h functions.
I don't have this pushed anywhere yet since I don't even have the hardware
to test it, but I'm slowly advancing. I was just at the point of needing to
design how the timing part would work on the LL.
Best,
Matias
pt., 17 lip 2020 o 04:40 Matias N. <mat...@imap.cc> napisał(a):
Hi,
I'm working on a BLE Link Layer for NuttX, which sits between HCI layer
and low-level radio-layer. I'm starting with BLE scanning and I need
to set
a timer to periodically execute the radio reception to listen for
advertisements. I'm trying to see which interface should this layer
use:
oneshot or watchdog? From what I understand, the oneshot would use a
separate timer that of the system timer. I can only think of that
difference, is there other?
In any case, I'm not sure what would be desireable to use for this. I
like
the simplicity of the watchdog (nothing to implement) but maybe it is
better to use a separate timer?
At the hardware level, the NRF52832 is already designed to have two
identical hardware timers, one usually used for the OS and the other
for
handling BLE timeouts, so maybe using a oneshot on the second timer is
most
apropriate.
What do you think?
Best,
Matias
