Porting Zephyr HCI Layer
|
ryan.kayesimmons@...
Hi there,
I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, on the same chip.
Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!
Thank you in advance for your response. 😃
Kind Regards, Ryan Kaye-Simmons
|
|
|
|
Hi Ryan,
On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS,What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? on the same chip.That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make?The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan
|
|
|
|
ryan.kayesimmons@...
Hi Johan Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr. The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. That might be the only way to continue with my issue and to get full access to the hci & link layer? Kind Regards, Ryan Kaye-Simmons
From: Hedberg, Johan <johan.hedberg@...> Sent: Wednesday, January 15, 2020, 1:17 AM To: ryan.kayesimmons@... Cc: devel@... Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan
|
|
|
|
Carles Cufi
Hi there,
Combining the Bluetooth Host from Nordic with the Zephyr Controller is not an option, because the SoftDevice is hardcoded to contain both Host and Controller and they cannot be decoupled. I understand that you have your own Host running on FreeRTOS that you want to combine with the Zephyr Link Layer. Porting the Zephyr controller to FreeRTOS is not going to be trivial, but it shouldn’t be too hard either if you are willing to do the work and maintain it. The controller uses mainly bare-metal with some Zephyr-specific primitives mostly in HCI and the ULL.
Here you have the following options:
Carles
From: devel@... <devel@...>
On Behalf Of ryan.kayesimmons via Lists.Zephyrproject.Org
Sent: 14 January 2020 22:26 To: Hedberg, Johan <johan.hedberg@...> Cc: devel@... Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer
Hi Johan
Thank you for your quick reply.
Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips.
In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.
The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. That might be the only way to continue with my issue and to get full access to the hci & link layer?
Kind Regards, Ryan Kaye-Simmons
From: Hedberg, Johan <johan.hedberg@...>
|
|
|