LOCODUINO
Discussions Générales => Bus CAN => Discussion démarrée par: Tony04 le mars 28, 2018, 07:14:07 pm
-
Bonjour,
je suis entrain de me saturer ma petite tête avec un projet de réseau utilisant le bus CAN pour l'envoie des commandes et la rétro-signalisation en partant de l'idée de DDEFF dans son article SGDD.
D'après l'architecture du système il semblerait que tout le monde part sur la séparation des tâches pour chaque module (cantons, aiguilles, signaux).
Pourtant on place toujours le décodeur aiguille proche de cette dernière; pourquoi ce décodeur ne pourrait'il pas s'occuper aussi de la détection de présence et du signal, cela réduirait considérablement le câblage je pense ? Est-ce une question d'adressage et de masque ?
Je suis preneur de toutes vos réflexions pour éviter de partir dans une usine à gaz, j'en suis à mon premier réseau et n'ai aucune expérience dans ce domaine (heureusement pour Arduino un peu plus).
Bonne soirée à tous
Antoine
-
Bonjour Antoine,
Non ce n’est une tendance de séparer les fonctions (1 Arduino par type de fonction) : c’est le choix que j’ai fait, moi, parce que j’ai développé mon réseau fonctions par fonctions (le TCO d’abord, puis les commandes d’aiguilles et la traction, puis le gestionnaire de Pierre59 et je n’ai pas fini). Cette méthode a des avantages mais elle nécessite beaucoup de câblage et des connexions longues car en étoile. Mais ça fonctionne bien quand même.
Une autre tendance est de regrouper les fonctions les plus proches les unes des autres dans un même Arduino (commande d’aiguille, capteurs de présence et signaux) et de relier tous les Arduino en bus Can, ce qui permet d’avoir des connexions courtes avec ces organes. On peut alors avoir un bus de 6 fils seulement qui courre le long du réseau : 2 pour le DCC, 2 pour le Can et 2 pour l’alimentation des Arduino.
C’est exactement un projet que nous sommes en train de développer à plusieurs sur Locoduino et que nous décrirons quand il sera suffisamment réalisé et testé.
Nous avons l’habitude de ne rien décrire tant que ce n’est pas testé donc il faudra attendre un peu, mais je peux essayer de répondre à tes questions en attendant.
On parle aussi parfois de « un Arduino par canton » mais je ne suis pas convaincu par les regroupements fonctionnels que cela entraîne.
Dominique
-
Bonjour à tous
Pour ma part je m'oriente aussi vers une solution d'intelligence répartie plutôt qu'une spécialisation par Arduino. Outre le gain de câblage je pense que cette organisation accompagne mieux les agrandissements du réseau. Je crois également que cela permet une meilleur utilisation des ressources en IO Ana PWM Interruptions ... De plus aujourd'hui la polyvalence ne s'impose-t-elle pas. J'attend donc avec intérêt la publication de vos travaux.
-
Bonjour à tous,
Je défend le concept présenté par Dominique que je n'hésite pas à appeler "un Arduino par canton". En réalité, il s'agit bien plus qu'un Arduino puisque cela comprend les servos (dans mon cas) pour les aiguillages, les détecteurs de consommation, la signalisation etc... etc... Donc tout ce qui fait un canton.
Je suis assez avancé sur un prototype où l'ensemble du code est identique sur tous les Arduinos. Seul l'ID de l'Arduino est différent et se paramètre en début de programme. Un certain nombre d'options sont "imposées par défaut" comme par exemple le fait que la classe aiguillage instancie 4 aiguillages ou que par défaut encore, le nombre de capteurs ON/OFF (consommation, effet Hall...) est fixé à 12. Je suis sur des MEGA et cela suffit dans mon cas à couvrir tous mes besoins et les dépasse même.
A partir d'un code standard et pour individualiser le travail de chaque MEGA à son canton, j'ai une méthode dans le setup qui va charger sur un serveur les paramètres spécifiques à ce canton reconnu par l'ID écrite en "dur" au début du programme. Pour cela, j'utilise une liaison Ethernet et un serveur en Node.js (mais cela pourrait aussi être fait en CAN). Le transfert des données est au format Json et j'utilise la bibliothèque "ArduinoJson" qui simplifie grandement l'affectation des valeurs à chaque paramètre.
L'avantage est bien sûr comme souligné déjà la réduction du câblage, mais aussi un code unique pour toutes les cartes donc plus facile à maintenir et à faire évoluer. Par ailleurs, le fait que tous les paramètres spécifiques d'un canon soient stockés dans de simples fichiers textes sur un serveur facilite aussi la maintenance et la mise à jour.
Je cherche à introduire en plus un bus CAN pour profiter d'une spécificité que bizarrement il ne me semble pas encore avoir vu développée sur Locoduino. La possibilité que chaque nœud a d'intercepter l'ensemble des messages et donc de pouvoir agir dans certains cas sans avoir besoin (ou d'attendre) l'information d'un gestionnaire central. Un certain nombre d'objets locaux pourraient alors interagir sans passer (ou tout passer par le gestionnaire). Le cas le plus évident me semble par exemple l'interaction d'un détecteur de consommation sur le la modification de la signalisation lumineuse.
Cela me semble intéressant là où les questions de sécurité sont critiques (rapidité d'intervention, panne éventuelle du gestionnaire...) ou au contraire très secondaire. La gestion d'un PN n'a en effet probablement pas besoin de passer par un gestionnaire central mais met en œuvre pas mal d'actions qui peuvent être auto-gérées localement. Détection d'un train, feux rouges clignotants, signal sonore, fermeture des barrières...
Le CAN avec son système de filtres et de masques permet cela à merveille. C'est comme cela que je comprends "solution intelligente répartie" dont parle Rob1.
Par contre, je déconseille vivement, et je ne suis pas le seul, d'envisager la conception d'un réseau aujourd'hui (hors traction bien sûr) sur le bus DCC et décodeurs comme en parle Tony04.
Bien amicalement
Christophe.
-
Cela fait du bien de ne pas se sentir seul. J’adhère à l’idée d’Arduino identique mais mon modeste passé d’automaticien me fait craindre que cet objectif, poussé trop loin, ne conduise à des ‘ usines à gaz ’. :-[
Il convient de bien modéliser des fonctions de base et de les faire inter-agir. L’intelligence répartie en automatisme est arrivée après les architectures maître-esclaves. Elles ont fortement évoluées avec ce que l’on a appelé les étiquettes mémoires embarquées et les machines transfert où chaque pièce (ou support) transportait les paramètres nécessaires pour chaque poste de travail automatique ou manuel.
C’est de cette manière que j’aimerais pouvoir déployer mon réseau. Ne riez pas tout le monde peut rêver, c’est pas taxer ::)
Idéalement une zone, piloté par un Mega autonome. Un train se présente à un des points d’entrée, il est équipé d’un récepteur infra-rouge. La motrice héberge un Attiny. Dans sa version la plus simple il émet en permanence le code DCC de la loco, à la détection de ce code l’Arduino demande au gestionnaire vers quel points de sortie il doit pousser le train. Dans une version plus utopiste l’Attiny a pu être programmé il porte son itinéraire.
Bien sûr le Mega informe le gestionnaire de ce passage et de l’état de tous les accessoires pour faire de belles images sur l’écran.
D’ici quelques années je vous donnerai des nouvelles en attendant merci à tous ceux qui défrichent sur le site.
-
Bonjour,
Il ne s'agit pas forcément de répartir l'intelligence mais de répartir intelligemment le matériel afin de minimiser le câblage. Effectivement répartir l'intelligence, ce que tu évoques me fait penser aux système multi-agents, est plus compliqué à gérer que lorsqu'elle est centralisée.
Donc dans mon esprit, il s'agirait plutôt de faire un système avec une intelligence hiérarchique plutôt que répartie.
-
Ouf, je vois que je ne suis pas seul à me poser ce problème de câblage.
En tous cas merci pour toutes ces réponses, elles vont encore me faire passer des nuits blanches avant d'y voir enfin plus clair.
Dans un post précédent (mon premier sur ce forum) je vous avais parlé d'un essai de reconnaissance de la loco par capteurs Hall. Je viens de tester le principe et c'est un sans faute, aussi bien à vitesse très réduite que de passer la loco à la main 3 fois plus vite que sa vitesse maximale. Avant d'en dire plus j’attends des capteurs CMS qui seront pratiquement invisibles entre les traverses.
A bientôt donc et bonne soirée
Antoine
-
Dans un post précédent (mon premier sur ce forum) je vous avais parlé d'un essai de reconnaissance de la loco par capteurs Hall. Je viens de tester le principe et c'est un sans faute, aussi bien à vitesse très réduite que de passer la loco à la main 3 fois plus vite que sa vitesse maximale. Avant d'en dire plus j’attends des capteurs CMS qui seront pratiquement invisibles entre les traverses.
J’en connais qui seront très intéressé !
Dominique
-
Bonjour à tous
Je suis très intéressé .....
Juste pour polémiquer ;)
Tout ceci c'est bien jolie, les questions y a-t-il des limites à vos projets ?????? (nbs d'Arduinos, longueur du développé du réseau, échelle pratiquée, champs magnétiques, perturbations en tout genre - IR - Eclairage, fils blindés, fils souple (section) alimentation générale du system 5Volts, 12volts (à petite distance + de 10 mètres chute de tension) etc.......
Cordialement
Marcel
-
j’ai des exemples d’installations :)
Nous réalisons l’électronique avec deux amis, Philippe et Pierre. Philippe a un blog, ici : http://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Les_trains_du_Tertre.html
Nous sommes en analogique, block system avec asservissement de vitesse. Détection uniquement par consommation. Les logiciels sont mis à jour « over the air » comme on dit :)
Philippe : échelle H0. 40 cantons, 3 bus CAN, environ 60 micro-contrôleurs. 10 + 20 + 4 nœuds CAN
Pierre : échelle N, 64 cantons, 3 bus CAN, environ 90 micro-contrôleurs 16 + 25 + 4 nœuds CAN
Pour ces deux réseaux, l’électronique est installée et opérationnelle. Pas d’erreurs sur le CAN, et de manière assez surprenante sur le réseau de Philippe, qui a choisi de réunir les cartes canton en un seul point, la mesure de FCEM des locomotives se fait parfaitement au travers de plusieurs mètres de fils.
Moi : échelle N, 38 cantons, 2 bus CAN, environ 60 micro-contrôleurs, installation en cours.
Concernant l’alimentation générale de l’informatique, il faut bien évidemment mettre un régulateur sur chaque noeud. Nous alimentons les nœuds en 9V. Mes fils d’alimentation font 1mm2.
Le premier réseau CAN qui relie les cartes traction est à 700kbits/s (un peu plus en fait, la faute au quartz de la carte où tourne le gestionnaire qui est à une fréquence idiote). Le câblage est en RJ45 : CAN + signal de synchro de PWM + signal de synchro de mesure de vitesse). Chez Philippe il est de longueur faible, toutes les cartes canton sont réunies sur 1m2. Chez Pierre, il fait le tour de la pièce, soit une quinzaine de mètres. Chez moi il fait 6m50.
Le second réseau CAN qui relie les autres cartes (signaux, aiguillages, son, éclairage, pont tournant, ...) est à 125kbits/s et est câblé en rj11 (câbles téléphoniques). Pas d’erreurs de communication non plus alors que sur ces câbles les paires ne sont pas torsadées.
Le troisième est destiné aux postes de conduites (4 maxi), postes que je n’utilise pas. Il est également à 125kbits/s. Le câblage est également rj11 mais différent car il transporte également l’alimentation du poste qui est connectable à chaud.
-
Bonjour à tous,
J'en suis à la finalisation du travail de charpentier qui préside à la réalisation d'un réseau.
Tout comme vous je suis en train de réfléchir aux types de câblages à adopté et mes premières réflexions vont effectivement vers "un Arduino par canton". Je ne'en suis qu'aux prémices mais je rejoins le projet de Christophe, pas forcément avec nodeJS mais je suis sur le même principe avec une description de réseau externe non codée en dur.
Je réfléchis à une piste en Wifi et il me suffirait de quelques unités seulement coté cantons. Bon évidement sur un réseau de 3.4m de long, et assez dense, on peut se poser la question de supprimer un bus d'autant qu'il faudra garder des fils pour les alimentations , mais c'est juste pour le challenge... A voir
Didier
-
Bonjour,
Étant cité au début de ce post et ayant un peu de temps à consacrer au forum, je me permets de préciser ma position.
1°) Je pense qu'il faut développer un module standard.
C'est à dire un module géré par un Arduino NANO et qui a pour rôle de s'occuper de 4 "machins". Pas plus, surtout.
Parmi les "machins" :
-> La détection de présence d'une seule zone (je n'ai pas dit "canton", qui peut contenir plusieurs zones)
-> la commande d'un appareil de voie (c'est à dire un servo-moteur)
-> la commande d'une LED (et donc des signaux)
On a 8 entrées et 8 sorties et donc, c'est assez.
Tout peut être est mélangé sur le même module.
Le choix est fait par la distance au "machin" (voir 2°)
2°) Un fichier texte qui donne les infos sur ce que fait le module en question (en fonction de ce qu'on y a branché).
3°) Des fiches démontables pour aller vers les "machins" avec des câbles qui ne devraient pas dépasser 30 cm.
4°) D'un module à l'autre, un câble RJ11 et un bus CAN
Donc, si un module tombe en panne, on le retire, on en prend un vierge et grâce au fichier texte spécifique et au programme standard, on régénère ce module spécifique.
On le rebranche et c'est reparti.
Denis
-
Hello,
Je réfléchis également à passer au CAN pour simplifier le câblage.
J'ai déjà un "bus" RJ45 qui relie mes 9 décodeurs infrarouges (3 brins pour l'alimentation, 1 pour le PWM à 38kHz, 4 brins pour coder en binaire sur 4 bits le détecteur qui se déclenche). Le câble est blindé sur quasiment toute la longueur, mais je commence à avoir des perturbations, il est raide, il ne sert qu'aux décodeurs IR...
Un bus CAN me permettrait de faire passer de l'info pour d'autres besoins : les consignes d'alimentation des cœurs d'aiguilles, des animations, de l'éclairage... avec un seul fil.
Je suis également parti dans l'idée d'avoir 3 arduinos répartis sur le réseau, pour simplifier le câblage : 1 "central" qui portera surtout la liaison avec la TCO (filaire, mais j'aimerais bien radio aussi), et 2 "locaux" qui s'occuperont des "machins" à proximité.
Je fabriquerai peut-être ma carte perso, un peu sur le modèle de la Sodaq Mbili (http://support.sodaq.com/sodaq-one/sodaq-mbili-1284p/) : un ATMEGA 328, un étage CAN (j'ai suivi à distance le fil de Dominique & Jean-Luc), et des prises qui exposent des pins d'alim et les entrées/sorties.
-
Je fabriquerai peut-être ma carte perso, un peu sur le modèle de la Sodaq Mbili : un ATMEGA 328, un étage CAN (j'ai suivi à distance le fil de Dominique & Jean-Luc), et des prises qui exposent des pins d'alim et les entrées/sorties.
Bon, ce vœux va être exhaussé et avec un peu de patience nous allons décrire ce que nous présenterons à Orléans, notamment une telle carte et un bus Can (sans fichier texte !).
Comme toujours la description suit le développement et la mise au point pour ne pas écrire de bêtises.
A bientôt donc sur ce sujet ;D
-
Bon, ce vœux va être exhaussé et avec un peu de patience nous allons décrire ce que nous présenterons à Orléans, notamment une telle carte et un bus Can (sans fichier texte !).
quel teasing ! 8)
-
Je suis impatient !
-
Bonjour à tous,
suite à ma question qui a démarrée ce sujet, j'ai développé, fait fabriquer les CI (en Chine) et tester 3 cartes avec base arduino nano et module CAN avec une grande partie du programme de l'article 130 (Mise en œuvre du bus CAN) de Jean-Luc et Dominique.
Je suis enchanté du résultat et vous joins 3 photos des CI où l'on voit très bien le module CAN à l'envers ainsi que l'arduino nano.
La carte Boucle permet de gérer entièrement une boucle de retournement avec:
- 1 sortie de commande de servo pour l'aiguille avec inversion du cœur d'aiguille par relais
- 2 entrées pour la position du servo (soit par contacts soit par effet Hall)
- 2 entrées détection courant (pour l'inversion du DCC dans la boucle)
- 4 entrées détection de courant indépendantes
- Prix de revient TTC: 19€
La carte 6 aiguilles gère, comme son nom l'indique, 6 aiguilles avec:
- 6 sorties servos avec inversion du cœur d'aiguille par relais
- 12 entrées pour la position des servos (soit par contacts soit par effet Hall)
- 8 entrées détection de courant indépendantes
- Prix de revient TTC: 41€
La carte Signalisation comporte:
- 24 sorties (sur ULN2008) indépendantes
- 8 entrées détection de courant indépendantes
- Prix de revient TTC: 25€
Je suis arrivé à ce choix pour optimiser un maximum les ES de l'arduino et de ce fait réduire le coût des cartes.
Les schémas et les dessins des CI sont disponibles si cela peut intéresser un des membres.
Les programmes seront forcément à personnaliser mais la base pour les échanges sur le bus CAN sont finalisés et bien testés (envoie et récupération de l'ID complète sur 2 octets).
Je tiens aussi à votre disposition la liste des pièces avec prix et adresses si besoin.
Bonne soirée à tous et à très bientôt
Antoine
-
Bonsoir Antoine.
Je suis toujours admiratif quand je vois quelqu'un aller jusqu'au bout de son projet.
Seulement 8 messages sur notre site et déjà du concret !
Bravo ! ;D ;D ;D
Denis
-
Merci Denis pour ce bel encouragement, mais je vais certainement avoir besoin de vous pour mettre un peu d'ordre au niveau des programmes.
Malgré plus de 30 ans (professionnellement) dans le microprocesseur, je ne suis de loin pas aussi organisé que vous et Dominique pour la structure de mes programmes.
De plus à 68 ans il est un peu plus dur de changer de philosophie dans le domaine du microprocesseur, j'ai toujours travaillé avec du motorola et en assembleur pur, alors quel régal la découverte du C++ et de la programmation "in situ".
Si mes cartes intéressent quelques membres, cette aide serait-elle envisageable, quitte à ce que je vous envoie 3 cartes équipées ?
Mais j'abuse peut-être :-[, dans e cas pas de soucis, on oublie ce message et on continue de partager sur ce merveilleux forum.
Très bonne journée
Antoine
-
Je sais pas :)
Pourrais tu poster les schémas ?
-
Bonjour Tony
Aurais-tu la bonté STP de nous faire partager tes:
Schéms et programme?
Marcel
-
Bonsoir tout le monde,
voici les schémas et programmes de mes cartes CAN.
Le programme de la carte signalisation (feux) n'est pas finalisé car il me manque les UGN2008 mais cela ne devrait pas beaucoup changer les choses.
Pour les autres PGM soyez indulgents :'(, je vous avais prévenu pour la mauvaise structure de mes PGM.
Un premier message pour la carte 6 aiguilles et la carte boucle, la 3è dans un second message.
A suivre donc
-
Suite et fin de mes PGM
J'attends avec impatience vos critiques et conseils
Bonne soirée à tous
-
Merci Antoine,
On va pouvoir décortiquer...
Tout d'abord, sur la philosophie.
Tu veux réduire le câblage et c'est une excellente initiative. De petits modules, des fils courts, OK.
Module aiguille :
J'aurais délocalisé la gestion des pointes de cœur juste sur l'aiguille.
Vois le fil : http://forum.locoduino.org/index.php?topic=532.0 (http://forum.locoduino.org/index.php?topic=532.0)
Quand tu regardes les schémas (de Jean-Luc et le mien), tu vois que tous les fis sont locaux.
Ils vont de l'aiguille à l'aiguille. Pas besoin de les mettre sur un circuit distant. On gagne plein de fils. C'est d'autant plus utile que ces fils véhiculent des courants forts, et donc parasités.
Module boucle :
Enfin un schéma Arduino qui prévoit l'inversion de courant pour les boucles, ponts-tournant et autres. ;D
J'en avait marre des modules LK100 et LK200 de Lenz...
Dernière remarque : tu te fournis où ? Je peux me tromper, mais je trouve ça encore "cher". Mais bien moins que dans le commerce DCC, bien sûr.
Denis
-
Pour mieux comprendre l'utilisation de ma carte boucle j'ai oublié de joindre une image avec les N° de fils, la voici.
En ce qui concerne la délocalisation des pointes d'aiguille, j'ai opté pour cette solution car mes aiguilles sont commandées par des servos avec 2 capteurs Hall pour confirmer leur position (et renvoyer l’info au TCO). Je voulais éviter à tout pris des micros-contacts pas toujours facile à mettre en œuvre.
Je suis d'ailleurs parti de l'idée de Jean-Luc (http://modelleisenbahn.triskell.org/spip.php?article35) mais j'ai mis la corde à piano à l'autre bout du palonnier ce qui confère une plus grande souplesse au déplacement. Sur la photo il manque le petit aimant.
Il y a juste 1 fil à tirer pour la pointe (est-ce ça "plein de fils" ? ;D). Par contre cela simplifie énormément la mécanique.
J'ai aussi suivi le fil 532.0 que tu m'as indiqué Denis et n'ai pas du tout compris toutes les questions concernant les risques de court-circuit ou d'étincelles lors de la commutation avec un relais.
A ma connaissance un relais n'a à aucun moment le contact repos et travail qui se touchent en même temps??? Et pour les étincelles, la commutation a toujours lieu hors consommation non?
J'ai suivi les instructions de l'excellent http://www.ho-ptit-train.be/Html/cablage_02.html et utilise des aiguilles TILLIG nouveau modèle, c'est peut-être pour cela que je ne comprend pas les problèmes évoqués.
Je risque fort de me tromper dans mon analyse, il faut dire qu'il y a encore 2 mois je ne savais pas ce qu'est le DCC ni les complications que cela engendre au niveau des aiguilles; je suis un tout nouveau passionné avide d'apprendre et de partager.
Avec quel logiciel faites vous tous vos schémas? Ils sont trop!!!
Pour Denis je joins également mes sources d'achat
Il est 2h38 et vais me coucher, bonne nuit à tous
Antoine
-
Bonjour Antoine,
Concernant les relais et les contacts, j'ai mis la réponse dans le fil correspondant (http://forum.locoduino.org/index.php?topic=532.msg5824#new (http://forum.locoduino.org/index.php?topic=532.msg5824#new))
OK pour le "plein de fils". ;)
Reste le problème des perturbations.
Il n'est jamais bon de mélanger des basses tensions logiques avec des courants "forts" d'alimentation des trains.
Plus on les éloigne, mieux c'est.
J'ai en préparation un article sur la construction d'une alimentation analogique. J'ai sorti l'oscillo pour voir comment était le "carré" sorti par l'alim.
Sympa avec une résistance simple, mais tu vas voir ce qu'il devient quand c'est un train qui l'utilise !
Concernant les prix, je ne suis pas le seul à y faire attention.
Je te conseille le magasin TME (https://www.tme.eu/fr/ (https://www.tme.eu/fr/)) qui fera encore baisser les prix. Livraison 24h, au pire 2 jours.
Denis
-
Merci Denis pour ces infos,
je vais les consulter ce soir, aujourd'hui je profite du beau temps pour faire des travaux dehors, printemps oblige 8)
A bientôt
Antoine
-
Bonjour Antoine
Je vois que tu as intégré la module CAN Niren, As tu les caractéristiques mécaniques exactes de ces modules ? dimensions, coordonnées des broches ?
-
Bonjour Jean-Luc,
tu m'apprends que c'est le module Niren et je n'ai pas trouvé les cotes mais je te joins une trace en BMP du composant que j'intègre dans tous mes montages.
Si cela ne convient pas, je peux te faire parvenir une exportation Gerber mais je doute que cela t'arrange mieux.
En dernier ressort je peux te coter moi-même le composant à partir de mon soft de réalisation PCB.
Cordialement
Antoine
-
J'ai oublié de te dire que je les monte tous à l'envers en enlevant le bornier 2 pins et en mettant des barrettes femelles comme support.
-
J'ai oublié de te dire que je les monte tous à l'envers en enlevant le bornier 2 pins et en mettant des barrettes femelles comme support.
J'ai le même problème. J'ai eu plusieurs échecs au dessoudage alors j'ai arrêté. La pastille du PCB avec tendance à se décoller mais je l'étais peut-être pas assez bien équipé en matos dessoudage.
Bravo pour tes cartes, je n'avais pas connaissance de ton projet et j'ai refait un truc dans le même genre.
-
Si cela ne convient pas, je peux te faire parvenir une exportation Gerber mais je doute que cela t'arrange mieux.
Si si au contraire, j'ai les coordonnées dans le Gerber !
-
J'ai oublié de te dire que je les monte tous à l'envers en enlevant le bornier 2 pins et en mettant des barrettes femelles comme support.
Pourtant sur les cartes que j'ai, le bornier est moins haut que barrette male + femelle. On peut donc le laisser en place. Par contre il n'y a pas la barrette pour mettre le strap de terminaison sur l'empreinte.
-
Non, comme la carte est enfichable il suffit de l'enlever pour mettre le strap. Mais pour enlever le bornier il suffit de couper à raz les 2 picots et en chauffant les pattes les unes après les autres et en tirant avec précaution du bon coté il n'y a aucune destruction de piste qui au passage ne servent plus à rien.
Je te joins le gerber. Il y a les deux versions avec et sans terminaison.
Sur mes dernières cartes j'ai même implanter des composants sous ce module.
Bonne nuit à tous
Antoine
-
Merci Antoine :)
Concernant le strap de terminaison, je pense que je l'aurais déporté sur la carte principale pour deux raisons :
- Pas besoin de retirer le module pour accéder au strap
- Une meilleure assise du module