Recherche sur le site Circuits et composants Guide d'achat Emplois Resources externe Forum de discussion Annonces Divers Connexion | Datasheet | Equiv. Nouv. | Cat. | Boitiers | Broches Audio-Vidéo | Téléphonie Informatique Offres | Ajout CVs | Ajout Cours | Montages | Logiciels Sociétés | Livres | Ajout lien Electronique | Informatique Dépannage | Hors Elec. Liste annonces Ajouter annonce Actualités | Barre d'outils Connecteurs | Contact

t digchip   Home » Diverses rubriques » Archive forum sujets+corp      Moniteur Sony CPD-1704 S   A la mise sous tension la led veille , s'allume une seconde puis s'éteind. On entend un sifflement, et c'est tout ! Ecran noir ensuite ! Je n'a pas le shéma, quelqu'un peut il m'aider à localiser la panne ! Merci par avance Un gars du sud ;o) Numéro de l'article: 56603   |  De: Francois34   |  Date: 2003-11-07 20:12:49    RE: Moniteur Sony CPD-1704 S il y a de grandes chences que le transfo tht soit en cc . 1 pour etre sur , dessoudez le transistor de puissance tht, vérifiez s'il est en cc. si c'est le cas le remplacer 2 dessouder la tht et rallumez , on ne doit plus entendre le sifflement . Numéro de l'article: 56771   |  De: jl   |  Date: 2003-11-09 18:17:55    RE: Moniteur Sony CPD-1704 S Bonjour Remplacer le petit condensateur chimique C 911 situé au primaire de l’alimentation et votre problème devrait être résolu ( c’est une panne typique sur ce modèle ) Dominique. Numéro de l'article: 56925   |  De: dom   |  Date: 2003-11-10 19:55:43    Quelle classe d'amplificateur ?   Bonsoir ! A quelle classe d'amplificateur , appartient le schéma visible a l'adresse suivante ? http://xoomer.virgilio.it/fladelle/Page2.htm A?; AB ? ... Merci et bonne soirée ! Numéro de l'article: 56605   |  De: Tronic-man   |  Date: 2003-11-07 21:53:21    RE: Quelle classe d'amplificateur ? Salut, moi je pense a un ampli de classe A, car les amplis de classe A, ont une puissance moins elevée que la classe AB, mais la classe A, a une distorsion plus faible que la classe AB donc de mélior qualité. Bonne soirée nico Numéro de l'article: 56609   |  De: nicolas   |  Date: 2003-11-07 22:49:42    RE: Quelle classe d'amplificateur ? Salut, Rappel, sans courant de repos dans les fets ce serait un 'classe B'donc avec distorsions qui sont toujours à réduire ! Comme indiqué dans la 'Note', par R11 régler I drain à 100mA, donc c'est un ampli classe A. cd Numéro de l'article: 56610   |  De: cd   |  Date: 2003-11-07 22:57:58    RE: Quelle classe d'amplificateur ? Salut, Classe AB traditionnel. Numéro de l'article: 56617   |  De: popelix   |  Date: 2003-11-08 02:20:33    RE: Quelle classe d'amplificateur ? ...Classe "A" ou "AB" alors ? je penche plus vers "A" comme "cd" la dit, mais "popelix" dit "AB"...je suis un peut perdu, je suis qu'un amateur... vous pouvez confirmer, que c'est un classe "A" ?... Si donc, c'est effectivement un classe "A", c'est un ampli de très bonne qualité, je pense ! Encore merci... Numéro de l'article: 56627   |  De: Tronic-man   |  Date: 2003-11-08 09:44:05    RE: Quelle classe d'amplificateur ? Salut Classe AB selon réglage / R11. (Avec 100 mA de courant) A+ Numéro de l'article: 56631   |  De: SuperPapum   |  Date: 2003-11-08 10:51:36    RE: Quelle classe d'amplificateur ? ok ,merci. Numéro de l'article: 56632   |  De: Tronic-man   |  Date: 2003-11-08 10:54:19    RE: Quelle classe d'amplificateur ? Salut, C'est un classe AB. @+ Numéro de l'article: 56634   |  De: Zell   |  Date: 2003-11-08 11:00:01    RE: Quelle classe d'amplificateur ? merci. Numéro de l'article: 56686   |  De: Tronic-man   |  Date: 2003-11-08 21:38:53    RE: Quelle classe d'amplificateur ? Bonjour C'est un classe AB A bientôt Numéro de l'article: 56694   |  De: EPERVIER   |  Date: 2003-11-08 22:01:41    RE: Quelle classe d'amplificateur ? salut d'apres ces caractristiques ca ma l'air d'un amplificateur de bonne qualité. je me trompe?? +++ Numéro de l'article: 56741   |  De: lolo56   |  Date: 2003-11-09 13:46:04    RE: Quelle classe d'amplificateur ? c un classe AB. Car c un push-pull avec polarisation Numéro de l'article: 56795   |  De: FABRICE   |  Date: 2003-11-09 20:25:27    Panne sur TV sony KV-X2540B(AE1C)   A le mise sous tension la led rouge s'allume une fois et s'eteint puis plus rien merci d'avance Numéro de l'article: 56606   |  De: roland   |  Date: 2003-11-07 21:56:27    RE: Panne sur TV sony KV-X2540B(AE1C) lorsque la led sallume et que la led marche arret la panne est situer en alim primaire change les condo pret du radiateur d'alim a plus. marc Numéro de l'article: 56665   |  De: bathedou   |  Date: 2003-11-08 17:36:29    RE: Panne sur TV sony KV-X2540B(AE1C) Salut, par hasard vous n'auriez pas un schema ? Numéro de l'article: 57068   |  De: boblaiponge   |  Date: 2003-11-11 22:50:24    recherche dissipateur peigne   Salut, Je recherche un dissipateur "peigne" du même genre que celui-ci: http://www.radiospares.fr/cgi-bin/bv/browse/Module.jsp?BV_SessionID=@@@@1919567879.1068239723@@@@&BV_EngineID=ccccadcjkjjhekdcfngcfkmdgkldfhf.0&cacheID=f1ie&3245692905=3245692905&catoid=-951358251 Le problème c'est que ce profilé n'est vendu qu'en morceau de 1m et vu le prix!! Alors si parmis vos stocks de recup vous avez un bout de profilé de dimensions approchées à celui ci en longeur de 5 à 10cm, je suis interessé. Contactez moi: ****************** Merci MANU Numéro de l'article: 56607   |  De: MANU   |  Date: 2003-11-07 22:33:00    RE: recherche dissipateur peigne Mets voir plutôt la référence de ce profilé. Le lien est périmé. Numéro de l'article: 57017   |  De: Fas54   |  Date: 2003-11-11 16:35:08    ideflasher...?   salut a tous le monde je voudrais savoir si quelqun connait ca : http://www.loet.de/flasher_en.html http://www.loet.de/images/ideflasherSchematic.gif et si quelqun a le typons de ce circuit ? amicalement ! Numéro de l'article: 56608   |  De: toi-mon-toi   |  Date: 2003-11-07 22:47:02    Ch info sur protocole de lecture sur une SIM card   Salut a tous... je cherche actuellement des infos (textuelle, site, ou autre) sur le protocole de communication à utiliser pour faire une sauvegarde du phonebook d'une SIM (dont je connais le code PIN bien entendu...) J'ai a ma dispo un socket de connection, un port // de PC avec tout ce qui faut pour dialoguer par ce dernier, pis un pic 16F84 au cas ou le timing serait serré (ce que je crois)... Et je peux aussi faire dialoguer le pic en serie vers un port du même accabit... J'ai aussi un programmateur Apollo pour Fun et Cie, qui pourrait peut etre servir, mais avec un micro controlleur propriétaire et non documenté... Numéro de l'article: 56611   |  De: Guillaume   |  Date: 2003-11-07 23:41:11    comment tester un quartz?   salut exite t il un montage ? merci d avance @+ Numéro de l'article: 56613   |  De: fthi   |  Date: 2003-11-07 23:56:59    RE: comment tester un quartz? Salut ! ben si tu as un pic genre 16f84 tu ecris un petit programme qui te sort un signal carré (sous multiple de la frequence F/4 de ton Quartz, pis tu ecoute la frequence de sortie... ca te donnera une idée... M'enfin y'a peut surement plus simple... Numéro de l'article: 56614   |  De: Guillaume   |  Date: 2003-11-08 00:15:48    RE: comment tester un quartz? Bonjour, Faut savoir aussi utiliser Google ! Une recherche avec testeur+quartz donne de multiples adresses dont celle-ci : http://membres.lycos.fr/pjacquet/quartz.htm André01 Numéro de l'article: 56625   |  De: André01   |  Date: 2003-11-08 09:11:40    RE: comment tester un quartz? Salut j' ai aussi cela : http://etronics.free.fr/montages/mesure/AME02.htm @+++ dan Numéro de l'article: 56693   |  De: dan   |  Date: 2003-11-08 21:57:12    choix d'un transistor MOSFET   bonjour, Je suis à la recherche d'un transistor MOSFET canal P destiné à couper l'alimentation 500ma d'un circuit alimenté par l'USB afin de pouvoir activer la com USB avec une conso qui doit rester <100mA. Je cherche donc un MOSFET canalP : -capable de passer facilement les 500mA -Capable de passer ce courant avec une faible resitance ON et ce avec -5V de tension grille source seulement (on appele ca MOSFET à commande logique non ?) -en boitier SOT223 -super courant (trouvable "partout", radiospares si possible, je dois leur faire une commande bientot...) -et concu pour ce genre de fonction (commutation d'alim) Vous devez vous dire "cherche dans les docs pour trouver ton bonheur, demerde toi !"...En fait, j'ai bien cherché et j'ai bien trouvé des transistors que je crois capable de ce que je veux (un paquet meme), mais ils sont tous fait pour des fonctions bisaroides que je ne connais meme pas (driver de ci ou commutation de ca...) et je suis finalement jamais sur de mon coup...surtout que les prix vont du simple au sextuple pour des performances qui, suivant mes critères, semblent les memes :-(( merci d'avance pour vos propositions de ref ou pour vos conseils, critères et techniques de choix Numéro de l'article: 56618   |  De: petitours   |  Date: 2003-11-08 02:43:33    prog in situe des 68HC908   bonjour, Je me suis mis depuis quelques temps aux 68HC908 avec grande satisfaction car cette gamme tres riche et large de microcontroleurs est pas chère, tres puissante et facile d'utilisation... Je les programme avec un programmateur inspiré de celui decrit sur le jeune mais déjà superbe site de YBdesign www.le68HC908.fr.st Avec ce programmateur, on met le 68HC908 dans un support, on le programme, puis on le retire pour le placer ensuite sur sa carte définitive. Quand on utilise un petit "monstre" à 64 pattes au format cms QFP comment fait on pour le programmer ou reprogrammer puisque on ne peut le retirer de sa carte ? Comment gère on toutes ces lignes "condamnées" pour la programmation ? Comment fait on si on utilise un quartz à 16MHz pour l'appli alors qu'il faut 4.915 ou 9.83 MHz pour la prog ? merci d'avance Numéro de l'article: 56619   |  De: petitours   |  Date: 2003-11-08 03:03:56    RE: prog in situe des 68HC908 salut. pour le programmer tu doit passer en monitor mode. Dans la doc de ton micro il doit y avoir tout les détail pour le configurer, en suite cela depand du materiel que tu possède: si tu as une mon08 multilink ou cyclone (p&e microelectronics) c'est tout simple tu l'as branche sur les broche du micro et tu utilise le logiciel fournie. sinon il existe plusieur instructions en monitor mode qui te permettent de programmer la flash (write, read,iwrite...) les instruction et les donné sont transmise en serie sur une broche est il te faut donc une petite interface pour adapter les niveaux rs232 vers le micro. donne moi + de détail sur ton materiel. je comprend pas les lignes "condamnées" pour la programation?? Le quartz ne gene pas tu peut utiliser un quartz 16Mhz je l'est déja fait. Numéro de l'article: 58886   |  De: seb   |  Date: 2003-11-24 21:57:14    Probleme TV DUAL Star2000: code parental   Bonjour, j'ai un soucis avec mon téléviseur, faisant des essaie pour la reception de l'image de mon ordi j'ai appué par erreur sur le verrouillage parentale du televiseur. n'ayant jamais rentré ce code qui est celui d'origine sur mon televiseur DUAL Star2000, qq'un a t il une idée sur comment pouvoir le deverrouiller ? désolé pour l'apparté et merci... Numéro de l'article: 56621   |  De: NRH   |  Date: 2003-11-08 06:26:46    RE: Probleme TV essaye un code du genre 0000 Numéro de l'article: 56623   |  De: frederic   |  Date: 2003-11-08 08:11:22     Probleme TV J'espère que vous avez pu réparer, nous sommes le 3 décembre. La technologie c'est super mais quand ça déconne on est plus qu'emmerdé. J'ai le meme problème de verrouillage et la meme non-volonté de verrouiller sur un téléviseue BLAUPUNKT. salut Numéro de l'article: 60102   |  De: COSSARD   |  Date: 2003-12-04 11:33:13    Liaison série bi directionnelle   Bonjour à tous, Je souhaite mettre en oeuvre une liaison série bi directionnelle en RS485. Le but est de faire dialoguer plusieurs cartes électroniques en mode multi-maître. (Je voudrais éviter le bus I²C qui ne possède pas assez d'adresses) Si vous avez des idées de protocole, surtout n'hésitez pas. Merci beaucoup Frédéric Numéro de l'article: 56622   |  De: frederic   |  Date: 2003-11-08 08:10:36    RE: Liaison série bi directionnelle Cela ne te suffit 128 ? Olivier Numéro de l'article: 56629   |  De: gemiolac   |  Date: 2003-11-08 10:40:14    RE: Liaison série bi directionnelle Ben non, il faut câbler un atelier de production entier. Pour commencer, il s'agit de contrôler l'accès à des zaones de travail (5 pour l'instant). A l'avenir, il faudrait pouvoir étendre ce bus à tout l'atelier pour contrôler le fonctionnement depuis un moniteur (de surveillance). Ce projet est très sérieux car il s'agit de ne pas dépenser 1500euro par contrôleur de porte (prix chez Siemens) ou par moniteur de machine En attendant, 128 sera suffisant mais il faut que je songe dès à présent à l'extension du bus. Peux-tu m'en dire un peu plus surles protocoles des bus de terrain genre CAN ou profibus??? Numéro de l'article: 56676   |  De: frederic   |  Date: 2003-11-08 19:01:51    RE: Liaison série bi directionnelle sur http://xavier.fenard.free.fr/Reseau%20RS485.htm il y a deja des morceaux... XF Numéro de l'article: 56708   |  De: XF   |  Date: 2003-11-08 23:51:20    RE: Liaison série bi directionnelle Salut ------ Laisse tomber le RS485 et passe au CAN. LE RS485 va te nécessiter un maître de bus, ou un protocole de communication compliqué, un seul interlocuteur peut parler en même temps, ce qui n'est pas le cas du CAN. Tu as le schéma et le logiciel d'un convertisseur CAN/RS232 sur mon site, rubrique "domocan". A+ Bigonoff Numéro de l'article: 56833   |  De: Bigonoff   |  Date: 2003-11-10 02:10:17    RE: Liaison série bi directionnelle Le CAN est pour l'automobile, on ne passe pas de données dessus, seulement des mesures,en CAN il n'y a pas d'AR. En clair, si l'info pression huile est perdu, c'est pas grave, elle sera retransmise dans la seconde suivante. Par contre perdre qq octets dans un fichier c'est une catastrophe. Le mieux c'est de mettre en RS485 le protocole OM AX25. En clair RS485: niveau0 (hard) le protocole X25 (niveau1 iso) garantie une transmission OK, des sources existent. Les radio amateurs (OM) utilisent le protocole, evidement en HF!!. Et la un fichier (des donnees)de l'autre bout de la terre arrivera (bon il faudra un routeur niveau 3). Sur une installation simple: un seul bus, le routeur n'est pas necessaire. Sinon, les cartes ethernets mais le soft n'est pas gratuit, et ce sont des boites noires...mais 100Mbit/s. Performance souhaitee? XF Numéro de l'article: 56973   |  De: XF   |  Date: 2003-11-11 11:14:02    RE: Liaison série bi directionnelle bonjour...pourquoi ne pas travailer en hf ....multimodulation...f1,f2,f3 etc...a+ Numéro de l'article: 56974   |  De: hacene   |  Date: 2003-11-11 11:27:20    RE: Liaison série bi directionnelle Pour la simple raison que c'est un milieu industriel ou des machines de découpe au laser travaillent en continu et que cela provoque assez de parasites EM. De plus, il faudrait une portée trop importante et passer à travers les murs. Merci pour l'idée Numéro de l'article: 56983   |  De: frederic   |  Date: 2003-11-11 12:44:51    RE: Liaison série bi directionnelle Je ne fais pas transiter des fichiers complets mais seulement des paramètres. Pour l'instant, je voudrais connecter des contrôleurs de portes (il faut juste transmettre les logs) puuis plus tard, on pourrait faire de la surveillance d'atelier en faisant transiter des paramètres tels que "Machine en production", "Machine en Panne", etc. Le CAN me parait une bonne idée. Numéro de l'article: 56984   |  De: frederic   |  Date: 2003-11-11 12:47:07    RE: Liaison série bi directionnelle Merci, je télécharge les fiches correspondantes et je te tiens au courant si le projet débouche (ce qui ne dépend pas de moi...) Merci Numéro de l'article: 56985   |  De: frederic   |  Date: 2003-11-11 12:48:12    RE: Liaison série bi directionnelle Effectivement, c'est le genre de réseau qu'il me faudrait. Merci Numéro de l'article: 56986   |  De: frederic   |  Date: 2003-11-11 12:50:32    RE: Liaison série bi directionnelle Effectivementy, c'est ce genre de réseau qu'il me faudrait, Merci XF Numéro de l'article: 56987   |  De: frederic   |  Date: 2003-11-11 12:52:02    RE: Liaison série bi directionnelle Attention le CAN ne garantie pas la suite des donnees.. c'est pas grave si une erreur n'entraine pas de consequence, mais sur une machine numerique.... un paquet de perdu et ca perce a cote de la plaque. XF Numéro de l'article: 57029   |  De: XF   |  Date: 2003-11-11 17:29:54    RE: Liaison série bi directionnelle Salut ------ Eh, XF, faut arrêter de raconter n'importe quoi! Le CAN est ultra-sécurisé, avec CRC inclus, répétition automatique des données, trames d'erreurs. Si tu veux tester mon bootloader CAN (sur mon site) tu verras si tu perds des octets. Le CAN garantit comme les autres la suite des données, tout dépend de la façon dont on met en oeuvre. Ton raisonnement est erroné. On peut numéroter les paquets, on peut aussi travailler avec un seul registre d'émission qui ne se libère que si la trame est correctement reçue par tous les destinataires. L'accusé de réception est automatique et intégré dans le protocole CAN. Je doute que dans une F1, ou sur un ABS, on se dise : "j'ai perdu des données, ce n'est pas grave, on me les renverra plus tard". LOL. Et dire : "on ne passe pas des données, on ne passe que des mesures", ça ne veut rien dire du tout. Tu devrais étudier attentivement le CAN, ta vision est un peu réduite à ce sujet. A+ Bigonoff Numéro de l'article: 57078   |  De: Bigonoff   |  Date: 2003-11-12 01:29:22    RE: Liaison série bi directionnelle En général, cetype de réseau a été pensé à l'avance, on n'a jamais vu un réseau concu pour perdre des informations en route. On s'arrange toujours pour les transmettre en entier Numéro de l'article: 57123   |  De: frederic   |  Date: 2003-11-12 13:52:42    RE: Liaison série bi directionnelle Desole, je maintien evidement TOUT. OUI on peut numeroter les paquets, declencher une retransmission etc... c'est la norme X25. Effectivement il y a un CRC, mais quand il est rejete (par un recepteur) l'emetteur ne le sait pas, donc l'info est perdu cf norme CAN. Dans la norme Auto destiné a la remise a jour du soft du calculateur de bord on ajoute au CAN le X25, d'ou 2 octets "utiles" par paquet CAN, et un temps de mise a jour des calculateur.... Le CAN sic "les motoristes" est un multiplexeur, il evite les fils (jauges, compte tours...) donc l'info (paquet CAN) recu doit etre bonne (le CRC CAN) mais si on en loupe une.. pas grave. Quand au systeme de collision avec priorite (CAN), qu'elle est la roue la plus prioritaire dans l'ABS? ...Le cafouillage des voitures avec ABS, d'ou un second reseau CAN... Heureusement que les avions de chasse( qui n'aiment pas les cables= poids)n'utilisent pas le CAN... Mais ARING bus a time slots, avec un maitre... defaut? son prix!!. A noter que le nouveau BUS AUTO LIN utilise un maitre. Mon but n'est pas de detruire le CAN, mais de dire pourquoi il a ete faite: du multiplexage de signaux, pas plus pas moins. La transmission de donnes sans rien perdre (X25) est d'autant efficace que le paquet est gros (DATA/ENCAPSULAGE>>>), CAN: paquetbrut =8!! XF Numéro de l'article: 57148   |  De: XF   |  Date: 2003-11-12 17:49:29    RE: Liaison série bi directionnelle Salut ----- XF, tu t'obstines à dire n'importe quoi. Tout d'abord ce que tu dis sur le CAN est faux : si on a une erreur de CRC sur un récepteur, une trame d'erreur est envoyée automatiquement à l'émetteur, qui réenvoie le message tout aussi automatiquement. Ca n'exite pas en RS 485. J'utilise le CAN pour des applications commerciales, et je sais comment il travaille. J'utilise également le RS485, et je connais les différences à l'utilisation pratique (entend la réalisation des cartes et des logiciels embarqués). Les trames "loupées", c'est n'importe quoi. Le CAN est très très sécurisé à ce sujet, alors que le RS485 ne dispose d'aucun mécanisme (ni accusé de réception, ni trames d'erreurs, ni CRC). Donc, on doit tout gérer par soft, par exemple un accusé de réception. Rien n'empêche, bien que ce soit inutile, de faire un accusé de réception supplémentaire sur CAN en soft pour confirmer la commande. Qui peut le plus peut le moins. Le CAN ne perd pas des trames, c'est n'importe quoi. Du reste, qui voudrait d'un bus qui perd des informations? Tes informations concernant la priorité des roues est louphoque. On travaille par messages, pas par adressage d'une carte. Donc, on peut envoyer le même message à plusieurs cartes simultanément. Le sujet de départ était la réalisation d'un bus de terrain permettant de faire dialoguer plusieurs cartes électroniques. Le CAN est précisément destiné à ça, quoi que tu en dises. Effectivement, la taille des octets est limitée à 8, car le CAN est un bus de terrain destiné à envoyer très rapidement des trames courtes, ce qui est tout à fait le cas lorsqu'on dialogue entre plusieurs cartes électroniques. En plus, la question initiale précisait qu'on désirait un mode multimaître, donc tout à fait conforme au bus CAN. Note que, à l'opposé de ce que tu dis, et étant donné le CRC codé sur 24 bits, la sécurité est d'autant plus grande que le nombre d'octets est faible (car on risque moins d'erreurs multiples qui s'annulent). Voici un copier/coller de la traduction d'un document officiel de chez Bosh (inventeur du bus CAN). Note, et ce n'est pas moi qui le dit, le "haut taux de fiabilité", le "mode multimaître", et la "détection des erreurs", ainsi que la "retransmission automatique des messages". Soit tout le contraire de ce que tu affirmes. **************************** Le protocole CAN (Control Area Network) est un protocole de communication série qui supporte des systèmes temps réel avec un haut niveau de fiabilité. Ses domaines d&#8217;application s&#8217;étendent des réseaux moyens débits aux réseaux de multiplexages faibles coûts. Il est avant tout à classer dans la catégorie des réseaux de terrain utilisé dans l'industrie pour remplacer la boucle analogique 20mA. La structure du protocole du bus CAN possède implicitement les principales propriétés suivantes : - hiérarchisation des messages. - garantie des temps de latence. - souplesse de configuration. - réception de multiples sources avec synchronisation temporelle. - fonctionnement multimaître. - détections et signalisations d&#8217;erreurs. - retransmission automatique des messages altérés dès que le bus est de nouveau au repos. - distinction d&#8217;erreurs : d&#8217;ordre temporaire ou de non-fonctionnalité permanente au niveau d&#8217;un n&#339;ud. - déconnexion automatique des n&#339;uds défectueux. ********************* Ajoute qu'on travaille en CAN avec de simples PICs à des vitesses de l'ordre de 1Mbits/s, et je ne vois pas que vouloir de plus pour l'application demandée. Un conseil, étudie ce bus avant d'en dire du mal. A+ Bigonoff Numéro de l'article: 57169   |  De: Bigonoff   |  Date: 2003-11-12 19:12:01    RE: Liaison série bi directionnelle Desole, je connait bien le CAN et le protocole... Effectivement si tu laisse un transmetteur CAN SEUL, il va constament re transmettre, jusqu'a ce que tu branches un autre module, qui renvoi l'ACK( AR en francais) MEME si le paquet ne lui est pas destine. C'est sur NON RECEPTION de l'ACK qu'il retransmet et non sur une ERREUR de CRC du recepteur CIBLE. Au niveau CRC, la "double erreur" ou la triple ne s'annulent pas, c'est pas un checksum. Le CRC est tres fiable sur la detection d'erreurs (sans correction) meme avec une taille superieure a 8 octets. Oui,8 octets: uniquement pour passer des parametres (temperature, pression..). Tu n'a pas compris le Pb des roues. Le CAN n'a pas ete prévu pour gerer des contre actions rapides, il peut partir (et des gens l'ont vu a leurs depends) en "vrille" sur l'ABS. Comme disent les motoristes: surchage du multiplexeur (le CAN). En fait c'est un probleme de reprise de collision sur des paquets de memes priorités!! (modules l'ABS). Et ca, c'est pas pardonnable sur un avion de chasse!. Si nous pouvons communiquer c'est parque la transmission est bonne!! Le RS485, est un niveau 0 (ISO): donc il faut effectivement mettre une couche X25 (niveau1) securisation des donnees(voir OM AX25). En clair, c'est plus facile de placer le X25 sur le RS485 que sur le CAN, (ce qui a ete fait pour la remise a jour des calculateurs!!). La taille fixe (8) est tres penalisant. Et l'ACK des qu'une station a recu le bon CRC (pas forcement celle qui dois recevoir le paquet) OBLIGE l'integralité de la couche X25!!. Le CAN (Bosh oui)a ete concus par des motoristes, mon but est d'expliquer son domaine d'utilisation: MULTIPLEXAGE pour la mesure ou la consigne. Enfin le CAN a beucoup evolué. Je vais pas faire l'historique. Grosso modo au debut le multiplexage devait fonctionner tout seul, le calculateur s'occupe uniquement du moteur. Avec les problemes, resolue en ajoutant d'autres fonctions, une grosse couche logiciel a été ajoutee. La derniere: le X25 pour assurer la couche 1 de l'ISO, "integrite des donnes"... avec ca tu peux faire du web!! XF Numéro de l'article: 57214   |  De: XF   |  Date: 2003-11-12 22:22:59    RE: Liaison série bi directionnelle Salut ----- Tu dis : "Effectivement si tu laisse un transmetteur CAN SEUL, il va constament re transmettre, jusqu'a ce que tu branches un autre module, qui renvoi l'ACK( AR en francais) MEME si le paquet ne lui est pas destine. C'est sur NON RECEPTION de l'ACK qu'il retransmet et non sur une ERREUR de CRC du recepteur CIBLE." Désolé, c'est faux. Si la trame est effectivement réémise en cas d'absence de cible, une trame d'erreur est automatiquement envoyée en cas d'erreur de réception de n'importe quelle carte connectée. La trame DOIT faire partie de la gestion hardware du fait de la norme, et doit provoquer le réenvoi du message. Donc, on est certain que le message est arrivé intact à toute carte connectée et en service (donc à la carte cible). De plus l'ack concerne l'intégralité des cartes connectées. Je cite : ************* Le champ d&#8217;acquittement possède 2 bits. La station émettrice de la trame laisse le bus libre pendant 2 coups d&#8217;horloge (ce qui correspond à l&#8217;émission de deux bits récessifs) et elle passe en mode réception pendant le premier coup d&#8217;horloge. Le premier bit correspond à l&#8217;acquittement par l&#8217;ensemble des n&#339;uds ayant reçu le message. Si aucune erreur n&#8217;a été détectée par un n&#339;ud (après calcul du CRC), ce dernier émet un bit dominant sinon il émet une trame d&#8217;erreur. La station émettrice du message originel doit alors être capable de réagir en fonction de l&#8217;émission d&#8217;un bit dominant ou non par les autres stations sur le premier bit du champ d&#8217;acquittement. Le second bit est un bit délimiteur d&#8217;acquittement qui doit toujours être récessif. ************ Tu dis : Au niveau CRC, la "double erreur" ou la triple ne s'annulent pas, c'est pas un checksum. Le CRC est tres fiable sur la detection d'erreurs (sans correction) meme avec une taille superieure a 8 octets. Oui,8 octets: uniquement pour passer des parametres (temperature, pression..). Je sais la différence entre un checksum et un CRC. En l'occurence, on peut aller jusque 5 erreurs. Je n'ai jamais nulle part dit que les erreurs doubles s'annulent. Par contre, au delà d'un certain nombre, on court le risque (faible, mais réel). Donc, comme j'ai dit, moins on a d'octets par trame, moins on a de risque, donc plus c'est fiable. De plus, tu abondes encore dans mon sens, puisque le CRC est INTEGRE au CAN, et tu dis que le CAN n'est pas fiable. Du reste, si tu veux la formule, la voici : g(x)=x15+x14+x10+x8+x7+x4+x3+1. En RS485, tu dois t'amuser à réaliser le polynôme par soft, en CAN c'est automatique. Note que 8 octets par trame, ça ne veut pas dire 8 octets en tout. J'ai bien précisé que le bus était adapté à des échanges rapides et sécurisés de trames courtes. Où ai-je dit le contraire? Par contre, ta vision du CAN est fort limitée, ça fait une paye que le CAN est utilisé dans un grand nombre d'applications, même s'il a été développé au départ pour le secteur de l'automobile. Je répéte une dernière fois que la question de départ concernait l'échange d'informations entre mode multimaître entre cartes électroniques. LE 485 n'est pas adapté à un mode multimaître, parce que les collisions sont destructives. Tu dis : "Tu n'a pas compris le Pb des roues. Le CAN n'a pas ete prévu pour gerer des contre actions rapides, il peut partir (et des gens l'ont vu a leurs depends) en "vrille" sur l'ABS. Comme disent les motoristes: surchage du multiplexeur (le CAN). En fait c'est un probleme de reprise de collision sur des paquets de memes priorités!! (modules l'ABS). Et ca, c'est pas pardonnable sur un avion de chasse!. " J'ai tout à fait compris. D'une part, où est-ce qu'on a parlé d'avions de chasse? D'autre part, chaque bus et chaque carte électronique a des limites physiques, et, si on les dépasse, on a des ennuis. Il suffit de faire l'étude correctement pour que ça n'arrive pas. Des trames CAN n'ont JAMAIS la même priorité, sauf si elles sont strictement identiques. J'ai peine à croire qu'on arrive à surcharger un bus CAN en répétant tout le temps la même chose, en même temps, et à partir de plusieurs modules distincts, qui, par définition n'envoient pas les mêmes informations. Si c'était le cas, ce serait une erreur de programmation, pas un défaut du CAN. Les motoristes, quand il y a un problème, c'est toujours la faute des autres, c'est connu. Maintenant, si un défaut CAN fait partir une voiture en vrille, il faut vite courir se plaindre chez Bosh et faire interdire le CAN. Le départ en vrille n'a JAMAIS été dû à une saturation du CAN, mais à des défauts intrinsèques à l'ABS (par exemple, il est pratiquement impossible de s'arrêter sur une neige dure avec un ABS). Les ABS mécaniques ou électroniques sans bus présentent STRICTEMENT le même problème. Ca n'a strictement rien à voir avec un avion de chasse, et ça ne démontre nullement l'inefficacité du CAN, c'est un problème de technologie ABS, parce que les paramètres sont difficiles à mettre en équation. LE CAN, il travaille jusque 1 Mbits/s. C'est clair que si une application (avion, haut-débit internet etc) nécessite une vitesse de 100Mbits/s, il faut passer à autre-chose. Ca ne veut pas dire que le CAN n'est pas fiable, ça veut dire qu'il n'est pas prévu pour ces vitesses. Mais dans ce cas, le RS485 ne convient pas non plus. Or, encore une fois, la question initiale portait sur le choix judicieux ou pas d'une liaison RS485. L'utilisateur n'a pas demandé à piloter un avion de chasse. Tu dis : "Si nous pouvons communiquer c'est parque la transmission est bonne!! " Ca, c'est clair. La-dessus, je suis d'accord, Lapalisse aussi. Tu dis : "Le RS485, est un niveau 0 (ISO): donc il faut effectivement mettre une couche X25 (niveau1) securisation des donnees(voir OM AX25). En clair, c'est plus facile de placer le X25 sur le RS485 que sur le CAN, (ce qui a ete fait pour la remise a jour des calculateurs!!). " Oui, ben tu essayeras de faire une liaison efficace et rapide en RS485 avec un système multi-maître. Tu vas devoir passer un jeton ou établir un protocole, sans aucun maître pour gérer ça. Si une carte ne répond plus, tu vas devoir placer dans toutes les cartes des temporisations de sécurité, pour savoir quoi faire en cas de plantage d'une carte etc. Ce n'est pas du tout, ni pratique, ni efficace. Je suis bien placé pour le savoir, j'ai réalisé un système domotique (entre autres) en RS485, et je suis en train de le recommencer en CAN, qui est beaucoup plus efficace, s'agissant de multi-maître. Il n'y a nul besoin d'un protocole supplémentaire pour encapsuler les trames CAN, vu que CRC, ACK, informations complémentaires etc. sont DEJA intégrés dans les trames CAN. Ton protocole, il ne fait que refaire par software (en moins puissant) ce qui est fait par hardware dans le CAN. Pour ce qui est de la confirmation de la bonne réception de la commande, il n'y a strictement RIEN qui empêche d'envoyer une réponse aux trames émises. C'est du reste ce que je fais sur une partie des commandes CAN de mon système domotique. Comme ça, mon logiciel de surveillance a une vue complète du réseau en temps réel. Une fois de plus, c'est plus simple à faire en CAN qu'en RS485. Tu dis : "La taille fixe (8) est tres penalisant. Et l'ACK des qu'une station a recu le bon CRC (pas forcement celle qui dois recevoir le paquet) OBLIGE l'integralité de la couche X25!!." La taille n'est pas fixe, la taille est de maximum 8 octets de data, plus 29 bits d'ID. Ce n'est nullement pénalisant si on a conçu le système en conséquence, et, je le répéte, des trames courtes sont plus sécurisantes que des trames longues. Certes un peu moins rapides (pour le cas où on a un grand nombre d'infos à envoyer), mais plus sécurisantes, et même plus rapides pour peu qu'on ait des perturbations ECM sur la ligne (on a moins à réenvoyer). On n'est obligé de rien du tout, tu as oublié les trames d'erreur en chemin. Si une carte reçoit un message erroné, elle renvoie AUTOMATIQUEMENT une trame d'erreur et le message est AUTOMATIQUEMENT renvoyé. Le seul cas où on aurait un problème ignoré, c'est celui où la carte de destination ne serait plus raccordée au bus, et, si on veut s'assurer de ce cas particulier, il suffit que la carte cible renvoie une trame d'ACK. Tu es du reste obligé de faire ça sur du RS485, même pour le CRC (tu dois tout prendre en gestion par soft). Sur le CAN, ce n'est utile que si la carte ne répond plus. Or, si la carte ne répond plus, à quoi sert de lui renvoyer l'information??? Le CAN n'a pas été pensé par des idiots, encore heureux. Tu dis : "Le CAN (Bosh oui)a ete concus par des motoristes, mon but est d'expliquer son domaine d'utilisation: MULTIPLEXAGE pour la mesure ou la consigne." Ta vision est beaucoup trop limitative. Ce n'est pas parce qu'un bus a été conçu pour une application qu'il ne convient pas pour une autre. Actuellement, le CAN est un des bus le plus en vogue dans les entreprises, or, j'ai rarement vu d'ABS sur un pont roulant. Tu dis : " Enfin le CAN a beucoup evolué. Je vais pas faire l'historique. Grosso modo au debut le multiplexage devait fonctionner tout seul, le calculateur s'occupe uniquement du moteur. Avec les problemes, resolue en ajoutant d'autres fonctions, une grosse couche logiciel a été ajoutee. La derniere: le X25 pour assurer la couche 1 de l'ISO, "integrite des donnes"... avec ca tu peux faire du web!! " Heuu, pour info, non seulement ta conclusion te contredit : si on sait faire du web, on peut échanger des données entre cartes électroniques. Ensuite, la couche 1 de la norme OSI définit non pas l'intégrité des données, mais la couche physique, elle-même scindée en 3 sous-couches : (PLS Physical Signalling), PMA (Physical Medium Access), et MDI (Medium Dependent Interface). Enfin, je ne parle pas d'un ancien hypothétique CAN initial limité, je parle du CAN actuel, le seul qui existe, et plus particulièrement de la version 2.0b. Mais bon, on ne va pas passer 10 ans la-dessus. Mettons que chacun reste sur ses positions, et que personne n'est convaincu. Celui qui veut se faire une idée par lui-même peut aller charger les docs chez Bosh, et peut aller télécharger sur mon site un bootloader CAN parfaitement opérationnel, et qui ne perd pas des octets, je le garantis. A+ Bigonoff Numéro de l'article: 57337   |  De: Bigonoff   |  Date: 2003-11-13 20:53:30    RE: Liaison série bi directionnelle Bonjour,mon but n'est pas de dire qui est le mieux, mais leurs utilisations. Le CAN pour le multiplexage donne/consigne en multimaitre avec des circuits complexe et "couteux" puisqu'il integre toute la gestion CAN. Dans une usine le CAN est pour la lecture des capteurs, la consigne au machine OK, mais luxe. Faire passer un message, non, il manque la couche X25.. Le RS485 est non multimaitre effectivement, l'USB aussi et le nouveau bus LIN et le bus avion c'est pas une tare, ca marche aussi oui tous ces bus recoivent un jeton. On place du multimaitre quand les stations ont la meme importances, ex des PCs (INTERNET 10/100Mbits/s). En RS485 le bus DMX (pour le controle des lumieres de spectacles) fonctionne,(il est vrai il est "rudimentaire"). Des lors qu'il y a un maitre (un calculateur, ou deux par redondance), des capteurs ou des actionneurs (esclaves) le mode mutimaitre n'est pas necessaire. C'est pour cela que les nouveaux bus ne l'ont pas . Enfin, en charge un syteme a collision de paquet, le bus peut "tomber" (un court instant dit temps de reprise) CAN /INTERNET pour eviter cela: deux bus CAN moteur/ABS!. Le time slot (GMS/ AVION)rudimentaire mais le plus efficace consomme. Les constructeurs automobile calcul les temps sur une chaine (le temps c'est de l'argent), si il avait trouver une methode plus simple (en utlisant les avantages du CAN) pour eviter de placer une couche X25, avec le temps induit, il l'aurait fait...En clair c'est plus long que le temps de programmation d'un octet de memoire flash ( et on aurait aime le contraire). XF Numéro de l'article: 57352   |  De: XF   |  Date: 2003-11-13 23:25:16    RE: Liaison série bi directionnelle Ci joint la norme "X25", l'introduction (en anglais). Prevu a l'origine pour le diagnostic (envoie d'ordre, message, dump..) Elle permet d'installer le network layer protocol. Par contre, mea culpa on peut passer 4/6 octes par paquet ( et pas deux) comme je l'avais dit (de memoire). ISO 15765 has been established in order to define common requirements for vehicle diagnostic systems implemented on a Controller Area Network (CAN) communication link as specified in ISO 11898 Road vehicles - Controller area network (CAN). Although primarily intended for diagnostic systems, ISO 15765 has been developed to also meet requirements from other CAN based systems needing a network layer protocol. To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO/IEC 7498 and ISO/IEC 10731 which structures communication systems into seven layers. XF Numéro de l'article: 57359   |  De: XF   |  Date: 2003-11-14 00:29:50    RE: Liaison série bi directionnelle On va bien voir, de toute façon, j'ai assez peu de temps pour mettre en oeuvre un système de controle des accès en service dans l'atelier. Je vais me renseigner chez Bosch pour les protocoles et les différentes couches. Peu importe le protocole uilisé pourvu que ca fonctionne et que ce soit facilement implémentable dans un µC. Le fait que le CAN possède des drivers tout prêts est séduisant car le RS485 ne possède pas de protocole défini donc les seuls drivers (que je connaisse en tout les cas) se limitent à convertir du 0-5V en signal symétrique. Merci à tous les deux Frédéric Numéro de l'article: 57372   |  De: frederic   |  Date: 2003-11-14 09:06:15    RE: Liaison série bi directionnelle De memoire je savais qu'une couche X25 ISO 15765 etait necessaire a cause de la perte de paquet en CAN, ( et pour cause j'ai ete dessus) j'ai effectivement fait une erreur sur le motif. Pourquoi l'ISO 15765?. A cause du principe du CAN: il donne toujours la derniere mesure/consigne , il ecrase donc le paquet precedent (d'ou la perte au sens reseau), pas de buffer. Aussi la norme ISO15765 met en place une negociation pour savoir a qu'elle rythme envoyer les paquets pour que le calculateur ait le temps de le recuperer avant qu'il soit ecrasé par le suivant. Ce rythme depend uniquement du programme, ce n'est donc pas le debit du CAN qui fixe le debit reel mais la caracteristique du soft. SeparationTimeMin (STmin): The minimum time the sender shall wait between the transmissions of two ConsecutiveFrame N_PDUs. Puis la norme reprend le X25 a savoir reprise en cas de perte... Les controleurs internet en hard reassemble les paquets d'ou le debit effectif de 10/100Mbits/s (et gere la couche X25 ou equ en hard) (collision multimaitre comme le can). En CAN, les motoristes veulent des controlleurs multifiltres pour le "maitre": le calculateur ou le PC.. (Intel, Siemens..) ainsi (1Filtre=1 canal=1mesure) ils ont en permanence (15) mesures en memoire, le calculateur s'occupe uniquement du moteur. Le chip Philips non multifiltre oblige le calculateur (host) a faire le tri en permanence. Le chip Philips est OK sur les capteurs, il envoi "tranquille" periodiquement la valeur mesuree. En mode CAN/Reseau on peut conserver avec les multifiltres par exemple 14 CAN, transparent et un avec action rapide pour recuperer les paquets reseaux (STMin faible). Quand mettre l'ISO 15765? Quand on veut envoyer un message de plus de 8 caracteres...(un numero de telephone!!). En ISO niveau 7: Application CONTROL (mesure/consigne) la norme CAN En ISO niveua 7: Application reseau (transfer de donne) CAN + ISO15657 Quand on recharge un programme pour un calculateur de bord on en peut pas se permettre d'oublier un morceau. Desole pour les imperfections de ma memoire, mais ca fait deja pas mal de temps que je fait plus de CAN. Mon objectif: donner des informations les plus precises. Il est capital de savoir ce qu'on peut faire, et dois faire avant d'installer un reseau!!. Au niveau soft "ouvert" GNU, le CAN est pauvre, les fabricants d'auto sont pas GNU!. Pour les reseaux domotique maitre, c'est plus ouvert en RS485 (USA tres utilise). Pour les reseux mutimaitres, c'est internet (voir le prix d'une carte reseau), ce serait mon choix pour une nouvelle etude y a du GNU qui pointe. XF Numéro de l'article: 57396   |  De: XF   |  Date: 2003-11-14 13:50:19    RE: Liaison série bi directionnelle Salut ----- Arf. Tu dis : "Le CAN pour le multiplexage donne/consigne en multimaitre avec des circuits complexe et "couteux" puisqu'il integre toute la gestion CAN. " Un pic, c'est coûteux? LOL. C'est exactement le même prix pour une liaison CAN avec un pic (PIC + MCP2551) que pour une liaison RS485 (PIC + MAX485) "Faire passer un message, non, il manque la couche X25.." LOL. On ne peut pas faire passer un message en CAN, première grande nouvelle. Je te le répéte, va voir sur mon site, LOL. Et en RS485, on peut sans doute? LOL. Le 485, il ne précise rien, on doit tout gérer par soft, on se contente d'envoyer des octets (bonjour le temps CPU consommé). " Le RS485 est non multimaitre effectivement, l'USB aussi et le nouveau bus LIN et le bus avion c'est pas une tare" Ben si, et une énorme en plus en fonction de l'application. Ca peut n'avoir aucune importante, mais ça peut aussi en avoir une énorme. Et je te rappelle l'énoncé de la question de départ : "Je souhaite mettre en oeuvre une liaison série bi directionnelle en RS485. Le but est de faire dialoguer plusieurs cartes électroniques en mode multi-maître. " Ca me semble clair. Donc, comme je dis depuis le début, le 485 ne CONVIENT PAS. Le CAN OUI. Dur dur. Tu n'as qu'à essayer de réaliser mon système domotique décentralisé avec ton RS485, pour rire un coup. "ca marche aussi oui tous ces bus recoivent un jeton. On place du multimaitre quand les stations ont la meme importances, ex des PCs (INTERNET 10/100Mbits/s). " Le jeton, c'est un pis-aller. C'est fortement dérangeant car chacun doit savoir qui va prendre la parole après. Et si on passe la parole à quelqu'un qui n'a rien à dire, il doit répondre "je n'ai rien à dire". En cas de perturbation du réseau, il faut savoir à qui revient le jeton, et que faire si celui à qui revient le jeton ne répond pas suite au plantage du réseau, etc. En cas d'un plantage quelconque, on risque que deux stations aient le jeton en même temps, etc. C'est pénible si on veut que tout le monde puisse prendre la parole uniquement lorsqu'il a quelque chose à dire. Le multi-maitre, ce n'est nullement quand toutes les stations ont la même importance, l'I²C fonctionne en multimaître même si les périphériques ont des rôles différents. L'avantage du multimaître, c'est qu'on peut parler sans attendre d'avoir le droit à la parole, et qu'il n'y a besoin de personne pour gérer la communication. X peut parler à Y pendant que U parle à V, sans problème. Mettre ça en place avec un RS485, c'est un challenge. "En RS485 le bus DMX (pour le controle des lumieres de spectacles) fonctionne,(il est vrai il est "rudimentaire")" Ce n'est pas du tout la même application. On a un pilote et des esclaves, donc pas de multimaître. Je n'ai pas dit que le RS485 n'était pas un bon bus (je viens encore de le mettre en application dans un appel infirmière sophistiqué pour une maison de repos, avec une centrale, donc un maître) j'ai dit qu'il ne convenait pas à l'objectif initial, c'est à dire multimaître (ou sans maître, ce qui revient au même). "Des lors qu'il y a un maitre (un calculateur, ou deux par redondance), des capteurs ou des actionneurs (esclaves) le mode mutimaitre n'est pas necessaire" Ben, C'est encore une lapalissade. Justement, le problème se pose quand il n'y a pas de maître, et c'est le cas de la question d'origine. L'internaute n'a pas demandé "le multimaître m'est-il nécessaire? Mais : "comment mettre en oeuvre une liaison multimaître?". Répondre à l'intérêt ou pas du multimaître équivaut à connaître l'application, et on ne la connait pas. "C'est pour cela que les nouveaux bus ne l'ont pas " Ca ne veut strictement rien dire. Un bus est prévu pour gérer ou pas les collisions, le multimaître ou pas. Ca dépend du cahier des charges prévu lors de sa création, ça n'a strictement rien à voir avec une quelconque mode ou un problème de date de création. "Les constructeurs automobile calcul les temps sur une chaine (le temps c'est de l'argent), si il avait trouver une methode plus simple (en utlisant les avantages du CAN) pour eviter de placer une couche X25, avec le temps induit, il l'aurait fait...En clair c'est plus long que le temps de programmation d'un octet de memoire flash ( et on aurait aime le contraire). " Ecoute, cette fois-ci, tu dis vraiment n'importe quoi. Une dernière fois, va sur mon site, et teste le bootloader CAN. TU verras si c'est la programmation flash qui attend le CAN ou le contraire. Je pilote des messages de tout type avec des trames CAN, et ce, sans aucun problème. UNe trame CAN se suffit à elle-même. Rien n'empêche d'ajouter des protocoles softwares, du reste, il faut bien établir les règles pour les ID, mais rien qu'avec l'envoi et la réception de trames, on fait ce qu'on veut. Les contructeurs automobiles, ils ont ajouté une couche dans leurs microcontrôleurs, qui leur permet de développer des applications indépendantes du microcontrôleur sur lesquels ils tournent. C'est un noyau multitâche, les procédures sont chargées sous forme de tâches. Les trames répondent aussi à une structure particulière, ce qui explique les protocoles mis en place. Tout ça est fait uniquement pour limiter les coûts de production, et pour que le logiciel développé par X puisse être utilisé par le fabricant de cartes Y pour être montés sur une voiture Z. Bref, ça leur permet d'échanger les logiciels pour éviter les frais de développement. On ne parle pas de ça ici. Quand à ta référence, il est clair, et je n'ai jamais dit le contraire, qu'on peut utiliser des octets de data (en l'occurance 2) pour établir des informations complémentaires, dans le but de libérer un maximum d'ID possible, et donc d'élargir le champ d'application. Cependant, ce n'est NULLEMENT indispensable. Mes applications ont à disposition les 8 octets de data pour l'usage interne, et le système est parfaitement sécurisé. Si je décide d'ajouter une couche qui précise que D0 et D1 représentent, par exemple, un numéro de réseau, ou un numéro de trame, alors je perds 2 octets, MAIS ça dépend de l'application envisagée et ce n'est NULLEMENT une obligation. Si je fais pareil avec un autre bus, il faut bien que j'ajoute des infos également (c'est ce qui se fait dans le TCPIP). Ca ne ralentit pas plus sur le CAN que sur un autre bus. Simplement, vu que le CAN limite le nombre d'octets à 8, je décomptes 2 octets sur les 8 possibles au lieu d'ajouter 2 au nombre initial. On obtient des trames plus courtes en CAN, mais plus sécurisées, soit le contraire de ce que tu dis. "De memoire je savais qu'une couche X25 ISO 15765 etait necessaire a cause de la perte de paquet en CAN" Tu t'obstines, mais il n'y a PAS de pertes de trames en CAN, SAUF si le système est mal conçu. Le RS485 ne dispose d'AUCUN moyen de vérification d'intégrité hardware, et est donc plus fragile que le CAN A-t-on jamais vu quelqu'un qui propose un bus qui perd des informations? Je t'ai démontré qu'il y avait des mécanismes, et lesquels. Toi, tu te bornes à répondre "le CAN perd des trames". La discussion n'est pas constructive, tu n'a répondu à aucune argumentation technique. "A cause du principe du CAN: il donne toujours la derniere mesure/consigne , il ecrase donc le paquet precedent (d'ou la perte au sens reseau), pas de buffer. " ARGGG. !!! AUCUN (NOTHING) message n'est écrasé en CAN. Les trames sont reçues dans un des buffers de réception (si si, des buffers) du micro de gestion CAN, et APRES masquage et filtrage. Partant de là, tout soft bien fait vide le buffer par interruption, et sauve le message pour traitement ultérieur si besoin est. Durant ce temps, la trame suivante arrive dans le buffer de comparaison, pour y être exposée aux masques et filtres avant rangement dans les buffers de réception, S'ils sont vides. Le logiciel a donc largement le temps de vider le buffer de réception (et il y en a souvent plusieurs) avant l'arrivée du message suivant. De toutes façons, le message ne sera jamais écrasé, tu auras dans le pire des cas (si tu ne traites pas les messages entrant) un message de type "overflow". Car, c'est clair que, et pour n'importe quel bus, si tu ne vides pas tes buffers d'entrée, tu vas finir par ne plus pouvoir recevoir. Essaye en RS485 pour rire un coup. Et encore, en RS485, avec un micro, tu es obligé de vider octet par octet, tu es obligé de lire TOUTES les trames, même celles qui ne te concernent pas. Par contre, en CAN, tu ne vide que trame par trame (donc on a beaucoup plus de temps), et, en plus, on ne reçoit que les trames qui sont destinées à la carte (donc on consomme de 10 à 1000 fois moins de temps CPU en fonction de l'application). Franchement, ce que tu dis là démontre que tu as lu des infos sur le CAN, mais que tu les a mal comprises, et probablement jamais mises en application dans un microcontrôleur. Il ne faut pas confondre les limites du CAN avec les limites de certains contrôleurs CAN désuets d'il y a quelques années. De même, si j'utilise un PIC à 1Mhz pour traiter des trames RS485 à 1Mbits/s, je ne vais jamais y arriver. "Intel, Siemens..) ainsi (1Filtre=1 canal=1mesure) ils ont en permanence (15) mesures en memoire, " Un 18F248 : 6 filtres et 2 masques. Faut évoluer. En interne, 3 buffers de réception hardware, et 2 fois 256 octets de buffer en soft. "Quand mettre l'ISO 15765? Quand on veut envoyer un message de plus de 8 caracteres...(un numero de telephone!!). " Tssss. Je fais un bootload d'un programme de 32Koctets avec des trames CAN, sans utiliser de protocole spécifique autre qu'un simple échange de trames CAN. Ce que tu dis n'a aucun sens. Je répéte encore une fois : 8 octets de data par trame, ça ne veut pas dire 8 octets en tout. Tu peux gérer les data comme bon te semble. Evidemment, il te faut des conventions, ou un protocole de ton choix, MAIS c'est pareil avec tout échange de données, que ce soit RS485 ou TCPIP, par exemple. Ce n'est nullement une limitation du CAN, simplement un choix entre trames courtes et trames longues. "Quand on recharge un programme pour un calculateur de bord on en peut pas se permettre d'oublier un morceau" On n'OUBLIE RIEN EN CAN, pas plus qu'avec un autre réseau si le réseau est correctement mis en oeuvre. Si on perd quelque chose, ce n'est pas la faute du réseau, c'est la faute de sa mauvaise mise en oeuvre, ou d'une mise en oeuvre inadaptée au fonctionnement requis. Tu crois que je peux me permettre d'oublier un morceau quand je recharge un PIC? LOL. Et mon application domotique n'est pas la seule où j'utilise un bootloader CAN, j'ai aussi une grosse application commerciale, avec upgrade par le client en CAN, carte en service. C'est comme si je disais : en RS485, on perd des informations, parce que mon contrôleur n'arrive pas à tout lire à cause qu'il n'a pas le temps de vider son buffer. C'est insensé de dire ça. "Desole pour les imperfections de ma memoire, mais ca fait deja pas mal de temps que je fait plus de CAN. " Ben, j'avais cru comprendre, oui. Tu confonds sans doute les limitations du CAN avec les limitations des anciens périphériques de contrôle obsolètes. "Il est capital de savoir ce qu'on peut faire, et dois faire avant d'installer un reseau!!. " AHHHHHHHHHHH, enfin. Donc, je te rappelle que l'utilisateur VOULAIT un réseau multimaître. Et le CAN est le plus adapté dans ce cas. "Au niveau soft "ouvert" GNU, le CAN est pauvre, les fabricants d'auto sont pas GNU!." Qu'est-ce que ça a à voir? Qui veut construire un ordinateur de bord pour automobile??? Le CAN est beaucoup moins pauvre que tu ne penses, cherche mieux sur le net. "Pour les reseaux domotique maitre, c'est plus ouvert en RS485" Effectivement, MAIS on ne veut pas du maître !!!! On a dit "multimaître". Si l'utilisateur avait parlé d'une centrale qui pilote des cartes esclaves, je lui aurait dit "RS485", parce que c'est plus simple à comprendre. J'ai fait une installation domotique RS485 en maître, ce n'est pas pratique. Une panne du maître et plus rien ne va dans la maison. En plus, on passe son temps à interroger les cartes, ou on doit ajouter des fils de requête de parole. Pas pratique. Avec mon système, une panne = panne de la fonction, le reste tourne toujours, c'est beaucoup plus flexible. Pas d'événement = aucun trafic sur le bus, c'est plus économique. "Pour les reseux mutimaitres, c'est internet (voir le prix d'une carte reseau)" Ben, tu essayeras de connecter ta carte réseau sur un microcontrôleur. A moins que tu ne veuilles faire un système domotique avec un PC par fonction? LOL. Je te rappelle qu'on parle d'échange d'informations entre cartes électroniques, et non entre PC. "ce serait mon choix pour une nouvelle etude y a du GNU qui pointe." Moi, ce n'est pas mon choix, et ce n'est pas "serait", c'est "c'est". Et tout sera disponible gratuitement sur mon site, avec les sources. C'est peut-être pas officiel "gnu", mais pour l'utilisateur, c'est tout comme. Et des sites qui proposent des réalisations CAN gratuites, il y en a d'autres, je ne suis pas le seul. Des systèmes domotiques décentralisés à base de carte "réseau internet", j'ai pas trouvé, même en GNU, désolé A+ Bigonoff Numéro de l'article: 57462   |  De: Bigonoff   |  Date: 2003-11-14 20:29:55    RE: Liaison série bi directionnelle Bonjour, Evidement que l'on peut faire des choses qui "fonctionnent", mais quand il sagit de passer a une normalisation (ISO), puis sur un banc de test (de stress), la couche est complexe, et les performances s'en ressentent. Oui, sur table on charge vite une flash, mettre la couche X25 n'a pas ete une partie de plaisir. On est d'accord, le temps de latence d'IT definit le taux de transfert max. Dans un systeme "heterogene" (en CAN et autres) il faut un preambule de negociation... Des protocoles sur les coins de tables, j'en ai vu, j'en ai fait aussi, et j'ai vu des degats, donc depuis longtemps j'ai compris qu'il faut, meme si c'est lourd UTILISER les ALGORITHMES des couches ISO. (meme les OM l'on compris avec l'AX25) Cette normalisation n'est pas facile a mettre en oeuvre, souvent c'est en equipe de programmeur. Effectivement la question etait "multimaitre avec RS485", c'etait pas possible electriquement, le debat ici est ouvert, la reponse est "avant le choix de l'implementations il faut definir un cahier des charges." Le CAN, le RS485 LIN ... ont leurs avantages et leurs inconvenients, un conseil, en pro, la solution passe par l'ISO. A+ XF Numéro de l'article: 57493   |  De: XF   |  Date: 2003-11-14 22:42:47    RE: Liaison série bi directionnelle Salut ----- Respecter l'ISO, ça ne veut strictement rien dire. La norme CAN définit 2 couches ISO, les autres sont au choix de l'utilisateur. Une fois que tu établis un protocole, même comme tu dis "sur un coin de table", on crée une couche ISO. Respecter une couche ISO particulière est utile si et seulement si on désire une compatibilité avec un autre système utilisant les même contraintes sur la même couche. Dans le cas contraire, ça ne signifie strictement rien. Pourquoi devrais-je respecter une couche ISO définie pour les échanges sur les bus automobiles si mon désir est d'interfacer mon CAN avec internet, ou avec un système déjà existant? Ca n'a aucun sens. Dire "en pro, la solution passe par l'ISO" ne veut strictement rien dire du tout. ISO quoi? quelles couches? Quel protocole? Pourquoi faire? Si par "pro", tu entends un type qui développe des applications commerciales, alors je suis un "pro", et mes systèmes fonctionnent parfaitement. Je ne respecte une norme particulière d'une couche ISO que si j'en ai l'utilité, par exemple si je veux m'interfacer sur un bus existant, ou si je veux être compatible avec une application particulière. Dans le cas contraire, je respecte les couches ISO imposées par le type de bus que j'utilise (2 couches en l'occurance pour le CAN), et le reste, j'utilise à ma meilleure convenance. Il n'y a pas de couche ISO qui contienne un seul et unique mode de fonctionnement. On ne peut pas dire : "je suis compatible ISO", c'est une abbération. Passer au banc de stress, c'est principalement vérifier les problèmes de CEM (90%), et vérifier qu'on a bien mis en oeuvre le bus (10%). Il n'y a PAS d'algorythme ISO à appliquer dans tous les cas, tu mélanges tout. Il y a des contraintes de certaines couches en fonction de certains systèmes, il n'y a rien d'universel. Les définitions des couches sont complètement différentes pour le CAN que pour le TCPIP. Certaines couches dans certains systèmes sont ouvertes, pour permettre justement d'interconnecter, par exemple, une couche physique de son choix sur un protocole de transmission déterminé. Franchement, j'ai l'impression que tu mélanges un peu tout. C'est mon avi A+ Bigonoff Numéro de l'article: 57612   |  De: Bigonoff   |  Date: 2003-11-15 18:59:41    RE: Liaison série bi directionnelle Bonjour, L'ISO sert a permettre une interoperabilite, quant on veut s'ouvrir vers l'exterieure, pas seulement dans son coin. L'automobile, demmandes des fonctions, l'industrie aussi, l'ISO donne des fonctions, reprend ce qui existe quand elle constate que cela repond a la fonction. Ex: le port centronic, fonction: impression... IEE488: mesure avec ce bus. Pour le CAN c'est mesure/controle, puis transmission de donne. Oui, l'automobile a ete (et est) un precurseur dans la normalisation (enjeu economique). Bosh c'est l'auto. Pour le diag on CAN (auto) fonction transmission de data, effectivment les circuits CAN (ex microchip) on evoluee, deux modes: CAN ou buffer (pour l'X25 le diag on CAN, la fenetre plus grande, l'IT plus souple...) En utilisant l'ISO 15765 on peux "melanger" les vieux contoleurs, les actuels et les futurs.. c'est aussi ca une norme. En "pro" pour les industriels (eviter le veto d'une propal) toutes les solutions doivent etre basée sur des fonctions "ISO", quand elles existent. Pour les autres fonction un dossier "solide". Proposer "sa solution fonction" en remplacement d'une de l'ISO?, veto: interoperabilite sans aller plus loin. L'ISO c'est surtout un algorithme QUI MARCHE et permet de savoir rapidement ce qu'il faudra POUR realiser la FONCTION (code, taille). Meme l'algo du jeton n'est pas evident. C'est pas Pasteur qui a invente les microbes, ni la CEM, en 1985 sur un reseau internet (pro DEC) tranceiver dans les faux plafonds, on detectait l'allumage des neons ou certain neon HS (starter) en monitorant les reprises, au niveau transfert de datas pas de pbs. Un stress type: un groupe A de modules CAN avec l'emetteur du paquet, bien plus loin un groupe B. A et B doivent recevoir l'info de l'emetteur. Au moment du paquet, parasite sur B (maximum), perturbe pas A. L'emetteur saura t il que B n'a rien recu ?. OUI c'est du CEM, mais aussi verifier que le systeme retombe sur ces pieds.. les fonctions (cas CAN et cas Transfert de data) seront elles assurées?. Le plus grave c'est quand on voit rien, une cloture de session c'est moins grave: au moins on sait a quoi s'en tenir.... L'ISO donne la fonction: presentation, routage (couche)... meme printer (fonction), l'algo (enchainement, automate), pas l'implementation. Je prefere mettre un petit ISO simple, JETON maitre/esclave, un petit PIC 628, a 19K2 (domotique) (genre Domosysteme, un vieux fabricant "domotique") plutot que mi rapide non ISO. De toute facons en ce moment, quand on passe un cable dans une maison, c'est un coax!! (quand pas un 100mbit avec routeur) , pour relier les PC de la maison... et plus quand ca existera (domotique). A+ XF Numéro de l'article: 57657   |  De: XF   |  Date: 2003-11-16 00:43:56    RE: Liaison série bi directionnelle Salut ----- >"L'ISO sert a permettre une interoperabilite, quant on veut s'ouvrir vers l'exterieure, pas seulement dans son coin. " L'ISO détermine les couches, et, au sein de chaque couche, on peut avoir toutes sortes de protocoles. On utilise les protocoles correspondants quand on veut s'interconnecter avec un système déterminé. Sans quoi, ça n'a aucun sens. Du reste, il est impossible d'être compatible avec tout, et donc il faut choisir en fonction de l'application. Ce que tu appelles "l'interopérabilité" est utopique. Tu ne peux être compatible qu'avec un système précis, et pas avec tout. >"Pour le CAN c'est mesure/controle, puis transmission de donne" Je t'ai déjà indiqué que ta vision du CAN est beaucoup trop limitative. Pourquoi veux-tu qu'une application domotique, par exemple, utilise des protocoles de communication propres à l'automobile???? Ca n'a pas de sens. >"Un stress type: un groupe A de modules CAN avec l'emetteur du paquet, bien plus loin un groupe B. A et B doivent recevoir l'info de l'emetteur. Au moment du paquet, parasite sur B (maximum), perturbe pas A. L'emetteur saura t il que B n'a rien recu ?. " Oui, parce qu'il est impossible que B ne reçoive rien du tout. Si parasite (parlons plutôt de perturbations CEM) il y a, alors le message arrivera erroné, et une trame d'erreur sera envoyée AUTOMATIQUEMENT par A. Pour que rien n'arrive sur A, il faudrait que le bus reste calé durant toute la transmission sur un niveau récessif. Or, une perturbation ECM, ce n'est pas une tension continue. De plus, et je te l'ai déjà indiqué, rien n'empêche pour une application spécifique, d'envoyer explicitement un accusé de réception (ce que tu es de toutes façons obligé de faire en RS485) >"OUI c'est du CEM, mais aussi verifier que le systeme retombe sur ces pieds.. les fonctions (cas CAN et cas Transfert de data) seront elles assurées?. " Oui, elles le sont. Etudie la norme CAN, c'est justement son point fort. >"un petit PIC 628, a 19K2 (domotique) (genre Domosysteme, un vieux fabricant "domotique") plutot que mi rapide non ISO. " Sorry, mais moi je travaille à 500Kbits/s, et j'ai des applications commerciales qui tournent à 100Kbits/s sans aucun problème. "non ISO", je t'ai déjà dit que ça ne veut strictement rien dire. ISO détermine 7 couches de communication, elle ne détermine pas le cahier des charges des 7 couches de façon générale, mais pour chaque cas particulier. La couche x ISO pour le TCPIP n'est pas la même que pour le CAN, par exemple. Quand tu crées une couche, même de ton invention, tu crées automatiquement une couche ISO. Tu ne peux donc pas communiquer si tu n'utilises pas de couche ISO, même sans t'en rendre compte. J'utilise un bus CAN, donc je respecte les couches ISO imposées pour le bus CAN, soit 2 couches. Les autres, c'est à moi de les créer. Je suis donc compatible avec tout périphérique CAN. Pour être compatible avec un système déterminé travaillant en CAN, je dois adopter les autres couches du dit système. Si je voulais être compatible avec, par exemple, une automobile, j'utiliserais les protocoles utilisés par l'automobile pour les autres couches. Seulement, ce n'est pas le cas, alors la compatibilité avec l'automobile ne m'intéresse pas. Du reste, tu parles de domotique : les systèmes domotiques actuels ne sont compatibles avec rien du tout, même pas avec les autres systèmes domotiques. Les gens qui ont développé ces applications ont pourtant utilisé les couches ISO. Du reste, je serais alors incompatible avec les protocoles utilisés pour d'autres communications. Donc, de toutes façons, je ne serais jamais compatible avec tout ce qui existe, il faut choisir. En plus, ton système jeton maître/esclave, ça ne MARCHE PAS dans une application sans maître, comme la mienne. Or, pourquoi lorsque mon interrupteur allume la lampe du salon dois-je passer par une unité centrale, qui renverra l'info? Ce n'est pas rentable, ni en terme de fiabilité ni en terme de vitesse (2 fois plus de trames), et en plus ça fragilise le système (panne de l'unité centrale = plus d'installation électrique dans la maison). Donc, tu essayes depuis le début de me dire qu'un protocole sous RS485 est meilleur qu'en CAN, alors que pour l'application donnée, ça ne fonctionne tout simplement pas. J'ai DEJA (je l'ai déjà dit) fait un système domotique à base d'un maître sur un réseau RS485, et c'est moins pratique que le nouveau système que je suis en train de concevoir, à base de CAN décentralisé. Je suis bien placé pour le savoir, puisque j'ai fait les deux. Par contre, j'ai fait (par exemple) un système d'appels infirmières relativement performant en RS485, et ce sans aucun problème, tout simplement parce qu'il y a une centrale dans ce genre d'application, donc un maître. Faut comparer des poires avec des poires, et des pommes avec des pommes. A+ Bigonoff Numéro de l'article: 57791   |  De: Bigonoff   |  Date: 2003-11-17 00:15:56    RE: Liaison série bi directionnelle Bonjour, L'ISO XXX c'est une GARANTIE: on evite les erreurs d'un fait main, sur table. Le plus "publicitaire" ISO9000: garantie QUALITEE. On n'est pas ISO quand on fait "sa fonction" (sa couche selonl'ISO), mais quand on utilise l'algo (les regles) de la fonction decrite par ISOXXXX. Le pire: ISO9000: 5 pages 20 chapitres... donne des kilos de papier en codage, c'est pas de l'informatique. Le stress ici, les certificateurs qui epluchent puis le tampon ( et la remonte si on l'a pas). En tete des documents ISOXXXX "pour realiser la fonction..." Le CAN repond au besoin d'une fonction: le multiplexage, pour reduire les fils, c'est tout. Oui,par Bosh, c'est l'auto la premiere utilisatrice. L'industrie a suivie pour la meme raison: multiplexage des mesures et commandes. L'ISO ici c'est seulement ca (ni huile, ni compte tours! ca c'est ultra top secret) . Les fonctions "Multiplexage" et "transmission data" sur CAN sont decrites dans les ISOXXXs. ya rien a "inventer", seulement coder. Au dessus ISO (7): oui la domotique (la je sais pas), je pense que chaque fabricant essaie ISOfier son standard (garantie), pas compatible oui!!.... Ce multiplexage (CAN) devait etre transparent pour les CPU des modules (calculateurs...)(pas de soft):c'est la raison du "multimaitre" dans le CAN. En realite, il a fallu mettre du soft (ex datation des messages). Un parasite peut empecher la reception, oui mais le module CAN va tuer la trame?. Et si UN module recoit mal (KO), il bloque tous le reseau (dur dans la voiture ou la maison) car il doit tuer TOUTES les trames... Alors on choisit de pas faire tuer les trames... . Des compteurs d'erreurs (de perte de trames) sont INTEGRES dans les chips (pour surveiller le taux d'erreurs et auto rideau du module (OFF) (surtout si il est actif en erreur, donc flingueur). Le CAN assure uniquement que les donnes d'un paquet sont correctes, en domotique: mesure de temperature, on off... Le CAN n'assure pas qu'apres le paquet 1 on a le paquet 2. L'auto (encore) ayant besoin de cela pour la foncion transmission de data a a joute le "diag on CAN". Remmetre a jour un programme n'est pas qu'automobile. Passer un descripteur, charger une table d'horaire etc..?. L'auto "ISOfie" pour reduire les couts, l'interoperabilité des EQUIPEMENTIERS, (du CAN dans les casses ca c'est tres positif!!). Le modele ISO: un tube a 7 couches, une application demandant du multiplexage aura le tube CAN (avec les deux couches can/hard, et des niveaux vides....) Une application demandant le transferts data aura la couche ISO15657 + les couches CAN. Oui, on peut en mettre une autre, mais c'est la plus simple, prevu pour le CAN, pour la fonction DATA. La fonction multiplexage est un "petit reseau", la fonction "web" un tres gros, un tube TCP/IP a des paquets plus gros que le CAN et son CRC. Pour la meme fonction il y aura deux calculs du CRC. Le CAN decoupera le paquet web!!(calcul CRC), le donne "reconstitue? pas garantie", re CRC par le web. L'ISO15657 est fait pour le CAN et il tiens compte du deja present (CRC).En clair: integrite du paquet: CAN. Continuite paquet, negociation debit/ fenetre ISO15657. Le CAN (comme tous les reseaux RS485..) son encadrés: soit par l'humain dans la voiture (contact), soit par l'employe (coup de poing), surveillance d'usine, soit par des systemes redondants. Le bus est "sensible" on a interet a segmenter (moins couteux que la redondance) l'auto (encore: oui adore le platre!!...) d'ou deux bus CAN, du LIN etc. L'auto pour "le test du feu" c'est pas mal, evidement il ne communique pas les "gros plantages", mais forcer un double CAN avec le cout en plus....!!. Au niveau debit ma souris RS232 sur PC suffit, alors pour un interupteur 500Kbit/s en domotique?. Les anti vol decoupent la maison en zone. Des maitres gerant une zone (piece), independant avec une RS485 local ou LIN. Le maitre a un opto-isole RS485 vers le central (Tandem). Le LIN: autobaud: sans quartz (derive 14%) uart soft!!, le master envoie un header a slave1, reponse pour slave 2!! interupteur< >lampe!! enfin notion de sommeil: reduction energie. LIN: pas ISO, en voie, pas stable LIN2.0.. "LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive __multiplex__ networks. LIN will be the enabling factor for the implementation of a __hierarchical__ vehicle network in order to gain further quality enhancement and cost reduction of vehicles." la solution envisagee pour les commandes (lumiere, climatisation, porte..) dans la petites maison qui roule. A+ XF Numéro de l'article: 57858   |  De: XF   |  Date: 2003-11-17 15:41:25    RE: Liaison série bi directionnelle Salut ----- Ecoute, j'abandonne. Juste que tu aurais du aller charger mes documents sur mon site, tu aurais vu qu'on peut, si on veut, s'arranger pour que les paquets arrivent dans l'ordre. Tout est fonction de la façon de travailler, et de la fonction qu'on désire. Quand mes modules passent en mode bootloader, ils recoivent les trames dans l'ordre. Un module en panne ne bloque pas le bus, il est désactivé en moins de quelques ms. Mon système domotique, c'est un vrai système domotique, pas un pseudo-système qui ne comporte que des interrupteurs. Donc, débit important nécessaire. Tu insistes avec ton RS485 avec maître, mais, avec ça, on ne sait pas faire un système domotique performant. J'ai besoin de 35 sorties gradateur rien que dans mon salon (éclairages d'ambiances personalisés), et d'une volée d'I/O par pièce (pas que des interrupteurs). Avec un système RS485, je suis obligé d'interroger sans arrêt toutes les cartes, c'est réellement peu pratique. Et mon système est prévu pour piloter des grands systèmes, donc peut piloter plusieurs sous-réseaux. La domotique, ce n'est pas un interrupteur et 2 gradateurs, avec une alarme. J'arrête là, les autres réponses, je les ai déjà faites dans les messages précédents. A+ Bigonoff Numéro de l'article: 57918   |  De: Bigonoff   |  Date: 2003-11-17 22:38:31    RE: Liaison série bi directionnelle Bonjour, j'ai lu la presentation. C'est dommage, offrir des cours, les sources a la communaute et ne pas "precher" pour l'ISO (pas un mot). C'est totalement FAUX qu'il soit necessaire d'avoir 500kbits/s pour la domotique. meme pour regler un gradateur!. Comme c'est ecrit les systemes existants utilisent du 20kbits/s. Cette valeur n'a jamais ete critiquee (vitesse LIN!). Le 500Kbits/s est necessaire dans le spectacle (domotique?), c'est la vitesse du DMX. En 2002, avec le LIN (domotique auto) les "industriels" allememands l'ont fait "dans son coin" (LIN1.0). Cherchant une certification ISO, pour ganrantir la perenite, ils ont ete oblige de revoir la copie avec un LIN2 INCOMPATIBLE avec le 1!. C'est pas grave car dans les faits le LIN1 n'est pas deployer, les modifs sont dans le "soft". Le filtre ISO est tres dur!!. Obliger microchip (PIC) et les autres 8051? DALLAS DS80C390 double CAN (tiens double?), pour la segmentation CAN?. La domotique s'oriente au "vert", petit, faible comsommation, segmentation du reseau(opto)(chapitre sur les precautions pour ne pas detruire le reseau). Ca c'est important, dans les reseaux 'habitations" (>100Kbits) il y a une isolation GALVANIQUE des stations, les transfos sont devenus INVISIBLES car dans la prise!!.Comme voiture=faraday pas d'opto, en industriel: opto pour le CAN. Des optos a 20Kb ok, chers a haute vitesse... Est ce que ca va marcher?, en se basant sur le document, un peu moins bien qu'une auto avec le CAN de 1er generation. C'est pas mal, car il y en a eu beaucoup de voiture. Probleme l'ABS: une charge importante, ce qui hormis lors d'un spectacle n'arrivera pas, et les datas... Un standard? non, la c'est dommage, car y a des exemples existent Linux....Soit, je critique, mais je trouve vraiment dommage de ne pas utiliser l'experience des autres, de l'ISO, la domotique, sujet tres interessant et enfin de commencer par la fin: imposer le CAN pour la domotique. A+ XF Numéro de l'article: 58065   |  De: XF   |  Date: 2003-11-18 23:25:10    RE: Liaison série bi directionnelle Salut ----- Ecoute, je t'ai dit que je laissais tomber. Mais bon, vu que tu critiques directement mes applications (c'est ton droit), je réponds (c'est le mien). Je réalise un système domotique (c'est mon second). J'utilise un débit de 500Kbits/s, je ne vois pas ce qui te pose problème. Je ne t'empêche pas de faire ton propre système. De plus, il est facile (et j'indique comment) de faire varier la vitesse du bus de 10 Kbits/s à 1Mbits/s, les sources sont fournies, il n'y a qu'une ligne ou deux à changer. Donc, celui qui voudrait absolument isoler galvaniquement peut le faire, tout est fourni : schémas, explications, sources, logiciels. Moi, j'explique la méthode que j'ai retenu pour moi-même. Celui qui veut mieux faire le fait, celui qui propose autre chose le fait. Je vais même plus loin puisque j'indique qu'une fois le système de base réalisé, je publierai toute réalisation qu'on m'enverra sur le sujet sur mon propre site. Plus ouvert que ça, ce n'est pas simple à trouver. Je n'ai pas dit qu'il FALLAIT du 500Kbits/S, j'ai dit que moi, j'utilisais du 500Kbits/s. Pour info, les bases de ce système sont utilisées simultanément sur des systèmes commerciaux, et mes choix n'ont pas été faits au hasard. J'avais le défit de faire passer un certain nombre d'infos dans un temps donné. Tu dis que le débit des autres systèmes n'a jamais été critiquée, c'est faux. Déjà, d'une part, parce que moi je la critique, et d'autre part je ne suis pas le seul. Le système que je développe est prévu pour le pilotage de grands ensembles (salles importantes, groupes de bâtiments, immeubles...), qui peut le plus peut le moins. Je veux pouvoir réaliser le maximum d'application sans être géné par le débit maximum. Tiens, à propos, avec tes systèmes à 20Kbits/s, tu sais faire passer de la musique par le bus? (je dis ça comme ça, LOL). Mon système ne va pas se limiter à une carte gradateur, laisse moi le temps de développer les applications : cours, docs, cartes, logiciels, site, forum, boulot, tu crois qu'il me reste combien de temps pour dormir? Pour l'instant, il est 2H13 du matin, et demain je suis debout à 7H. Et encore, j'ai pris du retard, je n'arriverai pas à répondre à mon courrier aujourd'hui (et j'en ai, du courrier). Donc, avant de dire que 500Kbits/s ne sont pas nécessaires, attends de voir ce que je vais développer. Ce que font les autres dans les systèmes domotiques ne m'intéresse pas (du moins pour le commercial). J'ai été invité à des démonstrations de systèmes domotiques officiels, et je n'ai pas (mais alors pas du tout) été convaincu. Ce sont des pseudo-systèmes domotiques, fort limités, genre : avec mon interrupteur de salon, j'allume la lampe du WC (ça intéresse qui?) et très chers (la dernière installation que j'ai vue coûtait 22000 euros). Moi, si je passe mon temps à faire mon propre système, c'est dans l'espoir de faire mieux et moins cher. Si c'est pour faire la même chose, je me contente de copier ce qui existe. Si je n'y arrive pas (on verra), c'est mon temps que j'aurais perdu, pas celui des autres. Ceux qui cherchent la "pérénité" de leur système le font pour des raisons de compatibilités soit dans les versions futures, soit avec d'autres produits. Moi, je te le répéte une dernière fois, je n'ai PAS BESOIN d'être compatible avec autre chose, donc je n'ai pas à me plier à une norme ISO particulière, excepté celles imposées par le bus CAN. J'ai reçu les mêmes réflexions pour l'ICD. Pour faire de l'ICD, il fallait un circuit compliqué, qui coûte assez cher, etc, c'était "impossible" de faire autrement (si si, on m'en a fait la démonstration), sinon Microchip n'aurait pas manqué de faire plus simple. Résultat, j'ai fait le mien pour moins de 3 euros (et plusieurs semaines de recherches et de travail, et une collaboration avec Bonny Gijzen pour la modification de IC-prog pour gérer ça), et il travaille plus vite que celui de Microchip. La aussi, c'était inutile et impossible. N'empêche que d'après le courrier reçu, pas mal de personnes trouvent mon ICD pratique. Le bootloader série sur n'importe quelle pin, c'était aussi inutile, vu que Microchip utilisait l'USART, on m'a même écrit pour me dire que je manquais d'intelligence, puisque je faisais autrement que Microchip. N'empêche que j'ai reçu pas mal de courrier de gens qui utilisent mon bootloader pour toutes sortes d'applications dans lesquelles l'USART n'est plus disponible (ben oui, c'était le but, Microchip semble ne pas y avoir pensé). Evidemment, c'était plus compliqué à créer que d'utiliser l'USART... La méthode de travail qu'on voit un peut partout, c'est de piocher ce que font les autres (ce que tu me préconises), puis d'ajouter ou d'améliorer à partir ce ce qu'on a lu. Moi, je procède différemment: Je ne lis strictement aucun ouvrage sur les questions qui m'intéressent, et je réinvente tout. Au besoin, je lis ensuite pour corriger ou pour améliorer. L'avantage, c'est que je ne pars pas d'idées préconçues, et donc j'obtiens des méthodes originales. Elles ne sont peut-être pas toujours meilleures, mais au moins on ne les retrouve pas sous 2000 versions différentes sur 3000 sites différents. Et ça, ça fait évoluer les choses : proposer du différent, et ne pas partir du principe que ce qui est déjà existant est forcément bon, puisque déjà pensé par d'autres. L'ISO je n'en parle pas? Désolé, je parle de l'ISO qui intéresse les utilisateurs. Donc, dans mon cours, je parle de l'ISO7816. Les autres normes iso ne concernent pas la programmation des pics proprements dit. Mais rien ne t'empêche de faire des cours sur l'ISO et de mettre ça à disponibilité, ce sera tout bénéfice pour tout le monde (et j'irai lire, si si). Moi, désolé, je ne sais pas tout faire, j'ai des priorités. Pour la protection CAN, je te suggère de lire le datasheet du MCP2551. 250V sur les pins de bus, protection jusque 6000V de CANH et CANL, et 4000V pour les autres pins. Note qu'une mise en application correcte des phénomènes ECM réduit (supprime) la nécessité des optocoupleurs même en cas de foudre. Tout est question de mise en place correcte. Avec ton système optocouplé avec alim directe sur les prises, tu auras l'air malin en cas d'une surtension arrivant sur le secteur. Moi, mon système va tenir. Avec tes cartes optocouplées alimentées sur les prises, ça va faire BOUM. Et oui, c'est facile de protéger une alimentation unique générale, mais protéger une alim par carte... En plus, placer une carte gradateur 16 sorties dans une prise, il faut pouvoir, LOL. De plus, les cartes dont il est question actuellement sur le site sont placées de façon centralisée (hardwarement, à ne pas confondre avec la décentralisation des fonctions). Un optocouplage nécessite des alimentations séparées partout (très coûteux et inutile), alors que le simple respect des normes ECM permet d'éviter les problèmes (note que sans respect des normes ECM, tes optos seront de toutes façons pulvérisés en cas de choc de foudre, donc inutiles). Les optocoupleurs pour une liaison inter-site, oui, sur le même site, c'est inutile (exactement comme pour l'automobile si on a respecté le maillage des masses). Mon système ne marchera pas mieux qu'un système auto de première génération? Si tu le dis, tu as sûrement raison. On verra à l'usage. Pour ce qui est d'imposer le CAN, moi je n'impose rien à personne. Je fais un système pour mon propre compte, et je propose d'en faire profiter les autres, c'est tout. Quand je vois les revues électroniques, qui ne proposent même pas les sources de leurs programmes, je me dis que ce n'est déjà pas si mal. Pour ce qui est d'imposer les pics, je n'impose rien non plus. Mes cartes sont à base de PICs 18Fxx8, j'ai laissé 252 numéros de microcontrôleurs différents pour y mettre ce qu'on veut. J'ai créé le système, j'utilise les microcontrôleurs que je veux, c'est la moindre des choses. D'autant qu'il s'agit d'un site sur les PICS, je te le rappelle quand même. Toutes les sources sont données et documentées, et donc, puisque je respecte les couches ISO (si si) du CAN, n'importe qui peut créer une carte compatible avec mon système, c'est très simple (pour qui sait programmer). Maintenant, celui qui veut le faire devra se farcir lui-même le noyau bootloader, je ne vais pas m'amuser à faire des bootloaders pour tous les microcontrôleurs existants (et qui acceptent ce type de mise à jour). Mais, de nouveau, toutes les infos sont données pour le faire, il n'y "a qu'à" La segmentation? Tu n'as pas du bien lire, parce que mon système incorpore la notion de "réseau", qui sont ce que tu appelles des "segments", donc des bus soit séparés physiquement, soit séparés uniquement logiquement, soit interconnectés directement ou par isolation galvanique (c'est strictement comme on veut). Je n'ai que faire de l'expérience des autres en matière d'ISO, parce que mon système n'a pas besoin d'être compatible avec une couche ISO autre que celles imposées par le CAN. Je ne vois pas pourquoi je dois créer des compatibilités avec des normes avec lesquelles je ne communique pas, ça n'a aucun sens. Tu parles des standards. Tu rigoles? Il n'y a pas deux systèmes domotiques sur le marché qui soient compatibles, alors les standards, permet-moi de rigoler. Et je ne vois pas ce que Linux vient faire dans l'histoire ??? L'expérience des autres servirait si je voulais m'intégrer dans un système existant, ce n'est pas le cas (je ne sais plus comment le dire, peut-être en chanson?) MAintenant, de nouveau, rien ne t'empêche de faire un autre système, avec tout l'ISO que tu veux, et de mettre tout ça sur un site gratuit, avec les docs et les sources, afin que tout le monde en profite. Comme ça, on aura un exemple pratique et utile de ta façon de concervoir les normes ISO. Pour ma part, je n'ai pas le temps de commencer à disserter sur mon site sur les centaines de normes ISO, et d'analyser pourquoi je n'utilise pas telle ou telle norme existante. Sans ça, mon site serait un site sur l'ISO et pas un site sur les pics. Il faut choisir, je n'ai plus de temps supplémentaire à consacrer. A titre d'information, quand je fais une carte pour moi, il me faut plus de temps pour écrire la doc que pour faire la carte. Or, la doc, je ne la fais pas pour moi. Je ne peux pas faire plus que ce que je fais, j'y passe déjà mes nuits et mes W.E. A toi la main pour réaliser quelque chose de meilleur ou pour parler d'ISO (OSI in french) A+ Bigonoff Numéro de l'article: 58265   |  De: Bigonoff   |  Date: 2003-11-20 02:29:33    RE: Liaison série bi directionnelle XF tu dis n'importe quoi Bigonoff a raison sur la fiabilité des trames. J'ai travaillé chez un constructeur automobile et je connais bien le pb. On voit bien que t'as rien compris quand tu dis que certaines trames ont la même prioritée!!!!lolll BRAVO POUR CETTE JOUTE EPISTOLAIRE TRES DISTRAYANTE. Numéro de l'article: 58318   |  De: ced   |  Date: 2003-11-20 13:35:15    RE: Liaison série bi directionnelle Bonjour, Ced: au sujet des trames, j'ai du mal m'exprimer, evidement la collision en CAN permet la gestion de la priorite, mais dans le cadre de l'exemple, ca peut poser un probleme. Ce n'est pas sans raison que microchip a ajoute ceci dans la doc du MCP2515: • One-shot mode ensures message transmission is attempted only one time " One-shot mode is required to maintain time slots in deterministic systems, such as TTCAN." Et chez un constructeur... a l'epoque ca n'existait pas "d'office". C'est vraie que le CAN ca marche bien, mais dans le service "bug rare", deformation professionnelle?.C'est pour cela que j'insiste : quoi qu'on fait avec!!. Au niveau musique: le coax et la video? et a min 10Mbits/s. C'est isole galvaniquement, pas cher. Par contre, le min pour la maison, "controlable", la je suis d'accord. Meme le DMX (RS485) est isole galvaniquement des stations. Au niveau domotique, j'avance comme la tortue ( et le boulot) , j'ai (sur la table!)du LIN, ca decante, et j'observe la normalisation LIN, (ils en sont a la version deux) pour pas avoir a le refaire!. XF Numéro de l'article: 58346   |  De: XF   |  Date: 2003-11-20 15:53:52    RE: Liaison série bi directionnelle Demmande des motoristes , entre eux: Lecture correcte:CRC, pas de soft: multimaitre, priorite naquit le CAN 0. Puis il a evolue au gres des problemes. Probleme: sonde HS (en analog: -200degre, +1000..), en CAN: derniere valeur!!!. Rustine: soft, datation, alarme si plus de nouvelle l'application de MULTIPLEXAGE d'origine a du avoir une rustine, ca aurait pu etre prevu C'est pas dans le CAN?: fonction multiplexage, pas d'assurance sur "la presence du capteur". Probleme: module CAN "secoué": bloque le bus solution: rideau par un compteur d'erreur. Probleme: ABS, vie humaine en jeu. Un module peut bloquer (Temps de rideau = accident), ou pas laisser passer les autres (dit"surcharge"?!!): pas de priorite "tourannte": modif en soft, mieux en hard...microchip. Enfin: les donnees: l'CAN X25. L'option systeme et reseau en fac c'est ca (bonne lecture); pas l'beurre et l'argent du beurre. Un bus c'est comme le porc salut, c'est ecrit dessus!. USB1: trop court pour la video (10Mbits/s): USB2 (480Mbits/s). Au niveau EQUIPEMENTIER y a une guerre des prix, microchip veut "sortir" le 8051 de l'auto ca va prendre? a suivre... Sinon dans 5 ans y a plus rien, pire (histoire vraie)un mois apres la recette final: arret de fabrication du chip principal, recent. D'ou le basic, le multisource mais c'est encore un autre aspect des choses, il est plus difficile de maintenir du materiel de 7 ans d'age que de 25 ans.Vive le 7400!!. En hard: RS232 point a point, dehors, LIN: bus collecteur ouvert (MUTISOURCE!!), minimal, fonction?ISO? a voir. RS485, idem, plus rapide, CAN "moins evident" (pas en SOFT!!), trop court pour le mutimedia. Interphone? RS485 passe. Enfin le connecteur?: 4 points necessaire. En CAN?, le 9 points (deux CAN!!). Blinde, le prix du m (a comparer au prix du chip PIC), bretelle: pas possible (excusable en segmente, faible vitesse): DB9 sur cable plat, facile a monter. Enfin, je dis pas POMPER le SOFT, je dis GNU: a lire. ON AJOUTE une pierre, c'est COMMUNAUTAIRE. Parceque tout seul, on peux ni changer ni faire le monde... A+ XF Numéro de l'article: 58372   |  De: XF   |  Date: 2003-11-20 18:36:34    RE: Liaison série bi directionnelle SAlut ----- un dernier. Tu me parles du can0, je te parle de la version 2.0b. Quel rapport???? "En CAN, dernière valeur". Tu rigoles? Un buffer, tu sais ce que c'est? Ton message, tu l'as reçu, tu en fais ce que tu veux. Un message n'écrase jamais le message précédent, c'est n'importe quoi de dire ça. Ton bus à 100Mbits/s en coax ??? Essaye d'implémenter ça sur un microcontrôleur, LOL. Je ne veux pas piloter ma maison avec un PC de 400W, je pilote par cartes à microcontrôleurs. L'absence d'un module CAN? Ben oui, et alors, où ai-je dit que si on enlève un module on a une erreur ??? J'ai dit : trame d'erreur pour tout module PRESENT. Tu penses que mes cartes vont se déconnecter toutes seules? Et de toutes façons, si j'enlève une carte gradateur de mon système, j'aurai beau le savoir, ça ne me permettra pas d'allumer la lampe. Donc, il faudra de toutes façons intervenir, QUEL QUE SOIT le bus utilisé. De plus, je t'ai dit que j'avais des mécanismes qui permettent de s'assurer de la présence d'une carte. C'est très (TRES) simple à implémenter, pas besoin de se perdre dans des protocoles compliqués. Tu dis : augmente la sortie de la lampe 3 de 10. La carte répond : ok, la nouvelle valeur est de 26. C'est compliqué? Ce n'est pas sûr? Il faut encore un autre protocole? Par contre, en cas de panne d'une carte, ma carte va se déconnecter automatiquement du bus. Avec ton RS485, tout est en panne avec un peu de malchance. Alors, tu auras beau avoir implémenté des détections softwares, tout sera bloqué. Les bugs de Microchip? Et alors? Tu en veux toute une liste? Tu sais que les modules I²C ont un bug en multimaître? Ce n'est pas un défaut de l'I²C, c'est un bug dans le module Microchip. Ca n'a strictement rien à voir. Du reste, je n'utilise pas de MCP2515, j'utilise un MCP2551. Le MCP2515 est un gestionnaire séparé de bus CAN, le 2551 est un driver de bus CAN. La gestion est assurée directement par le PIC, c'est plus simple et plus économique. Le one-shot, ça sert dans des protocoles spéciaux. En a besoin qui veut. Ce mode a été ajouté pour se rendre compatible avec ce qui existait déjà, et non le contraire. Moi, je n'ai pas besoin de "one-shot", parceque je n'ai pas besoin que mes trames soient incluses dans un créneau temporel déterminé. J'ai besoin que mes trames arrivent, point. Note que, du reste, c'est le contraire de ce que tu affirmes depuis le début, puisque le "one-shot" est là pour EMPECHER la réémission automatique des trames en erreur, alors que cette réémission est bel et bien automatique par défaut. Sommes toutes, ça permet de "dégrader" le CAN à un niveau du genre RS485, ou tout doit être géré par soft. Le basic? Tu rigoles? Avec une perte d'efficacité d'un facteur 10 à 100 selon l'application. Même le meilleur basic compilé a une perte d'un facteur 10 dans le meilleur des cas. Et dans les applications complexes, on atteint 100 (je parle compilé, interprété c'est une dégradation de 1000 à 10.000) En RS485, connecteur 4 points, 9 en CAN? Soyons sérieux. Tu confonds une des normes de connecteurs utilisés (il y en a plein, du DB9 au RJ10) avec le nombre de lignes nécessaires. En CAN : 2 fils, c'est tout. Comparer le prix d'un driver avec le prix d'un PIC. LOL. Et ton driver, il te ne te faut pas un contrôleur pour le piloter? LOL Le double CAN? Inutile pour ce genre d'application. Ou alors, c'est pour avoir de l'ultra-sécurisé. MAis, dans ce cas, il te faudra également un double RS485 (bonjour pour gérer par soft). Le GNU? Qu'est-ce que ça vient faire la-dedans. Le GNU c'est une charte qui précise les modalités si on veut faire des programmes publics. Les miens sont publics, commentés, avec les sources. Alors, je n'ai pas de leçon à recevoir du GNU. Le GNU ne m'intéresse pas, parce qu'il est dit dans la réglementation qu'on peut modifier tes applications et en faire un produit commercial. Alors, oui pour tout partager, mais si c'est un autre qui fait du fric sur base de mon travail, c'est une limite que je ne franchis pas. Mon travail reste et restera gratuit. Et si quelqu'un devait faire de l'argent avec, ce serait moi, pas un "copieur". C'est pour ça que j'ai refusé la réglementation GNU (généreux, mais pas fou). Ajouter la pierre à l'édifice? Ben oui, ce n'est pas ce que je fais? J'avais cru. Plus que ça, je ne sais pas, désolé. La guerre des équipementiers? Ben oui, tu débarques de quelle planète? La guerre, elle a toujours été là : soit on se fait la guerre, soit on s'allie. En dehors, point de salut. LE 8051, il est tout de même vachement obsolète, il est temps de tourner la page (et je sais de quoi je parle, j'ai programmé en 8051), même si les dernières versions (mémoire flash, modules etc) sont meilleures que les premières. Ecoute, plutôt que d'argumenter dans le vide pendant 6 mois, je te propose la solution suivante : - Je fais mon propre système domotique sur base du CAN - Tu fais le tien, sur base de ce que tu veux Au final, on met tout en ligne, et les utilisateurs comparent et choisissent. On verra aussi ce qu'il est possible de faire avec un système, et ce qu'il est possible de faire avec l'autre. C'est pas plus simple? A+ Bigonoff Numéro de l'article: 58390   |  De: Bigonoff   |  Date: 2003-11-20 22:46:36    RE: Liaison série bi directionnelle Bonjour, je n'ai pas dit qu'il y avait des bugs chez microchip. C'est un resume des problemes du CAN. Le one shot a ete fait pour resoudre un pb de deterministe, temps d'actions rapides. c'est pas en contadiction avec l'CAN X25 (DATA), c'est encore autre chose. Oneshot+CANX25(buffer)= systeme deterministe (rapide)+DATA, mais plus MULTIPLEXAGE!!. Oui, le 8051 y a mieux, mais tout les labos (equipement) ont les outils, le soft, leurs "moniteurs multitache normatif ;) " etc, et des nouveaux micros sortent c'est pour cela qu'il est "indeboullonnable". Micro chip veut faire de l'auto, le chip est cible: auto, pas d'UART. Ils ont fait le tour: MULTIPLEXAGE, DATA (le FIFO) et le one shot. Les 3 "fonctions auto CAN". Il "drague" l'auto. d'ou le "a suivre"... Un bus c'est fragile, meme avec les "protections", c'est pour cela que l'isolation galvanique devient le standard. Solution: redondance on double, pour avoir "toujours" l'ensemble OK, soit on segmente, avec de l'isolation galvanique entre chaque compartiment, comme "un sous marin", on perd un bout. Le LIN: le min pour avoir les fonctions "domotiques". Faible cout: objectif LIN dans 12C508?. Un cahier des charges, le "decantage", voir autour, le pourquoi "ca"?. Evite souvent des erreurs. Le CAN c'est 3 fils min, 4 avec l'alim. A cause du courant d'alim: le CAN: DB9 (RJ45 pas telephone), en pro, 3 fils: XLR (DMX). LIN 'faible courant' RJ45, ou DB9 cable plat (plusieurs points?): motif: facilite de cablage/Prix. Je fais pas la course a sortir un produit(temps), par contre, pour l'ensemble des lecteurs du forum qui veulent faire de la domotique, le debat me semble interesant. Au niveau du soft, "gratuit" (vague) c'est le mettre dans le domaine public, donc quiconque peut le modifier et en faire un produit commercial (sans source). Extrait info sur GNU GPL: "Considérons le GNU C++. Pourquoi existe-t-il un compilateur C++ libre ? Uniquement parce que la GNU GPL indiquait qu'il devait être libre. MCC, un consortium industriel, a développé GNU C++ à partir du compilateur GNU C. En temps normal, MCC rend sa production aussi propriétaire que possible. Mais ils ont fait une interface C++ libre parce que c'était la seule possibilité de l'éditer que leur laissait la GNU GPL. L'interface C++ comportait beaucoup de nouveaux fichiers, mais comme ils étaient prévus pour être liés à GCC, la GPL s'appliquait à eux. Le bénéfice pour notre communauté est évident. " Tout nouveau produit a partir du GNU GPL, restera libre (source obligatoirement disponible). c'est mieux?... et ils ont des avocats... (pot de fer contre terre). A+ XF Numéro de l'article: 58474   |  De: XF   |  Date: 2003-11-21 19:12:00    RE: Liaison série bi directionnelle Salut ----- 1) Le bus CAN, stop, je ne vais pas dire 100 fois la même chose. Garde tes convictions (fausses), je ne cherche plus à te donner d'argumentation, tu ne les prends pas en considération. 2) Je ne vais pas doubler mon CAN, je pilote une maison, pas un boeing 3) Ton RS485, à côté du CAN, ça fait pour le moins "primitif" niveau sécurité. Mais bon, je ne cherche plus à te convaincre. 4) On n'a aucune raison de "perdre un bout de bus". Tu ne sembles pas expert en bus. 5) Je sais ce qu'est un cahier des charges, merci. Je te signale que je développe des applications commerciales, et dans des domaines très critiques. Tu crois que je développe sans réfléchir à ce que je fais??? 6) Le CAN, c'est deux fils minimum, désolé. On n'envoie pas la masse sur un codage différentiel. Revois ta copie. Si on ajoute l'alim, ça fait 4, mais c'est pareil pour le RS485. 7) Le DB9 n'est pas l'unique connecteur CAN officiel, on voit que tu ne connais pas correctement le CAN, relis (ou plutôt lis) la norme officielle : CIA DR-303-1 : RJ45; RJ10, différents connecteurs DIN etc sont au programme des connecteurs officiels (avec les brochages normalisés correspondant). 8) Aucun standard domotique n'a jamais réussi à s'imposer, il n'y a donc PAS de standard officiel. Lin, X10 et autre, chacun fait comme il l'entend, chacun veut être le seul, et personne n'y arrive. 9) Rien ne t'empêche d'utiliser le standard de ton choix, rien ne m'empêche d'utiliser le mien. 10) Le GNU ne se limite pas au C++. Programmer en C++ sur un PIC est une hérésie. 11) Tu es très mal renseigné sur le GNU, moi je suis renseigné puisque j'ai eu contact pour y placer mes cours. Pour être GNU, tu dois accepter que ton travail puisse être utilisé par tous, MEME pour des applications commerciales. Tu ne peux plus rien revendiquer. AUtrement dit, j'écris un bouquin "GNU", un auteur xxx s'en empare et l'édite commercialement, je n'ai aucun droit dessus. Alors, le GNU... Par contre, mettre comme j'ai fait, une distribution libre, avec preuve que j'en suis l'auteur, INTERDIT (oui oui) toute application commerciale sans mon consentement, je reste propriétaire execlusif de mes cours. Un exemple, le GIF, qui était public, est redevenu privé, personne n'a le droit actuellement de l'utiliser sans license. Et pourtant, c'était public il y a 3 ans. La situation est donc exactement l'inverse de ce que tu dis. Tu débats sur des sujets que tu ne maîtrises pas, c'est mon avis. 12) Il n'y a pas besoin du GNU pour avoir des programmes libres, il en existe des centaines non "GNU". Je fais du gratuit non GNU, et ça ne semble déranger personne. J'autorise tout usage privé, et c'est ça qui compte. 13) Je sais ce que signifie "one-shot" et quelle est l'utilité, merci. Ce n'est pas signe d'un défaut du CAN. Pour info, tu as exactement les mêmes possibilités sur un réseau HF de type WIT2410 14) Les outils de développement sur pics ont un coût dérisoire, ce n'est pas ça qui va cantonner une société sur le 8051. C'est plus souvent la paresse d'étudier autre chose. 15) Je me sens subitement fatigué, là, LOL A+ Bigonoff Numéro de l'article: 58559   |  De: Bigonoff   |  Date: 2003-11-22 13:18:51    RE: Liaison série bi directionnelle Bonjour, 1) Pas de "conviction", les motifs de la creation et de l'evolution du produit. La confrerie des motoristes ont la conviction que le CAN est le plus beau bus du monde.... (c'est presque vrai!!)Les utilisateurs (l'argent) ont obliger les patrons (constructeurs) a prendre l'avis motive "d'exterieure". L'CAN X25 et le one shot a fait crincer des dents dans la confrerie. 2) Une panne sur une table pas grave, mais dans une maison, tout HS.. reseau CUIT. 3) CAN contre RS485 non!!, "caler le produit a l'objectif visé" un char pour une noisette!!... 4) Pas un bout l'ensemble, d'ou la segmentation, et l'opto isolation isolation galvanique. 5) Le cahier des charges consiste a placer le CAN?. Il est bien plus complexe... 6) Le CAN deux fils?. La y en a qui doivent se retourenr dans leurs tombes!!. La masse FIXE le mode COMMUN!!. Il ne PEUT pas ETRE INDEFINI avec des semi conducteurs!!. OBLIGATOIRE. Seul le TRANSFOS l'autorise (la masse devient l'ecran). Le "ca marche" n'est pas UNE DEMONSTRATION, c'est une "table"... Lire le cours sur l'AOP et la documentation de TOUT CI "MAXIMUN MODE COMMUN MODE".VCr= VCe+Vx?.Avec la masse: VCr=VCe!!. Pour eviter ce stress MORTEL on allonge la masse (premier contact) sur les connecteurs "jeunes" USB... ex: PCA82C25 "LIMITING VALUES (destruction)" -8<VM<+18 par rapport au GND (pin2), et si pas relier? (VX?)!!. Dans les DEUX "ex