Messages

1

Bus CAN / Re : BreakoutBoard CAN

« le: décembre 10, 2015, 03:01:15 pm »

Merci DDEFF

pour ta réponse documentée.
Le lien ne semble pas fonctionner; il m'intéresse pourtant, car j'ai peut-être eu des pb avec un bus I2C en tension mixte, comme c'est décrit.
Ce que j'indiquais avoir compris dans mon avant dernier message était donc applicable [reset et Rx].
Tu me confirmes que pour Tx (et non Rx), il n'y a rien à changer [liaison directe].
Tout est clair. Je vais faire un projet de plan de circuit imprimé simplifié d'ici quelques temps.

2

Bus CAN / Re : BreakoutBoard CAN

« le: décembre 07, 2015, 11:34:31 pm »

Bonsoir,

Merci pour ces réponses. On doit pouvoir simplifier, au moins en partie.
Pourtant, la réponse de Jean-Luc m'amène à demander des précisions et à proposer des réflexions complémentaires.

Reset:
Le circuit des composants D1, R2, R3, C5, BP ne pourra agir qu'en cas d'appui sur le bouton.
Dans un montage définitif aura-t-on accès au bouton ?
Par ailleurs, sans appui sur le bouton, à quoi peut servir de conserver la liaison K3, 6 - IC1, 17 ?
Il faudrait raccorder K3, 6 à une pin Arduino programmée spécifiquement pour faire le reset?
Dans ce cas, les composants anti-rebond deviennent aussi superflus, avec un changement d'état réalisé avec une pin pilotée par soft. Mais suite à quel évènement faudrait-il le déclencher? C'est une disposition plutôt inhabituelle.

J'ai connu d'autres circuits sur lesquels le reset logiciel (par écriture du mot ad'hoc dans un registre) fonctionnait effectivement; le hard reset devenait superflu. Le §9.0 de la datasheet confirme cette possibilité. Et c'est ce que semble faire la bibliothèque CAN (cas Uno); en effet, au démarrage (dans setup()), mcp2515_init() appelle bien la fonction  mcp2515_reset() qui procède par écriture d'un mot de reset. Il devrait donc rester possible de (re)faire un reset logiciel ultérieurement, en cas de besoin impératif (à condition de prévoir tout ce qu'il faut dans le logiciel applicatif Arduino; il n'y a sans doute pas seulement le MCP2515 à réinitialiser...).

Il semble donc qu'on devrait pouvoir supprimer sans perte grave toute la filerie de reset.



Résistance de tirage:
"Tx [de MCP2551] ne doit pas flotter tant que MCP2515 n'a pas fini de s' initialiser."
C'est une précaution qui paraît utile. En effet, j'ai constaté ce genre de phénomène sur les pins d'un Arduino Uno en initialisation. MCP2515, en tant que microcontrôleur, peut aussi se comporter ainsi.
Dans ce cas,  faudrait-il aussi ajouter une résistance tirant Tx vers GND sur cette liaison, qui n'en possède pas actuellement? Toutefois, les tests ne semblent pas avoir fait apparaître d'anomalies à ce niveau.
Il serait utile de tester le comportement lors d'un démarrage et branchement 'à chaud' sur un bus déjà lancé (2 autres transceivers actifs).

Si néanmoins on retenait d'ajouter une résistance de pull-down,  quelle valeur? Comme R4?
Dans le cas du Uno, c'est TXCAN du 2515  qui pilote le TxD du transceiver :
5V sur 5V, pas de problème, a priori. Sur Rx, la valeur actuelle de R4 semble convenir, d'après les tests.
Dans le cas du Due, 3V pour piloter 5V, il ne faut pas en 'faire  trop'.
Un test pourrait préciser la valeur. Il serait agréable que celle-ci convienne dans les deux cas, cela éviterait un strap supplémentaire.

Ceci dit, en consultant la datasheet du MCP2551 correspondante, certaines informations inciteraient à ne pas mettre de résistance de tirage vers la masse :
- le tableau sur la 'table de vérité' du circuit montre que si TxD est à 1 ou 'flottant',  le bus n'est pas piloté (ce sont les autres transceivers actifs qui éventuellement le pilotent); pour réellement 'émettre', il faut passer par TxD à 0; TxD flottant ou à 1 ne devrait donc pas engendrer un signal intempestif néfaste;
- un schéma de l'architecture interne suggère qu'il y a une résistance interne de tirage vers VDD sur l'entrée TxD;
- enfin MCP2515 et 2551 sont conçus pour fonctionner ensemble; sur leurs schémas, on observe des dispositifs hard internes de reset à la mise sous tension: on peut raisonnablement penser qu'ils ont été harmonisés à la conception pour se synchroniser convenablement.

Ceci ne pousserait-il pas à penser que ce soit plutôt un niveau bas de TxD qui soit susceptible de provoquer une anomalie? La solution actuelle semble déjà convenable, d'après les tests.

En espérant que cet apport sera utile aux choix définitifs; mais, n'ayant pas encore de montage à tester, je peux me tromper...

Cordialement.

3

Bus CAN / Re : BreakoutBoard CAN

« le: décembre 06, 2015, 12:41:43 am »

Bonjour,

J'ai commencé à étudier le bus CAN au travers des articles de Locoduino et du forum (encore bravo); j'aurais quelques questions à poser à propos du schéma de câblage du breakout du CAN bus présenté un peu plus haut dans ce fil (cf. l' intervention de Jean-Luc du 23 janvier, dans [2]). Ces interrogations sont simplement formulées  pour m'éviter doutes et tâtonnements. Elles seront peut-être utiles à d'autres et permettront de nous assurer que notre compréhension est correcte. Malgré l'excellente clarté des explications, il peut se faire que je comprenne de travers.

En l'étudiant, il semblerait que le schéma puisse être beaucoup simplifié, en ne câblant pas ce qui n'est, en réalité, pas utilisé, et sans perdre la flexibilité pour le couplage, au choix, à des Arduino Uno ou à des Due.

Par exemple, tout ce qui concerne le Reset physique semble inutile puisqu'on se charge de le faire par logiciel avec une commande SPI, quand c'est nécessaire. Sur un montage définitif, le bouton-poussoir ne sera même pas accessible...
On peut donc omettre : bouton-poussoir, pont de résistances, diode. Et dans ces conditions, même la borne 6 (Reset) du bornier K3 est superflue. K3 peut donc se limiter à cinq contacts.

Par ailleurs, il y a toutes les pins de IC1 qui ne sont pas du tout utilisées dans la façon présentée d'utiliser les composants CAN (tous les TXiRTS ou RXiBF, pin 4 à 6 et 10-11 de IC1), ainsi que SOF (pin 3). Il s'ensuit que le bornier K5 tout entier peut-être omis. A moins que cela présente un intérêt pour tester le fonctionnement du montage à l'oscillo (certaines pins sont des signaux d'interruptions)? Sur un proto, peut-être cela présente-t-il un intérêt, mais est-ce utile sur un montage de 'série'?

L'examen de la bibliothèque CAN proposée pour le Uno ne montre même pas de possibilités d'utiliser les fonctionnalités de ces 'registres' TXiRTS ou RXiBF autrement que par logiciel au travers du bus SPI. Je n'ai pas encore vérifié dans le cas Due.
Est-ce une compréhension correcte du montage proposé? Et le breakout ainsi simplifié fonctionnera-t-il de façon satisfaisante?


Enfin, dans la même intervention de Jean-Luc, l'usage des straps est défini.
L'usage du premier cité (S2 entre GND et Rx) ne me paraît pas totalement clair.
Si c'est pour utilisation avec un Due, on utilise les pins 2 et 3 de K4 pour piloter directement le transceiver CAN MCP2551 (le 2515 ne sert pas du tout) avec les Tx, Rx qui existent spécifiquement sur le Due pour piloter un CAN.  Dans ce cas, il faut omettre le strap S2 de façon à atténuer la réception Rx en 5V sur le MCP2551 pour l'adapter au 3,3V du Due grâce à un pont diviseur ?
Si c'est pour utilisation avec un Uno (5V), cette atténuation n'est au contraire pas souhaitable, donc il  faut shunter le strap dans ce cas. De toutes façons, avec un Uno, on n'utilise pas ce canal direct pour piloter le MCP2551, puisqu'on passe par les pin Tx Rx du contrôleur MCP2515, lui-même relié au bus SPI du Uno. Les bornes 2 et 3 de K4 sont 'à vide' dans ce cas. Je me demande même si la résistance de tirage ainsi introduite entre Rx et GND (R4= 18kOhm ) est nécessaire avec le Uno; elle va jouer sur l'entrée Rx du 2551. Elle ne semble pas nuisible puisque les tests montrent un fonctionnement correct, mais est-elle utile? Dans ce cas ne pourrait-on mettre le strap en série avec R5? Et on ne shunterait le strap, ainsi disposé, que pour l'utilisation avec un Due?

Est-ce une évolution correcte?

D'avance merci et encore bravo pour cette initiation au CAN.

4

Composants / Re : Etendre les entrées-sortie numériques

« le: novembre 27, 2015, 07:48:00 pm »

Je ne crois pas qu'il faille  'jeter' trop vite le bus I2C. A l'intérieur d'un boîtier, difficile de trouver plus simple et plus efficace (je crois que c'est, notamment, le bus interne entre modules des téléphones portables). Beaucoup de modules intéressants fonctionnent avec cet interface.

Les expandeurs d'E/S (pilotés par I2C) sont très utiles: sinon comment prendre en compte  plus de 53 contacts pour le module DCC que j'ai décrit, sachant que d'autres contacts supplémentaires doivent nécessairement être utilisés sur l'Arduino (écran LCD en direct, interruptions, pilote DCC, alarme DCC, ...). Même en prenant un plus gros modèle d'Arduino, le compte n'y sera pas. Et de plus, le fonctionnement avec l'I2C est très réactif et efficace (tout est gérable sur interruption, l'anti-rebond est intégré): je cite la gestion d'encodeurs rotatifs (2 contacts à gérer en tenant compte de l'ordre d'apparition des impulsions sur l'un et l'autre). Qui dit mieux ? D'accord, il faut adapter la bibliothèque pour encodeurs, mais ça fait partie de la maîtrise à acquérir...
Les précautions de blindage que j'indique sont assez simples à mettre en œuvre, et ont leur utilité, même sans I2C.
Dans le cas des entrées par boutons, cela ne fait aucun câblage supplémentaire. Tout est dans le boîtier et ne peut être que là, par construction.

Je suis d'accord, inversement, que pour les sorties PWM, on peut faire autrement, avec un bus CAN, soit en utilisant les sorties PWM d'un arduino (mais il y n'y en a pas beaucoup...), soit en utilisant dans le boîtier distant, un  module expandeur PWM (un ou plus). J'aurais pu faire cela pour mon TCO : cela aurait drastiquement réduit le nombre de câbles, c'est très vrai !
Mais j'avais déjà fini mon TCO quand les articles réellement utilisables sur le CAN sont parus... (et ils n'étaient que sur le forum).
Les articles présentant en détail la solution CAN ont commencé à paraître seulement en novembre de cette année...

C'est le grand mérite de Locoduino de mettre à la portée de tous des techniques difficiles d'accès au non initié comme le CAN, technique dont l'intérêt d'ailleurs dépasse largement le contexte du modélisme ferroviaire (cf. les applications industrielles citées qui invitent à l'appliquer à bien d'autres domaines encore).

On ne saurait trop remercier pour cela les excellents auteurs qui animent le site Locoduino avec un talent pédagogique remarquable.

5

Shields et Modules / Re : Conception de circuits imprimés et pooling ?

« le: novembre 21, 2015, 03:49:13 pm »

En complément, encore

une photo de l'insoleuse à LED montée dans sa caisse à outils ...

6

Shields et Modules / Re : Conception de circuits imprimés et pooling ?

« le: novembre 21, 2015, 03:46:50 pm »

En complément, voici une photo montrant un circuit imprimé.

Kicad permet de réaliser très facilement un plan de masse électrique (c'est lui qui le dessine en fonction des options définies par l'utilisateur).
Cela est favorable au blindage, cela fait moins de cuivre à retirer à la gravure et la plaque reste plus rigide.

7

Modélisation, Architectures logicielles et matérielles / Re : Machine à états

« le: novembre 18, 2015, 12:30:27 pm »

Je suis heureux que cela vous semble utile.

C'est étonnant comme ce formalisme relativement simple fonctionne bien.
Le cœur de la modélisation suffit : graphe entre états qui décrit avec une précision diabolique quels événements (et eux seuls) permettent de 'transiter' d'un état à un autre, et avec quel effet.
Chaque 'case' du 'switch case' concerne un état. Le code à l'intérieur de chaque 'case' est, en général, une forêt d'if(); if (tel_événement == vrai) alors {}; seuls les événements permettant une transition sont représentés; les autres sont ignorés: l'état reste inchangé.

Personnellement, je ne saurais plus m'en passer pour aborder ce genre de problèmes.
J'ai découvert cette approche professionnellement, il y a bien longtemps (années 80...), alors que j'étais (bien jeune et)  en train de me noyer dans un problème de ce type abordé, par ignorance, sans une méthode suffisamment rigoureuse et efficace. C'était une analyse de signal assez complexe (du style: 'interprêter un électrocardiogramme', mais dans un domaine technique très industriel). Je m'en suis toujours souvenu, même si ensuite j'ai abandonné ce terrain de jeu. C'était l'époque bénie où les consultants des sociétés de service en informatique vous aidaient réellement à trouver rapidement des solutions très concrètes à vos soucis.

Dans quelques exemples traités pour le modélisme ferroviaire, sans l'usage de diagrammes états-transitions, je pense que je ne serais pas parvenu au but.
Exemple avec l'enchaînement d'opérations nécessaire pour régler les courses des aiguillages (4 points par aiguillage) de mon petit TCO. Il faut pouvoir revenir en arrière en cas d'erreur de manipulation, à tous les stades, tout en gérant minutieusement les messages à l'écran pour ne pas perdre le fil de là où l'on est (c'est très vite fait!), et en parvenant au résultat, in fine.
La combinatoire devient vite énorme. J'étais parti avec l'idée de laisser beaucoup trop de latitude à l'utilisateur, comme par exemple, lui laisser choisir le sens de parcours des points. Parfaitement superflu et surtout dangereux, car foisonnant. Les premières esquisses sur papier m'ont permis de voir qu'il fallait davantage canaliser l'opérateur, tout en ajoutant la faculté de retours-arrière, bien encadrés, et pas tous pressentis au départ. Et je pourrais multiplier les exemples dans le domaine Locoduino.

Il ne faut surtout pas alourdir la modélisation : sa légèreté fait sa force, car elle garantit la rapidité et l'exhaustivité de l'exploration du 'terrain'.

L' 'expérience de pensée' n'est pas difficile, et elle est, de toutes façons, incontournable.
Étant dans tel état, quel événement vais-je autoriser, et s'il arrive, vers quel état va-t-il me conduire?
Quel événement veux-je (dois-je) ignorer dans tel état?
Compte tenu des opérations à faire, pourrais-je raisonnablement atteindre l'état que je vise en un seule étape? Dois-je me ménager une étape intermédiaire, une voie de repli? etc...
Qu'est ce qui caractérise ce nouvel état atteint (en terme de variables d'état)?
Faute de graves déboires futurs, il est inévitable d'agiter toutes ces questions en amont du codage.
La démarche de pensée reste assez naturelle.

Pour illustrer ces propos, voilà ce que ça peut donner :
http://www.forum-train.fr/forum/viewtopic.php?f=16&t=14445

Dominique y reconnaîtra la toile de fond de certains échanges que nous avons eu naguère.

Bien cordialement et à votre disposition sur tel ou tel sujet, dans la limite de ce que j'ai compris.

8

Shields et Modules / Re : Conception de circuits imprimés et pooling ?

« le: novembre 18, 2015, 03:26:32 am »

Bonsoir,

J'ai bataillé un certain temps avant de trouver la  (une) bonne solution.
J'ai glissé dans le texte les informations, mais c'est assurément trop elliptique, et insuffisant ...

Il ne faut surtout pas, idée naturelle, mettre une résistance (supposée nulle) sur du simple face ;
pour Kicad, les deux circuits ainsi joints ne peuvent plus être équipotentiels,
ce qui va causer beaucoup, beaucoup de complications, en particulier si cela concerne la masse ou le +xV.

En fait, il suffit de dire que l'on travaille en double face et d'utiliser la face supplémentaire pour mettre les liaisons correspondant aux straps dont on a besoin.
Attention : Il est nécessaire de prévoir systématiquement, sur le schéma de principe, placés n'importe où sur l'équipotentielle concernée (mais bien raccordés à celle-ci par chacun son point de jonction), une paire de connecteurs à un seul pôle, qui seraient parfaitement inutiles en l'absence de strap; ensuite, il faut  placer ces connecteurs aux bons endroits sur le le circuit (c'est-à-dire aux extrémités souhaitées du strap à venir), puis :
- d'une part, connecter chacun des connecteurs à une des deux portions de circuits à interconnecter, par une piste (normale et réelle), côté du 'vrai' cuivre,
- d'autre part, joindre ces deux points par une (fausse) piste de cuivre, côté strap (face supplémentaire).
Cela permet d'  'alimenter' le strap, côté (vrai) cuivre. Les deux connecteurs se retrouvent à l'emplacement exact des 'via'. Côté cuivre, cela va faire deux pastilles, avec un trou au centre (pour centrer le perçage), sur lesquelles souder les deux extrémités du strap.

En pratique, on commence par le schéma 'minimum'. A chaque fois qu'on détecte le besoin d'un strap en faisant l'implantation des composants, retour sur le schéma de principe pour ajouter la paire de connecteurs, là où il faut, puis retour à l'implantation et tracé des morceaux de piste manquants, et ainsi de suite. On prend vite l'habitude.

On n'utilise, pour le gravage, que le typon correspondant à la (vraie) face cuivrée.
Sur un tirage où l'on demande l'impression des deux faces (ou à l'écran), on verra les pistes cuivre véritables (par défaut, en vert) et les pistes des straps (par défaut, en rouge, donc bien visibles). Cela fait un bon pense-bête pour ne pas en oublier au soudage.

Et voilà... C'est beaucoup plus simple et rapide à faire qu'à expliquer.

9

Composants / Re : Etendre les entrées-sortie numériques

« le: novembre 18, 2015, 02:38:29 am »

Voici un lien pour des compléments plus illustrés sur ces montages.

http://www.forum-train.fr/forum/viewtopic.php?p=265089#p265089

Il m'est aussi revenue une observation faite sur la carte d'expansion Sx1509.
Cette carte, par défaut, fonctionne en 3.3V, avec possibilité, par straps, de la faire fonctionner en 5V.
Sur le montage 1, je l'ai alimentée avec la sortie 3.3V de l'Arduino. RAS.
Sur le montage 2, je l'ai alimentée par un régulateur 3.3V séparé. En passant de 2 à 4 cartes, on n'est jamais assez prudent. Hé bien, le bus I2C ne fonctionnait plus! J'ai compris que cela venait de cette tension, insuffisante : en réalité, cette sortie Arduino délivre plutôt du 3.7V. Pourquoi? C'est comme ça, mais non documenté. Une fois le régulateur ajusté à cette valeur, miracle, tout remarche bien. Sur les circuits imprimés des alimentations, je ménage toujours les pistes nécessaires à l'ajout d'un pont de résistances en cas de besoin d'ajuster la tension de sortie. Heureuse précaution! Le bus I2C, partagé entre les différents modules sous 5V et 3.3V, était pourtant bien alimenté en 5V par l'Arduino. Cette configuration n'aurait pas dû perturber. Hé bien, si.

Conclusion:
- Ces observations sont transposables à d'autres modules de ce type.
- Cette tension de 3.3V diminue peut être la consommation des circuits, mais dans nos montages, ce n'est en général pas critique, et cette mixité peut être source de complications. La preuve. J'aurais dû choisir l'option 5V.
- Il est possible que cela ait joué dans le mauvais comportement des divers écrans LCD-I2C que j'ai testés infructueusement. L'enfer est dans les détails. Il faudrait refaire des tests.

Cordialement

10

Composants / Re : Etendre les entrées-sortie numériques

« le: novembre 15, 2015, 02:40:44 pm »

Bonjour,

Voici mon expérience en matière d'expansion des E/S sur Arduino (Uno).

Premier montage: Commande de 48 aiguillages par servos à mouvements lents
   (par servo, 4 points de courses réglés individuellement et mémorisés en EEPROM, de façon à passer, dans chaque sens,  par une position de course extrême, avec un bon forçage mécanique, puis placement dans une position de repos avec effort et conso réduits)
    C'est une sorte de TCO, sans retour optique toutefois, les positions d'interrupteurs en tenant lieu. Ce retour aurait été possible, mais boff.
J'ai eu, au départ,  de grosses difficultés avec ce montage comportant sur un bus I2C :
- 2 cartes d'expansion 16 voies d'E/S Sx1509 de Sparkfun (pour une bonne vingtaine d'interrupteurs),
- 3 cartes PWM Adafruit 16-Channel 12-bit PWM/Servo Driver - I2C interface - PCA9685 (pour alimenter 48 servos d'aiguillages)
- et un afficheur 2 lignes à LCD sur I2C.

- étape 1 : bus I2C comportant quelques mètres à l'extérieur du boîtier (cartes PWM à proximité des servos) ; perturbations immédiates et irréversibles du bus dès débit sur les alimentations analogiques (mais néanmoins hachées) des locos, sous seulement 6V  -> solution à écarter impérativement
- étape 2: j'ai compris que les plus grosses perturbations étaient liées à l'écran LCD piloté par I2C; j'ai essayé plusieurs modèles, tous fautifs -> écran LCD piloté par I2C à écarter : il faut piloter l'écran en direct par des E/S tout ou rien; dommage, je n'ai pas compris pourquoi, mais c'est comme ça.
- étape 3: pour être sûr du résultat, comme je voulais passer l'alimentation des locos d'analogique continu à DCC, j'ai voulu mettre toutes les chances de réussite de mon côté et j'ai donc retenu toutes les précautions de blindage possibles :
   . circuit I2C uniquement à l'intérieur des boîtiers (3 boîtiers Teko ou équivalents empilés), liaisons entre cartes par câble blindé et mise à la masse du blindage à une seule extrêmité du câble; longueur totale d'environ 60cm;
   . boîtiers plastiques, mais blindés de l'intérieur avec un film d'aluminium auto collant (j'avais un rouleau de film prévu pour faire les joints entre rouleaux d'isolants thermiques domotiques - à placer sous les toits) : la continuité électrique entre bandes collées avec recouvrement (il en faut plusieurs pour couvrir toutes les surfaces) est très bonne  et le blindage est solide et bien continu;
   . isolement opto-galvanique + porte logique de remise en forme pour les sorties PWM (pilotage des servos); 12 câbles de liaisons vers les servos soigneusement blindés, avec mise à la masse du blindage côté boîtiers (cela représente une longueur cumulée considérable d'une trentaine de m);
   . alimentations séparées pour, d'une part la partie Arduino et circuits logiques intérieurs aux boîtiers, d'autre part les circuits extérieurs aux boîtiers (puissance et pilotage des servos); un régulateur de tensions déporté au plus près des servos, pour chaque groupe de 4 servos.
   Résultat : plus de problème de perturbations du bus I2C , ni même de vibrations résiduelles des servos au repos, même après être passé en DCC pour l'alimentation et le pilotage des locos du circuit (8 actuellement)
Conclusion pour ce montage :
  Outre le circuit I2C trop long, la perturbation venait surtout de l'afficheur LCD piloté en I2C.
  Dans un deuxième temps, j'ai pris les précautions maximales en terme de blindage. Non seulement le bus I2C n'est plus perturbé, mais il me semble que le fonctionnement des servos est plus net (plus de vibrations résiduelles au repos, avec les consignes de butées bien réglées).
  Le montage permet de piloter 48 aiguillages dans un environnement de locos pilotées en DCC. On pourrait augmenter ce nombre car le nombre de cartes PWM pouvant être couplées est bien supérieur (...et il reste de la place dans les boîtiers).
Remarque : L'environnement d'un circuit ferroviaire est plutôt bruité électromagnétiquement, et les précautions de blindage ne sont certainement pas un luxe.  Elles ne sont pas si difficiles que cela à mettre en oeuvre, avec les quelques 'astuces' indiquées. J'ai rétrospectivement un doute sur la nécessité impérative du découplage opto-galvanique des signaux PWM de pilotage des servos, mais c'est fait et ça ne peut nuire.

Deuxième montage: Commande individuelle de 8 locomotives en DCC, par encodeurs rotatifs et boutons-poussoirs
 Un montage comportant 4 cartes d'expansion 16 voies d'E/S Sx1509 de Sparkfun (pour gérer des boutons de contacts tout ou rien et des encodeurs rotatifs [2 contacts TOR]); il y a 8 fois un encodeur + 4 contacts, soit 48 contacts ce qui permet de piloter en direct huit locomotives; il y a quelques autres contacts supplémentaires pour la programmation du couplage de locos entre elles et diverses fonctions.
Tenant compte de l'expérience précédente l'écran LCD 4 lignes est piloté directement en tout ou rien. Le montage comporte aussi le circuit LM18200 (cité sur Locoduino) pour mettre en forme les signaux DCC. A la différence du précédent montage, pour ne pas risquer de détériorer les fronts du signal DCC, je n'ai pas placé d'isolement opto-galvanique sur le signal de pilotage DCC (isolement entre bas niveau et puissance'). Bas niveau et puissance sont toutefois placés dans deux boîtiers distincts, alimentations comprises.
Les mêmes précautions de blindage que ci-dessus ont été prises pour les deux boîtiers superposés abritant le montage.
Résultat : Le montage fonctionne parfaitement, sans perturbations, et permet de piloter simultanément en DCC  8 locomotives, chacune ayant sa vitesse contrôlée par son propre encodeur rotatif. Affichage sur LCD des vitesses (cible et actuelle) des locos, témoin d'allumage des feux, etc...

Complément sur la carte d'expansion 16 voies d'E/S Sx1509 de Sparkfun:
La version que j'ai utilisée a été stoppée récemment et remplacée par un nouveau modèle (non testé) encore plus petit ce qui peut être intéressant.
On peut programmer chaque carte en entrée, en sortie, avec pull-up ou non, et avec ou sans traitement anti-rebond (plusieurs options).
Pour les entrées, on peut aussi programmer individuellement, pour chaque entrée, une interruption, sur montée, sur descente ou sur changement au choix. L'interruption est valable pour toute les entrées d'une carte, et doit être raccordée à une entrée Arduino sur laquelle on a défini une interruption.
Ensuite, il faut par I2C récupérer un mot d'état de la carte qui indique l'entrée ayant déclenché l'interruption puis lire l'état, si nécessaire (déjà traité anti-rebond, si on a choisi cette option). Ce processus est très réactif et très rapide. Pas besoin de polling permanent des E/S.
De la sorte, j'ai même pu traiter au travers de telles cartes les encodeurs rotatifs. Bien sûr, il faut modifier la bibliothèque de base fournie avec les encodeurs (notamment parce que le programme d'interruption ne peut, par construction, contenir de lecture I2C faisant elle-même appel à des interruptions), mais ça se fait assez facilement, et ça marche très bien.
Sur l'ancien modèle, compte tenu des possibilités de paramétrage des adresses, on pouvait utiliser 4 cartes sur le même bus, soit 4x16 E/S.
Pour le modèle de carte PWM, le nombre de cartes pouvant être mises en parallèle est encore bien plus grand.

Remarque d'ordre général concernant ces montages comportant beaucoup d'entrées-sorties:
J'ai été frappé par le temps d'assemblage de tels circuits. Pour garder la possibilité de démonter les différents circuits imprimés en cas de besoin, j'ai mis des connecteurs là où c'était indispensable. Cela fini par faire beaucoup de perçages, de soudures, de soudage de câbles sur connecteurs; bien de ces opérations sont assez délicates et fastidieuses, mais inévitables.

Photos et autres renseignements disponibles en cas de besoin.

11

Modélisation, Architectures logicielles et matérielles / Re : Machine à états

« le: novembre 15, 2015, 01:45:15 am »

Bonsoir,

La modélisation d'un système par machine d'états-transitions est, à ma connaissance, un des moyens les plus efficaces pour analyser un problème et écrire du bon code (dans le sens conforme, efficace, facile à mettre au point et à maintenir). Cela s'applique à la gestion de systèmes physiques en toute sécurité ou à des protocoles de communication, avec la même facilité. C'est une approche malheureusement insuffisamment connue.

Pour chaque état, un (ou des) évènements permettent une transition vers un autre état (ou d'autres états), en réalisant éventuellement une action déterminée. Il peut parfois y avoir retour vers le même état (à une variable d'état près, éventuellement). A chaque état peuvent être associées un jeu de valeurs des variables d'état (ce qui peu matérialiser en quoi consiste une 'transition', mais pas toujours).
Cette approche permet effectivement de réfléchir à bien poser le problème, à trouver les bons états, les bonnes variables d'état, à tester sur papier la conformité du fonctionnement aux attentes, tout cela avec rapidité (ce n'est finalement que du dessin servant de support à une 'expérience de pensée') mais avec une grande sûreté (l'automate dessiné fait ce que l'on veut, ou non, le constat est immédiat, et en cas de non, c'est que la modélisation est à revoir). Cette approche événementielle est en général vécue comme assez naturelle. Tout cela sans avoir écrit une seule ligne de code !

Le passage du schéma au code est grandement simplifié, et une grande partie en devient assez 'mécanique', donc sûre :
- un bel enum() pour les états possibles de la variable 'état' (on peut mettre des noms parlants; si on en ajoute un, intermédiaire, rien n'est cassé avec l'enum) ;
- un grand switch sur la variable 'état' pour le choix de l'état courant à traiter, avec autant d' instructions 'case' que d'états recensés;
- et sous chaque 'case' du switch, la succession des événements possibles dans cet état (et seulement ceux-là) [souvent des  if() ],  suivi du code des actions à appliquer pour réaliser la transition correspondant à cette événement (changement de certaines valeurs d'état ou autre action) avec, in fine, le passage dans le nouvel état pour cet événement (nouvelle valeur assignée à 'état').
Ce code peut bien souvent être enrichi progressivement: on fait tourner la machine à vide au début (pour vérifier tous les enchaînements avec des traces simples), puis on ajoute les actions (dont certaines peuvent être 'dangereuses' surtout en cas de bug et pour lesquelles il vaut mieux être certain du fonctionnement correct de l'automate avant de les activer). Si l'étude est bien faite, cela doit marcher du premier coup, ou presque (pour la part automate, au moins).
Chacun pourra selon ses goûts y ajouter une dose appropriée de programmation-objet. Une transition, finalement, cela peut-être une action, donc une méthode appliquée à un objet.
De la sorte, on peut résoudre des problèmes très complexes en les divisant en des transitions simples et précisément définies. Cette approche structurée facilite la lisibilité, la maintenance et les évolutions.

Dans un projet de type Locoduino, il peut facilement y avoir besoin de plusieurs diagrammes états-transitions : un pour une phase de réglage de paramètres, par exemple, un pour le fonctionnement d'exploitation proprement dit, pour gérer un affichage, etc...

Un lien en français qui décrit une façon d'aborder cette modélisation : http://frederique.lafoux.free.fr/cours/pdf/ISI_UML_DiagrammeEtatsTransitions.pdf.
et il y en a sûrement bien d'autres.

Quoiqu'il en soit, en ce qui concerne la mise en oeuvre de la partie 'étude de l'automate', je suis d'accord avec Dominique, un outil n'est pas essentiel.
Au-delà du simple papier crayon gomme, un outil graphique pour faire des rectangles, des flèches et mettre des commentaires convient parfaitement. A défaut un Excel ou un LibreOffice répond aussi au besoin. Cela facilite l'établissement et les itérations de mise au point en restant plus 'propre' qu'un dessin manuel. Après, on peut aussi acheter l'outil de génie logiciel qui passe directement du schéma au squelette du code, mais c'est peut-être un peu luxueux.
J'ai même connu des concepteurs qui se contentaient de plusieurs colonnes : état de départ, événement, état d'arrivée, commentaires ou description de l'action. Il 'suffit' de détailler toutes les instances nécessaires, ligne par ligne. A chacun sa façon et ses préférences ...

Un autre lien qui donne des informations sur divers logiciels de génie logiciel, dont StarUml qui pourrait, sous Windows, répondre à la question : https://www.projet-plume.org/fr/fiche/staruml (non testé; et il y a beaucoup d'autres logiciels sur ce site, certains bien connus).

En espérant que cela pourra vous être utile.

12

Shields et Modules / Re : Conception de circuits imprimés et pooling ?

« le: novembre 13, 2015, 10:35:51 pm »

Bonsoir Marc-Henri,

C'est dommage de ne pas faire ses circuits imprimés-maison; c'est une perte d'autonomie, c'est moins réactif et, se limiter à du 10x10 cm, cela peut être contraignant. Pour des montages de modélisme ferroviaire un peu conséquents, on peut avoir assez souvent beaucoup d'entrées-sorties hard (pour l'interface utilisateur, notamment), ce qui implique des expandeurs, des connecteurs, donc de la surface sur le CI et le 10x16 cm (ou plus) est vite atteint.

Il y a des moyens de faire des CI plus simplement que ne le laissent entendre certains sites marchands qui en sont encore au perchlorure de fer, avec des installations chauffantes d'immersion du CI pour le gravage!
Ce lien donne des solutions pour la confection de bons CI.
http://wiki.jelectronique.com/doku.php?id=realisation_de_circuits_imprimes
Il indique notamment pour le gravage l'utilisation d'un mélange judicieux d'eau, acide chlorhydrique, et eau oxygénée qui se met en oeuvre dans un simple bac en plastique. Ces produits économiques se trouvent dans toutes les grandes surfaces de bricolage et le procédé marche très bien. Respecter les précautions d'usage que rappelle bien le lien. On voit aisément la progression de l'attaque et il n'y a pas de résidus gênants à éliminer. Idem pour le révélateur qui n'est ni plus ni moins que de la soude. Le résultat final est d'une finesse excellente.
Ce lien donne beaucoup d'autres informations pratiques utiles.

Pour l'insolation, j'avais tenté d'acheter un kit du marché à tubes UV. Après deux livraisons, soit avec casse, soit avec tube UV défaillant (si, si), j'ai tout renvoyé et décidé de faire par moi-même une insoleuse à LED-UV en m'aidant d'idées trouvées sur le net. Je l'ai logé dans un coffret plastique pour outillage. Ca marche pas mal du tout avec des temps d'exposition peut-être un peu plus longs qu'avec des tubes fluos, mais on ne fait pas de la série, en général ! La solution est réputée plus pérenne que des tubes.
J'utilise comme typon des transparents de bureautique, en double épaisseur, avec imprimante à jet d'encre et, moyennant un peu de soin lors de l'assemblage des deux couches, la précision est suffisante et vraiment très correcte.

Kicad permet de faire beaucoup de choses et est très fiable quand on fait beaucoup d'aller-retour de mise au point entre schéma et implantation, nettement plus que Fritzing, à mon goût (peut-être n'ai je pas su m'y prendre?). Je l'utilise en option double-face, mais pour faire des cuivres mono-face; la deuxième face ne me sert qu'à déterminer les emplacements des straps! En pratiquant ainsi, je n'ai jamais senti de limitations dans la complexité des schémas réalisables (avec des composants à pattes à souder au pas de 2.54mm ou plus, s'entend, mais on fait déjà beaucoup de choses sur cette base...). Bon, il y a quelques straps: et alors? J'ai mis un peu de temps à m’accoutumer à l'ergonomie de Kicad, mais une fois le cap franchi, c'est un produit très productif et très fiable.

Le problème des dimensions des pastilles et pistes est assez aisé à résoudre. Il faut faire le plus gros possible (si c'est moins esthétique, ça ne peut pas nuire) en tenant compte de l'espacement nécessaire à l'isolation électrique des pastilles, qui sur la plupart des composants ou connecteurs utilisés, sont au pas 2.54mm. Kicad permet de gérer cela parfaitement en fixant la limite autorisée de proximité des pistes, et en permettant de définir des pastilles rectangulaires ou oblongues, pour les pattes des composants, etc... Le dessin du plan de la masse (électrique) est également important. Kicad s'en débrouille très bien.

En fait, pour moi, le point le plus difficile (et le plus fastidieux) est le perçage. J'ai essayé plusieurs solutions : les mèches (carbure) qui doivent être utilisées à grande vitesse de rotation peuvent donner de bons résultats, mais sont dangereuses à manipuler (à cause de leur vitesse de rotation élevée) et cassent (trop) souvent au regard de leur prix; les bonnes vieilles mèches HSS donnent finalement d'aussi bons résultats à condition d'utiliser une perceuse de bonne qualité, avec un mandrin qui supporte des mèches de 0.8mm (on peut tricher un peu en enrobant la mèche dans la gaine plastique d'un fil électrique rigide de dimension adhoc, par exemple), sur un pied à colonne sans jeu (ce qui est plus difficile à trouver, de nos jours).
Peut-être verra-t-on un jour, pour les amateurs, un banc de perçage de CI conçu sur le principe d'une imprimante 3D?

Bon; voilà quelques idées simples pour être autonome en matière de fabrication de CI de qualité suffisante pour réaliser la plupart  des projets (voire tous) développés sur Locoduino.
Au besoin, si nécessaire, je peux préciser tel ou tel point particulier.

Meilleures salutations