Pourquoi programmer des interruptions??

[invite7dc03981]

Bonjour à tous,

j'ai une question très simple, quand on est ce que l'on doit programmer une interruption? je sais très bien programmer des interruptions mais pour le moment je ne vois pas l'intêret!


Alors supposons que je programme une interruption sur le PIC16F84A sur la patte RBO/INT.

Lorsque j'appuie sur un bouton poussoir, le programme se branche à l'adresse de la routine d'interruption et execute le code à l'intérieur, le code enquestion est de faire clignoter une led.

Don le programme principal est vide


mais on peut faire exactement la même sans utiliser d'interruption! Alors quelle est le role de l'interruption? a quoi ca sert d'en programmer? faut il toujours le faire ou ca dépend du projet??


merci de m'éclairer
-----

[luc_1049]

Bonjour

Une interruption évite au micro d'être en permanence en scrutation sur une entrée. Cela permet de faire ou du moins de s'approcher du temps réel.
Alors qu'il fait quelquechose en tâche de fond le micro est interrompu par un évènement qui est de haute priorité, une interruption.

S'il y en a plusieurs après il faut gérer les priorités c'est faisable quand on a de la pratique.
cdlt

[invitee05a3fcc]

Lorsque j'appuie sur un bouton poussoir, le programme se branche à l'adresse de la routine d'interruption et execute le code à l'intérieur, le code enquestion est de faire clignoter une led.

Et si tu ne travailles pas en interruption ? comment tu fais ?

Tu fais un pooling (scrutation) sur l'état de ton bouton ...... Donc le temps de ton µC est entièrement utilisé pour cette tâche idiote et ne peux plus rien faire d'autre ! Ou alors tu fais une scrutation plus lente et tu viens regarder l'état du bouton toutes les secondes (le temps de faire autre chose)..... et tu rates l'état du bouton .....

Moralité :
Le travail en interruption permet de faire autre chose que de scruter. Mais le programme en interruption doit être le plus court possible. Je trouve un bouton "ON", je positionne un flag et je lis ce flag dans le main quand j'ai le temps

[invite7dc03981]

Pouvez me donner un exemple en pratique ou l'utilisation d'une interruption serait la bienvenue?


Merci de vos reponses

[A voir en vidéo sur Futura]

[invitee05a3fcc]

Voir ma réponse #3 !

[invite7dc03981]

quand vous dites que l'interruption doit le plus court possible, que se passe t il si cette condition n'est pas respectée et que le programme d'interruption dure un bon moment?

[invitee05a3fcc]

Si dans un programme d'interruption tu fais le calcul d'une FFT ...... ça bloque le "main" pendant un certain temps et il ne pourra pas gérer ses sorties comme il faut. On risque aussi de rater des interruptions moins prioritaires (je ne sais pas comment est gérer la hiérarchie des interruptions sur un PIC)

[invite7dc03981]

d'accord, je commence a voir un peu le principe, il faut que je pratique pour que ca rentre bien
merci bien

[invite3a1051d7]

pour te faire la main et voir l’intérêt
tu programmes un clignotement de led (10 seconde allum ée 10 secondes eteinte ) avec des tempos et dans ce programme
par interruption tu interromps le clignotement en temps réel sans attendre la fin des 10 secondes par exemple par un bouton poussoir par exemple
cordialement
Alain

[invite7dc03981]

En gros sans interruption, impossible de faire autre chose pendant que le programme tourne

Avec les interruptions, on peut a tout moment executer la portion de code urgente en mettant en pause le programme principal, ca evite de monopoliser le main si j'ai bien compris je vais aller m'exercer

[invite3a1051d7]

les mains dans le cambouis c'est comme ça que l'on progresse !!

[invitee5da1686]

comme l'explique bigonoff dans son exellent cours sur les pic

extrait de son cour :

12.1 Qu’est-ce qu’une interruption ?
Imaginez une conversation normale :
- Chaque interlocuteur prend la parole quand vient son tour de parler.
- Survient alors un événement extérieur dont le traitement est urgent. Par exemple, un
piano tombe du 3
ème
étage de l’immeuble au pied duquel vous discutez.
- Vous imaginez bien que votre interlocuteur neva pas attendre la fin de votre phrase pour
vous signaler le danger. Il va donc vous INTERROMPRE durant le cours normal de votre
conversation., afin de pouvoir TRAITER IMMEDIATEMENT l’EVENEMENT extérieur.
Les interlocuteurs reprendront leur conversation où elle en était arrivée, sitôt le danger
écarté (s’ils ont évité le piano, bien sûr).
Et bien, pour les programmes, c’est exactement le même principe :
- Votre programme se déroule normalement.
- Survient un événement spécifique.
- Le programme principal est interrompu (donc, subit une INTERRUPTION), et va traiter
l’événement, avant de reprendre le programme principal à l’endroit où il avait été
interrompu.

[invite936c567e]

Bonjour

En gros sans interruption, impossible de faire autre chose pendant que le programme tourne

« Impossible » n'est pas exact.

Il est toujours possible de faire du polling dans le programme principal, en y insérant à intervalle régulier un test vérifiant les conditions de lancement de la routine.


L'intérêt d'utiliser une interruption est de pouvoir coder le reste du programme sans (trop) se soucier du sort de cette routine, et d'alléger grandement la taille et la rapidité du code.

En revanche il n'est pas toujours possible d'y avoir recours.

En effet, pour que l'interruption survienne, encore faut-il qu'un circuit la provoque (je laisse de côte la question des interruptions logicielles, qui ne sont rien d'autre que des appels simplifiés à des sous-routines). Or, toutes les conditions d'interruption qu'on pourrait souhaiter ne sont pas forcément disponibles sur les matériels, et on est souvent obligé de recourir à un traitement logiciel pour déterminer à quel moment lancer effectivement la routine, à partir d'une autre interruption (timer par exemple) ou par polling dans le programme principal (moniteur),.

Par ailleurs, le traitement d'une interruption matérielle suggère des ressources (mémoire de sauvegarde du contexte) et des temps d'exécution supplémentaires (avant, pendant et après la routine), voire l'attente d'un état compatible du matériel (la plupart des interruptions peuvent être masquées afin d'éviter de scinder certains traitements qui requièrent d'être menés impérativement d'une seule traite).

Le fait d'utiliser une interruption rajoute donc des contraintes auxquelles on n'est pas forcément en mesure de toujours répondre, en particulier sur les systèmes temps-réel déjà fortement chargés.

[invitee05a3fcc]

En revanche il n'est pas toujours possible d'y avoir recours.........

Là, tu envisages des cas extrêmes qui vont enduire le lecteur avec de l'erreur !

[invite936c567e]

Là, tu envisages des cas extrêmes qui vont enduire le lecteur avec de l'erreur !

Pas si extrême que ça, d'après ce que je peux constater.

On vient régulièrement m'embêter à cause de programmes qui n'arrivent pas tourner correctement sur des petits modèles de PIC ou d'AVR, justement à cause des interruptions qu'on pense à tort pouvoir utiliser sans restriction. Ça paraît tellement simple à mettre en œuvre, et les réelles difficultés ne sont pas apparentes.

Dans les situations (nombreuses) où le timing est important et où on s'approche dangereusement de la limite de capacité du matériel en terme de mémoire et de cycles machine, faire tomber des interruptions un peu n'importe peut s'avérer catastrophique pour les traitements interrompus, et même parfois pour les interruptions successives qui ne peuvent pas toujours être traitées à temps.

Ces petits µC sont assez simples pour être aisément exploités à fond. Mais la perte de contrôle de la chronologie des programmes, ralentis et saccadés par les interruptions, induit souvent des comportements indésirables, qu'on ne pourrait régler qu'en prenant une puce plus rapide... à moins de changer totalement la donne en reprenant le contrôle de la chronologie (traitements imbriqués, polling, etc.).


Le dernier exemple en date que j'ai eu à traiter concernait un déclenchement sur front montant, traité (à tort) par interruption, sur un système qui disposait par ailleurs d'une acquisition de capteurs à fréquence imposée, via des liaisons SPI à haute vitesse (une matérielle et deux logicielles). Environ une fois sur dix, l'interruption tombait au mauvais moment. Non masquée, elle provoquait une perte de points de mesure qui faussait les calculs effectués par la suite. Et mise en attente, elle présentait un temps de réaction trop long pour l'application, ou bien elle se terminait trop tard et gênait les autres traitements. Le problème a été réglé en réécrivant le programme sans l'interruption, ce qui prouve que la puissance du µC choisi était à la base très suffisante pour effectuer le travail demandé.

[invitee05a3fcc]

faut pas faire de la parano .....

[invite936c567e]

faut pas faire de la parano .....

Bah, là ce n'est pas de la parano, puisque sur les plus petits µC qu'on utilise pour des questions de prix de revient, ce cas de figure revient assez souvent dans mes projets et dans ceux de mon entourage. Maintenant, je me garderai de généraliser.

C'était juste pour illustrer le fait que, contrairement à une idée répandue et à ce que newtech1 concluait, le polling permet quand même à faire plusieurs choses en même temps, et le recours à l'interruption n'est pas « toujours » possible.

[invite66c1ab93]

Bonsoir à tous,

Je pense que chacun à sa façon de programmer !

Pour un simple bouton poussoir, je ne pense pas qu'il soit utile d'utiliser une interruption.

Dans ton cas, pour l'instant tu t'amuses à faire clignoter une LED, donc ton PIC ne fait pas grand chose, tu peux faire comme tu veux.
Tu as bien raison de faire des tests pour bien comprendre comment tout cela fonctionne.

Par contre, quand tu auras des programmes assez chargés, il faut veiller à utiliser les capacités du PIC intelligemment.
Il faut donner des priorités aux interruptions et comme cela a été dit plus haut, il faut sortir au plus vite de l'interruption et gérer l'évènement dans le main.

Mickael

[stefjm]

Bonjour à tous,
j'ai une question très simple, quand on est ce que l'on doit programmer une interruption? je sais très bien programmer des interruptions mais pour le moment je ne vois pas l'intêret!

Alors supposons que je programme une interruption sur le PIC16F84A sur la patte RBO/INT.
Lorsque j'appuie sur un bouton poussoir, le programme se branche à l'adresse de la routine d'interruption et execute le code à l'intérieur, le code enquestion est de faire clignoter une led.
Don le programme principal est vide
mais on peut faire exactement la même sans utiliser d'interruption! Alors quelle est le role de l'interruption? a quoi ca sert d'en programmer? faut il toujours le faire ou ca dépend du projet??
merci de m'éclairer

C'est toute la différence entre une programmation par événements (interruptions, événementielles) ou une programmation par activité (séquentielle).
http://fr.wikipedia.org/wiki/Program...%A9nementielle
http://fr.wikipedia.org/wiki/Program...3%A9quentielle

Bonjour
Une interruption évite au micro d'être en permanence en scrutation sur une entrée. Cela permet de faire ou du moins de s'approcher du temps réel.

On peut faire du temps réel à 10 secondes.
Temps réel sans préciser de time out (chien de garde) n'a pas de sens.

Utiliser une interruption permet à défaut de temps réel, de ne pas louper d'informations, qu'on traite ensuite. (comme déjà signalé par Daudet.)

Je pense que chacun à sa façon de programmer !

La bonne ou la mauvaise?

Pour un simple bouton poussoir, je ne pense pas qu'il soit utile d'utiliser une interruption.

Dans ton cas, pour l'instant tu t'amuses à faire clignoter une LED, donc ton PIC ne fait pas grand chose, tu peux faire comme tu veux.
Tu as bien raison de faire des tests pour bien comprendre comment tout cela fonctionne.

Ben, c'est aussi pédagogique : Il faut bien commencer simple!

Pour illustrer l'intérêt d'une interruption :
On veux générer un signal carré de 10 kilohertz à 1% près et ce quelque soit l’exécution du programme.

Si on n'utilise pas une IT matérielle sur un timer, cela va être très hasardeux à faire...

Cordialement.

[invite936c567e]

Pour illustrer l'intérêt d'une interruption :
On veux générer un signal carré de 10 kilohertz à 1% près et ce quelque soit l’exécution du programme.

Si on n'utilise pas une IT matérielle sur un timer, cela va être très hasardeux à faire...

Non, pas « hasardeux », mais seulement « très compliqué » (cela dit, il existe des outils pour contourner cette difficulté).

Ce qui est réellement hasardeux en revanche, c'est le résultat obtenu si le programme contient des zones d'exécution masquant les interruptions, ou bien s'il autorise simultanément d'autres interruptions. La fréquence obtenue par ce moyen ne sera plus contrôlées avec précision, et si les périodes bloquées sont trop longues, on risque de sortir des tolérances fixées.

Une fréquence de 10 kHz à 1%, ça ne laisse que 1 µs d'erreur. C'est difficilement tenable sur un petit PIC à 20 MHz, pour lequel cette durée ne représente que 5 cycles machine, soit :
- le temps d'exécuter seulement 4 cycles machine en zone d'interruption masquée,
- juste le temps de prendre en compte une interruption (latence) et d'exécuter la première instruction de sa routine.
Dans ce cas, il est impératif que la génération du 10 kHz soit la seule interruption traitée et la seule tâche urgente et indépendante à réaliser par le µC. Ça limite grandement les applications.

[stefjm]

Oui, j'ai utilisé "hasardeux" dans le sens "tombé en marche" de Daudet.
(et dans le cadre de débutants qui disposent de matériels raisonnables pour les performances demandées.)

[invite936c567e]

Oui, j'ai utilisé "hasardeux" dans le sens "tombé en marche" de Daudet.

Mais c'est justement ce point de vue que je réfute.

L'absence d'interruption permet justement de garantir que ce qui est exécuté correspond précisément à ce qui est codé, de façon parfaitement reproductible.

C'est au contraire l'utilisation des interruptions qui introduit des aléas, si l'on n'étudie pas de près toutes les éventualités liées à la chronologie du programme. Pour le coup, comme elles peuvent tomber à n'importe quel moment avec des conséquences pas toujours clairement établies, c'est là qu'on risque de « tomber en marche » si l'on doit répondre à des contraintes temporelles incompatibles ou trop restrictives.

Et si de plus grandes performances du matériel permettent d'améliorer les choses, généralement elles ne peuvent pas toutes les régler, sauf à sur-dimensionner le système bien au-delà du raisonnable (aujourd'hui, même des PC à 2 GHz en marche normale ne sont pas en mesure de respecter des contraintes temporelles que de petits µC à 4 MHz sans interruption arrivent parfaitement à tenir).

[stefjm]

Je comprends le point, mais il n'est pas facile pour un débutant. (déjà signalé par Daudet)

Pour les PC, depuis windows, je n'ai pas vu d'amélioration significatives des performances temporelles.

[invitee05a3fcc]

aujourd'hui, même des PC à 2 GHz en marche normale ne sont pas en mesure de respecter des contraintes temporelles que de petits µC à 4 MHz sans interruption arrivent parfaitement à tenir).

Mais ça c'est à cause de la lourdeur des OS et de leurs gigantismes démesurés! Rien que pour changer l'état d'un bit en sortie , il faut passer par une DLL !
Met un DOS 6.22 dessus et ça marche nickel !

[invite936c567e]

Met un DOS 6.22 dessus et ça marche nickel !

Non, pas nickel non plus. J'ai justement conçu des appareils sur base PC avec le bon vieux MS-DOS 6.22, et même si les résultat sont bien meilleurs qu'avec un Windows, il n'en reste pas moins qu'on ne peut pas non plus prévoir avec grande précision la chronologie de la machine. Même dans ce cas, les durées trop critiques doivent être contrôlées par des circuits supplémentaires.

[invitee05a3fcc]

les durées trop critiques ....

C'est quoi l'échelle de temps? µS ? mS ?
Tu fais de la parano (peut être justifiée dans tes applications professionnelles) mais qui ne concerne pas l'utilisation classique d'un µC dans 99,9% des cas . Et en défendant cette approche, tu embrouilles le Vulgum Pecus

[invite936c567e]

L'échelle, c'est la microseconde.

Et si tu parles de 99,9%, c'est parce que tu comptes là-dedans tous les cas qui ne sont pas du temps réel, ou alors sur des durées assez longues.

Moi je parle du problème des interruptions pour des durées critiques correspondant au temps d'exécution d'une routine d'interruption ou d'une fonction ne supportant d'être interrompue, ce qui peut représenter un temps non négligeable sur des petits µC, parfois de l'ordre de la milliseconde.

J'en parle parce que c'est simplement un problème à prendre en compte. Et parce qu'on vient souvent me solliciter quand des programmes mal foutus ne fonctionnent pas, juste à cause de ça. Je pense donc que ça concerne le vulgum pecus.

[invitee05a3fcc]

L'échelle, c'est la microseconde.

Donc pas le cas du Vulgum Pecus .....

ou d'une fonction ne supportant d'être interrompue, ce qui peut représenter un temps non négligeable sur des petits µC, parfois de l'ordre de la milliseconde.

Evidemment, si on fait une division en flottant sur un µC 8 bits dans un programme en interruption ...... et c'est vite fait (de l'écrire !) avec un compilateur !