[参考译文] SN65HVD72：接收与发送数据相同的数据

尊敬的 Max：

是的、您正确理解问题。 我有 USB->RS485软件狗、通过这些软件狗、我可以获得正确的数据(我在第一个帖子中提到过)。

好的、我一直有/re 低电平、但在本例中、您说我 juts 得到了回波？ 我尝试同时处理/RE DE 引脚、但在这种情况下看起来像是通信卡滞(我在 A/B 上看到数据、但从器件没有收到任何响应)。 我认为它可能与/re、de handling 相关、那么我们是否有一些 appnot 或类似2的东西应该被驱动？ 非常感谢。

Marek

Marek、

如何处理 DE/RE 取决于应用中需要的内容：

 -如果需要"回波"功能(即发送方也会接收到每条传输的消息)、则/RE 始终可以为低电平。  但是、应相应地配置 CPU、以便它期望这些回传消息并对其进行适当处理。

 -如果不需要"回波"、则/RE 在传输发生时应处于高电平、以便接收器输出不会切换。  (大多数收发器在此状态下会禁用 R 输出、因此使用上拉电阻可确保 CPU 看到恒定高电平并且不会错误地解释线路上的数据非常有用。)

第二种方法通常通过使用单个控制线控制 DE 和/RE 来实现。  听起来您尝试过这种方法并发现了一些问题、但我想如果我们再深入研究一下、我们可以调试这些问题。  (如果 A/B 线路上显示了正确的数据、那么从器件应该做出响应。  您可以检查从器件 R 线路是否相应地切换、并查看响应是否显示在 A/B 上、但不会以某种方式转换到 CPU。)

此致、
最大

尊敬的 Max：

谢谢。 让我来进一步调查一下、如果有问题、请联系您。 谢谢。

BR、

Marek

尊敬的 Max：

不幸的是、它仍然无法正常工作。

我以 这种方式劫持了一个位 libmodbus：

static ssize_t _Modbus_rtc_send (Modbus_t *ctx、const uint8_t * req、int req_length)
｛
#if defined (_WIN32)
Modbus_rtc_t * ctx_rtu = ctx->backend_data；
&n_bytes = 0；
return (reeFile (ctx_w_dword、dword) req-q、rend、rend_q null))？ (ssize_t)n_Bytes：-1；
#else
Modbus_rtc_t *ctx_rtu = ctx->backend_data；
ssize_t size；
/*#if heat_DECL_TIOCM_RTS
if (ctx_rtc->rts！= MODBUS_rts_none )；{if (ctx-tx->rtx_retriee_rts_deep)


；\n?br> tx<tx<tx<tx<tx<tx<tx<br> tx<tx<tx<br> tx<br> tx<tx<br> tx<tx<br> tx> tx<tx<tx> tx> tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<tx<t





/sys/class/gpio/gpio79/value /sys/class/gpio/gpio78/value


CTX_RTU->onebyte_time * req_length + ctx_rtc->rts_delay)；

usleep (ctx_rtc->onebyte_time * req_length + ctx_rtc->rts_delay)；

system ("rtx0 >/sys/class/gpio/gpio78/value；echo 0 >/sys/class/gpio/gpio79/value)；
/* crts_cm->set_length + rts_dirt/rts_de/


return！/#tx_r/ tx_r/ tx_return

因此、在写入之前、我将两个引脚都设置为1 (78是 DE、79是/RE)。 我可以在正确发送的 A/B 线路上看到数据、但看不到任何接收到的数据。 以上是否有任何意义？ 在发送数据时、我们需要交换/re、de、然后我们应该能够接收数据。 这是某种时间关键吗？ 谢谢。

Marek

尊敬的 Marek：

听起来您的理解是正确的。  您需要将 DE 设为高电平才能发送数据、并且您需要将 DE 和/RE 设为低电平才能接收响应。  是否有可能在您能够将/RE 状态切换为低电平并最终丢失响应之前恢复响应？  (另请注意、在/RE 变为低电平后、SN65HVD72接收器可能需要花费高达50ns 的时间才能启用、尽管与软件切换引脚所需的时间相比、此时间通常较短。)

最大

尊敬的 Max：

在源代码中、在写入延迟之后、以 uSec 为单位、我想保持数据通过总线发送(考虑波特率和负载长度)。 有效载荷的此延迟为~9ms。 我不擅长 RS485、但在接收到数据后、我立即看到停止位、然后从器件发回数据。 这是正确的、还是取决于主器件以某种方式告诉从器件等待一个位、直到我切换到接收模式？ 谢谢。

BR、

Marek

Marek、

在响应前、从器件应等待直到主器件处于接收模式。  您可能希望尝试向从器件代码添加长于主器件中配置的~9ms 的延迟。  您还可以通过探测收发器上的 D 和 DE/RE 线路来仔细检查主计时是否合理。  在 D 线上的"STOP"位之后的任何时间、DE/RE 都可以从高电平变为低电平、但它们进行此转换所需的时间越长、从器件在响应之前需要等待的时间就越长。

最大

尊敬的 Max：

我不能更改从设备上的代码，它是为我准备的黑盒;)。 在上面的回答中、您提到了信号 D (它正常或拼写错误？)。 我将尝试探测/DE、RE 和 A/B、并在 STOP 引脚正确切换后验证它。 谢谢。

Marek

尊敬的 Marek：

我的意思是、您可以同时查看 D 和 DE。  如果 DE 在 D 上的最后一位被发送后很长时间处于高电平、那么发送器可能会保持启用状态太长时间并干扰从器件响应。

最大

尊敬的 Max：

我能够同时使/RE 停止工作、但在连接到器件时、我仍然看到一个问题、即响应已提供、但结果不正确。

基本上，我正在尝试从设备读取输入状态：

使用此字节： [01][02][00][00][00][00][04][79][c9]、我在一行中看到它

然后响应应该类似于[01][02][04][00][CRC]、但我会随机得到：

<00><00><01><02><01><00>或 <00><01><02><01><00> <88>、这似乎是正常的、但第一个字节无效。

我联系了设备制造商、他们使用了一些 AnalogDevices RS485收发器、并告诉我、收发器可能不兼容、这种情况不太可能发生。

在示波器上、当 TX 完成并且我们启动 RX 时、我会看到以下内容：

这个小毛刺脉冲是否会导致问题？ 当 DE/RE 下降时。 RS485上的数据看起来也可以、但我在 RX 引脚上接收的数据就是上面发布的数据。 有什么想法要检查或调整什么？ 当 TX 完成并启动 RX 时、信号应该是什么样的？ 谢谢