LOCODUINO
Parlons Arduino => Shields et Modules => Discussion démarrée par: Jean-Luc le avril 22, 2015, 05:07:23 pm
-
Bonjour à tous,
j'ouvre ce fil pour déterminer les fonctions et composants à intégrer sur une carte destinée à piloter un réseau, que ce soit en analogique ou DCC.
Dans le pilotage, j'inclus le dialogue avec les Arduino en charge de :
- la détection de présence
- la commande des aiguillages
- la commande des ponts tournants
- la commande de la signalisation
- ...
Mais aussi l'anticollision, les itinéraires, la circulation automatique, la connaissance et la gestion des trains, ...
En DCC, cette carte servirait de centrale.
En analogique, elle piloterait également les cartes Traction.
Elle remplacerait le PC pour le pilotage du réseau.
L'Arduino ciblé pour cela est l'Arduino Due pour les raisons suivants :
- 512ko de Flash permettant de mettre de très gros programme et quantité de constantes de configuration du réseau.
- 96ko de RAM permettant de stocker beaucoup de données (12 fois plus que sur un Mega, 48 fois plus que sur un Uno)
- Processeur 32 bits à 84 MHz ce qui permet d'en avoir sous le pied
- 2 interfaces CAN natives
Le prix n'est pas un problème puisque le Due serait en exemplaire unique et on trouve des compatibles Due à 15€.
Le Due serait épaulé par un Nano pour générer des signaux précis temporellement sans être embêtés par les interruptions (comptage de temps, Interruption I2C, interruptions CAN, etc). Il s'agit de générer précisément le signal DCC en DCC et les signaux de synchro pour les cartes traction en analogique. Il effectuerait également la surveillance du booster DCC. La communication entre Due et Nano se ferait par le bus SPI.
Sur cette carte 10x10cm, le Due et le Nano viendrait s'enficher par dessous. Par dessus on aurait un emplacement pour mettre un LCD 20x4. On aurait également :
- Deux transceivers CAN 2551 pour les deux CAN du due
- Des prises RJ11/RJ45 pour le CAN/CAN avec synchro analogique
- Un emplacement pour mettre une UART Bluetooth
- Un connecteur pour branche le booster (LMD18200)
- Un connecteur I2C pour déporter un LCD
- Des boutons et switches pour interagir sans PC.
- Un régulateur 9v (7809) avec radiateur pour pouvoir accepter des tensions d'alimentation plus élevées que 12v
N'hésitez pas à mettre votre grain de sel !
-
J'ai une question annexe : quand est-ce que tu t'arrêtes ? ;)
Sinon, de mon coté, je ne vois pas trop quoi mettre en plus, vu que tu as du réfléchir à tous les aspects.
Néanmoins, je ne sais pas de ce que tu as fais d'une voie série si tu en laisses une de dispo pour un ordi.
D'une part pour le debug mais aussi pour ne pas fermer entièrement le truc. Pour faire une sorte de deuxième TCO comme j'aimerais faire sur mon module.
-
Oui, les deux ligne séries sur les connecteurs resteront libres. Il y en a 3 autres de disponibles sur le Due
-
D"accord ben parfait alors tout cela.
Du vrai travail de pro.
-
Je me réponds :)
En creusant, je me rends compte que le Due ne dispose pas d'EEPROM intégrée. Or ça me semble nécessaire de stocker l'état du réseau à l'extinction pour éviter une très fastidieuse séance de mise marche surtout pour un grand réseau.
Il faut donc rajouter une EEPROM externe en I2C par exemple. Un peu moins de 1€ pour une 32ko
-
Puisqu'on en est à rêver (encore qu'avec Jean-Luc, les rêves deviennent vite réalités :D), je pense qu'on devrait pouvoir commander simultanément des locos analogiques et DCC.
A "minima" : pouvoir faire une session DCC. Puis, en modifiant quelques bricoles, faire une session analogique. Mais pas en même temps.
Réfléchir aussi à une interface extensible. Je m'explique :
On crée quelque chose qui gère, mettons, 50 cantons et les aiguilles qui vont avec (ce qui est déjà énorme).
Si on a un grand réseau (Chalindrais, MiniWorld Lyon, ...), on met autant de fois le système que nécessaire.
Deux systèmes pour 100 cantons, par exemple.
Mais à ce moment, quid des cantons "communs" ?
A voir. Je pense qu'il doit y en avoir.
Bluetooth ou Wifi ?
Interface éventuelle avec les centrales DCC du commerce (par exemple XpressNet) pour ceux qui en ont déjà une et qui voudraient la garder.
A part ça, je vais commander un DUE. ça sera déjà prêt. ;D
-
Bonjour,
La carte ayant la connectivité nécessaire pour l'analogique et le DCC, elle peut effectivement commander les deux systèmes simultanément. C'est une affaire de logiciel.
Toutefois je ne vois pas comment gérer le passage d'un canton géré en numérique à un canton géré en analogique. Pour moi ce sont deux technologies incompatibles quand on arrive aux rails. Mixer les deux a coûter la vie à Driving Railway :(
Concernant l'extensibilité, un Due peut gérer allègrement plusieurs centaines de cantons. Par conséquent quel serait l'intérêt ?
Le Bluetooth est plus léger que le wifi et puis les UART Bluetooth sont plus répandues et plus éprouvées.
Concernant la connectique DCC, dites moi ce qu'il faut exactement :)
-
Après étude du contrôleur d'interruptions du micro contrôleur qui équipe le Due, j'ai acquis la certitude que l'on peut générer des signaux DCC temporellement précis sans l'aide d'un Nano. Exit le Nano.
-
Si réutiliser des manettes DCC "commerciales" est louable, il me semble que mettre une interface sur cette carte pour chaque manette est beaucoup. L'exemple sur le site fait qu'il y a quelques composants avec xpressnet, de plus la manette ROCO dans ce cas est alimenté par le prise rj, beaucoup de choses avec une interface logicielle à voir et tout donc pour ma part, je ne suis pas pour mettre tout sur la carte.
Simplement laisser des broches libres avec une interface sur le coté pour que chaque personne puisse brancher ce qu'elle veut.
-
Mettre un connecteur Xpressnet (RJ12) n'est pas un problème. Il suffit de rajouter un emplacement pour ce connecteur et un MAX485.
Ce que j'avais retenu de l'article de Nicolas sur son TCO XPressnet est qu'il faut une liaison série 9 bits. Bouni (http://blog.bouni.de/blog/2014/10/07/sending-and-receiving-9-bit-frames-with-arduino/) a un patch pour avoir une ligne série 9 bits sur tous les Arduino : https://github.com/Bouni/Arduino/tree/ide-1.5.x-hardware-serial-9-bit
-
Certes ce n'est pas un problème mais pour chaque système ? Je dirais qu'il faut laisser la possibilité mais ne pas tout mettre.
Autant rester sur le système Arduino et laisser après la possibilité à chaque de faire à sa sauce. Une sorte de kit de base.
D'autant que égoistement parlant, j'aime bien voir les fils et circuits imprimés : c'est pas joli si il y a des trous ;)
-
Bonjour,
Concernant les remarques de Jean-Luc :
1°) Passer d'un canton analogique à un canton DCC (et réciproquement) me paraît infaisable, effectivement.
Comme la carte centrale sait où sont les trains, on peut peut-être envisager que la carte centrale envoie l'info (DCC/analogique) au canton précédent, alors qu'il est vide ?
Il y a une grande partie de la carte canton qui est commune :
Même en DCC, il faut inverser le sens des rails (par exemple en sortie de boucle).
Il faut bien détecter la présence des trains.
Enfin, si c'est trop dur, on peut faire des sessions DCC puis des sessions analogiques distinctes. C'est déjà pas mal.
2°) Extensibilité : Excellente nouvelle ! Je ne sais pas comment c'est possible, mais c'est super. ;D
3°) OK pour le bluetooth. L'autre problème du wifi est que tout le monde s'en sert (les box en particulier) et les canaux sont saturés.
4°) Excellente nouvelle qu'il existe une bibliothèque permettant le 9 bits sur n'importe quel Arduino.
Concernant celles de Guillaume :
Je ne verrais effectivement pas l'intérêt de pouvoir utiliser une manette du commerce avec l'Arduino.
Par contre, l'accès à un bus (XpressNet, LocoNet, ...) pourrait être très utile vers une centrale du commerce.
Là où je te rejoins, c'est que je pense que c'est certainement sur une carte à part qu'il faut voir ça.
En effet, on en aura besoin que si on a déjà une centrale du commerce
Sinon, on ne va pas acheter une centrale du commerce si on gère tout par Arduino... ;)
Donc, au niveau connectique, je verrais une RJ12 sur la carte centrale et on mettrait un module XpressNet derrière vers le bus du même nom. Ou un module LocoNet. Ou ...
Autres possibilités :
1°) Pouvoir effectuer une action sur la loco (par exemple un coup de sifflet) à un endroit précis du réseau.
Exemple :
A 0,78 cm du début du canton 48 dans le sens horaire. Sans être obligé de mettre une pédale, un ILS, ...
On peut s'en servir aussi pour allumer la lumière quand le train va rentrer dans un tunnel.
2°) Ou déclencher une action ponctuelle sur des éléments extérieurs au réseau sans truffer le réseau de détecteurs.
3°) Soyons fous :
Quand un train circule, si on connait sa vitesse, on peut déduire du temps qu'il met à libérer un canton la longueur du train (top départ : arrivée sur un nouveau canton, top fin : on libère le canton précédent). Ainsi, d'un canton à l'autre, si cette longueur diminue c'est qu'on a perdu des wagons. :P
Je rigole : comme on a une détection par conso de courant, la sécurité est assurée sans surcharger le Due avec des bêtises...
-
Comme la carte centrale sait où sont les trains, on peut peut-être envisager que la carte centrale envoie l'info (DCC/analogique) au canton précédent, alors qu'il est vide ?
Il y a une grande partie de la carte canton qui est commune :
Même en DCC, il faut inverser le sens des rails (par exemple en sortie de boucle).
Il faut bien détecter la présence des trains.
Enfin, si c'est trop dur, on peut faire des sessions DCC puis des sessions analogiques distinctes. C'est déjà pas mal.
Malheureusement ça ne peut pas marcher. Si tu examines les schémas de la carte traction que je t'ai envoyé, tu verras qu'en DCC, la diode roue libre court-circuite le signal DCC sur une 1/2 alternance.
Il faudrait un moyen de mettre cette diode hors-circuit mais ça rajoute de la complexité sur cette carte qui n'en a pas besoin.
Pour moi, soit tu fais du numérique, soit tu fais de l'analogique. Vouloir faire les deux avec la même électronique, c'est aller dans le mur : plus coûteux, plus complexe => marche jamais.
Donc je préfère faire moins mais le faire bien.
Au pire, quelqu'un voulant faire un réseau qui fait les deux peut intercaler un relai entre les alim traction et les rails afin de les déconnecter et ajouter des détections séparées pour le DCC qui seraient également déconnectées sur la condition inverse. Ça fait un peu de matériel en plus mais seul celui qui veut fromage ET dessert le paye et se débrouille avec :)
-
Tu m'as convaincu.
Trop compliqué et cœur de cible inexistant. Donc une carte canton analogique ++ (la tienne) et une carte canton DCC plus simple. Et on choisit.
Donc, au niveau carte centrale, on n'exploitera que l'analogique ou que le DCC.
J'imagine que ton raisonnement est de dire que, comme elle est unique, elle peut être un peu plus compliquée.
D'autant que le fait de la rendre "bicéphale" se résume, au niveau électronique, à une prise booster. Le reste est commun à l'analogique et au DCC.
Mais c'est au niveau logiciel que la différence sera importante.
L'idée que j'avais eue d'une sortie vers XpressNet (p. ex) est finalement sans utilité même si, électroniquement, ça se résume à un MAX485 (essentiellement), dans un module à part.
Il faut bien insister sur le fait que ce cas n'a d'intérêt que si quelqu'un a déjà une centrale du commerce (mais ils sont nombreux). Sinon, on s'en passe.
Cas concret :
La carte centrale, analysant le réseau, décide que le train 3 doit s'arrêter.
Comme c'est la centrale DCC du commerce qui agit sur les trains, via les boosters (qu'on avait déjà ou des LMD18200), la carte centrale doit envoyer dans le bus XpressNet l'ordre correspondant à destination de la centrale DCC. Et le train 3 s'arrête.
Mais, en analysant, la centrale du commerce n'amène rien : il est bien plus simple que la carte centrale s'adresse directement aux boosters !!
A part ça, les boosters du commerce ont une prise bus XpressNet.
-
C'est l'idée oui.
Concernant XPressNet, comme cette carte est une centrale DCC, je voyais plus, comme Guillaume, la possibilité de brancher une multisouris (même si le prix de cet engin est honteux !) ou des accessoires XPressNet. C'est assez léger à mettre : une prise et un MAX485
Au niveau électronique, cette carte est simple.
-
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 !
-
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.
-
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
-
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
-
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.
-
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
-
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
-
Les 2 SPI de l'écran ne peuvent-ils pas être rassemblés ? le chip select sélectionnera le bon.
-
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.
-
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.
-
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 !
-
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.
-
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 !
-
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 (https://www.pjrc.com/teensy/index.html)
-
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.
-
Un petit exemple sur Due : le tracé "arrangé" de mon réseau, pour suivre les décisions du gestionnaire occupe quand même 50 Ko (tracé seul, sans gestionnaire) sur un écran 5 pouces, avec 20 boutons tactiles qui commandent les aiguilles.
Ca va augmenter quand j'aurai décrit et programmé tous les objets graphiques zone, aiguilles et signaux qui seront invoqués par les méthodes des zones, aiguilles, signaux et itinéraires du gestionnaire
-
Bonjour Tanguy
L'arduino Due est marquée "retired" sur le site arduino.cc. Même si elle continue à être distribuée,
Effectivement, elle a été déplacée dans la section "retired" : https://www.arduino.cc/en/Main/Products#retired
Le Nano y est également d'ailleurs
Comme le souligne Dominique, comme c'est de l'Open Hardware, des Due compatibles continueront d'être produites. On trouve également la Due chez Arduino.org : http://www.arduino.org/products/boards/arduino-due. Donc je ne pense pas qu'elle va disparaître, elle est toujours produite : arduino.org pour une version de bonne qualité ou les clones chinois si on n'est pas trop regardant sur les soudures :P
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.
J'en pense que du bien, d'ailleurs je l'utilise en TP : http://www.irccyn.ec-nantes.fr/~bechenne/trampoline-labs/trampoline_labs.pdf
Pour mon usage le défaut est qu'il n'y a qu'un CAN et qu'il m'en faut 2, 1 pour les accessoires, 1 pour la traction (je suis en analogique).
Si je devais remplacer la Due par une autre carte, j'irais sans doute vers la STM32F407 Discovery : http://www.farnell.com/datasheets/1868813.pdf
Ce n'est plus de l'Arduino même si il y a un port qui existe : http://www.stm32duino.com/index.php mais ce n'est pas d'actualité :)
-
Je persiste à penser que c'est bizarre qu'Arduino.cc mette à la retraite autant de cartes pourtant récentes et performantes, l'Arduino Zero n'étant pas équivalent à la Due.
Peut-être est-ce à cause des différents avec Arduino.org ???
En tout cas la Due est très acceptable pour un prix de 12-13 € et je n'ai jamais eu de problème avec mes 4 cartes Due pour le moment... sauf pour le reset qui nécessite un petit circuit supplémentaire, le MCP130-300 comme le montre la photo jointe.
Ce circuit se branche sur Reset, 3.3V et Gnd. Il résout simplement un problème difficile à comprendre quand on ne le connait pas. Et je me demande si la production d'Arduino.org en a tenu compte (vu la simplicité du site, on peut en douter, mais je me trompe peut-être).
Maintenant, je le dis franchement, je ne serais pas chaud pour mixer des Arduino avec d'autres micro-controlleurs ne supportant pas l'IDE Arduino.
Je préfèrerais même pouvoir trouver un système de mise à jour logicielle en réseau CAN, à partir d'une passerelle Wifi-CAN ou Bluetooth(5)-Can qui pourrait faire l'objet d'une étude sur Locoduino, un de ces jours, si c'est possible.
-
merci Dominique et Jean-Luc pour vos réponses et développements.
La carte Teensy me parait plus séduisante dans mon projet (dcc) notamment pour pouvoir la "sortir" du réseau et la reporgrammer sans tout dé-cabler.
A moins que l'alternative de Dominique (mise à jour par le bus CAN) soit faisable à mon niveau; mais j'ai du ma à comprendre à comment il serait possible de reprogrammer la carte par ce biais. J'attends le futur article ;).
Dominique quel est donc ce problème de reset sur la carte Due ? le bouton ne fonctionne pas comme attendu ?
-
Bonsoir Tanguy,
En ce qui concerne la question de "sortir" la carte pour la reprogrammer, il suffit de brancher un câble USB à demeure dont l'autre extrémité peut être raccorder à ton PC/Mac.
Moi j'ai résolu ce problème comme ça en utilisant un MacBook pour programmer mes Mégas et Due.
Pour le bus CAN, je n'ai pas encore la solution faute de temps. Je pense aussi à une solution OTA (over the air) en WiFi ou Bluetooth. Mais je cherche encore.
-
En ce qui concerne le Reset de la carte Due, il est connu que lorsqu'on branche l'USB sur la Due ou une alim externe, alors qu'elle a déjà été alimentée peu de temps auparavant (5 minutes d'après le forum arduino.cc, donc condensateur d'alimentation pas totalement déchargé), le reset ne se fait pas bien et la carte ne démarre pas correctement.
Nous avons discuté la solution entre nous et celle-ci consiste à utiliser un circuit spécialisé de reset : le MCP120 ou le MCP130 (version MCP130-300 pour un seuil à 3 V).
Il s'agit d'un bête à 3 pattes que l'on trouve en boîtier to92 entre autre (le petit noir des transistors)
Il se branche sur VDD, GND et RST
Tant que VDD est inférieur à un seuil, RST est maintenu à GND. Donc le micro reste en reset tant que l'alim n'est pas clairement établie. Quand VDD passe le seuil (3 V c'est bien), RST monte à VDD après un délai de 350ms. Cela assure le démarrage.
C'est facile à mettre en œuvre, conçu pour et le circuit coûte 40c par trois chez TME.
http://www.tme.eu/en/details/mcp130-300di_to/watchdog-and-reset-circuits/microchip-technology/ (http://www.tme.eu/en/details/mcp130-300di_to/watchdog-and-reset-circuits/microchip-technology/)
Voilà : j'avais détecté ce problème notamment en voulant faire des mises à jour de logiciel sur mon réseau et j'ai failli conclure à la mauvaise qualité des fabrications chinoises. Que neni, avec ce petit composant tout baigne :))
-
Bonjour à tous,
Avec le temps certaines choses se décantent :
- Le Due n'est plus au rebut :D
- je n'ai pas progressé sur le bootloader CAN mais j'accumule les infos quand je tombe dessus.
J'ai acheté un Teensy, installé les outils, fait quelques croquis pour découvrir, mais je n'ai pas décidé de remplacer le Due pour le moment car j'en ai 3 dont l'un est opérationnel sur le réseau et un autre sert aux développements en cours. Je me méfie un peu des différences possibles entre les bibliothèques et je manque de temps !
Amicalement
Dominique
-
De mon côté, j'ai acheté à l'autre bout de la planète deux STM32 à 3.50€ pièce, (http://www.icstation.com/stm32f103c8t6-stm32-minimum-system-development-board-module-p-7013.html) équipés de processeurs ARM Cortex M3, 64K mémoire programme et surtout 20k de mémoire vive, et dotés de SPI, I2C, USART, et même CAN ! Le tout dans un boitier à peine plus grand qu'un Nano...
La programmation réclame d'adapter l'IDE (http://www.grauonline.de/wordpress/?page_id=1004), et de passer par deux fils raccordés à une interface USB/UART.
J'ai fait tourner un petit blink, mais il faut passer plus de temps pour comprendre ce que l'on peut en tirer...
-
Bonjour à tous,
Mais qu'est-ce que c'est que tous ces machins ? :o
Vous sortez ça d'où ??
On dirait bien que c'est super ! ;)
Denis
-
Hey Denis,
Regardes régulièrement les nouveautés de quelques vendeurs sur eBay comme czb6721960 ou alice1101983 (ça a l'air d'être les deux même, ils ont les mêmes objets au même prix).
Et bien tu verras des tas de nouveaux processeurs ultra puissants à des prix dérisoires.
Par contre j'ai l'impression qu'il y a moins de nouveautés cite Arduino. J'ai fait des stocks au cas ou les prix remontent.
Je ne savais pas qu'on pouvait programmer ce STM32 avec l'IDE.
De toute façon je reste prudent et peu téméraire en ce moment pour essayer d'avancer sur mon projet.
Amicalement
Dominique
-
Bonjour,
Il y a également les nouveaux Teensy de PJRC : le 3.5 et le 3.6 qui sont probablement ce qui se fait de plus puissant en Arduino compatible.
Le 3.5 (26€) :
(https://www.pjrc.com/store/teensy35.jpg)
(https://www.pjrc.com/store/teensy35b.jpg)
120 MHz ARM Cortex-M4 with Floating Point Unit
512K Flash, 192K RAM, 4K EEPROM
Microcontroller Chip MK64FX512VMD12 (PDF link)
1 CAN Bus Port
16 General Purpose DMA Channels
5 Volt Tolerance On All Digital I/O Pins
62 I/O Pins (42 breadboard friendly)
25 Analog Inputs to 2 ADCs with 13 bits resolution
2 Analog Outputs (DACs) with 12 bit resolution
20 PWM Outputs
USB Full Speed (12 Mbit/sec) Port
Ethernet mac, capable of full 100 Mbit/sec speed
Native (4 bit SDIO) micro SD card port
I2S Audio Port, 4 Channel Digital Audio Input & Output
14 Hardware Timers
Cryptographic Acceleration Unit
Random Number Generator
CRC Computation Unit
6 Serial Ports (2 with FIFO & Fast Baud Rates)
3 SPI Ports (1 with FIFO)
3 I2C Ports
Real Time Clock
Le 3.6 (31€) :
(https://www.pjrc.com/store/teensy36.jpg)
(https://www.pjrc.com/store/teensy36b.jpg)
180 MHz ARM Cortex-M4 with Floating Point Unit
1M Flash, 256K RAM, 4K EEPROM
Microcontroller Chip MK66FX1M0VMD18 (PDF link)
USB High Speed (480 Mbit/sec) Port
2 CAN Bus Ports
32 General Purpose DMA Channels
22 PWM Outputs
4 I2C Ports
11 Touch Sensing Inputs
62 I/O Pins (42 breadboard friendly)
25 Analog Inputs to 2 ADCs with 13 bits resolution
2 Analog Outputs (DACs) with 12 bit resolution
22 PWM Outputs
USB Full Speed (12 Mbit/sec) Port
Ethernet mac, capable of full 100 Mbit/sec speed
Native (4 bit SDIO) micro SD card port
I2S Audio Port, 4 Channel Digital Audio Input & Output
14 Hardware Timers
Cryptographic Acceleration Unit
Random Number Generator
CRC Computation Unit
6 Serial Ports (2 with FIFO & Fast Baud Rates)
3 SPI Ports (1 with FIFO)
4 I2C Ports
Real Time Clock
Mon ami Pierre a construit un prototype de tablette avec un Teensy 3.6 et un LCD tactile 7". Nous étions parti à l'origine sur de l'iPad mais les contraintes des applications signées et le renouvellement permanent des certificats nous a dissuadé de continuer dans cette voie.
Il a développé une bibliothèque graphique de vues en s'appuyant sur UTFT, la bibliothèque d'Hennin Karlsen. De plus elle gère le clipping via un mécanisme de régions. Ça ressemble assez au Quickdraw originel du Mac qui à l'époque tournait sans problème sur une 68000 à 16MHz avec 128ko de mémoire au total. Alors sur un Cortex M4 à 180MHz, 1Mo de flash et 256k de RAM, il y a de la marge. Ces deux modèles ont également un slot microSD
-
Bien joué Jean-Luc et Pierre,
Le mien est un 3.2 et j'avais l'intention d'acheter plus puissant. D'autant qu'il est bien supporté par dl'IE d'Arduino.
J'utilise aussi la bibliothèque UTFT de Rinky-Dink Electronics, Henning Karlsen, avec UTFT_Buttons, UTFT_Geometry, UTFT_SdRaw, UTFT_SPIflash et UTouch.
Avec le Due c'est déjà pas mal :D
C'est probablement une évolution naturelle de mon gestionnaire.
J'ai aussi utilisé les premiers MBED avec leur compilateur en ligne. J'en ai 2 dans mes tiroirs.
Par contre le projet de Pierre est très intéressant : faire une tablette avec un écran 7" sans Linux ni Android, chapeau !
J'ai une petite question à ce sujet : j'avais récupéré 2 tablettes avec de superbes écrans dont je n'ai aucune idée sur la manière de les interfacer avec un Teensy ou un Due. Les écrans sont raccordés à une carte mère par une nappe. Par quel bout puis-je aborder ce problème ?
Merci d'avance et bon week-end !
Dominique
-
Je vous prie de bien vouloir m'excuser, je ne le referai plus ... :D
L'une des raisons pour laquelle j'avais arrêté Elektor était qu'on sortait un nouveau composant (lire processeur) à chaque projet.
Mes neurones ne suivaient plus. Il fallait réapprendre de nouvelles notions et presque un nouveau langage à chaque fois.
C'est très désagréable.
Ce que je retiens de ces quelques posts, c'est que, même si on arrête le DUE (on en a parlé un temps), on aura de quoi le remplacer.
C'est une bonne nouvelle.
Deuzio : j'ai acheté un PCDuino (que je n'ai pas encore testé) à environ 70 €
Peut-on espérer, moyennant un périphérique qui va bien, brancher une ou deux prise HDMI sur un de ces Teensy ?
Parce que ça serait moitié prix. ;)
Tertio :
Cela me paraît idéal pour ressusciter mon projet :
http://forum.locoduino.org/index.php?topic=156.0 (http://forum.locoduino.org/index.php?topic=156.0)
Sinon, bravo !
Denis
-
Denis,
Au sujet d'Elektor, j'ai été un peu comme toi : je vais jeter ou j'ai déjà jeté la Picée, l'Avrée et l'Armée, te souviens-tu ?
Amicalement
Dominique
-
La communication entre le Teensy et l'écran LCD se fait via 16 broches numériques pour les données plus quelques broches pour le contrôle.
-
OK pour le LCD.
Mais, moi, je voulais brancher une télé de récup pour afficher le TCO. Elle est en HDMI.
-
Par contre le projet de Pierre est très intéressant : faire une tablette avec un écran 7" sans Linux ni Android, chapeau !
Ça tourne déjà mais Pierre préfère diffuser des choses bien abouties. Il a également développé un simulateur sur Mac pour mettre au point les applications graphiques.
J'ai une petite question à ce sujet : j'avais récupéré 2 tablettes avec de superbes écrans dont je n'ai aucune idée sur la manière de les interfacer avec un Teensy ou un Due. Les écrans sont raccordés à une carte mère par une nappe. Par quel bout puis-je aborder ce problème ?
Je ne sais pas. Le proto fonctionne avec cet écran : http://www.ebay.com/itm/7-inch-TFT-LCD-module-Display-800x480-SSD1963-Touch-PWM-Arduino-AVR-STM32-ARM-/311523810931 mais pour ce qui est de la connexion avec un autre type d'écran, ça dépend du processeur graphique qui est utilisé et qui doit être supporté par UTFT.
-
Le Teensy 3.6 s'overclocke à 240 MHz sans soucis :-)
-
C'est pour les TGV ??? ;D ;D ;D ;D
Denis
-
Comment overclocker un Teensy ? En remplaçant le quartz ?
C'est pas toujours facile à dessouder !
-
Non non, pas besoin de toucher au quartz.
Sur un Uno, la fréquence de l'horloge du CPU est donnée par le quartz directement, pas d'autre choix.
Sur les micros un peu complexes (c'est à dire les ARM dans le monde Arduino), l'horloge du CPU est construite à partir d'un oscillateur à plus basse fréquence, soit un quartz externe, soit un oscillateur interne. Sur le Teensy 3.6, il s'agit d'un quartz externe à 16MHz.
Cette fréquence est multipliée par une PLL (Phase locked loop) pour donner la fréquence de l'horloge du CPU et cette PLL est programmable via des registres. On peut donc changer ce facteur multiplicatif. Il faut changer un peu le code d'initialisation fourni dans Teensyduino.
-
Rectification : l'option overclock à 240 MHz est directement dans les menus :)