Mise en œuvre bus I2C

[davidif]

Bonjour,

pour la première fois je met en oeuvre du I2C est comme je m'y attendais un peu j'ai quelques difficultés mais quelque notion de programmation me manque certainement bien que les driver ce génère automatiquement sous MPLAB v4.15 harmony V2.06 quand ont vient les cochets.
Je travail avec un pic32mx795f512l et je viens échanger avec le MAX17205 (composant qui mesure et acquière le SOC d'une batterie)
Ceci avec 2 carte d'éval, une pour le micro et l'autre avec le max17205 sur sa carte de test qui fonctionne tout autant en USB avec l'interface constructeur dont 2 emplacement prévu pour brancher les pins SDA et SCL.

Seulement j'ai le choix entre l'option static et dynamique mais je ne perçois pas bien ce que ça signifie en faite, juste pour avoir évidemment essayé les 2, j'ai moins de difficulté en static à voir une trame sur l'oscilo ... en dynamique pour le moment rien.

J'ai donc continué en statique, en voyant bien les trames passer, lesquelles correspondent bien à l'adresse envoyer? seulement je traverse 2 soucis pour le moment ... d'autres viendront (: par la suite.

Je n'arrive pas à envoyer plus d'un octet, tout au moins avec la fonction utilisé

char myBuffer[MY_BUFFER_SIZE] = { 56, 4, 78, 100, 55};
#define RTCC_SLAVE_ADDRESS 0x45
#define MY_BUFFER_SIZE 5

DRV_I2C1_Transmit ( RTCC_SLAVE_ADDRESS,&myBuffer,MY_BUFFER_SIZE,NULL);

Puis lorsque j'envoi une trame au MAX17205, la résultant marque bien l'adresse mais après le signal est écrasé, certainement une mauvaise adaptation je pense seulement je n'en suis pas sûr ... au départ j'ai mis des résistances de pull up de 460 Ohm le signal étant écrasé je les ai remplacer par des 5k, mais là le signal semble plus applati

Je ne sais pas encore si le problème est hard ou soft, bien que j'ai une suspicion sur le hard.

#define AvSOC                       ((uint16_t)0x0E)

uint16_t ReadRegistor (uint16_t reg)
{





	  RvBuffer[0]=0;
	  RvBuffer[1]=0;	 
	if (reg>0xff)
	{ 
		uint8_t t_reg=0;
		t_reg=(uint8_t)(reg&0xff);
        
		//I2C_MultiByteRead(Md_Addr,RvBuffer,t_reg,2);
        DRV_I2C1_Transmit (Md_Addr,RvBuffer,t_reg,NULL);
        
        RvTemp =(uint16_t)(((uint16_t)RvBuffer[1] << 8) | RvBuffer[0]);
    return RvTemp;
	}
	else
	{
		//I2C_MultiByteRead(Sl_Addr,RvBuffer,reg,2);
        DRV_I2C1_Transmit (Sl_Addr,RvBuffer,reg,NULL);
        
        RvTemp =(uint16_t)(((uint16_t)RvBuffer[1] << 8) | RvBuffer[0]);
		return RvTemp;
	}


 ret_max17=ReadRegistor(AvSOC);



}

Auriez vous des conseils s'il vous plait
-----

[Exotique]

Hello,
c'est sur que 460 ohms c'est bien trop faible, en général 4.7K c'est bien pour démarrer, tout dépend le nombre de CI que tu as en I2C, la longueur de tes pistes, la vitesse du bus.
Ta clock en bleu me semble propre, il faudrait voir ton signal plus dilaté, par exemple sur 2 périodes.
Le signal data par contre est curieux.
Poste ton schéma, je n'ai pas encore regardé ton code.

[Exotique]

J'ai un doute sur la fonction suivante:

DRV_I2C1_Transmit (Md_Addr,RvBuffer,t_reg,NULL);

Comment veux-tu écrire plusieurs fois avec NULL en paramètre?
Si tu as écrit cette fonction poste la que je comprenne comment tu l'as construite.

[davidif]

Hello,
c'est sur que 460 ohms c'est bien trop faible, en général 4.7K c'est bien pour démarrer, tout dépend le nombre de CI que tu as en I2C, la longueur de tes pistes, la vitesse du bus.
Ta clock en bleu me semble propre, il faudrait voir ton signal plus dilaté, par exemple sur 2 périodes.
Le signal data par contre est curieux.
Poste ton schéma, je n'ai pas encore regardé ton code.

Bonjour Exotique et merci pour ton temps,

Pour le moment j'ai pas mal tatoner, entre la comprehension du protocole I2C et son application propre aux matériel que j'utilise.

Côté max17205, je me suis inspiré de leur carte de dev pour l'électronique en page 23, pour les lignes SDA et SCL
https://datasheets.maximintegrated.c...7215XEVKIT.pdf

C10 et C11, D5,D3 ne sont pas présent, peut-être devrais-je me mettre derrière les résistances R14, R15 pour le moment j'ose pas trop modifié mon kit de dev et éviter de le mettre accidentellement hors service ce qui freinerai mon travail, aussi en cas de doute de dysfonctionnement je teste en USB via l'interface pc dédié qui marche bien.

Côté micro je sors direct des pins SDA, SLC avec les résistance de pull-up en 5K.

Niveau code, j'ai donc réussi à implémenter le bus I2C, mais encore du travaille à faire et des choses à éclaircir pour l'adapter au max

La j'ai le code généré par harmony de microchip :

// *****************************************************************************
// Section: I2C Instance 0 Function to write a buffer (Master/Slave)
// *****************************************************************************

DRV_I2C_BUFFER_HANDLE DRV_I2C0_Transmit (uint16_t deviceaddress,
                                    void *txBuffer,
                                    size_t size,
                                    void * context)
{
    DRV_STATIC_I2C_OBJECT* i2cBufferData;

    i2cBufferData = _DRV_I2C_QueueSlotGet_0();

    if (i2cBufferData != NULL)
    {
        i2cBufferData->i2cMode          = DRV_I2C_MODE_MASTER;
        if (deviceaddress > ADDRESS_7BIT_UPPER_LIMIT )
        {
            i2cBufferData->slaveaddresshighbyte = (uint8_t)((deviceaddress & 0xFF00)>>8);
            i2cBufferData->slaveaddresslowbyte  = (uint8_t)(deviceaddress & 0x00FF);
        }
        else
        {
            i2cBufferData->slaveaddresshighbyte = (uint8_t)(deviceaddress & 0x00FF);
            i2cBufferData->slaveaddresslowbyte  = 0;
        }
        i2cBufferData->i2coperation     = DRV_I2C_OP_WRITE;
        i2cBufferData->transfersize     = size;
        i2cBufferData->txBuffer         = txBuffer;
        i2cBufferData->bufferstatus     = DRV_I2C_BUFFER_EVENT_PENDING;
        i2cBufferData->transmitForced   = false;
        if (i2cBufferData->i2cMode == DRV_I2C_MODE_MASTER)
        {
            /*  if either START and STOP were not detected which is true the
            first time OR if STOP was detected, then it assumed the
            transaction on the bus is complete */

            if ( ((!(PLIB_I2C_StartWasDetected(I2C_ID_1))) && (!(PLIB_I2C_StopWasDetected(I2C_ID_1)))) || (PLIB_I2C_StopWasDetected(I2C_ID_1)) )
            {
                if ( (PLIB_I2C_BusIsIdle(I2C_ID_1)) && (!(PLIB_INT_SourceFlagGet(INT_ID_0, INT_SOURCE_I2C_1_MASTER))) )
                {
                        i2c0State = DRV_I2C_TASK_SEND_DEVICE_ADDRESS;
                        PLIB_I2C_MasterStart(I2C_ID_1);
                }
            }
        }
    }
    return (DRV_I2C_BUFFER_HANDLE)i2cBufferData;
}

Pour l'instant j'ai réussi à identifier l'adresse sur le bus à l'oscilo et ne comprend pas trop l'argument "void * context", c'est pour ça que j'ai mis le NULL, aussi en exemple des docs microchip.

Là c'est une petite partie du code envoyé par le support maxim concernant le pilotage du max

uint16_t ReadRegistor (uint16_t reg)
{
	  RvBuffer[0]=0;
	  RvBuffer[1]=0;	 
	if (reg>0xff)
	{ 
		uint8_t t_reg=0;
		t_reg=(uint8_t)(reg&0xff);
        
		//I2C_MultiByteRead(Md_Addr,RvBuffer,t_reg,2);
        DRV_I2C1_Transmit (Md_Addr,RvBuffer,t_reg,NULL);
        
        RvTemp =(uint16_t)(((uint16_t)RvBuffer[1] << 8) | RvBuffer[0]);
    return RvTemp;
	}
	else
	{
		//I2C_MultiByteRead(Sl_Addr,RvBuffer,reg,2);
        DRV_I2C1_Transmit (Sl_Addr,RvBuffer,reg,NULL);
        
        RvTemp =(uint16_t)(((uint16_t)RvBuffer[1] << 8) | RvBuffer[0]);
		return RvTemp;
	}
}

retour maxim

Linux driver
https://www.maximintegrated.com/en/p...5.html/tb_tab2

and here:
https://maximsupport.microsoftcrmpor...ticle/KA-11090

[A voir en vidéo sur Futura]

[davidif]

Ha oui j'oubliai,

J'ai qu'un périphérique (ou MAX17205) par bus, car j'utilise 4 bus I2C bien distinct de mon micro pour chacune des voies pour 4 batteries max à gérer.
J'ai donc pas besoin de faire de l'adressage, aussi par ce que j'aurai à échanger avec d'autre max embarqué sur d'autres batteries dont je ne connaitrai pas forcement leur adresses ... bien que j'imagine que l'on puisse les interroger ... mais ne connaissant pas encore trop leur fonctionnement pour le proto j'ai préféré faire comme ça le temps de comprendre comment tout ça fonctionne.

J'ai aussi un doute à savoir si l'on doit initialiser le max17205 au départ ou peut-on échanger sans ?.... pour récupérer l'info du soc.

[Exotique]

Tu utilises quel microcontrôleur de chez Microchip?

[Exotique]

J'ai aussi un doute à savoir si l'on doit initialiser le max17205 au départ ou peut-on échanger sans ?.... pour récupérer l'info du soc.

Oui il faut lui indiquer notamment la valeur de la capacité théorique de l'accu, mais par défaut il est capable de communiquer sans rien changer, sans quoi tu ne pourrais pas renseigner certains registres

[davidif]

Tu utilises quel microcontrôleur de chez Microchip?

J'ai l'habitude d'utiliser fréquemment le PIC32MX795F512L qui met maintenant assez familier pour pas perdre trop de temps, mais n'est pas encore utilisé toutes ces ressources
https://ww1.microchip.com/downloads/...S60001156K.pdf

docs I2C :
http://ww1.microchip.com/downloads/e...Doc/61116F.pdf

[davidif]

Bonjour,

Voici mon observation :

lorsque j'envoi

#define RTCC_SLAVE_ADDRESS 0xDE

avec

DRV_I2C1_Transmit ( RTCC_SLAVE_ADDRESS,&myBuffer,M Y_BUFFER_SIZE,NULL);

20201129_125806.jpg

lorsque j'envoi

#define RTCC_SLAVE_ADDRESS 0x6c registre du max

20201129_125920.jpg

En zoomant un peut
20201129_125939.jpg

A priori ont échange tout de même mais quoi ?

[davidif]

Bon bah, il semblerait bien que je balance les octets présent dans le buffer (:

char myBuffer1[MY_BUFFER_SIZE] = { 11, 52, 26,150,2};

en fait, a chaque pic, j'identifie bien les octets, juste que j'adapte ma trame (donc envoyer les bon octets d'adressage) de manière à avoir une réponses du max, que je ne perçois pas encore à ce jour.

[Exotique]

Oui tu envoies bien 0xDE on le lit facilement sur ta première photo (11011110).

[Exotique]

As-tu bien respecté ce protocole:

The read data protocol is used to transmit data from IC
memory locations 000h to 1FFh . Addresses 000h to 0FFh
and 180h to 1FFh can be read as a block. Addresses
100h to 17Fh must be read as individual words. The memory address is sent by the bus master as a single byte
value immediately after the slave address. Immediately
following the memory address, the bus master issues
a REPEATED START followed by the slave address.

[davidif]

As-tu bien respecté ce protocole:

The read data protocol is used to transmit data from IC
memory locations 000h to 1FFh . Addresses 000h to 0FFh
and 180h to 1FFh can be read as a block. Addresses
100h to 17Fh must be read as individual words. The memory address is sent by the bus master as a single byte
value immediately after the slave address. Immediately
following the memory address, the bus master issues
a REPEATED START followed by the slave address.

Bonjour

Ta raison, il faut que je détaille mieux cette partie là, pour commencer avec les routines transmis par le support maxim je n'ai pas vraiment vérifié tous ça en détails car je pensai qu'il n'y avait pas grand chose à faire, suffisait d'adapter la structure à mon architecture notamment pour les lecture et écriture sur le bus I2C propre à mon micro.

[davidif]

Bonsoir

Bon c'est pas encore ça

j'ai vu que mon horloge était cadencé à 50k, je l'ai donc augmenté à 100k, ayant pus lire que l'I2C est au standard à 100kbs d'une part, après ceci
Je me suis noyé dans les détails mais pas encore touché le fond , c'est à dire qu'en regardant en page 102 de la doc du max, est détaillé la trame de lecture

adr slave -- mémory adress -- slave adress -- data lsb -- data msb
6C 0A 6D hh hh

Bien que je ne comprenne pas la slave adress (6D)? on vient chercher la donnée en 0A pour le courant ok
j'ai donc tenté quelque chose comme ça

#define MY_BUFFER_SIZE 50
#define MY_BUFFER_SIZE1 1

#define RTCC_SLAVE_ADDRESS1 0x6d
#define RTCC_SLAVE_ADDRESS 0x6c

char myBuffer[MY_BUFFER_SIZE1] = {10};
char rxmyBuffer[MY_BUFFER_SIZE];


DRV_I2C1_Transmit ( RTCC_SLAVE_ADDRESS,&myBuffer,M Y_BUFFER_SIZE1,NULL);
DRV_I2C1_Receive (RTCC_SLAVE_ADDRESS1,&rxmyBuff er,MY_BUFFER_SIZE,NULL);



je récupère des données dans mon rxbuffer mais pour le moment je parviens pas à les identifier .

[davidif]

Bonjour et joyeuses fêtes,

j'ai enfin réussi à faire causer mes bus I2C, tout du moins en lecture avec les librairies mplab harmony de microchip, seulement j'ai une interrogation.
Mes bus sont embarqués sur des éléments que l'on peut switcher ou retiré à chaud comme des batteries équipé du max17205.
Chaque éléments (ou batteries) possède un connecteur 6 contacts qui vient ce mettre en contact sur un contacteur à ressort câbler sur ma carte, l'ensemble est fixé sur un pack plastic prévu pour guider les contacts bien en face l'un de l'autre.
Les contacts sont agencés de tel sorte que la tension batterie de 25,2VDC ne risque pas de ce trouvé sur les bus présent sur le même connecteur car dans l'ordre ont à : +25,2 -- 0V --- SDA --- SCL

je li donc les infos de chaque canal (ou emplacement des batteries équipé)instantanément lorsque celle-ci est présente sur un afficheur LCD et ça fonctionne plutôt bien, .... que lorsque j'enlève un éléments mes données affiche 0 normal et quand je le replace mes données reprennent or ça ne le fait pas tout le temps, car je suis parfois obliger de redémarrer l'électronique pour à nouveau les voir afficher ce que je ne comprend pas mais là encore c'est moins grave car cela ressemble à un problème soft à résoudre.

Là ou je me fais plus de soucies est que j'ai quelques canaux qui ne répondent plus, même en réinitialisant ... ce qui ressemble à grillage de port et donc m'obligerai à changer le pavé du coup ... elles restent à "0" ou évidemment j'ai des pull-up sur le 3,3Vdc.
Mécaniquement, le 25,2Vdc ne peut pas ce trouver sur les bus donc je comprend pas ce qui ce passe ?...

Quelqu'un auraient une idée sur une cause éventuelle que je pourrais corriger.

Et y a t-il un moyen de protéger des bus de mon micro ? sachant que c'est du bidirectionnel .. de simple zener 3,3vdc pourraient-elles suffire ?

Merci de votre attention

[jiherve]

Bonjour,
pour faire du hot swap il faut des composants prévus pour ou, à tout le moins, une connectique assurant un semblant d'ordre dans les prises de contact:
GND d'abord, VCC ensuite et seulement après les signaux cela évite "reset" foireux et "lacth up" fumeux!
JR

[Exotique]

Tu peux (tu dois) mettre une résistance en série avec chaque ligne (100~220 ohms max) et une transil coté interne.
Ici tu trouveras une autre approche qui rejoint ce que dit jiherve (en page 4).
https://www.ti.com/lit/an/scpa058/sc...ww.ti.com%252F

[davidif]

Bonjour,
pour faire du hot swap il faut des composants prévus pour ou, à tout le moins, une connectique assurant un semblant d'ordre dans les prises de contact:
GND d'abord, VCC ensuite et seulement après les signaux cela évite "reset" foireux et "lacth up" fumeux!
JR

Oui je comprend bien lorsque j'amène 1 batterie, on pourrait ce dire qu'il y ai un problème de synchro, mais je fais les tests aussi circuit alimenté par d'autres sources, le circuit est déjà fonctionnelle lorsque je switch sur d'autres canaux donc le processus d'init est déjà établi.

[jiherve]

bonjour,
Il n'y a pas que Texas et moi pour dire çà car cela doit tomber sous le sens de tout électronicien/electricien car ce principe existe sur les prises secteur : GND First always!
JR

[davidif]

Tu peux (tu dois) mettre une résistance en série avec chaque ligne (100~220 ohms max) et une transil coté interne.
Ici tu trouveras une autre approche qui rejoint ce que dit jiherve (en page 4).
https://www.ti.com/lit/an/scpa058/sc...ww.ti.com%252F

Merci Exotique je vais voir cette solution et si je peux faire un rajout sur mon proto ce qui m'arrangerait grandement.

j'ai gardé le même schéma que sur la carte de dev côté slave


Il faudrait rajouter une résistance et une transil côté maitre ? j'ai pour le moment juste des pull-up en 3,3 de ce côté là .

à votre avis, mes I2C qui reste à 0 sont flingués ? ou autres choses m'échappent ? puis-je encore sauver mon micro (:

[davidif]

bonjour,
Il n'y a pas que Texas et moi pour dire çà car cela doit tomber sous le sens de tout électronicien/electricien car ce principe existe sur les prises secteur : GND First always!
JR

Oui ça tombe sous le sens, c'est pour cette raison, que je fais des tests circuit déjà alimenté pour le moment car pour l'instant mes contacts déjà définit qui étaient compliqué à trouvé pour mon appli sont prévu pour mon proto et ne peut en changer.

Juste un détails, ... dans mon processus d'alimentation au cas ou 1 batterie soit la seul source et que donc l'allumage de l'ensemble ce fasse simultanément du fait de mon montage actuel, le circuit numérique est d'abord alimenté et c'est les maitre donc mon micro qui commence par causé sur le bus, dans l'absolue ça ne devrait pas causé de problème ?

[jiherve]

re
le probleme du hot swap c'est l’amorçage des thyristors parasites des circuits CMOS lorsqu'une I/O se trouve portée à un potentiel excédant les tensions d'alimentations absentes ou insuffisantes, donc en général avec la tripaille actuelle Vin > VDD +0,3V ou VIN < VSS - 0,3V; Et mème sans latchup l'I/0 peut se trouver dans la situation ou la diode de clamp est sollicitée pour alimenter tout le montage encore hors tension et que celle ci et/ou le bonding n’apprécient que très peu.
JR

[Exotique]

bonjour,
Il n'y a pas que Texas et moi pour dire çà car cela doit tomber sous le sens de tout électronicien/electricien car ce principe existe sur les prises secteur : GND First always!
JR

C'était vrai, maintenant il y a d'autre solutions.
Pour le secteur c'est juste une question de sécurité, c'est différent

Le hotswap en I2C n'est pas quelque chose de souhaitable sans prendre des précautions hardware mais aussi logicielle.
Un soft mal foutu va attendre longtemps un ACK qui ne viendra jamais ou une écriture en EEPROM qui échouera avec les conséquences que ça peut avoir.
Mieux vaut prévoir une sécurité au débranchement qui mette l'I2C au repos proprement.

[Exotique]

à votre avis, mes I2C qui reste à 0 sont flingués ? ou autres choses m'échappent ? puis-je encore sauver mon micro (:

Essaye de modifier ton code et fais juste alterner tes sorties de 0 à 1 sur SCL et SDA pour voir si ils réagissent.
Si ça ne bouge pas c'est mauvais signe...
Sinon il se peut aussi que ton code soit perdu dans une boucle infinie.
Tu as fait un reset?

[jiherve]

re
nous sommes d'accord!
JR

[davidif]

Oui un ACK qui ne viendra jamais, j'y ai pensé aussi, donc ajouter un time_out mais au moins quand on rallume ça repart c'est moins grave mais un canal qui repart pas c'est plus compliqué.

Je comprend qu'il fasse faire les choses proprement et dans l'ordre ce que je vais m'attarder à revérifier mais j'ai mesuré la petite électronique embarqué sur les batteries qui est évidemment en permanence sous tension, tout au moins tant que la batteries a un résiduel de tension acceptable pour le max17205, en mesurant les contacts, je suis bien à "0" sur les SDA et SCL déconnecté, donc dans l'ordre des choses, dès que je place tout au moins la 1er batterie, celle-ci alimente mon circuit numérique avant de causé sur l'i2c qui est initié par mon micro une fois reseter, donc si je dis pas de bêtises, mon micro ne reçoit pas de tension sur ces I/O avant le processus d'allumage de celui-ci ?

[davidif]

Essaye de modifier ton code et fais juste alterner tes sorties de 0 à 1 sur SCL et SDA pour voir si ils réagissent.
Si ça ne bouge pas c'est mauvais signe...
Sinon il se peut aussi que ton code soit perdu dans une boucle infinie.
Tu as fait un reset?

Oui je vais faire le test, merci
un reset, il suffit de redémarrer oui mais mon canal concerné est toujours à zéro

[davidif]

Essaye de modifier ton code et fais juste alterner tes sorties de 0 à 1 sur SCL et SDA pour voir si ils réagissent.
Si ça ne bouge pas c'est mauvais signe...
Sinon il se peut aussi que ton code soit perdu dans une boucle infinie.
Tu as fait un reset?

Bon bah, je pense qu'un port I2C du micro est définitivement perdu ... j'ai tenté de les mettre à 1 en sortie digital et ça ne répond pas, je vais donc devoir changer le pavé
j'ai vu le TCA9511A que je prévoirai sur les prochains mais avant je vais suivre ton conseil moins compliqué à mettre en oeuvre, mettre une transil et résistance de 150 ceci



En espérant que sa suffise.
D'ailleurs, en y regardant de nouveau, la transil serait mieux de l'autre côté des 150, sur les port du micro.

Aussi j'ai regardé le code envoyé par le support maxim pour envoyer les registres de configue, histoire de comprendre ou lister les données nécessaire à écrire

typedef struct
{
	uint16_t PckCf; //configuration 
	int      Rsen;  //value of Rsense milliohm
	float    Vemp;  //(V) Empty voltage per cell
	int      DesCap;// cell size mAh
	uint16_t CellNo;// cell number
}EZ_setting;


int Max17205_EZ_Mode(EZ_setting cfg)
{
	uint16_t temp_cap,temp_cnf, temp_sens, temp_vem,temp;
	int retries;
	temp_cap=(uint16_t)(cfg.DesCap/2);
	temp_cnf=cfg.PckCf;
	temp_sens=(uint16_t)(cfg.Rsen*100);
	temp =ReadRegistor(nVEmpty); //read out the VE &VR
	temp=temp&0xf8;//protec VR
	temp_vem=((uint16_t)(cfg.Vemp*100)<<7)|temp;
	
	retries=WriteVerifyReg(nPackCfg,temp_cnf);     		 //#define nPackCfg    ((uint16_t)0x01B5)//?? 				 page 1Bh   Addr 16:B5
	retries=retries+WriteVerifyReg(nRSense,temp_sens); 	 //#define nRSense     ((uint16_t)0x01CF)//No Nonvolatile	 page 1Ch   Addr 16:CF
	retries=retries+WriteVerifyReg(nVEmpty,temp_vem);    //#define nVEmpty     ((uint16_t)0x019E)//??				 page 19h   Addr 16:9E
	retries=retries+WriteVerifyReg(nDesignCap,temp_cap); //#define nDesignCap  ((uint16_t)0x01B3)//??				 page 1Bh   Addr 16:B3 
	delay_ms(100);
  return retries;
}


int WriteVerifyReg( uint16_t reg, uint16_t value)
{
	int flag;
	int retries = 0;	 
	uint16_t read_value=0;
  do {
       WriteRegistor (reg, value);
       delay_ms(1); //wait
       read_value = ReadRegistor (reg) ;
	   retries++;
     }
 while ((value != read_value) && retries<4);
 if (value == read_value)
	 flag=0;
 else
	 flag=1;
 return flag;
	
}


void ez_mode_set()
{
	int retry;
	EZ_setting ez_cfg;
	//TFT_ClearScreen(BLACK);
	retry=4;
	//GUI_Show12ASCII(10,200,"Loading...",YELLOW,BLACK);

	ez_cfg.CellNo=0x0005; //5cells  pour moi 7cells donc 0x007 
	ez_cfg.DesCap=1500; //mAh       pour moi 9000
	
	//#define  Pck_High_Cell_N   ((uint16_t)0x3900)//High-Cell Count Pack   ok
	//#define Pck_En_TdEn        ((uint16_t)0x0800)//Die temp enable   		?
	//ez_cfg.CellNo=0x0005; //5cells
	ez_cfg.PckCf=(Pck_High_Cell_N|ez_cfg.CellNo|Pck_En_TdEn);  
	ez_cfg.Rsen=10;//milliohom								   
	ez_cfg.Vemp=3.3;// moi ce sera 3.6V
	
	do{
		retry=Max17205_EZ_Mode(ez_cfg);
	}
	while(retry!=0);
	delay_ms(100);
	Max17205_Reset_Chip();
    //GUI_Show12ASCII(10,250,"Done!",YELLOW,BLACK);
}




void Max17205_Reset_Chip()
{
	WriteRegistor(0x060, 0x000f);//POR IC
	delay_ms(200);
	WriteRegistor(0x0bb, 0x0001);//Reset firmware
	delay_ms(200);
}

Et d'après se que je comprend

on doit envoyé

le pack config
le rsense donc 10m
nvempty ou tension d'une cellule 3.6v
designcap capacité de 9000mA
nombre de cellule donc 7 pour moi

[davidif]

Bonjour,

Merci pour vos explications, cependant une chose m'échappe en rapport avec mes problèmes de claquage du port I2C sur mon micro (pas sur les max17205, composant I2C embarqués) et n'arrive pas trop à comprendre ou identifier l'instant critique.

En fait, les moments critiques seraient lorsque mon micro non encore alimenté au moment de recevoir des trames si j'ai bien compris or mon système accepte 4 batteries chacune embarquant un composants discutant sur le port I2C.

Dans ma chronologie, la première batterie alimente l'ensemble, dont mon micro qui début une com avec la 1er batteries donc pas de soucie après j’insert la 2ième mais là le micro est déjà alimenté -- jusqu'à la 4ième donc la il devrait pas avoir de soucis ?

Si j'en retire une, le circuit reste alimenté et la dernière éteint l'ensemble.

au début, j'avais tendance à éteindre l'alimentation du micro pour le redémarrer lorsque j'avais de la com de perdu et ainsi resynchroniser les bus, batteries en place d'ou peut-être des retours de com pas terrible pendant cette transition, maintenant je fais juste un reset du micro sans l'éteindre en espérant que ce soit moins destructeur normalement.

aussi, j'ai rajouté côté pic des 100 Ohm plus transil 3.3v en espérant que tout ça soit suffisant.


Bonne journée