Systèmes embarqués et firmware

Que convient-il le plus d'éviter dans un gestionnaire d'interruption ?

  1. AÉcrire 1 dans une variable drapeau pour avertir le traitement principal
  2. BEffacer le bit indiquant la cause de l'interruption
  3. CDes traitements longs, comme l'affichage d'une longue chaîne par printf ou une boucle d'attente jusqu'à un événement
Afficher la réponse et l'explication

Réponse : C. Des traitements longs, comme l'affichage d'une longue chaîne par printf ou une boucle d'attente jusqu'à un événement

Pendant qu'un gestionnaire d'interruption s'exécute longuement, les autres interruptions ne sont pas servies et le traitement principal est également arrêté. printf met du temps à terminer l'affichage et peut lui-même utiliser des interruptions ; il est donc particulièrement dangereux. Le gestionnaire se limite au strict minimum, comme recevoir une donnée dans un tampon ou lever un drapeau, et confie les traitements lourds au traitement principal ou à une tâche. Il ne faut pas non plus oublier d'effacer le bit de cause.

S'entraîner sur ce thème Retour au thème

Autres questions sur Systèmes embarqués et firmware

  1. Lorsque le programme ci-dessus est compilé avec optimisation, led_on() peut ne pas être appelée même si l'interruption de temporisateur survient. Quelle combinaison de cause et de remède est correcte ?
  2. Sur un microcontrôleur 8 bits, une interruption de temporisateur incrémente une variable 32 bits ticks, et le traitement principal lit ticks pour calculer le temps écoulé. Quelle est la cause des valeurs parfois très erronées ?
  3. Quelle caractéristique de la communication série par UART est correcte ?
  4. Pour un UART à 115200 bps au format 8 bits de données, sans parité, 1 bit de stop (8N1), quelle valeur est la plus proche du nombre d'octets transmissibles par seconde ?
  5. Un léger écart de débit en bauds entre émetteur et récepteur UART peut produire des caractères corrompus. Pourquoi l'écart admissible est-il limité à quelques % environ ?

Comparatifs sur ce thème