bon et bien comme vous l'avez dit à de nombreuses reprises le problème se situe souvent entre la chaise et le clavier, bon la pour le coup entre la chaise est la board PCB.
EN effet sur le PCB j'ai mes les barrettes de connecteurs puis déposer le nano sans souder pour ne pas être ennuyer quand je mettrais sur un vrai circuit.
Et bien le problème venait de là. mauvaise connexion certainement ou faux contact. En mettant directement les fils dans les trous ça fonctionne.
Merci a tous pour votre aide sur mon probleme qui pour le coup est ridicule.
Cela prouve bien a quel point j'ai encore du travail.
Cela confirme que plus l'erreur est énorme plus elle est difficile [à trouver.
Il faut bien débuter un jour et c'est en forgeant qu'on ...
Juste pour info
rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
Il se base sur quoi pour la date.
J'ai cru comprendre qu'il prenait celle du pc avec lequel on injectais le code.
Quand la pile se decharge et qu'on en remet une nouvelle il relance ce bout de code.
Il faut rebrancher le nano à chaque changement de pile du coup?
merci
DATE et TIME représentent la date et l'heure de compilation.
Pour éviter de repartir sur cette date à chaque changement de pile, Il faudrait par exemple entrer la date et l'heure par le terminal, ou un clavier matriciel, ou quelques boutons + / -.
@+
On ne met pas à l'heure un DS3231 tous les jours ni tous les ans. Pour moi la mise ou remise à l'heure se fait à la première mise sous tension ou très exceptionnellement, un programme dédié qu'on charge exprès pour cette opération est la meilleure solution.
Dans le programme applicatif on ignore totalement les fonctions de mise à l'heure, cela évite bien des complications.
Bonsoir
Je me permets un petit déterrage des familles mais le problème rencontré est le même.
Il y a énormement de sujets sur ce souci, j'en ai parcouru pas mal !!
J'ai ce module:
J'ai tenté 2 branchements:
module -> arduino Uno
VCC -> 3.3v
GND -> GND
SDA -> SDA
SCL -> SCL
et aussi :
VCC -> 3.3v
GND -> GND
SDA -> A4
SCL -> A5
Ces branchements ont été testés avec et sans pile.
A chaque fois jai la lecture 165.165.165
Lorsque je scanne l'I2C, je vois uniquement le 0x57 mais pas le 0x68 du chip DS3231
J'ai lu qu'il y avait de nombreux modules pour lesquels il y avait de mauvaises soudures.
A l'oeil tout me semble correct.
Que dois-je tester pour déceler une erreur ?
Merci bien
L'adresse I2C de ce module est bien 0x57, voir ici
Les connexions sont expliquées aussi. Il faut donner plus d'informations pour qu'on t'aide. Poste ton code ou teste les exemples de la bibliothèque .
L'adresse I2C de ce module est bien 0x57, voir ici
De quel module tu parles ?
L'adresse du DS3231 est fixe et vaut 0x68.
Les adresse I2C sont limitées en nombre et il a été considéré que dans un montage on ne plaçait qu'une seule horloge.
Toutes les horloges RTC I2C ont l'adresse 0x68
Can be cascaded with other IIC device, 24C32 addresses can be shorted A0/A1/A2 modify default address is 0x57
C'est l'adresse de l'eeprom qui comporte 3 bits modifiables.
Le problème n'est pas le code personnel, il existe déjà avec le scanner qui détecte l'eeprom mais pas le ds3231.
Si l'adresse 0x68 n'est pas vue alors que 0x57 est vue c'est qu'il y a un problème.
Une bonne loupe et refaire les soudures ne fera pas plus de mal qu'il y en a déjà.
C'est le type de produit à 1,5€ (peut-être pas chez amazon) que l'on achète par 2 ou 3 .................pour le cas où.
Le fait qu'amazon indique que le produit est indisponible et qu'il sera ne sera peut-être pas réapprovisionné fait penser à un abandon de fournisseur.
oui merci c'est tout à fait ca.
j'ai un peu testé les continuités tout m'a l'air OK
En revanche j'ai l'impression que j'ai le cas ou le + pile et le VCC sont en commun du coup je pense que quand j'ai braché l'USB le chip a du recevoir 3.3+5V donc il n'a pas du aimer...