Un buen protocolo de comunicaciones serie / pila para dispositivos embebidos? [cerrado]

StackOverflow https://stackoverflow.com/questions/1159379

Pregunta

Después de escribir varios protocolos personalizados de serie diferentes para diversos proyectos, he comenzado a frustrarse con la re-inventar 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 sabe de un protocolo serie (o mejor aún, la implementación) que cumpla los siguientes requisitos:

  • Soporte de múltiples dispositivos. Nos gustaría ser capaz de soportar un bus RS485.
  • Entrega garantizada. Algún tipo de mecanismo de confirmación, y algunos de detección de errores simples (CRC16 es probablemente muy bien).
  • No maestro / esclavo. Lo ideal sería que el esclavo (s) sería capaz de enviar datos de forma asíncrona. Esto es más que nada por razones estéticas, el concepto de sondeo cada esclavo no se siente bien para mí.
  • independencia del sistema operativo. Lo ideal sería que no se basaría en un entorno multitarea preventiva en absoluto. Estoy dispuesto a conceder este si puedo conseguir las otras cosas.
  • ANSI C. Debemos ser capaz de compilar para varias arquitecturas diferentes.

La velocidad no es demasiado de un problema, que estamos dispuestos a renunciar a algo de velocidad con el fin de satisfacer algunas de esas otras necesidades. Nos gustaría, sin embargo, como para minimizar la cantidad de recursos necesarios.

Estoy a punto de empezar a aplicar un protocolo de ventana deslizante con ACK piggybacked y sin repetición selectiva, pero pensé que tal vez alguien me podría ahorrar la molestia. ¿Alguien sabe de un proyecto existente que podría aprovechar? O tal vez una mejor estrategia?

Actualizar
He considerado seriamente una aplicación TCP / IP, pero estaba realmente esperando por algo más ligero. Muchas de las características de TCP / IP son excesivos 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 incluidos en los protocolos más claros.

ACTUALIZACIÓN 2
Gracias por los consejos sobre la CAN. He mirado en el pasado y probablemente voy a utilizar en el futuro. Realmente me gustaría la biblioteca para manejar el acuses de recibo, almacenamiento temporal, reintentos, etc., sin embargo. Creo que estoy más en busca de una capa de red / transporte en lugar de una capa de enlace de datos / física.

Actualización 3
Por lo que suena como el estado de la técnica en este área es:

Por favor, no dude en enviar más respuestas si se encuentra con esta pregunta.

¿Fue útil?

Solución

Ha considerado HDLC o SDLC ?

También hay LAP / D (Protocolo de acceso al enlace, D-Channel).

Uyless de Negro " Protocolos de enlace de datos " es siempre cerca en mi estantería - es posible encontrar algún material útil en allí también (incluso leer la tabla de contenido y la investigación de los diferentes protocolos)

Otros consejos

CAN reúne una serie de sus requisitos:

  • Soporte de múltiples dispositivos: Es compatible con un gran número de dispositivos en un bus. No es, sin embargo, compatible con RS485.
  • Entrega garantizada: utiliza la capa física relleno de bits y un CRC, todos los cuales se implementan en hardware en un creciente número de procesadores integrados modernos. Si necesita acknlowedgement, es necesario añadir que en la parte superior a sí mismo.
  • No maestro / esclavo: No hay maestros o esclavos; todos los dispositivos pueden transmitir cuando lo deseen. Las ofertas de hardware del procesador con el arbitraje y la contención.
  • independencia OS: No es aplicable; se trata de un bus de bajo nivel. Lo que se pone encima de eso depende de usted.
  • ANSI C:. Una vez más, no aplicable
  • Velocidad: Típicamente, hasta 1 Mbps hasta 40 m; usted puede elegir su propia velocidad para su aplicación.

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

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

(Adición artículo de Wikipedia sobre μIP desde la fuente original está muerto.)

Tome un vistazo a Profibus .

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

¿Consideraría el protocolo MODBUS? Es orientado maestro / esclavo, por lo que el esclavo no podía iniciar la transferencia, pero por lo demás es ligero para su aplicación, libre y bien apoyado con herramientas de alto nivel. Usted sólo debe tener una idea de su terminología / como registro de retención, registro de entrada, la bobina de salida, etc.).

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

Tenga una mirada en microcontrolador red de Internet (MIN):

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

Inspirado por la CAN, pero el uso de hardware UART estándar, con formato de suma de comprobación y el marco de Fletcher comprobación de detección de errores y bytes de relleno para marcar una cabecera de trama.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top