Temporizador de sistema de alta resolución en STM32

Como ha descubierto, manejar el desbordamiento del contador con un controlador de interrupciones es complicado y propenso a la carrera. Incluso con su aumento de prioridad, obtendrá la respuesta incorrecta si las interrupciones están deshabilitadas mientras lee el contador. Hay una técnica mucho más simple que funciona si no está leyendo el reloj desde el contexto de interrupción (tenga en cuenta que aquí estoy usando el contador de ciclos DWT , que está integrado en el procesador, por lo que es rápido y simple):

uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
// Do not call from interrupt context!
uint64_t GetCycleCount64() {
  last_cycle_count_64 += DWT->CYCCNT - (uint32_t)(last_cycle_count_64);
  return last_cycle_count_64;
}

Si necesita llamarlo desde un contexto de interrupción (o con un sistema operativo preventivo):

volatile uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
uint64_t GetCycleCount64() {
  uint32_t primask;
  asm volatile ("mrs %0, PRIMASK" : "=r"(primask));
  asm volatile ("cpsid i");  // Disable interrupts.
  int64_t r = last_cycle_count_64;
  r += DWT->CYCCNT - (uint32_t)(r);
  last_cycle_count_64 = r;
  asm volatile ("msr PRIMASK, %0" : : "r"(primask));  // Restore interrupts.
  return r;
}

Es posible que primero deba habilitar el contador de ciclos:

DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;  // Set bit 0.

Su código tiene dos problemas:

• No sabe si la interrupción que aumentó SysTickMajorocurrió antes o después de leer el valor del temporizador en time.

• Las operaciones en valores de 64 bits no son atómicas en un sistema de 32 bits. Entonces, el valor de SysTickMajorpodría actualizarse por la interrupción entre la lectura de las dos palabras de 32 bits.

Yo lo haría de la siguiente manera:

major0 = SysTickMajor;
minor1 = SysTick->VAL;
major1 = SysTickMajor;

minor2 = SysTick->VAL;
major2 = SysTickMajor;

if ( major0 == major1 )
{
    time = major1 + minor1;
}
else
{
    time = major2 + minor2;
}

Aquí se supone que si SysTickMajorse cambia durante el primer bloque de tareas, no volverá a cambiar en el segundo bloque. (Esta suposición podría ser incorrecta si este código se interrumpe durante esta rutina y no se puede ejecutar durante mucho tiempo).

Consulte también esta pregunta sobre Stackoverflow .

Acabo de encontrar la respuesta en un póster muy útil en el foro STM32:

Lo siguiente no es correcto. SysTick es un 'Controlador del sistema' y, como tal, la prioridad no se establece de esta manera en absoluto:

  NVIC_InitStructure.NVIC_IRQChannel = SysTick_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; // Highest priority
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);

En realidad está configurado con:

  NVIC_SetPriority(SysTick_IRQn, 0);

¡Llamar a ese código resuelve el problema!

Entonces, mi versión de getSystemTime podría haber tenido un problema, y ​​el método de starblue es mejor que el mío; sin embargo, la causa real de los problemas fue la anterior.

Solo pensé en agregar otra posible mejora a getSystemTime que también probé:

do {
 major0 = SysTickMajor;
 minor = SysTick->VAL;
 major1 = SysTickMajor;
while (major0 != major1);
return major0 - minor;

Esto anulará efectivamente el problema en el que podría (de alguna manera) terminar con el SysTick implementado dos veces en una sucesión muy rápida.

Las respuestas anteriores son geniales. Esta es la que más me gusta:

do {
 major0 = SysTickMajor;
 minor = SysTick->VAL;
 major1 = SysTickMajor;
while (major0 != major1);
return major0 - minor;

Puede optimizarlo un poco más, ya que sabe que si tiene un rollover de SysTickMajor, no obtendrá otro rollover "en mucho tiempo". Deberías estar seguro haciendo esto:

major = SysTickMajor;
minor = SysTick->VAL;
if (major != SysTickMajor)
    return SysTickMajor - SysTick->Val;
return major - minor;

Lo anterior asume, por supuesto, que SysTickMajor y VAL se declaran como volátiles. Hace varios años, en un trabajo anterior, descubrí que, lamentablemente, lo anterior aún no es perfecto en todos los procesadores. Estaba usando un STM32F407, que tiene un caché y está canalizado. A veces, la búsqueda del segundo SysTickMajor llegaba antes que el VAL aunque se emitieran en orden. Introduzca la barrera de la memoria (instrucción dmb):

major = SysTickMajor;
minor = SysTick->VAL;
__asm__ volatile("dmb");
if (major != SysTickMajor)
    return SysTickMajor - SysTick->Val;
return major - minor;

En mi caso, estaba usando un TIM2 de 32 bits y un ISR de rollover de TIM2 que incrementa los 32 bits superiores de mi contador de ciclos de 64 bits, pero creo que debería actuar igual que lo que está haciendo con SysTick.