Auteur Sujet: Carte « Cerveau du réseau »  (Lu 52232 fois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #15 le: juillet 25, 2015, 09:57:07 am »
Citer
Concernant la connectique DCC, dites moi ce qu'il faut exactement :)

Je réagit à retardement : il est super ce fil !

Pour le DCC, si on utilise un booster simple externe comme le module LMD18200 que j'ai décrit dans la centrale va et vient, il suffit de 2 fils PWM et DIR, + les entrées mesure de courant et alarme température, ainsi que le 5V et le Gnd, soit 6 fils.

Dans mon architecture le cerveau qui est un DUE avec CAN peut très bien se retrouver partie de ce projet, combiné par exemple avec le générateur DCC.

J'ai fait quelques tests de performance du CAN entre un UNO et un MEGA2560 : on peut allègrement dépasser les 50 messages par seconde et à 100/s il y a quelques pertes mais avec un accusé de réception ou d'exécution, ça peut s'arranger.
Coté DUE les performances doivent être meilleures.

Pour moi, le "cerveau" doit avoir aussi quelques interactions avec les animations dans le décor (gestion du temps accéléré, de l'éclairage ambiant, …) en relation avec un autre Arduino pour les exécutions. Le bus CAN est là : pas besoin d'interfaces supplémentaires.

Effectivement une EEPROM est nécessaire !

Cordialement,
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #16 le: août 25, 2015, 01:13:47 pm »
Finalement j'étais loin du compte :

Dans ce fil sur le forum Arduino,
http://forum.arduino.cc/index.php?topic=131096.495

Un Due est capable de lire 1600 messages par seconde, connecté à une Zoé !

The Due proved a really good choice as this car is producing chatter in excess of 1600 frames per second on the main CANbus only and there is no way a smaller micro-controller can handle that, let alone push it out over real UART serial 115200.
Cordialement,
Dominique

DDEFF

  • Hero Member
  • *****
  • Messages: 738
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #17 le: août 31, 2015, 12:02:29 pm »
Ayant pas mal avancé sur la gestion des trains, je vais vous exposer ma vision des choses :

I°) On doit dès le début choisir entre 3 options :

1°) Réseau complètement géré par Arduino, en analogique pur
2°) Réseau complètement géré par Arduino en DCC, y compris la centrale DCC en Arduino
3°) Réseau géré par Arduino et centrale DCC du commerce, pour ceux qui ont acheté un starter kit et qui hésitent à agrandir leurs gestion en voyant le prix des boîtiers DCC du commerce. C'est le cas le plus complexe.
La centrale du commerce ne s'adresse qu'aux trains, le reste (aiguilles, signaux, etc) étant géré par l'Arduino.

II°) On ne peut pas gérer ET en analogique ET en DCC.

C'est certainement techniquement possible, mais très dangereux : imaginez une loco qui, par erreur, serait à cheval sur un canton analogique et un canton DCC : le moteur n'y survivrait pas. On ne peut pas se le permettre.

Donc, on choisit au départ une technique et on s'y tient.

III°) Utilisation du bus CAN pour les échanges sous le réseau.

C'est le meilleur, le plus fiable et il sait tout faire.

IV°) L'Arduino DUE, avec 2 bus CAN natifs, est le candidat idéal pour gérer deux bus : un "rapide" pour la gestion des trains et un "lent" pour les accessoires.
De plus, il a 64+32 k de SRAM et donc plus aucun problème de mémoire.
Et processeur 32 bits...

V°) Je conserve la répartition des tâches (mail de Jean-Luc du 15/04) entre différentes cartes :

A) cartes de commande / détection de canton
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO

VI°) Cartes canton "A" :

En analogique, elle existe déjà (voir sur le forum "alimentation traction de canton")

En DCC, comme on en demande moins à la carte, on pourra en avoir une pour plusieurs cantons.
En DCC, la carte détecte la présence des trains sur les 3 zones (zone d'arrêt gauche, pleine voie et zone d'arrêt droite).
On peut avantageusement profiter qu'on gère 3 zones pour en déduire finement et localement le sens de déplacement du train, sans pour cela avoir à décoder la trame DCC.
A noter une chose importante : la gestion des boucles de retournement.
C'est par des échanges entre A et D qu'on peut inverser l'alimentation en sortie de boucle.
Je suis contre le système qui consiste à détecter un court circuit (type LK200 de Lenz)

VII°) Cartes de commande d'aiguille "B" :

Dans ma logique (type PRS), je détecte la présence d'un train sur chaque aiguille indépendamment.
Ce qui m'oblige à une carte qui contient un détecteur de présence et de sens de circulation.

Sur un grill complexe (le mien a 180 itinéraires), il y a des aiguilles qui peuvent être alimentées de multiples façons et dans les 2 sens.
J'ai besoin d'un  relai de sens (2RT) et d'un relais d'alimentation (1RT) suivant la position.
En prenant 2 x 2RT, je gère la pointe de cœur.

Mais un seul Nano peut gérer plusieurs cartes. Il aura à gérer la communication bus CAN.
De D vers B, le sens de circulation et la position demandée.
De B vers D, la présence et la position du fin de course.

VIII°) Carte de commande des signaux "C" :

Non nécessaires au fonctionnement, mais ça fait tellement joli ...

IX°) Carte de pilotage du réseau "D" :

C'est évidemment la plus complexe.

Il faut trouver un moyen compact d'emmagasiner les informations :

Un objet "canton" définit pour chaque canton l'élément précédent et l’élément suivant.
Je dis bien "élément" car il peut s'agir soit d'un autre canton, soit d'une aiguille.

Un objet "aiguille" définit pour chaque aiguille l'élément précédent et l’élément suivant.

Périodiquement, le réseau envoie via le bus CAN lent des infos sur les occupations des cantons et aiguilles, des positions des aiguilles.
Pour ne pas saturer le bus CAN, les infos ne sont envoyées par les cartes A et B que quand elles ont évolué.
Il ne servirait à rien d'envoyer toutes les 10 ms "l'aiguille est tout droit" quand aucun train n'est dans les parages.
C'est au niveau des cartes A et B que l'opportunité d'envoi d'infos est jugée.

Ces infos mettent à jour les objets "canton " et "aiguille".

Périodiquement, mais, là, c'est la carte D qui décide, les infos calculées des objets "canton" et "aiguille" sont calculées.

Sur un réseau de 60 cantons et 60 aiguilles, ces calculs prennent ... 6 ms seulement.  :D

Et dans ces 6 ms, je calcule les itinéraires (180, je le rappelle), ce qui me permet, cette fois, de calculer quel est le canton suivant un canton donné, en tenant compte de la position réelle des aiguilles (pas l'élément suivant, mais bien le canton).

En ayant les cantons suivant et les occupations, je peux calculer tous les feux.
Et en ayant les positions d'aiguilles, je peux même gérer les R et RR, 30, 60 et 160.

Mais pourquoi donc calculer tous les feux, si c'est seulement pour faire joli ?  ???
Mais parce que le feu donne au train sa vitesse maxi.
Et ça, la carte D en a vraiment besoin, de cette information.

Je mets à jour un autre objet, "train", cette fois qui gère tous les trains et leur assigne une vitesse dans le bus CAN rapide.

X°) Cartes TCO "E" :

En lisant les objets "train" et les objets "canton", la carte D peut envoyer à la carte E les LED à allumer
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #18 le: janvier 16, 2016, 03:33:36 pm »
Bonjour à tous,

Les choses murissent dans ma tête mieux quand je réalise.

Mon prototype de cerveau sera avantageusement remplacé par ta carte cerveau à base de Due.

Au départ je n'envisageais que la fonction cerveau (gestion des évenements venant des autres modules et commandes vers les autres modules) , tout le reste étant décentralisé vers ces modules (TCO, traction DCC, aiguilles, capteurs, signaux, décor).

Avec le début de réalisation je découvre que j'ai besoin de plusieurs éléments :
- un circuit horloge + EEPROM DS3231 + 24C32 : je pense que 32K suffisent pour stocker les états initiaux et la configuration des trains, mais je n'en suis pas sûr. Pour le moment j'utilise un breakout trouvé sur eBay, mais si c'est intégré sur la carte, il vaut mieux mettre une24x256, tant qu'à faire. Par contre la circuit date+heure+température est indispensable pour gérer les horaires de circulation des trains, les cycles jour-nuit  et les animations du décor. Cela occupe le bus I2C.

- un clavier 16 touches pour entrer des valeurs numériques autrement que par la console PC/Mac connecté (qui ne sera pas toujours connecté d'ailleurs. Le mien occupe 8 pins.
Je ne recommande pas du tout les claviers à membrane comme celui que j'ai mis, car pas très ergonomique. Un clavier tactile serait parfait. L'écran TFT cité plus bas propose un écran tactile que je n'ai pas utilisé pour le moment car cela alourdi le soft mais c'est à voir.

- un écran TFT avec interface SPI et son alimentation séparée de celle du Due. Ce n'est pas pour faire le TCO mais pour la mise au point et surtout la configuration. J'en ai branché 2 de 2,4 pouces pour voir, sur le Due et je suis étonné de la rapidité : avec 80 K de programme, la loop ne prend pas plus de 20 microsecondes pour en faire le tour. Cela occupe le bus SPI et 2/3 pins supplémentaires.
Cerise sur le gateau, certains écrans comportent aussi un lecteur SD, sur bus SPI (une pin supplémentaire pour le chip select).

- quelques boutons poussoirs supplémentaires pour naviguer confortablement dans les menus (+, -, OK, Home)

- en ce qui concerne la génération du DCC, je continue à penser que c'est mieux de la décentraliser vers une carte de traction (3 dans mon cas, une pour le gros du réseau, une autre pour le va et vient et une autre pour la voie de programmation. Cependant je commence à pencher pour intégrer la voie de programmation dans le cerveau, justement pour configurer les trains.

- ne pas oublier la détection de court-circuit que je réalise par un circuit Max471 en série avec l'alimentation continue du LMD18200 (car la sortie de mesure de courant du composant est trop folklorique à utiliser, sachant qu'on est en présence de courants fortement alternatifs, sans référence de tension). J'avais regardé la mesure de courant dans la carte traction de Jean-Luc pour alimentation PWM : c'est plus simple finalement avec un Max471. Cette détection peut-être placée dans la carte traction déportée comme indiqué plus haut. Mais si la carte cerveau comporte une génération de DCC, c'est nécessaire. Il faut seulement une seule patte analogique.

- j'ajouterai enfin quelques commandes de relais pour isoler ou raccorder les 3 tronçons de voie précités

- sans oublier la détection de coupure d'alimentation pour sauvegarder l'état du réseau.

J'oublie certainement d'autres choses, mais c'est à discuter encore entre nous.



Je joins 2 images de mon proto
« Modifié: janvier 16, 2016, 03:42:49 pm par Dominique »
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #19 le: janvier 21, 2016, 10:02:17 am »
Bonjour Dominique,

Concernant la taille de l'eeprom, abondance de bien ne nuit pas. On peut imaginer y stocker la position, l'identification et la longueur des trains à l'extinction. La position des aiguilles, etc. Enfin l'état, c'est à dire l'ensemble des variable du «cerveau». On peut aussi y stocker de manière permanente le graphe du réseau. Donc autant mettre une 128k x 8 bits.

Ok pour un connecteur écran / clavier. Il faut en définir un. Note que j'avais également fait des essais d'écran SPI avec le due et j'avais monté la fréquence du SPI au max sans que l'écran décroche. Il faut que je retrouve le code. Ok pour les poussoirs. Mais dans ce cas, ne vaut il pas mieux déporter sur une carte d'IHM les éléments d'interface utilisateur ? Cette carte d'IHM n'étant pas toujour connectée. Si tu mets un écran SPI, un clavier et des boutons, l'écran LCD est il encore nécessaire ? Si oui, un 20x4 est-il nécessaire ?

Pour la mesure de courant, il faudrait un schéma.

Concernant la connectivité sans fil, nous avons avec mes camarades, expérimenté le CC3000, il s'agit d'un module wifi SPI. Il fonctioone bien. Le cerveau serait un noeud sur le réseau wifi de la maison. Comme nous somme tous sous iOS, nous nous orientons vers une appli tablette pour configurer et piloter les locomotives.

Ok pour le RTC.
« Modifié: janvier 21, 2016, 10:16:51 am par Jean-Luc »
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #20 le: janvier 21, 2016, 10:18:08 am »
J'avais aussi pensé à un lecteur de carte micro (ou pas) SD.
Là, ça donne de grandes capacités de stockage.

Comme on trouve ce type de lecteur sous forme de BoB à prix dérisoire, je ne pense pas qu'il soit nécessaire d'intégrer le lecteur directement dans la carte, mais il suffit de prévoir un connecteur amenant le port SPI et un chip sélect avec quelque straps à souder.

Par contre l'inconvénient est que ça occupe pas mal de mémoire.

Dominique
Cordialement,
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #21 le: janvier 21, 2016, 10:32:55 am »
Je suis OK aussi pour un connecteur écran/clavier du type SPI aussi, de façon à déporter l'IHM. Les écrans que j'ai testé et qui sont visibles sur la photo sont utilisés avec une bibliothèque standard et les performances ne semblent pas nécessiter d'accélérer le Due, d'autant que j'ai mis 2 écrans pour 10 € environ seulement.

Ces écrans comportent d'ailleurs un lecteur SD, mais sur un port SPI séparé, ainsi qu'un port pour le tactile, également en SPI. Cela fait 3 ports SPI par écran : n'est-ce pas trop ?

Je joins le schéma pour la mesure de courant : c'est tout simple, pourquoi n'y avais-je pas pensé plus tôt ?

Pour le CC3000 version SPI, cela m'intéresse.

Dominique
« Modifié: janvier 21, 2016, 10:47:23 am par Dominique »
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #22 le: janvier 21, 2016, 10:59:52 am »
Les 2 SPI de l'écran ne peuvent-ils pas être rassemblés ?  le chip select sélectionnera le bon.
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #23 le: janvier 21, 2016, 11:37:08 am »
Oui bien entendu les SPI peuvent être réunis (MISO, MOSI, SCK, RST) donc être commun. Il faut donc autant de Chip Select (ou Slave Select) que de périphérique.

Ce que je me demande, c'est quelle limite en nombre de Chip Select est permise par la bibliothèque SPI.

A priori je ne vois pas de limite dans la page "reference " d'arduino.cc, autre que la disponibilité de pins. Mais cela n'étonne.
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #24 le: janvier 21, 2016, 11:54:32 am »
A priori si tu veux utiliser les capacités étendues pour le Due, c'est 3. J'imagine que pour utiliser d'autres CS, il faut bricoler les bibliothèques.

Note que le module Adafruit CC3000 te donne la possibilité de te passer de RTC puisqu'il peut récupérer l'heure sur Internet. Elle comporte également un lecteur SD

La doc : https://learn.adafruit.com/downloads/pdf/adafruit-cc3000-wifi.pdf

Note également qu'une solution pour configurer cette carte est de le faire par le CAN à partir d'une carte IHM qui serait autonome et dialoguerait en CAN avec le cerveau.
« Modifié: janvier 21, 2016, 11:58:01 am par Jean-Luc »
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #25 le: janvier 21, 2016, 12:51:50 pm »
Merci Jean-Luc,

Donc avec un port SPI et 2 CS seulement (le 3ème étant utilisé par le CS3000), on doit pouvoir faire tout ce qu'on veut.

Je pense qu'un accès NTP pour la date et l'heure n'enlève pas la nécessite d'un circuit RTC autoalimenté, mais ça utilise le port I2C comme l'EEPROM.

J'avais aussi pensé au périphérique via  ce CAN qui est génial !
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #26 le: janvier 21, 2016, 01:32:22 pm »
Je pense qu'un accès NTP pour la date et l'heure n'enlève pas la nécessite d'un circuit RTC autoalimenté, mais ça utilise le port I2C comme l'EEPROM.

Honnêtement je sais pas. D'autant plus que autoalimenté implique une batterie qui ne se chargera qu'à quand le module sera sous tension. D'autre part, le circuit de charge de ces modules est vraiment médiocre. J'ai peur que l'heure se perdre rapidement.
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #27 le: janvier 21, 2016, 02:02:02 pm »
Je ne savais pas non plus jusqu'à ce que je lise des tas de contributions sur le ouaibe et que j'essaye un module I2C DS3231 + 24C32 alimenté par pile CR2032 : ça devrait tenir plusieurs années et au pire on change la pile.

Les modèles à accu rechargeables sont à éviter d'après ce qu'ai lu.

En prime, ça donne aussi la température : très utile pour éviter de sortir les trains par grand froid !

« Modifié: janvier 21, 2016, 02:04:32 pm par Dominique »
Cordialement,
Dominique

Tanguy

  • Newbie
  • *
  • Messages: 19
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #28 le: juin 10, 2016, 06:41:52 pm »
Bonjour à tous,

L'arduino Due est marquée "retired" sur le site arduino.cc. Même si elle continue à être distribuée, que pensez-vous de la carte Teensy 3.2 comme alternative ?

Elle est en retrait sur quelques caractéristiques par rapport à Due, mais elle est moins encombrante et me semble-t-il suffisante pour une carte cerveau. Elle est par ailleurs distribuée sur le site arduino.cc et est programmable depuis l'IDE Arduino.

Teensy 3.2 :
---------------------------
Operating Voltage        3.3V
Input Voltage (limit)     5V
Digital I/O Pins                   34
PWM Digital I/O Pins   12
Analog Input Pins           21
Analog Output Pins            1
Flash Memory               256 KB
SRAM                         64 KB
EEPROM                          2
Clock Speed               72 MHz (32 Bits)
Can                                1


https://www.pjrc.com/teensy/index.html

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Carte « Cerveau du réseau »
« Réponse #29 le: juin 11, 2016, 12:41:05 am »
Bonjour Tanguy,

Cela m'étonne que la Due soient déjà à la retraite : je n'ai pas vu "retired" sur Arduino.cc, mais je n'ai pas forcément tout regardé.

Cela dit on en trouve à 12/13€ sur le net et elle a quelques atouts comme :
CPU Clock at 84Mhz.
96 KBytes of SRAM.
512 KBytes of Flash memory for code.
A DMA controller, that can relieve the CPU from doing memory intensive tasks.
2 bus CAN et 80 ports environ, et
Des tas de périphériques (3,3V attention !)

Il ne faut pas oublier qu'un programme pour un processeur 32 bit va être double de celui pour un 8 bits et 512Kb avec du graphique, ça peut être utile.

Mais la curiosité m'a conduit à acheter une Teensy 3.2 que je n'ai pas encore vraiment utilisée ne sachant pas si les bibliothèques sont compatibles et même existante. Elle est aussi 2 fois plus chère et on n'en trouve pas beaucoup sur la baie.

Je suis néanmoins d'accord à priori que pour un gestionnaire de réseau l'une ou l'autre peuvent faire l'affaire.

Jean-Luc la connaît mieux que moi et pourrait te répondre de façon plus détaillée.
Cordialement,
Dominique