Zephyr Project BLE vs Mynewt NimBLE - Page 1
Forum section: electronics / general

author: Terence
author_rank: Newbie
timestamp: September 27, 2021, 03:10:26 pm
content: Hi all,As I mention inhttps://www.eevblog.com/forum/microcontrollers/abstraction-layer-for-da1469x/msg3679534/#msg3679534, I am looking to create a port for the DA1469x for an open source hal.Currently, my eyes are on Arduino and MicroPython. The BLE part of the DA1469x SDK is not open source. My goal is to create a fully open source port, therefore, I am looking at Zephyr and Mynewt NimBLE as an open source BLE stack replacement. If I look at other MicroPython ports, STM32, ESP32, and Unix, they all went for NimBLE. When I compare Zephyr and Mynewt populair wise, as an RTOS, Zephyr comes out on top.Could anyone share their experience with Zephyr and Mynewt NimBLE, and possibly, why Zephyr or Mynewt might be better?I am grateful for any feedback and please do not hesitate to ask me questions.

author: devan
author_rank: Contributor
timestamp: September 28, 2021, 09:00:52 am
content: Personally I'm rather fond of Zephyr from my experiments so far, though I haven't used their BLE stack or built anything substantial with it.However, I will note that NimBLE has a big leg up in this case if you want BLE - someone's already ported the full NimBLE stack to run on the DA1469x! See this mailing list message:https://www.mail-archive.com/dev@mynewt.apache.org/msg01804.htmlTo elaborate a bit on why that's important, there are roughly two major components to many BLE stacks - the host layer that manages the high-level functionality like GATT and the controller layer that handles the low-level radio timing. The host layer and controller layer can be separated to run on different processors and communicate through a standardized protocol named "Host-Controller Interface" or "HCI."The host portion is typically very portable since the HCI is standardized and more-or-less hardware independent. The implementation might need some OS abstraction to manage timers or threads, but typically it has very modest timing/latency requirements on the order of milliseconds.In contrast, the controller layer has to manage the radio hardware to very tight timing tolerances on the order of tens of microseconds. If you peek inside the NimBLE controller implementation, you'll find that the HAL actually includes an entire real-time scheduler built around a hardware timer. So porting the controller portion is quite a lot of work. Often instead of trying to port the controller, the controller runs in a separate chip that just runs the controller firmware and then the host stack talks to that controller through HCI. I'm fairly certain that the ESP32 port is just the host portion, and that's likely the case for STM32 port as well.The Nordic nRF51/52 series is somewhat of a standout exception in having the luxury of three different complete open-source BLE host + controller ports targeting it. It's pretty amazing that there's even a single open-source option for the DA1469x, honestly. For most other single-chip solutions, you pretty much have to use the vendor's BLE controller implementation and that's that.I'm sure the Zephyr community would welcome a port of their controller to the DA1469x if you wanted to go that route, but it's a pretty substantial commitment.