android7藍牙筆記

1 代碼位置 魔窟

藍牙協議目錄：system/bt
藍牙vendor層目錄：hardware/broadcom/libbt

2 啟動 萬惡之源

system/bt/hci/src/hci_layer.c

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定義的時間內沒有完成則認為失敗，將重復整個初始化程序，

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 型別的結構體：

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 介面但不實作，

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層去處理，

hci層的start_up雖然執行完了，但是并不代表配置成功，因為
vendor->send_async_command(VENDOR_CONFIGURE_FIRMWARE, NULL);
是放到執行緒中執行的，那hci 怎么知道配置是否成功呢?
這就用到了startup_timer了，

//啟動定時器
//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層發送了命令，這些才是核心內容，也非常復雜，后面再分析，