Ember模塊筆記——排查串口硬件流控問題

#背景 Ember庫在RTL8196的Linux上運行不正常。經咱們的小夥伴精密地排查，問題不在硬件板子、串口驅動、EM3581固件上。由於咱們本身寫的串口硬件流控Demo在嵌入式Linux上是正常的。那麼，問題只能定位爲Ember庫在處理硬件流控中，因爲平臺的緣由致使的異常。

#正文 對於這個問題，個人首先能想到的就是Ember代碼關於串口的配置部分。首先找到程序入口：

這個函數 emberAfMain()函數的參數，實際是：emberAfMain(5, "emberAfMaim -n 0 -p ttyS1")。
進入該函數，在文件 protocal/zigbee_5.7/app/framework/util/af-main-host.c 文件中：

其中L519是在解析 MAIN_FUNCTION_PARAMETERS(其實就是int argc, char *[]args) 中參數的。而後再在L525對串口進行配置。
進入 emberAfMainStartCallback() 函數去看：

emberAfmainStartCallback(int *ret, int argc, char **argv)
 ` ezspProcessCommandOptions(argc, argv)
     `ezspInternalProcessCommandOptions(argc, argv, errStr)

最終是在 ezspInternalProcessCommandOptions(int argc, char *argv, char *errStr)中對參數進行解析，在 protocal/zigbee_5.7/app/ezsp-host/ash/ash-host-ui.c，代碼以下：

其中咱們很關心的兩個參數的處理分別爲：

從代碼能夠看出"-n" 這個參數只做爲第一個參數，它調用了ashSelectHostConfig(cfg)，cfg就是"-n"的參數，這裏咱們填的是0。
去看 ashSelectHostConfig()，定義在 protocal/zigbee_5.7/app/ezsp-host/ash/ash-host.c：

ashSelectHostConfig()的功能是選擇一個配置模板。這也是爲何"-n"參數必定要排在最前面的緣由了，後面的參數是對這個模板進行修改。 在L157~159，若是cfg小於ashHostConfigArray數組的長度，那就 ashHostConfig = ashHostConfigArray[cfg]。
咱們去看看 ashHostConfigArray數組的定義：

L95是ashHostConfigArray[0]，被定義成了宏 ASH_HOST_CONFIG_DEFAULT；L97~116爲ashHostConfigArray[1]。
咱們去看 ASH_HOST_CONFIG_DEFAULT 定義：

在L69行的值爲true，即開啓硬件流控。
從L87來看，ashHostConfig的默認值就是 ASH_HOST_CONFIG_DEFAULT，即開啓了硬件流控的。
AshHostConfig 的定義以下：

其中L53定義了硬件流控字段rtsCts。爲了查問題，咱們直接去找 rtsCts的引用處，找到以下：
protocal/zigbee_5.7/app/ezsp-host/ash/ash-host-io.c
readConfig(rtsCts)其實就是個宏，它展開爲：ashHostConfig.rtsCts，就是咱們上面看到的設備。
咱們要注意兩個變量：rtsCts,flowControl，由於下面引用到了：


它設置了兩個串口配置參數：tios.c_iflag, tios.c_cflag。這個是重點排查對象！！
好，經過打調試信息來區別咱們Demo與Ember庫之間的差別。