Communication PIC et CAN 24bits

[invite3d4f2ff3]

Bonjour,

Je cherche à réaliser la communication entre un PIC18F4525 et un CAN ADS1251 datasheet :http://focus.ti.com/lit/ds/symlink/ads1251.pdf

Tout ce joue sur la durée des fronts t2 et t3 (figure 11 p12). Je souhaite éviter de passer par l'utilisation des interruptions car j'en ai déjà beaucoup sur mon projet. Une fois que j'ai trouvé ces fronts je n'ai plus qu'à balancer une horloge et récupérer les données. Ma question porte donc sur la détection de ces fronts, point de départ pour mon acquisition???? Auriez-vous des idées? Merci
-----

[invite74b5b8f7]

Salut,

Si t´attends un évènement, t´as le choix entre scrutation ou interruption, si tu veux pa utiliser les interruptions, il reste la scrutation mais bon c´est pas terrible pour un truc qui tourne à cette vitesse...

Pourquoi ne veux tu pas utiliser les interruptions?
Que fait d´autre ton programme?
A quelle vitesse tu utilises ton ADS1251, et ton PIC?

[invite3d4f2ff3]

En réalité j'ai déjà codé le fonctionnement avec interruption, ça fait des mois que je suis dessus, il marche mais cela necessite un redémarrage de l'appareil (au 1er démarrage cela ne fonctionne pas). Pour ce projet j'ai 2 CAN de ce type qui sont reliés à mon PIC et je gère donc avec 2 interruptions. Mon appareil plante au 1er démarrage lorsque je fais l'acquisition sur les 2 voies, cela fonctionne lorsque je fais l'acquisition sur une seule voie. Mes interruptions sont bien configurés je soupçonne le compilateur de mal les gérées c'est pourquoi je voudrais tenter une scrutation mais je ne vois pas trop comment m'y prendre en C? cela voudrait dire avec des boucles "while"??

Pour info j'utilise mon CAN à 19200Hz et le PIC à un quartz de 10Mhz

[invite74b5b8f7]

Désolé mais à mon avis ça ne vient pas du compilateur, c´est le PIC qui "gère" les interruptions, le compilateur ne fait que traduire ce que t´as écris en C en ASM...

Sinon, oui, une scrutation se fait avec une boucle "while(!condition);" ou un if(condition) dans une boucle... Mais une scrutation n´est pas une méthode très propre (pas pour l´attente d´une condition exterieure de cette fréquence)!

Perso je n´utilise pas les PICs, mais tu peux surement nous montrer ton programme et on te dira ce qui va pas...

[A voir en vidéo sur Futura]

[invite3d4f2ff3]

Mes interruptions sont bien réglées, j'ai longuement débatu à ce sujet et cela fonctionne parfaitement après un redémarrage du système. Il semble bien que cela vienne du compilateur, en effet j'ai posé la question au fabricant qui m'a répondu qu'il n'avait pas pris cet élément en compte et qu'il faudra attendre la prochaine mise à jour du compilateur, donc en attendant je voudrais trouver une alternative. Je voudrais bien vous envoyé un bou de mon code mais je ne sais pas quoi vous envoyer étant donné qu'il est long et très orienté PIC.
Je cherche juste à avoir un tout petit code me permettant de "scruter" le front comme cité dans mon 1er post. Le souci étant de distinguer le niveau bas de ce front du long niveau bas qui suit...

[invite74b5b8f7]

T´as qu´á faire des compteurs qui s´incrémentent quand ton DOUT est au niveau bas et comparer les temps, de toute facon pour moi faire de la scrutation la dessus c´est du bricolage donc faut bricoler...

[RISC]

Salut,

En réalité j'ai déjà codé le fonctionnement avec interruption, ça fait des mois que je suis dessus, il marche mais cela necessite un redémarrage de l'appareil (au 1er démarrage cela ne fonctionne pas).

C'est la preuve que ton système n'est pas opérationnel...et qu'il reste un problème hard ou soft

Mon appareil plante au 1er démarrage lorsque je fais l'acquisition sur les 2 voies, cela fonctionne lorsque je fais l'acquisition sur une seule voie.

As-tu par exemple vérifié les errata de ton PIC ? Il existe des bugs sur la liaison SPI. Vérifie quelle version de silicium tu as (je crois que tu peux voir cela sur la Programming Specification en utilisant le code que tu vois à la connection de ton ICD2 ou ICD3 dans MPLAB dans la fenêtre Output

Mes interruptions sont bien configurés je soupçonne le compilateur de mal les gérées

Il faut éviter de penser que les compilateurs sont fautifs....C'est rassurant mais à 99,999% ...faux..et de toute façon cela ne résouds pas ton PB sauf si le fabricant confirme le bug que tu as mis en évidence

c'est pourquoi je voudrais tenter une scrutation mais je ne vois pas trop comment m'y prendre en C? cela voudrait dire avec des boucles "while"??

A éviter, cela risque de t'amener de nombreux problèmes temps-réel en plus...

Quel compilateur utilises-tu ? et quelle version ?

a+