页次: 1
audio_source_demo 跑起来,声音很卡,试过关掉log,或者:
[2018-05-20 05:40:14.238] LOG -- hci.c.2800: hci_power_control: 1, current mode 0
[2018-05-20 05:40:14.239] LOG -- btstack_uart_block_posix.c.177: h4_set_baudrate 1500000
[2018-05-20 05:40:14.339] LOG -- hci_transport_h5.c.816: enable even parity for BCSP mode
[2018-05-20 05:40:14.340] LOG -- hci_transport_h5.c.830: UART driver does not provide compatible sleep mode
[2018-05-20 05:40:14.341] LOG -- hci_transport_h5.c.720: resend timeout for 1500000 baud: 77 ms
[2018-05-20 05:40:14.341] LOG -- hci.c.3859: BTSTACK_EVENT_STATE 1
读了下源码,发现这个文章讲得比较清晰。 https://blog.csdn.net/zjli321/article/details/52122447
uart接口蓝牙的fw download及config配置工作也放到了应用层,这些工作都是由hciattach来实现。串口的使用有一个切换的过程,在初始化的时候,由hciattach使用串口,初始化完成后,把串口切换给hci使用,hci负责与串口交互蓝牙数据,中间还经过了h4/h5协议层,驱动层跟移植相关只有h4/h5协议,若h4/h5使用的是内核自带的协议,那驱动层就不需要做任何的工作。 只有uart接口的蓝牙才需要hciattach工具,hciattach的作用为配置串口,下载fw及config文件,把串口切换给hci_ldisc使用。
CTS/RTS 那个引脚下拉没?或者接串口对应引脚。
都正确连接了,需要时也会给出的低电平。在内核里处理了协议栈的驱动加载之后,可以使用。
然而,目前最头大的问题是,经常启动之后,对于rtk_hciattach的输出,蓝牙模块是完全不给回应的。
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5
Realtek Bluetooth :Realtek hciattach version 2.5
Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8
...
Realtek Bluetooth :3-wire sync pattern resend : 40, len: 8
Realtek Bluetooth ERROR: H5 sync timed out
即使对BT_RST引脚手工进行拉低的reset,再去连接,也是不理的。
彻底断电重启也只是偶尔可以回应。一旦回应则蓝牙各种功能都正常。
发现是模块的复位问题,多复位几次就有进展了:
> ./rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5
Realtek Bluetooth :Realtek hciattach version 2.5
Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 2, len: 8
Realtek Bluetooth :Get SYNC Resp Pkt
Realtek Bluetooth :3-wire config pattern resend : 1 , len: 10
Realtek Bluetooth :Get CONFG resp pkt-active mode
Realtek Bluetooth :H5 init finished
Realtek Bluetooth :config offset(f4),length(8)
Realtek Bluetooth :config baud rate to :4928002, hwflowcontrol:5f, 1
Realtek Bluetooth :config offset(27),length(1)
Realtek Bluetooth :config offset(fe),length(1)
Realtek Bluetooth :config offset(15b),length(4)
Realtek Bluetooth :config offset(1e3),length(1)
Realtek Bluetooth :Get config baud rate from config file:4928002
Realtek Bluetooth :Load FW OK
Realtek Bluetooth :RTK send HCI_VENDOR_READ_RTK_ROM_VERISION_Command
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth :RTK get HCI_VENDOR_READ_RTK_LMP_VERISION_Command
Realtek Bluetooth :rtk get lmp version timeout, retry: 0
Realtek Bluetooth :Peer acked invalid packet
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth ERROR: h5 hdr checksum error!!!
Realtek Bluetooth :RTK get HCI_VENDOR_READ_RTK_LMP_VERISION_Command
Realtek Bluetooth :rtk get lmp version timeout, retry: 1
暂时卡在这个问题上了
这个问题也浪费了我几个小时,后来拿云盘上给的那个rootfs来对比,才发现:
1. arm-linux-gnueabi 这个工具链用来编译内核没有问题,编译应用则会出现问题;
2. 编译应用的问题,是因为工具链所附加的库,是面向Cortex A7来编译的;因为假如只编译,不链接: arm-linux-gnueabi-gcc -Q -v -c -mcpu=arm926ej-s hello.c ,然后用readelf -A hello.o,会发现:Tag_CPU_name: "ARM926EJ-S";但只要链接了库,就成了:Tag_CPU_name: "7-A"
3. 解决方法,重新编译工具链,使得它附带的库是用于ARM926EJ-S的,方法是:
https://briolidz.wordpress.com/2012/02/07/building-embedded-arm-systems-with-crosstool-ng/
http://unisim-vp.org/site/crosstool-arm-926ejs-linux-gnueabi-how-to.html
4. 之后再使用编译出来的external toolchain,也是完全OK的。
页次: 1