[ARM] Problème dans la génération d'interruptions

[invite0bef94e7]

Bonsoir,

Je dois coder un programme capable de lire une fréquence (provenant d'un capteur de fumée), et d'afficher les informations sur un écran LCD (ou port USART). J'utilise deux timers pour provoquer les interruptions. Le timer 1 permet la mesure de la fréquence, le timer 2 permet de mttre à jour l'affichage (toutes les deux secondes environ).

Problème: L'interruption permettant de mettre à jour le menu ne se déclenche que lorsque la fréquence mesurée par l'autre timer est suffisamment élevée En clair, il faut que la fréquence du signal soit supérieure à une fréquence critique pour obtenir un fonctionnement correct toutes les deux secondes (sinon le µc ne rentre pas dans l'interruption).

J'ai essayé d'utiliser d'autres timers, même problème Des idées?
-----

[invite29971eb1]

Sur les ARM7, la gestion des interruptions est une calamité. D'ailleurs les CortexM3, qui les remplacent, disposent d'un bien meilleur gestionnaire d'interruptions.

Je crois que c'est un problème de taille de pile, mais je ne suis pas sur.

A défaut de solution (j'ai abandonné pour ma part), je peux te donner quelques conseils:
- Fais en sorte que tes routines d'interruption soient les plus courtes possibles
- élimine les appels à des fonctions dans ces mêmes routines. Remplace-les par le code correspondant ou éventuellement des macros

Les solutions qui circulent sur le net impliquent de passer en mode privilégié et d'assembleur inline. Je ne maitrisais pas assez les ARM7 pour m'y lancer.

Si ça peut aider, voici 2 docs de NXP sur les interruptions:
http://www.nxp.com/documents/applica...te/AN10381.pdf
http://www.nxp.com/documents/applica...te/AN10414.pdf

Bon courage et tiens-nous au courant, je suis curieux de la conclusion

[invite0bef94e7]

Merci, mais le fait est que, dans les interruptions, je n'appelle aucune fonction
Donc selon toi le problème viendrait d'une pile trop petite (ou compilateur foireux (keil µvision))?
Pour le mode privilégié et l'assembleur, je le sens moyen, je débute la dedans.

[invite29971eb1]

Merci, mais le fait est que, dans les interruptions, je n'appelle aucune fonction
Donc selon toi le problème viendrait d'une pile trop petite (ou compilateur foireux (keil µvision))?
Pour le mode privilégié et l'assembleur, je le sens moyen, je débute la dedans.

Ça n'a rien à voir avec le compilateur, c'est le hardware qui est foireux.

Je crois me souvenir que c'est plus complexe qu'une simple histoire de pile, mais ça fait 1 an que je n'ai pas été confronté à ça....

[A voir en vidéo sur Futura]

[invite0bef94e7]

Sinon est-ce qu'il existe un autre moyen pour déclencher correctement l'interruption? (En écrivant dans un registre par ex)

[invite923be736]

Bonjour,
oui il existe des software interrupt, mais je vois pas comment ça pourrait régler ton problème.
Deux question est ce que tes interruptions son réentrantes ou pas, déclencher sur front ou niveau.

[invite0bef94e7]

En fait je voudrais afficher les informations provenant des capteurs sur un écran.
Sinon les interruptions sont bien réentrantes, et déclenchées sur front montant.

[invite0bef94e7]

Problème résolu.

A mon avis c'était un problème dans le code, surtout pour les écritures dans les registres:
APMC_PCER |= (1<<TC1_ID); alors que ce registre est accessible seulement en écriture. J'ai remplacé par:
APMC_PCER = APMC_PSR | (1<<TC1_ID) ; et ça fonctionne.

Voila

[invite29971eb1]

Quelle idée aussi de lire des registres en écriture seule

Content pour toi que ce soit pas la gestion d'interruptions