Hi Mateusz, This is a great idea! Note that zGlue did exactly it, but they are using nRF52.
Maybe Sony or Xiaomi has something similar implemented for NuttX and could help. Guys, are you hearing? Xiang? Masayuki? BR, Alan On 6/17/20, raiden00pl . <raiden0...@gmail.com> wrote: > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few > hacks even Nordic SDK can be integrated with Nuttx. > This gives you a certified BLE stack but it has a huge disadvantage - it is > a closed source. Looking for bugs in such an environment is a nightmare. > > Some time ago I started working on the BLE stack for NRF52 integrated with > Nuttx, but I don't have much done at the moment. > I don't think there is an easy way to port the Zephyr BLE stack to Nuttx. > It > looks just as much work as writing it from scratch. > > śr., 17 cze 2020 o 03:32 Matias N. <mat...@imap.cc> napisał(a): > >> Not sure what you mean by "slave" in this case. What I'm referring to is >> the access to the low-level Bluetooth hardware (register based access to >> radio peripheral). I didn't meant NuttX's BLE stack would only support >> HCI >> UART, I mean that there's no support for NRF radio (link-level layer) on >> NuttX yet. >> >> In other words, using Zephyr figures from their docs, the idea would be >> to >> support this scenario (replace Zephyr with NuttX): >> https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png >> >> Whereas NuttX currently supports the scenario on the left of this figure: >> https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png >> >> As you mention, this requires code which interfaces the upper bluetooth >> stack with the low-level radio hardware. This is the code that is >> available >> un Zephyr under Apache 2.0 license. >> >> Best, >> Matias >> >> On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: >> > >> > > AFAIK NuttX supports the Host level API and at most HCI UART >> interface. I'm referring to the link-level code which interfaces directly >> with NRF51822 so that you can run NuttX in the board itself (and not as >> an >> external module via UART). >> > It supports both host and slave and uses a driver defined by and >> > interface. HCI UART is *not* assumed or required. I don't know that it >> > is compatible with the NRF. I imagine you would have to use the NRF >> stack. >> > >> >
