Messages

1336

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.

1337

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 

1338

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.

1339

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.

1340

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.

1341

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.

1342

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

1343

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.

1344

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.

1345

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

1346

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.

1347

Présentez vous ! / Re : Bonjour à tous

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

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

1348

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 ?

1349

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.

1350

Bus CAN / Re : BreakoutBoard CAN

« le: janvier 24, 2015, 06:21:50 pm »

Oui, c'est avec les filtres. Si aucun filtre n'est en place, tous les nœuds reçoivent tous les messages sauf ceux qu'ils émettent.

Comme je t'expliquais jeudi, le CAN fonctionne un peu comme un crieur public. Tous les nœuds sont potentiellement destinataires. Si des nœuds ne sont intéressés que par certains messages, ils doivent mettre en place des masques et des filtres

Il y a 2 masques et 6 filtres. Il faut tous les initialiser.

Exemple :

Code: [Sélectionner]

  CAN.init_Mask(0,0,0xFFFF);
  CAN.init_Mask(1,0,0xFFFF);
  CAN.init_Filt(0,0,1); // Filtre 0, trame standard, id = 1
  CAN.init_Filt(1,0,3); // Filtre 1, trame standard, id = 3
  CAN.init_Filt(2,0,0); // Filtre 2, trame standard, id = 0
  CAN.init_Filt(3,0,0); // Filtre 3, idem
  CAN.init_Filt(4,0,0); // Filtre 4, idem
  CAN.init_Filt(5,0,0); // Filtre 5, idem

Les masques font que tous les bits de l'identifiant sont significatifs
Les filtres font que seuls les identifiants 0, 1 et 3 sont acceptés