Le protocole 1-Wire et la commande Search ROM

[invite3d2336a7]

Bonjour,

Je me suis un peu penché sur la fonction qui permet de lister les adresses connectées sur un bus 1-Wire, mais qque chose m'interpelle.
Si je comprend bien la fonction search va scanner tout les participants du bus et permettre de lister leurs adresses, mais en aucun cas, il ne permet de savoir quel participant dispose de quelle adresse...

Donc pour le système d'identification i-Button de Dallas ou leur puce mémoires, ce n'est pas trop grave, mais dans le cas de leurs très connues sonde de température DS18B20, c'est problématique je trouve. Si je place 10 sonde sur le même bus, je ne saurais jamais quelle sonde me donne quelle température...

Suis je dans le bon ou j'ai loupé qque chose ?

Merci pour vos réflexions
Jo
-----

[invitee05a3fcc]

je ne saurais jamais quelle sonde me donne quelle température...

Effectivement ....
Tu peux identifier la sonde et son identifiant de trois manières :
- Tu laisses une seule sonde sur le bus et tu notes son identifiant
- Tu débranches une sonde sur le bus et tu notes l'identifiant de celle qui disparait
- Tu chauffes une sonde sur le bus et tu notes l'identifiant de celle qui change

[invite3d2336a7]

Merci Daudet,
C'est bien ce que je craignais. C'est pas bien méchant, mais dommage.

[invite3d2336a7]

Je vais pousser le bouchon un peu plus loin, mais avec une orientation de stockage.
Je fais comment pour créer un tableau qui va contenir toutes les adresses sans savoir à l'avance combien de capteurs je vais avoir.
Ou si je décide d'en rajouter par la suite.

Ma première piste serait dans la fonction Search, d’abord calculer combien de capteurs sont présent et ensuite faire un malloc avec le nombre de ligne nécessaires.
Si j'ajoute un capteur, je détruit le tableau et je recommence.

J'aime pas trop cette idée car cela prendrait un temps bête en ressource et si j'ajoute un capteur, je détruit le travail déjà fait.

Il y a une autre solution ?

[A voir en vidéo sur Futura]

[invite3d2336a7]

Je vois la solution de la mémoire externe... EEPROM, Flash, fichier, etc. mais rien de "temporaire"

[invitee05a3fcc]

Ca sert à quoi ton assortiment de capteurs ?

[invite3d2336a7]

Ben dans ce cas précis, je voudrais mesurer les variations de température sur une hauteur de 3m. Donc une tige de 3m avec une dizaine de capteurs.
Mais quand je développe une librairie, j'aime qu'elle soit complète afin de ne plus me poser la question au prochain usage...
Imaginons que plus tard, je décide de mettre une seconde batterie de capteurs...

[invitee05a3fcc]

je décide de mettre une seconde batterie de capteurs...

Tu mets un second bus OneWire ....

[invite3d2336a7]

Tu mets un second bus OneWire ....

Oui, mais ca, c'est la solution de facilité...
Je pourrait aussi mettre un capteur par patte de mon µC.

Cela ne répond pas à la problématique initiale.

[adipie]

Bonjour,
Je relève l'adresse de chaque capteur et je la stocke dans la zone Eeprom avec un pas de 8.
Puis à l'init je copie toutes les adresses avec un boucle For dans une variable indicée.
En cas d'ajout d'un capteur il suffit de stocker la nouvelle adresse dans l'Eeprom et d'adapter le nombre de boucles.

[invitee05a3fcc]

J'ai trouvé une N.A. intéressante : https://www.maximintegrated.com/en/a...ex.mvp/id/4037

[invite3d2336a7]

Hummm intéressant ces pistes...
Entre temps, j'avais pensé à autre chose. Est il envisageable de définir un endroit dans la mémoire assez éloigné afin de supposer que rien ne viendra s'y incruster et de stocker les données là ?
On peut alors espérer que j'ai la place en fonction de la mémoire max - l'endroit ou je débute et j'incrémente mon pointeur en fonction...

Je vais me pencher sur vos solutions.

[invitee05a3fcc]

Une autre solution plus géniale !
Dans le DS18B20, tu as deux registres 8 bits non volatiles dans la scratchpad en #2 et #3 .

Dans un p'tit montage de personnalisation :
- tu écris 1 dans le registre #2 du capteur 1
- tu écris 2 dans le registre #2 du capteur 2
- tu écris 3 dans le registre #2 du capteur 3
- etc

Tu mets tes 8 capteurs en chaine
Tu détectes les 8 identifiants
Sur le premier identifiant trouvé, tu viens lire le registre #2, si c'est 5, c'est le cinquième capteur !

PS : par sécurité, tu mets le numéro du capteur dans #2 (par exemple 00000101 soit 5) et son inverse dans #3 (11111010) . Si tu trouves ces valeurs, c'est bon, sinon, c'est un capteur non initialisé . The Must !

[invite3d2336a7]

Oui, en effet, ça peut être une bonne idée si on prend la peine de créer un petit montage à part qui permet cette manipulation.
Pour l'avenir, cela peut être plus simple.
Mais je vais d'abord continuer à me casser les dents pour faire une librairie complète.

[adipie]

D’habitude quand il faut ajouter un ou des capteurs, il faut reprendre le code source et recompiler le programme.
Donc au passage tu modifies la table des adresses dans l’Eeprom et le tour est joué.
Il faut aussi penser que tu devra un jour remplacer le capteur N° X et à ce moment il suffit de corriger l’adresse dans l’Eeprom.
Pour relever les adresses d’une série de capteurs, j’avais réalisé une petite appli (voir pièce jointe).

[invite3d2336a7]

Yes, je vois ça.
Sympa la petite appli.
On reconnais de suite que ce sont des DS18B20 grâce au code 0x28...

Mais bon, tout cela ne m'avance pas dans la création de ma librairie avec une fonction search ROM. Je suis toujours limité à ma taille de tableau.
Vu qu'une lib n'a pas pour but d'exploiter de la mémoire externe...
Mais toutes ces solutions sont bonne pour mon application final. C'est déjà ça...

Je continue à éplucher les app notes de Maxim (Dallas).

[adipie]

Je ne comprend pas pourquoi tu veux absolument créer une librairie alors que ça existe ?
Tu programme avec quoi ?

[invite60c6fa7f]

Excuser moi d'arriver comme un cheveu sur la soupe...

@ adipie: J'avoue ne pas encore trop m'être penché dessus, mais si tu as trouvé une librairie pour grochip, je suis preneur...

@ jonhatan82: +1 stockage dans l'eeprom

[adipie]

Grochip ????????????????
Pour MikroC, MikroPascal, MikroBasic, la librairie est fournie avec le logiciel.
Pour ARDUINO ça existe voir Google
Voir aussi les librairies One Wire disponibles sur le site de DALLAS pour les développements Windows.

[invite60c6fa7f]

microchip, tout nu, donc MPLAB et un compilateur genre XC8.

[invite3d2336a7]

Grochip ????????????????
Pour MikroC, MikroPascal, MikroBasic, la librairie est fournie avec le logiciel.
Pour ARDUINO ça existe voir Google
Voir aussi les librairies One Wire disponibles sur le site de DALLAS pour les développements Windows.

MikroC est un peu mon Arduino, c'est ce dont je me sert pour faire du développement rapide par exemple.
Ils ont une librairie de communication, mais cela s'arrête là. Ils ont pas développé autre chose que Reset, Read et Write. Tout reste donc encore à faire.
Et la librairie Arduino reste également très basique...

[adipie]

MikroC est un peu mon Arduino, c'est ce dont je me sert pour faire du développement rapide par exemple.
Ils ont une librairie de communication, mais cela s'arrête là. Ils ont pas développé autre chose que Reset, Read et Write. Tout reste donc encore à faire.
Et la librairie Arduino reste également très basique...

Cela suffit amplement pour ton application, faire une recherche automatique des capteurs ne sert strictement à rien, car il faudra quand même adapter le soft après le rajout d'un capteur, à moins que j'ai loupé un épisode..
Ce n'est pourtant pas compliqué de faire une mise à jour d'une table en Eeprom.

[invite3d2336a7]

Cela suffit amplement pour ton application, faire une recherche automatique des capteurs ne sert strictement à rien, car il faudra quand même adapter le soft après le rajout d'un capteur, à moins que j'ai loupé un épisode..
Ce n'est pourtant pas compliqué de faire une mise à jour d'une table en Eeprom.

Oui, en effet, MikroC répond à mes besoins immédiat. Mais comme à la base, je voulais développer une lib complète, le problème de l'EEPROM et du soft ne se posait pas.
Une librairie, c'est comme une boîte à outils non ? Je prend ce dont j'ais besoin avec un minimum de modifications.

[invite60c6fa7f]

Si tu ébauche une libraire en C et veux bien la partager je suis preneur...

[invite3d2336a7]

Il me vient une autre idée. Certes, c'est plus long, mais c'est sans doute plus propre quand à l'exploitation de l'espace mémoire ainsi que plus "universel".
Il suffirait de compter le nombre de conflit sur le bus afin de savoir combien de capteur sont présents. On mémorise le dernier conflit à chaque fois pour ne pas devoir remonter toute la chaîne et avec un malloc, on détermine la taille du tableau nécessaire...