Soy nuevo en las prácticas/arquitecturas de codificación de 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 manejan por algún otro medio, como en el ISR fuera de una tarea en particular? ¿Cómo marca sus aplicaciones de 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. por ejemplo, la temperatura puede incluirse en una tarea de cálculo de humedad relativa, puede usarse en una tarea que envía la temperatura al usuario a través del UART y puede usarse en otra tarea que corrige algún otro sensor que tiene una salida dependiente de la temperatura.
Algunos tipos de sensores deben leerse en un horario muy estricto o, de lo contrario, la información recibida de ellos será errónea, ya sea porque la lectura tiene que tener una cierta relación de tiempo con algún otro evento (por ejemplo, uno está midiendo la luz reflejada por una lámpara de iluminación que solo es para 100us cada 10ms), o porque las lecturas encapsulan información de tiempo implícita (por ejemplo, si uno está tratando de muestrear audio a 44100Khz, cada lectura debe encapsular el hecho de que se tomó 22.6757 microsegundos después de la anterior; simplemente tomando 44,100 lecturas en momentos arbitrarios a lo largo de ¡un intervalo de un segundo no es equivalente!). Se pueden leer otros tipos de sensores en el tiempo libre.
Si está tratando con el primer tipo de sensor, debe tener una tarea programada de muy alta prioridad para realizar la lectura, o hacerlo dentro de una interrupción del 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 para 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 manejarse, por ejemplo, con una interrupción de manejo de sensor de 10Khz, usar una interrupción de tasa fija para todo suele ser mucho más simple que tratar de lidiar con tasas de interrupción cambiantes, incluso si a menudo lo único que hará la interrupción será disminuir un "
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 garantizar que nunca haya conflictos de tiempo. Por ejemplo, si, por ejemplo, uno tiene un sensor que debe leerse a una frecuencia estricta de 5 KHz y otro que debe leerse a una frecuencia muy estricta de 2 Khz, y ambos sensores usan el mismo ADC, puede ser más útil tener una frecuencia de 20 Khz. interrumpir y organizar las cosas para que cada interrupción capture la lectura solicitada anteriormente, solicite una nueva lectura, ambas o ninguna, y los dos sensores escalonarán sus lecturas para que nunca necesiten tener solicitudes pendientes simultáneamente. Si los dos sensores fueran manejados por tareas separadas, asegurarse de que ningún sensor quiera usar el ADC cuando el otro sensor lo está usando puede ser más difícil.
La pregunta que haces no puede ser respondida en general. Hay algunos enfoques comunes, cada uno con sus ventajas y desventajas.
Lectura asíncrona bajo demanda. Está 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. Suele ser un buen compromiso, especialmente cuando los usuarios deben procesar el valor, incluso cuando no se cambia.
Lectura síncrona (periódica), los usuarios son notificados cuando es necesario (publicación-suscripción, oyente). Esto se usa a menudo para activar entradas que ocurren solo esporádicamente, como cuando se presiona o suelta una tecla. Buena idea cuando el costo de procesamiento es relativamente alto.
En los dos últimos enfoques, se pueden utilizar interrupciones en lugar de lectura síncrona (periódica).
david tweed
Beto
Beto