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 >
