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.


Sujets - Jean-Luc

Pages: [1] 2
1
Bibliothèques / LightDimmer : une bibliothèque pour les feux
« le: mars 29, 2018, 09:40:14 am »
Hier j’ai programmé une bibliothèque pour faire de l’allumage et de l’extinction progressive des ampoules des feux de signalisation. On peut voir ça dans la vidéo de l’article http://www.locoduino.org/spip.php?article47. Le filament des ampoules à incandescence ayant beaucoup d’inertie, il faut 250ms pour qu’ils s’éteignent ou s’allument. Il faut bien sûr une sortie PWM.

La bibliothèque est en bêta, c’est ici :

https://github.com/Locoduino/LightDimmer/releases

Un peu de doc :

https://github.com/Locoduino/LightDimmer/blob/master/README.md

2
Bibliothèques / Hardware packages
« le: février 09, 2018, 05:21:11 pm »
Bonjour,

Je propose de rassembler ici les liens vers les « hardware packages », collections logicielles qui permettent d'ajouter le support d'une carte ou d'un micro-contrôleur à l'IDE Arduino, rendant ce matériel compatible avec le logiciel Arduino.

Au fur et à mesure des contributions, je les ajouterai en tête de fil.



MicroCore https://github.com/MCUdude/MicroCore

Ajoute le support des ATtiny13, ATtiny13A et ATtiny13V.



ATTinyCore https://github.com/SpenceKonde/ATTinyCore

Ajoute le support des ATtiny2313, 4313, ATtiny24, 44, 84, ATtiny25, 45, 85, ATtiny261, 461, 861, ATTiny87, 167 (with or without Optiboot boot loader), ATTiny48, 88, ATTiny441, 841 (With or without Optiboot boot loader), ATTiny1634 (With or without Optiboot boot loader), ATTiny828 (With or without Optiboot bootloader)

3
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.

4
Bus CAN / Composants : transceivers et contrôleurs
« le: juin 17, 2017, 12:01:31 pm »
Bonjour,

J'attire votre attention sur deux composants :

Le premier est un transceiver CAN de Microchip, le 2562. Il est similaire au et compatible avec le 2551. La différence est qu'il dispose de deux alimentations. La première est destinée à l'interface avec le microcontrôleur et la seconde pour le bus CAN. Ceci permet de connecter un microcontrôleur alimenté en 3,3V au réseau CAN qui lui est alimenté en 5V sans composants supplémentaires pour adapter les niveau logiques.



http://www.tme.eu/fr/details/mcp2562-e_p/circuits-integres-interface-can/microchip-technology/

Le second, le 25625, est un 2515 et un 2562 dans le même boîtier. Il permet donc d'économiser aussi des composants.



http://www.tme.eu/fr/details/mcp25625-e_ss/circuits-integres-interface-can/microchip-technology/

Le défaut est que le boîtier le plus accessible pour nous est le SSOP 28 broches, boîtier CMS avec un pas de 0,65mm. Ça se soude mais c'est un peu délicat :)

5
Vos projets / Tablette de commande du réseau
« le: juin 16, 2017, 12:08:14 pm »
Bonjour,

J'ouvre ce fil pour exposer le projet que nous avons de développer une tablette à base d'Arduino. Il s'agit d'un projet collectif mené avec deux camarades, Pierre et Philippe, dans lequel je ne suis pas le programmeur principal et ma part y est pour l'instant extrêmement faible. Je vais donc présenter un travail qui n'est pas le mien car ni Pierre ni Philippe ne participent au forum.

Pour commencer je vais présenter rapidement le système d'exploitation de réseau que nous avons conçu. Il s'agit d'un système de pilotage analogique. Le réseau est donc divisé en zones alimentées séparément. On distingue deux types de zones :
1 - les cantons dans lesquels un convoi peut être à l'arrêt. Le plus petit canton du réseau en longueur de rails définit la longueur maximum d'une rame. les cantons ont une zone de pleine voie et une zone d'arrêt dans chaque sens
2 - les zones d'aiguille

Chaque zone alimentée est gérée par un microcontrôleur et de l'électronique associée : l'alimentation traction.
Une alimentation traction remplit les fonctions suivantes :
* détection en zone de pleine voie et en zone d'arrêt
* mesure du courant (détection des court circuits)
* mesure de la vitesse du convoi (toutes les 10ms)
* calcul de la PWM par un asservissement proportionnel intégral
* alimentation du convoi
* éclairage permanent du convoi

Les alimentations traction sont reliées par un bus CAN à 727Kbits/s à un contrôleur central qui
- diffuse deux signaux de synchronisation pour la synchronisation des PWM (à 32kHz) et la mesure de vitesse (à100Hz)
- reçoit des alimentations traction les informations de détection de présence, de mesure de courant, etc
- envoie aux alimentations traction des ordres d'affection de convoi (gains de l'asservissement), les consignes de vitesse

Un second bus CAN dédié aux accessoires (aiguillages, signaux, ponts tournants, portes de remises, ...) permet de communiquer entre le contrôleur central et les cartes de pilotage des accessoires.

Le contrôleur central contrôle le déplacement des convois et assure la sécurité : block system habituel. Il contrôle également la signalisation. Il reçoit des souhaits de positionnement des aiguillages. Ces derniers sont effectivement positionnés lorsque par le contrôleur central lorsque les contraintes de sécurité le permettent.Le logiciel de suivi de convois, Caniche, a été développé par Pierre.

Toute cette électronique n'est pas entièrement Arduino. Pour ma part, j'ai deux cartes construites autour d'un Arduino Nano : la carte pont tournant et une carte servo pour les portes de remises. Toutefois, pour des évolutions futures, nous pensons remplacer le contrôleur central (actuellement une carte Olimex avec un ARM 7 TDMI à ~60MHz) par un Teensy 3.6 qui dispose de deux contrôleur CAN.

Comme nous ne souhaitons pas avoir un ordinateur de bureau ou portable dans la boucle, l'interface homme-machine pour piloter le réseau choisi est une tablette (entre autre).

Pour répondre à une question qui ne manquera pas d'arriver, pourquoi ne pas avoir utilisé une tablette existante fonctionnant sous iOS ou Android ? Effectivement nous réalisons une tablette qui est plus épaisse et moins performante sans être pour autant vraiment moins chère. Mais un critère essentiel à nos yeux est de ne pas être dépendant d'une infrastructure logicielle complexe et de politique de développement et déploiement évolutives, casse pieds et imprévisibles.

Le hard

Pour l'instant Pierre a développé un prototype composé de :
- Un écran tactile 7" avec interface parallèle :



- Un Teensy 3.6



- Une connectique CAN
- Un ampli audio LM386 (pour faire des blip)
- Un encodeur rotatif (qui n'est pas monté et qui je pense ne le sera pas)

le tout intégré sur une carte.

À l'étude :

- Intégration dans un boîtier
- Alimentation sur batterie LiPo
- Lien radio avec un NRF24

Le soft

Le logiciel Arduino bien sûr,
UTFT, bibliothèque de gestion des écrans LCD
Une bibliothèque de gestion du tactile, URTouch étant mal écrite et buggée
AW (Arduino Widgets), bibliothèque développée par Pierre qui affiche des widgets, gère leur superposition et l'interaction avec l'écran tactile et qui sera disponible bientôt.

Des photos vont suivre :)

6
Infos et bonnes affaires / Selectronic c'est terminé
« le: mai 07, 2017, 02:37:53 pm »
La société a déposé le bilan.

7
Infos et bonnes affaires / PCB chez SeeedStudio
« le: mai 04, 2017, 09:29:33 am »
Bonjour,

Comme j'avais besoin de tirer des cartes plus grandes que 10x10, j'ai essayé le service PCB de SeeedStudio : https://www.seeedstudio.com/fusion_pcb.html

Pour du 10x10 et inférieur, les prix étaient comparables à ceux d'ElectroDragon : 10€ les 10. Récemment, SeeedStudio est passé à moins de 5€ les 10. En revanche le port est un petit peu plus élevé et peut être un peu plus long.

Le résultat est comparable : nickel


8
Les réseaux / Projet Jean-Luc
« le: février 13, 2017, 05:47:35 pm »
Bonjour,

Après un bon bout de temps passé sans toucher à mon réseau, je me suis décidé à revoir ma copie. Je casse et je recommence.

J'étais parti sur quelque chose de trop grand (2m70 x 1m20) par rapport à la place disponible et à vrai dire pas bien fichu. Le plateau est trop haut, bloque l'accès au velux et il n'y a pas assez de place pour travailler autour. Le plateau étant trop haut, 1m, c'est un bazar pour mettre en place un éclairage avec le toit mansardé. Par ailleurs le velux sera à changer dans les 5 ans à vue de nez et une fois le réseau terminé, ça ne sera plus possible sans risquer de l'endommager.

L'ancien projet :



J'avais fait une vidéo :

Tous ces inconvénients m'avaient fait perdre ma motivation et mon épouse avait été bien trop gentille de me laisser installer ce gros machin...

Je repars donc sur quelque chose de plus modeste : un réseau en L de 2 mètres sur 1m18, les branches du L faisant 60cm de profondeur. L'accessibilité est meilleures, tout est à portée de bras. Il sera également plus bas sur pattes, 70cm pour le 0 du réseau, pas plus bas pour pouvoir s'asseoir avec les genoux dessous. C'est un réseau pour manœuvrer, pas pour regarder passer les trains, quoiqu'en automatisant la circulation, tout est permis.



Aucun rail n'était fixé définitivement, je ne perds que du bois, un peu de trackbed woodland scenic, le travail que j'avais effectué sur le TCO et du temps.

Exit la double voie, on est sur de la voie unique, ligne secondaire, gare terminus avec un petit dépôt vapeur.

Je garde les éléments qui me plaisaient le plus : la gare, le dépôt. J'enlève la double voie et le port. Au premier plan, en contrebas de la gare et du dépôt, il y a une voie de parade. Eventuellement je peux mettre un pont au niveau de la ligne droite de la voie de parade.

Je garde le principe de la gare cachée qui fait boucle de retournement :



La gare cachée est au niveau 0, la gare terminus et le dépôt sont à +90mm. La pente est de 2%. Comme l'ancien, le réseau sera sur roulettes afin de pouvoir le déplacer et notamment accéder à l'arrière qui sera ouvert pour pouvoir facilement régler un problème dans la gare cachée.

Les TJD, TJS et aiguillages qui ont la malchance d'être au dessus d'une voie de la gare cachée recevront une commande de servomoteur déportée.

Enfin comme la taille est plus modeste, j'envisage de pouvoir le poser sur la tranche afin d'accéder plus facilement au dessous : câblage,  mécanique et électronique. Essentiellement pour l'installation initiale. Il pourra être également déplacé dans la pièce voisine en cas de travaux à effectuer dans la pièce où il est installé (comme par exemple changer le velux  :))

Voilà, à un moment il faut convenir que les choix étaient mauvais et les remettre en question.

9
Shields et Modules / Module WIFI
« le: juin 17, 2016, 06:15:10 pm »
(le but est de connecter l'électronique du réseau à la box de la maison pour dialoguer via un ordi, une tablette ou un téléphone)

Il y a quelques temps, nous avions parlé des modules ESP8266 d'expressif qui permettent de faire du TCP/IP en wifi à partir d'un Arduino (entre autre). Ayant lu dans Open Silicium que ce n'était pas très stable et que le firmware était un peu écrit avec les pieds, j'avais un jugement plus que réservé :)

Entre-temps mon ami Pierre a découvert un module CC3000 commercialisé par Adafruit. Le module est construit autour du CC3000 de Texas Instruments avec lequel on dialogue via des commandes SPI. Il supporte 4 sockets. TI étant une maison sérieuse, nous étions assez enthousiastes à propos de ce module.

Après plusieurs mois de tests et d'essais, Pierre ne mâche pas ses mots « j'abandonne, c'est de la ***** ». Soft instable, ping de durée aléatoire, les données partent et arrivent au bout d'un certain temps ou pas. La documentation est incomplète, certaines commandes ne sont pas détaillées. C'est peut être suffisant pour faire un capteur intelligent qui envoie une donnée toutes les 5 secondes mais pour le reste c'est nettement insuffisant.

Nous sommes donc repartis avec un Particle Photon. L'avantage est qu'il est Open Hardware et que son firmware est OpenSource. Grosso modo c'est une carte un peu plus petite qu'un Arduino Nano et qui se programme comme un Arduino. Elle coûte entre 20 et 25€. Elle comporte un module Wifi et un ARM Cortex M3 à 120MHz avec une interface CAN. Toutes les bibliothèques qui vont bien sont livrées. L'idée est de faire une passerelle Wifi/TCP/IP-CAN toute simple. La tablette ou le smartphone envoie et reçoit des trames CAN encapsulées dans du TCP/IP, le Photon extrait les trames CAN et les envoies sur le CAN et inversement il reçoit les trames CAN et les envoie via TCP/IP.

https://docs.particle.io/datasheets/photon-datasheet/

Je vous tiens au courant :)

10
Shields et Modules / Testeur de câble RJ11
« le: mai 01, 2016, 12:26:13 pm »
Coucou,

Je vais bientôt envoyer 2 cartes à la fabrication (la semaine prochaine) :
  • La carte de commande de pont tournant
  • La carte 8 servomoteurs manuelle + platines servo pour les fins de course

La partie platines servo correspond à http://modelleisenbahn.triskell.org/spip.php?article35 mais avec le brochage des cartes servomoteurs CAN + DCC et manuelle. D'ailleurs cet article va être mis à jour car mes nouvelles cartes à base de PIC ont le même brochage que les cartes Arduino

Donc sur une carte 50x100mm, je case 6 platines. Avec 12 cartes, ça fait 72 platines. Mais je n'en ai besoin que de 42. Si je ne mets que 4 platines, j'ai 48 platines ce qui me suffit et je dégage la place pour une carte 33x50. Sur cette carte, on peut mettre 2 prises RJ11 et un connecteur vers l'Arduino pour faire un testeur de câbles. Il y aurait donc 12 testeurs disponibles. Si vous êtes intéressés, dites le ci-dessous ;)

11
Bus CAN / Moniteur CAN
« le: avril 30, 2016, 07:29:57 pm »
Bonjour,

Pour permettre de développer plus facilement le logiciel des cartes avec du CAN, j'ai commencé un Moniteur CAN.

En substance c'est un sketch que l'on met sur une carte avec du CAN (la carte 8 servos par exemple) et qui va permettre d'afficher des messages CAN reçu sur le terminal mais également de changer la vitesse du CAN et d'envoyer des messages. Les messages entrant ne sont pas affichés en direct mais transitent dans un tampon circulaire de 16 emplacements et l'on peut activer ou désactiver l'affichage.

Pour l'instant c'est ce que ça fait.

Je vais ajouter l'envoi de messages périodiques mais également des commandes dédiées aux cartes Locoduino (la carte 8 servos mais également la carte pont tournant).

J'ai poussé la version initiale qui est fonctionnelle sur le gitlab de locoduino : https://git.framasoft.org/locoduino.org/MoniteurCAN

J'ai encore des plantages qui se traduisent par un reset

La ligne série est programmée à 115200. Il suffit de taper help pour avoir les commandes


12
Bonjour,

Je voudrais présenter un Design Pattern, ou patron de conception : le Proxy, appliqué à un système en contrôle commande décentralisé en réseau.

En POO, les patrons de conception sont des architectures logicielles réutilisables dans de nombreux cas.

Un Proxy est une « classe qui se substitue à une autre classe » ce qui hors contexte ne veut pas dire grand chose. Prenons un exemple concret : un système de commande de réseau en DCC formé d'un Arduino gestionnaire central, d'un Arduino jouant le rôle de centrale DCC et d'Arduino pilotant des actionneurs d'aiguillage, d'autres Arduino gérant la détection de présence, etc.

Le gestionnaire central doit donc :
  • envoyer des ordres aux trains (la locomotive qui le tracte) en communicant avec le calculateur DCC
  • envoyer des ordres aux actionneurs d'aiguillages en envoyant des messages CAN
  • recevoir la position des trains via des messages CAN
  • recevoir la position des aiguillages via des messages CAN (en effet, la position effective ne correspond pas à l'ordre donné, du moins pas tout de suite)

Idéalement le gestionnaire central devrait pouvoir manipuler un train ou un aiguillage sans se soucier de la manière d'interagir, c'est la que le Proxy entre en scène.

Supposons que nous ayons une classe Train avec les méthodes fixeVitesse (fixe la vitesse du train) et position (retourne le canton où se situe le train). Le gestionnaire interagit avec les objets de cette classe, donnant, pour chacun d'entre eux, la vitesse à intervalles régulier et récupérant la position.

Supposons également que nous ayons une classe Aiguillage avec les méthodes positionneDroit et positionneDevie pour commander la position et une méthode position pour retourner la position de l'Aiguillage. De même le gestionnaire interagit avec les objets de cette classe.

Train::fixeVitesse effectue la communication avec l'Arduino DCC
La position retournée par Train::position est possiblement actualisée au gré de l'arrivée des messages CAN indiquant l'occupation des canton

Aiguillage::positionneDroit et Aiguillage::positionneDevie effectuent l'envoi d'un message CAN correspondant
La position retournée par Aiguillage::positionne est actualisée au gré de l'arrivée des messages CAN indiquant l'état des aiguillages.

Ces objets sont des proxy, ils agissent pour le compte d'objets distants mais donnent l'impression au gestionnaire central que ce sont de simples objets en mémoire.

À noté qu'ils permettent également, via le polymorphisme, de concevoir un gestionnaire indépendamment de la technologie DCC/Analogique sous jacente et indépendamment du type de carte utilisées sur le réseau.

13
Bonjour,

Ma petite contribution à la modélisation.

Ayant travaillé sur l'approche objet pour la gestion d'un gare cachée, les articles sont en attente de publication, j'ai fait des classes pour chaque type de voie : aiguille, voie d'extrémité de la gare et voie en gare. Les classes en question sont instanciées et les objets sont connectés pour former un graphe. Une recherche de chemin est ensuite faite pour trouver une voie libre ou pour relier l'entrée à une voie ou bien une voie à la sortie. Le défaut est que le graphe est orienté ce qui fait qu'un aiguillage va connaître les voies en aval mais pas en amont. Donc partant de l'entrée, on trouve une voie en gare, idem partant de la sortie mais on ne trouve pas un chemin de l'entrée vers la sortie par exemple.

Titillé par DDEFF, j'ai généralisé l'idée à un graphe où chaque nœud (bout de voie) connaît ses voisins. Comme exemple, j'ai choisi la gare de DDEFF que j'ai re-dessinnée en PECO code 55 (gare dont on peut déduire deux choses d'ailleurs : 1) Ça va coûté un bras à DDEFF, rien qu'en appareils de voie, il y en a pour 1300€, 2) DDEFF a de la place, la gare fait 4,2m de long. Bref je suis jaloux !  ;D)

Je vous mets le lien vers le PDF : La gare de DDEFF en PDF

J'ai donc défini une classe abstraite de base, Voie :

class Voie
{
  private:
    byte mIdentifiant;
    byte mDirection;
 
  protected:
    void fixeDirection(byte dir);
   
  public:
    Voie(byte identifiant) { mIdentifiant = identifiant; mDirection = AUCUNE_DIRECTION; }
    byte idVoie() { return mIdentifiant; }
    byte direction() { return mDirection; }
    virtual void connecteDeVoie(Voie *voie, byte connecteur) = 0;
    virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL) = 0;
};

Une voie a : 1) un identifiant, 2) une direction. On l'instancie en lui donnant un identifiant et par défaut il n'y a pas de direction fixée. La direction est fixée plus tard lorsque le graphe est construit.

connecteDeVoie permet d'établir une connexion entre deux voies, j'explique ci-dessous. creeCheminVers permet de trouver un chemin entre deux nœuds du graphe (entre deux bout de voies) en suivant une direction.

Ensuite, j'ai 5 classes :

1) les voies de garage qui n'ont qu'un seul connecteur : SORTANT



2) les voies normales qui ont 2 connecteurs : ENTRANT et SORTANT



3) les aiguillages qui ont 3 connecteurs : ENTRANT, SORTANT_DROIT et SORTANT_DEVIE



4) les traversées de jonction double (on peut ajouter également les simples) qui ont 4 connecteurs : ENTRANT, SORTANT, ENTRANT_BIS et SORTANT_BIS
5) les croisement qui ont également 4 connecteurs



Un sens normal de parcours est également défini : de entrant vers sortant.

14
Shields et Modules / Carte Pont tournant
« le: février 13, 2016, 03:41:19 pm »
J'ai donc redessiné la carte pont tournant en format 10x10. La roue codeuse est marginalement plus petite car j'ai mis les capteurs sur la disgonale.

J'en ai profité pour ajouter le CAN et le DCC

Voici les schémas :

http://www.locoduino.org/pic/CartePontTournant/CartePontTournant.pdf

Et une partie des typons :






15
Shields et Modules / Carte Servomoteurs DCC + CAN
« le: janvier 14, 2016, 06:12:22 pm »
Bonsoir,

J'ai été hors course ces derniers temps mais je ne suis pas resté complètement inactif.

Voici donc une carte destinée à piloter 8 servomoteurs et raccordable au bus DCC et au bus CAN.

La carte comporte
- une alimentation pour les servos (un 7805, certains modèles délivrent 1,5A)
- un Arduino Nano
- un contrôleur CAN et un transceiver
- une interface DCC
- 2 connecteur RJ11 pour le CAN
- un bornier pour le DCC
- un bornier pour l'alim 9 à 12V
- 8 connecteurs pour les servos
- optionnellement un expandeur d'I/O pour lire des fins de course
- J'ai casé un détecteur de coupure d'alim pour la sauvegarde en EEPROM

J'ai réussi à tout faire tenir sur une carte 10x5 cm

Voici les schémas : http://www.locoduino.org/pic/carteServoCANDCC/schematique.pdf

Les typons :

Recto





Verso





Le logiciel reste à faire. Il se basera sur SlowMotionServo

Pages: [1] 2