¿Debe "obtener nuevos datos del sensor" ser su propia tarea en un RTOS?

5

Soy nuevo en las prácticas / arquitecturas de codificación RTOS, y estoy aprendiendo específicamente en RTX. ¿Debo tener una tarea get_new_sensor_data para cada sensor, o los datos del sensor generalmente se cuidan por algún otro medio, como en el ISR, fuera de cualquier tarea en particular? ¿Cómo marca sus aplicaciones que tiene un nuevo dato para ellas?

No quiero llamar a subrutinas de lectura de hardware desde las aplicaciones que usan los datos del sensor porque los datos pueden estar bloqueando varias aplicaciones diferentes. p.ej. la temperatura puede entrar en una tarea de cálculo de humedad relativa, puede ser utilizada por una tarea que le da temperatura al usuario a través del UART, y puede ser utilizada en otra tarea que está corrigiendo algún otro sensor que tenga una salida dependiente de la temperatura. / p>     

pregunta Bob

2 respuestas

2

Algunos tipos de sensores deben leerse en un horario muy estricto o, de lo contrario, la información recibida desde allí será errónea, ya sea porque la lectura debe tener una cierta relación de sincronización con algún otro evento (por ejemplo, uno mide la luz reflejada por la lámpara de iluminación). que es solo para 100us cada 10 ms), o porque las lecturas encapsulan la información de tiempo implícita (por ejemplo, si se intenta muestrear audio a 44100 Khz, cada lectura debe encapsular el hecho de que se tomó 22.6757 microsegundos después de la anterior; simplemente se tomaron 44.100 lecturas en los tiempos arbitrarios en un intervalo de un segundo no son equivalentes!). Otros tipos de sensores pueden leerse a gusto.

Si está tratando con el tipo anterior de sensor, debería tener una tarea programada de muy alta prioridad para hacer la lectura, o bien hacerlo dentro de una interrupción de temporizador que se envía directamente en lugar de a través del sistema operativo. Organice las cosas de modo que, a menos que la aplicación se retrase tanto que la pérdida de datos sea inevitable, el código de lectura del sensor siempre tendrá un lugar donde colocar sus datos. Si tiene varios sensores que necesitan interactuar, a menudo es bueno manejarlos todos dentro de la misma interrupción del temporizador cuando sea práctico. Si todo puede ser manejado por ej. una interrupción en el manejo del sensor de 10 KHz, el uso de una interrupción de velocidad fija para todo es a menudo mucho más simple que tratar de lidiar con el cambio en las tasas de interrupción, incluso si muchas veces lo único que hará la interrupción es disminuir "¿Cuántas tics más hasta que haga algo? interesante "contador.

A veces, tener diferentes tareas para diferentes sensores puede ser un buen enfoque, pero si algún sensor comparte recursos (como los canales ADC), puede ser muy difícil asegurarse de que nunca haya conflictos de tiempo. Por ejemplo, si por ejemplo uno tiene un sensor que debe leerse a una velocidad estricta de 5 KHz y otro que debe leerse a una velocidad muy estricta de 2 KHz, y ambos sensores usan el mismo ADC, puede ser más útil tener una interrupción de 20 KHz y organizar las cosas de manera tal que cada interrupción capture la lectura solicitada previamente, solicita una nueva lectura, ambas o ninguna, y los dos sensores escalonarán sus lecturas para que nunca tengan que tener solicitudes pendientes simultáneamente. Si los dos sensores fueron manejados por tareas separadas, asegurarse de que ningún sensor querrá usar el ADC cuando el otro sensor lo esté utilizando puede ser más difícil.

    
respondido por el supercat
2

La pregunta que hagas no puede ser respondida en general. Hay algunos enfoques comunes, cada uno con los pros y los contras.

  • Lectura asíncrona bajo demanda. Bien cuando el proceso que necesita el valor puede esperar a que se complete la lectura. Podría ser la mejor solución cuando la lectura es costosa (por ejemplo, en términos de mAh).

  • Lectura síncrona (periódica) en un grupo, los usuarios leen del grupo. A menudo es un buen compromiso, especialmente cuando los usuarios deben procesar el valor, incluso cuando no se modifica.

  • Lectura síncrona (periódica), se notifica a los usuarios cuando es necesario (publicación-suscripción, escucha). Esto se usa a menudo para entradas de activación que ocurren solo esporádicamente, como una tecla que se presiona o suelta. Buena idea cuando el costo de procesamiento es relativamente alto.

En los dos últimos enfoques se pueden usar interrupciones en lugar de lecturas síncronas (periódicas).

    
respondido por el Wouter van Ooijen

Lea otras preguntas en las etiquetas