40

After writing several different custom serial protocols for various projects, I've started to become frustrated with re-inventing the wheel every time. In lieu of continuing to develop custom solutions for every project, I've been searching for a more general solution. I was wondering if anyone knows of a serial protocol (or better yet, implementation) that meets the following requirements:

  • Support multiple devices. We'd like to be able to support an RS485 bus.
  • Guaranteed delivery. Some sort of acknowledgement mechanism, and some simple error detection (CRC16 is probably fine).
  • Not master/slave. Ideally the slave(s) would be able to send data asynchronously. This is mostly just for aesthetic reasons, the concept of polling each slave doesn't feel right to me.
  • OS independence. Ideally it wouldn't rely on a preemptive multitasking environment at all. I'm willing to concede this if I can get the other stuff.
  • ANSI C. We need to be able to compile it for several different architectures.

Speed isn't too much of an issue, we're willing to give up some speed in order to meet some of those other needs. We would, however, like to minimize the amount of required resources.

I'm about to start implementing a sliding window protocol with piggybacked ACKs and without selective repeat, but thought that perhaps someone could save me the trouble. Does anyone know of an existing project that I could leverage? Or perhaps a better strategy?

UPDATE
I have seriously considered a TCP/IP implementation, but was really hoping for something more lightweight. Many of the features of TCP/IP are overkill for what I'm trying to do. I'm willing to accept (begrudgingly) that perhaps the features I want just aren't included in lighter protocols.

UPDATE 2
Thanks for the tips on CAN. I have looked at it in the past and will probably use it in the future. I'd really like the library to handle the acknowledgements, buffering, retries etc, though. I guess I'm more looking for a network/transport layer instead of a datalink/physical layer.

UPDATE 3
So it sounds like the state of the art in this area is:

  • A trimmed down TCP/IP stack. Probably starting with something like lwIP or uIP.
  • A CAN based implementation, it would probably rely heavily on the CAN bus, so it wouldn't be useful on other physical layers. Something like CAN Festival could help along the way.
  • An HDLC or SDLC implementation (like this one). This is probably the route we'll take.

Please feel free to post more answers if you come across this question.

4

6 回答 6

12

您是否考虑过HDLCSDLC

还有LAP/D(链路访问协议,D 通道)。

Uyless Black 的“数据链路协议”总是在我的书架上——你也可以在那里找到一些有用的材料(甚至仔细阅读 TOC 并研究不同的协议)

于 2009-07-21T21:40:16.370 回答
5

CAN满足您的许多标准:

  • 支持多设备:在一条总线上支持大量设备。但是,它与 RS485 不兼容。
  • 保证交付:物理层使用位填充和 CRC,所有这些都在越来越多的现代嵌入式处理器上的硬件中实现。如果您需要确认,则需要自己添加。
  • Not master/slave:没有master或slave;所有设备都可以随时传输。处理器硬件处理仲裁和争用。
  • 操作系统独立性:不适用;这是一个低级总线。你把它放在上面取决于你。
  • ANSI C:同样,不适用。
  • 速度:通常最高 1 Mbps,最长 40 m;您可以为您的应用程序选择自己的速度。

如前所述,它的定义相当低级,因此仍有工作要做才能将其转变为完整的协议以满足您的需求。但是,很多工作都是在硬件中为您完成的这一事实确实对各种应用程序非常有用。

于 2009-07-21T18:12:35.040 回答
5

我猜一个合理的起点可能是uIP

(添加关于 µIP 的 Wikipedia 文章,因为原始链接已失效。)

于 2009-07-21T14:27:43.323 回答
2

看看微控制器互联网网络(MIN):

https://github.com/min-protocol/min

受 CAN 启发,但使用标准 UART 硬件,使用 Fletcher 的校验和和帧格式检查进行错误检测和字节填充以标记帧头。

于 2015-02-23T18:18:48.650 回答
2

你会考虑MODBUS协议吗?它是面向主/从的,因此从属不能启动传输,但在其他方面是轻量级的,免费的,并且得到高级工具的良好支持。您应该掌握他们的术语/如保持寄存器、输入寄存器、输出线圈等)。

物理层可以是 RS232、RS485、以太网……

于 2013-01-24T15:20:24.177 回答
1

看看Profibus

如果您不想要主/从,我认为您应该使用硬件(CanbusFlexRay)进行仲裁。

于 2009-07-21T17:41:33.870 回答