bus 1-wire

[HULK28]

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.

[mizuki]

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

[invite76a]

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

[HULK28]

......, 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.

[Mkala]

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

[HULK28]

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.

[bibigeii]

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

[bibigeii]

lien vers le nouveau sujet:
par ici

[aurel2638]

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?

[DAUDET78]

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