bus 1-wire

[invite854f2515]

bonjour,
nous sommes deux étudiants en iut geii, ce semestre nous démarons un projet sur l'étude et la réalisation d'un bus 1 fil sur lequel doit se trouver un capteur de température DS18S20 pour commencer puis d'autre capteur ensuite. Nous ne savons pas vraiment par ou commencer, nous avons consulté quelques cours sur le sujet ainsi que la data sheet du capteur, après quelques recherches nous pensons partir sur un microcontroleur 68HC11 pour pour gérer le bus.
Nous venons demander quelques conseils aux personnes plus expérimenté ou aillant déjà réalisé un tel projet.
Merci d'avance
olivier et stephane
-----

[invite5637435c]

Salut le binôme,

Ca tombe bien il se trouve que je dois réaliser de mon coté une mesure de 3 températures déportées (2m) avec des ds18s20 et j'ai comme vous feuilleté la doc pour le moment.
Pour l'instant j'ai retenu que l'on pouvait soit utiliser les 3 fils du composant (VCC,DQ,gnd) ou seulement 2 fils (parasite power) qui semble plus intéressant mais complique juste un peu le protocole à mettre en oeuvre.

Pour ma part, je vais utiliser un PIC18F4520 vu que c'est pour une centrale de mesures (12 A/D 10 bits requis).

On se tient au courant sur ce fil de nos avancées respectives.
Ceux qui ont des expériences à nous communiquer sont les bienvenus.
@+

[invite854f2515]

nous allons nous renseigner sur le PIC que tu proposes, de notre coté on nous impose de n'utiliser que deux fils donc nous allons approfondir nos recherches sur le "parasite power".
grace à un autre lien trouvé sur le forum nous avons pu trouver un document assez complet sur cette technologie.
nous avons aussi un boitier de controle à réaliser:
- 4 boutons pour créer un menu (on n'en sait pas plus de ce coté la ^^)
- un afficheur à cristaux liquide pour l'affichage de la température (et autre) mais nous ne connaissons rien dans ce dommaine .

Hello,

Pour mettre en oeuvre un bus 1-wire de plusieurs metres avec plusieurs dispositifs esclaves, il est prudent de lire la note d'application MAXIM :

http://www.maxim-ic.com/appnotes.cfm/appnote_number/148

A+,

Bruno

[A voir en vidéo sur Futura]

[invite5637435c]

nous allons nous renseigner sur le PIC que tu proposes, de notre coté on nous impose de n'utiliser que deux fils donc nous allons approfondir nos recherches sur le "parasite power".
grace à un autre lien trouvé sur le forum nous avons pu trouver un document assez complet sur cette technologie.
nous avons aussi un boitier de controle à réaliser:
- 4 boutons pour créer un menu (on n'en sait pas plus de ce coté la ^^)
- un afficheur à cristaux liquide pour l'affichage de la température (et autre) mais nous ne connaissons rien dans ce dommaine .

Le pic ne doit pas être la préoccupation, un 68hc11 c'est très bien aussi.
Dans quel langage de programmation devez-vous traiter le problème?

Pour Brunog, merci en effet j'ai déjà téléchargé la note d'appli, une bonne habitude à avoir avec Dallas/Maxim...
J'ai en passant pu vérifier que Mikroelektronika ne faisait effectivement pas payer ses mises à jour (en mono poste), je me demande dans ce cas comment ils s'en sortiront financièrement parlant dans 3 ans et plus.
Par contre il faut leur reconnaitre un joli travail de documentation, qui manque chez pas mal.
Juste dommage qu'il ne soit pas full ANSI...

[invite5637435c]

nous avons aussi un boitier de controle à réaliser:
- 4 boutons pour créer un menu (on n'en sait pas plus de ce coté la ^^)
- un afficheur à cristaux liquide pour l'affichage de la température (et autre) mais nous ne connaissons rien dans ce dommaine .

Il faudrait exposer votre projet intégralement, ça peut intéresser d'autres gens, c'est le meilleur moyen d'obtenir des conseils.
Plus c'est flou, moins le "passant" va s'arrêter.
Je vous rappelle qu'il y a la section "Projets" qui est faite pour ça.
Il faut amener un projet, l'animer, et aller jusqu'au bout de l'aventure.
Si le coeur vous en dit, vous avancerez plus vite.
@+

J'ai en passant pu vérifier que Mikroelektronika ne faisait effectivement pas payer ses mises à jour (en mono poste), je me demande dans ce cas comment ils s'en sortiront financièrement parlant dans 3 ans et plus.
Par contre il faut leur reconnaitre un joli travail de documentation, qui manque chez pas mal.
Juste dommage qu'il ne soit pas full ANSI...

Je pense qu'ils comptent attirer de nouveaux clients en phase de renouvellement de leur licence sur d'autres compilateurs.
Vu leurs tailles, les docs contiennent encore des erreurs, mais bon je préfère encore que les erreurs soient dans la doc que dans le compilo
Le compilateur C est ANSI mais non pas full ANSI en raison des caractéristiques propres des PICs : ré-entrance et récursion limitées, traitement du modificateur 'const' pour les données en ROM.
Il manque les structures & unions anonymes, mais c'est seulement quand il faut porter une appli microchip que c'est douloureux

A+,

Bruno

[invitea192d499]

Salut

Bon le bus 1-wire de dallas, je connais bien et j'ai deja fait pas mal d'essai dessus

Alors peut importe quel microcontroleur ou processeur vous utilisez tant que vous avez 1 broche d'un port qui marche en binaire (0-1)
Ensuite dans tous les cas faut que vous recreez quelques procedures dans le langage que vous utilisez mais personnellement dans la programmation, il vaut mieux utiliser l'assembleur pour avoir des tempos precise meme si ce genre de bus ne le necessite pas specialement

Pour communiquer avec le capteur de temperature et obtenir la temperature, c'est tres facile
Il faut juste lire une memoire et encore qu'une partie mais pour cela toute la procedure et tout ce dont vous avez besoin est dans le datasheet
Les durees des etats, les niveaux, les signaux a envoyer, etc... tout est dedans

Le plus long sera de calculer les tempo

Pour l'alimentation parasite, je sais qu'il y a un petit paragraphe dessus dans le datasheet et qu'il y aurait une commande liee mais j'ai jamais teste parceque je suis pas a 1 fil pres surtout qu'il n'y a que 3 fils max

[invitea516a87c]

Salut !

J'ai utillisé un DS1821 et fait une doc :

http://www.jelectronique.com/Capt_te...0&%201Wire.pdf

(JE electronic c'est pas mon site, mais y ont piqué ma doc et fait un PDF avec mon dossier )

[invite5637435c]

Merci Mkala pour cette doc bien faite et instructive.

Pour Mizuki, je vois pas bien l'intérêt de l'assembleur pour une telle fonction.
La température est un phénomène lent et rien ne nécessite de la vitesse de traitement là dedans.
Le protocole est simple et peu gourmand en ressource, et le timer du µC est largement assez précis (10 bits) pour produire une tempo précise.

[invite854f2515]

je pense que nous allons poster dans la partie projet mais il faut qu'on mette nos idées un peut en place avant car on nous lache un peut à l'aventure la dessus puisqu'on nous donne uniquement le sujet, qui est donc consevoir un bus 1 fil et nous devons nous débrouiller pour le reste, on doit donc faire le cahier des charges, réaliser le boitier de commande donc tipon de la carte, liste des composants, programmation du µC en language C++ et même si on fait pas mal de C++ en cours d'info on ne voit pas vraiment comment gérer un µC avec. on doit aussi gérer une liaison série pour transférer à un ordi il me semble aussi mais je ne suis pas certain de ce point. je met tout ça en forme histoire que ça soit plus lisible et je vous tiens au courant, je pense m'en occuper d'ici ce week-end.

Mkala merci pour ton lien, j'avais déjà trouvé ta doc et justement je l'ai imprimé car je la trouve bien faite assès complète sur le sujet

Bonne journée à tous, à bientot

[invite5637435c]

je pense que nous allons poster dans la partie projet mais il faut qu'on mette nos idées un peut en place avant car on nous lache un peut à l'aventure la dessus puisqu'on nous donne uniquement le sujet, qui est donc consevoir un bus 1 fil et nous devons nous débrouiller pour le reste, on doit donc faire le cahier des charges, réaliser le boitier de commande donc tipon de la carte, liste des composants, programmation du µC en language C++

Comme dans la vraie vie...

[invite2562e666]

Bonjour,

C'est toujours assez amusant comme on embraye au quart de tour vers les PICs.

Si tu utilises un 68HC908 (dont l'assembleur est très proche du HC11), regarde sur www.68hc08.net :
dans
http://www.68hc08.net/modules/smarts....php?itemid=69
Il y a une fichier de gestion "DS1820.inc" que tu trouveras dans le "zip" à télécharger. L'assembleur est mieux adapté que le C pour gérer des tempos précises, et d'autre part, on peut mélanger C et ASM sans problème.

Tu trouveras très un bon compilateur C (full ANSI et full GRATUIT) (+simulateur/debugger/programmateur) gratuit ici :
http://www.freescale.com/webapp/sps/...elopment_Suite
Et pour te donner des idées Hardware :
http://www.68hc08.net/modules/smarts....php?itemid=24

et tout, et tout sur ce site, y compris l'aide du forum en ligne.

Dernière remarque : le HC11 n'est plus fabriqué (sucesseurs HC908 et HC12), il devient difficile à trouver et très cher.
thierry

[invite5637435c]

Salut thm,

tu remarqueras que j'avais expliqué à nos jeunes amis que le choix du µC n'était pas la priorité dans ce projet.
Un pic, un freescale, peu importe, le plus important c'est de bien comprendre ce que l'on fait.
Pour ce qui est des tempos en assembleur, à ma connaissance c'est surtout en vidéo que le besoin peut se faire sentir, mais dans l'appli qui nous préoccupe, vraiment aucun intérêt.
Les avantages de l'assembleur avec les nouveaux compilateurs C sont vraiment des cas particuliers.
Je teste en comparaison de temps à autre des progs en assembleur et en C, et je t'assure que la différence de taille de code est dérisoire.
Par contre le temps de modif (genre 2 ans plus tard) est nettement en faveur du C.

[invite2562e666]

Salut thm,

tu remarqueras que j'avais expliqué à nos jeunes amis que le choix du µC n'était pas la priorité dans ce projet.
Un pic, un freescale, peu importe, le plus important c'est de bien comprendre ce que l'on fait.
Pour ce qui est des tempos en assembleur, à ma connaissance c'est surtout en vidéo que le besoin peut se faire sentir, mais dans l'appli qui nous préoccupe, vraiment aucun intérêt.
Les avantages de l'assembleur avec les nouveaux compilateurs C sont vraiment des cas particuliers.
Je teste en comparaison de temps à autre des progs en assembleur et en C, et je t'assure que la différence de taille de code est dérisoire.
Par contre le temps de modif (genre 2 ans plus tard) est nettement en faveur du C.

Merci de tes leçons, HULK,

mais je te fais quand même remarquer que mon post était avant tout destiné à proposer des pistes de solutions tant hardware que software pour le problème cité dans le post original, ce qui est plus concret qu'une réponse du style "moi je le fais avec un PIC18F1234".

Ceci dit, aussi, je constate qu'il y a 2 posts (dont un des tiens) consacrés à MiKromachin, qui n'ont strictement rien à voir avec le sujet et dont je ne vois pas la valeur ajoutée. Je considère donc que ma (courte) phrase de constatation est encore gentille et polie.

Un programme bien compris en asm est facile à convertir en C, et sa connaissance permet de comprendre ce que fait le compilateur et donc de savoir ce que l'on fait exactement avec le matériel.

Excuse moi d'avoir cru que le HC908 était plus proche du HC11 que le PIC18F1234. Et pour répondre à ta remarque suivante, ce n'est pas vrai que le C permet de s'affranchir de cette "couche physique" car les registres des périphériques sont toujours appelés par leur nom propre, les procédures de gestion et d'acquitement des interruption .. etc ..dépendent également du µC.



thierry

[invite5637435c]

Merci de tes leçons, HULK,

Je ne suis pas là pour donner des leçons mais des conseils, je considère que "leçons" est déplacé ici...

mais je te fais quand même remarquer que mon post était avant tout destiné à proposer des pistes de solutions tant hardware que software pour le problème cité dans le post original, ce qui est plus concret qu'une réponse du style "moi je le fais avec un PIC18F1234".

Je ne comprend pas bien cette prise à partie, je ne faisais qu'expliquer sur quoi je bossais c'est tout.

Ceci dit, aussi, je constate qu'il y a 2 posts (dont un des tiens) consacrés à MiKromachin, qui n'ont strictement rien à voir avec le sujet et dont je ne vois pas la valeur ajoutée. Je considère donc que ma (courte) phrase de constatation est encore gentille et polie.

Ca c'est quand même la meilleure, si tu suivais mes posts tu constaterais que je me suis expliqué clairement et vivement avec Brunog sur le sujet Mikroelektronika.
De plus, et là je te trouve un peu gonflé quand même, je suis peut-être un des seuls à parler de freescale dans mes interventions face aux solutions Microchip.

Un programme bien compris en asm est facile à convertir en C, et sa connaissance permet de comprendre ce que fait le compilateur et donc de savoir ce que l'on fait exactement avec le matériel.

Le C s'impose dans le monde de l'électronique tu n'y peux rien, l'assembleur ne présente aujourd'hui aucun intérêt si ce n'est dans quelques cas bien particulier comme je l'ai indiqué.

Excuse moi d'avoir cru que le HC908 était plus proche du HC11 que le PIC18F1234. Et pour répondre à ta remarque suivante, ce n'est pas vrai que le C permet de s'affranchir de cette "couche physique" car les registres des périphériques sont toujours appelés par leur nom propre, les procédures de gestion et d'acquitement des interruption .. etc ..dépendent également du µC.

Je ne comprend pas le début de ta phrase, ni la fin d'ailleurs.
Je n'ai pas prétendu que le C s'affranchit de la couche physique, il permet de s'occuper de l'essentiel à savoir les fonctions à remplir pour effectuer le travail demandé.
Réalise que les temps de développement sont divisés par 10 avec le C ou tout autres langages évolués, c'est ça le progrès, l'assembleur c'est bon pour le coté "comment ça marche" mais après il faut savoir évoluer.
Il y a des routines impensables à réaliser en assembleur sans y passer l'année, et encore avec des bugs de tout coté.
Effectuer des calculs complexes par exemples avec l'assembleur c'est vraiment aimer se faire mal.

Quoiqu'il en soit, j'aimerai que tu ne prennes pas la mouche dès que quelqu'un sort le mot Microchip.
Je pense que la meilleure approche est de proposer des solutions équivalentes en freescale ou autre, les forumeurs choisiront leur camp, c'est aussi ça la liberté de penser.

[invitea192d499]

Je ne suis pas d'accord avec certaine chose

Pour le choix du µP, ok ce qui est important c'est comprendre ce qu'on doit faire pour cette application on peut prendre n'importe lequel
Bon sur d'autre application qui ont un besoin plus specifique on doit choisir la personne ne me contre dira
Les motorola ont beaucoup de potentiel sur certain point par rapport a certain pic ou atmel mais tous reste different
Je pense que "leur" choix d'un pic n'est pas vraiment le leur mais plutot celui du prof qui connait que la programmation des pic et c'est malheureux je trouve

Pour ce qui est du langage je ne suis pas d'accord avec ce qui est dit
L'assembleur reste et restera toujours important a connaitre par rapport au autre langage evolue
Apres je dis qu'il faut le faire en assembleur parceque le protocol est tres simple a realise, on a un code plus compact qu'on peut copier/coller dans des applications futurs sans se preoccupe de la provenance d'un manque de place a venir
Les tempos plus precise, ca depend de ce que tu utilises si c'est un quartz ou un circuit RC ou rien
Je peux t'assure qu'il y a beaucoup d'application ou les tempos doivent etre precise, la video n'est pas la seul

Le C se developpe dans la programmation electronique mais personnellement je m'en sers que pour des tests rapide sinon je cherche plutot a developpe en assembleur
Je reconnais qu'il y a des structures de mes programmes que j'arrive pas completement a developpe en assembleur mais je cherche quand meme

D'un autre cote les µP ont plus de place, etc... mais cela n'empeche pas d'avoir des bonnes methodes a la base, efficace et surtout savoir exactement ce que fait le programme
Mais bon dela a dire que le C c'est la seul, unique, meilleur solution pour programmer c'est la pire betise que j'ai jamais entendu dans la programmation surtout quand on sait que pour le C, basic ou autre on passe toujours mais toujours par l'assembleur avant d'obtenir le code machine

Surtout que je me souviens en cours d'elec, on apprennait d'abord l'assembleur et apres le C (le C etait un plus meme pas une obligation)
L'assembleur sert a comprendre le C car tout s'y ramene

[invite2562e666]

Je suis tout à fait d'accord avec Mizuki,

Pour des applications "lourdes", je pense que le C est mieux adapté, quoi que cela soit encore discutable : exemple récent sur le site 68hc08, un (excellent) programmeur a réalisé une routine FFT en .. assembleur car 30x plus rapide qu'en C (avec un compilateur pourtant performant). Le C est aussi mal adapté pour les opérations "bits" (->nécessité de masques). Et comme le dit Mizuki, il n'y a pas que la vidéo qui nécessite des timings précis.

Et puis, personnellement j'utilise les 2, c'est vrai que le C permet de mieux voir la structure d'un programme. Je n'ai donc aucun à-priori, je prends le plus facile mais je regarde toujours l'assembleur que le C génère;et cela m'a déjà amené à modifier des expressions C parce que "mal" traduites en ASM. Le programmeur C qui ne connait pas l'ASM risque d'être un piètre programmeur (même si son code C est esthétique).

Maintenant,

Quoiqu'il en soit, j'aimerai que tu ne prennes pas la mouche dès que quelqu'un sort le mot Microchip.
Je pense que la meilleure approche est de proposer des solutions équivalentes en freescale ou autre, les forumeurs choisiront leur camp, c'est aussi ça la liberté de penser.

je signale à HULK que je n'ai pas pris la mouche dans mon post #13 (relis-le éventuellement), mais après avoir constaté (très poliment) que sur les 7 premiers posts, il y en avait déjà 3 ou l'on "introduisait" MiKRO** et PIC**, les 90% restant de mon post étaient consacrés à donner une solution logicielle : ASM de communication DS1820 (- je l'aurais aussi donnée en C si je l'avais trouvée-); compilateur C performant et hardware correspondant (µC avec LCD et boutons); ce que je n'ai pas vu avec des PICS.

Je n'aime pas les PICs, c'est beucoup de "vent" et je ne me gènerai pas pour le dire, comme certains n'aiment pas d'autres µC que les pics et ne se gènent pas pour le dire non plus.

thierry

[invite5637435c]

......, après quelques recherches nous pensons partir sur un microcontroleur 68HC11 pour pour gérer le bus.
Nous venons demander quelques conseils aux personnes plus expérimenté ou aillant déjà réalisé un tel projet.
Merci d'avance

Pour Mizuki, je vois pas ou tu vois que bibigeii veux partir sur du Pic, faudrai voir à être précis quand même.

...Les motorola ont beaucoup de potentiel sur certain point par rapport a certain pic ou atmel mais tous reste different...

C'est quoi ce charabia?

Je peux t'assure qu'il y a beaucoup d'application ou les tempos doivent etre precise, la video n'est pas la seul

J'attend des exemples.

Mais bon dela a dire que le C c'est la seul, unique, meilleur solution pour programmer c'est la pire betise que j'ai jamais entendu dans la programmation surtout quand on sait que pour le C, basic ou autre on passe toujours mais toujours par l'assembleur avant d'obtenir le code machine

Non sans blague?
C'est ce que je disais, il faut vraiment que tu apprennes à lire.
Tu confonds tout.

Le C se developpe dans la programmation electronique mais personnellement je m'en sers que pour des tests rapide sinon je cherche plutot a developpe en assembleur

Tu m'expliqueras ce qu'est la "programmation électronique".
Des tests rapides, humm, pourquoi faire allumer une led?

Surtout que je me souviens en cours d'elec, on apprennait d'abord l'assembleur et apres le C (le C etait un plus meme pas une obligation)
L'assembleur sert a comprendre le C car tout s'y ramene

N'importe quoi, la plupart des gens qui aprennent le C, n'ont jamais appris l'assembleur, et en tout cas ce n'est pas une obligation.
Je rapelle quand même qu'un langage évolué est une couche supérieure au matériel, ce qui permet de ne pas réapprendre l'assembleur du nouveau µC que l'on décide d'adopter.
L'assembleur encore une fois permet de manipuler des registres ou des fonctions internes qui ne peuvent être atteintes efficacement avec le langage évolué.
Notamment les actions sur la pile.
Il serait donc bon que tu reprennes tes cours d'élec avant de colporter des aneries.

Pour des applications "lourdes", je pense que le C est mieux adapté, quoi que cela soit encore discutable

Non, c'est juste ton point de vue, mais dans l'industrie c'est depuis longtemps indiscutable.
Désolé, mais j'ai un bureau d'études à faire tourner et quand tu sais le coût d'une heure de développeur, tu fais vite le meilleur choix économique, le langage évolué.
On ne parle pas du cadre amateur, mais des programmes sur des projets plannifiés sur 3 à 6 mois, je te laisse faire le calcul du coût de développement quand tu dois prévoir de l'assembleur avec le gars spécialisé qui va bien derrière le clavier.
Dans le cadre amateur, on peut tout prétendre, mais quand on parle sérieusement, il faut parler chiffre, et là les choix sont beaucoup plus restreint.
Un exemple concret et récent:
Une modification de soft assembleur sur µC 68HC11 a nécessité plusieurs jours de travail à un développeur chevronné extérieur qui a dû reprendre un soft mal goupillé à la base et pour lequel la même modif en C aurait pris quelques heures pour des programmeurs ne connaissant même pas le µC en question.
Résultat un coût prohibitif en regard du coût en C.
Ca c'est concret.

Quant au choix des µC, je l'ai souvent dis avec d'autres, ce ne sont que des discussions de comptoir dans lesquels je ne prendrai jamais part.

[invitea516a87c]

De rien pour la doc !

Sinon c'est quoi ce pourissage de sujet avec ces uC ??? C'est bientot dans tous les sujets qu'il y a une gerre la dessus ! C'est pas le but

[invite5637435c]

Je suis bien d'accord mais je ne peux pas laisser dire n'importe quoi non plus.

Dorénavant, le principe sera plus simple, poubellisation sans préavis des messages incriminés dès que ça tourne à l'eau de boudin.

[invite854f2515]

merci à vous tous pour vos réponces (on ne s'attendait pas à ce que le bus 1 fil déchaine autant de passion ) cela nous aide bien et nous avons trouvé plusieur piste à suivre. pour le moment nous devons nous occuper de toute la partie "administrative" (planing, schéma fonctionnel, etc, etc...).
nous allons poster le projet en tier dans la partie que tu nous as conseillé hulk.
merci à tous et à bientot sur l'autre sujet

[invite854f2515]

lien vers le nouveau sujet:
par ici

[invite4ba2d78b]

lien vers le nouveau sujet:
par ici

Pourquoi quand je clique sur le lien, on me dit que je n'ai pas l'autorisation d'ouvrir cette page?

[invitee05a3fcc]

Pourquoi quand je clique sur le lien, on me dit que je n'ai pas l'autorisation d'ouvrir cette page?

Parce qu'on est en 2009 et que le lien date de 2006 et que la page n'existe plus