Incompatibilité entre périphériques i2c: certaines RTC 1307 et eeprom 27c256?

Version imprimable

3 pièce(s) jointe(s)

Bonsoir à tous

Je croyais mon problème complètement résolu. J'ai lancé plusieurs SOS pour des comportements curieux et inexplicables, dont des versions de mes anciens sketches devenus totalement inopérants sans que je n'arrive à trouver l'explication, et des recherches manipulations récentes me font mettre le doigt sur un comportement curieux que je ne sais expliquer.

Mon dernier appel https://www.developpez.net/forums/d2.../#post11907298, m'a permis de faire tourner simultanément deux maquettes, sur deux ordinateurs différents, dont une maquette de mon application et une autre permettant de tester le contenu de l'eeprom générée par ma maquette, et qui comporte des "parasites" lors de sa programmation.

Ma maquette est celle qui est "traitée" ici et que j'ai pu réaliser grâce à votre aide. :applo:

https://www.developpez.net/forums/d2.../#post11773277

https://www.developpez.net/forums/d2.../#post11720415

https://www.developpez.net/forums/d2.../#post11708737

https://www.developpez.net/forums/d2.../#post11700225

Suite à ces manipulations, je constate une "incompatibilité" (apparente) entre ma mémorisation en eeprom et une sorte de RTC à base de 1307, choisie car elle comporte une petite RAM non volatile que j'utilise pour conserver quelques valeurs (des durées manuelles) pour ne pas qu'elles soient perdues en cas de coupure d'alimentation. Ce serait donc bien de pouvoir les conserver, à condition d'expliquer et de supprimer mon problème, actuellement insoluble (pour moi).

Les faits:

Quand j'enregistre une piste de programmation d'une voie (sur les quatre possibles) pour une durée de X minutes sur une semaine qui en comporte 10080, j'ai remarqué que l'écriture semblait bien se faire, aux bonnes adresses, mais que d'autres écritures parasites apparaissaient dans d'autres zones des 10080 positions, et le plus souvent de manière erratique.

Le rebondissement récent est que c'est la présence sur le même bus i2c de la rtc fautive qui sème le trouble. Voilà, sur un sketch réalisé sur une maquette uno, qui comporte un afficheur (en i2C), une RTC et une eeprom. J'ai aussi une RTC 1307 aussi, d'un autre modèle qui ne pose pas le problème d'où mon trouble.

Voici le listing du sketch:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
      //  Cohabitation_1307_eeprom_01.ino copie de 1307_eeprom_01.ino nettoyé des inutilités 10 janvier 2023
 #include <Wire.h>    // Bibliothèque pour l'I2C
#include "RTClib.h"  // Bibliothèque pour le module RTC
#include <LiquidCrystal_I2C.h> // Bibliothèque pour l'écran
          //  =================  Définitions  =====
uint16_t    nbDeDump  =   1000 ;   // nombre de case de dump
 
#include "I2C_eeprom.h"
I2C_eeprom ee ( 0x50 , I2C_DEVICESIZE_24LC256 ) ;
 
       //   mes variables Clavier
int   KA  ;   // poussoir 1
int   KB  ;   // poussoir 2
int   KC ;    // poussoir 3
int   KD  ;   // poussoir 4
int   touches ;   // "clavier" combiné
uint16_t cpt1  ;   // compteur de boucle dump
int reep  ;   // read eeprom cad lecture EN eeprom
uint16_t  Erreurs ;   //  comptage des erreurs
 
LiquidCrystal_I2C lcd ( 0x27 , 16 , 2 ) ; //  afficheur 2 lignes 16 caractères
void setup ( void ) 
    {
    Serial.begin ( 115200 ) ;  // était 115200 bauds
            //Initialisation de l'éran
    lcd.begin ( 16 , 2 ) ;    // 16 col, 2 lignes
    lcd.init () ; // initialisation lcd
    lcd.clear () ;
    lcd.backlight () ;
    Wire.begin () ;   // Initialise la liaison I2C  
 
           // Définition ports e/s
    pinMode ( 9 , OUTPUT ) ;      // borne 9 ou PB1 ou D9 en sortie
    pinMode ( 10 , OUTPUT ) ;      // borne 10 ou PB2 ou D10 en sortie
    digitalWrite ( 9 , LOW ) ;    // 0 par défaut
    pinMode ( 2 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D2 ou INT0 ou 32
    pinMode ( 3 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D3 ou INT1 ou 1
    pinMode ( 4 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D4 ou PD4 ou 2
    pinMode ( 5 , INPUT_PULLUP ) ;    // entrée 
 
    Serial.print ( "Source du fichier: " ) ;
    Serial.print ( __FILE__ ) ; Serial.println ( "\tGuy du 10 jan 2023" ) ;   // mon commentaire initial
    ee.begin () ;   // initialisation dialogue
    }
          //  ====  Entrée dans la boucle 
void loop ()
    {
    if ( touches == 1 ) dumpEeprom () ;     // lecture et affichage de eeprom toutes les minutes
 
    lectureClavier () ;   //
 
    delay ( 1000 ) ; // delais de 1 seconde
    allumeBleu () ;
    delay ( 500 ) ;
    eteintBleu () ;
    }
           /// ===== fin du loop ====
 
      ///   =============================
 
void dumpEeprom ()      // lecture et affichage de eeprom
    {
          Serial.println () ;   // saut de ligne
          Serial.print ( "\tDump de l'eeprom (" ) ;  // message
          Serial.print ( nbDeDump , DEC ) ;   // précise le nombre
          Serial.println ( " octets)" ) ;    // terminaison message
          for ( cpt1 = 0 ; cpt1 < nbDeDump ; cpt1 ++ )      // définition de la boucle 32767
              {
                reep = ee.readByte ( cpt1 ) ;   // lecture courante
                if ( cpt1 % 100 == 0 ) 
                    {
                      Serial.print ( "\t@ " ) ; Serial.print ( cpt1 , DEC ) ;   // adresse
                      Serial.println () ;    // fin de ligne
                    }
                if ( reep == 0 ) Serial.print ( "-" ) ;
                if ( cpt1 % 10 == 0 ) Serial.print ( " " ) ;    // séparateur dizaines
                if ( reep != 0 ) Serial.print ( reep , HEX ) ;
              }
         Serial.println () ;    //  saut de ligne terminal 
         Serial.println ( "Fin du dump" ) ;    //  
         Serial.println () ;    //  
        }
            //  ===========     
void  allumeBleu ()
  {
    digitalWrite ( 9 , HIGH ) ;    // allume
  }
          // ========
void  eteintBleu ()
  {
    digitalWrite ( 9 , LOW ) ;    // allume
  }
          // ========
 void lectureClavier ()     // lecture des boutons
    {
    KA = digitalRead ( 2 ) ;    // lecture poussoir 1
    KB = digitalRead ( 3 ) ;    // lecture poussoir 2
    KC = digitalRead ( 4 ) ;    // poussoir 3
    KD = digitalRead ( 5 ) ;    // poussoir 4
 
    if ( KA == 1 ) KA = 0 ; else KA = 1 ;   // inversion
    if ( KB == 1 ) KB = 0 ; else KB = 2 ;   // inversion et poids 2
    if ( KC == 1 ) KC = 0 ; else KC = 4 ;   // inversion et poids 
    if ( KD == 1 ) KD = 0 ; else KD = 8 ;   // inversion et poids 
 
    touches = KA + KB + KC + KD ;    // KC en positon2
    lcd.setCursor ( 14 , 1 ) ; 
    lcd.print (  touches , DEC  ) ;       // clavier décodé         
    }

Voici les ingrédients utilisés:

Pièce jointe 632249

Ceci est l'eeprom.

Pièce jointe 632253
Ceci est la RTC qui ne pose pas de problème.

Pièce jointe 632252

Ceci est l'eeprom qui pose problème, pas toujours le même.

Et voici un dump sur les 1000 premiers octets de l'eeprom testée. Les bits utiles à 0 du nibble bas sont remplacés par des tirets pour simplifier la lecture. Quand c'est différent de 0, c'est que une des quatre piste est programmée.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	Dump de l'eeprom (1000 octets)
	@ 0
- --------- 1111111111- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
 2222222222- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- --------- 3333333333- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- --------- 4444444444- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- --------- 5555555555- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- --------- 6666666666- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- --------- 7777777777- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- --------- 8888888888- ---------- ---------
Fin du dump

C'est lu sans que le RTC soit enfichée. C'est lu correctement, et j'ai pu vérifier que la RTC, qui là n'est pas programmée, est bien lue quel qu'en soit le modèle si le programme du sketch l'exploite et l'affiche.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
	Dump de l'eeprom (1000 octets)
	@ 0
- --------- 1111111111- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
 2222222222- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- --------- 3333333333- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- --------- 4444444444- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- --------- 5555555555- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- --------- 6666666666- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- --------- 7777777777- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- --------- 8888888888- ---------- ---------
Fin du dump

Sauf erreur, c'est strictement identique.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	Dump de l'eeprom (1000 octets)
	@ 0
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- --------- 2222222222- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- --------- 4444444444- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- --------- 8888888888- ---------- ---------
Fin du dump

Ceci est la lecture de la même eeprom par l'échantillon 1 de ma RTC à problème. Je me suis aperçu que mon autre échantillon donne une lecture différente de celle-ci:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	Dump de l'eeprom (1000 octets)
	@ 0
- --------- 1111111111- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------
Fin du dump

Côté hard, la maquette ne comporte que le bus i2c et les alimentations en plus des switches qui permettent de lancer le dump.

J'ose espérer que je ne fais pas d'erreur d'interprétation et que mes informations données ici vous permettront de mettre le doigt sur l'ânerie que je fais (je ne vois pas d'autre explication) qui m'empêche de dormir depuis déjà un certain temps.

J'avais contourné le problème sur mon prototype, en limitant ma zone à 1440 octet, soit une journée au lieu de la semaine. Bien que non prouvé dans les faits, j'ai cru remarquer que les parasites apparaissaient parfois avec un décalage de 4096 octets.

Pourtant, les constats que montrent mes relevés ci-dessus, montrent une altération en lecture de l'eeprom.

J'attends avec une grande impatience vos remarques, vous les spécialistes mais surtout les pratiquants car j'ai du mal admettre que ce que je demande à mes deux périphériques est normal, et si le comportement est anormal, c'est mon programme qui comporte une erreur ou des maladresses.

Merci d'avance pour les progrès que vous allez, une fois de plus, me permettre de faire. :hola:

Bonjour à tous

Pour bien prouver que ce n'est pas l'inactivité de la RTC qui est susceptible de modifier son comportement, je tiens à compléter mes informations en publiant la version du sketch qui a précédé celle de mon #1, et dans lequel le loop comporte une interrogation de cette RTC et affiche sur ma visu lcd, la date et l'heure, et permet, sur action du switch, de lancer un dump de l'eeprom.

Voici ce listing, sans les nettoyages des inutilités.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
      /// 1307_eeprom_uno_03.ino    9 janvier 2023
        // version 03 pour introduire eeprom et procéder à des lectures écritures
 
      // pour test hw-111 qui ne fonctionne pas sur nano
#include <Wire.h>    // Bibliothèque pour l'I2C
#include "RTClib.h"  // Bibliothèque pour le module RTC
#include <LiquidCrystal_I2C.h> // Bibliothèque pour l'écran
 
          //    pour eeprom 
          //  =================  Définitions  =====
int   colonne = 0 ;   // colonne écriture      
uint16_t    nbDeDump  =   1000 ;   // nombre de case de dump
uint8_t     temoin    =   5  ;   // valeur à écrire
uint16_t    quantite  =   10  ;   // nb octet à écrire
uint8_t     Version    =   10  ;   // version du programme prévu de 0 à F
uint16_t    Offset  =   0  ;   // décalage de l'écriture du temoin en eeprom  
int         seconde ;   // la secone courante 
int         minute ;   // la minute courante 
int         heure ;   // la heure courante 
 
#include "I2C_eeprom.h"
I2C_eeprom ee ( 0x50 , I2C_DEVICESIZE_24LC256 ) ;
 
       //   mes variables
int   KA  ;   // poussoir 1
int   KB  ;   // poussoir 2
int   KC ;    // poussoir 3
int   KD  ;   // poussoir 4
int   touches ;   // "clavier" combiné
uint16_t cpt = 0 ;   // comptage boucles
uint16_t cpt1  ;   // compteur de boucle dump
int reep  ;   // read eeprom cad lecture EN eeprom
uint16_t  Erreurs ;   //  comptage des erreurs
 
 
 
 
RTC_DS1307 RTC;      // Instance du module RTC de type DS1307
//  LiquidCrystal_I2C lcd ;   // (0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); ////Instance d'écran
//LiquidCrystal_I2C lcd  (0x3F, 2, 1, 0, 4, 5, 6, 7, 3 ) ; // , POSITIVE); ////Instance d'écran
 
LiquidCrystal_I2C lcd ( 0x27 , 16 , 2 ) ; //  afficheur 2 lignes 16 caractères
//  
void setup ( void ) 
    {
    Serial.begin ( 115200 ) ;  // était 115200 bauds
            //Initialisation de l'éran
    lcd.begin ( 16 , 2 ) ;    // 16 col, 2 lignes
    lcd.init () ; // initialisation lcd
    lcd.clear () ;
    lcd.backlight () ;
    // lcd.setCursor ( 0 , 0 ) ;
        // lcd.setCursor(0, 1);
    Wire.begin () ;   // Initialise la liaison I2C  
    RTC.begin ()  ;   // Initialise le module RTC
 
           // Définition ports e/s
  pinMode ( 9 , OUTPUT ) ;      // borne 9 ou PB1 ou D9 en sortie
  pinMode ( 10 , OUTPUT ) ;      // borne 10 ou PB2 ou D10 en sortie
  digitalWrite ( 9 , LOW ) ;    // 0 par défaut
  pinMode ( 2 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D2 ou INT0 ou 32
  pinMode ( 3 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D3 ou INT1 ou 1
  pinMode ( 4 , INPUT_PULLUP ) ;    // entrée SW avec pull up  borne D4 ou PD4 ou 2
  pinMode ( 5 , INPUT_PULLUP ) ;    // entrée 
 
 
        //Initialise la date et le jour au moment de la compilation 
        // /!\ /!\ Les lignes qui suivent sert à définir la date et l'heure afin de régler le module, 
        // pour les montages suivant il ne faut surtout PAS la mettre, sans à chaque démarrage 
        // le module se réinitialisera à la date et heure de compilation
 
        // DateTime dt = DateTime ( __DATE__ , __TIME__ )  ;   // debug = supprimé
        // RTC.adjust ( dt ) ;
    Serial.print ( "Source du fichier: " ) ;
    Serial.print ( __FILE__ ) ; Serial.println ( "\tGuy du 30 dec 2022" ) ;   // mon commentaire initial
    Serial.print ( "Version EEPROM: " ) ;
    Serial.println ( I2C_EEPROM_VERSION ) ;
    ee.begin () ;   // initialisation dialogue
 
    }
          //  ====  Entrée dans la boucle 
void loop ()
    {
            // lcd.setCursor ( 0 , 0 ) ;  
  DateTime now = RTC.now () ; //Récupère l'heure et le date courante
  affiche_date_heure  ( now ) ;  //Converti la date en langue humaine
          // seconde = now.second () ; 
  // lcd.setCursor ( 14 , 1 ) ;
          // lcd.print ( "TATA" ) ;
  seconde = now.second () ;
  heure   = now.hour () ;
  minute  = now.minute () ;
  // lcd.print (  touches , DEC  ) ;       // clavier décodé
  lcd.setCursor ( 0 , 1 ) ;
  lcd.print ( Vers2Chiffres ( heure ) ) ; lcd.print ( ":" ) ;
  lcd.print ( Vers2Chiffres ( minute ) ) ; lcd.print ( ":" ) ;
  lcd.print ( Vers2Chiffres ( seconde ) ) ; lcd.print ( ":" ) ;
  if ( touches == 1 ) dumpEeprom () ;     // lecture et affichage de eeprom toutes les minutes
 
  lectureClavier () ;   //
 
 
   // lcd.setCursor ( 0 , 0 ) ;
     //  lcd.print ( "TOTO" ) ;
            // lcd.print ( jour )  ;
     //  lcd.setCursor ( 0 , 1 ) ;
     //  lcd.print ( "TATA" ) ;
    delay ( 1000 ) ; // delais de 1 seconde
    allumeBleu () ;
    delay ( 500 ) ;
    eteintBleu () ;
    }
           /// ===== fin du loop ====
 
        //Converti le numéro de jour en jour /!\ la semaine commence un dimanche
String donne_jour_semaine ( uint8_t j )
  { 
  switch ( j )
      {
      case 0: return "DIM";
      case 1: return "LUN";
      case 2: return "MAR";
      case 3: return "MER";
      case 4: return "JEU";
      case 5: return "VEN";
      case 6: return "SAM";
      default: return "   ";
      }
  }
      ///   =============================
        // affiche la date et l'heure sur l'écran
void affiche_date_heure ( DateTime datetime )
  {
 
        // Date 
  String jour = donne_jour_semaine  ( datetime.dayOfTheWeek ()) + " " + 
                Vers2Chiffres ( datetime.day  ()  ) + "/" + 
                Vers2Chiffres ( datetime.month  ()  ) + "/" + 
                String  ( datetime.year ()  , DEC ) ;
        ////  ==================
        // heure
  String heure = "" ;
  heure  = Vers2Chiffres  ( datetime.hour  () )   + ":" + 
           Vers2Chiffres  ( datetime.minute  () ) + ":" + 
           Vers2Chiffres  ( datetime.second  () ) ;
            /// ==========
 
          //affichage sur l'écran
          // jour = "LUN" ; 
         // heure = 12 ;   // debug
  lcd.clear ();
  lcd.setCursor ( 0 , 0 ) ;
  // lcd.print ( "TOTO" ) ;
  lcd.print ( jour )  ;
  }
        /// ================
 
        //permet d'afficher les nombres sur deux chiffres
String Vers2Chiffres ( byte nombre ) 
  {
  String resultat = "";
  if ( nombre < 10 )  resultat = "0" ;
  return resultat += String ( nombre , DEC ) ;  
  }
      //// =======================
 
void dumpEeprom ()      // lecture et affichage de eeprom
    {
          Serial.println () ;   // saut de ligne
          Serial.print ( "\tDump de l'eeprom (" ) ;  // message
          Serial.print ( nbDeDump , DEC ) ;   // précise le nombre
          Serial.println ( " octets)" ) ;    // terminaison message
         // for ( cpt1 = 0 ; cpt1 < 10101 ; cpt1 ++ )      // définition de la boucle
          for ( cpt1 = 0 ; cpt1 < nbDeDump ; cpt1 ++ )      // définition de la boucle 32767
              {
                reep = ee.readByte ( cpt1 ) ;   // lecture courante
               // reep &= 0x0F ;          // masquer msb    //debug
                if ( cpt1 % 100 == 0 ) 
                    {
                      Serial.print ( "\t@ " ) ; Serial.print ( cpt1 , DEC ) ;   // adresse
                      Serial.println () ;    // fin de ligne
                    }
 
                if ( reep == 0 ) Serial.print ( "-" ) ;
                if ( cpt1 % 10 == 0 ) Serial.print ( " " ) ;    // séparateur dizaines
                if ( reep != 0 ) Serial.print ( reep , HEX ) ;
              }
         Serial.println () ;    //  saut de ligne terminal 
         Serial.println ( "Fin du dump" ) ;    //  
         Serial.println () ;    //  
        }
            //  ===========     
void  allumeBleu ()
  {
    digitalWrite ( 9 , HIGH ) ;    // allume
  }
          // ========
void  eteintBleu ()
  {
    digitalWrite ( 9 , LOW ) ;    // allume
  }
          // ========
 void lectureClavier ()     // lecture des boutons
    {
    KA = digitalRead ( 2 ) ;    // lecture poussoir 1
    KB = digitalRead ( 3 ) ;    // lecture poussoir 2
    KC = digitalRead ( 4 ) ;    // poussoir 3
    KD = digitalRead ( 5 ) ;    // poussoir 4
 
    if ( KA == 1 ) KA = 0 ; else KA = 1 ; // inversion
    if ( KB == 1 ) KB = 0 ; else KB = 2 ;   // inversion et poids 2
    if ( KC == 1 ) KC = 0 ; else KC = 4 ; // inversion et poids 
    if ( KD == 1 ) KD = 0 ; else KD = 8 ; // inversion et poids 
 
    touches = KA + KB + KC + KD ;    // KC en positon2
    lcd.setCursor ( 14 , 1 ) ; 
    lcd.print (  touches , DEC  ) ;       // clavier décodé         
    }

et voici les résultats des deux dumps à problèmes

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Source du fichion EEPROM: 1.7.0
Source du fichier: C:\Users\Guy\Documents\Arduino\1307_eeprom_uno_03\1307_eeprom_uno_03.ino	Guy du 30 dec 2022
Version EEPROM: 1.7.0
 
	Dump de l'eeprom (1000 octets)
	@ 0
- --------- 1111111111- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------
Fin du dump
 
 
	Dump de l'eeprom (1000 octets)
	@ 0
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 100
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 200
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 300
- ---------- --------- 2222222222- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 400
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 500
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 600
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 700
- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------	@ 800
- ---------- ---------- ---------- ---------- ---------- --------- 4444444444- ---------- ---------- ---------	@ 900
- ---------- ---------- ---------- ---------- ---------- ---------- --------- 8888888888- ---------- ---------
Fin du dump

qui sont inchangés alors que la RTC, elle, fonctionne correctement.

La version RTC elegoo ne comporte pas d'erreur et n'est donc pas reproduite.

On remarque sur les deux listes à problèmes que des tas de valeurs sont manquantes et/ou erronées. La seconde liste, qui comporte des 444 en ligne 900 devrait ne comporter que des 7777, soient deux bits qui y manquent.

Je reste sagement à l'écoute. :hola:

11/01/2023, 20h59
f-leb

Bonsoir,

Est-ce que l'eeprom qui pose problème a toujours le même problème quand elle est seule sur le bus I2C ? (c'est-à-dire sans le LCD ni la RTC).
11/01/2023, 21h49
gienas

Bonsoir f-leb

Citation:

Envoyé par f-leb

... Est-ce que l'eeprom qui pose problème ...

Je crois comprendre qu'il y a un malentendu. J'ai dû mal m'exprimer mais il semble que ce ne soit pas l'eeprom qui pose problème. J'en ai plus d'une dizaine et elles ont toutes le même comportement.

Le problème se manifeste uniquement lorsque je couple une eeprom, n'importe laquelle avec un modèle de RTC. Le problème n'existe pas si je couple une autre RTC, avec la même puce 1307, mais sur une autre carte.

Malheureusement, je ne suis pas certain de pouvoir réussir à mettre au clair cette histoire, car, à force de manipulation sur ma maquette de tests, où je passais d'une RTC à une autre, je crois bien que mes deux modèles fautifs semblent avoir rendu l'âme. Probablement à la suite de décalage de broches lors d'insertions sur mes plaques Labdec.

Je vais aller voir sur mon prototype, qui lui est en place, si c'est ce modèle qui s'y trouve. C'est très probable puisque sur cet équipement aussi, je constate mes "parasites".

Citation:

Envoyé par f-leb

... Est-ce que l'eeprom qui pose problème a toujours le même problème quand elle est seule sur le bus I2C ? (c'est-à-dire sans le LCD ni la RTC).

Je pense que cet essai a bien été pratiqué, mais toujours avec l'afficheur LCD. Depuis que j'ai constaté cette incompatibilité probable avec cette carte RTC, je me suis cantonné à des essais de lecture et sur une gamme de 1000 octets sur un contenu eeprom qui est présenté en #1.
11/01/2023, 23h09
Jay M

avez vous mis des résistances de pullup pour l'I2C ?

la sensibilité aux parasites dépend du pullup en place (que ce soit le votre où celui existant sur la carte et éventuellement les modules)

http://manubatbat.free.fr/robot/Doc/I2C/I2C.HTM
12/01/2023, 10h15
gienas

Bonjour Jay M

Citation:

Envoyé par Jay M

avez vous mis des résistances de pullup pour l'I2C ?

la sensibilité aux parasites dépend du pullup en place (que ce soit le votre où celui existant sur la carte et éventuellement les modules) ...

Oh que oui! C'est même toi, dans une de mes questions, qui avais attiré mon attention sur cette nécessité.

J'en suis actuellement à 1,5k de pullup, que j'avais même réduit à moins de 1k, mais cela n'arrange rien.

Le terme de "parasite" que j'utilise dans mon cas n'est probablement pas très adapté. On l'utilise habituellement pour désigner des impulsions qui passent et agissent, alors qu'elles sont inattendues, imprévues.

Dans mon cas, étant donné que des programmations déposées à certaines adresses se retrouvaient aussi à d'autres adresses, je les avais qualifiées de parasites. Depuis, je m'aperçois que ce sont bien parfois des présences inattendues, donc bien parasites, mais aussi des manques, des lacunes, comme mes relevés du #1 le montrent.

Ce qui est curieux, c'est qu'une seule variété de cartes RTC présentent ce défaut. Les deux qui me servaient à faire les tests sont effectivement détruites. Je viens de vérifier sur mon prototype que c'est bien le même modèle de RTC qui était monté. Je l'ai sorti pour essayer de mener mes essais jusqu'au bout, car cela me paraît totalement inexplicable, et j'y ai mis à la place, un modèle de carte 1307 qui ne présente pas le défaut.

J'ai fait une tentative de dump (donc avec l'ordinateur connecté dessus), et il semble que la lecture de l'eeprom présente sur cette maquette y soit lue correctement.

C'est encore trop tôt pour "pavoiser" car le programme y est modifié pour limiter le programmation possible à une seule journée au lieu de la semaine, mais c'est prometteur.

Pour étayer cet optimisme, la RTC récupérée et qui est maintenant la seule dont je dispose, essayée sur mon testeur objet du présent #1 provoque bien des manques lors de la lecture. Mon problème est donc bien réel.

Noter que cette carte RTC comporte deux adresses i2c: une de 0x50 et une de 0x68. Je n’exploite cependant que la 0x68.

Il se trouve que j'ai d'autres travaux urgents à faire avant de poursuivre. Je garde une oreille connectée pour pouvoir, le cas échéant, pratiquer un test qui pourrait m'être proposé, mais je vais lever le pied sur l'acharnement actuel.

Merci en tout cas pour les aides très appréciées. :hola:
12/01/2023, 11h51
Jay M

Citation:

Noter que cette carte RTC comporte deux adresses i2c: une de 0x50 et une de 0x68. Je n’exploite cependant que la 0x68.

c'est normal d'avoir deux adresses I2C visibles puisqu'il y a deux périphériques adressages sur un bus partagé sur la carte.

- Sur une DS1307 l'adresse 0x50 c'est pour l'EEPROM de la RTC (fixe) et l'adresse 0x68 c'est la RTC elle même
- Sur une DS3231 l'adresse 0x50 c'est pour l'EEPROM de la RTC (en fait c'est configurable suivant les modules entre 0x50 et 0x57) et l'adresse 0x68 c'est la RTC elle même

je n'ai pas bien compris si vous rajoutez une autre EEPROM que celle de la RTC? dans ce cas il faut bien entendu qu'elle ne soit pas à l'adresse 0x50 sinon lors de la tentative de discussion avec le composant sur le bus I2C vous aurez 2 composants sur le bus qui pensent que c'est à eux que l'on s'adresse et ça va mettre le bazar.

sur une DS1307 l'EEPROM est une AT24C32 donc avec 32,768 bits soit 4Ko de mémoire (4096 octets). Vous ne pourrez donc jamais y stocker une semaine sous forme de 10080 octets.. Seuls donc les 6 bits de poids faible de votre adresse en EEPROM sont pertinents. Si vous dépassez 4095 vous bouclez (4096 écrit à l'adresse 0, 4097 à l'adresse 1 etc)

Elle est donnée pour 1 million de cycle d'écritures donc le souci ne devrait pas être dans la destruction même si vous écrivez souvent (enfin du moment que ça reste raisonnable)

pour sérialiser les problèmes je vous recommanderais de tester avec juste la RTC connectée et en enlevant l'écran I2C ainsi que les résistances de pullup - et bien sûr ne pas chercher à écrire plus de 4Ko de données dans cette EEPROM.
12/01/2023, 14h03
gienas

Citation:

Envoyé par Jay M

... je n'ai pas bien compris si vous rajoutez une autre EEPROM que celle de la RTC? ...

Bien sûr. J’ajoute une eeprom autre puisque j’ai besoin de bien plus de capacité.

Citation:

Envoyé par Jay M

... si vous rajoutez une autre EEPROM que celle de la RTC? dans ce cas il faut bien entendu qu'elle ne soit pas à l'adresse 0x50 sinon lors de la tentative de discussion avec le composant sur le bus I2C vous aurez 2 composants sur le bus qui pensent que c'est à eux que l'on s'adresse et ça va mettre le bazar ...

Je crois bien que tu viens là de mettre le doigt sur mon problème. Je suis trop occupé par mon travail soudain pour y aller de suite, mais cela semble coller. Il est sûr que si deux périphériques ont la même adresse, on ne sait pas qui ”parle” et c’est le plus fort qui impose sa ”loi". Et, comme par hasard, je note des écarts de 4096 octets.

J’irai voir ce soir ce qu’il en est au juste, mais ça me semble parfaitement plausible.
12/01/2023, 14h37
Jay M

1 pièce(s) jointe(s)

à la lecture du code d'ailleurs (j'aurais dû mieux regarder) je vois

Code:

I2C_eeprom ee ( 0x50 , I2C_DEVICESIZE_24LC256 ) ;

donc vous pensez effectivement avoir une EEPROM de 256kbits (32Ko) à l'adresse 0x50 qui est l'adresse par défaut d'une 24LC256 mais aussi de la RTC.

et si vous voyez 4Ko d'écart il se peut que vous soyez en train d'écrire dans l'EEPROM de la RTC et donc toute lecture ou écriture qui dépasse la taille max reboucle

la bonne nouvelle c'est qu'on peut régler l'adresse I2C de la 24LC256 grace aux pins A0 A1 et A2 du composant

Pièce jointe 632393

l'adresse obtenue c'est 0x50 plus la valeur binaire du triplet "A2.A1.A0". En mettant à GND c'est un 0 et à HIGH c'est un 1. donc si vous mettez par exemple A0 à HIGH et laissez les deux autres à GND, l'adresse devient 0x50 + 0b001 soit 0x51

en faisant cela et en déclarant

Code:

I2C_eeprom ee ( 0x51 , I2C_DEVICESIZE_24LC256 ) ;

plus de conflit de bus I2C et tout devrait rentrer dans l'ordre.
12/01/2023, 22h27
gienas

Bravo! tu viens de mettre dans le mille! :applo:

Citation:

Envoyé par Jay M

... I2C_eeprom ee ( 0x50 , I2C_DEVICESIZE_24LC256 ) ...

C'est en effet, l'explication qui permet de comprendre tous mes déboires.

J'aurais d'ailleurs dû m'en apercevoir aussi, mais je n'avais pas tillté. Il m'est arrivé d'oublier d'embrocher l'eeprom et pouratnt, les dump me donnaient des contenus, farfelus mais des contenus.

Citation:

Envoyé par Jay M

... la bonne nouvelle c'est qu'on peut régler l'adresse I2C de la 24LC256 grace aux pins A0 A1 et A2 du composant ...

Oui mais non. Sur la RTC les broches adresses ne sont pas réglables et sur mon eeprom non plus. Sur l'eeprom, tout est mis à la masse et c'est tellement miniature (plus petit qu'un timbre) qu'il est hors de question d'y toucher.

La solution sera de changer de RTC, par exemple DS3231 miniature qui ne fait que l'horloge ou une autre version dont l'eeprom est en 0x57.

Merci pour cette super résolution. :yaisse2:
13/01/2023, 21h54
Jay M

Il existe des modules externes ou c’est réglable

Cf https://m.fr.aliexpress.com/item/1005001724767883.html
18/01/2023, 15h48
gienas

Petit complément à la solution proposée

Bonjour à tous

Merci encore pour "l'enquête" qui a porté ses fruits et même permis de réaliser un petit outil bien commode.

La correction, par remplacement de la RTC "incompatible" étant acté, j'ai pu rétablir la programmation sur la semaine comme initialement prévu.

Cette programmation est un peu fastidieuse à réaliser, debout dans la salle de bain où se trouve le prototype, bien entendu sans ordinateur. J'avais émis l'idée de réaliser cette programmation sur une maquette, avec l'ordinateur pour contrôler plus facilement les résultats, mais c'est difficile de placer sur un même bus i2c, deux eeprom identiques, une servant de source et l'autre étant la destination des écritures de copie.

J'ai réussi à y parvenir et je poste ici pour le cas où un besoin similaire se présentait avec la "philosophie" du processus.

Les deux eeprom sont utilisées à tour de rôle, Elles sont alimentées en permanence et le bus i2c est permuté au moyen de quatre interrupteurs CMOS MC4016 qui présentent le Data et le Clock sur l'eeprom souhaitée.

Deux sorties logiques sont sorties de l'Arduino pour sélectionner l'un ou l'autre et qui commandent les gates du 4016.

Les fonctions dump de l'une ou l'autre eeprom ainsi que les effacements (qui, au final ne sont pas utiles puisque la copie recopie les états présents sur la source) sélectionnent en permanence l'eeprom traitée.

La copie est un peu plus difficile et plus longue. Pour chaque octet à copier, il faut:

1- sélectionner la source;
2-lire la valeur;
3-désélectionner la source;
4-sélectionner la destination;
5- écrire la valeur lue;
6- lire la valeur enregistrée;
7- comparer avec la valeur source;
8- si erreur il y a, incrémenter le nombre d'erreurs;
9- désélectionner la destination.

Après le dernier octet écrit, on peut afficher le nombre d'erreurs, mais il doit rester nul.

Cet outil fonctionne sur la seule alimentation de la prise USB de l'Arduino. Il nécessite quatre boutons poussoirs pour les quatre seules fonctions nécessaires:

1- dump de la source qui s'affiche via le moniteur série;
2- dump de la destination;
3- copie de source vers destination;
4- RAZ de la destination.
19/01/2023, 20h24
Jay M

merci du retour.

Citation:

Envoyé par gienas

La copie est un peu plus difficile et plus longue. Pour chaque octet à copier, il faut:
...

vous pourriez éventuellement travailler avec plusieurs octets d'un coup car ces EEPROM supportent un mode "page" pour l'écriture si je me souviens bien.