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库之间的差别。