> 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.
I'm following the BLE 4.0 spec and the most I could find about timing requirements is on p.55. It states that two clock resolutions are acceptable, depending on the power consumption of the device, and mostly speaks about deviations in ppm. Regarding resolution, for now I saw timings in the order of ms (for example, some interval in units of 1.25ms), not us. It would seem the RTC timer meets this. On the other hand, it is true it does not support capture. Which part of the BLE protocol requires capture? I'm learning the protocol as I go, so I'm not fully aware of the whole complexity of the system. > > 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. Great, I will have a look when you do and base my work on that. PS: have you seen https://github.com/apache/incubator-nuttx/issues/1416 ? > > 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 > > > > > >
