HCI SPI - how to use


Piotr Barszczewski <piotr@...>
 

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an implementation available https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html 
I’m wondering how could this actually be tested - just by sending raw HCI bytes to the board flashed with https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi ?

My interest is in somehow making it possible for embedded Linux distribution be able to use SPI transport for HCI. With all the chip shortages of recent months and unsure about future I’m looking for a way to get rid of relying on USB. Uart would be good but is already used + I need more than 1, so besides USB I’ve only got SPI left but not sure how it’s supposed to be tested. Guess I’m missing what the host should do, with USB it’s clear.

Is there anybody who has prior experience with running the HCI SPI implementation?

Best regards
 


Bolivar, Marti
 

Hi,

The hci_spi sample was originally upstreamed for use on the nRF51 chip
on the 96Boards Carbon board.

Please refer to the documentation for that board for more information.
You can refer to 96b_carbon and 96b_carbon_nrf51 board configurations as
a starting point for your own application.

Marti

"Piotr Barszczewski via lists.zephyrproject.org"
<piotr=1am.pl@lists.zephyrproject.org> writes:

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an
implementation available
https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html
I’m wondering how could this actually be tested - just by sending raw HCI
bytes to the board flashed with
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi
?

My interest is in somehow making it possible for embedded Linux
distribution be able to use SPI transport for HCI. With all the chip
shortages of recent months and unsure about future I’m looking for a way to
get rid of relying on USB. Uart would be good but is already used + I need
more than 1, so besides USB I’ve only got SPI left but not sure how it’s
supposed to be tested. Guess I’m missing what the host should do, with USB
it’s clear.

Is there anybody who has prior experience with running the HCI SPI
implementation?

Best regards



Piotr Barszczewski <piotr@...>
 

Hi,

I’ll look into it and the board definitions. I think this was the part I’ve missed, that the project has 2 96b_carbon and 96b_carbon_nrf51 board configurations which are not part of the example but Zephyr boards definition. Thank you for pointing that out.

Best regards,
PB

On 14 August 2021 at 02:30:47, Bolivar, Marti (marti.bolivar@...) wrote:

Hi,

The hci_spi sample was originally upstreamed for use on the nRF51 chip
on the 96Boards Carbon board.

Please refer to the documentation for that board for more information.
You can refer to 96b_carbon and 96b_carbon_nrf51 board configurations as
a starting point for your own application.

Marti

"Piotr Barszczewski via lists.zephyrproject.org"
<piotr=1am.pl@...> writes:

> Hello,
>
> I’ve found that Zephyr HCI stack supports SPI as transport and there is an
> implementation available
> https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html
> I’m wondering how could this actually be tested - just by sending raw HCI
> bytes to the board flashed with
> https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi
> ?
>
> My interest is in somehow making it possible for embedded Linux
> distribution be able to use SPI transport for HCI. With all the chip
> shortages of recent months and unsure about future I’m looking for a way to
> get rid of relying on USB. Uart would be good but is already used + I need
> more than 1, so besides USB I’ve only got SPI left but not sure how it’s
> supposed to be tested. Guess I’m missing what the host should do, with USB
> it’s clear.
>
> Is there anybody who has prior experience with running the HCI SPI
> implementation?
>
> Best regards
>
>
>