commit | afbbeace7053d866aa8b52fadb13d9dc92de1897 | [log] [tgz] |
---|---|---|
author | Andrzej Kaczmarek <andrzej.kaczmarek@codecoup.pl> | Thu Dec 05 17:04:31 2019 +0100 |
committer | Andrzej Kaczmarek <andrzej.kaczmarek@codecoup.pl> | Mon Dec 09 19:15:56 2019 +0100 |
tree | 277eb30487b9e32993d414e10d2d0f6f4a90d3f0 | |
parent | 0e9dd72964677c21db0d78a49e4be410daf4ec66 [diff] |
nimble/ll: Fix recalculating rfclk start ble_ll_xcvr_rfclk_timer_start() assumes that it should not reschedule rfclk if it's already scheduled before requested tick. This is correct since it may be called it different contexts, however when called from ble_ll_sched_rfclk_chk_restart() we expect that rfclk will be scheduled for a first item in scheduler and this may not work as expected. Consider following scenario (one of many): - connection is active - sync with periodic advertising is active - scaner is active - sync scan item is in scheduler - next connection event item is scheduled *after* above sync scan item At this point we have rfclk timer set to fire at sync scan item. And now interesting things will happen: - terminate sync which removes sync scan item from scheduler - disable scan If both of the above happen before scheduled connection event item, we have a problem. This is because when sync scan item was removed, we did not move rfclk timer to connection event item because rfclk code checked that it already has rfclk scheduled before requested time. This means rfclk will be enabled at the time of removed sync scan item, but it will not be rescheduled to connection event item since there is no scheduler item do do this. So far so good - we still have rfclk enabled. But then we have scan disable which disables rfclk since connection event item is apparently far enough in the future so this is allowed. As a result we do not have rfclk enabled for a connection event. To fix this we make sure that every time we reevaluate scheduler for rfclk change, we need to stop existing timer so it can be always started for a proper item.
Apache NimBLE is an open-source Bluetooth 5.0 stack (both Host & Controller) that completely replaces the proprietary SoftDevice on Nordic chipsets. It is part of Apache Mynewt project.
Features highlight:
Controller supports Nordic nRF51 and nRF52 chipsets. Host runs on any board and architecture supported by Apache Mynewt OS.
If you are browsing around the source tree, and want to see some of the major functional chunks, here are a few pointers:
nimble/controller: Contains code for controller including Link Layer and HCI implementation (controller)
nimble/drivers: Contains drivers for supported radio transceivers (Nordic nRF51 and nRF52) (drivers)
nimble/host: Contains code for host subsystem. This includes protocols like L2CAP and ATT, support for HCI commands and events, Generic Access Profile (GAP), Generic Attribute Profile (GATT) and Security Manager (SM). (host)
nimble/host/mesh: Contains code for Bluetooth Mesh subsystem. (mesh)
nimble/transport: Contains code for supported transport protocols between host and controller. This includes UART, emSPI and RAM (used in combined build when host and controller run on same CPU) (transport)
porting: Contains implementation of NimBLE Porting Layer (NPL) for supported operating systems (porting)
ext: Contains external libraries used by NimBLE. Those are used if not provided by OS (ext)
kernel: Contains the core of the RTOS (kernel/os)
There are also some sample applications that show how to Apache Mynewt NimBLE stack. These sample applications are located in the apps/
directory of Apache Mynewt repo. Some examples:
If you are having trouble using or contributing to Apache Mynewt NimBLE, or just want to talk to a human about what you're working on, you can contact us via the developers mailing list.
Although not a formal channel, you can also find a number of core developers on the #mynewt channel on Freenode IRC or #general channel on Mynewt Slack
Also, be sure to checkout the Frequently Asked Questions for some help troubleshooting first.
Anybody who works with Apache Mynewt can be a contributing member of the community that develops and deploys it. The process of releasing an operating system for microcontrollers is never done: and we welcome your contributions to that effort.
More information can be found at the Community section of the Apache Mynewt website, located here.
Apache Mynewt welcomes pull request via Github. Discussions are done on Github, but depending on the topic, can also be relayed to the official Apache Mynewt developer mailing list dev@mynewt.apache.org.
If you are suggesting a new feature, please email the developer list directly, with a description of the feature you are planning to work on.
Bugs can be filed on the Apache Mynewt NimBLE Issues. Please label the issue as a “Bug”.
Where possible, please include a self-contained reproduction case!
Feature requests should also be filed on the Apache Mynewt NimBLE Bug Tracker. Please label the issue as a “Feature” or “Enhancement” depending on the scope.
We love getting newt tests! Apache Mynewt is a huge undertaking, and improving code coverage is a win for every Apache Mynewt user.
The code in this repository is all under either the Apache 2 license, or a license compatible with the Apache 2 license. See the LICENSE file for more information.