Método para tener largos retrasos de tareas en freertos

Navega tus respuestas
0

Me preguntaba cómo puedo demorar más tiempo usando la función vTaskDelay () de freertos. Debido a que el número más grande que puede almacenar en un entero sin signo de 16 bits es 65535, el más largo que puedo demorar es un poco menos de 2 horas. Actualmente he implementado un método que utiliza un contador. ¿Es este enfoque el mejor o hay otra manera? 

  void vSomeTask(void) {
  static int16_t counter = 0;

  // DO SOMETHING

  //WAIT 24 Hours
  while (counter != 23) {
    vTaskDelay((1000*3600) / portTICK_RATE_MS);
    counter++
  }
    counter = 0;

  //DO SOMETHING ELSE AFTER ONE DAY DELAY


  vTaskDelete(NULL);
}

EDIT: Acabo de darme cuenta de que, debido a que vTaskDelay es relativo, no tiene en cuenta el tiempo que transcurre después de que finaliza el retraso si otras tareas de mayor prioridad siguen ejecutándose. Por lo tanto, un enfoque más refinado sería obtener la hora actual y, en su lugar, utilizar vTaskDelayUntil () porque se basa en el tiempo absoluto.

    
pregunta h3y4w

2 respuestas

3

Lo que ha propuesto funcionará en términos conceptuales y a un costo relativamente bajo, aunque podría implementarse de manera más limpia como un bucle for .

Las funciones de devolución de llamada programadas de FreeRTOS utilizan el mismo argumento TickType_t , por lo que no serán de ayuda para usted.

Sin embargo, vale la pena señalar que el límite de 16 bits que menciona no está realmente arreglado, sino que se puede configurar en FreeRTOSConfig.h

  

Definir configUSE_16_BIT_TICKS como 0 hace que TickType_t se defina (typedef'ed) como un tipo sin signo de 32 bits.

     

El uso de un tipo de 16 bits mejorará en gran medida el rendimiento en arquitecturas de 8 y 16 bits, pero limita el período de tiempo máximo especificable a 65535 "tics". Por lo tanto, asumiendo una frecuencia de marca de 250Hz, el tiempo máximo que una tarea puede demorar o bloquear cuando se usa un contador de 16 bits es de 262 segundos, comparado con 17179869 segundos cuando se usa un contador de 32 bits.

Por lo tanto, especialmente si tiene una MCU de 32 bits, podría considerar usar el tipo más grande.

Sin embargo, es probable que haya muchas, muchas variables de TickType_t almacenadas y utilizadas que no tienen nada que ver con su demora, e incluso en una MCU de 32 bits esto todavía cuesta memoria, y su tarea de demora de conteo solo se activará hasta contar con poca frecuencia, por lo que cambiar el tipo de datos solo para este propósito puede no valer la pena.

    
respondido por el Chris Stratton
1

xTaskCheckForTimeout () se encargará de la sincronización, incluso cuando otras tareas se estén ejecutando en el medio. Sin embargo, esto no debería ser necesario si establece configUSE_16_BIT_TICKS en 0, como ya se mencionó.

    
respondido por el Richard

Lea otras preguntas en las etiquetas

¿Un convertidor de voltaje reducido reduce su potencia máxima? Alimentación de energía a la red eléctrica