Dans le chapitre précédent, nous avons vu que l’instruction
qui permettait l’attente d’une interruption n’était valide qu’en mode SVC
superviseur. Pour voir le clignotement de la Led en mode User j’ai modifié le
projet précédent pour appeler la procédure de gestion de la LED depuis la
procédure test_interruption_timer. Mais en fait dans cette procédure nous
sommes en mode IRQ puisque c’est la routine de gestion de l’exception irq
initié par l’horloge du timer qui l’a appelée.
Donc dans cette routine nous allons nous contenter de gérer
un top qui à chaque interruption va le basculer de 0 en 1 puis de 1 en 0. Et
dans la procédure de gestion de la led, nous allons dans une boucle tester la
valeur de ce top. S’il est égal à zéro, nous éteindrons la led et s’il est égal
à 1 nous l’allumerons. Nous effectuerons ce processus 5 fois. Et comme cette
procédure est appelée par la routine kernel, nous resterons en mode user.
Vous remarquerez que le top led est utilisé dans 2 modules
différents. C’est pourquoi il est déclaré dans le module kernel comme global.
Si vous regardez le plan de chargement (dans map1) vous le verrez apparaitre
alors que les autres données n’y figurent pas.
Nous en profitons pour améliorer la gestion des autres
exceptions en ajoutant un message pour les signaler et nous prenons comme
options par défaut, d’effectuer un reset du Raspberry pour éviter un blocage du
processeur.
Pour tester un cas d’exception, nous ajoutons une commande
test qui effectuera un appel à une routine traitementTest dans laquelle nous
générons volontairement une erreur en dépilant un nombre différent de registres
que nous avons empilés.
Les tests étant concluants, tout le projet est à récupérerici.
Remarque 1 : les autres exceptions n’ont pas été
testées et donc il faudra surveiller les reset intempestifs du Raspberry.
Aucun commentaire:
Enregistrer un commentaire