pxa255 支持 RS485
我想使用卡上的 rs485。我正在使用arm-linux 和pxa255 处理器。我已经检查了arm-linux工具链中的“serial.h”，但不幸的是我找不到适当的rs485设置结构，尽管它在其他一些环境（如cris）中受支持。那么现在，我是否必须编写一个低级驱动程序来启用 rs485 或者是否有其他更简单的方法来做到这一点？
I want to use rs485 placed on my card. I'm working on arm-linux and with pxa255 processor. I have already checked "serial.h" located in arm-linux tool chain but unfortunately i couldn't find the appropriate rs485 settings struct although it is supported in some other environments like cris. So now, do i have to write a low-level driver to enable rs485 or is there any other easier way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您查看此页面，了解 Linux RS-485 支持。
I'd recommend reviewing this page about Linux RS-485 support.
关于 Linux 驱动程序上的 RS485 模式支持，串行端口似乎存在很多混乱。我想我也许能够回答这个问题。
首先，您应该问自己：为什么我要在串行端口上激活 RS485 支持？我不知道您使用的是什么开发板或硬件，但请注意，大多数 UART 仅适用于单端 TTL 电平（5V 或 3.3V 电平）。这意味着您将无法直接与 RS485 设备通信，因为它们只处理差分信号。如果您想了解更多详细信息，可以查看此链接：https://www2.htw- dresden.de/~huhle/ArtScienceRS485.pdf 提供了很好的介绍。
因此，您可以根据需要编写任意多行代码和驱动程序，但这无助于您的 TTL UART 与 RS485 通信。即使您的设备在其驱动程序上支持 RS485，硬件本身也需要具有电平转换器 IC（例如 MAX485）才能使用它。幸运的是，我们敬爱的 Linux 内核开发人员对硬件了解很多，您不必担心这一点（无论如何对于大多数设备）。然后，回答您的问题：如果您无法在驱动程序上找到 RS485 设置，则很可能意味着您的硬件不直接提供支持。
幸运的是，解决方案非常简单：只需购买一个便宜的 USB 转 RS485 适配器即可。它们的价格从 5 美元到 10 美元不等，在大多数情况下它们开箱即用就可以正常工作。根据我的经验，FTDI 芯片运行良好。
例如，如果您出于任何原因确实必须使用一种特定的 UART，那么想象一下您想在 Raspberry Pi 或任何其他只能访问 TX 和 RX 信号的地方使用 UART。那么您面临着一个稍微困难一些的挑战，您需要更多地研究 RS485 设备的工作原理。这里的关键是了解半双工两线链路上的 RS485（有关更多详细信息，请参阅下面的注释）。为了能够共享一个或多个设备正在侦听并且在任何时候只有一个设备在说话的两线总线，您需要在 TX 和 RX 之上添加一个额外的控制信号（驱动器启用/~读取启用）（请注意，当使用单端 TTL 时，使用三根线有两个参考 GND 的信号，而 RS485 侧则有一条差分总线（使用两根线）。您的 RS485 收发器（例如 MAX485）将需要这个 RE/~DE 信号来安排谁在总线上讲话以及谁在监听总线，即：总线上监听的所有设备都将具有该信号为低电平（读使能设置），而讲话者将为高（驱动使能）。
在这里，我们得到了你的问题的本质：你从哪里可以获得这个额外的信号？嗯，答案是：这取决于你的 UART 芯片。有些芯片不提供任何可用的功能，那么您只能选择在软件应用程序中手动驱动可用的 UARTS 的 GPIO 线路或流量控制信号（RTS 或 DTR）。您可以在此处阅读有关 FTDI 芯片特定情况的更多详细信息：RS485：不适当的 ioctl对于设备。还提到了使用神秘的 555 定时器 IC 来解决此问题的良好硬件解决方案。
注意：比较容易混淆的地方：一、RS485是半双工的，有时会与RS422混淆，RS422是全双工的，需要四根线；第二：在我说两线和四线的地方，我最好说三线和五线，因为差分电压信号需要 GND 作为返回路径；遗憾的是，RS485 的大多数实际实现都是两线的，它们似乎对大多数人来说都能可靠地工作，但这本身就是一个很大的话题，我们可以在其他地方讨论它。
There seems to be quite a lot of confusion about serial ports with regards to RS485 mode support on Linux drivers. I think I might be able to shed some light answering this question.
First off, you should ask yourself: why do I want to activate RS485 support on my serial port? I don't know what development board or hardware you're using but be aware that most UARTs work with single-ended TTL levels only (5V or 3.3V levels). That means you won't be able to talk to RS485 devices directly because they only handle differential signals. If you want more details you can see this link: https://www2.htw-dresden.de/~huhle/ArtScienceRS485.pdf for a good introduction.
So you can write as many lines of code and drivers as you want but that won't help your TTL UART talk to RS485. Even if you have a device that supports RS485 on its driver, the hardware itself needs to have a level translator IC (like a MAX485) for you to be able to use it. Fortunately, our beloved Linux Kernel developers know a lot about hardware and you don't have to worry about this (for most devices anyway). Then, answering your question: if you are not able to find the RS485 settings on your driver it will most likely mean your hardware does not offer support directly.
Luckily for you, the solution is quite easy: just get a cheap USB to RS485 dongle. You can find them from 5-10$ and they should work fine out of the box for most scenarios. In my experience, FTDI chips work well.
If you really have to go with one particular UART for any reason whatsoever, for instance, imagine you want to use the UART on your Raspberry Pi or any other where you only have TX and RX signals accessible. Then you have a slightly more difficult challenge ahead of you and you need to study a bit more about how RS485 devices work. The key aspect here is to understand that RS485 on a half-duplex two-wire link (see note below for more details on this). To be able to share a two-wire bus where one or multiple devices are listening and only one is talking at any time, you need an additional control signal (Drive Enable/~Read Enable) on top of your TX and RX (note that when you go on single-ended TTL you have two signals referred to GND using three wires compared to one differential bus with two wires for the RS485 side). Your RS485 transceiver (say MAX485) will need this RE/~DE signal to arrange who is talking and who is listening on the bus, namely: all devices listening on the bus will have this signal low (read enable set) while the talker will be high (drive enable).
Here we get to the essence of your question: where can you get this additional signal? Well, the answer is: it depends on your UART chip. Some chips don't offer anything to work with, then you're left with the option of manually driving in your software application a GPIO line or flow controls signals (RTS or DTR) for UARTS where you have them available. You can read more details on this topic for the particular case of the FTDI chips here: RS485: Inappropriate ioctl for device. There is also a reference to a nice hardware solution to this problem using the mythical 555 timer IC.
Note: more confusing areas: one, RS485 is half-duplex and sometimes mixed up with RS422, which is full duplex and needs four wires; and two: where I say two-wire and four wires I should better say three-wire and five wires because the differential voltage signals need a GND to serve as a return path; sadly, most practical implementations of RS485 are two-wire and they seem to work reliably for most people, but that's a huge topic itself and we can talk about it somewhere else.