藍芽協定目錄：system/bt
藍芽vendor層目錄：hardware/broadcom/libbt
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定義的時間內沒有完成則認為失敗，將重複整個初始化過程。
上一步結尾的函數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就不會被呼叫
就是對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層處理，處理完後會呼叫相應的回撥函數就可以了。
這一層的程式碼跟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層傳送了命令，這些才是核心內容，也非常複雜，後面再分析。