[PIC18] interruption sur front montant - retard important

[sdec25]

Bonjour à tous.
J'utilise un PIC18 pour analyser l'injection de ma voiture.
L'injection est reliée à une entrée du PIC avec une résistance de pull-up (1k) et un filtre passe-bas (10k, 3nF).

J'ai joint en PJ un graphique qui montre 3 voies :
La première est l'injection filtrée.
La deuxième l'injection non filtrée.
La 3ème change d'état à chaque interruption sur front changeant.


Première constatation : l'entrée filtrée est retardé d'environ 50µs (normal).
L'interruption sur front descendant a lieu normalement, mais celle sur front montant est en retard d'environ 500µs, je trouve que c'est énorme !

Au début j'ai pensé que le seuil de changement d'état était trop haut (l'entrée sur interruption est un trigger de Schmitt) mais d'après mes calculs au bout de 500µs la tension est d'environ 4,99999 V.

Alors si quelqu'un a une idée ça m'aiderait beaucoup, car je ne trouve rien qui explique ce retard dans la doc du PIC.

Merci

PS : le programme que j'ai utilisé pour ce test est précis à une dizaine de µs et fonctionne sur le simulateur.
-----

[sdec25]

Personne n'a de solution ? Même une toute petite idée ?
Si je n'ai pas donné assez d'infos dites le moi.
Merci.

[invite3c35244f]

Bonjour,

si tu penses que le problème vient du soft, ton programme serais une aide pour nous et surtout pour toi...

[simon.]

Salut,

Comment tu as produit ces graphiques ? Un genre d'analyseur logique ?
Une trace à l'oscillo serait peut-être utile.

[A voir en vidéo sur Futura]

[sdec25]

Bonjour et merci pour vos réponses.

si tu penses que le problème vient du soft, ton programme serais une aide pour nous et surtout pour toi...

PS : le programme que j'ai utilisé pour ce test est précis à une dizaine de µs et fonctionne sur le simulateur.

id est le problème ne vient pas du soft (d'ailleurs le soft est fait uniquement pour ce test).

@ simon : J'ai utilisé l'analyseur logique du PICkit2.
Malheureusement je n'ai pas de vrai oscilloscope, je ne peux donc que déduire la tension.

[simon.]

Tu pourrais peut-etre tester en utilisant en entrée un bête oscillateur qui te donne de beaux signaux carrés avec de jolis fronts, et voir si tu as le même problème, (aussi avec ou sans le filtre). Ça te permettra de faire la part des choses entre programme et electronique.

Ou bien même, tu intercales un 74ls14 entre ton filtre et le pic, ça te permet de mettre une sonde après le trigger de schmitt.

(A defaut de 74ls14 un trigger de schmitt se fait très bien avec une bête porte logique ou un AOP et 2/3 résistances)

[sdec25]

ok je vais tester en mettant l'entrée à 5V sans filtre.
Mais si ce retard vient du filtre je serai bien avancé puisque je ne peux pas faire sans.
Je vous tiens au courant.

[invitef26bdcba]

Salut,

Quel est ton temps de TCY?

Si TCY inférieure à 500µsec et que tu es certain que le retard de ton filtre est de 50µsec, l'interruption se produit au plus tard le TCY suivant la détection ajouté des 50µsec...

Conclusion, c'est un problème soft...

David.

[RISC]

Salut,

Je pense également que le problème vient du soft mais pour pouvoir creuser il nous faudrait :
1/ La vitesse d'horloge que tu utilises (Fosc ou Fcy)
2/ Quel langage tu utilises (C18, assembleur,...)
3/ Utilises-tu une version d'évaluation ou avec une licence ?
4/ et surtout nous faire voir ton PROG ;=)

Je pense que ton problème vient certainement des temps de sauvegardes et de restauration insérés par le compilateur C18 si c'est celui que tu utilises. Il est facile de remédier à cela en demander au compilateur de réduire le nombre de paramètres sauvegardés par défaut.

a+

[sdec25]

Salut à vous 2

Quel est ton temps de TCY?

Si TCY inférieure à 500µsec et que tu es certain que le retard de ton filtre est de 50µsec, l'interruption se produit au plus tard le TCY suivant la détection ajouté des 50µsec...

TCY c'est la période de l'oscillateur ? Je suis à 8 Mhz, donc chaque cycle processeur dure 0,5µs

@RISC :
Vitesse : 8Mhz -> 0,5µs par instruction
langage : C18 student
Le graphique que j'ai posté en premier message était fait dans une boucle qui dure une 10aine de µs (d'où la précision d'une 10aine de µs). Les interruptions étaient désactivées.
Voici mon prog :

#define SORTIE_PICKIT1 LATBbits.LATB7
#define SORTIE_PICKIT2 LATBbits.LATB6


#define _PORT PORTBbits.RB1
#define _TRIS TRISBbits.TRISB1
#define _IF INTCON3bits.INT1IF
#define _IE INTCON3bits.INT1IE
#define _EDG INTCON2bits.INTEDG1


void testFrontMontant(void) {
	TRISBbits.TRISB7 = 0; // sortie PICkit n°4 = CH1
	TRISBbits.TRISB6 = 0; // sortie PICkit n°5 = CH2
	LATBbits.LATB5 = 0;
	TRISBbits.TRISB5 = 0; // sortie RB5 (signal carré) reliée à RB1 via le filtre
	_TRIS = 1; // entrée RB1 = RB5 filtrée
	
	INTCONbits.GIEH = 0;
	_EDG = 1;
	_IE = 1;
	_IF = 0;
	
	
	while(1) {
		long i;
		
		for(i=0; i<1000; ++i) {
			SORTIE_PICKIT1 = _PORT;
			if (_IF) {
				SORTIE_PICKIT2 = _EDG;
				_IF = 0;
				_EDG = !_EDG;
			}
		}
		LATBbits.LATB5 = !LATBbits.LATB5; // signal carré
	}
}

J'ai refait des graphiques : mêmes conditions, un avec filtre, l'autre sans.

[sdec25]

Encore quelques graphiques :
Voie 1 = signal filtré, entrée RB1
Voie 2 = signal filtré, détection de front
Voie 3 = signal carré

J'ai fait varier la résistance : R = 0 à 2k
C = 0.47µF

Je crois qu'on peut définitivement écarter un problème de soft.
Est-ce que quelqu'un connait la cause de ce problème ?

[invitef86a6203]

		for(i=0; i<1000; ++i) {
			SORTIE_PICKIT1 = _PORT;
			if (_IF) {
				SORTIE_PICKIT2 = _EDG;
				_IF = 0;
				_EDG = !_EDG;
; POUR SORTIR DE LA BOUCLE !!!!!!!!!!!!!!!!
                                i = 1001;
			}
		}

[invitef26bdcba]

Faut travailler sous INT pour la détection de front car tu ne maîtrises rien en faisant du polling dans ta boucle while...

De plus c'est quoi cette boucle "i" qui correspond exactement au temps de retard que tu mesures?

Moi, je vois définitivement un problème soft!!!

David.

[sdec25]

@ freepicbasic :
euh je vois pas pourquoi il faudrait sortir de la boucle. Ça changerait la fréquence du signal ce qui n'apporte rien.

@ DavidDB : il y a une interruption lorsque IF = 1.
for(i) c'est pour la fréquence du signal carré.

Moi, je vois définitivement un problème soft!!!

Et moi je vois définitivement que vous ne comprenez pas mon problème.
Ce code est fait UNIQUEMENT pour sortir sur l'oscilloscope les signaux. Vous ne voyez pas qu'il y a un retard entre la voie 3 et la 1 (normal = filtre RC) et entre la 2 et la 1 (pas normal) ?
Je savais que c'était une mauvaise idée de mettre le code...

[sdec25]

Merci quand même de m'aider mais j'ai bien précisé au départ que le problème ne venait pas du code qui est là juste pour afficher les voies sur l'oscillo, je voulais comprendre le retard entre voie 1 et voie 2 (sur les derniers graphiques que j'ai posté).
Donc j'ai pas envie d'arriver à la conclusion que le code est bon au bout de 50 posts...

[invitef26bdcba]

@ DavidDB : il y a une interruption lorsque IF = 1.
for(i) c'est pour la fréquence du signal carré.

ha bon..., elle est où ta routine d'INT dans ce cas???

[sdec25]

ha bon..., elle est où ta routine d'INT dans ce cas???

J'ai désactivé les interruptions, donc pas de routine, je sors l'IF sur l'oscillo.
J'ai aussi testé sur simulateur : ça marche.
Sans filtre sur circuit réel ça marche bien (regarde le premier graphique de mon post de 20h40).
J'ai fait ces tests parce qu'avec interruption j'avais remarqué un retard plus grand que le temps de traitement de l'interruption (que j'ai mesuré au simulateur).

De plus, l'interruption est déclenchée par la mise à 1 du bit IF, pas l'inverse.

Sache aussi que certaines personnes (dont je fais partie) font un minimum de vérifications avant de demander de l'aide sur le forum.

Après, il pourrait toujours y avoir une erreur dans mon code (je ne suis pas parfait), mais cela voudrait dire que je n'ai rien retenu de ma lecture intensive de datasheet du PIC18.
Ma question portait plutôt sur la partie électronique, que je maîtrise moins bien que la partie informatique.
Merci.

[invitef26bdcba]

boucle "i" qui correspond exactement au temps de retard que tu mesures?

David.

Tu avoueras quand même, que la coïncidence est forte avec un retard qui correspond au temps de ta boucle + le traitement...

Je suis certain que si tu diminues de moitié ta boucle, le retard sera deux fois moins grand. C'est quand même étonnant pour un code où l'on peut écarter les erreurs et où l'on incrimine d'emblée le hard...

Je te laisse avec tes convictions, et bonnes recherches dans ton problème hard!


David.

[sdec25]

Tu avoueras quand même, que la coïncidence est forte avec un retard qui correspond au temps de ta boucle + le traitement...

Le retard ne correspond pas au temps de la boucle + traitement.
Il ne correspond à rien.

Temps d'un passage dans la boucle = 18µs
Temps de la boucle = très grand (18000µs)

Dans le graphique essai4, j'ai un retard de + de 300µs. Il ne vaut ni 18µs, ni 18000.
Si j'enlève le condensateur ou je mets la résistance à 0, il n'y a plus ce retard, donc j'ai des raisons d'incriminer le hard.

Si j'étais doué en électronique et pas en programmation je chercherais l'erreur dans le code, mais ce n'est pas le cas.

[sdec25]

si tu diminues de moitié ta boucle, le retard sera deux fois moins grand.

J'ai quand même testé ça, au cas où.
Résultat : aucun changement, toujours le même retard.

Quelqu'un aurait une explication ?

[invitef26bdcba]

Sort cette détection de front de ta boucle de tempo...

On ne teste pas une détection de front dans une tempo, un doué en programmation ne fait pas ce genre d'erreur.

J'ai quand même testé ça, au cas où.
Résultat : aucun changement, toujours le même retard.

Oui, et la marmotte elle emballe le choc....

Dernier point, essai 5 :
520µsec = égale à 1000(500µsec) incrémentations + 18µsec de la boucle

Encore une autre coïncidence????

David.

[RISC]

Salut,

Un autre point :
Quel référence de PIC18 utilises-tu ?

Pourquoi as-tu choisi les broches les plus critiques (RB6 et RB7). Ces broches sont généralement nécessaire au DEBUG et à la programmation -->> A EVITER ABSOLUMENT car il est IMPOSSIBLE de deboguer une application qui utilises les même broches que l'interface ICSP.
Je te recommande de changer immédiatement RB6 et RB7...

a+

[sdec25]

Sort cette détection de front de ta boucle de tempo...

Hum, vu que le but est de "copier" cette valeur sur l'entrée de l'oscillo à la fréquence la plus haute possible, non.

On ne teste pas une détection de front dans une tempo, un doué en programmation ne fait pas ce genre d'erreur.

Dans mon cas c'est nécessaire.

Dernier point, essai 5 :
520µsec = égale à 1000(500µsec) incrémentations + 18µsec de la boucle

Encore une autre coïncidence????

J'ai pas compris.

Je vais tout reprendre :
La boucle dure 18000µs, au bout desquels on change l'état, ce qui génère un signal carré de période 36ms.

Sur ce signal on place un filtre passe-bas RC, dont la sortie filtrée est sur RB1.
Je veux mesurer le retard de changement d'état de ce signal filtré.
Dans la boucle, toutes les 18µs je fais ceci :
Je mets RB1 sur l'oscillo : SORTIE_PICKIT1 = RB1;
J'attends aussi qu'il y ait une détection de front (détection de front = IF à 1) :
SORTIE_PICKIT2 = INTEDG1;
Comme ça, dès qu'il y a une détection de front, je le vois sur l'oscillo.
La durée de la boucle est de 18µs donc le graphique est précis à 18µs.

Je résume :
Sur SORTIE_PICKIT1 (voie 1 de l'oscillo) j'ai le signal filtré.
Sur SORTIE_PICKIT2 (voie 2 de l'oscillo) j'ai le signal filtré dès que le changement de front est détecté.

Mon but étant de mesurer le retard de ce signal filtré, c'est tout ce que je demande au programme.
Et je remarque que le front montant n'est pas encore détecté alors que l'entrée RB1 est déjà à 1.

@ RISC : J'utilise RB6 et RB7 car ce sont les pins reliées au PICKIT (j'utilise l'analyseur logique du PICKIT).

[sdec25]

Au fait j'utilise un PIC18F2685.
Et je n'utilise pas le PICkit comme débogueur, juste l'analyseur logique.

[RISC]

Salut,

Comme te l'a dit David, utilise une interruption pour les détections de fronts...Tu peux par exemple changer à la volée dans l'interruption le sens du front....Dans tous les cas ne sous estime pas les temps de sauvegardes / restauration ajoutés par le compilateur en en-tête et sortie de l'interruption.
Une petite vérification de la fenêtre View > Disassembly Listing te permettra de comprendre le nombre de cycles générés.

a+

[invitef86a6203]

@ freepicbasic :
euh je vois pas pourquoi il faudrait sortir de la boucle. Ça changerait la fréquence du signal ce qui n'apporte rien.

Le signal de sortie se fait qu'après la boucle , il ne peut donc en aucun cas être plus court.

Si l'on fait un test comme ceci;
Le signal devrait être décalé simplement de la constante de temps RC.
Au niveau hard la seule différence est le niveau de seuil de déclenchement du trigger , je n'ai jamais testé, mais ça ne devrait pas dépasser le double du temps.
ça fonctionne à condition toutefois que l'arrivée des signaux soit plus lente que 2 x la tempo RC + le temps de la boucle

D'ailleurs sur les graphiques, je ne vois pas le pulse de commande, il devrait y avoir une monté et une descente...

On devrait avoir des relevés scope comme le dessin ci joint.

J'ai déjà utilisé ce genre de manip , mais évidemment en interruption, pas en pooling, il n'y a aucune raison que ça ne fonctionne pas.

		for(i=0; i<1000; ++i) {
			SORTIE_PICKIT1 = _PORT;
			if (_IF) {
				SORTIE_PICKIT2 = _EDG;
				_IF = 0;
				_EDG = !_EDG;
		               LATBbits.LATB5 = !LATBbits.LATB5; // signal carré
			}
		}

[sdec25]

@ RISC : salut. Relis mes posts (surtout l'avant dernier), je ne veux pas utiliser les interruptions.
De plus, une interruption est déclenchée par le bit IF à 1 et pas l'inverse, donc il suffit d'analyser le bit IF pour voir si une interruption devrait être générée.
J'ai quand même fait une routine avec interruption. Résultat : toujours le même retard (j'ai pris en compte le temps de sauvegardes). Ce qui n'est pas étonnant puisque l'interruption n'est déclenchée que quand le bit IF est à 1. Donc retard sur bit IF => retard sur interruption.

@ freepicbasic

Le signal de sortie se fait qu'après la boucle , il ne peut donc en aucun cas être plus court.

Justement, tu me conseillais de sortir de la boucle plus tôt (ou alors j'ai mal compris).
De toute façon la période de ce signal n'importe pas, il faut juste qu'elle soit assez grande. Si j'avais un seul front montant et plus rien après, les mesures seraient exploitables (mais il y a un délai entre le démarrage du programme et le début de la capture avec l'oscillo, donc il vaut mieux une boucle). Je pourrais très bien enlever la boucle for(i), mettre une tempo au début et un seul front montant, puis un while(1); à la fin.

D'ailleurs sur les graphiques, je ne vois pas le pulse de commande, il devrait y avoir une monté et une descente...

C'est parce que le graphique n'est pas assez long. Ci-joint un graphique sur une plus grand période. On voit qu'il y a un retard uniquement pour les fronts montants. (je rappelle que voies 3 = signal carré, voie 1 = signal carré filtré, voie 2 = signal carré filtré avec détection de front).

Le signal devrait être décalé simplement de la constante de temps RC.
Au niveau hard la seule différence est le niveau de seuil de déclenchement du trigger , je n'ai jamais testé, mais ça ne devrait pas dépasser le double du temps.
ça fonctionne à condition toutefois que l'arrivée des signaux soit plus lente que 2 x la tempo RC + le temps de la boucle

Justement c'est le but de ce topic (malgré les nombreuses remarques sur la qualité de mon code...). Je voulais savoir pourquoi il y a un retard important, si c'était à cause du trigger ou autre chose.

Merci.

[invitef26bdcba]

Allez, une dernière au génie de la programmation qui ne veut toujours pas admettre que sont code est buggé et que le filtre n’est pas en cause :

1 tu inverses ton signal carré
2 tu exécutes ta boucle "for" et juste après la première incrémentation de "i" tu inverses EDG vu que tu viens d'inverser ton signal carré.
Le reste de l'incrémentation de "i" plus rien vu que le signal carré ne change pas d'état...
3 tu inverses signal carré
4 tu exécutes ta boucle "for" et juste après la première incrémentation de "i" tu inverses EDG vu que tu viens d'inverser ton signal carré.
Le reste de l'incrémentation de "i" plus rien vu que le signal carré ne change pas d'état...
5 ...

Tu ne vois pas un problème de taille dans ton code ????

Il est impossible avec cette méthode de codage de travailler sur les deux fronts, et ton programme exécute simplement le changement d'état de "signal carré" avec un retard du temps de la boucle "FOR" suivant l'état du bit EDG!!!

Mais bon, je sais c'est un problème hardware, et le soft est sans erreur...

David.

[sdec25]

Allez, une dernière au génie qui ne veut pas admettre que son raisonnement est buggé.

1 tu inverses ton signal carré
2 tu exécutes ta boucle "for" et juste après la première incrémentation de "i" tu inverses EDG vu que tu viens d'inverser ton signal carré.
Le reste de l'incrémentation de "i" plus rien vu que le signal carré ne change pas d'état...
3 tu inverses signal carré
4 tu exécutes ta boucle "for" et juste après la première incrémentation de "i" tu inverses EDG vu que tu viens d'inverser ton signal carré.
Le reste de l'incrémentation de "i" plus rien vu que le signal carré ne change pas d'état...
5 ...

Petite remarque :
"juste après" : on travaille avec un filtre RC qui retarde le front. C'est d'ailleurs le but de la manip de mesurer ce retard. Hormis ce détails les étapes 1 à 5 sont bonnes, et c'est le programme que j'avais prévu.

avec un retard du temps de la boucle "FOR"

Déjà, si tu avais regardé les graphiques faits à l'oscillo tu aurais vu que le retard n'est pas du temps de la boucle. D'ailleurs, les front pourraient avoir un retard du temps de la boucle (ils seraient inversés), ça ne me dérangerait pas. Ce qui m'intéresse c'est DeltaT entre le front (voie 1) et le front (voie 2).

Mais bon, je me doute que tu compiles de tête, donc tu vois les problèmes du programme sans le tester.

[invitef26bdcba]

Je t'arrête immédiatement, je suis loin d'être un génie, ce n'est pas moi qui aie écrit à plusieurs reprise être un génie de la programmation!!!

Change "Juste après la première incrémentation" par "x incrémentations", cela ne me dérange pas, le problème reste identique…

Ta méthode de programmation induit un retard du fait de la boucle "for" et en plus empêche la détection des fronts!!!
Tu travailles sur changement d'état de RB1, c'est ce que tu dois te mettre dans la tête.
Sans ton filtre, tu es décalé d'une boucle complète "for" et cela te donne l'impression de fonctionner correctement alors que ton programme est buggé.

Maintenant, peut-être que RISC ou Freepicbasic arriveront à te faire comprendre que c'est ton code qui est en cause et non ce filtre...

J'abandonne ce fil, je pense avoir assez tenté de t'ouvrir les yeux!

David.