30 votos

¿Cómo se puede diseñar una serie de comandos de protocolo para un sistema embebido?

Tengo un sistema embebido, me estoy comunicando con más de serie. La estructura de mando ahora mismo está diseñado para ser operado de forma interactiva: se muestra un mensaje, acepta un par de comandos, y muestra los resultados en un formato legible.

Estoy pensando en cambiar esto a una más de la máquina-formato utilizable, así que puedo hablar con ella a través de una GUI de MATLAB sin demasiados problemas (ahora es hipo en el interactive solicita y la variación de mensaje de longitud, etc.).

Por lo que hay un documento estándar o en algún lugar que describe cómo diseñar una buena serie de comandos de protocolo para su sistema embebido?

41voto

Bruce McGee Puntos 12225

Tengo algunas preferencias y manías) de la escritura de software para el control de los medios de comunicación y dispositivos de visualización mediante RS232. Dependiendo de su hardware, algunos de estos pueden no ser aplicables:

  • Creo que es una buena idea para hacer su protocolo más amigable para la automatización. Si usted necesita una interfaz interactiva de línea de comandos (o de otros), compilación por separado y que utilice el protocolo de automatización. Yo no se preocupe demasiado acerca de lo que es legible por humanos, pero depende de usted.

  • Siempre devuelve una respuesta, incluso (sobre todo) si usted recibe un comando no válido. Algo tan simple como $06 de ACK y $15 para NAK. O hechizo, si quieres ser un poco más legible para los humanos.

  • Si se puede establecer cualquier valor, asegúrese de que hay una cierta manera a la consulta de que mismo valor. Si usted tiene un montón de valores, se podría tomar un tiempo para la consulta de todos ellos. Considere la posibilidad de tener uno o unos pocos meta-consultas que devuelven varios valores a la vez.

  • Si usted tiene información que no se puede establecer, pero es importante (modelo, número de serie, versión, autor, etc.), asegúrese de que estos pueden ser consultados en lugar de mostrar sólo una vez en el inicio o reinicio.

  • Nunca responder con un error de un comando válido. Uno pensaría que esto sería obvio...

  • Hablando de lo obvio, documento de la serie de la configuración de tu hardware es compatible. Especialmente si va a ser utilizado por nadie más que usted y que usted no quiere pasar los primeros 30 minutos tratando de averiguar si ellos no pueden hablar en el dispositivo porque de el puerto serie, las conexiones, el cable o su software. No es que me amargo...

  • El uso absoluto de comandos en lugar de alternar los valores. Por ejemplo, se han separado los comandos de Encendido y Apagado en lugar de enviar el mismo comando y tener el conmutador de alimentación de encendido y apagado.

  • Las respuestas deben incluir información sobre el comando que está respondiendo. De esta manera cualquier programa no es necesario recordar la última cosa que hizo en el fin de lidiar con la respuesta (véase el crédito adicional a la opción de abajo).

  • Si su dispositivo es compatible con un modo de espera (apagado, pero en realidad no lo fuera), asegúrese de que las consultas trabajar mientras estás en este estado.

Dependiendo de cómo paranoicos que son acerca de la integridad de datos:

  • Envuelve tu mensaje en un sobre. El encabezado se puede incluir un carácter de inicio, el lengeth del mensaje y un cierre de caracteres. Sólo en caso de ser parcial o mensajes con formato incorrecto. Tal vez de $02 para el inicio y $03 para el final.

  • Si eres muy paranoico acerca de la integridad del mensaje, incluir una suma de comprobación. Pueden ser un poco de un dolor, aunque.

Para crédito extra:

  • Si su configuración de hardware puede ser cambiado manualmente, tal vez enviar este cambio por el puerto serie como si el usuario hubiera consultado. Por ejemplo, puede que usted no desea que el usuario pueda cambiar la fuente de entrada para un público de monitor de pantalla.

Espero que esto ayude.

Actualización:

Me olvidé de algo importante. Antes de utilizar esto en serio y, especialmente, antes de dársela a alguien más, probarlo en algo trivial para asegurarse de que funciona de la manera que usted espera, y (más importante) para asegurarte de que no has dejado nada fuera. Va a tomar más tiempo y esfuerzo para arreglar las cosas si usted encuentra un problema en el medio de un proyecto más grande.

Esta es una buena regla de oro si usted está diseñando un protocolo de comandos, un servicio web, un esquema de base de datos o una clase, etc.

8voto

Marcelo MD Puntos 812

Aquí es un gran artículo por Eli Benderski en el protocolo de serie de encuadre. Sea cual sea el formato del paquete que usted elija, asegúrese de utilizar caracteres de escape. Esto le permite tener a estos personajes en el interior de datos reales y hace que sea muy fácil para volver a sincronizar en el caso de los paquetes de la corrupción.

5voto

Michael Kohne Puntos 8233

A menos que el ancho de banda o latencia es un gran problema, el uso de ASCII donde se puede - que hace que la depuración mucho más fácil.

Soy aficionado a los protocolos que enviar un mensaje, a continuación, un claro "mensaje final" carácter (tales como el "retorno de carro'). Yo generalmente no encontrar en inicio de paquete de señales para ser útil (¿qué otra cosa está en que el alambre?) El uso de CR para el mensaje final también hace que sea más fácil de poner a prueba a través de programa de terminal.

Actualización: Bruce señaló (en los comentarios) que de un inicio de paquetes carácter le permite encontrar los paquetes ligeramente más rápido en el caso de la corrupción. Sin el principio de paquetes carácter, habrá que esperar hasta el final del próximo paquete antes de que supiera dónde estaban y en ese momento se estaría lanzando 2 paquetes en lugar de uno.

4voto

Me gusta Bruce McGee respuestas. Después de haber trabajado con similar interfaces puedo ofrecer varios otros indicadores:

  • Al regresar tipos numéricos en un paquete de datos, por favor, por favor, por FAVOR trate de hacer todo en el mismo formato. No tiene solo un poco de números y el doble para los demás. Y no arbitraria!

  • Se proporcionan ejemplos de paquetes de datos en su ICD. Es terriblemente frustrante tener que adivinar el orden de los bytes o incluso la orden de bits (es MSByte primera, o la última? ¿Cuál es la primera y última?). Proporcionar un diagrama que muestra los paquetes en función del tiempo (es decir, 0x02 es enviado primeros, a continuación, la dirección de byte, entonces el id de mensaje, etc).

  • No cambie de alrededor de entre formatos de datos si es posible. He trabajado en sistemas que utilizan 'ASCII codificado números' de algunos mensajes donde tienes que tira el líder de '3' fuera de la bytes, a continuación, tirar de ellos juntos para hacer que el número real. (Generalmente ASCII-codificación se utiliza cuando se tiene una secuencia de bytes que se deben evitar, como 0x02, 0x04, etc. Codificado de los números sería 0x30, 0x32, 0x30, 0x34. El uso de un campo de longitud si es posible para evitar esto, o al menos lo hacen todo el tiempo!)

  • Definitivamente, definitivamente, definitivamente el documento de la velocidad en baudios, paridad, etc. Si usted está usando RS-485 documento el modo de bus (2-wire? 4-wire?) o lo que aparecen las opciones de configuración en la máquina en la que la intención de este para ser utilizado en. Dar las capturas de pantalla si es necesario.

Esta interfaz probablemente va a ser muy útil para la depuración. He trabajado con algunos de los sistemas que tenían las características de depuración, tales como:

  • Un sistema en el que el programador hizo una lista de 'registra los parámetros (variables internas). Usted sería como decir que el sistema que se quería informado (hasta 8) y, a continuación, cuando se le preguntó por el sistema para el registro de parámetros volvería en un paquete de datos. Me gustó esto, pero dependiendo de la complejidad del sistema que usted puede o no puede ser capaz de especificar ellos en tiempo de ejecución (o podría hacer algo simple y enviar el sistema de una mascarilla que seleccione los que desea que se devuelvan).

  • Los paquetes de datos que 'romper' el comportamiento y permitir que las partes del sistema probado de forma independiente (es decir, en un D/a de poner esta tensión, en un DIO de puerto stim este byte, etc)

Buena suerte!

2voto

Michael Burr Puntos 181287

FTP es un ejemplo de un protocolo que funciona razonablemente bien de forma interactiva y con la automatización. Una de las claves es que las respuestas comienzan con un código que indica si un fichero automatizado de cliente debe pagar attnetion o no. Del mismo modo para POP3.

Una cosa buena acerca de estos protocolos es que cuando su desarrollo/depuración se puede reasonbly de la unidad de la comunicación de regular la terminal de comandos o de la comunicación con los scripts de shell/archivos de proceso por lotes/lo que sea.

Sin embargo, hay una cosa que no se hacer es proporcionar la fiabilidad que proporciona una capa inferior de la comm de la pila. Es algo que debe ser considerado en la mayoría de los incrustado de comunicación de la pah.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X