Hi Matias, On 6/18/20, Matias N. <mat...@imap.cc> wrote: > 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. >
Exactly, and if you see their two approach diagram the refer to "HCI" in RAM communicating with the chip registers. So probably this layer is just a "fake" HCI implementation. > 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. > Yes, it should be a nice improvement to have it! BR, Alan
