启动期间嵌入式Linux设备阻塞RS485总线

Question

我正在处理一台工业用的Linux电脑，并尝试通过RS485总线与多个连接设备进行通信，但我遇到了问题。遇到的问题是，RS485 USART驱动器使用的IO引脚在启动时被设置为不同的电平而不是进入RS485空闲/三态状态。结果，总线上的其他设备会被阻塞超过30秒钟，同时引发各种外部问题。可以在附加的图像中查看事件的过程，在此期间使用示波器测量输出电压。

我的猜测是，只有当电压水平达到它们的三态水平（例如对于此设备而言约为~2.2V）时，才会启动实际的驱动程序。之后，一切都按预期工作。

我已经尝试查找任何配置文件以在引导时设置引脚的默认IO电平（认为这可能由引导加载程序设置），但没有发现。

此外，我尝试应用一个“足够早”的启动脚本来将DATA高电平，但据我所知，该设备没有提供任何接口来控制这些引脚作为常规GPIO。

非常感谢任何帮助、提示或见解！

编辑：我不是一个经验丰富的Linux开发人员，所以请指出我是否遗漏了任何重要的细节。

一些规格：

• CPU：ARM920T rev 0（v41）
• Linux 2.6的专有分发版本
• 使用Busybox
• Atmel USART驱动程序

从启动日志中提取：

Linux版本2.6.28.10（root@）（gcc版本4.1.2）#94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU：ARM920T [41129200]修订版0（ARMv4T），cr=c0003177
/...
.../
RS485模式为端口/dev/ttyS3启用
/...
...（我猜测在这里经过约30秒）
.../
atmel_usart.3：ttyS3位于MMIO 0xfffcc000（irq=9）， 是ATMEL_SERIAL
atmel_serial.3：将RS485 RTS引脚向下拉
/...
...
.../

完整的启动日志：https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view

类似的问题：

可能类似的问题在这里讨论：UART初始化：防止UART拉高RTS
但我不确定如何执行建议的解决方案。

- Stenis

---

你可以从SoC串行调试端口获取更多信息（例如引导日志），因此我认为连接到串行控制台对于进一步的进展至关重要。串行端口通常在内核启动早期初始化，因此您需要将RS485状态与系统启动活动相对应。您可能需要识别使用的RS-485收发器芯片，以便您了解其控制输入的正确逻辑（例如将DE低电平和RE-高电平驱动）。Atmel没有太多使用ARM920T的SoC，您可能有一个AT91RM9200。 - sawdust

@sawdust 感谢您的评论。我需要深入挖掘并了解更多信息。 - Stenis

我已经进行了更深入的挖掘，找到了一个打印引导日志的程序（dmesg）。我已经将其中一些内容添加到问题中，但不确定它是否有帮助，除了确认所有内容都是通过引导加载程序处理的。我假设 RTS 默认为高电平，并在约30秒后设置为低电平。对于配置为RS232的UART来说，这是正常行为吗？ - Stenis

你能提供更多的启动日志吗？我不确定这个操作是在内核初始化期间还是由任何用户空间程序执行的。 - Samrat Das

你猜测的“30秒时间到这里”是不合理的。内核在初始化阶段不应该需要那么长时间。这个30秒延迟的起点是什么？对应于这个起点的控制台输出在哪里？（例如，在内核启动之前？）你需要将示波器和计算机监视器放在一起以相互关联事件。 - sawdust

Answer 1

这只是不太可靠的猜测，但值得尝试添加一个启动脚本，在启动过程中尽早向设备（例如/dev/ttyS1或其他）回显一个NULL字符。这可能足以激活驱动程序初始化硬件。

你也可以尝试在Linux源代码中查找驱动程序，以了解其启动方式。

- Ian Goldby

---

谢谢你的好建议。然而，我无法找到一种足够早的方法来实现这个（例如尝试从rcs启动脚本中实现）。 - Stenis

这些事情在内核启动后也会发挥作用，意味着需要10到20秒的时间。 - Samrat Das

@SamratDas 看来你是正确的。请查看我插入到 Q 中的机器人日志 - 显示所有事情都发生在启动期间。 - Stenis

Answer 2

也许您可以访问源代码，这样您就可以调查是谁在何时搞乱了那个GPIO。只需在内核源代码中搜索Atmel GPIO控制器端口地址，即可弄清发生了什么。如果幸运的话，可能会有内核命令行选项，您可以从引导加载程序传递该选项，事先设置所需的行。

- Atanas Palavrov

Answer 3

如果您能找到下面提到的所需内容，那么此答案可能有效！

我也曾遇到过PWM相同的问题。 我发现我的引导加载程序是有责任的，我在引导加载程序配置中进行了更改，然后它开始正常工作。

检查由板卡供应商或第三方提供的BSP（如果您有源代码），如果您的引导加载程序是U-boot，则可以在U-boot-(source)/include/configs/(your-board).h内找到它，在那里您可以找到RS484的配置。 根据您的板卡数据表，您可以检查其他与同一引脚混合的事物，并在启动时禁用不需要的事物并启用RS485。

通过更改值0,1或2，可以执行启用/禁用，根据您的配置，您还可以通过注释掉行来简单地禁用任何内容。//

- Samrat Das

---

不幸的是，我似乎没有U-boot（但我无法确定我真正拥有什么）。没有这样的目录，我已经使用grep查找*.h文件，但没有结果。感谢您的建议和坚持帮助我！ - Stenis