Algorithme 2 boucles principales et interruption

[boy30]

Bonjour, je programme sur un PIC en assembleur.
J'ai une boucle principale qui ne fait rien, seul le code de l'interruption est nécessaire.
Puis j'ai une boucle secondaire qui ne fait rien non plus mais dans laquelle d'autres interruptions sont en œuvres; la sélection et le changement de mode se fait dans l'interruption matérielle (RB0: appui sur un bouton).

Cependant, je ne peux pas utiliser de "Goto mode1 ou mode2" dans l'interruption puisque par définition elle revient d'où elle est venue.

Je suis donc obliger de scruter sans cesse dans quel mode je suis pour rediriger vers la boucle adéquate selon celle choisie lors d'une interruption suite à l'appui sur le bouton. Ce qui enlève tout l'intérêt de l'interruption, et en plus j'aurais besoin de très longue tempo dans une boucle, alors le temps de réaction sera ridicule.

Quelqu'un aurait-il une piste qui pourrait m'inspirer?



-----

[DAUDET78]

A mon humble avis ..... tu as mal démarré l'étude de ton programme !
Tu peux expliquer ce que tu veux faire, les actionneurs, les capteurs , l'organigramme ?

[Gérard]

Un BP par mode.

[jlcms]

Bonjour,

Cela ressemble à un système multitâche dans lequel on exécute deux taches: mode1 et mode2.
Il faut donc un "ordonnanceur" qui sera la tache lancée par la gestion de l’interruption du BP.
Cet ordonnanceur devra stocker les compteurs de programme de la tache mode1 et de la tache mode2, il devra aussi stocker le contexte (le contenu des accumulmateurs et registres), et l'identifiant de la tâche courante (qui décrit si c'est mode1 ou mode2 qui tourne). A chaque entrée dans l'ordonnanceur on va sauver le contexte courant et restituer le contexte suivant et faire un goto sur le compteur de programme.

[A voir en vidéo sur Futura]

[boy30]

Merci, je préfère de loin cette réponse qui réponds à une question d'ordre générale où il n'est nul besoin de savoir ce que font les modes (tâches). De plus je ne le sais même pas encore moi-même!
Donc, cela veut dire qu'il faut un ordonnanceur qui sera exécuté après l'interruption pour rediriger vers la tâche activée mais comme il revient d'où il vient, où dois-je mettre cet ordonnanceur, un petit organigramme je pense serait très intéressant, si possible.

[DAUDET78]

Ce que tu cherches, c'est un moniteur temps réel qui permet de faire exécuter plusieurs taches successivement par une unité centrale.

A mon avis, c'est un marteau pilon qui est inutile dans ton application . Si tu nous disais ce que tu veux faire ?

PS : Ca existe pour un PIC, http://nicot31.fr/noyau-temps-reel.

[jlcms]

Bonjour,

En général l’ordonnanceur est une routine d’interruption (sur pic on dit ISR).
Cette routine d’interruption est, en général, lancée par un timer toutes les xxx secondes, cela peut ressembler à 10ms ou à 1µs, suivant la simplicité de changement de contexte, la stratégie de découpage des tâches, les capacités du processeur qui va hacher le temps.
Dans ton cas ce n'est pas un timer qui demande la commutation de tâche, mais l'appui sur un BP.

[boy30]

Merci pour les infos des noyaux, je vais y venir mais pour l'instant c'est vrai que mon problème ne nécessite pas un tel niveau de complexité. Je vais juste choisir le mode dans l'interruption et faire un goto vers celle qu'il faut en restaurant le contexte comme si il sortait de la routine d'interruption mais sans le "return from interrupt" qui me posait problème, et qui ne sera pas exécuté, son adresse de retour stockée en stack sera écrasée ou non mais ne servira pas puisque remplacée par le goto, je shunte en fait la sortie de l'interruption. Pour ce qui est de l'ordonnanceur, c'est justement dans l'un des deux mode qu'il rentrera en jeu...

[DAUDET78]

Une usine à gaz !
Tu positionnes un flag qui est testé dans ton main

1/ Flag= 1 GOTO 4/ pour exécution prog1
2/ exécution prog0
3/ GOTO 1/
4/ exécution prog1
5/ GOTO 1/

En interruption :
- Interruption bouton 0 -> Flag=0 et return from interrupt
- Interruption bouton 1 -> Flag=1 et return from interrupt

[jlcms]

@ DAUDET78

Cela ne marche pas, on ne sait pas à quel endroit du mode1 ou du mode2 revenir, il faut sauvegarder le contexte.

[DAUDET78]

Cela ne marche pas,

Si ça marche !
Si on est en train d’exécuter le prog1 et qu'on appui sur le bouton 0 , le flag est mis à 0 et après l'interruption, on reviens d'où on est parti .
Quand le prog1 est terminé, il vient testé le flag et donc ensuite c'est le prog0 qui est exécuté .

Pour accélérer le basculement, on peut tester l'état du flag dans diverses phases de prog0 et de prog1 (par exemple, dans des boucles de tempo)

[boy30]

Le contexte n'est pas trop important puisque le shuntage d'un mode à l'autre commencera obligatoirement par son initialisation spécifique mais surtout je ne veux en aucun cas scruter un flag pour savoir si il faut changer de mode, j'ai besoin de l'immédiateté de l'interruption. Il pourrait avoir des tempo de l'ordre de quelques secondes dans le mode 2 par exemple avant d'aller voir le flag qui aurait déjà changé.

[jlcms]

@DAUDET78: Stack overflow

[DAUDET78]

@DAUDET78: Stack overflow

I d'ont agree ! J'ai pisser plus de ligne de code dans ma vie que tu n'en as encore écrite !

mais surtout je ne veux en aucun cas scruter un flag pour savoir si il faut changer de mode,

Et pourquoi?

j'ai besoin de l'immédiateté de l'interruption.

c'est quoi immédiat pour toi? 1µS ? 1mS ? 100mS?

Il pourrait avoir des tempo de l'ordre de quelques secondes dans le mode 2 par exemple avant d'aller voir le flag qui aurait déjà changé.

Tu fais comment ta tempo ?
- par une boucle soft ? tu met le test du flag dans ta boucle
- par un timer que tu viens tester ? tu met le test du flag dans ta boucle de test du timer

[r4ph]

Tu le dis toi même, c'est pas possible par interruption. Donc qu'est ce que tu n'aimes pas dans la proposition de Daudet? Si ton programme est truffé de tempo, c' est pas le test d'un flag qui va le ralentir.... Reste à savoir si c'est une question rétorique ou qui débouche sur une application pratique. Si ça te tentes, tu peux très bien aboutir à une solution avec IRQ. Resette le pic en IRQ avec le WDT, c'est pas si sale, et au début de ton programme, et bien tu teste dans quelle boucle tu veux aller...

[r4ph]

Remarque jamais fait ça, mais en assembleur tu peux même essayer depuis l'Irq de revenir à l'adresse 0, comme le ferait un reset. En tout cas, tu peux essayer...

[jlcms]

I d'ont agree ! J'ai pisser plus de ligne de code dans ma vie que tu n'en as encore écrite

Je ne sais pas, moi j'en suis à environ 467000 lignes.

[DAUDET78]

comme le ferait un reset. En tout cas, tu peux essayer...

Ca ... c'est un stack overflow !

[r4ph]

Je ne sais pas, moi j'en suis à environ 467000 lignes.

C'est tu rendu un concours de quéquette?!

Moi je dis ça, c'est juste pour donner des idées hein... Mais on en apprends, je pensais que le stack overflow arrivait juste quand la stack est pleine, quand on a trop fait de sauts....

Sinon, pensez vous que ça marcherais?

[Gérard]

C'est tu rendu un concours de quéquette?!

Comprends pas tout là, ça doit être l'heure.

Moi je dis ça, c'est juste pour donner des idées hein... Mais on en apprends, je pensais que le stack overflow arrivait juste quand la stack est pleine, quand on a trop fait de sauts....

Sinon, pensez vous que ça marcherais?

Stack overflow arrive quand on a fait un appel de S/P ou d'interruption de trop. Un saut simple (GOTO) ne compte pas.

[r4ph]

Oui ce doit être l'heure. Pour être plus cohérent, j'aurais aussi du mettre la citation de Daudet post #18. Mais oui c'est ce que je voulais dire par saut, pour un appel de fonction ou une interruption, je me suis mal exprimé.

Bon, j'ai crois avoir compris ce qu'il voulais dire, un stack overflow aboutirai à un reset manifestement. Est-ce qu'un GOTO 0 aurais le même effet?

[r4ph]

Finalement il y a plein de solutions pour Boy30, non?

[DAUDET78]

Est-ce qu'un GOTO 0 aurais le même effet?

Je précise : je ne connais rien aux PICs

Mais je sais qu'on peut faire plusieurs types de reset : Hard, WD , instruction reset (?) qui ont des effets différents (sinon de relancer le programme) . Différents? Au sens que l'état hard et soft du µC n'est pas tout à fait identique .

Par contre le GOTO 0 est à proscrire car le pointeur de la pile n'est pas modifié et on va droit au stack overflow

PS : Une autre solution ! Avec ses deux boutons poussoirs, il fait toujours un reset hard du µC et il positionne une bascule RS fait avec deux portes logiques . Quand le µC redémarre, il vient lire l'état de la RS et démarre le programme "0" ou "1" . Chouette non ?

[r4ph]

Très chouette effectivement, mais tu le sais bien, pourquoi faire simple quand on peut faire compliqué !


Quoi qu'il en soit, merci à tous, je me coucherais moins bête. Mais moins con, pas si sur...