rs232 - ¿Un buen protocolo/pila de comunicaciones en serie para dispositivos integrados?

rs-232

Question

Después de escribir varios protocolos serie personalizados diferentes para varios proyectos, comencé a frustrarme con la reinvención de la rueda cada vez. En lugar de continuar desarrollando soluciones personalizadas para cada proyecto, he estado buscando una solución más general. Me preguntaba si alguien sabe de un protocolo en serie (o mejor aún, implementación) que cumple con los siguientes requisitos:

• Admite múltiples dispositivos. Nos gustaría poder admitir un bus RS485.
• Entrega garantizada. Algún tipo de mecanismo de acuse de recibo y alguna detección simple de errores (CRC16 probablemente sea correcto).
• No es maestro / esclavo Idealmente, los esclavos podrían enviar datos de forma asíncrona. Esto es principalmente por razones estéticas, el concepto de sondear a cada esclavo no me parece correcto.
• Independencia del sistema operativo Idealmente, no dependería en absoluto de un entorno multitarea preventivo. Estoy dispuesto a conceder esto si consigo las otras cosas.
• ANSI C. Necesitamos poder compilarlo para varias arquitecturas diferentes.

La velocidad no es un gran problema, estamos dispuestos a ceder algo de velocidad para satisfacer algunas de esas otras necesidades. Sin embargo, nos gustaría minimizar la cantidad de recursos requeridos.

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

ACTUALIZAR
He considerado seriamente una implementación de TCP / IP, pero realmente esperaba algo más ligero. 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 livianos.

ACTUALIZACIÓN 2
Gracias por los consejos sobre CAN. Lo he visto en el pasado y probablemente lo use en el futuro. Sin embargo, me gustaría que la biblioteca maneje 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 física / de enlace de datos.

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

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

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

Answer 1

¿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. Debería obtener una comprensión de su terminología / como registro de retención, registro de entrada, bobina de salida, etc.).

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

Answer 2

¿Has 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 están siempre cerca, en mi estantería; es posible que también encuentres material útil allí (incluso revisa el TOC e investiga los diferentes protocolos)

Answer 3

Echa un vistazo a Microcontroller Internet Network (MIN):

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

Inspirado por CAN pero usando hardware UART estándar, con suma de comprobación de Fletcher y verificación de formato de trama para la detección de errores y byte-relleno para marcar un encabezado de marco.

Answer 4

Eche un vistazo a Profibus .

Si no quiere maestro / esclavo, creo que debe hacer el arbitraje con hardware ( CAN , FlexRay ).

Answer 5

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

(Agregar un artículo de Wikipedia sobre μIP dado que el enlace original está muerto).

Answer 6

CAN cumple con varios de sus criterios:

• Admite múltiples dispositivos: admite una gran cantidad de dispositivos en un solo bus. Sin embargo, no es compatible con RS485.
• Entrega garantizada: la capa física utiliza relleno de bits y un CRC, todos los cuales se implementan en hardware en un número creciente de procesadores incorporados modernos. Si necesita ayuda, debe agregarla por su cuenta.
• No es maestro / esclavo: no hay maestros o esclavos; todos los dispositivos pueden transmitir cuando lo deseen. El hardware del procesador trata con el arbitraje y la contención.
• Independencia del sistema operativo: no aplicable; es un autobús de bajo nivel. Lo que le pones encima depende de ti.
• ANSI C: Nuevamente, no aplica.
• Velocidad: Típicamente, hasta 1 Mbps hasta 40 m; puede elegir su propia velocidad para su aplicación.

Como se mencionó, su definición es bastante baja, por lo que aún queda trabajo por hacer para convertirla en un protocolo completo que satisfaga sus necesidades. Sin embargo, el hecho de que gran parte del trabajo se hace en hardware para usted lo hace muy útil para una variedad de aplicaciones.