Temporizador del sistema de alta resolución en STM32

Acabo de encontrar la respuesta de 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:

  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 más agradable que el mío, sin embargo, la causa real de los problemas fue la anterior.

Pensé que agregaría otra posible mejora a getSystemTime que también probé:

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

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

Como has descubierto, el manejo del desbordamiento de contador con un controlador de interrupción es complicado y propenso a la carrera. Incluso con su aumento de prioridad, obtendrá la respuesta incorrecta si las interrupciones se desactivan mientras lee el contador. Hay una técnica mucho más simple que funciona si no estás leyendo el reloj desde el contexto de interrupción (ten en cuenta que estoy usando Contador de ciclos DWT aquí, que está integrado en el procesador de manera rápida 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;
}

Su código tiene dos problemas:

• No sabes si la interrupción que aumentó el SysTickMajor ocurrió 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. Por lo tanto, el valor de SysTickMajor podría actualizarse mediante la interrupción entre la lectura de las dos palabras de 32 bits.

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 SysTickMajor cambió durante el primer bloque de asignaciones, no volverá a cambiar en el segundo bloque. (Esta suposición podría ser errónea si este código se interrumpe durante esta rutina y no se puede ejecutar durante mucho tiempo).

Vea también esta pregunta en Stackoverflow .