Go Down

Topic: Résistance pull-up Arduino Due inversée ?  (Read 195 times) previous topic - next topic

BobarTrump

Bonjour,

Voila, depuis peu j'utilisais le MPU 9250 sur une carte arduino UNO, les tests que j'avais réalisé avec me semblaient correctes. Pour des raisons techniques, il a fallu que je passe à la carte Arduino Due et là, galère.

Au départ j'avais connecté le MPU sur les broches  SDA1 et SCL1 plus ou moins au même endroit que sur la UNO. Comme je n'utilisais pas Wire1,  je n'avais plus de réponse, c'est comme ça que j'ai réalisé qu'il y avait deux paires pour l'I2C avec l'Arduino Due.

Comme j'ai lu que les broches SDA0 et SCL0 (20 et 21) avaient des résistances pullup et qu'on utilisait habituellement cette paire, j'ai donc changé mon cablâge pour  les utiliser. J'avais enfin une réponse du MPU mais le magnétomètre ne répondait plus et les valeurs obtenues pour pour l'accéléromètre et le gyroscope étaient totalement bidons :

Pour finir je suis revenu sur les broches SDA1 et SCL1 sans résistances Pullup externe et en utilisant Wire1 dans mon code et là ça fonctionne parfaitement.

D'où ma question, est-ce qu'il est possible que sur ma carte Arduino Due, les résistances pullup internes se trouvent en fait sur les broches SDA1 et SCL1 ? Comment est-ce que je pourrais le vérifier ?


68tjs

Je ne connais pas l'ARM SAMxxxxx qui équipe la carte DUE mais en principe toutes les I/O sont pourvues de résistance de tirage à l'alim (pull-up).
Il faudrait s'en assurer en consultant la datasheet du microcontrôleur de la DUE.

Elles sont activées ou désactivées par programmation.
La version de Wire  pour architecture avr les active par défaut.
Il faut vérifier s'il en est de même avec la version pour ARM --> la seule solution est d'ouvrir les fichiers de la bibliothèque.

De toute façon ces résistances de pull-up internes au microcontrôleur ont des valeurs trop élevée pour obtenir un fonctionnement correct de l'I2C.
L'I2C, surtout si Vcc= 3,3V, demande une résistance entre 4 et 10 k --> c'est une question de bande passante minimale.
Je ne peux que te conseiller de placer des résistances externes si les modules I2C n'en sont pas déjà pourvu.

bilbo83

Bonjour,

Résistances inversées, cela serait étonnant sur une DUE d'origine Arduino.
Pour tester, rien de plus simple, un ohmmètre et une mesure entre les bornes SDA (SDA1) et +3,3v, puis entre SCL (SCL1) et +3,3v. Les résistances ont une valeurs de 1,5K (sur le port 1 uniquement).

ard_newbie


les schémas des 2 versions de cartes DUE indiquent bien des résistances de tirage de 1K5 sur SDA/SCL uniquement :
voir ici

D'autre part, les AVR ont un filtrage hardware que n'ont pas les ARM., voir réponse #19 de ce post pour y remédier:
ICI

Enfin, si SDA1/SCL1 sont utilisées, il faut effectivement placer ceci en début de code:
#include <Wire.h>
#define Wire Wire1
et mettre des résistances de tirage de 2K2 (reliées au 3.3V), c'est la valeur qui semble donner les meilleurs résultats.

Il se peut aussi que l'équipement connecté dispose déjà de résistances de tirage.

BobarTrump

Merci pour vos réponses :) J'ai effectivement mesuré une résistance de ~1,5 KOhm sur les pins 20 et 21 de la cartes.

Donc ça n'explique pas pourquoi ça déconnait. Pour donner un ordre d'idée en ce moment je teste le MPU 9250 avec le code de Kriswiner, sans les pullup j'avais un rate avec une moyenne de 680 Hz et parfois des freeze qui m'obligeait à redémarrer la carte. Depuis que j'ai ajouté des pullup de 2K ça tourne plutôt autour de 700 Hz, il y a une nette différence mais surtout je n'ai plus de freeze. 

ard_newbie

#5
May 21, 2017, 06:49 am Last Edit: May 21, 2017, 11:27 am by ard_newbie
Le code de Kriswiner est, semble-t-il, écrit pour tourner sur un STM32. je n'ai pas regardé en détail, mais il est probable que des optimisations du code utilisent des spécificités de cet uc.

Il y a  ICI , #reponse 11, un code qui reste à améliorer, mais qui utilise le TWI avec le DMA du Sam3x, donc à priori beaucoup plus performant. Ce code écrit pour le MPU 6050 devrait être transposable à ton module.

J'ai noté que le MPU 950 fonctionne en I2C (TWI) mais aussi en SPI. La bibliothèque TurboSpi pour Sam3x est très performante (42 MHz) car elle utilise le DMA.

BobarTrump

#6
May 22, 2017, 04:34 pm Last Edit: May 22, 2017, 08:05 pm by BobarTrump
Ben, le truc c'est ça fonctionne quand même assez bien maintenant, donc le code n'est pas si incompatible que ça, j'ai du faire des aménagements évidemment, comme me resservir à nouveau de Wire.h au lieu de sa bibliothèque, cela dit ça reste erratique pour des raisons qui m'échappe encore...


En fait, il n'arrive pas toujours à trouver le MPU en faisant un SCAN, mais quand il y arrive ça va très bien. En règle général si ça arrive, je redémarre Arduino et je déconnecte et reconnecte l'USB, ça se remet à fonctionner. Ca n'arrive pas toujours, hier pendant deux trois heures je l'ai trouvé très très stable par exemple, je pensais même être débarrassé du problème...

Est-ce que vous pourriez me dire si mon schéma de câblage avec les résistances 2K est correcte ?




68tjs

Quote
Est-ce que vous pourriez me dire si mon schéma de câblage avec les résistances 2K est correcte ?
Depuis l'écran principal de fritzing tu as un "bouton" marqué "schematic".
Cela va donner un schéma électrique , parce que ce tu donnes c'est un schéma de câblage.
Pour te répondre il faut reconstituer dans notre tête le schéma électrique qui est le seul sur lequel on travaille.
Peut tu nous envoyer ce schéma électrique .

Quote
comme me resservir à nouveau de Wire.h au lieu de sa bibliothèque, cela dit ça reste erratique pour des raisons qui m'échappe encore...
Qu'est-ce qu'une bibliothèque?
C'est un fichier c ou c++ qui est compilé, qui est utilisé dans le programme principal.

Qu'est-ce qu'un fichier *.h
C'est un fichier d'en-tête.
Arduino c'est du C ou du C++. Pour comprendre la programmation avec arduino rien ne vaut un bon tuto de C ou C++.
En C/C++ tout doit être annoncé au compilateur  : si on utilise une fonction elle devra être déclarée avant son utilisation, c'est pour cela que cela se fait en début du fichier principal.  C'est le rôle des fichiers inclu par " #include " en début de fichier principal.

Création d'un programme exécutable:
Soit tu fais tout à la main avec un makefile (je n'y ai encore rien compris) soit tu ne te casse pas la tête et tu utilises un Environnement de Developement Intégré (en anglais IDE) qui construira le makefile pour toi et qui fera bien d'autre choses pour te simplifier la vie.

Ici on utilise l'IDE "dite Arduino" (en fait arduino a adapté l'IDE Processing ).
Du point de vue bibliothèque cette IDE fait quoi ?
- elle prévoit des emplacements réservés pour le dépot des fichiers sources des bibliothèques.
Il y en 3 : un emplacement pour les bibliothèques gérées par Arduino (Wire en fait partie), un emplacement pour les bibliothèques de tierces parties "officielles" comme la bibliothèque servo et un emplacement pour les bibliothèques "utilisateur".
Les bibliothèques "utilisateur" se déposent dans le répertoire de ton compte /arduino/libraries/
Les différents chemins vers ces répertoires sont indiqués au compilateur par l'IDE.

- le seul fait d'indiquer dans le fichier *.ino un fichier d'en-tête (fichier *.h) fera que l'IDE signalera au compilateur qu'il doit compiler aussi le fichier *c ou *.cpp correspondant.
Tu n'as rien à faire l'IDE le fait pour toi, mais si la bibliothèque a été mal installée le compilation générera des insultes.

Nb Les anglo-saxons disent "library" mais nous les francophones mous utilisons le terme "bibliothèque"

BobarTrump

J'ai corrigé mon schéma de câblage parce que j'avais une grosse erreur en inversant sur le VCC et le GND du MPU, erreur que je n'ai pas fait en vrai (heureusement). Mais bon cette discussion est +ou- close parce que j'ai enlevé les résistances pullup en restant sur SDA1 et SCL1, ça fonctionne très bien. les freeze que j'avais devaient venir d'ailleurs... En tout cas je n'ai plus de problèmes de ce type. Je tâtonne encore avec toutes ces notions, c'est étonnant que ça n'ait pas encore grillé d'ailleurs...

Je comprends ce qu'est qu'une librairie ou autre, en fait je m'en sors plutôt bien en C et en C++ (par rapport à Arduino ^^). Je me suis  mal exprimé, dans son code il se sert d'une bibliothèque différente pour l'I2C étant donné que son code est destiné à être utilisé avec un matériel différent : "Sketch runs on the 3.3 V 8 MHz Pro Mini and the Teensy 3.1."

Donc je suis simplement revenu à Wire.h en modifiant certaines partie du code et ça a marché, c'est ça que je voulais dire.


68tjs

Ok, il existe d'autres bibliothèques i2C pour mivrocontroler Atmel avr qui peuvent aussi être utilisées.
Elles sont souvent plus optimisées et plus rapides (c'est souvent lié) mais gèrent rarement le mode esclave comme le fait la bibliothèque fournie pas l'IDE arduino.

Go Up