nimble/transport: Add generic IPC transport with flow control

This adds generic IPC transport that should be used as a base for any
transport with LL on separate core. It's similar to HCI H4, but has a
bit different header to simplify processing and supports internal flow
control to make sure LL does not send data that other core does not have
free buffers for.

IPC transport requires memory shared between cores to keep track of
number of available buffers on application core. Application core will
initialize counters to total number of available buffers. Then on each
alloc LL will atomically test and decrease relevan counter and will
allocate buffer only if that counter was non-zero. The counter will be
increased by application core if relevant buffer was freed.
10 files changed
tree: 2bb3334b3d428a58256a6564c4cc85aef91ff1fd
  1. apps/
  2. babblesim/
  3. docs/
  4. ext/
  5. nimble/
  6. porting/
  7. targets/
  8. tools/
  9. .gitignore
  10. .mailmap
  11. .rat-excludes
  12. .style_ignored_dirs
  13. .travis.yml
  16. NOTICE
  19. repository.yml
  20. uncrustify.cfg
  21. version.yml


Apache NimBLE is an open-source Bluetooth 5.1 stack (both Host & Controller) that completely replaces the proprietary SoftDevice on Nordic chipsets. It is part of Apache Mynewt project.

Feature highlight:

  • Support for 251 byte packet size.
  • Support for all 4 roles concurrently - Broadcaster, Observer, Peripheral and Central
  • Support for up to 32 simultaneous connections.
  • Legacy and SC (secure connections) SMP support (pairing and bonding).
  • Advertising Extensions.
  • Periodic Advertising.
  • Coded (a.k.a. Long Range) and 2M PHYs.
  • Bluetooth Mesh.

Supported hardware

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)

Sample Applications

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:

  • blecent: A basic central device with no user interface. This application scans for a peripheral that supports the alert notification service (ANS). Upon discovering such a peripheral, blecent connects and performs a characteristic read, characteristic write, and notification subscription.
  • blehci: Implements a BLE controller-only application. A separate host-only implementation, such as Linux's BlueZ, can interface with this application via HCI over UART.
  • bleprph: An implementation of a minimal BLE peripheral.
  • btshell: A shell-like application allowing to configure and use most of NimBLE functionality from command line.
  • bleuart: Implements a simple BLE peripheral that supports the Nordic UART / Serial Port Emulation service (

External projects using NimBLE

Several other projects provide support for using NimBLE either by NPL port or forking:

If you publish a NimBLE port, please let us know to include it here!

Getting Help

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.

Pull Requests

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

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.

Filing Bugs

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

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.

Writing Tests

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.