871
Bus CAN / Re : Les cartes CAN en 8MHz
« le: septembre 15, 2017, 07:14:54 pm »
À 500kb, pas de soucis, c'est comme 1Mb avec un quartz à 16MHz 
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
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.
872
Bus CAN / Re : Les cartes CAN en 8MHz
« le: septembre 15, 2017, 03:07:57 pm »
Je confirme que PS2 doit être compris entre 2 et 8. En effet, PS2 peut être raccourcis de 1 (ou plus si sa valeur est > 2) pour synchroniser les nœuds. Comme il ne peut pas devenir nul, il doit au minimum être à 2
Par conséquent, on ne peut pas configurer le bus en 1Mb avec des cartes dont le quartz est à 8MHz
Par conséquent, on ne peut pas configurer le bus en 1Mb avec des cartes dont le quartz est à 8MHz
873
Bus CAN / Re : Le bus CAN
« le: septembre 14, 2017, 05:32:48 pm »
Bonjour Gérard,
Je vais contredire en partie Dominique.
Bien que le signal soit différentiel, la différence de tension entre les masses des nœuds connectés aux réseau CAN ne doit pas dépasser une certaine valeur. La norme ISO-11898 indique un différentiel compris entre -2V et +7V. Le MCP2551 de Microchip indique de -12V à +12V. En pratique, quand toutes les cartes sont branchées sur une ou plusieurs alimentations, le réseau EDF donne une référence commune à tout le monde.
Dans ta plateforme d'essais, un problème de communication pourrait survenir si un ensemble de nœuds CAN est alimenté via un bloc secteur, alors qu'un autre ensemble de nœuds est alimenté via l'USB d'un ordinateur portable fonctionnant sur batterie. Dans ce cas, il se pourrait que le différentiel de masses dépasse ce qui est toléré avec des erreurs de transmission à la clé.
Je vais contredire en partie Dominique.
Bien que le signal soit différentiel, la différence de tension entre les masses des nœuds connectés aux réseau CAN ne doit pas dépasser une certaine valeur. La norme ISO-11898 indique un différentiel compris entre -2V et +7V. Le MCP2551 de Microchip indique de -12V à +12V. En pratique, quand toutes les cartes sont branchées sur une ou plusieurs alimentations, le réseau EDF donne une référence commune à tout le monde.
Dans ta plateforme d'essais, un problème de communication pourrait survenir si un ensemble de nœuds CAN est alimenté via un bloc secteur, alors qu'un autre ensemble de nœuds est alimenté via l'USB d'un ordinateur portable fonctionnant sur batterie. Dans ce cas, il se pourrait que le différentiel de masses dépasse ce qui est toléré avec des erreurs de transmission à la clé.
874
Bus CAN / Les cartes CAN en 8MHz
« le: septembre 12, 2017, 06:21:10 pm »
Comme je suis en train de faire ma propre bibliothèque pour le 2515, je regarde en détails son fonctionnement ainsi que les normes et recommandations pour la mise en œuvre d'un bus CAN.
Via la configuration on détermine le débit du bus.
La durée d'un bit est quantifiée en TQ (Time Quantum). Cette durée est divisées en 4 segments successifs dans le temps :
1 - Le segment de synchronisation (SyncSeg) qui est de durée fixe : 1 TQ
2 - Le segment de propagation (PropSeg) qui permet de tenir compte du temps de propagation du signal dans le bus. Il peut être programmé de 1 à 8 TQ
3 - Le segment de phase 1 (PS1), également programmable entre 1 et 8 TQ
4 - Le segment de phase 2 (PS2), programmable entre 2 et 8 TQ (plus loin dans la datasheet, c'est de 1 à 8, enfin passons)
Par ailleurs il y a des contraintes :
a - PropSeg + PS1 ≥ PS2
b - PropSeg + PS1 ≥ 2
l'échantillonnage du bit présent sur le bus est réalisé à la fin de PS1 et doit se situé entre 60 et 70% de la durée du bit d'après Microchip mais pour CANOpen et DeviceNet c'est 87,5 et la norme ARINC dit 75%.
TQ est dérivé de l'oscillateur dédié au 2515 (Fosc = 16MHz habituellement, 8MHz sur les cartes chinoises) via un Baud Rate Prescaler (BRP) sur 6 bits et qui peut donc avoir une valeur comprise entre 0 et 63 :
TQ = 2 x (BRP + 1) / Fosc
Donc avec Fosc = 16MHz et BRP = 0 (division minimum), on a TQ = 125µs et pour faire un bit, il faut 8 x TQ
Par exemple, la bibliothèque mcp_can utilise les valeurs suivantes pour un bus à 1Mbits :
BRP = 0 (TQ = 125µs)
PropSeg = 1 TQ (0)
PS1 = 3 TQ (2)
PS2 = 3 TQ (2)
Avec le SyncSeg qui dure 1 TQ, on a bien 8 TQ. L'échantillonnage est à 5/8 = 62,5%
Avec un carte à 8MHz, on a 4 x TQ de 250µs pour faire la durée du bit. Comme le SyncSeg prend 1 TQ, il en reste 3 (PropSeg = 1, PS1 = 1 et PS2 = 1) et ça coince car à priori PS2 est au mini à 2 TQ. Je ne suis pas persuadé qu'on puisse atteindre 1Mb avec un quartz à 8MHz.
Via la configuration on détermine le débit du bus.
La durée d'un bit est quantifiée en TQ (Time Quantum). Cette durée est divisées en 4 segments successifs dans le temps :
1 - Le segment de synchronisation (SyncSeg) qui est de durée fixe : 1 TQ
2 - Le segment de propagation (PropSeg) qui permet de tenir compte du temps de propagation du signal dans le bus. Il peut être programmé de 1 à 8 TQ
3 - Le segment de phase 1 (PS1), également programmable entre 1 et 8 TQ
4 - Le segment de phase 2 (PS2), programmable entre 2 et 8 TQ (plus loin dans la datasheet, c'est de 1 à 8, enfin passons)
Par ailleurs il y a des contraintes :
a - PropSeg + PS1 ≥ PS2
b - PropSeg + PS1 ≥ 2
l'échantillonnage du bit présent sur le bus est réalisé à la fin de PS1 et doit se situé entre 60 et 70% de la durée du bit d'après Microchip mais pour CANOpen et DeviceNet c'est 87,5 et la norme ARINC dit 75%.
TQ est dérivé de l'oscillateur dédié au 2515 (Fosc = 16MHz habituellement, 8MHz sur les cartes chinoises) via un Baud Rate Prescaler (BRP) sur 6 bits et qui peut donc avoir une valeur comprise entre 0 et 63 :
TQ = 2 x (BRP + 1) / Fosc
Donc avec Fosc = 16MHz et BRP = 0 (division minimum), on a TQ = 125µs et pour faire un bit, il faut 8 x TQ
Par exemple, la bibliothèque mcp_can utilise les valeurs suivantes pour un bus à 1Mbits :
BRP = 0 (TQ = 125µs)
PropSeg = 1 TQ (0)
PS1 = 3 TQ (2)
PS2 = 3 TQ (2)
Avec le SyncSeg qui dure 1 TQ, on a bien 8 TQ. L'échantillonnage est à 5/8 = 62,5%
Avec un carte à 8MHz, on a 4 x TQ de 250µs pour faire la durée du bit. Comme le SyncSeg prend 1 TQ, il en reste 3 (PropSeg = 1, PS1 = 1 et PS2 = 1) et ça coince car à priori PS2 est au mini à 2 TQ. Je ne suis pas persuadé qu'on puisse atteindre 1Mb avec un quartz à 8MHz.
875
Bus CAN / Re : Le bus CAN
« le: septembre 12, 2017, 05:47:57 pm »
La différence est le
Qui indique où ça échoue. Et ça échoue immédiatement lors de la mise en mode configuration du 2515 qui constitue la première tentative de lecture d'un registre du 2515 via le SPI.
Pour moi il y a un problème de câblage.
Citer
Enter setting mode fall
Qui indique où ça échoue. Et ça échoue immédiatement lors de la mise en mode configuration du 2515 qui constitue la première tentative de lecture d'un registre du 2515 via le SPI.
Pour moi il y a un problème de câblage.
876
Bus CAN / Re : Le bus CAN
« le: septembre 11, 2017, 04:51:17 pm »
Bonjour Gérard
Ah. On n'est pas sur la même version. J'ai regardé la version qui est ici : https://github.com/Seeed-Studio/CAN_BUS_Shield
D'où vient la votre ?
Concernant l'éditeur, j'utilise atom (https://atom.io) mais l'éditeur de l'IDE Arduino affiche également les numéros de ligne via une case à cocher dans les préférences.
Amicalement
Ah. On n'est pas sur la même version. J'ai regardé la version qui est ici : https://github.com/Seeed-Studio/CAN_BUS_Shield
D'où vient la votre ?
Concernant l'éditeur, j'utilise atom (https://atom.io) mais l'éditeur de l'IDE Arduino affiche également les numéros de ligne via une case à cocher dans les préférences.
Amicalement
877
Bus CAN / Re : Le bus CAN
« le: septembre 11, 2017, 01:33:33 pm »
Essaye ceci pour voir où ça coince :
Ligne 56 de mcp_can_dfs.h (dans le répertoire où est la bibliothèque CAN), dans la directive :
remplace le 0 par un 1 :
La progression de l'initialisation apparaîtra sur la console
Ligne 56 de mcp_can_dfs.h (dans le répertoire où est la bibliothèque CAN), dans la directive :
Code: [Sélectionner]
#define DEBUG_EN 0
remplace le 0 par un 1 :
Code: [Sélectionner]
#define DEBUG_EN 1
La progression de l'initialisation apparaîtra sur la console
878
Bus CAN / Re : Le bus CAN
« le: septembre 11, 2017, 08:27:03 am »
CAN bus init ok indiqué que la communication SPI entre l'Arduino et le MCP2515 fonctionne correctement.
Pourrait-on avoir le code du Nano ? Quelle broche est employée pour le CS ?
Pourquoi la led TX flashe-t-elle ? Le programme du Nano écrit-il en permanence sur la sortie série ?
Pourrait-on avoir le code du Nano ? Quelle broche est employée pour le CS ?
Pourquoi la led TX flashe-t-elle ? Le programme du Nano écrit-il en permanence sur la sortie série ?
879
Vos projets / Re : 2D2 Echelle 1/32
« le: septembre 09, 2017, 08:29:30 am »
Je vais mettre mon grain de sel :
- le L298. C'est de la vieille techno, ça chauffe, c'est encombrant. Il vaut mieux prendre un pont en H CMOS. Pololu fait des modules bon marché destinés normalement à la robotique. Par exemple : https://www.pololu.com/product/1213.
- le son. Les modules MP3 sont biens pour passer une bande son mais pour sont ils les mieux adaptés pour produire des bruitages ? Sur les Teensy il y a une sortie analogique et une bibliothèque permet de jouer, de manière non bloquante, des sons stockés dans la mémoire du micro, ce qui permet de construire des séquences dynamiquement par programme ou de jouer en boucle.
- une alimentation 5V. Je suggérerais plutôt d'attaquer VIN en 9V ce qui permettra de bénéficier de l'alimentation régulée de l'Arduino.
- pont de diodes pour redresser le DCC. Le DCC étant un signal carré, La tension récupérée en sortie du redresseur sera celle du DCC. 18V ? Il y aura quelques trous à 0V du fait des temps de montée et de descente qui ne sont pas nuls mais les capas en entrée du régulateur 12V lisseront cela. Attention de mettre des diodes assez costauds.
- le L298. C'est de la vieille techno, ça chauffe, c'est encombrant. Il vaut mieux prendre un pont en H CMOS. Pololu fait des modules bon marché destinés normalement à la robotique. Par exemple : https://www.pololu.com/product/1213.
- le son. Les modules MP3 sont biens pour passer une bande son mais pour sont ils les mieux adaptés pour produire des bruitages ? Sur les Teensy il y a une sortie analogique et une bibliothèque permet de jouer, de manière non bloquante, des sons stockés dans la mémoire du micro, ce qui permet de construire des séquences dynamiquement par programme ou de jouer en boucle.
- une alimentation 5V. Je suggérerais plutôt d'attaquer VIN en 9V ce qui permettra de bénéficier de l'alimentation régulée de l'Arduino.
- pont de diodes pour redresser le DCC. Le DCC étant un signal carré, La tension récupérée en sortie du redresseur sera celle du DCC. 18V ? Il y aura quelques trous à 0V du fait des temps de montée et de descente qui ne sont pas nuls mais les capas en entrée du régulateur 12V lisseront cela. Attention de mettre des diodes assez costauds.
880
Shields et Modules / Re : Re : Re : Module pour boucle de retournement
« le: août 31, 2017, 08:49:56 am »Pas de souci avec des interrupteurs à lames souples (+aimant obligatoire), mais le sens de circulation est imposé. Il en faudrait deux par boucle. Et passer à une détection infra-rouge. Mais bon, ce n'est pas ce que je cherche, avec une détection intégrée.
Personnellement, je n'irais pas mettre une détection événementielle, par nature peu fiable, pour gérer un système ou une faute engendre un court circuit.
Il n'y a que la détection de présence par consommation qui soit adaptée à ce problème.
Citer
Pour ce qui est du montage maison, les demi-cantons amont/aval devraient pouvoir être évités si on en croit le TK200.
Le TK200 réagit au court-circuit.
881
Shields et Modules / Re : Module pour boucle de retournement
« le: août 31, 2017, 12:06:53 am »
Et puis c'est pas vraiment foufou côté programmation Arduino.
882
Shields et Modules / Re : Module pour boucle de retournement
« le: août 30, 2017, 12:18:16 pm »un montage maison prévu pour l'analogique (ILS), mais si la commutation se fait par relais, ce serait OK en DCC 8,2€ :
http://www.cc2rails.com/modules-electroniques/4029-module-boucle-de-retournement-automatique-train-echelles-ho-n-o.html
Je ne pense pas que ce module fonctionne en DCC, notamment les entrées de détection.
Le montage maison peut sembler complexe mais je ne vois pas comment faire autrement sans détection de court-circuit.
883
Vos projets / Re : Rétrosignalisation/Bus Can
« le: août 23, 2017, 02:15:17 pm »
Oui pardon, J3, pas J2 qui est le bornier.
J3 c'est pour brancher des fils ou utiliser un connecteur au lieu du bornier.
Oui, d'une part les transceiver CAN sont conçus pour supporter les courts circuits, de la datasheet du TJA1050
D'autre part, le contrôleur va rapidement se mettre en bus-off et cesser d'émettre en cas de court jus permanent.
J3 c'est pour brancher des fils ou utiliser un connecteur au lieu du bornier.
Oui, d'une part les transceiver CAN sont conçus pour supporter les courts circuits, de la datasheet du TJA1050
Citer
A current-limiting circuit protects the transmitter output stage from damage caused by accidental short-circuit to either positive or negative supply voltage, although power dissipation increases during this fault condition.
D'autre part, le contrôleur va rapidement se mettre en bus-off et cesser d'émettre en cas de court jus permanent.
884
Vos projets / Re : Rétrosignalisation/Bus Can
« le: août 23, 2017, 11:05:06 am »
Je strap est sur J1, je n'ai pas l'impression que ça court-circuite les sorties.
Ne me dites pas que vous mettez le strap sur J2
Ne me dites pas que vous mettez le strap sur J2
885
Vos projets / Re : Rétrosignalisation/Bus Can
« le: août 23, 2017, 09:26:36 am »
Quelles cartes CAN utilises-tu ?