¿Un buen protocolo/pila de comunicaciones en serie para dispositivos integrados? [cerrado]


Después de escribir varios protocolos seriales personalizados diferentes para varios proyectos, he comenzado a sentirme frustrado con reinventar la rueda cada vez. En lugar de seguir desarrollando soluciones personalizadas para cada proyecto, he estado buscando una solución más general. Me preguntaba si alguien conoce un protocolo serie (o mejor aún, implementación) que cumpla con los siguientes requisitos:

  • Soporta múltiples dispositivos. Nos gustaría ser capaces de soportar un RS485 bus.
  • entrega Garantizada. Algún tipo de mecanismo de reconocimiento, y alguna simple detección de errores (CRC16 probablemente está bien).
  • No maestro/esclavo. Idealmente, el esclavo(s) sería capaz de enviar datos de forma asíncrona. Esto es sobre todo por razones estéticas, el concepto de encuestar a cada esclavo no se siente bien para mí.
  • OS independencia. Idealmente, no dependería de un entorno multitarea preventivo en absoluto. Estoy dispuesto a conceder esto si puedo conseguir el otro cosa.
  • ANSI C. Necesitamos poder compilarlo para varias arquitecturas diferentes.

La velocidad no es un gran problema, estamos dispuestos a renunciar a algo de velocidad con el fin de satisfacer algunas de esas otras necesidades. Sin embargo, quisiéramos reducir al mínimo la cantidad de recursos necesarios.

Estoy a punto de comenzar a implementar un protocolo de ventana deslizante con ACKs a cuestas y sin repetición selectiva, pero pensé que tal vez alguien podría ahorrarme el problema. ¿Alguien sabe de un proyecto existente que podría aprovechar? O quizás una mejor estrategia?

UPDATE
He considerado seriamente una implementación TCP / IP, pero realmente esperaba algo más liviano. Muchas de las características de TCP/IP son excesivas para lo que estoy tratando de hacer. Estoy dispuesto a aceptar (a regañadientes) que tal vez las características que quiero simplemente no están incluidas en protocolos más ligeros.

ACTUALIZACIÓN 2
Gracias por los consejos sobre LATA. He mirado en el pasado y probablemente lo usará en el futuro. Sin embargo, realmente me gustaría que la biblioteca manejara los agradecimientos, el almacenamiento en búfer, los reintentos, etc. Supongo que estoy más buscando una capa de red / transporte en lugar de una capa de enlace de datos/física.

ACTUALIZACIÓN 3
Así que parece que el estado del arte en esta área es:

  • Una pila TCP/IP recortada. Probablemente comenzando con algo como lwIPo uIP.
  • Una implementación basada en CAN, it probablemente dependería en gran medida del bus CAN, por lo que no sería útil en otras capas físicas. Algo como PUEDE Festival podría ayudar en el camino.
  • Una implementación HDLC o SDLC (como esta). Esta es probablemente la ruta que tomaremos.

Por favor, siéntase libre de publicar más respuestas si se encuentra con esta pregunta.

Author: dsolimano, 2009-07-21

6 answers

¿Ha considerado HDLC o SDLC?

También hay LAP/D (Protocolo de Acceso de Enlace, Canal D).

Los "Protocolos de enlace de datos " de Uyless Black siempre están cerca en mi estantería, es posible que también encuentre algún material útil allí (incluso lea detenidamente el Índice e investigue los diferentes protocolos)

 12
Author: Dan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-07-21 21:40:16

CAN cumple varios de sus criterios:

  • Soporta múltiples dispositivos: Soporta un gran número de dispositivos en un bus. Sin embargo, no es compatible con RS485.
  • Entrega garantizada: La capa física utiliza relleno de bits y un CRC, todos los cuales están implementados en hardware en un número creciente de procesadores embebidos modernos. Si necesita reconocimiento, debe agregarlo usted mismo.
  • No amo / esclavo: Allí no son amos o esclavos; todos los dispositivos pueden transmitir cuando quieran. El hardware del procesador se ocupa del arbitraje y la contención.
  • Independencia del sistema operativo: No se aplica; es un bus de bajo nivel. Lo que pongas encima de eso depende de ti.
  • ANSI C: De nuevo, no procede.
  • Velocidad: Normalmente, hasta 1 Mbps hasta 40 m; puede elegir su propia velocidad para su aplicación.

Como se mencionó, su definición es bastante de bajo nivel, por lo que hay todavía trabajo por hacer para convertirlo en un protocolo completo para satisfacer sus necesidades. Sin embargo, el hecho de que gran parte del trabajo se realiza en hardware para usted hace que sea muy útil para una variedad de aplicaciones.

 5
Author: Steve Melnikoff,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-07-21 18:12:35

Supongo que un punto de partida razonable podría ser uIP.

(Añadiendo artículo de Wikipedia sobre µIP ya que el enlace original está muerto.)

 5
Author: Javier,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-08-14 00:43:25

Echa un vistazo a Profibus.

Si no quieres maestro/esclavo, creo que debemos hacer el arbitraje con el hardware (Canbus, FlexRay).

 1
Author: KeyserSoze,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-07-21 17:41:33

¿Consideraría el protocolo MODBUS? Está orientado a maestro / esclavo, por lo que el esclavo no pudo iniciar la transferencia, pero por lo demás es liviano para la implementación, gratuito y bien soportado con herramientas de alto nivel. Solo debe obtener una comprensión de su terminología / como registro de retención, registro de entrada, bobina de salida, etc.).

El nivel Phy podría ser RS232, RS485, Ethernet...

 1
Author: Drazen Cika,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-01-24 15:41:39

Echa un vistazo a Microcontrolador Internet Network (MIN):

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

Inspirado en CAN pero usando hardware UART estándar, con la suma de comprobación de Fletcher y el formato de fotograma verificando la detección de errores y el relleno de bytes para marcar un encabezado de fotograma.

 1
Author: Ken Tindell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-02-23 18:18:48