Sistema de transferencia de archivos único basado en el protocolo xmodem. (Proyecto de graduación).
Resumen: Este artículo describe el diseño del programa de comunicación utilizando el protocolo de transferencia de archivos XMOMDEM. Este diseño proporciona la función de transferencia de archivos entre el sistema integrado con memoria FLASH y el software HyperTerminal en la PC sin instalación. Se puede realizar software de comunicación especial en la máquina, actualizaciones de programas a bordo, personalización de datos a bordo, etc., lo que brinda comodidad para la depuración y el mantenimiento en el sitio. Además, este artículo también describe el método de programación del software de comunicación basado en la matriz de estado.
Palabras clave: descarga de archivos XMODEM Matriz de estado FSM
1 Propósito y uso del diseño
2 Introducción al protocolo XMODEM
3 Capas y protocolos interfaz entre capas
3.1 Capas de protocolo
3.2 Interfaz entre la capa de enlace y la capa física
3.3 Interfaz entre la capa de enlace y la capa de aplicación
4 Implementación de protocolo en capas
4.1 Plataforma de sistema operativo de protocolo
4.2 Implementación de software de capa de aplicación
4.3 Implementación de software de capa de enlace
p>
4.4 Implementación de software de capa física
5 Trasplante de software
6 Método de depuración de software
Referencias
Apéndice 1: Lista de excepciones en Comunicación del protocolo XMODEM
Apéndice 2: Tabla de transición de estado del protocolo XMODEM
Apéndice 3: Lista de archivos de código fuente
Apéndice 4: Código fuente completo
1 Propósito y uso del diseño
El código de programa de los sistemas integrados generalmente se almacena en la memoria FLASH o en la memoria OTP. Esta última es en realidad una EPROM programable de una sola vez. El costo es bajo y es adecuado para aplicaciones de gran tamaño. Productos de volumen, pero el programa no se puede modificar después de escribirlo. La ventaja de usar FLASH es que el programa se puede reemplazar en la placa en cualquier momento. Esta característica brinda una gran comodidad para la depuración en el sitio y las actualizaciones y modificaciones del software.
Existen varios métodos para programar FLASH en placas impresas. El método original es utilizar un programador, lo cual es muy inconveniente porque es necesario quitar el chip. También hay procesadores producidos por algunos fabricantes que están conectados. a través de la interfaz JTAG o el puerto serie En una PC (como la P89C51RD de PHILIPS), se puede lograr la programación integrada del FLASH interno del procesador, pero se requiere una descarga especial del software de programación (generalmente proporcionado por el fabricante del chip). , y el FLASH externo al procesador no se puede programar.
El uso del protocolo XMODEM para descargar programas es una práctica común para muchos productos, como los productos de enrutador de CISCO y los productos de terminal ISDN de HUAWEI. Este método utiliza el software HyperTerminal que viene con WINDOWS para transferir archivos. instalar software especial. Siempre que agregue un diagrama de código 1 que implemente el protocolo XMODEM en la placa de destino, podrá descargar fácilmente programas o archivos de datos. A continuación, se describe el método de implementación del programa de protocolo XMODEM.
Gráfico 1: El programa de la placa de destino consta de dos partes: programa de descarga y programa de aplicación
2 Introducción al protocolo XMODEM
El documento 1 del protocolo XMODEM es el más antiguo 2 Es un protocolo de comunicación estándar para la transferencia de archivos entre computadoras a través del puerto serie asíncrono RS232. En comparación con otros protocolos de transferencia de archivos como YMODEM y ZMODEM, el protocolo XMODEM es simple de implementar y adecuado para aquellas ocasiones con memoria limitada.
El remitente del archivo XMODEM descompone el archivo en bloques de datos de longitud fija de 128 bytes. Cada vez que se envía un bloque de datos, espera a que la otra parte responda antes de enviar el siguiente bloque de datos. Acumulación y verificación vertical, también puede utilizar la verificación CRC de 16 bits. Es un protocolo ARQ (Solicitud de repetición automática) simple, por lo que también es adecuado para su uso en redes RS485 semidúplex de 2 hilos.
2.1 Terminología
Antes de describir el contenido específico del protocolo XMODEM, primero damos la tabla de abreviaturas terminológicas 2 utilizadas en el protocolo.
Observaciones sobre el significado numérico de los términos
Decimal hexadecimal
SOH 1 01H Inicio del bloque de datos
EOT 4 04H Fin de la transmisión
p>
ACK 6 06H Respuesta aceptada
NAK 21 15H Respuesta no aceptada Para el software de protocolo de verificación CRC, esta señal se reemplaza por la letra "C" (43H).
DLE 16 10H Abortar conexión de datos
Cuando el buffer de recepción está lleno debido a la lentitud, se envía "X-off" al remitente para hacer que el remitente detenga el envío de datos. Equivalente a DSR, CTS y otras señales de interfaz RS232.
X-off 19 13H Se detiene la transmisión de datos
SYN 22 16H Sincronización
CAN 24 18H Cancela la transmisión
Gráfico 2: Protocolo XMODEM Los caracteres de control
Cada abreviatura en la tabla anterior también es un carácter del código ASCII estándar. Estos caracteres deben usarse en el protocolo XMODEM para expresar el estado del protocolo. Y su significado básico es el que se describe en la tabla.
2.2 Formato del marco de datos y descomposición del archivo
La longitud del marco de datos transmitido por el protocolo XMODEM cada vez es de 132 bytes, de los cuales los datos del archivo representan 128 bytes, y el Otros 4 bytes son el indicador de inicio, el número de secuencia del bloque, el complemento del número de secuencia del bloque y el byte de verificación. La marca de inicio, el número de secuencia del bloque y el complemento del número de secuencia del bloque se encuentran al principio del bloque de datos, y el byte de verificación se encuentra al final del bloque de datos, como se muestra en la Figura 3:
Descripción del nombre del número de byte de desplazamiento
Valor del nombre (HEX)
0 1 SOH 01 Indicador de byte de inicio
1 1 Seq 1~Número de secuencia del bloque FFh
2 1 cmpl FFH- seq El complemento del número de secuencia del bloque
3 128 datos? Datos del contenido del archivo
131 1 csum Verificación de suma de acumulación vertical 1 : El protocolo XMODEM permite el uso de 2 tipos de códigos de verificación. 2: El código de verificación solo se calcula a partir de 128 bytes de datos y los primeros 3 bytes no participan en la operación de suma de verificación.
2 CRC ? Comprobación de redundancia cíclica de 16 bits
Gráfico 3: Formato de trama de datos del protocolo XMODEM
Si la longitud del archivo no es un múltiplo entero de 128 bytes, el contenido efectivo del último bloque de datos debe ser menor que la longitud del marco y la parte restante debe completarse con otros datos. XMODEM recomienda usar "CTRL-Z" (=26 (01aH)). ¿Cómo distingue el receptor el marco? ¿Qué pasa con el contenido que pertenece al archivo y el contenido que se completa?
Si el archivo transmitido es un archivo de texto que contiene solo letras, números y símbolos visualizables (como un archivo de código fuente de un programa C), entonces el destinatario puede distinguirlo basándose en el contenido mismo ("26" es (no una letra o un código de números ASCII), si se transmite un archivo binario con cualquier valor (como un código objeto de programa), el receptor no puede distinguir el contenido del archivo y el contenido del relleno.
Nota importante: El protocolo XMODEM no garantiza que la longitud del archivo recibido por el receptor sea exactamente la misma que la del remitente. La longitud de los datos del archivo recibido por el receptor es siempre un múltiplo entero de. 128 bytes, que es más larga que la longitud real del archivo enviado. Big 1 a 127 bytes. El contenido adicional está al final del archivo.
Esta deficiencia del protocolo XMODEM no tiene ningún impacto práctico en la descarga de código de programa para sistemas integrados. El procesador no ejecutará el contenido de llenado como código, siempre que la memoria del programa tenga suficiente capacidad para almacenar todo lo recibido. los datos están disponibles. Si se utiliza el protocolo XMODEM para la descarga de la base de datos, se debe considerar el impacto del contenido redundante. Generalmente, los archivos de base de datos estándar tienen parámetros de estructura de base de datos como el tamaño de la base de datos, la cantidad de campos, la cantidad de registros, etc., por lo que el contenido completo no se cargará. considerarse registros de la base de datos en sí.
Del mismo modo, para bases de datos como las bibliotecas de caracteres chinos, la descarga utilizando el protocolo XMODEM no causará problemas.
2.3 Algoritmo de Verificación
El código de verificación es un código que se obtiene realizando algún cálculo sobre los datos enviados. Para evitar ciertos errores de bits en los datos durante la transmisión, se utilizan varios protocolos de comunicación de datos. Se estipula que, además de enviar los datos de la solicitud, el remitente también debe enviar un código de verificación, y el receptor de datos calcula el código de verificación a partir de los datos de la solicitud recibidos de acuerdo con el mismo algoritmo y lo compara con el código de verificación enviado por el remitente, si es igual, se considera que se han recibido datos correctos.
En el protocolo XMODEM, se puede utilizar la suma acumulativa vertical o la verificación CRC. El software de comunicación que utiliza la verificación CRC puede cambiar automáticamente del modo de verificación CRC al modo de verificación de suma acumulativa. En esta aplicación, utilizamos la verificación de suma vertical.
El código de verificación de suma acumulativa es acumular la suma de todos los datos enviados por bytes y retener el byte más bajo como código de verificación. Por ejemplo, los tres bytes de datos enviados son 255 (FFh), 5. (05h),6(06h), luego:
1 1 1 1 1 1 1 1 FFH
0 0 0 0 0 1 0 1 05H
0 0 0 0 0 1 1 0 06H
1 0 0 0 0 1 0 1 0 -> 0000 1010
Después de descartar los bits altos, el código de verificación de suma acumulada es 0Ah ( 10). En el ejemplo anterior, si los datos originales cambian en el camino, como FFH se convierte en FEH, 06H se convierte en 07H y 05H permanece sin cambios, el código de verificación calculado por el receptor es:
Recibir Enviar
1 1 1 1 1 1 1 0 FEH <- FFH
0 0 0 0 0 1 0 1 05H < - 05H
0 0 0 0 0 1 1 1 07H <- 06H
1 0 0 0 0 1 0 1 0 -> 0000 1010
El código de verificación también es 0AH. Se puede ver que cuando cambian 2 bits en los datos, el código de verificación calculado por el receptor sigue siendo coherente con el del remitente. Este método de verificación no puede detectar errores de bits pares.
El código de verificación del protocolo XMODEM se calcula solo para los 128 bytes de datos en el marco de datos. Los primeros 3 bytes no participan en la operación de suma de verificación.
2.4 Inicio del protocolo XMODEM
El protocolo XMODEM se inicia cuando el receptor del archivo envía un byte "NAK", y el remitente del archivo envía una trama de datos después de recibir la señal, y el dos partes inician el proceso de comunicación normal. Después de que el remitente del archivo ingresa al protocolo XMODEN, espera a que la otra parte envíe "NAK". Si el tiempo de espera excede los 60 segundos, sale de esta comunicación (Figura 4B).
Después de que el receptor envía "NAK", si la otra parte no ha enviado el primer cuadro de datos después de 10 segundos, enviará "NAK" repetidamente. Esta repetición se permite hasta 10 veces, y la tercera. La trama de datos aún no se recibe. Un bloque de datos, luego salga de esta comunicación. Figura 4A.
Gráfico 4 Dos situaciones en las que no se puede iniciar el protocolo XMODEM
En aplicaciones donde el sistema integrado descarga software a través de la PC, el software del sistema integrado es el receptor de archivos y la PC super terminal El software es el remitente del archivo. Según el protocolo, después de que el software de comunicación del sistema integrado ingresa al estado del protocolo XMODEM, el software de la PC debe ingresar al estado del protocolo dentro de 100 segundos (es decir, ejecutar la función de transferencia de archivos XMODEM del Hyper Terminal). el último ingresa primero al estado de protocolo y el primero debe ingresar al estado de protocolo en 60 segundos. Obviamente, esta diferencia de tiempo es un poco estrecha cuando se opera manualmente. La única solución es alargar el tiempo de espera de inicio para cargar el software en el sistema integrado. Esta modificación no causará ambigüedad en la comprensión del protocolo.
Nota importante: para facilitar que el remitente y el receptor inicien el protocolo XMODEM, en el diseño, el tiempo de retardo de inicio del software de descarga del sistema integrado se ampliará en el siguiente código. este retraso El tiempo se cambia a 600 segundos (10 minutos). O establezca el tiempo de espera en infinito y envíe señales "NAK" de manera constante hasta que se ejecute el software HyperTerminal en la PC.
2.5 El proceso de transmisión normal de XMODEM
La Figura 5 muestra el proceso de comunicación tanto del emisor como del receptor en una comunicación XMODEM normal.
Figura 5: Proceso de transferencia de archivos sin errores
Cada vez que el receptor del archivo recibe un marco de datos, si no hay error de verificación, error de número de secuencia, etc., enviará un carácter "ACK" " como respuesta. El remitente comienza a enviar el siguiente carácter después de recibir la respuesta. Esto se repite hasta que se transfiere el contenido del archivo. El remitente envía el carácter "EOT" para indicar que la transferencia se ha completado. Después de recibir el remitente responde con "ACK" nuevamente; en este punto, todo el proceso de transferencia de archivos ha terminado.
2.6 Suspensión del protocolo XMODEM
Durante el proceso de comunicación, si alguna de las partes desea finalizar esta comunicación, puede enviar el carácter "CAN" a la otra parte. Ahora hay muchos protocolos XMODEM. El software requiere enviar 2 caracteres "CAN" para lograr esto.
La terminación activa de la comunicación por parte del software de protocolo generalmente se inicia manualmente, como presionar el botón "Cancelar" del software HyperTerminal. O utilice el interruptor DIP para controlar el software de descarga del sistema integrado para salir de la comunicación.
2.7 Manejo de excepciones del protocolo XMODEM
Durante el proceso de comunicación, siempre ocurren diversas situaciones anormales, como la interrupción repentina de la línea de comunicación, el corte de energía de la máquina de una parte que causa el el software deja de ejecutarse, etc. El software de comunicación debe poder detectar estos errores y manejarlos adecuadamente. El tema de la detección de errores se cubrió en la sección anterior de inicio del protocolo. XMODEM tiene disposiciones muy detalladas sobre errores. Hay 8 situaciones en total. El texto del protocolo no explica cómo se producen. Las posibles razones se dan en el Apéndice 1. ,
En los sistemas integrados, considerando que la descarga de software generalmente es operada por humanos, es posible que no se considere el manejo de errores, por lo que se reducirá el código de implementación. En este artículo, se considera el manejo de diversos errores teniendo en cuenta la integridad del protocolo.
2.8 Cambiar entre el modo de verificación CRC y verificación de suma acumulativa
El protocolo XMODEM requiere que el software de comunicación que admite la verificación CRC también admita la verificación de suma acumulativa, de modo que pueda usarse con aquellos que solo se comunican con software que admite la verificación de suma acumulativa. Si el receptor de archivos solo admite la suma acumulativa y el remitente puede admitir CRC, el receptor envía una señal de inicio de "NAK" y el remitente envía automáticamente tramas de datos en el método de suma acumulativa. después de recibirla, si por el contrario, el receptor admite CRC y el remitente admite suma acumulativa, el receptor envía primero la letra "C" como señal de inicio. En este momento, el receptor debe ignorar esta señal y el remitente continúa enviando. la señal "C" después de 3 segundos, después de no recibir respuesta tres veces, se envía la señal "NAK", lo que indica que se utiliza el método de suma acumulativa para la comunicación.
Si ambas partes que se comunican utilizan la verificación CRC, la señal de protocolo de enlace de comunicación anterior "NAK" se reemplaza por la letra "C" y los demás procesos son los mismos que los anteriores.
Porque el El software PC Hyper Terminal admite el modo CRC. Como receptor de archivos, el sistema integrado puede comunicarse automáticamente con la otra parte de acuerdo con el método de suma de verificación enviando una señal "NAK".
3 Protocolos en capas e intercapas. interfaz
3.1 Capas de protocolo
Dividimos el código de protocolo en 3 capas: capa física, capa de enlace y capa de aplicación de protocolo. La capa física se utiliza para controlar el dispositivo UART, el enlace. La capa maneja el protocolo XMODEM y la capa de aplicación es responsable de recibir datos. El único bloque de datos de 128 bytes obtenido se combina en un bloque de datos completo y se escribe en el búfer de memoria del programa. Con esta capa, solo la capa física y la capa de aplicación. El código relacionado con el hardware debe modificarse cuando se trasplanta el programa, sin modificar la implementación de XMODEM. El código de la capa de enlace del protocolo.
Las capas se comunican a través de mensajes. El protocolo XMODEM no especifica la estructura en capas ni el formato de mensaje entre capas. Aquí, la comunicación entre la capa de enlace y la capa de aplicación, y entre la capa de enlace y la física. la capa es El formato del mensaje se especifica uniformemente de la siguiente manera:
typedef struct {
int len /* Longitud del contenido del mensaje, es decir, el número de bytes en el mensaje*/
char mType; /* Tipo de mensaje entre capas, */
char Message[MAX_ MESSAGE_LEN] /* Contenido del mensaje, completado por el proceso de envío*/
} MessageOfLayer;
Considerando que la trama de datos XMODEM es de 132 bytes, la constante "MAX_MESSAGE_LEN" se define como 132 bytes. Según el estándar OSI, las primitivas de mensajes entre capas tienen cuatro tipos: Solicitud de datos, indicación de datos, respuesta y confirmación Documento 5. La Figura 7 muestra los tipos de mensajes entre capas cuando la Parte A envía datos y la Parte B recibe datos. Figura 6: Secuencia de mensajes entre capas para transmisión de datos unidireccional: ①②③④
Los mensajes 1 y 2 transportan datos reales. Marco de datos, los mensajes 3 y 4 son marcos de respuesta durante el proceso de transmisión, lo que indica que los datos se han transmitido correctamente. Debe tenerse en cuenta que el mensaje de confirmación 3 de los datos enviados no se envía desde la otra parte. los datos, inmediatamente sube. La capa envía un mensaje de confirmación.
En aplicaciones prácticas, además de los mensajes necesarios para la transmisión de datos normal, también es necesario definir algunos mensajes de gestión de control. Los tipos y funciones de los mensajes entre capas se explican en detalle a continuación.
3.2 Interfaz entre la capa de enlace y la capa física
n Solicitud de datos: este mensaje se utiliza para enviar datos de trama XMODEM a la capa física, incluida la trama de datos de archivo de 132 bytes y NAK. ACK, CAN tramas de señal de un solo byte, etc. El software de descarga solo recibe archivos y no necesita enviar tramas de datos de archivos de 132 bytes.
n Confirmación de datos: después de que la capa física recibe el marco de solicitud de datos de la capa de enlace, se envía al búfer UART. Cuando el búfer de envío está vacío, indica que los datos de bytes se han enviado y. enviado al enlace. La capa de ruta envía un mensaje de confirmación. Después de que la capa de enlace recibe este mensaje, puede enviar el siguiente byte. De hecho, la transmisión de la capa física es sin conexión. No puede indicar que la otra parte ha recibido los datos correctamente, solo indica que los datos han sido enviados. Los protocolos de capa física generalmente no proporcionan mecanismos de transmisión de acuse de recibo.
n Indicación de datos: la capa física envía datos a la capa de enlace una vez que el búfer de recepción está lleno.
Además de los 3 mensajes anteriores, también existen los siguientes 2 mensajes entre la capa física y la capa de aplicación:
n Circuito de inicio: enviado desde la capa de enlace a la capa física. capa, la capa física Después de recibir el protocolo, se inicializará el puerto serie.
n Error de circuito: Enviado por la capa física a la capa de enlace, utilizado para informar errores en el proceso de transmisión de datos de la capa física.
El mensaje "Respuesta de datos" no se utiliza en esta aplicación.
3.3 Interfaz entre la capa de enlace y la capa de aplicación
Hay dos mensajes de transmisión de datos entre la capa de enlace y la capa de aplicación:
n bloque de datos Instrucción: La capa de enlace recibe una trama de protocolo XMODEM (128 bytes) y la envía a la capa de aplicación. Después de que la capa de aplicación recibe la trama de datos, la escribe en la memoria flash (la versión para PC lo escribe en un archivo).
n Respuesta del bloque de datos: la capa de aplicación envía una señal de respuesta a la capa de enlace después de recibir el marco de datos XMODEM y escribirlo en la memoria flash (la versión para PC escribe en un archivo). Después de recibir la respuesta, la capa de enlace envía una señal "ACK" al remitente del archivo.
Se definen otros tres mensajes de control de gestión:
n Inicio del protocolo: la capa de aplicación notifica a la capa de enlace que inicie el protocolo XMODEM.
n Fin de la comunicación: después de recibir la señal EOT de la otra parte, la capa de enlace la envía a la capa de aplicación. Después de que la capa de aplicación recibe este mensaje, puede transferirla a la entrada de la aplicación para ejecutarla. solicitud.
n Aborto de comunicación: cuando la capa de enlace no puede continuar la transmisión XMODEM debido a diversas circunstancias, envía este mensaje a la capa de aplicación. Después de recibir este mensaje, la capa de aplicación descarta los datos recibidos y emite un error de comunicación. indicación.
4 Implementación del protocolo en capas
4.1 Plataforma del sistema operativo del protocolo
Para implementar el protocolo en capas, el sistema operativo no preventivo del Documento 4 se utiliza como plataforma de software, cada capa se trata como un proceso.
4.2 Implementación del software de la capa de aplicación
El software de descarga del sistema integrado solo recibe archivos de código. No es necesario escribir el código de procesamiento como remitente del archivo en el protocolo. La capa de aplicación es para recibir el enlace. Los paquetes de datos de la capa se escriben en la memoria del programa de acuerdo con el orden en que se reciben los paquetes de datos. Al simular la implementación en la PC, almacenamos los datos en un búfer, los escribimos. en un archivo una vez completado y utilice el software windiff para compararlo con el archivo enviado y determinar si el código es correcto.
La función del código de inicialización del proceso de la capa de aplicación es:
n Borrar la MEMORIA FLASH utilizada en la memoria del programa (en este ejemplo, escriba el código según 29F010).
n Inicie un temporizador de 10 segundos y notifique a la capa de enlace que inicie el protocolo XMODEM después de 10 segundos.
n