Timer irrégulier lorsque instructions dans while(1) - suite

[invitebf0c0d36]

Pour reprendre suite au lock du topic suivant : http://forums.futura-sciences.com/el...while-1-a.html

Suite à tous vos conseils (je ne met pas les noms, vous avez tous apporté votre pierre à l'édifice ) :

J'ai utilisé le timer2 qui effectivement peut comparer à une valeur définie à l'initialisation. (TMR2/PR2).

J'ai utilisé un quartz d'une valeur de 12.288MHz.

L'interruption ressemble donc désormais à ça :

void InterruptServiceHigh(void) {
	if(PIE1bits.TMR2IE && PIR1bits.TMR2IF) {
		PIR1bits.TMR2IF = 0;
		++counter;
	}
}

(je pourrai même enlever la condition).

Et là (toujours avec le simulateur MPLAB) j'ai parfois un écart mais qui la fois d'après est corrigé !!

Je pense que vous avez trouvé la solution à mon problème.

Vos remarques sont toujours les bienvenues.
-----

[polo974]

message 4, ElMamat donne la cause (pas localisée):

Ca peut etre une instruction qui met plusieurs cycles d horloge a s'effectuer et c est autant de temps de perdu.

message 8, DAUDET a encore des illusions sur le PIC...
mais détecte le pb:

Ou alors, tu recharges ton timer dans la procédure d'interruption ? Mauvaise méthode de programmation ...

Ah, ah, on sait pourquoi ça dérive... (enfin, au moins certains...)

message 15, DAUDET a encore ses illusions...
message 21, DAUDET se rend compte que les timers (pas tous) du pic sont fait pour rouler en free-running.

message 27, simon. indique LE timer à utiliser pour obtenir une période programmée:

C'est vrai pour certains timers. De mémoire souvent le timer2, celui qui sert aussi pour les PWM.

message 34, DAUDET explicite clairement le pb d'un reload manuel:

• si cet aléa se cumule à chaque interruption et que 100 interruptions te donne (100+100*aléas) millisecondes (le cas avec reload)
• si cet aléa ne se cumule pas à chaque interruption et que 100 interruptions te donne (100+aléas) millisecondes (le cas sans reload)

si l'it tombe au milieu d'une instruction de 2 ou 3 cycles, le code de l'it sera retardé d'autant.
on pourrait compenser la chose en lisant le timer pour tenir compte de cette latence au moment de le recharger (mais c'est jouer avec le feu).

message 35, je résume un peu la situation, écarte les fausses pistes, propose des solutions viables (timer avec comparateur ou registre de reload, ou timer en free-runing qu'il est interdit de toucher une fois lancé et logiciel) et dérape un peu en dernière ligne... (oups)

message 39, DAUDET met les points sur les I sur la cause du jitter:

L'overflow du timer arrive bien sur le même Tclk, mais l'interruption est exécutée quand l'instruction en cours est terminé .... donc il y a un jitter

Le jitter vient de la durée de l'instruction en cours d'exécution au moment où le timer déclenche l'interruption.
On peut mesurer ce décalage (et donc le compenser) en lisant le timer au début de l'interruption si on veut vraiment recharger ce timer dans l'interruption.
Si on ne compense pas ce retard, le décalage va se cumuler dans le temps...

[invitef26bdcba]

Salut,

En timer Synchrone, il n'y a pas de jitter...

Une instruction(Tcy) pic18 c'est 4 Tclk, l'IT du Timer synchrone tombe toujours sur le même Tclk, elle est donc toujours sur le même Tclk du Tcy(ou de l'instruction en cours)

Donc, au cas où ce ne serait toujours pas assez clair :
Peut importe l'instruction, le déclenchement de l'IT se fera toujours sur le même Tclk du Tcy en cours!

Dit encore autrement :

- Le positionnement du flag d'IT(ou l'incrémentation du Timer) se fait toujours sur le Tclk3.
- La latence d'entrée en interruption du timer est de 3 TCY de manière à s'affranchir des instructions nécessitant 2 TCY(type call,return,...)
- Donc peut importe l'instruction en cours, l'entrée en interruption à lieu systématiquement au 4ème TCY de la détection d'overflow


Faut arrêter de chercher une cause, là où elle n'existe pas!

Pour vérifier le bon fonctionnement du Timer2, il ne faut garder que le Timer2 et tester cela.
Il est impossible d'avoir le moindre jitter en utilisant un Timer synchrone!

Ouvrez le manuel de référence des pic18, sur l'utilisation des Timers en mode synchrone pour vous rendre compte que ce vous écrivez n'existe pas sur ce mode d'utilisation du Timer.

David.

[invitee05a3fcc]

- Donc peut importe l'instruction en cours, l'entrée en interruption à lieu systématiquement au 4ème TCY de la détection d'overflow

Je ne connais aucun µC ou µP qui puisse commencer d’exécuter la première instruction du programme d'interruption sans avoir terminé l'instruction en cours.

• Il n'y a pas de jitter sur la détection matérielle d'une interruption
• Il y a un jitter sur l’exécution du programme d'interruption

[A voir en vidéo sur Futura]

[invitef26bdcba]

Je ne connais aucun µC ou µP qui puisse commencer d’exécuter la première instruction du programme d'interruption sans avoir terminé l'instruction en cours.

Ben, ce n'est pas ce que j'ai mentionné dans le post précédent, tu ne sembles pas avoir lu correctement!
Ouvre le datasheet de pic18 pour enfin comprendre

[*]Il n'y a pas de jitter sur la détection matérielle d'une interruption

je n'ai jamais dit le contraire...

[*]Il y a un jitter sur l’exécution du programme d'interruption[/LIST]

Non, pas un jitter au sens propre!
Dans le cas de cette IT, il y a un décalage constant(donc parfaitement prévisible) de 5 TCY!

Donc, sans preload, suffit d'ajouter 5 à la valeur calculée pour avoir une reproduction exacte(à la dérive près du quartz) de la même manière que le ferait un Timer à rechargement automatique...

David.

[polo974]

Même si la latence est toujours la même (à vérifier sur instruction à 3 cycles), il reste le problème des bouts de code où les irq sont dévalidées (sémaphores et autres joyeusetés) et là, la désynchro est assurée.

Donc on ne touche pas un timer "bête" dans son irq sans avoir lu le contenu pour compenser.

[invitef26bdcba]

Même si la latence est toujours la même (à vérifier sur instruction à 3 cycles), il reste le problème des bouts de code où les irq sont dévalidées (sémaphores et autres joyeusetés) et là, la désynchro est assurée.

Cà, cela n'a rien avoir avec le Timer, l'unique responsable est le programmeur, à lui de programmer correctement!

Vu que dans ce cas ci, il n'y a qu'une unique interruption haute priorité, rien ne doit pouvoir la désactivée. Si elle est désactivée ailleurs, c'est une erreur grossière de programmation!

Donc on ne touche pas un timer "bête" dans son irq sans avoir lu le contenu pour compenser.

Valable uniquement en cas de non utilisation du prédiviseur Timer...
Si on utilise le prédiviseur, cette méthode ne fonctionne pas, car le prédiviseur n'est pas accessible en lecture, pas plus qu'en écriture...

En cas d'utilisation du prédiviseur, l'unique solution est de connaître précisément le nombre d'instructions pour corriger le Timer(la recharge du timer réinitialise à 0 le prédiviseur)
Sans oublier d'interdire le moindre test conditionnel (qui risquerait d'induire une erreur pour la future IT).

David.

[polo974]

Cà, cela n'a rien avoir avec le Timer, l'unique responsable est le programmeur, à lui de programmer correctement!

L'usage de sémaphore est tout ce qu'il y a de plus correct.

Vu que dans ce cas ci, il n'y a qu'une unique interruption haute priorité, rien ne doit pouvoir la désactivée. Si elle est désactivée ailleurs, c'est une erreur grossière de programmation!

Donc pour toi, bien programmer, c'est se priver de sémaphores...

Valable uniquement en cas de non utilisation du prédiviseur Timer...
Si on utilise le prédiviseur, cette méthode ne fonctionne pas, car le prédiviseur n'est pas accessible en lecture, pas plus qu'en écriture...

Ne pas toucher le timer dans l'it fonctionne toujours.
C'est le fait d'y toucher qui peut poser problème.

En cas d'utilisation du prédiviseur, l'unique solution est de connaître précisément le nombre d'instructions pour corriger le Timer(la recharge du timer réinitialise à 0 le prédiviseur)

Chose impossible dès lors qu'on veut pouvoir dévalider les it, ce qui est tout de même une chose normale pour qui fait un peu de multitâche.

[invitef26bdcba]

Salut,

Même si la latence est toujours la même (à vérifier sur instruction à 3 cycles)

Je ne l'avais pas vu cette remarque...
Cella ne pose pas de problème non plus :
Il y a 3 TCY après le positionnement du flag, donc, si une instruction sur 3 cycles est préchargée au Tclk2(juste avant le positionnement du flag) elle terminera son exécution normalement.

L'usage de sémaphore est tout ce qu'il y a de plus correct

Il est où le rapport avec le Timer utilisé en base de temps précise???

Donc pour toi, bien programmer, c'est se priver de sémaphores...

Même remarque, je ne vois vraiment pas le rapport avec un Timer tournant en tâche de fond.

Ne pas toucher le timer dans l'it fonctionne toujours.
C'est le fait d'y toucher qui peut poser problème.

Ben, y toucher dans l'IT ou non, faut que tu m'expliques la différente...
Dans les deux cas, le timer tourne, le problème est identique. on ne parle pas d'un Timer configuré en single shoot.

Enfin si, il y a une énorme différente:
En dehors de l'IT, il n'est plus possible de garantir la correction du Timer afin de conserver la base de temps. Si la correction prend du retard, on risque tout simplement de louper une IT ou de ne pas pouvoir apporter la correction du fait que la correction ferait tout simplement déborder le Timer sans apporter la bonne correction.

Chose impossible dès lors qu'on veut pouvoir dévalider les it, ce qui est tout de même une chose normale pour qui fait un peu de multitâche.

J'ai vraiment du mal à te suivre...

Pourquoi faudrait-il dévalider l'IT d'un Timer qui sert de base de temps et tourne en fond de tâche ? il se sert de cette IT pour faire une incrémentation.
Justement sur cette configuration du Timer, c'est exactement le contraire qu'il faut faire, s'assurer que rien ne peut interrompre les tâches dédiées à ce Timer.


Pour résumer ce fil, les possibilités qui s'offre à quichedood :

- Utiliser un Timer à rechargement automatique et uniquement incrémenter sa variable dans l'IT (d'ailleurs, il y a toujours un problème, vu que même là il y a toujours une erreur de temps)
- Utiliser un Timer sans préload et additionner sa valeur de chargement à la valeur courante du timer, dans la routine d'IT (à la condition que le prédiviseur soit correctement positionné) solution que tu proposais dans ce fil.
- Dans le cas très précis de la routine qui a été présenté dans le fil d'origine, utiliser un Timer sans préload et ajouter à sa valeur de chargement le nombre d'instructions qui ont été exécutées jusqu'au moment du chargement du timer dans la routine d'IT.

Ces trois solutions, garantissent une base de temps fiable (sauf la dérive du quartz)

David.

[invitebf0c0d36]

Je vous laisse débattre mais je suis tout de même le fil de la discussion (un peu largué des fois tout de même)

Pour info je retiens donc la première solution (cf premier post) à savoir utiliser le timer2 qui lui peut être rechargé automatiquement à une valeur précisée au démarrage du programme.

On a certes parfois un écart mais qui est à chaque fois compensé à l'interruption suivante, on a donc au maximum 400ns ce qui dans mon cas ne me gêne pas du tout.

[inviteeb160de1]

Ben, y toucher dans l'IT ou non, faut que tu m'expliques la différente...
Dans les deux cas, le timer tourne, le problème est identique. on ne parle pas d'un Timer configuré en single shoot.

C'est simple, si le timer n'est à aucun moment touché, on se fiche du sychronisme entre l'overflow et l'execution de l'IT, tant que cet écart de temps est inférieur à la période du timer, sinon on loupe une interruption. Si on doit recharger le timer dans l'IT, on ajoute un délai fixe (temps execution interruption). Si en plus dans le programme on desactive les IT, alors ce délai peut s'allonger, et devient variable !
D'où l'utilisation du Timer2 ou de n'importe quel timer pouvant être associé avec un registre de type Compare. Il n'y a pas proprement dit de reload, mais le timer revient de lui meme à 0 une fois le match avec le registre de Compare effectué, et ainsi de suite.

Sinon, une autre question, relative à tout problème de mesure : comment fais tu pour savoir que ton timer dérive ? Moi je prends mon scope et je vérifie la sortie. Et toi, que fais tu précisemment ? De plus, tu dis que ton timer "derive". Mais de combien ? Detailler ce qui se passe permet de mieux comprendre.

Ta variable "counter", c'est quoi comme type ? Quel traitement effectues-tu sur elle hors IT ? Si jamais tu dois y écrire, tu dois impérativement desactiver les IT le temps d'y toucher pour éviter un conflit avec ta routine d'IT.

Aurélien

[polo974]

Salut,


Je ne l'avais pas vu cette remarque...
Cella ne pose pas de problème non plus :
Il y a 3 TCY après le positionnement du flag, donc, si une instruction sur 3 cycles est préchargée au Tclk2(juste avant le positionnement du flag) elle terminera son exécution normalement.

Détail matériel...

L'usage de sémaphore est tout ce qu'il y a de plus correct

Il est où le rapport avec le Timer utilisé en base de temps précise???
...

Pour maintenir un sémaphore, il faut être protégé des interruptions qui pourraient y toucher (je ne parle même pas des problèmes additionnels en multiprocesseurs), donc il faut en quelques instructions dévalider les it (toutes), modifier le sémaphore, revalider les it (si elles étaient valides au départ).
Là le timer s'en moque (c'est sûr, et ce n'est pas le problème), mais l'it déclenchée peut être décalée de quelques cycles.

C'est le fait d'y toucher qui peut poser problème.

Ben, y toucher dans l'IT ou non, faut que tu m'expliques la différente...
Dans les deux cas, le timer tourne, le problème est identique. on ne parle pas d'un Timer configuré en single shoot.

On parle d'un timer dont on accède à la volée la valeur.
Comme il est impossible de garantir le synchronisme, y toucher pose problème, ne pas y toucher ne pose pas problème. C'est toute la différence.

Enfin si, il y a une énorme différente:
En dehors de l'IT, il n'est plus possible de garantir la correction du Timer afin de conserver la base de temps. Si la correction prend du retard, on risque tout simplement de louper une IT ou de ne pas pouvoir apporter la correction du fait que la correction ferait tout simplement déborder le Timer sans apporter la bonne correction.

Dans l'it non plus, tu ne peux pas garantir la correction (soit pour cause de prescaler, soit pour cause de dévalidation d'it).

...
J'ai vraiment du mal à te suivre...

Pourquoi faudrait-il dévalider l'IT d'un Timer qui sert de base de temps et tourne en fond de tâche ? il se sert de cette IT pour faire une incrémentation.

On ne dévalide pas le timer, il tourne toujours, on dévalide très sporadiquement l'interruption, ce qui entraine un retard max de quelques cycles cpu.

Justement sur cette configuration du Timer, c'est exactement le contraire qu'il faut faire, s'assurer que rien ne peut interrompre les tâches dédiées à ce Timer.

L'appli ici est un chrono à la ms, donc avoir un retard absolu de l'ordre de quelques cycles cpu n'a rien de choquant.

Pour résumer ce fil, les possibilités qui s'offre à quichedood :

- Utiliser un Timer à rechargement automatique et uniquement incrémenter sa variable dans l'IT (d'ailleurs, il y a toujours un problème, vu que même là il y a toujours une erreur de temps)
- Utiliser un Timer sans préload et additionner sa valeur de chargement à la valeur courante du timer, dans la routine d'IT (à la condition que le prédiviseur soit correctement positionné) solution que tu proposais dans ce fil.

Je n'ai pas dit ça... (faire une différence de 2 lectures, sans jamais écrire dans le timer, oui, mais avec des précautions...)

- Dans le cas très précis de la routine qui a été présenté dans le fil d'origine, utiliser un Timer sans préload et ajouter à sa valeur de chargement le nombre d'instructions qui ont été exécutées jusqu'au moment du chargement du timer dans la routine d'IT.

Solution qui interdit de dévalider les interruptions ou d'utiliser le prescaler, donc à éviter (car on fini par oublier ces contraintes et ...).

[invitef26bdcba]

C'est simple, si le timer n'est à aucun moment touché, on se fiche du sychronisme entre l'overflow et l'execution de l'IT, tant que cet écart de temps est inférieur à la période du timer, sinon on loupe une interruption. Si on doit recharger le timer dans l'IT, on ajoute un délai fixe (temps execution interruption). Si en plus dans le programme on desactive les IT, alors ce délai peut s'allonger, et devient variable !
D'où l'utilisation du Timer2 ou de n'importe quel timer pouvant être associé avec un registre de type Compare. Il n'y a pas proprement dit de reload, mais le timer revient de lui meme à 0 une fois le match avec le registre de Compare effectué, et ainsi de suite.

Oui, avec préload, mais sans préload le problème est totalement différent(si tu n'avais pas suivi le post initial, il y était prétendu qu'il était impossible d'avoir une base de temps précise sans utiliser un Timer à préload)...
Le valeur courante du Timer sans préload ne peut être modifiée que dans sa propre IT, ailleurs, c'est inévitablement s'attirer des problèmes

La vrai question à se poser Aurélien, est-ce qu'il t'est déjà arrivé de désactiver une IT pour des raisons qui n'ont rien avoir avec cette IT sachant que cette IT est déterministe pour le programme?
Moi, j'ai beau chercher une raison valable, c'est inconcevable comme méthode de programmation.
Par-contre, si maintenant le temps du Timer ne doit être qu'approximatif, par facilité de programmation, il m'est déjà arrivé de désactiver toutes les IT tout en sachant que cette méthode de programmation n'est pas des plus propre et diminue fortement la facilité de maintenance du programme.

Pour maintenir un sémaphore, il faut être protégé des interruptions qui pourraient y toucher (je ne parle même pas des problèmes additionnels en multiprocesseurs), donc il faut en quelques instructions dévalider les it (toutes), modifier le sémaphore, revalider les it (si elles étaient valides au départ).
Là le timer s'en moque (c'est sûr, et ce n'est pas le problème), mais l'it déclenchée peut être décalée de quelques cycles.

C'est un PIC18 dont on parle, s'il faut commencer à généraliser à tout ce que l'on trouve sur le marché, on n'a pas fini d'en discuter et en plus c'est sortir de mon domaine de compétence!!!

Et puis, qu'est ce que le Timer base de temps à allez toucher à des sémaphores qui ne le concerne pas???
C'est quoi ce genre de programmation où un Timer va modifier des truc qui ne le concerne en rien ???
Dit autrement, la modifications des sémaphores qui n'ont rien avoir avec la base de temps, ne peuvent en aucun cas interdire une IT qui ne les concerne pas.

On parle d'un timer dont on accède à la volée la valeur.
Dans l'it non plus, tu ne peux pas garantir la correction (soit pour cause de prescaler, soit pour cause de dévalidation d'it).

A la volée oui, mais sous sa propre IT, donc à un moment où l'on connait sa valeur courante à quelques instructions près(car systématiquement au même moment de sa propre IT), d'où la possibilité d'une correction sans erreur!!!

On ne dévalide pas le timer, il tourne toujours, on dévalide très sporadiquement l'interruption, ce qui entraine un retard max de quelques cycles cpu.

Désolé, je ne vois pas pourquoi tu dois interdire l'IT d'un timer qui sert de base de temps, qui tourne en fond de tâche et dont on se sert de l'IT pour modifier une variable.
C'est aberrant de vouloir faire cela, c'est garantir une erreur à un moment ou à un autre.

L'appli ici est un chrono à la ms, donc avoir un retard absolu de l'ordre de quelques cycles cpu n'a rien de choquant.

Mais ici on ne parle pas de retard ablolu, mais bien de perdre purement et simplement une IT si le programme qui désactive l'IT dure plus longtemps que le temps d'overflow(tu sais, les contraintes que l'on fini pas oublier à un moment ou à un autre...)

Solution qui interdit de dévalider les interruptions ou d'utiliser le prescaler, donc à éviter

Je te rappelle, que cette solution n'est valable que dans le cas très précis de qui à été présenté dans le fil initial, donc, sans utilisation du prédiviseur et sans jouer à l'apprenti sorcier avec la désactivation de l'IT de ce Timer
Donc, c'est la solution qui permet de faire du rechargement sans conséquences pour la base de temps, vu que tu effectues le chargement à un endroit parfaitement connu du programme...
A nouveau, pourquoi veux-tu absolument désactiver une interruptions qui ne dois jamais être désactivée???

(car on fini par oublier ces contraintes et ...)

Oui, c'est une vision du problème...
Moi, j'en ai une autre, avec ce genre de pratique, j'ai systématiquement un retour quand une personne tente de modifier un de mes programme sans que je le sache!

A te lire, tu me donnes l'impression que dans un programme de gradateur à retard de phase tu te permettrais d'interdire l'IT qui gère ce retard de phase avec les conséquences que cela engendre pour intervenir sur des sémaphores qui ne concerne même pas le retard de phase....

David.

[inviteeb160de1]

Oui, avec préload, mais sans préload le problème est totalement différent(si tu n'avais pas suivi le post initial, il y était prétendu qu'il était impossible d'avoir une base de temps précise sans utiliser un Timer à préload)...
Le valeur courante du Timer sans préload ne peut être modifiée que dans sa propre IT, ailleurs, c'est inévitablement s'attirer des problèmes

Faut être clair ici, ne pas confondre preload et valeur d'overflow. Les micros un tant soit peu bien foutus ont tous un ou des registres de periode qui servent de repere d'overflow. Le timer se reinitialise automatiquement à 0

La vrai question à se poser Aurélien, est-ce qu'il t'est déjà arrivé de désactiver une IT pour des raisons qui n'ont rien avoir avec cette IT sachant que cette IT est déterministe pour le programme?
Moi, j'ai beau chercher une raison valable, c'est inconcevable comme méthode de programmation.
Par-contre, si maintenant le temps du Timer ne doit être qu'approximatif, par facilité de programmation, il m'est déjà arrivé de désactiver toutes les IT tout en sachant que cette méthode de programmation n'est pas des plus propre et diminue fortement la facilité de maintenance du programme.

Il n'y a pas de réponse à ta question. Ou plutot il y en a une très simple : ça dépend. On ne peut pas établir de règle aussi simplement.
Mais un timer en IT peut etre utilisé pour deux choses :
- incrémenter une variable qui sera reprise par le programme principal qui veut se repérér dans le temps
- executer une fonction rapide
Dans le premier cas, le programme principal peut avoir besoin de reinitialiser la variable de comptage (par exemple si on gère plusieurs délais différents à partir d'un meme timer 1ms, ce que je fais couramment). Donc dans le premier cas la réponse est oui, car on veut écrire dans la variable et que l'opération n'est pas atomique, alors il faut couper les IT pour y accéder.
Dans le second cas, tout dépend des autres contraintes du programme (qui peut avoir d'autres choses importantes à gérer) et des variations acceptées par le programme.

C'est un PIC18 dont on parle, s'il faut commencer à généraliser à tout ce que l'on trouve sur le marché, on n'a pas fini d'en discuter et en plus c'est sortir de mon domaine de compétence!!!
Et puis, qu'est ce que le Timer base de temps à allez toucher à des sémaphores qui ne le concerne pas???

Sans partir sur des considérations micropross et sémaphore, si ton IT dans un PIC18 fait incrémenter une variable sur 16 bits, alors il faudra désactiver les IT si tu veux lire ou écrire dans cette variable via le programme principal.

Désolé, je ne vois pas pourquoi tu dois interdire l'IT d'un timer qui sert de base de temps, qui tourne en fond de tâche et dont on se sert de l'IT pour modifier une variable.
C'est aberrant de vouloir faire cela, c'est garantir une erreur à un moment ou à un autre.
Mais ici on ne parle pas de retard ablolu, mais bien de perdre purement et simplement une IT si le programme qui désactive l'IT dure plus longtemps que le temps d'overflow(tu sais, les contraintes que l'on fini pas oublier à un moment ou à un autre...)

Bonne conclusion. On peut faire ce qu'on veut avec les IT desactivées, tant que ça dure moins de la période du timer.

A nouveau, pourquoi veux-tu absolument désactiver une interruptions qui ne dois jamais être désactivée???

Voir explications plus haut.

Aurélien

[polo974]

...
C'est un PIC18 dont on parle, s'il faut commencer à généraliser à tout ce que l'on trouve sur le marché, on n'a pas fini d'en discuter et en plus c'est sortir de mon domaine de compétence!!!

Rien n'interdit de programmer en multitâche sur un pic18, je l'ai fait sur des 4, 8, 16, 32 et 64bits, et quand il faut synchroniser les tâches, on est bien souvent appelé à utiliser les sémaphores.

Et puis, qu'est ce que le Timer base de temps à allez toucher à des sémaphores qui ne le concerne pas???
C'est quoi ce genre de programmation où un Timer va modifier des truc qui ne le concerne en rien ???
Dit autrement, la modifications des sémaphores qui n'ont rien avoir avec la base de temps, ne peuvent en aucun cas interdire une IT qui ne les concerne pas.

Aurélien a bien répondu: ne serait-ce que pour accéder au compteur d'interruptions pour peu qu'il soit sur plus d'octets que ne peut accéder de façon atomique le processeur.

...
Désolé, je ne vois pas pourquoi tu dois interdire l'IT d'un timer qui sert de base de temps, qui tourne en fond de tâche et dont on se sert de l'IT pour modifier une variable.
C'est aberrant de vouloir faire cela, c'est garantir une erreur à un moment ou à un autre.

C'est le contraire qui pose problème...

Mais ici on ne parle pas de retard ablolu, mais bien de perdre purement et simplement une IT si le programme qui désactive l'IT dure plus longtemps que le temps d'overflow(tu sais, les contraintes que l'on fini pas oublier à un moment ou à un autre...)

Comme tu a bien soigneusement éviter de citer les conditions d'opérations sur les IT, les revoici:

... donc il faut en quelques instructions dévalider les it (toutes), modifier le sémaphore, revalider les it (si elles étaient valides au départ).
...
on dévalide très sporadiquement l'interruption, ce qui entraine un retard max de quelques cycles cpu. ...

Donc sauf à retoucher selon une méthode "gros doigts" les quelques lignes de code gérant les sémaphores, il est improbable de perdre une IT (sauf à vouloir une périodicité extrême sous la micro-seconde).

...
Moi, j'en ai une autre, avec ce genre de pratique, j'ai systématiquement un retour quand une personne tente de modifier un de mes programme sans que je le sache!

Faut-il s'en vanter ? ? ?

A te lire, tu me donnes l'impression que dans un programme de gradateur à retard de phase tu te permettrais d'interdire l'IT qui gère ce retard de phase avec les conséquences que cela engendre pour intervenir sur des sémaphores qui ne concerne même pas le retard de phase....
David.

Comme dans ce cas, il est normalement fait usage de timer à rechargement ou comparaison, je n'y aurai aucun scrupule, vu qu'il faut mettre à jour avant le prochain débordement ou matching, les sorties étant pilotées par le timer de façon hard, le soft n'intervenant que pour la prochaine période...

[invitef26bdcba]

Rien n'interdit de programmer en multitâche sur un pic18, je l'ai fait sur des 4, 8, 16, 32 et 64bits, et quand il faut synchroniser les tâches, on est bien souvent appelé à utiliser les sémaphore

heuu... faut-il rappeler le sujet de ce fil...
C'est totalement hors sujet sur le cas présenté dans ce fil!

Aurélien a bien répondu: ne serait-ce que pour accéder au compteur d'interruptions pour peu qu'il soit sur plus d'octets que ne peut accéder de façon atomique le processeur.

He...
Tu réponds à côté de la plaque...

Je te pose une fois de plus la question :
Pourquoi désactiver l'IT d'un périphérique, alors même que tu ne touches en rien à ce périphérique (ou ses fonctions) durant le temps de cette désactivation ?

Aurélien, lui, il répond exactement dans le cas ou la désactivation de cette IT est nécessaire pour modifier des actions ou des opérations qui ont avoir avec ce Timer!

Dit autrement:

Dès qu'une action concerne le fonctionnement d'un périphérique, Il est normal de pouvoir y toucher, y compris à ses IT...

C'est le contraire qui pose problème...

Vu que tu sembles vouloir noyer le poisson, voici une autre méthode imagée de l'aberrance de tes propos :

- une interface PWM de contrôle sinus déterministe qui tourne entièrement sous IT, à Timer non rechageable automatiquement .
- Une interface UART qui communique sporadiquement avec machin chose et qui nécessite sporadiquement la modif de sémaphores.
- Les deux, n'ayant strictement rien avoir l'une avec l'autre.

Toi, tu trouves parfaitement logique, normale et même indispensable de désactiver l'IT de la PWM pour toucher à l'UART et sémaphores!!!!

Je laisse les lecteurs juger de cette approche de programmation.

Comme tu a bien soigneusement éviter de citer les conditions d'opérations sur les IT, les revoici:
Donc sauf à retoucher selon une méthode "gros doigts" les quelques lignes de code gérant les sémaphores, il est improbable de perdre une IT (sauf à vouloir une périodicité extrême sous la micro-seconde).

Heuu..., j'attends toujours une explication valable sur le fait de désactiver une IT, alors que rien ne le justifie!!!

Faut-il s'en vanter ? ? ?

Ben, tu proposes identiquement le même principe en supposant que tu as assez de temps pour faire ton traitement entre deux OF d'un Timer....

Comme dans ce cas, il est normalement fait usage de timer à rechargement ou comparaison, je n'y aurai aucun scrupule, vu qu'il faut mettre à jour avant le prochain débordement ou matching, les sorties étant pilotées par le timer de façon hard, le soft n'intervenant que pour la prochaine période...

M'enfin ce que je retiens de cette phrase, c'est que la solution de compter trois instructions pour la recharge d'un timer est une très mauvaise pratique. Mais interdire des IT pour lesquels on ne touche même pas aux fonctions du périphérique c'est une solution à utiliser sans scrupule!!!

J'aime ce genre de réflexion qui laisse songeur...

David.

[polo974]

Bon, on reprend:
ou bien on code crade, sans se soucier d'éventuelles évolutions ou réutilisation du code, c'est une façon (provisoire) de régner sur les lignes qu'on a pondu...

ou bien on réfléchit, et on prend de bonnes habitudes dès le début, donc on construit un code solide, réutilisable, partageable.

on n'écrit pas une routine de sémaphore pour chaque appli, on en fait une (ou utilise une toute faite) qui dévalide globalement les IT, traite le sémaphore et revalide globalement (si besoin).

Je laisse les lecteurs juger de cette approche de programmation.

Allez, on fait un sondage chez de vrais codeurs...

On peut aussi regarder un peu le source d'un OS temps réel par exemple...

...
Ben, tu proposes identiquement le même principe en supposant que tu as assez de temps pour faire ton traitement entre deux OF d'un Timer....

D'abord, je ne me vante pas que mon code soit irrécupérable, au contraire, je fais tout pour qu'un collègue puisse facilement entrer dedans.

On reprend: un sémaphore se gère en une petite dizaine d'instructions, donc aucun risque de rester coincé trop longtemps en IT dévalidées et de perdre une IT.

... J'aime ce genre de réflexion qui laisse songeur...

Ce n'est pas grave, du moment que le timer pilote directement le port de sortie, le fait que l'it soit traitée avec quelques cycles de retard ne pose pas problème.

[inviteeb160de1]

Heuu..., j'attends toujours une explication valable sur le fait de désactiver une IT, alors que rien ne le justifie!!!

La question est une peu biaisée : effectivement, si rien ne le justifie, aucun réel interet à le faire...
Mais plusieurs cas permettent de couper une IT alors qu'on ne touche pas au périphérique concerné ou à ses conséquences :
- par facilité de programmation, on coupe toutes les IT, donc un seul bit à toucher, pour desactiver toutes les IT
- c'est d'autant plus important si dans le programme il peut arriver qu'on active ou desactive certaines IT de périphériques en fonction de la machine d'état du programme (IT non utilisées en permanence). Si on veut desactiver juste une IT, pas de souci, mais au moment de la reactiver, il faut savoir si le programme a vraiment besoin de l'activer. Ce qui implique de sauvegarder le statut de l'IT avant de la couper, ce qui est plus long.

- dans le cas d'une fonction qui a besoin de timings précis et rapide (pilotage d'IO), on coupe tout et on s'emmerde pas, tant que l'opération est maitrisée (pas de risque d'overflow d'UART, ou autre).

Pour en revenir au sujet, notre quiche n'a pas réapparu, mais il pourrait répondre à mes questions de mon premier message concernant la dérive (comment est fait la mesure, quelle dérive est mesurée, etc.).

Aurélien

[polo974]

Pour en revenir au sujet, notre quiche n'a pas réapparu, mais il pourrait répondre à mes questions de mon premier message concernant la dérive (comment est fait la mesure, quelle dérive est mesurée, etc.).

C'était fait en simulation, il faut voir le premier fil de discussion qui a été fermé pour cause de vague critique de certaines architectures (enfin question vagues, c'était un peu des déferlantes ...).

Comme il le dit lui même, il a trouvé sont bonheur avec le timer 2 qui dispose d'un comparateur.
Pour la variable (je cite):

 short long counter = 0;

c'est un type assez étrange, pas très standard et il manque volatile (t'es toujours là, quichedood ? ? ?):

volatile unsigned long counter;

Mais c'est vrai, que pour le lire, il y a des précautions à prendre:
soit le protéger par dévalidation des IT, lecture, revalidation des IT,
soit répéter la lecture pour avoir 2 fois de suite la même valeur:

unsigned long counter2:
 
do
{
    counter2 = counter;
}while (counter2 != counter);

Puis utiliser counter2.

(idem pour le raz)