Bonjour,
J'ai fais un circuit pour faire l'acqusition de trames RS485 à travers un PIC16F628 et un LTC490.
J'ai fais mon programme en C avec des morceaux trouvé ca et la, il utilise une interruption pour l'acquisistion des données.
J'ai vu que certains faisaient la même chose sans interruption.
Je n'arrive pas à bien comprendre le fonctionnement de celle-ci et est ce la meilleur solution avec l'uart.
J'espere etre clair et vous remercie d'avance
C'est en general difficile de faire un programme a partir de morceaux, des fois même plus difficile que de l'écrire soit même.
Les interruptions permettent d'exécuter un morceau de code a un instant précis correspondant a l'evenement déclencheur.
Cela évite de devoir "surveiller tout le temps" l'uart.
Reste a savoir ce que tu prefere
Merci pour ta réponse
Si je comprends bien il est donc tout à fait possible de faire une boucle infinie pour surveiller l'uart, cela fonctionnera aussi bien qu'une interruption?
Mon prog consiste à écouter l'uart, à modifier les trames et à les renvoyer.
Siu j'utilise une interruption, le programme de transformation de la trame doit se trouver hors de l'interruption?
En fait le but est de pouvoir utiliser le watchdog, je sais que celui-ci doit etre placé en dehors d'une interruption
C'est simple de savoir comment de partager :
- Si ton pic ne fait rien d'autre, si tu es le seul programme sur le pic, alors tu peux travailler en scrutation.
- Si il faut que le pic fasse d'autres choses, préférer l'interruption
Bonjour,
Il faut aussi considérer qu'en mode scrutation, si ton programme est bloqué dans une routine, tu aura un délai avant de voir un changement, tandis que sur une interruption tu es sur d'être prévenu "tout de suite".
En y repensant ça rejoins ce que dit Zhal, si tu as beaucoup d'autres choses à calculer il vaut mieux éviter la scrutation.
Ensuite, si tu as de longs traitements ET beaucoup d'interruptions, il se peut que tu n'arrive jamais à la fin de tes traitements parce que le pic sera toujours interrompu, et à chaque interruption aura ses longs traitements à faire, qui ne termineront jamais...
Il faut donc bien analyser le tout avant de choisir... Et peut-être même faire des tests.
On ne pouvait pas mieux dire
OK merci je vais tester le boucle sans interuption
Merci pour vos réponse
Par contre une dernière interogation, lorsqu'on utilise une interuption, on ne met dans celle-ci que les getc() et les putc() et tous les calculs intermédiaire se mettent dans le corps du programme?
Je dirais que ça dépend de ce que tu as a faire.
Si dans ton programme tu travailles sur un buffer contenant le caractère précédemment lu ; imagine une interruption à ce moment qui va écrire dans ton buffer un nouveau caractère reçu ; tu revient alors dans ton corps de programme et tu continues à travailler sur ton buffer... Dont le contenu a changé!
Il te faut absolument éviter ce genre de cas, soit en faisant le traitement dans la fonction d'interruption, sachant qu'il vaut mieux qu'elle reste la plus petite possible pour éviter les interruptions qui interrompent des interruptions dont je te parlais dans mon précédent message ;
soit tu utilise un buffer circulaire (tu rajoute ton caractère au bout des précédents) : tu ne fais que le mettre a jour dans ton interruption, et dans ton prog principal tu traite tout ce buffer circulaire en supprimant au fur et à mesure les caractères traités.
donc pour répondre à ta question : oui, il vaut mieux mettre le strict minimum dans la routine d'interruption et faire le traitement dans la boucle principale, en gardant à l'esprit qu'à tout moment il peut être interrompu.
En fait j'ai deja fait mon programme avec l'ensemble du traitement dans l'interuption, cela ne posait aucun problème donc je pense que le traitement était suffisement rapide pour ne pas etre interompu.
En fait c'est parce que je me doutais et vous me le confirmez que c'est pas la bonne facon de programmer , de plus je ne peux pas utiliser le watchdog.
Je ne peux pas utiliser de buffer circulant parce que je doit traiter des trains de 7 octets complets avec des valeurs à renvoyer qui dépendent de plusieurs octets.
Bah, après je ne suis pas sûr qu'il y ait de "bonne" façon de programmer, tout au plus des recommandations mais chaque programme est différent, répond à des besoins différents donc il ne faut rien prendre au pied de la lettre mais adapter au cas à traiter.
La bonne façon de programmer c'est celle qui fonctionne sans problème dans les conditions demandées et qui procure suffisamment de satisfaction du travail bien fait
P.S. : Je voudrais ajouter à la bonne façon de programmer : c'est aussi celle que l'on peut relire quelques temps après et comprendre la logique utilisée : la maintenance est importante aussi, il faut y penser en développant (commentaires notamment)
Raaaaa allez .... la prog c'est de la poesie
C'est pas faux... Il y a autant de façon d'écrire un programme qu'il y a de programmeurs ; et dans la logique d'écriture d'un programme on peut retrouver la logique de celui qui l'a écrit
Bonjour,
Je voulais juste rajouter que je viens de voir ça dans le 1er cours de bigonoff qui concerne le 16F84, je cites :
- Une interruption ne peut pas être interrompue par une autre interruption. Les interruptions sont donc invalidées automatiquement lors du saut à l'adresse 0x04 par l'effacement du bit GIE (...)
- Les interruptions sont remises en service automatiquement lors du retour de l'interruption. L'instruction RETFIE agit donc exactement comme l'instruction RETURN, mais elle repositionne en même temps le bit GIE.
1er cours (part1_R31.pdf), page 111
Et, j'aurais tendance à lui faire confiance
C'est peut-être pour ça que tu n'es par interrompu dans ton traitement d'interruption.
Par contre du coup, je me demande si ce mode de fonctionnement peut entrainer des pertes d'interruption? Puisqu'elles n'ont pas pu être traitées car une interruption était déjà en cours, sont elles "perdues à jamais"?
Ce programme sert à piloter une caméra mobile et je n'ai observer aucune perte de mouvement (enfin rien de sensible par l'homme)
En revanche il y a un temps de latence mais qui démarre dès le premier mouvement donc ca ne peut pas venir de trames perdues.
Merci pour toutes vos réponses, j'ai refais le programme avec la partie calcul sortie de l'interruption je vais tester les deux.
