> I'm following the BLE 4.0 spec and the most I could find about timing requirements is on p.55.
Look at BLE spec vol 6, part B.4 - Air Interface protocol. If you look at the spec for BLE 5.1, a little more is written there. "The Inter Frame Space is designated “T_IFS” and shall be 150 μs." > Which part of the BLE protocol requires capture? TIMER capture + PPI enables you to get exact times of radio events. Without this you probably cannot handle TIFS or window widening properly. There is hardware support for TFIS but it is usable only for RX -> TX transition. For TX -> RX you have to use TIMER capture to know how long you should wait in RX state. > I looked a bit at Zephyr's stack, and in the process found this video which cleared some questions about the code (which is quite complex): https://www.youtube.com/watch?v=rIicvcriWR8 The code in Zephyr is complex and completely unreadable :) sob., 18 lip 2020 o 03:56 Matias N. <mat...@imap.cc> napisał(a): > I looked a bit at Zephyr's stack, and in the process found this video > which cleared some questions about the code (which is quite complex): > https://www.youtube.com/watch?v=rIicvcriWR8 > > It seems that once you get into handle multiple connections, it requires > some clever handling of communication intervals. This guy from Zephyr > developed the "mayfly" system, which is a kind of RPC system that I > understand helped him dealing with this. I think the use of the TIMER may > be tied to that. Moreover, looking at the code I found about nRF52 PPI > (Programmable Peripheral Interconnect) which lets you chain events to > tasks, to avoid doing this in ISR (one cool use is to tie GPIO outputs to > events and you can inspect low-level events of the protocol using a logic > analyzer). > > I think that I'm still far at handling all that complexity, since I will > probably just tackle the whole scanning/advertisement and connection of a > single device. > > Best, > Matias > > On Fri, Jul 17, 2020, at 16:27, raiden00pl wrote: > > > 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 > > > > > > > > > >
