android7蓝牙笔记

1 代码位置 魔窟

蓝牙协议目录:system/bt
蓝牙vendor层目录:hardware/broadcom/libbt
linux

2 启动 万恶之源

system/bt/hci/src/hci_layer.cios

static future_t *start_up(void) {
.......
 startup_timer = alarm_new("hci.startup_timer");
 .......
 alarm_set(startup_timer, startup_timeout_ms,startup_timer_expired, NULL);
......  
vendor->set_callback(VENDOR_CONFIGURE_FIRMWARE, firmware_config_callback);.
......
  int power_state = BT_VND_PWR_OFF;
#if (defined (BT_CLEAN_TURN_ON_DISABLED) && BT_CLEAN_TURN_ON_DISABLED == TRUE)
  LOG_WARN(LOG_TAG, "%s not turning off the chip before turning on.", __func__);
  // So apparently this hack was needed in the past because a Wingray kernel driver
  // didn't handle power off commands in a powered off state correctly.

  // The comment in the old code said the workaround should be removed when the
  // problem was fixed. Sadly, I have no idea if said bug was fixed or if said
  // kernel is still in use, so we must leave this here for posterity. #sadpanda
#else
  // cycle power on the chip to ensure it has been reset
  vendor->send_command(VENDOR_CHIP_POWER_CONTROL, &power_state);
#endif
  power_state = BT_VND_PWR_ON;
  vendor->send_command(VENDOR_CHIP_POWER_CONTROL, &power_state);
  ......
    thread_post(thread, event_finish_startup, NULL);
  return local_startup_future;
  }

代码解释:
1 建立startup_timer
2 启动startup_timer
3 reset 蓝牙模块
4 event_finish_startup 将startup最后过程放到线程中执行
startup_timer 定时器:设定蓝牙配置时间,若是超时则认为配置失败 。




数组

先power off 再power on,完成对蓝牙模块的reset。event_finish_startup 过程在线程中作,若是在startup_timer定义的时间内没有完成则认为失败,将重复整个初始化过程。app

3配置 绞肉厂

上一步结尾的函数event_finish_startup 就是配置的开始异步

static void event_finish_startup(UNUSED_ATTR void *context) {
  LOG_INFO(LOG_TAG, "%s", __func__);
  hal->open();
  vendor->send_async_command(VENDOR_CONFIGURE_FIRMWARE, NULL);
}

代码简单,但程序中越简单,越折磨人。
hal是 hci_hal_t 类型的结构体:
async

typedef struct hci_hal_t {
  bool (*init)(const hci_hal_callbacks_t *upper_callbacks, thread_t *upper_thread);
  bool (*open)(void);
  void (*close)(void);
  size_t (*read_data)(serial_data_type_t type, uint8_t *buffer, size_t max_size);
  void (*packet_finished)(serial_data_type_t type);
  uint16_t (*transmit_data)(serial_data_type_t type, uint8_t *data, uint16_t length);
} hci_hal_t;

很是熟悉的配方,linux 中太多这种定义接口的方式了。
hci_hal_t 是HCI调用hal层的接口,及我将要用到这些函数,hal 层去实现至于怎么实现这里不关心.
蓝牙芯片与CPU通信方式是多样的,能够是串口、usb、pcie等等,具体通信接口是哪种hci 层是不关心的,因此HCI层定义hci_hal_t 接口但不实现。

ide

vendor 是vendor_t 结构体:函数

typedef struct vendor_t{
  bool (*open)( const uint8_t *local_bdaddr,const hci_t *hci_interface);
  void (*close)(void);
  int (*send_command)(vendor_opcode_t opcode, void *param);
  int (*send_async_command)(vendor_async_opcode_t opcode, void *param);
  void (*set_callback)(vendor_async_opcode_t opcode, vendor_cb callback);
} vendor_t;

多么熟悉的配方,与hal相似,也是接口。
vendor打开的是so库,这个由hardware/broadcom/libbt 生成,固然不一样的厂商生成不一样的so,这里用的是broadcom的芯片,因此用到的是hardware/broadcom/libbt 生成的so库
接口的做用根据名字基本就能判断,这里不展开了。
执行完 vendor->send_async_command(VENDOR_CONFIGURE_FIRMWARE, NULL);初始化过程就算完成了,剩下的事情,交给vendor层去处理。


post

hci层的start_up虽然执行完了,可是并不表明配置成功,由于
vendor->send_async_command(VENDOR_CONFIGURE_FIRMWARE, NULL);
是放到线程中执行的,那hci 怎么知道配置是否成功呢?
这就用到了startup_timer了。


ui

//启动定时器
//startup_timer 定时器
// startup_timeout_ms 超时时间,
//startup_timer_expired 超时回调函数,
alarm_set(startup_timer, startup_timeout_ms,startup_timer_expired, NULL);

当定时器超时调用startup_timer_expired 则配置失败。那怎样才算成功呢?

//设置VENDOR_CONFIGURE_FIRMWARE 命令的回调函数为firmware_config_callback
vendor->set_callback(VENDOR_CONFIGURE_FIRMWARE, firmware_config_callback);.

看看firmware_config_callback函数:

static void firmware_config_callback(UNUSED_ATTR bool success) {
  LOG_INFO(LOG_TAG, "%s", __func__);

  alarm_cancel(startup_timer);

  pthread_mutex_lock(&commands_pending_response_lock);

  if (startup_future == NULL) {
    // The firmware configuration took too long - ignore the callback
    pthread_mutex_unlock(&commands_pending_response_lock);
    return;
  }

  firmware_is_configured = true;
  future_ready(startup_future, FUTURE_SUCCESS);
  startup_future = NULL;

  pthread_mutex_unlock(&commands_pending_response_lock);
}

因此在VENDOR_CONFIGURE_FIRMWARE执行完后会地用
firmware_config_callback
而firmware_config_callback中会执行
alarm_cancel(startup_timer);
此时就会中止startup_timer定时器,startup_timer_expired就不会被调用



4 vendor 层初始化 王婆

就是对vendor_t 结构体的填充

typedef struct vendor_t{
  /××××××
  ×打开so库
  ×local_bdaddr 不知道神码用
  ×hci_interface 这个是hci层提供给vendor层的接口(又是接口),比较重要
  ×××××××××××××/
  bool (*open)( const uint8_t *local_bdaddr,const hci_t *hci_interface); 
  /××××××××××××
  ×关闭 没什么好讲的
  ××××××××××××××××/
  void (*close)(void);
  /×××××××××××××
  ×发送同步命令,param是命令携带参数
  ××××××××××××××/
  int (*send_command)(vendor_opcode_t opcode, void *param);
  /×××××××××××××
  ×发送异步命令,param是命令携带参数
  ××××××××××××××/
  int (*send_async_command)(vendor_async_opcode_t opcode, void *param);
  /×××××××××××××
  ×设置命令的回调函数
  ××××××××××××××/
  void (*set_callback)(vendor_async_opcode_t opcode, vendor_cb callback);
} vendor_t;

代码这里就不贴了,大概说明一下:
代码位置hci/source/vendor.c
open函数主要是打开so 库:
static const char *VENDOR_LIBRARY_NAME = “libbt-vendor.so”;
并赋值给lib_interface ,



lib_handle = dlopen(VENDOR_LIBRARY_NAME, RTLD_NOW);
  lib_interface = (bt_vendor_interface_t *)dlsym(lib_handle, VENDOR_LIBRARY_SYMBOL_NAME);

该so中提供三个函数:

/*
 * Bluetooth Host/Controller VENDOR Interface
 */
typedef struct {
    size_t          size;
    int   (*init)(const bt_vendor_callbacks_t* p_cb, unsigned char *local_bdaddr);
    int (*op)(bt_vendor_opcode_t opcode, void *param);
    void  (*cleanup)(void);
} bt_vendor_interface_t;

从代码来看同步命令和异步命令都是调用的 op接口,因此二者起始没区别
这里面没有看到vendor_t 中set_callback 对应的接口:

static void set_callback(vendor_async_opcode_t opcode, vendor_cb callback) {
  callbacks[opcode] = callback;
}

因此从代码来看,set_callback 只是将回调函数放入了数组中,与so无关系,可是so是怎么用到这些回调函数的呢?那就要看callbacks 的用法了。
在vendor.c中定义了不少后缀为cb的函数,如firmware_config_cb:
该函数从数组中取出VENDOR_CONFIGURE_FIRMWARE 对应的回调函数并执行

// Called back from vendor library when the firmware configuration
// completes.
static void firmware_config_cb(bt_vendor_op_result_t result) {
  LOG_INFO(LOG_TAG, "firmware callback");
  vendor_cb callback = callbacks[VENDOR_CONFIGURE_FIRMWARE];
  assert(callback != NULL);
  callback(result == BT_VND_OP_RESULT_SUCCESS);
}

而firmware_config_cb 被赋值给了以下结构体,这里还有其余全部cb后缀的函数

static const bt_vendor_callbacks_t lib_callbacks = {
  sizeof(lib_callbacks),
  firmware_config_cb,
  sco_config_cb,
  low_power_mode_cb,
  sco_audiostate_cb,
  buffer_alloc_cb,
  buffer_free_cb,
  transmit_cb,
  epilog_cb,
  a2dp_offload_cb
};

lib_callbacks 在open函数中 传递给了so库

int status = lib_interface->init(&lib_callbacks, (unsigned char *)local_bdaddr);

因此整个vendor.c就是在给hci 与libbt-vendor.so 牵线搭桥
给他取个别名王婆不过度。
这一层其实能够忽略,只要知道,commend 由vendor层处理,处理完后会调用相应的回调函数就能够了。

5 vendor 配置蓝牙 干活的人

这一层的代码跟soc 密切相关,因此不一样平台这里的代码区别会有许多区别,但基本逻辑基本同样。
蓝牙vendor层目录:hardware/broadcom/libbt
前面的分析都是在hci层, 下面进入vendor层,这一层是干实事的,hci层只是发送一些命令,vendor层处理这些命令,并调用相应回调函数返回调用结果。
hci层用到的libbt-vendor.so 就是这一层代码生成的。


回头来看VENDOR_CONFIGURE_FIRMWARE的执行过程:
首先要说明的是:
VENDOR_CONFIGURE_FIRMWARE = BT_VND_OP_FW_CFG,
及在vendor层VENDOR_CONFIGURE_FIRMWARE 叫BT_VND_OP_FW_CFG
在op函数中有各个命令的处理过程
BT_VND_OP_FW_CFG命令的处理函数 hw_config_start:




void hw_config_start(void)
{
    HC_BT_HDR  *p_buf = NULL;
    uint8_t     *p;

    hw_cfg_cb.state = 0;
    hw_cfg_cb.fw_fd = -1;
    hw_cfg_cb.f_set_baud_2 = FALSE;
    //ALOGE("dzw %s",__func__);
    /* Start from sending HCI_RESET */

    if (bt_vendor_cbacks)
    {
        p_buf = (HC_BT_HDR *) bt_vendor_cbacks->alloc(BT_HC_HDR_SIZE + \
                                                       HCI_CMD_PREAMBLE_SIZE);
    }

    if (p_buf)
    {
        p_buf->event = MSG_STACK_TO_HC_HCI_CMD;
        p_buf->offset = 0;
        p_buf->layer_specific = 0;
        p_buf->len = HCI_CMD_PREAMBLE_SIZE;

        p = (uint8_t *) (p_buf + 1);
        UINT16_TO_STREAM(p, HCI_RESET);
        *p = 0; /* parameter length */

        hw_cfg_cb.state = HW_CFG_START;

        bt_vendor_cbacks->xmit_cb(HCI_RESET, p_buf, hw_config_cback);
    }
    else
    {
        if (bt_vendor_cbacks)
        {
            ALOGE("vendor lib fw conf aborted [no buffer]");
            bt_vendor_cbacks->fwcfg_cb(BT_VND_OP_RESULT_FAIL);
        }
    }
}

首先分配了一个HC_BT_HDR 类型的结构体:

p_buf = (HC_BT_HDR *) bt_vendor_cbacks->alloc(BT_HC_HDR_SIZE + \
                                                       HCI_CMD_PREAMBLE_SIZE);

bt_vendor_cbacks 即 在HCI调用so的init时传入的hci层接口,对p_buf进行赋值,
而后调用

bt_vendor_cbacks->xmit_cb(HCI_RESET, p_buf, hw_config_cback);

这里又回到hci层去执行命令了,调来调去,別晕,先放一边默认它调用成功,后面再分析,跳来跳去容易乱。
成功后执行hw_config_cback,这里注意一行代码:
hw_cfg_cb.state = HW_CFG_START;
hw_config_cback中是许多case


switch(hw_cfg_cb.state){
 。。。。。
      case HW_CFG_START:
        if (UART_TARGET_BAUD_RATE > 3000000)
        {
            /* set UART clock to 48MHz */
            UINT16_TO_STREAM(p, HCI_VSC_WRITE_UART_CLOCK_SETTING);
            *p++ = 1; /* parameter length */
            *p = 1; /* (1,"UART CLOCK 48 MHz")(2,"UART CLOCK 24 MHz") */

            p_buf->len = HCI_CMD_PREAMBLE_SIZE + 1;
            hw_cfg_cb.state = HW_CFG_SET_UART_CLOCK;

            is_proceeding = bt_vendor_cbacks->xmit_cb( \
                                HCI_VSC_WRITE_UART_CLOCK_SETTING, \
                                p_buf, hw_config_cback);
            break;
        }
        /* fall through intentionally */
    case HW_CFG_SET_UART_CLOCK:
        /* set controller's UART baud rate to 3M */
        UINT16_TO_STREAM(p, HCI_VSC_UPDATE_BAUDRATE);
        *p++ = UPDATE_BAUDRATE_CMD_PARAM_SIZE; /* parameter length */
        *p++ = 0; /* encoded baud rate */
        *p++ = 0; /* use encoded form */
        UINT32_TO_STREAM(p, UART_TARGET_BAUD_RATE);

        p_buf->len = HCI_CMD_PREAMBLE_SIZE + \
                     UPDATE_BAUDRATE_CMD_PARAM_SIZE;
        hw_cfg_cb.state = (hw_cfg_cb.f_set_baud_2) ? \
                    HW_CFG_SET_UART_BAUD_2 : HW_CFG_SET_UART_BAUD_1;

        is_proceeding = bt_vendor_cbacks->xmit_cb(HCI_VSC_UPDATE_BAUDRATE, \
                                            p_buf, hw_config_cback);
        break;
        。。。。。。。
   }

bt_vendor_cbacks->xmit_cb的回调函数都是设置为hw_config_cback 而具体作什么超做根据hw_cfg_cb.state 来决定,这是一个简单的状态机。

当UART_TARGET_BAUD_RATE >3m时则执行HW_CFG_START 不然执行HW_CFG_SET_UART_CLOCK,大于3m的这里不分析。

HW_CFG_SET_UART_CLOCK分支现将 hw_cfg_cb.state设置为HW_CFG_SET_UART_BAUD_1而后再调用 bt_vendor_cbacks->xmit_cb(HCI_VSC_UPDATE_BAUDRATE, p_buf, hw_config_cback); 因此下一步hw_config_cback 中走的是HW_CFG_SET_UART_BAUD_1分支 依次类推配置所走的分支顺序: HW_CFG_START:HW_CFG_SET_UART_CLOCK (至关于同一分支) HW_CFG_SET_UART_BAUD_1 HW_CFG_READ_LOCAL_NAME HW_CFG_DL_MINIDRIVER:HW_CFG_DL_FW_PATCH(至关于同一分支) HW_CFG_START(这个时候与第一步的区别在于f_set_baud_2 设置为true) HW_CFG_SET_UART_BAUD_2 HW_CFG_SET_BD_ADDR 到这一步配置就完成了因而回调firmware_config_cb 函数: bt_vendor_cbacks->fwcfg_cb(BT_VND_OP_RESULT_SUCCESS); 完成。 但没有结束,在配置过程当中每一步都向HCI层发送了命令,这些才是核心内容,也很是复杂,后面再分析。

相关文章
相关标签/搜索