Balada de transferencia de datos
En las primeras líneas de mi hemorragia de texto quiero decir lo siguiente: se ha escrito mucho sobre esto, escribiré mi visión. Las interfaces estándar para transmitir información son excelentes, pero para mis necesidades no proporcionan suficiente transferencia de datos satisfactoria (bueno, o casi). Intentaré hacer algunas adiciones para llevar esto al estado que más me convenga.Hay 2 o más dispositivos a una distancia suficientemente grande (1-100 metros) entre los cuales se deben transmitir los datos. Después de examinar algunas interfaces (rs232 / 422/485, I2C, Ethernet), llegué a la conclusión de que tampoco garantizan una transferencia de datos inequívoca, tampoco me gustaron muchos cables, no dieron una respuesta de que la información fuera aceptada. Decidí tomar la interfaz RS485 como base: puede ir muy lejos de sus ventajas, 2 cables, puede conectar un montón de dispositivos al mismo tiempo, es simple, (UART) está en casi cualquier controlador.En mi caso, el esquema clásico 1 que lidera al resto de los esclavos es adecuado para mí. El algoritmo de mensajería es el siguiente: los datos se transmiten en ciclos de intercambio, un ciclo de intercambio consiste en un mensaje que se transmite del maestro al esclavo, en respuesta el maestro recibe el mensaje del esclavo, todos los demás están en silencio. Sobre la misma base, implemente una solicitud de datos desde un dispositivo esclavo.
Un ciclo de intercambio.Para satisfacer mis necesidades de transferencia de datos, necesito resolver solo dos preguntas. Pregunta uno: la comprobación del byte transmitido se basa en la interfaz RS-485 en sí misma, pero no garantiza un byte transmitido confiablemente: si se encuentra un byte en la interfaz, se elimina de los datos recibidos, pero aún es posible transferir el byte incorrecto, si ha cambiado (se ha dañado) ) un número par de bits en un byte. es decir Se requiere una verificación del número de bytes transmitidos y la validez de bytes en los datos transmitidos.Pregunta dos: recibir un mensaje de respuesta al transmitido.Sobre la primera pregunta: se propone este esquema: el byte inicial, el byte del número decaracteres transmitidos en todo el mensaje, algo más, el byte de suma de comprobación (BCS), el byte final.
Nota: el byte de suma de verificación debe considerarse el módulo 2.Según el esquema propuesto, se puede juzgar que si la respuesta no regresó, entonces el seguidor no está disponible. En este caso, las opciones son posibles cuando un mensaje dañado llega al seguidor y él no responde, o el mensaje llega a él y envía la respuesta, pero la respuesta sale mal y el líder la ignora.Para corregir esto, se aceptó: si la respuesta no llega (o no es confiable), repita (el número de veces sin locura) repita el ciclo de intercambio actual. El siguiente error puede ocurrir aquí. Supongamos que enviamos un comando diciéndole al dispositivo que necesita subir el volumen en +1 unidad. Cuando el mensaje llega al esclavo, ejecuta el comando para subir el volumen y envía la respuesta "ok, hice lo que quería", pero puede resultar que la respuesta salga mal y el presentador no entiende que el comando ya se ha ejecutado, y envía el mensaje nuevamente. Como resultado, al recibir un comando en el lado esclavo, el volumen ya será agregado por +2 unidades. Para evitar este fenómeno, se acostumbra introducir un identificador (NS - número de mensaje) de la diferencia del mensaje. Si el número del mensaje se repite, entonces este es un mensaje repetido y el comando especificado no necesita ejecutarse,pero solo envíe el mensaje de respuesta anterior.También ingreso 2 parámetros más aquí: este es el número (código) del dispositivo al que se transmiten los datos y el número (subcódigo) que indica qué comando debe ejecutarse (o qué datos están dentro del mensaje).
Como resultado, lo pondré todo junto y pasaré por el algoritmo, utilizando el ejemplo de aumentar el umbral del relé en 5 grados centígrados y tomar la temperatura actual del esclavo durante 1 ciclo de intercambio:genero los datos transmitidos desde el maestro:
cuando se recibe el mensaje, el esclavo mira 2 bytes, donde es el número de bytes enviados, si el número de bytes enviados es igual al número recibido, entonces el mensaje no ha perdido bytes, entonces miramos el byte inicial (carácter) si = '$', y también el byte final (carácter) si = ' # '- este es un mensaje de viajar al esclavo.Inmediatamente consideraré las posibles opciones de mensaje del maestro al esclavo con errores en los bytes iniciales y finales, así como la opción con un error en el número de bytes en el mensaje. Haré una reserva de inmediato de 3 valores de parámetros que consideraré correctos 2 y 3, es decir si 2 parámetros de 3 posibles coinciden, considero que el mensaje es válido.1. byte de inicio = '$', número de bytes recibidos = 7 (número de bytes enviados = 7), el byte final no es igual a '#';
2. el byte inicial no es igual a '$', el número de bytes recibidos = 7 (el número de bytes enviados = 7), el byte final = '#';
3. byte de inicio = '$', número de bytes recibidos = 7 (número de bytes enviados = 7, número de bytes no es igual a 7), byte final = '#'.
A continuación, calculamos la suma de verificación de los 3 bytes restantes (bytes 3, 4, 5), si coincide con el BCS, continuamos analizando los datos, buscamos este dispositivo para estos datos y qué se debe hacer en él, en nuestro caso el código esclavo es 55 y el subcódigo 2 dice sobre la necesidad de agregar otros 5 grados al umbral del relé y en el mensaje de respuesta para enviar los datos de temperatura actuales. Verifico el NS si no es igual al número de mensaje anterior, luego ejecuto el comando y agrego 5 grados al valor actual del umbral del relé. Si son iguales (NS), entonces no realizo las acciones indicadas, luego procedo a la formación de un mensaje de respuesta.aplicación del esquema ['$'] [número de bytes enviados / recibidos] [...] ['#'] - con una alta probabilidad garantiza que tal combinación no se podrá encontrar en los datos transmitidos y provocará un mensaje falso.Formo los datos transmitidos desde el esclavo en función del mensaje recibido:
El principio de procesamiento es el siguiente: mire 2 bytes donde se encuentra el número de bytes enviados, si el número de bytes enviados es igual al número de bytes recibidos y también el byte inicial = '@' y el byte final = '&' - este es un mensaje del esclavo al maestro. Si es necesario, uso el mecanismo 2 de 3, similar al descrito anteriormente solo para el mensaje de respuesta (para los caracteres '@' y '&'). Al recibir este mensaje, el host analiza los 9 bytes de la suma de verificación (del 3 al 11), si la suma de verificación coincide, los datos en el mensaje se consideran confiables y el análisis de datos continúa. Si el código, el subcódigo y el NS de los mensajes enviados y recibidos coinciden, continuamos analizando la respuesta al mensaje enviado por el host. El siguiente es el análisis de los datos recibidos,en mi caso, en el sexto byte, un valor de 1 significa que el comando para aumentar 5 grados hasta el umbral del relé fue exitoso, los 5 bytes restantes indican las lecturas de temperatura actuales; el séptimo byte es una bandera que indica la confiabilidad de la temperatura transmitida (es decir, Estoy considerando la opción de que el esclavo está encendido y responde, pero el sensor puede no funcionar) y 4 bytes de valores de temperatura de flotación.El uso de 2 caracteres de prueba al principio y al final de un mensaje con una alta probabilidad garantiza que, en caso de error, no confunda los mensajes del esclavo y el maestro. Además, los datos aleatorios (no aleatorios) en el canal no estropearán el intercambio.Un poco sobre la transmisión de datos del esclavo al esclavo, y un mensaje centralizado a todos los esclavos del maestro.Primero, el último: la transmisión del maestro por el esclavo se lleva a cabo asignando el código de dispositivo 255, que le dice al esclavo que este es un mensaje centralizado, luego solo queda resolver el problema de los subcódigos comunes, también es posible agrupar por códigos de dispositivo, es decir asignar el código de dispositivo 254 y 3 o 4 dispositivos recibirán un mensaje usando este código; el resto lo ignorará, naturalmente, la parte de enviar respuestas de esclavos no debería funcionar aquí, es decir ¡no está garantizado que los seguidores hayan aceptado inequívocamente estos mensajes!El esclavo envía información sobre la transmisión de datos al esclavo, implementado por el maestro envía un mensaje al esclavo (esclavo1) desde el cual se debe enviar información al otro esclavo (esclavo2), el esclavo1 envía una respuesta al maestro mientras el esclavo2 escucha esta respuesta tomando los datos para sí mismo. De nuevo, no hay garantía de una entrega inequívoca de mensajes de esclavo1 a esclavo2, ¡esto debe tenerse en cuenta!Número de capacidades de interfaz de dispositivos teóricamente conectados alrededor de 250, comandos / tipos de datos de hasta 248 para cada dispositivo, la longitud de la información útil en el mensaje es de hasta 250 bytes.Hable acerca de las trampas:Toda la transferencia de datos está diseñada para funcionar a tiempo, es decir se deben observar ciertos retrasos entre mensajes. También le recomiendo que haga un retraso fijo entre el mensaje enviado por el maestro y la respuesta del esclavo para que el esclavo pueda generar datos y transmitirlos por completo al canal.El momento de organizar las respuestas del esclavo también es importante, puede suceder que el esclavo esté ocupado y tenga varios mensajes de datos en su canal a la vez, debe evitar las respuestas a mensajes obsoletos (porque el líder ya no los espera) ignorándolos, ejecutando comandos de solo los últimos mensajes y dale una respuesta.Por separado, me gustaría resaltar el problema de la sincronización de dispositivos por tiempo: debe tenerse en cuenta que la sincronización de tiempo del esclavo al recibir un mensaje requiere tener en cuenta el retraso de tiempo para enviar datos al canal (a una velocidad de 9600, se transmitirá un mensaje de 10 bytes durante aproximadamente 11 ms) y el momento en que se activa la interrupción al final recibir datos en el lado esclavo, si no hay interrupción, vale la pena considerar el momento de verificar la llegada de datos en el búfer del dispositivo, etc.También vale la pena señalar que reenviar un ciclo de mensajes también agrega matices, recomiendo usar el envío de mensajes sin repeticiones para la sincronización de tiempo y componer mensajes con un nuevo NS.PSTengo dudas de que descubrí algo nuevo aquí, ¡todo esto se utiliza en alguna parte en diferentes interfaces! Con la mano ligera del autor de este garabato y la aplicación de este protocolo en mis desarrollos, quiero dar el nombre a este protocolo de transferencia de datos "SRDB2". Source: https://habr.com/ru/post/es398791/
All Articles