La compatibilidad de freemodbus es muy buena, y se puede portar fácilmente en muchas plataformas, lo que tiene una gran relación con su arquitectura de código.
Aquí no consideramos el proceso de trasplante de código, solo analizamos su jerarquía.
En mi opinión, el protocolo freemodbus en realidad se divide en tres niveles
1. Capa de aplicación (o interfaz expuesta a la capa de aplicación): todas las
definiciones de interfaz se incluyen en el archivo de encabezado mb.h y se implementan en mb.c.
Incluyendo las partes que no necesitan cambiarse durante la migración (algo de inicialización, habilitación, sondeo, etc.), y las partes que deben modificarse o implementarse (registre el controlador de devolución de llamada correspondiente al código de función dado, operaciones relacionadas con el registro, etc.).
Y en la inicialización, la función de devolución de llamada apunta a la interfaz de función de la segunda capa, lo que equivale a proporcionar una interfaz unificada para que todo el programa acceda a la función de la segunda capa, sin considerar los cambios de la segunda capa.
2. Capa de protocolo (trasplante):
esta capa refleja los diversos tipos de freemodbus (modo RTU, modo ASCII, modo TCP, etc.)
, definición de interfaz tipo.h (mbrtu.h / mbascii.h), que se incluye en el correspondiente .c Implementado en.
Todas las funciones que ve hasta ahora se pueden llamar directamente sin modificación. Se implementan funciones parciales como la inicialización específica (RTU), inicio, detención, procesamiento de recepción y procesamiento de transmisión.
Esta función de capa llama directamente a la interfaz de capa física.
3. Capa física:
La definición de interfaz se define en mbport.h. El usuario solo necesita implementar las interfaces relevantes de acuerdo con la implementación específica de la plataforma (inicializar el puerto serie, inicializar el temporizador con una unidad mínima de 50us, habilitar el puerto serie y el temporizador, etc.). Para la ubicación específica, las operaciones básicas relacionadas con el puerto serie están en portserial.c, el temporizador está relacionado con porttimer.c, y la máquina de estado está en portevent.h.
4. Punto especial:
aquí hay un lugar especial, que es recibir y enviar funciones de interrupción . La aceptación y el procesamiento reales se definen e implementan en la capa de protocolo (trasplante), pero la interrupción clara debe transferirse a la capa física para adaptarse a las diferentes plataformas.
Por lo tanto, freemodbus estipula que la interrupción de recepción y la interrupción de envío deben incluir dos funciones respectivamente, y estas dos funciones finalmente apuntan a las funciones de procesamiento de recepción y envío de la capa de trasplante de protocolo a través de devoluciones de llamada. La aceptación de la función de procesamiento de interrupción y el envío de la función de procesamiento de interrupción deben registrarse en la parte de inicialización del puerto serie de esta capa (capa física).
Así que creo que se puede decir que el protocolo freemodbus estipula el flujo de las funciones de procesamiento de interrupción.
También se puede decir que freemodbus ha completado la función de procesamiento de interrupciones, pero solo permite al usuario ayudar a borrar el indicador de interrupción en la capa física. Si se necesitan otras operaciones, también se pueden agregar al mismo tiempo.
5. Resumen: esta arquitectura obviamente se divide en tres niveles, que corresponden a las tres situaciones de migración de usuarios:
(1) Empresa: el puerto serie que recibe datos está completamente separado de la empresa, la empresa solo necesita llamar a la interfaz, sin hacer nada a la arquitectura del puerto serie Solo modifícalo.
(2) Protocolo de conmutación: suponiendo que se cambia de RTU a ASCII, solo necesita registrar la devolución de llamada de ASCii en la interfaz de la capa de aplicación para completar, sin modificar la capa inferior y el negocio.
(3) Cambio de la plataforma: tome como ejemplo el microordenador de un solo chip, solo el hardware de la capa física necesita ser readaptado al cambiar, sin ningún cambio en la capa superior.
Entonces el flujo de llamadas es:
Aplicación-> (llamada) interfaz de capa de aplicación-> (devolución de llamada) protocolo (puerto) función de capa-> (llamada) interfaz de capa física
Por supuesto, este acuerdo es mucho más complicado y específico que mi análisis, y continuaré estudiándolo, analizándolo y organizándolo en el futuro.