Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Jean-Luc

Pages: [1] 2 3 ... 65
1
Les réseaux / Re : Re : Projet Jean-Luc
« le: août 16, 2018, 09:10:40 am »
    • Il y a une alimentation de PC portable. Est-ce à partir de cette alimentation que tu dérives toutes les autres ?

    Non. L’alimentation de PC portable est l’alimentation 9V. Je n’ai pas trouvé d’alimentation industrielle 9V.

    Citer
    • Quels connecteurs y-a-t-il sur la 3ème face ?

    Il n’y a pas de connecteur sur la 3ème face.

    Bonne journée

    2
    Les réseaux / Re : Re : Projet Jean-Luc
    « le: août 16, 2018, 09:06:35 am »
    Tiens, je vois que la fixation des rails, à gauche de la dernière photo, se fait avec des plaquettes qui pincent les traverses sur le support. Cela évite de coller les rails. Est-ce uniquement pour les parties cachées ?

    C’est une fixation temporaire. A terme les rails seront collés une fois le montage validé et les plaquettes seront retirées. Donc oui je vais utiliser la même technique pour les parties visibles.

    3
    Bus CAN / Re : Re : Bus CAN avec DCCpp
    « le: juillet 26, 2018, 02:38:50 pm »
    et là pas question d'utiliser la pin 3 à la place (également timer2).

    Pourquoi ?

    4
    Bus CAN / Re : Bus CAN avec DCCpp
    « le: juillet 26, 2018, 11:58:53 am »
    Bonjour,

    Si j'ai bien compris, DCCpp utilise la PWM engendrée par le TIMER 1 sur la pin 10 (OC1B) pour le signal DCC. Il pourrait très bien faire la même chose sur la pin 9 (moyennant une modification de DCCpp) et libérer ainsi le SPI. Pour rappel il n'est pas obligatoire que la pin 9 (CS) soit employée comme chip select pour le SPI. Elle doit juste être programmée en sortie pour que le SPI soit en mode maître.

    5
    Composants / Re : Re : Teensy 3.1, 3.2 - Sonorisation locomotive
    « le: juillet 25, 2018, 03:05:42 pm »
    Merci Jean-Luc,
    Par contre, je ne sais pas trop comment faire sur le Teensy  pour "et en même temps":
     - Jouer le son : playFlashRaw1
     - Recevoir les commandes de son (provenant de l'arduino) via SoftwareSerial mySerial(7, 8 ); // RX, T (sur le teensy)

    Tout d'abord il faut enlever le while qui attend la fin du son et qui bloque la réception des commandes

    Ensuite que veux tu faire ?

    Une nouvelle commande doit-elle être mise en attente en attendant que le son termine ou bien le son en cours (si il y en a un) doit-il s'arrêter pour laisser la place au nouveau ?

    6
    Composants / Re : Teensy 3.1, 3.2 - Sonorisation locomotive
    « le: juillet 25, 2018, 10:53:18 am »
    Bonjour,

    C'est toi qui bloque le CPU dans playFile1 en attendant que le son finisse de jouer :

         // Simply wait for the file to finish playing.
         while (playFlashRaw1.isPlaying()) {
         }

    7
    Débuter / Re : Tableau d'objet
    « le: juillet 14, 2018, 09:50:46 am »
    Une dernière solution qui évite de cosommer plus de mémoire que nécessaire mais qui n'est applicable que pour un tableau alloué statiquement est de référencer directement le constructeur dans l'initialisation du tableau. Ceci infirme une de mes affirmation précédentes. Je pense que cette façon de faire n'est apparue qu'avec C++11.

    Comme ceci :

    class Led {
      private: uint8_t mPin;
      public: Led(uint8_t inPin) : mPin(inPin) {}
      public: void display() { Serial.println(mPin); }
    };

    Led ledTab[] = {
      Led(10),
      Led(8),
      Led(3),
      Led(2)
    };


    void setup()
    {
      Serial.begin(115200);
      for (int i = 0; i < 4; i++) {
        ledTab[i].display();
      }
    }

    void loop()
    {
    }

    8
    Débuter / Re : Tableau d'objet
    « le: juillet 10, 2018, 04:58:10 pm »
    Pas de soucis Pierre  ;)

    9
    Débuter / Re : Re : Interruption petite énigme à résoudre
    « le: juillet 10, 2018, 04:54:06 pm »
    Oui j'ai déjà fait le test.
    Il y a plus ou moins 600 µs d'écart entre les valeurs qui apparaissent identique en ms.

    Je pourrait contourner le problème mais c'est toujours mieux de savoir pour progresser.

    Et donc à l'oscillo tu vois 2 fronts séparés de 600µs ?

    10
    Débuter / Re : Tableau d'objet
    « le: juillet 10, 2018, 04:26:31 pm »
    C++ est un langage compliqué avec des pièges à tous les coins de rues  :)

    Et donc ta question initiale était un peu trop générale pour une réponse courte, ce qui explique le silence relatif.

    Oui on peut faire un tableau d'objets. Oui les objets seront construits mais le constructeur appelé sera celui sans argument : on ne peut pas passer des argument lors de la construction de chaque objet d'un tableau (en fait si, dans le cas où le tableau est initialisé explicitement, voir http://forum.locoduino.org/index.php?topic=549.msg6577#msg6577).

    Dans la manière dont tu t'y es pris : déclarer des objets puis les utiliser comme valeur d'initialisation de ton tableau, il y a 2 problèmes :
    • l'initialisation du tableau réalise une copie des objets
    • La copie d'objet est piègeuse

    Pour le 1., la conséquence est que tu vas avoir tes objets en doublon. D'une part tes objets led1, led2 et led3 et d'autre part une copie dans le tableau. Donc une consommation de mémoire double et un risque de confusion : appeler une méthode de led1 et une méthode de tableau_led[0] ne s'adresse pas au même objet.

    Pour le 2., copier un objet est fait selon différentes façons :
    • Il n'existe pas de constructeur par recopie. La copie est réalisée en copiant brutalement la zone mémoire occupée par l'objet
    • Il existe un constructeur par recopie : un constructeur de la forme Led(Led & objToCopy) ou bien un opérateur d'affectation : operator=(Led & objToCopy). La copie est réalisée en appelant le constructeur par recopie ou l'opérateur =

    Qu'est ce que ça change ? Eh bien si l'objet à copier contient un membre qui est un pointeur vers un tableau alloué dynamiquement lors de la construction de l'objet, la copie brutale réalisera une copie du pointeur. Par conséquent, l'objet et ça copie partageront ce tableau alloué dynamiquement, ce qui n'est peut être pas ce que l'on veut. Dans ce cas, il faut définir un constructeur par recopie dont le rôle sera d'allouer un tableau et d'effectuer la copie du tableau. L'objet et sa copie ont donc leur propre tableau au lieu d'en partager un seul.

    En résumé, faire :

    Led led1;
    Led led2;
    Led led3;

    Led tabl[] = { led1, led2, led3 };

    Ne fait sans doute pas ce que tu voudrait. Si il est nécessaire d'avoir des arguments pour construire un objet, il vaut mieux avoir un objet Led avec une méthode permettant de l'initialiser à postériori, appelons la init. Donc il suffit d'écrire

    Led tabl[3];

    void setup()
    {
      for (int i = 0; i < 3; i++) {
        tab[i].init(monArgumentQuiVaBien);
      }
    }

    11
    Débuter / Re : Interruption petite énigme à résoudre
    « le: juillet 10, 2018, 11:04:01 am »
    Et si tu affiches micros() au lieu de millis() ?

    12
    Débuter / Re : Interruption petite énigme à résoudre
    « le: juillet 10, 2018, 09:01:16 am »
    Bonjour Rob1

    En branchant l'oscilloscope sur la broche 2 du Uno, que voit on ?

    13
    Débuter / Re : Carte Arduino plus visible ?
    « le: juillet 09, 2018, 01:16:45 pm »
    Oui mais non

    Le Leonardo est différent. Il est équipé d'un ATMega 32u4 qui possède une cellule USB. La communication avec l'ordinateur hôte de développement est donc assurée directement pas le bootloader sans l'assistance d'un composant tier comme ceux que tu cites.

    Donc il s'agirait de reflasher un bootloader

    https://electronut.in/bootloader-atmega32u4/

    14
    Bus DCC / Re : Re : Gare cachée en DCC
    « le: juillet 05, 2018, 03:32:38 pm »
    Bonjour Marc Henri

    En équipant la gare cachée de détecteurs de présence, par exemple par consommation de courant, l'Arduino pourrait, connaissant les emplacements initiaux des locos et la position des aiguilles, en déduire quelle loco est arrivée sur quelle voie de la gare cachée.

    Oui, et je rajouterais qu'en mettant cet Arduino entre la centrale ROCO et la voie avec un rôle de passerelle, il pourrait intercepter les ordres adressés au loco, en se basant sur l'adresse, et quand une, ou plusieurs, locos sont en approche de la gare cachée, prendre la main en automatique et la ralentir pour l'arrêter conformément à la politique de gestion de la gare.

    15
    Bus DCC / Re : Gare cachée en DCC
    « le: juillet 05, 2018, 02:45:58 pm »
    Ça va mal se passer étant donné qu'il y a une latence, celle du booster) entre le signal émis par la centrale et celui émis par le booster. Par conséquent une Loco qui passe de la zone alimentée en direct à la zone alimentée via le booster verra pendant une durée égale à cette latence du +15V et du -15V. Donc un court jus.

    En effet, les 2 signaux ne sont forcément pas en phase. Cela voudrait dire qu'il est impossible d'alimenter un grand circuit avec plusieurs sources DCC ?

    Je pense que si tu fais un arbre de booster équilibré de manière à ce que chaque section alimentée le soit en traversant un nombre de booster égal, le déphasage sera trop faible pour que ça pose problème.

    Citer
    Une question qui se pose : comment savoir que la loco qui est détectée à l'approche de la gare cachée a tel ou tel adresse ? Qui supervise le circulation ?

    C'est bien la "nouvelle question" que j'ai mis dans mon message. Là tu ne m'aides pas beaucoup mon cher Jean-Luc  ;) . Ce serait un arduino qui superviserait la circulation de façon automatique (ça fonctionne déjà en tous cas sur le papier et avec l'aide de ton article sur les gares cachées)

    Du coup que fait la ROCO ? Comment lui donnes-tu des ordres à partir de l'Arduino ? En fait je ne comprends pas trop l'architecture visée. L'Arduino qui superviserait la circulation connait-il les adresses des Locos ?

    Pages: [1] 2 3 ... 65