CMSIS y demoras por debajo de milisegundos

Navega tus respuestas
2

Estamos ejecutando FreeRTOS con CMSIS. ¿Es posible, utilizando CMSIS en el tablero de descubrimiento STM32F3, tener tareas periódicas ejecutándose con períodos de menos de 1 milisegundo de resolución? Queremos ejecutar tareas a 400 Hz, lo que significa que el período debe ser de 2.5 milisegundos. Todas las funciones relacionadas con los retrasos en CMSIS que he encontrado tienen una resolución de milisegundos. ¿Debemos reconsiderar el uso de CMSIS para nuestros propósitos?

EDIT 2: Una pregunta directa ahora, jeje. ¿Podría alguien mostrarme un ejemplo de cómo configurar una tarea para que se ejecute periódicamente con una frecuencia de 400 Hz con FreeRTOS, posiblemente utilizando CMSIS pero no limitado a ello, en la placa de descubrimiento STM32F3?

EDITAR: Voy a tratar de explicar con más detalle. La tarea es un controlador PID que debe ejecutarse lo más rápido posible, pero no más rápido que 432 Hz. Entonces 400 Hz parecía un número redondo. Esto significa que 2 ms es un período demasiado corto. Y la diferencia en la frecuencia de tareas entre 2 ms y, digamos, 4 ms es bastante dramática. Sin embargo, no sé cuánto jitter podemos aceptar. Pero probablemente no debería estar en el rango de milisegundos.

Parece que tenemos que hacer uso de las llamadas nativas de FreeRTOS para programar las tareas.

Estaríamos encantados de cambiar la utilización de la CPU por una mayor precisión en el tiempo, ya que probablemente no usaremos gran parte de los ciclos en actividades que no sean del SO.

    
pregunta mickey

3 respuestas

1

¡Finalmente encontré la solución! Lo que hice fue cambiar la constante 'configTICK_RATE_HZ' en 'FreeRTOSConfig.h' a algo para que 400 Hz pudiera expresarse como un múltiplo entero de la tasa de tics, y luego usé la función 'vTaskDelayUntil'. Es decir. 'configTICK_RATE_HZ 4000' y 'vTaskDelayUntil (& firstWake, 10)'.

¡Asegúrese de establecer 'INCLUDE_vTaskDelayUntil 1' también en el mismo archivo!

Advierten sobre el uso de valores superiores a 1000, pero parece funcionar para nosotros. Sin embargo, las funciones de CMSIS 'osDelay *' ya no se pueden utilizar.

    
respondido por el mickey
2

La granularidad es probablemente una limitación de FreeRTOS, no de CMSIS en sí.

Dado que necesita una tarea cada 2.5 ms, es posible que desee configurar un temporizador para que se active cada 2.5 ms (Interrumpir). Haga lo que tiene que hacer dentro de su interrupción (pero sea breve) y salga lo más rápido posible. Por lo general, hay hardware disponible para tareas específicas, por lo que si nos puede contar algo sobre su tarea, podría haber una mejor solución.

    
respondido por el Tom L.
0

Usted tiene razón al decir que FreeRTOS especifica todos los tiempos en tics (como puede verse por el nombre de los parámetros en funciones como vTaskDelay ( ) , aunque vTaskDelayUntil () se adapta mejor a las tareas periódicas). La macro pdMS_TO_TICKS () se utiliza para convertir milisegundos en tics. Cuando se utiliza FreeRTOS por sí mismo, la limitación es en realidad una de la potencia de procesamiento. El establecimiento de tics de menos de milisegundos es posible y muchas personas lo hacen, pero naturalmente experimentará que un mayor porcentaje de su tiempo de CPU va a las interrupciones de procesamiento.

Si las API de CMSIS no permiten que se especifiquen tiempos sub-milisegundos, entonces no hay nada que le impida llamar a la API nativa también. La restricción de los tiempos para que sean múltiplos de ms parecería ser algo limitante, ya que asume que su marca es un múltiplo exacto de ms.

    
respondido por el Richard

Lea otras preguntas en las etiquetas

Circuito de preprocesamiento analógico (anti-alias / pre-amp) para conducir ADC ¿Es posible programar microcontroladores AVR utilizando el convertidor USB-UART en lugar de USBasp?