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