Topics

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

 

Johan Hedberg
 

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

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

  • Drop your Host, use Zephyr’s
  • Port your Host to Zephyr, replacing Zephyr’s Host. This should be fairly straightforward.
  • Use another open source controller that runs of FreeRTOS (though I am not sure how easy it is to combine the controller in that stack with your Host). See nimBLE: https://github.com/apache/mynewt-nimble

 

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