使用(DR)STRACE比较Windows程序的执行情况
我在这里直接提出了一个问题,关于这个问题在github上的node-serialport。 简而言之,在库的v4.x中正常工作的东西不再适用于库的v6.x。 我认为它必须与图书馆如何打开COM端口(选项或其他)有关,而且我怀疑它是否会在当前版本的库中人为地限制通过USB传输的功率。
我写了最简单的脚本,我可以重现问题(脚本张贴在问题中)使用:
- NodeJS和v4.x的库[作品]
- NodeJS和v6.x库[失败]
- Python和PySerial相当于[作品]
通过维护者维护者的build议,我研究并find了一个名为drstrace的实用程序,它允许我捕获执行一段时间内执行的每个脚本的日志(这些日志作为附件发布在引用问题)。
现在我被卡住了,因为我不知道如何制作drstrace日志的正面或反面,但是我确信在比较这三个文件时差异可能是明显的。 我只是不知道如何阅读drstrace日志和Windows驱动程序和系统调用突破。
我意识到在这里发表这个问题是一个绝望的行为,但我认为这是值得一试。 希望很清楚,我自己并不缺乏这方面的努力,在这一点上我只是头脑发展,并且可以帮助我们取得进一步的进展。 任何指导将不胜感激。 最令人敬畏的是那些熟悉这种诊断水平的人,看一看茶叶。 回馈给这样一个重要的开放源代码库是非常好的。
更新2017年11月10日
我接触FTDI支持问:
我在我的许多产品中使用FT231X。 我需要一些帮助,了解Windows FTDI驱动程序如何pipe理电源。 更重要的是,我希望你能帮助我理解如何让驱动程序允许USB允许的全部500mA通过Windows计算机传递到我的产品。
答复是:
只需使用我们的FT_Prog实用程序将最大VBUS电stream设置为500 mA即可:
在FT231X枚举后,这个驱动电stream变为可用。
我还没有尝试过这个build议,但我想分享给任何读这个的人。 事实上,node-serialport 6.0.4行为与node-serialport 4.0.7行为和pyserial行为都有所不同。
以下是您可以研究的另一种理论:
与V6.x交互的Windows可能会与stream控制设置进行不同的交互,这可能会导致设备以意外的状态进行响应,导致testing失败。
我读了一些关于Windows驱动程序,以及他们如何pipe理,我只发现它与硬件制造商有关,我认为它不是自串行端口的故障,因为它真的使用自己的驱动程序,它没有增加额外的水平。
我是SerialPort的贡献者,可以告诉你,它只提供操作系统到节点的绑定,这意味着它不会为你提供任何操作,只有一个API从微软读取以下内容,他们说你应该问你的硬件供应商
串行端口驱动程序中的电源pipe理(Windows CE 5.0)
Windows CE 5.0发送反馈串行端口驱动程序可以提供的最低电源pipe理是使用HWPowerOff函数将串行端口硬件置于最低功耗状态,并使用HWPowerOn函数完全重新打开串行端口硬件。 这两个函数都在下层实现。 除了这个最小的处理之外,串行端口驱动器可以通过保持端口断电来更有效地节省电力,除非应用程序打开了串行端口。 如果驱动程序不需要检测可移动串行端口设备的对接事件,则驱动程序可以更进一步,从串行端口的通用asynchronous收发器(UART)芯片断开电源,如果没有应用程序正在使用端口。 即使没有为串行线路驱动器供电,大多数串行端口硬件也可以支持读取端口的input线路。 请查阅串口硬件的文档,以确定串口电路的哪些部分可以select性地开启和closures,以及在各种使用条件下必须为哪些部分供电。
来源: https : //msdn.microsoft.com/en-us/library/aa447559.aspx
关于serialport v4 => 6的变化
- 新的stream接口
- 但港口的核心开放方式并没有改变。
- 也没有改变打开端口的绑定
- 节点serialport是用c ++编写的绑定的集合