#背景 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库之间的差异。