Détection Court-circuit sur sonde DS18B20

[RATAXES64]

Bonjour à tous,

Ah! les souris dans les chaufferies! Grignotage d'un câble de sonde DS18B20 ayant conduit à un court-circuit entre fil Data et fil de masse (Vss)... Comment le détecter ?
Un tel court-circuit se traduit par une "valeur" figée le plus souvent comprise entre -5 et +5, et donc sur une valeur qui peut être "normale" notamment pour la sonde mesurant la température extérieure.
On pourrait envisager de scruter si une variation se produit sur une période donnée , mais les variations de températures sont pour la plus part extrêmement lentes... parfois stables plus d'une heure! C'est beaucoup trop.

Si on écarte la scrutation de la variation, je suppose que ce court-circuit Data/Vss devrait rendre l'identification de la sonde impossible...
J'ai l'intuition que c'est alors via OneWire_.h et OneWire_c que ça se passe (unsigned char onewireCRC(unsigned char* addr, unsigned char len); void Relecture_Current_ID_datas(voi d); ...)
Quelqu'un a-t-il déjà exploré une telle piste, voire proposé un code pour traiter ce genre d'incident sur ces sondes DS18B20 ?

Pour info, mes 3 sondes ne sont pas en bus, mais chacune affectée à un port dédié au MCU (longueur de câble = 15m, résistance pull-Up = 4k7)

Merci de votre aide.
-----

[antek]

En considérant ce schéma je suis incomprenant du problème

[RATAXES64]

Bonjour,
Le schéma du montage des Sondes, avec en rouge le court-circuit accidentel à détecter :

[antek]

Tu configures RA2 en entrée comparateur ou en entrée GPIO, à un moment où une émission du DStruc n'est pas attendue.
Si pas possible il faudra ajouter un circuit.
Autre option : j'ai pas compris le problème !

[A voir en vidéo sur Futura]

[RATAXES64]

Bonjour,
Inputs data des sondes en RA0, RA1, RA2 du PIC
Si effectivement un court-circuit à Vss d'une entrée Data "empêche" une lecture correcte de l'ID de la sonde concernée : Quel(s) code(s) "retournerai(en)t quelque chose" d'exploitable permettant d'identifier l'anomalie...?
Dans OneWire.h, j'ai laissé commenté void Relecture_Current_ID_datas(voi d);
Mais je ne suis pas du tout sûr que ce soit par là qu'il faille creuser...

Pour info, le code dans OneWire.h

//https://raw.githubusercontent.com/simonbarker/pic-libraries/master/onewire.h
#ifndef ONEWIRE_H_   /* Include guard */
    #define ONEWIRE_H_
    #define _XTAL_FREQ 64000000
    //onewirePin defines
    #define onewirePin PORTAbits.RA0
    #define onewirePinDirection TRISAbits.TRISA0 //0 = output, 1 = input
    #define onewirePin1 PORTAbits.RA1
    #define onewirePinDirection1 TRISAbits.TRISA1 //0 = output, 1 = input
    #define onewirePin2 PORTAbits.RA2
    #define onewirePinDirection2 TRISAbits.TRISA2 //0 = output, 1 = input

    void onewireWriteBit_X(int b);
    void onewireWriteBit_0(int b);
    void onewireWriteBit_1(int b) ;
    void onewireWriteBit_2(int b) ;

    unsigned char onewireReadBit_X();
    unsigned char onewireReadBit_0();
    unsigned char onewireReadBit_1();
    unsigned char onewireReadBit_2();
    unsigned char onewireInit_X();
    unsigned char onewireInit_0();
    unsigned char onewireInit_1();
    unsigned char onewireInit_2();
    unsigned char onewireReadByte_X();
    unsigned char onewireReadByte_0();
    unsigned char onewireReadByte_1();
    unsigned char onewireReadByte_2();

    void onewireWriteByte_X(char data);
    void onewireWriteByte_0(char data);
    void onewireWriteByte_1(char data);
    void onewireWriteByte_2(char data);

    unsigned char onewireCRC(unsigned char* addr, unsigned char len);
    //void Relecture_Current_ID_datas(void);
#endif

[antek]

Pour le code, je ne vais pas me mettre aujourd'hui aux 18F

[umfred]

heureusement que sur le schéma on voit que c'est commander par un PIC18F, sinon on n'avait pas l'info.
De même pour la librairie OneWire, où l'as-tu trouvé ? (si je me base sur le lien en haut de ton code ça serait là https://github.com/simonbarker/pic-l...ster/onewire.h mais le fichier n'est pas du tout identique)

Pour le problème de détection du court-circuit sur le DS18B20, peut-être faire une écriture/relecture d'une donnée dans le Scratchpad du composant ou tout autre commande dont la réponse ne serait pas OK.
Pour le faire avec les fonctions que tu nous indiques, plonge toi dans la doc du DS18B20 pour savoir quoi envoyer (avec les fonctions writebyte pour envoyer les bonnes commandes et les ReadByte pour lire le retour (si il y en a) ). après tu as peut-être des fonctions de plus haut niveau dans un fichier DS18B20.c/.h de ton projet)

D'ailleurs, en 1-Wire, un court-circuit à la masse de la ligne de Data, rien ne devrait se passer, car le DS18 ne voit pas passer de commande, et le maitre (le PIC) ne voit pas de retour à 1 de la ligne donc ne devrait pas engager de communication.
(et les 3 sondes pourraient être sur la même ligne de communication).

[RATAXES64]

mais le fichier n'est pas du tout identique
tu as peut-être des fonctions de plus haut niveau dans un fichier DS18B20.c/.h de ton projet

Oui, j'ai indiqué le code OneWire.h bâti à partir du lien, et n'ai pas joint les fichiers OneWire.c et DS18B20.c/.h pour ne pas trop charger ma demande...

En 1-Wire, un court-circuit à la masse de la ligne de Data, rien ne devrait se passer, car le DS18 ne voit pas passer de commande, et le maitre (le PIC) ne voit pas de retour à 1 de la ligne donc ne devrait pas engager de communication.

Effectivement, rien ne devrait passer... mais l'entrée du PIC voit bien quelque chose qui est traduit par une 'mesure' autour de 0 (+/-5)... fixe, certes, mais potentiellement normale

Pour le problème de détection du court-circuit sur le DS18B20, peut-être faire une écriture/relecture d'une donnée dans le Scratchpad du composant ou tout autre commande dont la réponse ne serait pas OK.
Pour le faire avec les fonctions que tu nous indiques, plonge-toi dans la doc du DS18B20 pour savoir quoi envoyer (avec les fonctions writebyte pour envoyer les bonnes commandes et les ReadByte pour lire le retour (si il y en a) ).

Oui, umfred, et merci de cette réponse claire : on est bien d'accord que c'est finalement la seule solution.
Sauf que Savoir quoi envoyer...pour lire le retour : C'est justement ce que je voudrais faire mais ... ne sais pas faire...

[umfred]

Comment tu fais pour lire ta température ?
et comme je l'ai dit, c'est dans la doc du DS18B20 pour les différentes commandes et tu as le code pour récupérer la température dans le fichier DS18B20.c qui peut te servir d'exemple.

En gros, c'est exactement la même chose que les fonctions getTemperature, sauf que tu lis d'autres octets du scratchpad (si tu optes pour la lecture de celui-ci)
Sinon faire la lecture du code en ROM (que tu peux faire car tu n'as qu'un DS18 par ligne de data) et dans ce cas là, la commande change de valeur (0x33) et tu n'aurais besoin de vérifier que le 1er octet (LSB) dont la valeur devrait être 0x28 (code famille des DS18B20).
lien de la doc (au cas où) https://www.gotronic.fr/pj2-ds18b20-3090.pdf

[RATAXES64]

Comment tu fais pour lire ta température ?

Extrait du code DS18B20.c (fourni par paulfjujo)

#include <xc.h>
#include <pic18f27k42.h>
#include "DS18B20.h"
#include "OneWire.h"
#define AVEC_TEMPO
extern void PrintChar(unsigned char txData);
uint16_t Lx;
unsigned char scratchPad[9] = {0,0,0,0,0,0,0,0,0};

void broadcastConvert_X() 
{
    //broadcast that temp conversions should begin, all at once so saves time
    onewireInit_X();
    onewireWriteByte_X(0xCC);
    onewireWriteByte_X(0x44);
    while (1) 
    {
        if (onewireReadBit_X())  // au moins 1 capteur connecté
        break;
    }
}

float getTemperature1() // Température Intérieure
{
    unsigned char i;
    float temperature0;
    onewireInit_0();
    onewireWriteByte_0(0xCC);
    onewireWriteByte_0(0x44);
    __delay_ms(100);   // was 10
    onewireInit_0();
    onewireWriteByte_0(0xCC);
    onewireWriteByte_0(0xBE);
    for (i = 0; i < 2; i++)  scratchPad[i] = onewireReadByte_0();
    onewireInit_0();
    Lx=(scratchPad[1] <<8)+ scratchPad[0];
    temperature0 = (float)Lx * 0.06250; // Resolution;
    return temperature0;
}

float getTemperature2() // TempératureExtérieure
{
    unsigned char i;
    float temperature1;
    onewireInit_1();
    onewireWriteByte_1(0xCC);
    onewireWriteByte_1(0x44);
    __delay_ms(100);
    onewireInit_1();
    onewireWriteByte_1(0xCC);
    onewireWriteByte_1(0xBE);
    for (i = 0; i < 2; i++)  scratchPad[i] = onewireReadByte_1();
    onewireInit_1();
    Lx=(scratchPad[1] <<8)+ scratchPad[0];
    temperature1 = (float)Lx * 0.06250; // Resolution;
    return temperature1;
}

float getTemperature3() // Température Eau Chaudière
{
    unsigned char i;
    float temperature3;
    onewireInit_2();
    onewireWriteByte_2(0xCC);
    onewireWriteByte_2(0x44);
    __delay_ms(100);
    onewireInit_2();
    onewireWriteByte_2(0xCC);
    onewireWriteByte_2(0xBE);
    for (i = 0; i < 2; i++)  scratchPad[i] = onewireReadByte_2();
    Lx=(scratchPad[1] <<8)+ scratchPad[0];
    temperature3 = (float)Lx * 0.06250; // Resolution;
    return temperature3;
}

Sinon faire la lecture du code en ROM (que tu peux faire car tu n'as qu'un DS18 par ligne de data) et dans ce cas là, la commande change de valeur (0x33) et tu n'aurais besoin de vérifier que le 1er octet (LSB) dont la valeur devrait être 0x28 (code famille des DS18B20).

Merci pour le lien qui pointe vers la même Datasheet que celle que j'ai, et effectivement la commande : Read Rom [33h] est adaptée à ma configuration hard, sauf que je n'ai aucune idée de comment coder pour valider l'intégrité de sonde.

En tout cas, merci de ces réponses qui me confirme aller dans une direction prometteuse, même si c'est pour le moment hors de mes compétences

[umfred]

Aie Aie quand je vois le code que tu fournis.
copier-coller de la fonction d'origine avec l'ajout d'un chiffre derrière et je comprends pourquoi c'est pareil dans OneWire, on aurait peut-être pu factoriser un peu tout ça mais bref (en plus, il y a une incohérence qui peut être trompeuse: fonction getTemperature1 utilise les fonctions onewire "0" pourquoi ne pas avoir au moins donner le même chiffre .....

pour rester dans l'esprit donc, une version qui ne vérifie que le type de ROM (octet 0 lu par la commande, mais on pourrait aussi regarder le CRC

unsigned char isDSRomOk1() // test si Rom Ok de la sonde 1
{
    unsigned char i;
    onewireInit_0();
    onewireWriteByte_0(0x33);
    for (i = 0; i < 8; i++)  scratchPad[i] = onewireReadByte_0();
    onewireInit_0();
    return (scratchPad[0]==0x28); // la fonction retourne 1 (true) si les valeurs sont identiques, et 0 (false) si les valeurs sont différentes
}

Donc si tu veux le faire pour chacune des lignes, à recopier comme c'est fait pour les autres fonctions.
Et à toi de voir ce que tu veux faire du résultat.

PS: je viens de remarquer qu'il manque l'appel onewrieInit_2() après la lecture des octets dans getTemperature3()

[RATAXES64]

Aie Aie quand je vois le code que tu fournis.
copier-coller de la fonction d'origine avec l'ajout d'un chiffre derrière et je comprends pourquoi c'est pareil dans OneWire, on aurait peut-être pu factoriser un peu tout ça mais bref (en plus, il y a une incohérence qui peut être trompeuse: fonction getTemperature1 utilise les fonctions onewire "0" pourquoi ne pas avoir au moins donner le même chiffre .....

Oui, effectivement, lever cette incohérence d'index serait plus adéquate

on pourrait aussi regarder le CRC

Cela a été tenté, mais on a des retours CRC qui correspondent des valeurs de mesure "normales", comme par exemple :
=> fil mesure Sonde1 relié au Gnd
=> Lecture Adresse MAC via cde 0x33
> retour init ows : 0x01
> Family Code : 0x00
> ID= 000000000000 ID CRC= 00
> Tx = 0.000 ° C
En revanche, le Family Code est 0x00... donc c'est bien lui qu'il faut prendre en compte, et non CRC

PS: je viens de remarquer qu'il manque l'appel onewrieInit_2() après la lecture des octets dans getTemperature3()

Oups! Bien vu ; je corrige

Pour la sonde 2, ça donnerait ça ?

unsigned char isDSRomOk2() // test si Rom Ok de la sonde 1
{
    unsigned char i;
    onewireInit_2();
    onewireWriteByte_0(0x33);
    for (i = 0; i < 8; i++)  scratchPad[i] = onewireReadByte_0();
    onewireInit_2();
    return (scratchPad[0]==0x28); // la fonction retourne 1 (true) si les valeurs sont identiques, et 0 (false) si les valeurs sont différentes
}

Bref, ça avance! Merci encore pour tout

[umfred]

Si tu as renommé les fonctions dans onewire.c pour être cohérent au niveau des numéro, oui (sinon il faut le décalage) et met à jour le commentaire avec le nom de ta sonde pour que ce soit plus facile pour toi à t'y retrouver.

[RATAXES64]

Autre observation...
Si c'est le fil d'alim qui est coupé, la sonde passe en Mode Parasite, et donc on aura un retour correct du Family Code .
Certes (espérons!), la sonde continue de fonctionner correctement sous ce mode, mais on ne sait pas que le fil d'alim a été coupé. Et là, je ne vois pas de solution, d'autant que l'on n'a aucune info du 'retour' que pourrait fournir le POWER-SUPPLY SENSE intégré à la sonde (et donc inaccessible physiquement)

[RATAXES64]

Hééé non! Comme quoi, il faut toujours relire et relire encore un datasheet...
In some situations the bus master may not know whether the DS18B20s on the bus are parasite powered or powered by external supplies. The master needs this information to determine if the strong bus pullup should be used during temperature conversions. To get this information, the master can issue a Skip ROM [CCh] command followed by a Read Power Supply [B4h] command followed by a “read time slot”. During the read time slot, parasite powered DS18B20s will pull the bus low, and externally powered DS18B20s will let the bus remain high. If the bus is pulled low, the master knows that it must supply the strong pul
Donc, si je comprends bien, il serait possible de savoir si le fil d'alim est coupé ? si on peut récupérer l'info ...

[umfred]

A vérifier, car normalement, en mode alimentation parasite, le Vdd devrait être à la masse.
En combinant la lecture du mode d'alimentation et le code famille, on devrait pouvoir s'en sortir pour détecter une anomalie

[RATAXES64]

A vérifier, car normalement, en mode alimentation parasite, le Vdd devrait être à la masse.
En combinant la lecture du mode d'alimentation et le code famille, on devrait pouvoir s'en sortir pour détecter une anomalie

Euh, la question c'est surtout de pouvoir récupérer une info que la commande Read Power Supply [B4h] + read time slot fournirait...
Il est seulement indiqué During the read time slot, parasite powered DS18B20s will pull the bus low ; Si je ne me trompe pas, cela signifierait que si l'alim VDD n'est pas fournie à la sonde, RA0 au Pic serait forcé à l'état bas pendant la durée du read (Aucune idée d'ailleurs de cette durée...) ; et ce serait un moyen d'identifier l'anomalie telle que ci-dessous ?


J'aurais aimé pouvoir présenter, au moins en partie, le code correspondant pour vérifier, mais, découvrant le 'C' depuis quelques mois seulement, mes tentatives à ce niveau restent encore lamentablement nulles.

A suivre...

[umfred]

Durant la période de lecture d'un bit (read time slot), si le maitre lit un 0, alors il y a composant qui fonctionne en mode parasite, si le maitre lit un 1, alors, il n'y en a pas.

Le mode alimentation parasite est défini actif dans la doc quand Vdd est relié à GND. Quand Vdd est en l'air, il n'est pas relié à GND, donc, a priori, il peut être à n'importe quel potentiel. et donc, je ne saurai dire avec certitude que le composant entre en mode alimentation parasite (d'ailleurs, je ne sais pas si il peut switcher d'un mode d'alimentation à un autre en cours de route, à mon avis, non; au mieux, il faudrait refaire une initialisation du bus je pense, mais là encore, ce n'est qu'une supposition. )

Donc si la coupure fait qu'il n'est plus alimenté (donc qu'il n'est pas passé en mode alimentation parasite), il n'y aurait aucune raison qu'il passe à 0 sa ligne data, et donc que le maitre le voit alimenté en mode parasite; mais la lecture de la ROM donnerait 0x00 ... comme dans le cas précédent.

Pour moi, il faut tester.

Pour le code dont tu as besoin, tu as les fonctions de base (ce n'est pas compliqué de savoir ce qu'elles font, leur nom est suffisamment parlant il me semble), et tu peux t'aider de l'organigramme dans la doc (page 13 et 14) pour voir ce qu'il faut faire.

[RATAXES64]

"Pour moi, il faut tester"
Test :
=> Coupure du fil d'alim : plus d'alim en Pin VDD de la sonde, qui reste "en l'air"
=> Et pourtant, avec Pin VDD "en l'air", la sonde réagit normalement...
=> Donc je suppose qu'elle est en Alim Mode Parasite... via la 4k7 (aussi pull-up pour RA0 du PIC)
=> J'appelle le Family Code, et il m'est retourné correctement ; Pas de 0x00! donc la sonde est bien reconnue présente et fonctionnelle...

Je n'ai pas le matos qu'il faudrait pour tenter de "voir" ce qui ce passe sur le Data à la coupure de l'alim, ou au lancement de la commande Read Power Supply [B4h] + read time slot (que je n'arrive toujours pas à coder : je commence à avoir honte là! Je vais continuer à chercher pour au moins ne solliciter une aide qu'à partir de quelque chose, même abscond).
Certes tant que je n'ai pas pu tester complètement je n'affirmerais rien, mais j'ai moi aussi les mêmes gros doutes...

Par ailleurs, j'ai tenté d'augmenter la R-pull-Up au plus haut : 47k (cette R est aussi en pull-up pour le port du PIC!), et même pour cette valeur, la sonde marche toujours sans alim en Pin VDD... il est vrai, pour une longueur de câble plus courte (OK pour mes 2 sondes de 5m, mais pas celle de 15m).

Ce qui est étonnant, c'est que pour ce risque majeur avec une alim "normale" (et d'ailleurs recommandée pour des mesures > 100°C), le fabricant n'a (n'aurait, soyons prudent) rien prévu ; Même sur un câble de 15m, la sonde n'y voit que du feu...
Sauf que... si, justement on veut mesurer des T°C > 100°C, on est hors cadre des recommandations faites au Datasheet.

[RATAXES64]

Bonsoir,
Décidément mes débuts en C me donnent beaucoup de mal...
Je n'arrive toujours pas à intégrer correctement les lignes de code données par umfred il y a maintenant plus de 10 heures.
Après maintes tentatives que je vais vous épargner, vous me pardonnerez d'oser vous indiquer la dernière (qui n'est toujours pas correcte) et solliciter un guidage pour avancer sans tourner en rond...

//Dans DS18B20.c
//----------------------
unsigned char isDSRomOk1() // test si Rom Ok de la sonde 1
{
    int DS1RomOk;
    unsigned char i;
    onewireInit_0();
    onewireWriteByte_0(0x33);
    for (i = 0; i < 8; i++)  scratchPad[i] = onewireReadByte_0();
    onewireInit_0();
    if (scratchPad[0]==0x28) DS1RomOk=1; else DS1RomOk=0;
    return DS1RomOk; // la fonction retourne 1 (true) si les valeurs sont identiques, et 0 (false) si les valeurs sont différentes
}

//Dans main.c
//----------------------
int DS1RomOk;
//----------------------
if(DS1RomOk==1) sonde1=1; else sonde1=0 // 1 => OK ; 0 => HS
//----------------------
// visu sur LCD
sprintf(CRam1,"%d    ",DS1RomOk);
Print(CRam1); 
LCD_Write_Text_At(1,1,CRam1);  // Affiche toujours 0 ???!

Bien entendu, la sonde1 est parfaitement connectée et pleinement opérationnelle...
Sauf que...ça me dit le contraire : retourne 0 au lieu de 1...

Il parait que la nuit porte conseil... Je verrai demain!
A+

[paulfjujo]

bonjour,

....
..... copier-coller de la fonction d'origine avec l'ajout d'un chiffre derrière

... parce qu'il y a un bus OWS par capteur.! et inutile de multiplexer ou compliquer quand on a de la place dans le MCU ..
Au depart du projet on etait avec les 3 capteurs sur 1 seul bus
...modifié pour pour éviter une gestion de Mac adresse , et faciliter l'interchangeabilité de sonde.

.... (en plus, il y a une incohérence qui peut être trompeuse: fonction getTemperature1 utilise les fonctions onewire "0" pourquoi ne pas avoir au moins donner le même chiffre .....

Je rappelle que le reperage bas niveau comme onewireInit(0); pour la sonde #1
est dù au fait qu’en bas niveau de programmation, on travaille sur des registre MCU de RA0 ( TRISA0 ,PORTA0, LATA0..)
qui commence à 0 et non 1 ...
l’eternelle difference entre le software qui compte à partir de Zero et l’humain qui compte à partir de 1
La difference reste quand meme estompée par l’usage de fonction designant bien la sonde 1 , 2, ou 3.
Toute verité sur une prise de choix depend du contexte qu’il ne faut pas oublier.
Si le cablage des sondes avait été sur RA1,RA2,RA3 on n’aurait aucune remarque à ce sujet.

[umfred]

Dans l'absolu, il aurait pu n'y avoir qu'une fonction à laquelle on passerait le numéro de sonde et selon ce numéro, on agirait sur la bonne ligne.
J'ai compris plus le choix en lisant mieux le code, mais on aurait pu harmoniser les numéro des fonctions 0,1,2 pour sonde 0,1,2, ou fonctions 1,2,3 pour sonde 1,2,3, c'est moins "perturbant" d'utiliser le même numéro de la sonde dans une fonction qui traite de la sonde. A la relecture du code, on se pose moins de questions sur pourquoi dans la fonction qui récupère la température de la sonde 1, j'appelle une fonction 0 (ou alors nommé la fonction en fonction de la zone de la sonde). Comme c'est un humain qui lit le code, il faut que ça lui parle à lui aussi.

Mais bref, ce n'est qu'un problème de nommage, du moment que ça fonctionne.
J'avoue aussi que j'aurai sans doute fait comme ça aussi (un ensemble de fonction par sonde) au début pour ne pas trop réfléchir à comment factoriser.

@RATAXES64
La variable DS1RomOk qui se trouve dans la fonction isDSRomOK1() n'est visible que dans cette fonction et est donc différente de celle que tu as déclaré dans le main.
Pour récupérer la valeur, il faut appeler la fonction dans le main et la mettre dans une variable (celle que tu as déclaré dans le main par exemple).

Pour les autres fonctions, je t'encourage à regarder ce que font les fonctions (getTemperature, ...) et de regarder en parallèle les organigrammes des pages 13 et 14 de la doc et également les exemples de la page 18; tu verras que la fonction suit la logique de l'organigramme (qui décrit comment le DS traite les commandes qu'il reçoit):

avec getTemperature on veut récupérer la température, donc il faut la commande Convert T (0x44) pour demander une mesure et lire le résultat dans le scratchpad, donc commande Read ScratchPad (0xBE) et lire les octets du scratchpad.

Dans l'organigramme, on voit que pour utiliser la commande Convert T, il faut passer par une autre commande auparavant, l'exemple 1 qui adresse un DS particulier passe par la commande 0x55 (Match ROM) pour adresser le bon DS; chez nous, pas d'intérêt, donc ce sera la commande Skip ROM (0xCC) (pas besoin d'adresser, on a un seul DS par ligne); Ensuite, page 14, la commande Convert T arrive dans une boucle d'attente de mesure qui retourne à la phase de séquence d'initialisation pour effectuer un nouveau transfert. Ce qui nous amène à notre 2nde commande, et comme précédemment, on commence par l'envoi du Skip ROM avant la commande de Read Scratch, et l'on voit qu'on a à nouveau une boucle dans laquelle le maitre doit lire un octet, la transaction peut s'arrêter si le maitre envoi un RESET après la réception d'un octet, ou on poursuit l'envoi des octets jusqu'au CRC.

Si on regarde maintenant la fonction, on voit le cheminement décrit au dessus par l'utilisation des fonctions de base.

PS1: petite coquille dans ton code, il manque le point virgule à la fin de la ligne (après la dernière instruction)

if(DS1RomOk==1) sonde1=1; else sonde1=0;

PS2: tu dis débuter en C, ok, mais tu connais d'autres langages quand même ? si oui, les principes restent "globalement" les mêmes (avec des variations certes)(fonctions, paramètres de fonction, retour de fonction, portée des variables, ...) ; si débutant en programmation, je comprends mieux et que ma petite explication aidera à la compréhension du cheminement.