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. > > > > > > > > > >
