Comme quoi on peut ne pas particulièrement apprécier ce protocole et prendre le temps de faire une excellente présentation de celui-ci. Merci beaucoup EB !
Bonjour à tous. Je suis à l'origine de cette suggestion concernant le 1-Wire. Avec la réponse que j'avais reçue en messagerie privée, j'avais compris sans équivoque que cette interface n'était pas appréciée. Je cite : "Je le hais encore plus que le I2C". C'est pour cette raison que j'ai été très surpris de constater que, malgré cette "haine", EB a fait l'effort de produire cette vidéo, le résultat est de qualité. Un grand bravo !!! Je pensais que ça pourrait intéresser et/ou faire découvrir cette interface. Personnellement je n'ai pas d' a priori pour telle ou telle autre techno, c'est en général enrichissant. C'est le DS18B20 que j'ai souhaité découvrir en premier et non le 1-Wire, mais comme l'un ne va pas sans l'autre. Je l'ai utilisé une fois pour un petit projet autour d'un C.H.I.P. avec prises de températures avec 6 capteurs DS18B20 sur le même bus pour vérifier le comportement d'un système de chauffage, avec data logging. J'ai trouvé cela simple et adapté. Je rejoins bien sûr certains commentaires, si l'on fait du 1-Wire c'est dans certaines conditions et ce n'est pas forcément compatible d'autres contraintes techniques. Encore Bravo !
7 років тому
Merci de la suggestion originelle! Comme professionnnel, je suis capable de faire abstraction de mes préférences quand c'est nécessaire!
bonjour a tous. je suis aussi sur un projet et aimerai utilisé le même capteur DS18B20 ( 3 sonde ) mon objectif c'est de prélever la température sur chaque sonde puis faire une comparaison et mettre en marche un ventilateur en fonction des condition. pourrais je avoir un exemple de code avec 3 sonde DS18B20? voila mon mail: niki.hamed@gmail.com merci d'avance
bonjour a tous. je suis aussi sur un projet et aimerai utilisé le même capteur DS18B20 ( 3 sonde ) mon objectif c'est de prélever la température sur chaque sonde puis faire une comparaison et mettre en marche un ventilateur en fonction des condition. pourrais je avoir un exemple de code avec 3 sonde DS18B20? voila mon mail: niki.hamed17@gmail.com merci d'avance
J'ai découvert ta chaîne par cette vidéo. J'adore ce que tu fais. C'est très bien expliquer et simple à comprendre. Il manque peut-être quelques animations vidéos afin de rendre certaines explications plus passionnante. Mais c'est dommage que ce genre de chaîne ne soit pas plus souvent mis en avant. Elles sont ludiques et intéressantes pour une grande partie des gens.
Gérer ce protocole est un job pour un pic ou un Attiny85, qui fera une conversion vers un protocole moins rigoureux en timing. Mais c'est du boulot en plus. Il vaut mieux un fil supplémentaire pour une horloge , qui pourrait fournir l'alimentation en plus. Bonne vidéo, je vais regarder mes DS avec le scope et l'analyseur logique, ça m'a donné l'envie de voir çà de plus près.
Très bonne présentation (comme d'hab, merci encore :) ). En particulier la partie avec les oscillo est très bien expliquée. J'ai bien compris que le 1W n'est pas forcément ta tasse de thé, cependant, il a l'avantage de permettre une relativement grande distance (70m pour le bus de ma maison avec une 20e de sondes de températures mais aussi des GPIOs déportés) en utilisant seulement une seule broche et sans grande complication. Sous Unix, j'utilise un DS2482-800 et OWFS (beaucoup plus complet que de passer par les modules kernel) : strictement aucun impacte sur la charge de mon BananaPI. Je l'utilise aussi avec des ESP8266 pour mesurer des températures et ajouter des GPIOs, la aussi avec une grande satisfaction.
7 років тому
Bonjour. Merci pour les bons mots au sujet de cette présentation. Content de savoir que vous appréciez ce protocole. Comme mentionné, je comprends son utilité. Cependant je persiste à dire qu'un protocole synchrone à 2 ou 3 fils est plus facile à utiliser et plus robuste que le OneWire. Il s'agit de ralentir le débit, tout simplement, lorsque les distance sont plus grandes. Cordialement.
Bonjour, merci beaucoup pour vote temps passé à produire ces vidéos de très bonne qualité. seriez-vous d'accord de couvrir aussi le protocole CAN Bus ?
@ "C'est donc un rendez-vous" 😉Je continue à vous suivre assidûment. Merci encore pour vos vidéos d'une efficacité remarquables et " je vous dis: à la prochaine ! " 😉
A noter que les contraintes de timing font que l'implémentation de 1w sur GPIO dans le noyau linux (raspberry, beaglebone etc...) est atomique. (bloque toutes les autres traitements) pendant l'aquisition (approx 1s pour le thermometre DS18B20). C'est généralement éliminatoire sans un système temps réel.
Ben ce n'est pas ce qu'indique w1-gpio.c du kernel qui utilise des timings par msleep() qui n'est par définition pas atomic. De plus, c'est peut etre vrai lors d'envois/reception de trames sur les systèmes lents ou le msleep() ne serait plus assez précis ... mais en tout les cas, les systèmes n'est pas bloqué pendant que la sonde fait son acquisition (1s), car un stop total du système pendant pas loin d'une seconde ne pourrait que mettre la grouille dans les autres échanges (ceux qui administre des applies Java comprendront :) )
Ah mais justement! ça la fout la grouille ! J'ai testé sur une raspbian : je ne sais pas si c'est un stop total du système mais ça y ressemble carrément. Il n'y a plus de ping et les autres process ne communiquent plus sur l'uart pendant l'aquisition. Après, mes tests datent de 2016 et j'ai pas testé avec les dernières versions parce-que depuis j'ai intercalé un µC pour faire ce job. Mais matériellement, je ne vois pas comment on pourrait avoir des timings précis (et garantis) de l'ordre de la µs sans bloquer le noyau. En fait, même sur un microcontroleur, c'est difficile de faire autre chose en même temps qu'une transaction 1w. (sur un atmega, en soft, j'ai pas réussi, la moindre interrupt qui ne fait rien fausse déjà trop les delais. J'ai pas essayé avec un timer.)
Bon ben ... t'as raison : j'ai regardé les sources de l'antique kernel 3.4 tournant sur mon BananaPI (github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/w1/w1_io.c) qui utilise udelay() dans la fonction w1_delay(). Idem avec un kernel recent. D'ou l’intérêt d'utiliser un DS2482 comme je le fais :) Ceci dit, la com atomique n'est nécessaire QUE lors de l'envoie des trames car il n'y a strictement aucune raison d'avoir une attente bloquante durant une conversion avec un 18b20 : la sonde vie sa vie et écrit dans son scratchpad sans qu'on ne fasse rien. Pour avoir la température, il suffit de lire le dit scratchpad une fois le delai passé. Exemple de code pour ESP : github.com/destroyedlolo/OWBus/blob/master/examples/Temperature_Async_DS18B20/Temperature_Async_DS18B20.ino Sous Linux, pendant l'equivalent du delay(), on reste en multi-tache. La zone atomique n'est dont "que" pendant les l'envoie/la reception des trames. Si ton driver bloquait le système pendant la seconde, c'était qu'il était mal foutu :) Voili, voila.
BJ et merci, peut on expliquer simplement pourquoi dans le code utilisé, il y a delay(1000). Je voudrais avoir un bouton poussoir pour commander grâce aux interruptions, ce qui est difficilement possible avec ce delay.
5 років тому+1
Le DS18B20 prend environ 750 ms pour faire une conversion (compléter la lecture) Pas le choix d'attendre. Mais il serait possible de construire le code pour ne pas attendre avec un delay, mais de plutôt utiliser une minuterie et de passer à répétition pour vérifier si le temps d'attente est terminé.
Bonjour, combien de sonde peut ont placé sur le même file?
3 роки тому
En théorie, une tonne! Car il y a une adresse unique pour chaque sonde. En pratique, je ne sais pas. La capacité parasite du câblage va finir par détériorer le signal au point où ça ne marchera plus.
Bonjour, je viens de regarder toute la série sur les protocoles du même nom (série). Très bon travail ! Les sujets sont suffisamment bien traitées pour comprendre dans quoi on met les pieds si on veut aller plus loin. Bravo ! Y aura-t-il un jour le JTAG comme sujet dans cette série?
6 років тому
JTAG n'est pas simplement un protocole de communication série au même titre que les autres. C'est quelque chose de beaucoup, beaucoup vaste comme sujet. Hmmmm... Je sais pas. C'es comme une boîte de pandore. Je l'ai mis dans ma liste de suggestion. On verra bien un jour si l'envie me prend. Merci.
Je vous comprends, je suis en train de me documenter la dessus, ça a l'air vaste et très pratique au niveau des tests en production industriel et plus encore. Merci pour votre attention.
Toujours excellent, merci Et concernant le protocole pour l'USB ? c'est quoi exactement
7 років тому
Ne vous attendez pas à ce que je fasse une vidéo détaillée de cette interface! Beaucoup trop complexe à émuler. Au mieux, je pourrais discuter des points généraux. C'est pas pour rien qu'il faut une puce de conversion aux deux extrémités...L'acquisition et l'échange sont mal conçus à mon avis. Beaucoup trop complexe dans sa forme la plus simple. Je verrai. Entre temps, nourrissez-vous de wikipédia!
Merci pour le souci d'exhaustivité dans la présentation de ce protocole. Ta grimace en début de vidéo vient du coeur et en dit long sur ton goût pour le 1wire. Je le partage tout a fait. J'ai horreur de la complexité qu'ajoute au code les protocoles asynchrones. Un bon 4AL22 blindé n'est pas plus chere qu'un côte à côte. J'adore faire usage des interruptions et ce n'est vraiment pas compatibles avec ce genre de timing qui impose son carcan dans toute l'application. A moins comme tu le fais d'utiliser un adaptateur dédié qui ne gère que la comm. Mais bon ça fait déja un brol en plus dans la chaîne alors qu'un simple uC peut tout faire en synchrone. Mais bon tout existe... La preuve les gardes de securité sur mon lieu de travail scannent des bouton DALLAS collé sur les murs lorsqu'ils font leur ronde.
Avec quelques --siècles-- de retard, MERCI pour toutes ces explications sur les protocoles séries.
Tous les jours, j'en apprends un peu plus.
Comme quoi on peut ne pas particulièrement apprécier ce protocole et prendre le temps de faire une excellente présentation de celui-ci.
Merci beaucoup EB !
Bonjour à tous. Je suis à l'origine de cette suggestion concernant le 1-Wire. Avec la réponse que j'avais reçue en messagerie privée, j'avais compris sans équivoque que cette interface n'était pas appréciée. Je cite : "Je le hais encore plus que le I2C". C'est pour cette raison que j'ai été très surpris de constater que, malgré cette "haine", EB a fait l'effort de produire cette vidéo, le résultat est de qualité. Un grand bravo !!! Je pensais que ça pourrait intéresser et/ou faire découvrir cette interface. Personnellement je n'ai pas d' a priori pour telle ou telle autre techno, c'est en général enrichissant. C'est le DS18B20 que j'ai souhaité découvrir en premier et non le 1-Wire, mais comme l'un ne va pas sans l'autre. Je l'ai utilisé une fois pour un petit projet autour d'un C.H.I.P. avec prises de températures avec 6 capteurs DS18B20 sur le même bus pour vérifier le comportement d'un système de chauffage, avec data logging. J'ai trouvé cela simple et adapté. Je rejoins bien sûr certains commentaires, si l'on fait du 1-Wire c'est dans certaines conditions et ce n'est pas forcément compatible d'autres contraintes techniques. Encore Bravo !
Merci de la suggestion originelle! Comme professionnnel, je suis capable de faire abstraction de mes préférences quand c'est nécessaire!
bonjour a tous. je suis aussi sur un projet et aimerai utilisé le même capteur DS18B20 ( 3 sonde ) mon objectif c'est de prélever la température sur chaque sonde puis faire une comparaison et mettre en marche un ventilateur en fonction des condition. pourrais je avoir un exemple de code avec 3 sonde DS18B20? voila mon mail: niki.hamed@gmail.com
merci d'avance
bonjour a tous. je suis aussi sur un projet et aimerai utilisé le même capteur DS18B20 ( 3 sonde ) mon objectif c'est de prélever la température sur chaque sonde puis faire une comparaison et mettre en marche un ventilateur en fonction des condition. pourrais je avoir un exemple de code avec 3 sonde DS18B20? voila mon mail: niki.hamed17@gmail.com
merci d'avance
J'ai découvert ta chaîne par cette vidéo. J'adore ce que tu fais. C'est très bien expliquer et simple à comprendre. Il manque peut-être quelques animations vidéos afin de rendre certaines explications plus passionnante. Mais c'est dommage que ce genre de chaîne ne soit pas plus souvent mis en avant. Elles sont ludiques et intéressantes pour une grande partie des gens.
Bravo pour la clarté des explications.
Ce n’était pas si simple à expliquer.
Bonsoir , Merci pour cette vidéo comme toujours bien expliquée !
Gérer ce protocole est un job pour un pic ou un Attiny85, qui fera une conversion vers un protocole moins rigoureux en timing. Mais c'est du boulot en plus. Il vaut mieux un fil supplémentaire pour une horloge , qui pourrait fournir l'alimentation en plus. Bonne vidéo, je vais regarder mes DS avec le scope et l'analyseur logique, ça m'a donné l'envie de voir çà de plus près.
Très bonne présentation (comme d'hab, merci encore :) ). En particulier la partie avec les oscillo est très bien expliquée.
J'ai bien compris que le 1W n'est pas forcément ta tasse de thé, cependant, il a l'avantage de permettre une relativement grande distance (70m pour le bus de ma maison avec une 20e de sondes de températures mais aussi des GPIOs déportés) en utilisant seulement une seule broche et sans grande complication.
Sous Unix, j'utilise un DS2482-800 et OWFS (beaucoup plus complet que de passer par les modules kernel) : strictement aucun impacte sur la charge de mon BananaPI.
Je l'utilise aussi avec des ESP8266 pour mesurer des températures et ajouter des GPIOs, la aussi avec une grande satisfaction.
Bonjour. Merci pour les bons mots au sujet de cette présentation. Content de savoir que vous appréciez ce protocole. Comme mentionné, je comprends son utilité. Cependant je persiste à dire qu'un protocole synchrone à 2 ou 3 fils est plus facile à utiliser et plus robuste que le OneWire. Il s'agit de ralentir le débit, tout simplement, lorsque les distance sont plus grandes. Cordialement.
Merci, c'est bien expliqué, bien compris.
Bonjour, merci beaucoup pour vote temps passé à produire ces vidéos de très bonne qualité. seriez-vous d'accord de couvrir aussi le protocole CAN Bus ?
Déjà dans ma longue liste de sujets potentiels...
@ "C'est donc un rendez-vous" 😉Je continue à vous suivre assidûment. Merci encore pour vos vidéos d'une efficacité remarquables et " je vous dis: à la prochaine ! " 😉
I need to read the ROM Command using one wire in STC15F. kindly send the Read Rom command function
A noter que les contraintes de timing font que l'implémentation de 1w sur GPIO dans le noyau linux (raspberry, beaglebone etc...) est atomique. (bloque toutes les autres traitements) pendant l'aquisition (approx 1s pour le thermometre DS18B20). C'est généralement éliminatoire sans un système temps réel.
Ben ce n'est pas ce qu'indique w1-gpio.c du kernel qui utilise des timings par msleep() qui n'est par définition pas atomic.
De plus, c'est peut etre vrai lors d'envois/reception de trames sur les systèmes lents ou le msleep() ne serait plus assez précis ... mais en tout les cas, les systèmes n'est pas bloqué pendant que la sonde fait son acquisition (1s), car un stop total du système pendant pas loin d'une seconde ne pourrait que mettre la grouille dans les autres échanges (ceux qui administre des applies Java comprendront :) )
Ah mais justement! ça la fout la grouille ! J'ai testé sur une raspbian : je ne sais pas si c'est un stop total du système mais ça y ressemble carrément. Il n'y a plus de ping et les autres process ne communiquent plus sur l'uart pendant l'aquisition. Après, mes tests datent de 2016 et j'ai pas testé avec les dernières versions parce-que depuis j'ai intercalé un µC pour faire ce job. Mais matériellement, je ne vois pas comment on pourrait avoir des timings précis (et garantis) de l'ordre de la µs sans bloquer le noyau.
En fait, même sur un microcontroleur, c'est difficile de faire autre chose en même temps qu'une transaction 1w. (sur un atmega, en soft, j'ai pas réussi, la moindre interrupt qui ne fait rien fausse déjà trop les delais. J'ai pas essayé avec un timer.)
Bon ben ... t'as raison : j'ai regardé les sources de l'antique kernel 3.4 tournant sur mon BananaPI (github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/w1/w1_io.c) qui utilise udelay() dans la fonction w1_delay(). Idem avec un kernel recent.
D'ou l’intérêt d'utiliser un DS2482 comme je le fais :)
Ceci dit, la com atomique n'est nécessaire QUE lors de l'envoie des trames car il n'y a strictement aucune raison d'avoir une attente bloquante durant une conversion avec un 18b20 : la sonde vie sa vie et écrit dans son scratchpad sans qu'on ne fasse rien. Pour avoir la température, il suffit de lire le dit scratchpad une fois le delai passé.
Exemple de code pour ESP : github.com/destroyedlolo/OWBus/blob/master/examples/Temperature_Async_DS18B20/Temperature_Async_DS18B20.ino
Sous Linux, pendant l'equivalent du delay(), on reste en multi-tache. La zone atomique n'est dont "que" pendant les l'envoie/la reception des trames.
Si ton driver bloquait le système pendant la seconde, c'était qu'il était mal foutu :)
Voili, voila.
BJ et merci, peut on expliquer simplement pourquoi dans le code utilisé, il y a delay(1000).
Je voudrais avoir un bouton poussoir pour commander grâce aux interruptions, ce qui est difficilement possible avec ce delay.
Le DS18B20 prend environ 750 ms pour faire une conversion (compléter la lecture) Pas le choix d'attendre. Mais il serait possible de construire le code pour ne pas attendre avec un delay, mais de plutôt utiliser une minuterie et de passer à répétition pour vérifier si le temps d'attente est terminé.
Bonjour, combien de sonde peut ont placé sur le même file?
En théorie, une tonne! Car il y a une adresse unique pour chaque sonde. En pratique, je ne sais pas. La capacité parasite du câblage va finir par détériorer le signal au point où ça ne marchera plus.
Bonjour,
je viens de regarder toute la série sur les protocoles du même nom (série).
Très bon travail ! Les sujets sont suffisamment bien traitées pour comprendre dans quoi on met les pieds si on veut aller plus loin. Bravo !
Y aura-t-il un jour le JTAG comme sujet dans cette série?
JTAG n'est pas simplement un protocole de communication série au même titre que les autres. C'est quelque chose de beaucoup, beaucoup vaste comme sujet. Hmmmm... Je sais pas. C'es comme une boîte de pandore. Je l'ai mis dans ma liste de suggestion. On verra bien un jour si l'envie me prend. Merci.
Je vous comprends, je suis en train de me documenter la dessus, ça a l'air vaste et très pratique au niveau des tests en production industriel et plus encore.
Merci pour votre attention.
Bravo CoooooooooooooooL
plus de description sur la band des 11metres citizen band svr merci
Toujours excellent, merci
Et concernant le protocole pour l'USB ? c'est quoi exactement
Ne vous attendez pas à ce que je fasse une vidéo détaillée de cette interface! Beaucoup trop complexe à émuler. Au mieux, je pourrais discuter des points généraux. C'est pas pour rien qu'il faut une puce de conversion aux deux extrémités...L'acquisition et l'échange sont mal conçus à mon avis. Beaucoup trop complexe dans sa forme la plus simple. Je verrai. Entre temps, nourrissez-vous de wikipédia!
Merci pour le souci d'exhaustivité dans la présentation de ce protocole.
Ta grimace en début de vidéo vient du coeur et en dit long sur ton goût pour le 1wire.
Je le partage tout a fait.
J'ai horreur de la complexité qu'ajoute au code les protocoles asynchrones.
Un bon 4AL22 blindé n'est pas plus chere qu'un côte à côte.
J'adore faire usage des interruptions et ce n'est vraiment pas compatibles avec ce genre de timing qui impose son carcan dans toute l'application.
A moins comme tu le fais d'utiliser un adaptateur dédié qui ne gère que la comm.
Mais bon ça fait déja un brol en plus dans la chaîne alors qu'un simple uC peut tout faire en synchrone.
Mais bon tout existe...
La preuve les gardes de securité sur mon lieu de travail scannent des bouton DALLAS collé sur les murs lorsqu'ils font leur ronde.
superbe!
+1 ;)