我们有一个运行XP的系统,其中COM2是硬件RS485端口。

在我的代码中,我使用 RTS_CONTROL_TOGGLE 设置DCB。我假设它会做它所说的......一旦写入空中断发生,就在内核模式下关闭RTS。这应该是暂时的。

相反,我们在一个范围上看到PC正在驱动总线的任何地方比消息结束的时间长1-8毫秒。我们正在谈论的设备在大约1-5毫秒内响应。所以...通信腐败很多。不,没有办法改变目标的响应时间。

我们现在已经连接到RS232端口并将示波器连接到TX和RTS线路,我们也看到了同样的事情。发送消息后,RTS线保持高电平1-8毫秒。

我们也试过关闭FIFO,或者将FIFO深度设置为1,但没有效果。

有什么想法吗?我将尝试在“SendFile,clear RTS”期间尝试从具有REALTIME优先级的用户模式手动控制RTS线路。周期。我也没有太多希望这也能奏效。这不应该在用户模式下完成。

有帮助吗?

解决方案

在我们的嵌入式XP平台上,

RTS_CONTROL_TOGGLE 不起作用(在传输后关闭之前有一个可变的1-15毫秒的延迟)。如果我使用timeBeginPeriod(1)等将时间量改为1 ms,我可能会降低这一点,但我怀疑它是否可靠或足够重要。 (设备有时会响应@ 1毫秒)

最终解决方案真的很难看,但它适用于这个硬件。我不会在硬件不固定的任何地方使用它。

基本上:

1)将串口的设备管理器页面上的FIFO设置为关闭或1个字符深

2)使用以下代码发送消息+ 2个额外字节

int WriteFile485(HANDLE hPort, void* pvBuffer, DWORD iLength, DWORD* pdwWritten, LPOVERLAPPED lpOverlapped)
{
  int iOldClass = GetPriorityClass(GetCurrentProcess());
  int iOldPriority = GetThreadPriority(GetCurrentThread());
  SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
  SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

  EscapeCommFunction(hPort, SETRTS);

  BOOL bRet = WriteFile(hPort, pvBuffer, iLength, pdwWritten, lpOverlapped);

  EscapeCommFunction(hPort, CLRRTS);

  SetPriorityClass(GetCurrentProcess(), iOldClass);
  SetThreadPriority(GetCurrentThread(), iOldPriority);

  return bRet;
}

当最后一个或两个字节写入串口时,WriteFile()返回。他们还没有离开端口,因此需要发送2个额外的字节。当你做CLRRTS时,其中一个或两个都会被删除。

就像我说的那样......很难看。

其他提示

  

有什么想法吗?

您可能会发现DDK中的串行端口驱动程序有源代码,可以让您了解该选项应该如何实现:即它是在中断级别,在DPC级别还是更差。“ / p>

其他可能性包括重写驱动程序;使用第三方RS485驱动程序,如果你能找到一个;或者使用第三方RS485硬件和自己的驱动程序(例如,至少在过去的第三方用于制作具有32个端口,深度缓冲器和自己的微处理器的“智能串行端口板”;我希望RS485是一个问题,已经被某人解决了。

8毫秒看起来确实令人失望很长时间;我知道XP不是RTOS,但我希望它(通常)做得更好。另一件需要关注的事情是,是否有其他高优先级线程正在运行,这可能会产生干扰。如果您一直在提高自己应用程序中某些线程的优先级,那么您应该减少其他线程的优先级。

  

我将尝试在“SendFile,clear RTS”期间尝试从具有REALTIME优先级的用户模式手动控制RTS线路。周期。

不要让该线程失去控制:IME这样的线程可以,如果它的bug会永远抢占所有其他用户模式线程。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top