adresse de retour interruption sur PIC

[invite5396f733]

bonjour,

Imaginons que l'autorisation de l'interruption RB0 soit activée.
Lors d'une interruption de programme, le pointeur se connecte à l'adresse 0x004.
Quand le cycle de l'interruption est terminé, le pointeur se reconnecte à l'adresse quittée.
Ma question est la suivante:

- Y a-t'il un moyen de se connecter ailleur qu'à l'adresse du programme
quittée précédement et se débarrasser de l'adresse de retour programme
mémorisée par la PIC?

J'ai essayé de manipuler le registre PCL, mais j'ai remarqué que la mémorisation de l'adresse quittée est toujours active (stack Windows de MPLAB).

Cordialement

Arzew
-----

[invitef26bdcba]

Salut,

La question à se poser est pourquoi tu veux faire ce genre de manipulation...

Car si tu veux modifier l'adresse de retour c'est que ton programme est soit mal "pensé" ou que le problème n'est pas posé "correctement".

Quel est le but réel de cet artifice, qui abandonne la tâche en cours sans s'occuper d'une sortie propre de la routine et va sans aucun doute conduire à des erreurs ?

David.

[invite87be5ae9]

Bonjour,

Pour modifier l'adresse de retour, il faut pouvoir manipuler la pile ! Ce qui est d'office impossible sur la série PIC16 !
La série PIC18 (et au delà, j'imagine...) permet de manipuler la pile, et donc, de changer l'adresse de retour en cas d'interruption.
Il faut te renseigner sur le pointeur de pile (registre STKPTR) et les registres "Top Of Stack" (TOSU, TOSH, TOSL), mais également les instructions PUSH et POP, afin de modifier la pile.

Cependant, ces manipulations sont utiles afin d'implémenter une pile logicielle, par exemple (pour avoir plus de niveaux de pile), mais pas pour directement modifier l'adresse de retour d'une interruption !!!

En effet, le principe d'une interruption est qu'elle peut interrompre un programme à tout moment ! Le déroulement du programme deviendrait alors difficile à prévoir !!!

Je rejoins l'interrogation de DavidDB afin de savoir quel est le but final de cette manipulation ?!

[Seb.26]

Je rejoins l'interrogation de DavidDB afin de savoir quel est le but final de cette manipulation ?!

Ce sont des techniques souvent utilisées pour faire un scheduler ou un noyau multi-taches à temps partagé ...

[A voir en vidéo sur Futura]

[invite_P89]

SALUT Arzew et Co

Je rejoins Seb.26 (bonsoir Seb) c'est une façon de faire du multi-taches.
Mais sur les pics, je ne vois pas très bien le but.
Tu peux le faire, il suffit de ne pas faire le retour INT mais tu risques le débordement de la pile avec d'autres µP c'est possible,mais pas avec 16Fxxx la pile fait 8 niveaux de 13 octets.
Tu peux faire 8 appels a des SPG pas plus ou empiler 8 INT.

a bientôt

[invite87be5ae9]

Merci pour ce renseignement Seb26 et Pom26.
Aussitôt cherché sur le WEB, aussitôt trouvé une application : le système PICOS18.
http://www.picos18.com/Projects/RTOS...OS_PICOS18.htm

A+

[Seb.26]

[...](bonsoir Seb)[...]

Salut !

Et +1 pour le fait que ça doit être fait avec un pile placée dans un BANK, ou alors il faut prevoir un espace de stockage de la pile pour chaque tache ... ce qui peut permetre de sauvegarder d'autres elements de contexte ... ... mais n'oublions pas que l'on est sur PIC ...

[invite_P89]

et que le multi-taches c'est le partage du temps

[invitef26bdcba]

Ce sont des techniques souvent utilisées pour faire un scheduler ou un noyau multi-taches à temps partagé ...

Oui, mais dans ce cas là, on ne manipule pas l'adresse de retour d'INT !
Et, on n'ignore pas purement et simplement la partie du programme qui était en cours avant l'INT...

Donc, je le répète, quel est le but réel de cette artifice, car je reste persuadé que l'on est pas sur la bonne piste...

Si il s'agit de multitâche on travaille sur un timer (pouvant à la rigueur travailler sur le PC du µC; mais ce n'est pas la bonne méthode avec un PIC) et certainement pas en modifiant l'adresse de retour d'INT.

David.

[invite5396f733]

bonjour,

Ce n'était qu'une simple question à mettre dans mes réponses .
J'imaginais ce qui suit :
Nous sommes dans une routine principale, une interruption est prise en compte.
Je veux que cette interruption me connecte à une autre routine car le fait de retourner dans la précédente entraine l'écriture d'une condition pour en sortir afin de brancher le programme sur le routine voulue.

Tout ceci dans le but de rendre plus simple les branchements.
J'ai lu dans les réponses que cela n'était pas possible avec certains PIC.

Arzew

[invitef86a6203]

Et, on n'ignore pas purement et simplement la partie du programme qui était en cours avant l'INT...

Oui ,
et Notamment avec un programme en C qui empile les variables locales et dépile à la sortie.
Le "stack overflow" est inévitable !

Et de plus, de façon aléatoire , au gré des ints.

[Seb.26]

Oui, mais dans ce cas là, on ne manipule pas l'adresse de retour d'INT !
Et, on n'ignore pas purement et simplement la partie du programme qui était en cours avant l'INT...

L'int est un timer qui "desempile" le contexte de la tache precedente, puis "empile" le contexte de la prochaine tache, y compris l'adresse du code où la tache en était ...

Lorsque l'on sort de IT, la tache reprend là où elle en etait ... et n'a rien vu ...

[Seb.26]

bonjour,

Ce n'était qu'une simple question à mettre dans mes réponses .
J'imaginais ce qui suit :
Nous sommes dans une routine principale, une interruption est prise en compte.
Je veux que cette interruption me connecte à une autre routine car le fait de retourner dans la précédente entraine l'écriture d'une condition pour en sortir afin de brancher le programme sur le routine voulue.

Tout ceci dans le but de rendre plus simple les branchements.
J'ai lu dans les réponses que cela n'était pas possible avec certains PIC.

Arzew

Oula ... ton truc semble bien compliqué ... pourquoi le pas simplement positionner un boolean global dans ton IT ?

[invitef26bdcba]

L'int est un timer qui "desempile" le contexte de la tache precedente, puis "empile" le contexte de la prochaine tache, y compris l'adresse du code où la tache en était ...

Lorsque l'on sort de IT, la tache reprend là où elle en etait ... et n'a rien vu ...

L'INT du timer va empiler une place supplémentaire et ne saura pas désempiler l'adresse de retour (de souvenir Arzew travaille sur 16F)...

A partir du 18F, cet artifice est possible mais demande une parfaite maîtrise de ces fonctions car il ne suffit pas simplement de désempiler à l'entrée de l'INT.
En désempilant il faut en même temps sauvegarder l'adresse que l'on est occupé à désempiler afin de faire plus tard le retour au bon endroit...
Mais bon, je ne vois pas réellement l'intérêt de jouer de cette manière avec la pile, pour ma part, manipuler la pile n'est réellement utile que pour augmenter sa capacité si elle est trop juste.

Dans tous les cas, ce n'est pas ce que voulait Arzew, car il veut simplement ignorer l'adresse de retour, et ignorer la tâche qui était en cours me semble très hasardeux sans sauver un minimum du contexte de départ...

Nous sommes dans une routine principale, une interruption est prise en compte.
Je veux que cette interruption me connecte à une autre routine car le fait de retourner dans la précédente entraîne l'écriture d'une condition pour en sortir afin de brancher le programme sur le routine voulue.

Il n'est pas nécessaire de travailler sur la pile pour faire ça...

Dans ton INT tu positionnes simplement un flag, et juste avant la routine d'écriture tu test ce flag et en fonction de ce flag :
- soit tu fais l'écriture
- soit tu branches ton programme sur une autre routine en prenant soins d'effacer ce flag à l'entrée de cette routine.

David.

[invite5396f733]

bonjour,

Je vois ce que tu veux dire DavidDB ... je suis d'accord avec toi pour cette solution ... qui n'est pas la mienne.

Je vais faire plus court :l'apparition de l'interruption nous envoie à l'adresse 0x04.
A la fin de l'étude de l'interruption (retfie) je veux que le programme me connecte à une autre adresse que celle du retour qui a été empilée en oubliant pas de désempiler cette même adresse.

a+

[invite5396f733]

bonjour,

Je vois ce que tu veux dire DavidDB ... je suis d'accord avec toi pour cette solution ... qui n'est pas la mienne car à la fin de ce programme (retfie) je retournerai inexorablement à l'adresse que j'ai quittée lors de l'interruption d'où l'écriture supplémentaire d'une condition (dans le programme de retour) pour se brancher (goto) à l'adresse voulue.

Je vais faire plus court :l'apparition de l'interruption nous envoie à l'adresse 0x04.
A la fin de l'étude de l'interruption (retfie) je veux que le programme me connecte à une autre adresse que celle du retour qui a été empilée en oubliant pas de désempiler cette même adresse.
Mais apparement difficile de manipuler cela !

a+

[invite5396f733]

bonjour,

ne pas tenir compte du message 15 , j'ai voulu le changer mais il s'est enregistré en message 16
je me suis trompé, je recommence mon message

[invitef26bdcba]

Salut,

Je vais faire plus court :l'apparition de l'interruption nous envoie à l'adresse 0x04.
A la fin de l'étude de l'interruption (retfie) je veux que le programme me connecte à une autre adresse que celle du retour qui a été empilée en oubliant pas de désempiler cette même adresse.
Mais apparement difficile de manipuler cela !

Ce n'est pas possible ce que tu veux faire...
Le hardware du PIC16 ne permet pas de manipuler la pile (si tu veux manipuler la pile, il faut passer au PIC18), la seule chose que tu peux faire est de manipuler le PC!

Donc, on n'en revient au même point, tu dois utiliser un flag afin d'ignorer la partie de ton programme et faire ton branchement conditionnel à la sortie de l'INT.

car à la fin de ce programme (retfie) je retournerai inexorablement à l'adresse que j'ai quittée lors de l'interruption

Oui...
C'est le principe même des interruptions, et heureusement que cela fonctionne de cette manière.

Si tu veux absolument manipuler le PC, il faut abandonner la méthode par INT, et travailler par polling sur RB0. De cette manière, la pile ne sera plus corrompue et cela devrait fonctionner, mais, un simple branchement conditionnel suffirait et limiterait sérieusement le risque de bug!

David.

[invite_P89]

LU arzew et CO

Je ne comprends pas très bien ton problème, avant l'INT ton programme faisait quoi ?
Peut-être une solution, avant le ret int, placer un flag sur une RAM puis dans ton Prog Prin faire un test sur ce Flag suivant test un goto

A bientôt

[invite5396f733]

bonjour à vous,

bien compris DavidDB
S'il faut passer par le pic18 ... soit.
Pour l'instant je me débrouille autrement ... à savoir que le saut conditionnel se fera dans le programme principal, au retour de l'INT.
Ce qui implique l'écriture des ses conditions à chaque que j'en ai besoin (lignes de programmation en plus) .

bien compris Pom26
ta solution n'est pas mal. Mais je préfère écrire la condition ds le programme principal (au retour INT).

Cordialement à vous

[invite_P89]

ta solution n'est pas mal. Mais je préfère écrire la condition ds le programme principal (au retour INT).

C'est cela que je te propose LOL

[invite5396f733]

salut

peut-être ... mais pourquoi me parles-tu de RAM ?
Je comprend plutôt "placer une variable témoin dans l'INT" et la tester dans le programme principal (de retour) !
Je vois que chacun à son language ... tous les chemins mènent à Rome.

[invite_P89]

salut

peut-être ... mais pourquoi me parles-tu de RAM ?
Je comprend plutôt "placer une variable témoin dans l'INT" et la tester dans le programme principal (de retour) !
Je vois que chacun à son language ... tous les chemins mènent à Rome.

Placer une variable témoin dans l'INT et cette variable tu vas la chercher ou ?sinon en RAM.Mais tu as raison question de langage

[invite_P89]

LU arzew et CO

Tu peux aussi charger W d'une valeur, puis faire le test sur W comme cela pas besoin de RAM

[invitef26bdcba]

Salut,

LU arzew et CO

Tu peux aussi charger W d'une valeur, puis faire le test sur W comme cela pas besoin de RAM

Cela ne fonctionne pas, car tu ne peux pas savoir où le programme va pointer en sortie de l'interruption, et donc si w est utilisé ailleurs dans le programme il a forte chance de perdre l'info au minimum et risque de bug dans le pire des cas.

Par contre une solution tordue est d'utiliser un bit d'un registre d'un module hardware non utilisé pour faire ce test afin de préserver la RAM utilisateur.

David.