Messages

1366

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 02, 2015, 11:48:35 am »

Si tu envisages d'aller jusqu'à 13 modules, il ne faut pas que la solution de communication choisie te limite. Même si tu ne sais pas si tu iras jusque-là. Nous avons tous nos rêves et il faut se donner les moyens de les réaliser

Donc potentiellement tu auras 14 nœuds sur ton réseaux: le maître + 13 modules et un bus que s'étend sur une vingtaine de mètres. Les interfaces de communication natives de l'Arduino (I2C, SPI, série) ne sont pas du tout faites pour une telle distance si on veut un débit suffisamment élevé et une bonne sûreté de fonctionnement. De plus, elles n'implémentent que de la communication très bas niveau.  Le lien série n'est pas un bus comme le signale Guillaume et est donc hors jeu.

Donc en bus fiable, prévu pour être déployé sur une grande distance, rapide, avec détection d'erreur et des contrôleurs peu chers qui gèrent la totalité du protocole, il y a le CAN. Problème, les shields CAN sont fort chers (pour une raison qui m'échappe) et les clôneurs chinois ne se sont pas attaqués au créneau. Du coup nous avons conçu un module CAN dont le prix de revient (en kit avec PCB professionnel) est d'environ 6€50. La communication avec l'Arduino se fait par le bus SPI. La bibliothèque est tout simplement celle du shield CAN de seeedstudio. Nous avons fait fabriquer 10 ex du PCB pour 11 livrés chez Electrodragon. Dominique en a 6, Thierry 2 et moi 3. Je sais qu'Hubert est candidat pour quelques exemplaires donc une seconde commande pourrait être faite. Donc si tu veux essayer, c'est faisable. Comme c'est le bus que j'utilise sur mon réseau et que dans les projets LOCODUINO nous somme partis sur ce bus, il y aura prochainement des articles consacrés au CAN avec des exemples de mise en oeuvre.

Concernant l'éclairage public et des bâtiments, une alternative est le TLC5940 de Texas. Ce circuit permet de piloter 16 DEL en courant (donc sans résistance) chacune avec une PWM 12 bits. Il est assez cher en Europe mais bon marché sur eBay Chine. Il y a une bibliothèque pour le piloter. Ces circuits peuvent être chainés pour piloter plus de DEL sans consommer plus de fils sur l'Arduino. J'en ai quelques uns en stock et j'ai testé, ça fonctionne très bien.

Pour l'horloge de gare, nous sommes preneurs d'un article décrivant le système 

1367

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 02, 2015, 09:12:45 am »

Bonjour petitrain

Joli projet, il y a beaucoup de choses.

Quelques questions:

1) quelle serait la longueur de fil maximum totale pour la communication entre les Arduino ?
2) est-ce que tous les Arduino emettent des informations ou bien y a-t-il un seul émetteur et plusieurs récepteurs.
3) est-ce que c'est gênant que la communication se fasse mal ponctuellement ?

Concernant l'horloge HO avec un afficheur à DEL, il existe des afficheurs de petite taille conçus pour l'heure avec le ´:´ de séparation : http://www.tme.eu/fr/details/lfd028aue-103a/afficheurs-led-quadruples/#  A l'échelle ça donne une horloge avec des chiffres de 60cm de haut. Ça consomme 13 fils, un Arduino y passe.

Concernant les ULN2803, chaque sortie supporte effectivement 500mA mais si les 8 sorties sont en route, ça fait 4A. La datasheet n'est pas très claire à ce sujet mais, vers la fin, elle parle de 2,5A. Donc je ne suis pas sûr que l'ULN puisse tenir dans ces conditions. A tester, un ULN ne coûte pas si cher. Si il s'agit de commander l'éclairage par bande de DEL, l'alternative est de ne pas les alimenter indépendamment mais en une fois avec un MOSFET de puissance. Pour mon réseau, j'ai un MOSFET pour 5m de DEL 5050 ton chaud et un MOSFET pour 5m de DEL 5050 blanc. De mémoire j'ai 7,5A par ruban.

1368

Vos projets / Re : Animations lumineuses

« le: février 01, 2015, 09:52:05 pm »

L'idée est très bonne. Mais c'est diablement coton a mettre en oeuvre 

1369

Vos projets / Re : Animations lumineuses

« le: février 01, 2015, 07:24:55 pm »

Réécrire delay n'est pas si simple. D'accord au lieu d'attendre que le temps passe, on bloque l'appelant de delay. Ensuite que fait-on ? Il faudrait pouvoir donner la main à un autre programme. Puis quand le temps serait écoulé, préempter cet autre programme et redonner la main à celui qui était bloqué. Évidemment cet autre programme peut lui même appeler delay.

Réécrire delay c'est en fait ecrire un système d'exploitation multitâche préemptif. Pas aussi compliqué qu'un système d'exploitation pour machine de bureau mais quand même assez compliqué à ecrire.

1370

Présentez vous ! / Re : Bonjour à toute l'équipe.

« le: janvier 31, 2015, 11:00:23 pm »

Bienvenue sur LOCODUINO. Pour les questions, n'hésite surtout pas !

Bonne fin de week-end.

1371

Bus CAN / Re : BreakoutBoard CAN

« le: janvier 31, 2015, 04:39:27 pm »

Bonjour,

Je viens de faire un essai de performance sur le CAN.

Le bus est réglé a 125kbps, pas agressif donc mais, pour les accessoires, c'est largement suffisant.
Deux Arduino sont connectés : un Nano et un compatible Uno (le Visduino que je viens d'acheter).

Les deux Arduino sont chargés avec le même sketch. Le sketch fait la chose suivante :

Dans setup
- lecture d'une broche numérique pour avoir l'identifiant du message CAN. Sur l'un des Arduino, cette broche est raccordée a la masse et sur l'autre elle est raccordée à 5V. Les sketchs récupèrent dont respectivement un identifiant 0 et un identifiant 1.
- intialisation d'un buffet ne comprenant qu'un seul octet.
- après initialisation du CAN, envoi d'une trame avec l'octet en question.

Dans loop
- attente de réception de message, on utilise une interruption externe.
- quand le message est reçu, il est lu, on vérifie que ca longueur est bonne et que l'octet de données est bon puis il est renvoyé.

C'est donc une sorte de double ping pong avec deux messages qui tournent.

Le rythme d'arrivée des interruptions sur un des Arduino est de 1,64ms et stable. C'est équivalent à 205 bits. Sachant qu'au maximum une trame comportant un octet de données comprend 65 bits et que le contrôleur attend 11 bits pour s'assurer que le bus est libre, soit 76 bits. Donc 152 bits. Il y a du temps perdu dans le programme et sur la communication SPI également. Ça me semble donc cohérent.

1372

Bus DCC / Re : DCC & CVs

« le: janvier 31, 2015, 11:30:22 am »

Thierry,

Voici le montage de mesure de chute de tension. Il est extrait des cartes faites par Pierre Molinaro (un collègue) que j'utilise sur mon réseau.

Voir la pièce jointe ci-dessous.

À gauche, on a la tension de base du DCC avant le booster que j'ai arbitrairement fixée à 15V. L'alimentation du booster traverse R3 et entre sur le booster. Quasiment tout le courant passe par R3, R1 et R2 faisant 1MΩ, le courant qui les traverse est négligeable. Le courant i_o qui traverse R8 est donné par l'équation suivante :

i_o = (1+u)(V₊-V_-) / (u R0)

u est le rapport de R5 sur R4. On a forcément R1 = R2 = R6 = R4 et R5 = R7

Donc ici, le courant qui traverse R8 est égal à (1+1x10^-3)(V₊-V_-)/(1x10^-3 x 1x10⁶)

donc (1+1x10^-3)(V₊-V_-)/1000

Donc par exemple si 100mA traverse R3, V₊-V_- = 1 x 0,1 = 0,1

i_o = 1,001 x 0,1 / 1000 ~ 1mA. Et donc la tension en entrée de l'Arduino est de 2000 x 0,001 = 2V

Si ça monte à 160mA, ça fait 3,2V

D1 empêche que la tension ne monte au dessus de 5V et casse l'entrée analogique de l'Arduino.

Ensuite, il faut changer les valeurs de R5 et R7 selon ce qui est consommé au repos sur la voie de programmation. Une petite campagne de mesure s'impose.

1373

Infos et bonnes affaires / ElectroDragon rime avec service client

« le: janvier 30, 2015, 05:51:51 pm »

Bonsoir,

Lors de ma dernière commande chez ElectroDragon, j'ai pris un Visduino pour voir comment ça marchait. La carte compatible Uno coûte $4.90. http://www.electrodragon.com/product/arduino-compatible-visduino-uno-r3/



J'ai eu un petit problème de qualité dessus. Après deux branchements du câble sur le connecteur USB, le connecteur s'est dessoudé. Les pattes de fixation du connecteur étaient mal soudées. J'ai ressoudé avec quelques difficultés pour les broches du connecteurs car elles sont proches et on est gêné par le quartz. Finalement tout marchait bien.

J'ai ensuite contacté ElectroDragon pour signaler le problème tout en leur disant que j'avais réparé la carte. Le contact m'a proposé un remboursement ou un bon d'achat (sans préciser la somme). J'ai choisi le bon d'achat qui s'est avéré être de $9  presque 2 fois le prix de la carte

1374

Bus DCC / Re : DCC & CVs

« le: janvier 29, 2015, 05:07:39 pm »

Oui, il faut mesurer la consommation du décodeur. On fait ça en mettant une résistance dans le circuit, par exemple 1Ω. Quand le décodeur ne surconsomme pas de 60mA, disons qu'il consomme 100mA, la chute de tension dans la résistance va être de 100mV. Quand il surconsomme, 160mA, elle va être de 160mV. Le problème est que ce différentiel de tension n'a pas de référence de masse. En mettant un ampli op aux bornes de la résistance, on transforme ce différentiel en une tension par rapport à la masse que tu peux ensuite entrer sur une entrée analogique. Je suis pas un expert là dessus mais j'ai un collègue qui peut m'aiguiller.

Il y a un montage sur mes cartes alimentation qui permet de mesurer un courant via un ampli op, il faut sans doute adapter mais il s'agit du même type de montage.

1375

Vos projets / Re : Adaptation aux PICs

« le: janvier 28, 2015, 10:24:58 am »

Bonjour Francis

Après discussion avec mes camarades, nous pensons que LOCODUINO n'est pas approprié pour parler micro-contrôleur et train miniature au sens large. En effet, la spécificité de l'Arduino est l'ensemble du logiciel qui permet de s'abstraire dans la plupart des cas des détails du matériel (dans la plupart des cas car un contre-exemple est la série d'articles de Christian sur les timers des AVR) et de simplifier la prise en main. Comme il y a déjà beaucoup de choses à assimiler pour pouvoir utiliser des bibliothèques et assembler des systèmes logiciels, la complexité nous semble largement suffisante.

Par conséquent, l'ouverture d'un forum dédié PIC est malheureusement hors sujet. Parler des spécificités de ces micro-contrôleurs est également hors-sujet. Par contre, parler des PIC dans le contexte Pinguino (ou Picduino qui est une alternative) qui est un couple IDE / bibliothèques dans les grandes lignes compatible avec Wiring et les autres bibliothèques Arduino, pourquoi pas. Parler de principe d'applications du point de vue architecture logicielle également même si ce n'est pas mis en œuvre sur Arduino

Cordialement.

1376

Bus DCC / Re : DCC & CVs

« le: janvier 27, 2015, 04:08:07 pm »

Ce n'est pas ça que tu cherches ? http://www.nmra.org/sites/default/files/s-9.2.3_2012_07.pdf

1377

Présentez vous ! / Re : Le bonjour de Francis8

« le: janvier 27, 2015, 10:14:16 am »

Bonjour Francis et bienvenue sur le forum LOCODUINO.

Je programme également un peu sur PIC18.

1378

Présentez vous ! / Re : Bonjour à tous

« le: janvier 26, 2015, 01:41:29 pm »

Bienvenue parmi nous ! N'hésite pas sur les questions 

1379

Débuter / Re : problème de driver

« le: janvier 26, 2015, 01:40:16 pm »

Bonjour,

L'ordinateur de bureau serait-il sous Windows 7 ? Cette vidéo explicative correspondrait-elle au problème ?

1380

Bus CAN / Re : BreakoutBoard CAN

« le: janvier 24, 2015, 06:33:26 pm »

Plus la valeur de l'identifiant est faible et plus sa priorité est élevée.

Quand on construit un système avec du CAN, on définit une messagerie : l'ensemble des messages qui vont transiter et leur identifiant.

Par exemple, supposons que tu utilises le bus pour envoyer des ordres à des moteurs d'aiguillage et pour envoyer des ordres à des signaux. Tu vas définir un jeu d'identifiants pour les messages destinés aux cartes qui commandent les moteurs d'aiguille. On va rester en trame standard, donc les identifiants font 11 bits. Supposons qu'au maximum tu aies 16 cartes de moteurs d'aiguillage : 4 bits

Par exemple, on va choisir un identifiant qui sera 0000111xxxx, xxxx étant le numéro de carte. Ensuite les données du message vont spécifier la position de chaque moteur. Les cartes aiguillage vont donc définir un masque à 11111111111 (donc 0xFFFF) dans la bibliothèque et un filtre à 0000111xxxx, xxxx étant défini par la position d'un dip-switch sur la carte. Ensuite si tu branches une carte pour piloter le TCO et que tu veuilles recevoir tous les ordres à destination des moteurs d'aiguillage, elle spécifiera un masque à 11111110000 car xxxx n'a pas d'importante et un filtre à 00001110000, comme les 4 bits de poids faible du masque sont à 0, les 4 bits de poids faible du filtre sont ignorés dans la comparaison avec les identifiants des messages entrant. Donc le TCO recevra tous les messages à destination des cartes aiguillage.

Pour les signaux, supposons qu'on ait 32 cartes, on va choisir un identifiant moins prioritaire : 000010xxxxxx. Idem, masque à 11111111111, filtres à 000010xxxxx, xxxxx étant récupéré d'un dip-switch. Le TCO quand à lui aura un 2e masque à 111111 et un 2e filtre à 00001000000. Il récupérera tous les ordres pour les signaux.

Enfin, si les cartes de pilotage des aiguillages émettent les positions effectives récupérée via des contacts de fin de course, on attribue un autre identifiant, 0000001xxxx, plus prioritaire car la connaissance de la position des aiguillages est plus importante que ce qui s'affiche sur les feux ou les commandes des aiguillages. Les autres cartes aiguillage et les cartes feux ne verront pas ces messages car cet identifiant n'est pas accepté par leur filtre.