Condición de carrera de sueño del microcontrolador

Suele haber algún tipo de soporte de hardware para este caso. Por ejemplo, la instrucción de los AVR seipara habilitar las interrupciones difiere la habilitación hasta que se complete la siguiente instrucción. Con ella se puede hacer:

forever,
   interrupts off;
   if has_flag,
      interrupts on;
      process interrupt;
   else,
      interrupts-on-and-sleep;    # won't be interrupted
   end
end

En este caso, la interrupción que se habría perdido en el ejemplo se retrasaría hasta que el procesador complete su secuencia de suspensión.

En muchos microcontroladores, además de poder habilitar o deshabilitar causas de interrupción particulares (generalmente dentro de un módulo de controlador de interrupción), hay un indicador maestro dentro del núcleo de la CPU que determina si se aceptarán las solicitudes de interrupción. Muchos microcontroladores saldrán del modo de suspensión si una solicitud de interrupción llega al núcleo, ya sea que el núcleo esté dispuesto a aceptarla o no.

En un diseño de este tipo, un enfoque simple para lograr un comportamiento de suspensión confiable es hacer que la verificación del bucle principal borre una bandera y luego verifique si conoce alguna razón por la cual el procesador debería estar activo. Cualquier interrupción que ocurra durante ese tiempo que pueda afectar cualquiera de esas razones debe establecer la bandera. Si el bucle principal no encontró ninguna causa para permanecer despierto, y si la bandera no está configurada, el bucle principal debería deshabilitar las interrupciones y verificar la bandera nuevamente [quizás después de un par de instrucciones NOP si es posible que una interrupción quede pendiente durante una instrucción de inhabilitación-interrupción podría procesarse después de que ya se haya realizado la obtención del operando asociado con la siguiente instrucción]. Si la bandera aún no está configurada, vete a dormir.

En este escenario, una interrupción que ocurra antes de que el bucle principal deshabilite las interrupciones establecerá la bandera antes de la prueba final. Una interrupción que pasa a estar pendiente demasiado tarde para ser atendida antes de la instrucción de suspensión evitará que el procesador entre en suspensión. Ambas situaciones están bien.

Sleep-on-Exit a veces es un buen modelo para usar, pero no todas las aplicaciones realmente "encajan" en él. Por ejemplo, un dispositivo con una pantalla LCD de bajo consumo podría programarse más fácilmente con un código que se parece a:

void select_view_user(int default_user)
{
  int current_user;
  int ch;
  current_user = default_user;
  do
  {
    lcd_printf(0, "User %d");
    lcd_printf(1, ...whatever... );
    get_key();
    if (key_hit(KEY_UP)) {current_user = (current_user + 1) % MAX_USERS};
    if (key_hit(KEY_DOWN)) {current_user = (current_user + MAX_USERS-1) % MAX_USERS};
    if (key_hit(KEY_ENTER)) view_user(current_user);
  } while(!key_hit(KEY_EXIT | KEY_TIMEOUT));
}

Si no se presiona ningún botón y no sucede nada más, no hay razón para que el sistema no deba ir a dormir durante la ejecución del get_keymétodo. Si bien es posible que las teclas activen una interrupción y administren toda la interacción de la interfaz de usuario a través de la máquina de estado, el código como el anterior suele ser la forma más lógica de manejar los flujos de interfaz de usuario altamente modal típicos de los microcontroladores pequeños.

Programe el micro para que se despierte en caso de interrupción.

Los detalles específicos variarán según el micro que esté utilizando.

Luego modifique la rutina main():

int main()
{
    while(1)
    {
        sleep();
        process(); //process the interrupt
    }
}