Bonjour à tous,
J'essai d'utiliser une dalle tactile resistive 4fils interfacé sur un PIC 24HJ128 GP504 par l'intermédiaire d'un controleur microship AR1020.
Mon problème : Losque j'envoi une commande SPI type "enable touche" au controleur , ce dernier ne m'envoi pas d'accusé de réception.
Avez Vous déjà utilisé ce controleur ?
Merci Beaucoup !
Enfin de compte, l'AR1020 réponds mais avec un niveau de 0 - 0,6V au lieu de 0 - 3,3V ... Auriez-vous une idee
Salut,
As-tu jeté un coup d'oeil sur les fichiers fournis avec le kit d'évaluation qui sont en téléchargement ?
Parfois il y a du code source, un schéma électronique qui permet de démarrer.
Es-tu sur d'avoir bien initialisé ta liaison SPI sur le PIC24H ?
(il y a des exemples d'initialisation pour le SPI ici).
Méfies toi de ne pas être sur une broche de type drain ouvert. Si c'est le cas il faut soit activer la résistance de pull-up interne si elle existe sur cette broche ou en ajouter une externe.
a+
Salut à tous,
je me permets de ressuciter ce topic car j'ai également un problème avec le AR1020. Lorsque je lui envoie un byte via SPI, il me le renvoie, un byte plus tard (au lieu de répondre avec ce que je lui demande)
P.ex : j'envoie 0x55 0x01 0x12 0x00 0x00 (enable touch), il me renvoie 0x00 0x55 0x01 0x12 0x00 au lieu de 0x00 0x55 0x02 0x?? 0x12
Voici le schéma de la partie AR1020 :
j'ai ajouté un condensateur de 10uF en parallèle de C22, CONN11 et CONN12 vont sur le microcontrôleur (un STM32F103)
La datasheet du AR1020 : http://ww1.microchip.com/downloads/e...Doc/41393A.pdf
J'ai mesuré les tensions à l'oscillo, et il à l'air de recevoir et d'envoyer des signaux à 3.3V, et les signaux sont jolis.
Merci pour votre aide..!
Benjamin
Salut,
Daprès la spec, la commande (enable touch) est 0x55 0x01 0x12 (page 24). Pourquoi envoies-tu 0x55 0x01 0x12 0x00 0x00 ?
a+
Peut-être ai-je alors mal compris le SPI mais il me semble qu'il faille envoyer quelque chose pour que l'esclave réponde (pour qu'il y ait un clock). Quelqu'un peut-il confirmer cela..?Envoyé par RISC
Salut,Je pense effectivement que c'est ta compréhension du SPI qui pose le PB.
Il n'y a aucune raison d'ajouter des octets pour que l'esclave réponde...sauf si c'est implicitement marqué dans la doc du controleur AR1020.
Ou as-tu vu qu'il faut faire cela : dans la doc du AR1020 ou dans la doc de ton STM32F103 ?
a+
Salut,
Ce qui est vrai c'est que pour recevoir les données de l'esclave SPI, il faut effectivement que le maitre envoie des données "non perturbantes à l'esclave" en nombre équivalent du nombre d'octets qu'il est sensé recevoir car c'est le même registre qui fait l'envoi et la réception par décalage.
Il faut faire très attention à la programmation des conditions sur les broches SCLK SDI/SDO car cela dépend des chips (polarité positive/négative, déphasage...).
a+
D'après la datasheet du AR1020, la ligne SDI est à 0 lorsqu'il répond, donc j'en déduis qu'il faut envoyer 0x00. (j'avoue ne pas avoir vérifié ça avant, je l'avais juste supposé..)
Je viens de faire un test pour vérifier que c'est bien le AR1020 qui me renvoie la même chose et pas un truc interne au microcontrôleur : en déconnectant SDO, le microcontrôleur ne reçoit plus rien (0x00).
Serait-ce possible que mon AR1020 soit cassé ? Ce serait bizarre car je l'ai déjà changé une fois. Supporte-t-il très mal la chaleur ? je l'ai soudé au fer à souder 330°C et c'est un boitier SOIC.
Normalement j'ai fait attention au paramétrage du SPI, j'ai aussi essayé toutes les combinaisons de phase / polarité, et j'ai des valeurs non-aléatoires seulement dans un cas, qui semble correspondre à la datasheet du AR1020.
Je n'obtiens pas de différence en envoyant le LSB en premier ou en dernier, ce qui me fait penser que le AR1020 agit en simple registre à décalage.
Salut,
J'ai de nouveau regardé la doc. Je pense que ton souci est qu'apparemment tu ne gères pas la broche SIQ.
Regardes le paragraphe 7.2.2 figures 12 et 13.
Si tu gères la broche SIQ de l'AR1020 en la branchant (de préférence sur une INT de ton micro) tu sauras quand l'AR1020 est prêt à t'envoyer des données...
Si tu as vraiment des PB, investit dans le kit AR1000 et branche ton scope. Tu verras les messages transiter.
Le Pickit Serial Analyzer est très pratique car il permet d'analyser les protocoles I2C, SPI, UART, Microwire...
a+
Excellente remarque, je ne gère pas du tout cette sortie ! je vais souder un petit pont quelque part.. merci
Mais mis à part ça, l'AR1020 ne devrait-il pas m'envoyer 0x4d s'il n'a rien de valide à envoyer ?
Salut,
J'ai aussi compris que l'on devrait recevoir 0x4D lorsqu'il n'y a rien ou lorsque l'on ne veut pas gérer SIQ pour gagner une broche.
La seule chose qui fait foi c'est l'oscilloscope pour déboguer les liaisons SPI ou I2Cvoire le Pickit Serial Analyzer si tu en as un sous la main.
J'ai utilisé le kit AR1000 par le passé. Cela simplifie grandement la compréhension
a+
ok, alors je vais essayer de trouver un analyseur, et dans un premier temps y jeter un oeil à l'oscillo. Merci déjà pour l'aide !
Je me suis procuré un analyseur logique, et voilà ce que ça dit : si j'envoie p.ex :
0x55 0x01 0x22 0x00 0x00
je reçois :
0x00 0x55 0x01 0x22 0x00
Comme si l'AR1020 était un registre à décalage..
J'ai déjà changé l'AR1020 deux fois, donc les risques qu'il soit cassé sont faibles.
Mon schéma électrique est-il correct ?
Et encore ce que donne l'analyseur logique :
Uploaded with ImageShack.us
Je viens d'essayer avec un AR1010 (connection UART), et ça fonctionne (en tout cas mieux qu'avec le 1020).
Disons, problème à moitié résolu :/
Bonjour ben106,
As tu réussi à résoudre ton pb avec le AS1020, j'essai moi aussi de faire fonctionner ce circuit avec une dalle résistive, mais je n'arrive pas recevoir moi aussi les trames de réponses .
Merci de ton retour,
