> I'm not sure why a TIMER would be needed. Do you mean because of the RTC resolution?
To meet the BLE timing specification, we need a timer resolution in microseconds and support for BLE/RADIO events capture. There is no capture interface for RTC and maximum counter resolution is 30.5us which can be not sufficient. As far as I know, the main problem with implementing a radio based BLE stack is the time requirements. > 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 So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll prepare a PR. pt., 17 lip 2020 o 16:09 Matias N. <mat...@imap.cc> napisał(a): > 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 > > >
