Is there a plan to support Bluetooth?

[tadli]

Bluetooth can be used for sharing network, it would be cool to use Bluetooth function.

[rsta2]

There was some rudimentary BT support in Circle earlier, but it was removed for legal reasons. In my opinion it is not possible to develop BT support, without being a member of the BT SIG (Special Interest Group). Please see issue #90 for a discussion on this.

[rsta2]

I had an idea, that it may be possible to port an existing BT stack (e.g. BlueZ) to Circle. BlueZ is GPL licensed and perhaps may be ported without using the BT core specs, which is prohibited for non-BT-SIG-members.

Unfortunately I'm not familiar with BlueZ and I don't know, if it would provide all required functions, which one would need to use BT with Circle. In any way it's probably a big effort to port it.

[tadli]

Can I use bluetooth by just apt install bluez without porting bluetooth driver? I'm testing raspberry pi and I installed bluez directly to use bluetooth

[tadli]

To avoid Bluetooth membership fees, I thought maybe I could use AdHocWiFi, which can also share the network.

[sebastienNEC]

Just my 2 cents: it's relatively easy to port nimble (https://github.com/apache/mynewt-nimble) to circle. I've done it (in a hacky way but it works) and it's only a matter of modifying nimble_hci.cpp to use CBTUARTTransport and writing the OS abstraction layer nimble_npl_os.cpp

[rsta2]

@tadli I don't think, that any available BT stack will run on Circle without porting it. Unfortunately I don't expect the Circle WLAN support to work in a wireless ad hoc scenario.

@sebastienNEC Thanks for the info about nimble! This is very interesting. I will have a look on it.

[rsta2]

I had a look on NimBLE and currently I can connect a RPi 4B running the NimBLE bleprph application with my desktop PC. I used an USB BT dongle so far, not the internal BT device. Unfortunately this is only a quick porting hack and the way to some useful application and support for all internal BT devices of the different RPi models is probably long. I'm currently not sure, if it is worth going this way. NimBLE does support BLE (BT Low Energy) only, so it wouldn't help for standard BT (BR/EDR) applications. And I have no idea, for what this can be used in the end. Honestly I'm not very familiar with BT applications.

[sebastienNEC]

Hello Rene, sorry for the very late reply ! I am personally using (nim)BLE for wireless MIDI but I guess other use cases include wireless mice/keyboards ? And potentially quite a few IoT devices.
I agree though that it might not be worth continuing in this direction if there is not a big demand.
It might be enough to just document your early efforts in e.g. /doc/nimble-support.txt so that people in need of BLE don't need to start from scratch?
Just a suggestion of course :)

[rsta2]

No problem. I would be interested in using NimBLE to communicate between multiple devices (e.g. some RPis Zero W) in a mesh, like the microbit does in the image at the end of this tutorial. Unfortunately I do not know, how to implement this from the point of view of a NImBLE application. NimBLE provides many services for applications, but which have to be used?

This is really a hack so far, what I have done and describing it wouldn't help very much probably. But if there would be an interesting application, I would think about improving it.

[probonopd]

To avoid Bluetooth membership fees

Isn't Raspberry Pi Trading Ltd. paying those, and hence we are paying them by buying the devices?

[rsta2]

No, any usage of the BT core spec is prohibited, if you are not a member of the BT SIG. I cannot talk about others, but by myself I won't use it. A possibility would be to use open source source code, which is ready to be ported, so that one does not need to look into the specs. I tried this with NimBLE earlier, but realized, that most of the Raspberry Pis, that I have here, do not support the necessary version of BLE yet. Even my RPi 4B would not work with it. I have a RPi 400, which would work, probably because it uses a newer revision of the wireless chip. But, this discussion is currently difficult, because I won't have enough time left to deal with BT. I'm currently very busy, especially with the RPi 5. There is lots to do for it.

[omersiar]

I found this gem

https://www.rpi4os.com/part7-bluetooth/
It seems it isn't any different from WLAN

[rsta2]

Yes, but this does only send a BT beacon. For a reasonable BT support it would require much more. The hardware interface is not the problem. We already had this in Circle years ago (see commit 41b5650). It was removed for legal reasons.

One could only try to port some existing open source BT package, but I tried this already with NimBLE, which is BLE (low energy), but found out, that it works only on the RPi 400 (and maybe newer RPi 4B) models, so I aborted this project. I don't know about RPi 5, because it was not available at this time. I'm also not a BT expert, so this would be difficult for me.

[omersiar]

Oh did not realise about the 41b5650. Since HCI layer is covered I think I can try to get NimBLE's GATT layer to work, that can be an entry point to BLE MIDI which is simple enough.

[sebastienNEC]

I have done that (BLE MIDI with nimble, see above) a few years back, and it works indeed. @rsta2 BLE also works on raspberry pi zero W.
Let me know if you need pointers for necessary Nimble adaptations, i.e. nimble_hci.cpp and nimble_npl_os.cpp.

[omersiar]

@sebastienNEC If pointers were there do we access to all NimBLE Host APIs? GATT Server/Client? Do you know if also the Security API works?

[sebastienNEC]

I've only ever used the JustWorks association model, but there's no reason the rest should not work.

I am using both ble_gatts_* and ble_gattc_* functions, so yes both GATT server/client works.
More specifically, I am making the raspi expose a Nordic UART service (so acting as a host), and I am also scanning/connecting to BLE MIDI devices (so acting as a client)

I also tried to send raw audio over an L2CAP connection, but abandoned that, as I could not get low enough latency for my purposes.

Mind you, I was using Nimbler 1.0.0 back then, and they are quite a few versions further.

[rsta2]

BLE also works on raspberry pi zero W.

@sebastienNEC I tested my RPi 4B and it didn't work, because the supported BLE version was not sufficient. Then I tested RPi 400 and it worked. But if some RPi 4B do not work, that's a problem. Perhaps you used a newer version of NimBLE, which works with older BLE versions?

[rsta2]

If one of you guys wants to provide a BT library for Circle, it would be great! I think you have more BT knowledge than myself, so this should be easier for you. In case you want to develop such library, my suggestion would be, to do this as a separate project in your own project space on GitHub. Circle could be integrated as a submodule, like this has been done for other projects (e.g. libcamera). This would make it easier for you to develop and maintain the project. There could be a link added in the Circle Wiki to your project, so that potential users can find it more quickly. If you need modifications in Circle to be able to support BT, just let me know!

[probonopd]

Not a BLE expert, but could this be helpful in any way?

• https://github.com/rppicomidi/pico-w-ble-midi-lib

[rsta2]

Not a BLE expert, but could this be helpful in any way? * https://github.com/rppicomidi/pico-w-ble-midi-lib

This is for the RPi Pico, but it's up to @omersiar, @sebastienNEC or to anybody, who wants to deal with such a project, to decide, on what he/she wants to build on.

[omersiar]

@rsta2 Thanks for putting it in a direction. @sebastienNEC I have created the repository for it > https://github.com/omersiar/libbt (just a placeholder, structure copied from libcamera)
If you decide to share your MIDI implementation that would also greatly appreciated. I am targeting both circle's Step48 and NimBLE 1.8.0 releases.

[sebastienNEC]

Hello, sorry about the late reply ! I won't be able to contribute to the actual development unfortunately (lack of time, 2 small kids), but I can of course provide my code as it is. Give me some day to clean it up though, and I'll add it to the repository you created :)

[omersiar]

Hi,

Do you folks have any idea why in example of 41b5650, BT uart does not respond to reset command?

I have spent entire two day to troubleshoot it, first I realized my RPI 3a+ has a different chip revision, then even with the correct firmware it seems bTDeviceManager state stays at 1 (waiting for reset) but the actual command never getting be sent.

Bluetooth do work on raspi os.

Tried different config.txt options and raspberry documentation a little confusing on gpu frequency and uart baud, since in circle example they are getting checked I assumed, it should work with default settings

[omersiar]

Okay,

The culprit seems related to how UART0 is initialized, HCI reset command is written to FIFO but response (if BT chip ever responds) never got an interrupt, so the communication between chip and cpu is not working.

I tried different UART init (8N1 and FIFOs enabled) masks to some point and somehow reset command triggered an interrupt but the FIFO is always empty so nothing to carry on.

if (read32 (ARM_UART0_FR) & FR_RXFE_MASK)  // always true
{
   break;
}

From datasheet, it seems selecting 115200 baud rate can introduce some errors, tried different baud rates as well

The BCM43455 UARTs operate correctly with the host UART as long as the combined baud rate error of the two devices is within ±2%.
Table 12: Example of Common Baud Rates

[rsta2]

I tried it with commit 5f8c3f3 from the Circle repo again on a RPi 3B, which was the last commit, before BT support has been removed from Circle. That works. There has never been BT support for the RPi 3A+ in Circle and they may have changed some detail in the hardware interface for the 3A+, which came after the 3B.

[omersiar]

@rsta2 Thank you for your input, much appreciated.

You have tried with 32-bit build right? What is your config.txt look like? Never got 32-bit working, it stays at splash screen.

HCI layer seems vendor independent, so every chip out there should respond to RESET command.

[rsta2]

Yes, at this time there wasn't 64-bit support in Circle. config.txt is: arm_64bit=0 initial_turbo=0 I built with "RASPPI = 2". The resulting kernel7.img should run on RPi 2 and 3, when there is no kernel8-32.img on the SD card. I used the recent firmware, which can be downloaded in boot/ on the develop branch.

[rsta2]

The general UART HCI transport should be the same, but there may be pins, which must be set to enable BT at all and to provide necessary clocks. Also the usage of UART handshaking (RTS, CTS) pins may be different. The current driver does not care about them, which works with the RPi 3B, but not necessarily with all RPi models.

[omersiar]

I was searching for this information, what is required to configure to UART, according to datasheet the chip seems to support even 3 wire setup TX, RX, GND.

But datasheet is confusing to me, it says

The UART supports the 3-wire H5 UART transport, as described in the Bluetooth specification (Three-wire UART Transport Layer). Compared to H4, the H5 UART transport reduces the number of signal lines required by eliminating the CTS and RTS signals.

and

CTS should be held high for power on

How did you figure out the PL011 masks?

[omersiar]

Booted up raspi os to dump some information

/sys/bus/amba/devices/3f201000.serial
/sys/bus/serial-base/devices/3f201000.serial:0
/sys/bus/serial-base/devices/3f201000.serial:0.0
/sys/bus/serial/devices/serial0
/sys/bus/serial/devices/serial0-0

udevadm info /sys/class/bluetooth/hci0

P: /devices/platform/soc/3f201000.serial/serial0/serial0-0/bluetooth/hci0
M: hci0
R: 0
U: bluetooth
T: host
E: DEVPATH=/devices/platform/soc/3f201000.serial/serial0/serial0-0/bluetooth/hci0
E: SUBSYSTEM=bluetooth
E: DEVTYPE=host
E: USEC_INITIALIZED=13480732
E: SYSTEMD_ALIAS=/sys/subsystem/bluetooth/devices/hci0
E: SYSTEMD_WANTS=bluetooth.target
E: SYSTEMD_USER_WANTS=bluetooth.target
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

udevadm info /sys/bus/amba/devices/3f201000.serial

P: /devices/platform/soc/3f201000.serial
M: 3f201000.serial
U: amba
V: uart-pl011
E: DEVPATH=/devices/platform/soc/3f201000.serial
E: SUBSYSTEM=amba
E: DRIVER=uart-pl011
E: OF_NAME=serial
E: OF_FULLNAME=/soc/serial@7e201000
E: OF_COMPATIBLE_0=arm,pl011
E: OF_COMPATIBLE_1=arm,primecell
E: OF_COMPATIBLE_N=2
E: OF_ALIAS_0=serial1
E: OF_ALIAS_1=uart0
E: AMBA_ID=00241011
E: MODALIAS=amba:d00241011

udevadm info /sys/bus/serial/devices/serial0

P: /devices/platform/soc/3f201000.serial/serial0
M: serial0
R: 0
U: serial
E: DEVPATH=/devices/platform/soc/3f201000.serial/serial0
E: SUBSYSTEM=serial
E: OF_NAME=serial
E: OF_FULLNAME=/soc/serial@7e201000
E: OF_COMPATIBLE_0=arm,pl011
E: OF_COMPATIBLE_1=arm,primecell
E: OF_COMPATIBLE_N=2
E: OF_ALIAS_0=serial1
E: OF_ALIAS_1=uart0

dmesg | grep -i tty

[    2.888549] 3f201000.serial: ttyAMA1 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2
[    2.890841] serial serial0: tty port ttyAMA1 registered

dmesg | grep -i hci

[    2.814118] sdhci: Secure Digital Host Controller Interface driver
[    2.818947] sdhci: Copyright(c) Pierre Ossman
[    2.821261] sdhci-pltfm: SDHCI platform and OF driver helper
[   12.117173] Bluetooth: HCI device and connection manager initialized
[   12.117200] Bluetooth: HCI socket layer initialized
[   12.163468] Bluetooth: HCI UART driver ver 2.3
**[   12.163508] Bluetooth: HCI UART protocol H4 registered**
**[   12.172516] Bluetooth: HCI UART protocol Three-wire (H5) registered**
[   12.173185] Bluetooth: HCI UART protocol Broadcom registered
[   12.173980] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator
[   12.174513] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator
[   12.546599] Bluetooth: hci0: BCM: chip id 107
[   12.548780] Bluetooth: hci0: BCM: features 0x2f
[   12.550893] Bluetooth: hci0: BCM4345C0
[   12.550932] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[   12.560167] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd' Patch
[   13.338701] Bluetooth: hci0: BCM: features 0x2f
[   13.341105] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3+-0190
[   13.341142] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0382
[   13.341601] Bluetooth: hci0: BCM: Using default device address (43:45:c0:00:1f:ac)

hciconfig -a hci0 version

hci0:   Type: Primary  Bus: UART
        BD Address: B8:27:EB:47:D3:35  ACL MTU: 1021:8  SCO MTU: 64:1
        HCI Version: 5.0 (0x9)  Revision: 0x17e
        LMP Version: 5.0 (0x9)  Subversion: 0x6119
        Manufacturer: Cypress Semiconductor (305)

ls /proc/device-tree/soc/gpio@7e200000/uart0*

/proc/device-tree/soc/gpio@7e200000/uart0-ctsrts-gpio16:
brcm,function  brcm,pins  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0-ctsrts-gpio30:
brcm,function  brcm,pins  brcm,pull  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0-ctsrts-gpio38:
brcm,function  brcm,pins  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0-gpio14:
brcm,function  brcm,pins  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0-gpio32:
brcm,function  brcm,pins  brcm,pull  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0-gpio36:
brcm,function  brcm,pins  name  phandle

/proc/device-tree/soc/gpio@7e200000/uart0_pins:
brcm,function  brcm,pins  brcm,pull  name  phandle

cat /proc/device-tree/soc/serial@7e201000/clock-names
uartclkapb_pclk

https://github.com/raspberrypi/linux/blob/a40c744db5c0eee3ffb3fdc2e2da5e877f64f361/arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts

			  /* Used by BT module */
			  "CTS0",
			  "RTS0",
			  "TXD0",
			  "RXD0",

/* uart0 communicates with the BT module
 *
 * WL_REG_ON and BT_REG_ON of the CYW43455 Wifi/BT module are driven
 * by a single GPIO. We can't give GPIO control to one of the drivers,
 * otherwise the other part would get unexpectedly disturbed.
 */
&uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&uart0_ctsrts_gpio30 &uart0_gpio32 &gpclk2_gpio43>;
};

cat /proc/tty/driver/ttyAMA

serinfo:1.0 driver revision:
1: uart:PL011 rev2 mmio:0x3F201000 irq:99 tx:70730 rx:7034 RTS|CTS|DTR

https://github.com/RPi-Distro/pi-bluetooth/blob/master/usr/bin/btuart

[omersiar]

Difference between 3B and 3B+/3A+ is uart0_ctsrts_gpio30