I've been looking a bit more into how Zephyr code handles the NRF chips and how the Bluetooth stack is organized, see here: https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller
From what I understand, they can either talk to a controller via HCI UART/SPI or directly to the chip's radio peripheral via vendor HAL. There's a link-layer (ll_sw directory) which I understand is their abstract interface into on-chip radio peripherals such as Nordic. The Nordic specific part is really thin, the HAL mostly sets registers directly and doesn't have much logic to it. I also looked at how NuttX is organized and it would appear that the host-level stack assumes a controller stack based on HCI interface commands. From what I've read, for on-chip radio peripheral there isn't a standardized interface proposed. So, this could be either handled by creating a fake HCI wrapper to on-chip radio peripheral to satisfy what NuttX's host-level stack expects (may be inefficient) or extend this part to support talking to the controller via HCI or a NuttX defined interface for on-chip peripherals. As I mentioned, I don't really know about Bluetooth internals but it would appear that lower-level part missing should not be that difficult to implement since the host-level stack is already implemented in NuttX. Also, the RADIO section of the nRF51 reference manual is pretty straightforward. Best, Matias On Thu, Jun 18, 2020, at 02:28, raiden00pl . wrote: > I agree that access to low-level radio with documented registers is a big > plus for Nordic. > I hope other vendors will follow the same path (if not then we always have > reverse engineering :P). > For this reason, we should have a standardized interface for BLE > single-chip solutions in Nuttx. > A non-standardized BLE stack probably won't have much value in commercial > products, but for amateur projects it would be a great tool. > > śr., 17 cze 2020 o 17:00 Matias N. <mat...@imap.cc> napisał(a): > > > I saw that option recently and I don't really like it. It seems a > > debugging nightmare. > > What I actually like about Nordic is that at least it is possible to have > > an open-source low-level radio stack, which is not the case for Espressif > > since this is still closed source and undocumented. So I think the best > > path is to get proper support for this part in NuttX. > > > > But yes, maybe it is not really a porting effort but writing something > > from scratch. But even in that case it is good to have a working reference > > such as Zephyr. IMHO it would really be worth the effort. Support for > > Nordic/Espressif radio is what is attractive in other RTOSs, such as > > Zephyr. > > > > Best, > > Matias > > > > On Wed, Jun 17, 2020, at 04:06, raiden00pl . 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. > > > > > > > > > > > > > > >
