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