RTOS sobre protocolo UART

Navega tus respuestas
3

Estoy desarrollando un protocolo UART para asegurar la comunicación entre dos placas (la placa maestra y la placa esclava). La placa esclava incluye muchos sensores y los actuadores y la placa maestra ordenará esta placa mediante un conjunto de comandos como GET_SENSOR_VALUE y SET_MOTOR_SPEED etc. Se ejecutarán muchas funciones en mi proyecto y se realizará un control permanente de los valores de los sensores ( Ejemplo: la tarjeta maestra obtendrá el valor de temperatura cada 5 segundos, obtendrá el nivel de la batería cada 5 segundos, habilitará la ventilación cuando la temperatura sea alta ...). Todos los equipos están conectados a la placa esclava (sensores y actuadores) y la función principal de la placa maestra es la supervisión.

He estado leyendo algunos artículos sobre especificaciones y diseño de sistemas integrados y descubrí que lo primero que hay que hacer antes de comenzar es elegir el núcleo: RTOS o GPOS (Bare metal).

Mi pregunta es: en mi caso, si elijo RTOS (en la placa maestra), ¿debo implementar mis necesidades como tareas / funciones separadas?

  • temperature_task
  • Humedad_tarea
  • battery_task
  • motor_task
  • ventilación_tareas

En caso afirmativo, ¿admite UART el tiempo de cambio de contexto de alta velocidad? ejemplo:

00:00 temperature_task: GET_TEMPERATURE     si temp > threshhold envía START_VENTILATION
  00:01 battery_task: GET_LEVEL if level < threshhold enviar TURN_OFF_SYSTEM
  00:02 humedad_tarea: GET_HUMIDITY si nivel < threshhold enviar DO_SOMETHING
00:03 temperature_task: GET_TEMPERATURE     si temp > threshhold envía START_VENTILATION
  00:04 battery_task: GET_LEVEL if level < threshhold enviar TURN_OFF_SYSTEM
  00:05 humedad_tarea: GET_HUMIDITY si nivel < threshhold enviar DO_SOMETHING

    
pregunta Pryda

2 respuestas

2

Sí, generalmente es una GRAN idea separar la funcionalidad de esta manera cuando un RTOS está en el sistema. Se debe tener mucho cuidado para asegurar la exclusión mutua entre las tareas y los recursos compartidos, como la memoria común o los periféricos, para evitar las condiciones de carrera y el comportamiento impredecible. Un enfoque común a este problema es bloquear cada periférico detrás de una tarea de "guardián de la puerta" que administra el flujo de datos hacia adentro y hacia afuera, generalmente emitiendo una función de devolución de llamada al llamante cuando se han recibido los datos esperados. Lea el artículo este (el Capítulo 7 trata este tema específicamente) de la documentación de FreeRTOS. Dicho esto, el enfoque básico puede ser perfectamente adecuado al tener un acoplamiento más estrecho entre los módulos funcionales del software.

    
respondido por el Luke Gary
2

Normalmente, UART es bidireccional (cable RX + TX), por lo que puede enviar / recibir sin necesidad de cambiar.

No tengo experiencia (Arduino) con RTOS, sin embargo, dividir la funcionalidad en funciones siempre es algo bueno. En este caso simple razonable no necesita tareas o un RTOS. Esto complicará principalmente el acceso a UART y el intercambio necesario de datos entre tareas.

Sobre sus requisitos de "sincronización": un segundo es una gran cantidad de tiempo, incluso para un simple microcontrolador como un Arduino. Probablemente pueda usar Arduinos de metal puro (a menos que planee usar cálculos / esquemas complicados), asumiendo que puede ajustar todos los sensores a un Arduino (o Mega?).

Si hace esto fijo (por ejemplo, siempre 20 bytes para acomodar todos los valores de los sensores), no necesita una nueva línea / fin del byte de mensaje.

Sobre el protocolo: ¿por qué no enviar cada x ms todos los datos de todos los sensores como un paquete al controlador (esclavo a maestro)? Y el maestro puede enviar mensajes breves como "Apagar el sistema" o comandos específicos (incluidos los parámetros) cuando sea necesario (sobre la marcha para baja latencia).

Ejemplo de comandos del esclavo al maestro: 

Byte   Meaning
0      Temp sensor
1      Humidity level
2      Battery level (?)
3      ... other sensors

Ejemplo de comandos de Master: 

Byte 0    Byte 1
Command   Parameter    Meaning
  0         n.a.      Turn off system 
  1         n.a.      Turn on system
  2         0-255     Move servo to loc x (as example)

etc.

    
respondido por el Michel Keijzers

Lea otras preguntas en las etiquetas

SPI Loopback valor recibido es la mitad del valor transmitido ¿Qué tipo de transistor para la tira de LED pulsante?