1111
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 09, 2016, 03:09:34 pm »
Tu as connecté le DUE via le programming port ?
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
1112
Le logiciel DCC++ / Re : Re : Re : DCC++ BaseStation
« le: mars 09, 2016, 02:37:35 pm »Si je voulais être caustique, je dirais « le droit de concourir à The International Obfuscated C Code Contest » http://www.ioccc.org
Plus sérieusement, bien fait ça donne un code (légèrement) plus efficace tout en restant concis. Personnellement je n'aime pas. Il y a tellement de possibilités de se faire avoir par le préprocesseur qu'il ne vaut mieux pas s'y frotter de cette manière
Donc, qu'est-ce ça donne en clair ?
Prenons la ligne
Code: [Sélectionner]
OCR ## N ## A=DCC_ONE_BIT_TOTAL_DURATION_TIMER ## N
OCR n'est pas une macro
N est l'argument de la macro dans laquelle cette ligne apparaît
A n'est pas une macro
DCC_ONE_BIT_TOTAL_DURATION_TIMER n'est pas une macro
Donc première passe, N est remplacé par sa valeur, 0 ou 1. Prenons 1
Code: [Sélectionner]
OCR1A=DCC_ONE_BIT_TOTAL_DURATION_TIMER1
OCR1A est une macro de l'AVR, DCC_ONE_BIT_TOTAL_DURATION_TIMER1 est défini à 3199
2e passe
OCR1A est défini dans iom328p.h
Code: [Sélectionner]
#define OCR1A _SFR_MEM16(0x88)
Et donc
Code: [Sélectionner]
_SFR_MEM16(0x88)=3199
1113
Le logiciel DCC++ / Re : DCC++ BaseStation
« le: mars 09, 2016, 01:45:45 pm »
Si je voulais être caustique, je dirais « le droit de concourir à The International Obfuscated C Code Contest » http://www.ioccc.org 
Plus sérieusement, bien fait ça donne un code (légèrement) plus efficace tout en restant concis. Personnellement je n'aime pas. Il y a tellement de possibilités de se faire avoir par le préprocesseur qu'il ne vaut mieux pas s'y frotter de cette manière
Plus sérieusement, bien fait ça donne un code (légèrement) plus efficace tout en restant concis. Personnellement je n'aime pas. Il y a tellement de possibilités de se faire avoir par le préprocesseur qu'il ne vaut mieux pas s'y frotter de cette manière
1114
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 09, 2016, 01:37:36 pm »
Effectivement, mon émulation pour Mac (et Unix en général, ça compilera sous Linux et sans doute sous Windows) casse la compilation pour un Arduino à base d'ARM
Voici une version à jour qui compile sur Due. Hier soir j'ai également commencé à travailler sur les itinéraires et les ensembles d'itinéraires. il y a donc de nouvelles classes qui ne sont pas utilisées pour le moment. Le sketch actuel fait la même chose que celui que j'ai déjà posté.
J'ai également commencé à mettre le code en plusieurs fichiers de manière à ne laisser dans le sketch que ce qui est propre au réseau.
Voici une version à jour qui compile sur Due. Hier soir j'ai également commencé à travailler sur les itinéraires et les ensembles d'itinéraires. il y a donc de nouvelles classes qui ne sont pas utilisées pour le moment. Le sketch actuel fait la même chose que celui que j'ai déjà posté.
J'ai également commencé à mettre le code en plusieurs fichiers de manière à ne laisser dans le sketch que ce qui est propre au réseau.
1115
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 09, 2016, 10:58:07 am »
Tout bon
1116
Le logiciel DCC++ / Re : DCC++ BaseStation
« le: mars 09, 2016, 09:18:11 am »Citer
mais il reste une syntaxe dans DCCpp_Uno.ino que je n'ai pas comprise (ligne 443) :Code: [Sélectionner]if(R.currentReg->activePacket->buf[R.currentBit/8] & R.bitMask[R.currentBit%8]){
OCR ## N ## A=DCC_ONE_BIT_TOTAL_DURATION_TIMER ## N;
OCR ## N ## B=DCC_ONE_BIT_PULSE_DURATION_TIMER ## N;
} else{ /* ELSE it is a ZERO */
OCR ## N ## A=DCC_ZERO_BIT_TOTAL_DURATION_TIMER ## N;
OCR ## N ## B=DCC_ZERO_BIT_PULSE_DURATION_TIMER ## N;
} /* END-ELSE */
est-ce que ## est un opérateur ?? J'avoue que je sèche.
C'est le token de concaténation de macros :
https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
Donc là, OCR, N, A sont des macros qui sont respectivement expansées et concaténées
DCC_ONE_BIT_TOTAL_DURATION_TIMER (ou DCC_ONE_BIT_PULSE_DURATION_TIMER) et N sont également expansées et concaténées
Le résultat repasse par le préprocesseur pour traitement et éventuelle réexpansion.
1117
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 09, 2016, 12:18:49 am »
Salut Dominique
C'est réservé à l'admin effectivement.
Eventuellement vous pouvez vous faire un article bidon dont vous ne demandez pas la publication et vous chargez vos images dans cet article. Il suffit ensuite de récupérer l'URL de l'image pour pouvoir l'insérer dans le forum. Comme ceci :
Il y a un truc qui m'intéresserait : comment mettre des images dans le dossier www.locoduino.org/pic ?
C'est peut-être réservé à l'admin ?
C'est réservé à l'admin effectivement.
Eventuellement vous pouvez vous faire un article bidon dont vous ne demandez pas la publication et vous chargez vos images dans cet article. Il suffit ensuite de récupérer l'URL de l'image pour pouvoir l'insérer dans le forum. Comme ceci :
1118
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 09, 2016, 12:12:21 am »Sur ton schéma, Jean-Luc, chaque flèche est un pointeur.
Oui
Citer
Pour tjd12, pointeur de mVoieEntrant = voie8 et pointeur de mVoieEntrantBis = voie21
De même pour voie8, pointeur de mVoieSortant = tjd12 et pour voie21, pointeur de mVoieSortant = tjd12
Oui
Citer
Dans le test if (venantDe == mVoieSortantDroit) {..},
mVoieSortantDroit est un élément de la classe Voie et donc ce n'est pas un pointeur.
Non, mVoieSortantDroit est un pointeur vers un objet de type Voie. Regarde dans la déclaration de la classe Aiguille :
Code: [Sélectionner]
Voie *mVoieSortantDroit;
Citer
Il y a deux mVoieSortantDroit : celui de la voie8 et celui de la voie21 et il faut donc choisir.
Non, mVoieSortantDroit est une donnée membre de la classe Aiguille.
Citer
Tu es dans bool traverseeJonctionDouble(...), donc tu es sur la tjd12 et tu recherches les antécédents pour pouvoir créer un chemin qui va venir soit de la voie8, soit de la voie21.
Quand tu rentres comme argument de bool(...) Voie *venantDe, tu veux préciser en entrée que tu viens de la voie8 ou que tu viens de la voie21.
Admettons qu'on vienne de la voie8.
Est-ce que je peux dire, dans tjd12, que Voie *venantDe = voie8 ?
Non. Comme voie8 a passé this dans l'argument venantDe, venantDe est un pointeur vers voie8, c'est à dire &voie8. On compare chacun des pointeurs vers les voies précédentes : mVoieEntrant et mVoieEntrantBis à venantDe. L'un d'entre eux étant un pointeur vers voie8, il est égal à venantDe et de cette manière tu sais d'où on vient et tu connais la position de l'aiguille d'entrée de la TJD
Citer
Par ailleurs, dans voie8, mSortantDroit, pointe vers tjd12.
Est-ce que je peux dire, dans voie8 cette fois, que *mSortantDroit = tjd12 ?
Je ne suis pas sûr de comprendre ce que tu veux écrire. Ton égal est le égal mathématique ou l'affectation ?
1119
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 08, 2016, 11:51:09 am »
Je complète la réponse de Thierry avec un petit dessin que j'ai fait en parallèle
Pas du tout, ça ne pollue rien, un forum c'est fait pour discuter
__AVR__ est un symbole défini par le compilateur quand il compile pour AVR et donc pour Arduino Uno/Nano. Sinon il ne l'est pas. J'utilise ça pour émuler des macros et des classes Arduino sur mon Mac. Ça me permet de compiler et exécuter le programme sur mon Mac, sans Arduino, et de mettre au point dans un environnement plus confortable.
C'est ça
C'est ça.
Non, je compare les pointeurs.
En effet, chaque voie connaît ses voisines via des pointeurs. Par exemple quand on écrit :
ça donne ça
Quand creeCheminVers de la TJD est appelée, venantDe sert à savoir de où on vient, voie8 ou voie21 ? En le comparant avec les deux pointeurs arrière, on détermine la position de l'aiguille d'entrée de le TJD. Idem quand on entre dans une aiguille par la branche déviée ou la branche droite
J'ai bien conscience que ça va "polluer" ton exposé, mais je me pose quelques questions :
Pas du tout, ça ne pollue rien, un forum c'est fait pour discuter
Citer
Code: [Sélectionner]#ifdef __AVR__Je ne connais pas ___AVR__ ?
#include <avr/pgmspace.h>
#endif
#ifndef __AVR__
#include <iostream>
#define F(string) string
#define PROGMEM
__AVR__ est un symbole défini par le compilateur quand il compile pour AVR et donc pour Arduino Uno/Nano. Sinon il ne l'est pas. J'utilise ça pour émuler des macros et des classes Arduino sur mon Mac. Ça me permet de compiler et exécuter le programme sur mon Mac, sans Arduino, et de mettre au point dans un environnement plus confortable.
Citer
Le simple fait de mettre #define DEBUG au début suffit pour pouvoir afficher les essais ?
Tu mets les sorties Serial.print() entre #ifdef DEBUG .... #endif et elles sont affichées et si tu dévalides le #define DEBUG pour ne plus les afficher.
C'est sympa, ça.
C'est ça
Citer
Et, dans mes efforts pour comprendre les pointeurs, je choisis "venantDe". Exemple :Code: [Sélectionner]bool Aiguillage::creeCheminVers(byte identifiant, byte dir, Voie *venantDe)
{
if (idVoie() == identifiant) return true;
else {
if (direction() == dir) {
if (mVoieSortantDroit != NULL) {
if (mVoieSortantDroit->creeCheminVers(identifiant, dir, this)) {
afficheNomVoie(idVoie());
Serial.println(F(": droit"));
return true;
}
else if (mVoieSortantDevie != NULL) {
if (mVoieSortantDevie->creeCheminVers(identifiant, dir, this)) {
afficheNomVoie(idVoie());
Serial.println(F(": devie"));
return true;
}
else return false;
}
else return false;
}
else return false;
}
else {
if (mVoieEntrant != NULL) {
if (mVoieEntrant->creeCheminVers(identifiant, dir, this)) {
afficheNomVoie(idVoie());
if (venantDe == mVoieSortantDroit) {
Serial.println(F(": droit"));
}
else {
Serial.println(F(": devie"));
}
return true;
}
else return false;
}
else return false;
}
}
}
Au début, il y a une étoile : Voie *venantDe
J'en déduis que c'est un pointeur ?
C'est ça.
Citer
Puis, un peu plus loin dans un test, tu as : if (venantDe == mVoieSortantDroit)
Et là, c'est le contenu de la variable ?
Non, je compare les pointeurs.
En effet, chaque voie connaît ses voisines via des pointeurs. Par exemple quand on écrit :
Code: [Sélectionner]
voie8.connecteSortantAVoie(tjd12, ENTRANT);
voie21.connecteSortantAVoie(tjd12, ENTRANT_BIS);
ça donne ça
Quand creeCheminVers de la TJD est appelée, venantDe sert à savoir de où on vient, voie8 ou voie21 ? En le comparant avec les deux pointeurs arrière, on détermine la position de l'aiguille d'entrée de le TJD. Idem quand on entre dans une aiguille par la branche déviée ou la branche droite
1120
Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 07, 2016, 08:02:44 pm »
La solution pour caser les 4m dans ta pièce est de courber la gare. Note que j'ai mis des voies de garage très généreuses
Concernant les voies intermédiaires, du point de vu du graphe on peut effectivement les omettre mais je pense étendre le système au delà de la détermination des itinéraires.
Je continue.
Chaque classe dispose de fonction de connexion. Ainsi une voie de garage possède une unique fonction de connexion :
qui va connecter SORTANT à la voie et au connecteur passés en argument.
Une voie normale possède 2 fonctions de connexion :
qui vont connecter respectivement SORTANT et ENTRANT à la voie et au connecteur passés en argument. Si on utilise connecteSortantAVoie, une voie normale est connecté dans le sens normal (DIRECTION_AVANT) si on utilise connecteEntrantAVoie, elle est connectée dans le sens inverse (DIRECTION_ARRIERE).
Un aiguillage possède 3 fonctions de connexion :
De la même manière, si on utilise connecteSortantDroitAVoie ou connecteSortantDevieAVoie, l'aiguillage est connecté en DIRECTION_AVANT et si on utilise connecteEntrantAVoie, il est connectée en DIRECTION_ARRIERE.
Idem pour les croisement et TJD :
Les connexions doivent être réalisées de manière compatible. C'est à dire qu'un élément de voie ne peut pas être connecté de telle sorte qu'il soit à la fois en DIRECTION_AVANT et DIRECTION_ARRIERE. Pour cela il faut connecter en parcourant les éléments dans une direction.
Je ne traite donc pas les boucles de retournement pour l'instant.
Les objets sont instanciés simplement. Par exemple, si on prend en bas à gauche VoieLibre0, Aiguille0, Voie0 et Voie1, on a
Une fois instanciés les objets, on les connecte. Il faut décider d'un direction de connexion, de la gauche vers la droite dans notre cas :
Ici tous les objets sont en DIRECTION_AVANT. Mais, par exemple, en connectant de gauche à droite, l'aiguillage Aiguille3 sera en DIRECTION_ARRIERE.
On a donc une ligne par connecteur dans la gare. Pour la gare de DDEFF nous avons 110 connexions :
Je vous livre le sketch complet avec la recherche de deux chemins. Je n'ai pas tout testé, je viens de le terminer. Il peut être modifié pour ajouter des requêtes de chemin. Pour l'instant l'algorithme ne cherche qu'un seul chemin. Je vais rajouter la recherche de tous les chemins possibles, le calcul de l'intersection des chemins et donc l'établissement de plusieurs chemins simultanément.
Ça tourne sur un Uno en bouffant 33% de la flash et 52% de la SRAM
Concernant les voies intermédiaires, du point de vu du graphe on peut effectivement les omettre mais je pense étendre le système au delà de la détermination des itinéraires.
Je continue.
Chaque classe dispose de fonction de connexion. Ainsi une voie de garage possède une unique fonction de connexion :
Code: [Sélectionner]
void connecteAVoie(Voie &voie, byte connecteur);
qui va connecter SORTANT à la voie et au connecteur passés en argument.
Une voie normale possède 2 fonctions de connexion :
Code: [Sélectionner]
void connecteSortantAVoie(Voie &voie, byte connecteur);
void connecteEntrantAVoie(Voie &voie, byte connecteur);
qui vont connecter respectivement SORTANT et ENTRANT à la voie et au connecteur passés en argument. Si on utilise connecteSortantAVoie, une voie normale est connecté dans le sens normal (DIRECTION_AVANT) si on utilise connecteEntrantAVoie, elle est connectée dans le sens inverse (DIRECTION_ARRIERE).
Un aiguillage possède 3 fonctions de connexion :
Code: [Sélectionner]
void connecteSortantDroitAVoie(Voie &voie, byte connecteur);
void connecteSortantDevieAVoie(Voie &voie, byte connecteur);
void connecteEntrantAVoie(Voie &voie, byte connecteur);
De la même manière, si on utilise connecteSortantDroitAVoie ou connecteSortantDevieAVoie, l'aiguillage est connecté en DIRECTION_AVANT et si on utilise connecteEntrantAVoie, il est connectée en DIRECTION_ARRIERE.
Idem pour les croisement et TJD :
Code: [Sélectionner]
void connecteSortantAVoie(Voie &voie, byte connecteur);
void connecteSortantBisAVoie(Voie &voie, byte connecteur);
void connecteEntrantAVoie(Voie &voie, byte connecteur);
void connecteEntrantBisAVoie(Voie &voie, byte connecteur);
Les connexions doivent être réalisées de manière compatible. C'est à dire qu'un élément de voie ne peut pas être connecté de telle sorte qu'il soit à la fois en DIRECTION_AVANT et DIRECTION_ARRIERE. Pour cela il faut connecter en parcourant les éléments dans une direction.
Je ne traite donc pas les boucles de retournement pour l'instant.
Les objets sont instanciés simplement. Par exemple, si on prend en bas à gauche VoieLibre0, Aiguille0, Voie0 et Voie1, on a
Code: [Sélectionner]
VoieNormale voieLibre0(VOIE_LIBRE_0);
Aiguillage aiguille0(AIGUILLE_0);
VoieNormale voie0(VOIE_0);
VoieNormale voie1(VOIE_1);
Une fois instanciés les objets, on les connecte. Il faut décider d'un direction de connexion, de la gauche vers la droite dans notre cas :
Code: [Sélectionner]
voieLibre0.connecteSortantAVoie(aiguille0, ENTRANT);
aiguille0.connecteSortantDevieAVoie(voie0, ENTRANT);
aiguille0.connecteSortantDroitAVoie(voie1, ENTRANT);
Ici tous les objets sont en DIRECTION_AVANT. Mais, par exemple, en connectant de gauche à droite, l'aiguillage Aiguille3 sera en DIRECTION_ARRIERE.
On a donc une ligne par connecteur dans la gare. Pour la gare de DDEFF nous avons 110 connexions :
Code: [Sélectionner]
/*
* Connexion des voies de bas en haut et de gauche à droite
*/
voieLibre0.connecteSortantAVoie(aiguille0, ENTRANT);
aiguille0.connecteSortantDevieAVoie(voie0, ENTRANT);
aiguille0.connecteSortantDroitAVoie(voie1, ENTRANT);
voie0.connecteSortantAVoie(tjd0, ENTRANT_BIS);
voie1.connecteSortantAVoie(tjd8, ENTRANT_BIS);
voieLibre1.connecteSortantAVoie(tjd0, ENTRANT);
tjd0.connecteSortantAVoie(voie3, ENTRANT);
tjd0.connecteSortantBisAVoie(voie2, ENTRANT);
voie3.connecteSortantAVoie(tjd8, ENTRANT);
tjd8.connecteSortantAVoie(voie22, ENTRANT);
tjd8.connecteSortantBisAVoie(voie21, ENTRANT);
voie22.connecteSortantAVoie(aiguille12, SORTANT_DEVIE);
aiguille12.connecteEntrantAVoie(voieGarage2, SORTANT);
voie32.connecteSortantAVoie(aiguille12, SORTANT_DROIT);
voieLibre2.connecteSortantAVoie(tjd1, ENTRANT);
voie2.connecteSortantAVoie(tjd1, ENTRANT_BIS);
tjd1.connecteSortantAVoie(voie8, ENTRANT);
tjd1.connecteSortantBisAVoie(voie6, ENTRANT);
voie8.connecteSortantAVoie(tjd12, ENTRANT);
voie21.connecteSortantAVoie(tjd12, ENTRANT_BIS);
tjd12.connecteSortantAVoie(voie27, ENTRANT);
tjd12.connecteSortantBisAVoie(croisement2, ENTRANT_BIS);
voie27.connecteSortantAVoie(tjd15, ENTRANT_BIS);
croisement2.connecteSortantAVoie(tjd15, ENTRANT);
tjd15.connecteSortantBisAVoie(voie31, ENTRANT);
tjd15.connecteSortantAVoie(voie32, ENTRANT);
voie31.connecteSortantAVoie(aiguille11, ENTRANT);
aiguille11.connecteSortantDevieAVoie(voieGarage3, SORTANT);
aiguille11.connecteSortantDroitAVoie(voieGarage4, SORTANT);
voieLibre3.connecteSortantAVoie(tjd2, ENTRANT);
voie6.connecteSortantAVoie(tjd2, ENTRANT_BIS);
tjd2.connecteSortantAVoie(voie12, ENTRANT);
tjd2.connecteSortantBisAVoie(voie11, ENTRANT);
voie12.connecteSortantAVoie(tjd11, ENTRANT_BIS);
voie20.connecteSortantAVoie(tjd11, ENTRANT);
tjd11.connecteSortantBisAVoie(voie26, ENTRANT);
tjd11.connecteSortantAVoie(croisement2, ENTRANT);
voie26.connecteSortantAVoie(tjd14, ENTRANT);
croisement2.connecteSortantBisAVoie(tjd14, ENTRANT_BIS);
tjd14.connecteSortantAVoie(voie30, ENTRANT);
tjd14.connecteSortantBisAVoie(voie29, ENTRANT);
voie30.connecteSortantAVoie(aiguille10, ENTRANT);
aiguille10.connecteSortantDroitAVoie(voieGarage5, SORTANT);
aiguille10.connecteSortantDevieAVoie(voie34, ENTRANT);
voie34.connecteSortantAVoie(aiguille14, SORTANT_DROIT);
voie33.connecteSortantAVoie(aiguille14, SORTANT_DEVIE);
aiguille14.connecteEntrantAVoie(voieGarage6, SORTANT);
voieLibre4.connecteSortantAVoie(tjd4, ENTRANT);
voie11.connecteSortantAVoie(tjd4, ENTRANT_BIS);
tjd4.connecteSortantAVoie(voie16, ENTRANT);
tjd4.connecteSortantBisAVoie(croisement0, ENTRANT_BIS);
voie16.connecteSortantAVoie(tjd7, ENTRANT_BIS);
croisement0.connecteSortantAVoie(tjd7, ENTRANT);
tjd7.connecteSortantAVoie(voie20, ENTRANT);
tjd7.connecteSortantBisAVoie(voie19, ENTRANT);
voie19.connecteSortantAVoie(aiguille8, SORTANT_DROIT);
voie25.connecteSortantAVoie(aiguille8, SORTANT_DEVIE);
aiguille8.connecteEntrantAVoie(voie28, ENTRANT);
voie28.connecteSortantAVoie(tjd16, ENTRANT);
voie29.connecteSortantAVoie(tjd16, ENTRANT_BIS);
tjd16.connecteSortantAVoie(voie33, ENTRANT);
tjd16.connecteSortantBisAVoie(voieGarage7, SORTANT);
voieLibre5.connecteSortantAVoie(tjd3, ENTRANT_BIS);
voie10.connecteSortantAVoie(tjd3, ENTRANT);
tjd3.connecteSortantAVoie(croisement0, ENTRANT);
tjd3.connecteSortantBisAVoie(voie15, ENTRANT);
voie15.connecteSortantAVoie(tjd6, ENTRANT);
croisement0.connecteSortantBisAVoie(tjd6, ENTRANT_BIS);
tjd6.connecteSortantAVoie(voie18, ENTRANT);
tjd6.connecteSortantBisAVoie(croisement1, ENTRANT_BIS);
voie18.connecteSortantAVoie(tjd10, ENTRANT_BIS);
croisement1.connecteSortantAVoie(tjd10, ENTRANT);
tjd10.connecteSortantAVoie(voie25, ENTRANT);
tjd10.connecteSortantBisAVoie(voieGarage8, SORTANT);
voieLibre6.connecteSortantAVoie(aiguille3, SORTANT_DROIT);
voie5.connecteSortantAVoie(aiguille3, SORTANT_DEVIE);
aiguille3.connecteEntrantAVoie(aiguille4, ENTRANT);
aiguille4.connecteSortantDroitAVoie(voie9, ENTRANT);
aiguille4.connecteSortantDevieAVoie(voie10, ENTRANT);
voie9.connecteSortantAVoie(tjd5, ENTRANT_BIS);
voie14.connecteSortantAVoie(tjd5, ENTRANT);
tjd5.connecteSortantAVoie(croisement1, ENTRANT);
tjd5.connecteSortantBisAVoie(voie17, ENTRANT);
voie17.connecteSortantAVoie(tjd9, ENTRANT);
croisement1.connecteSortantBisAVoie(tjd9, ENTRANT_BIS);
tjd9.connecteSortantAVoie(voie24, ENTRANT);
tjd9.connecteSortantBisAVoie(voie23, ENTRANT);
voie24.connecteSortantAVoie(aiguille9, SORTANT_DROIT);
voie36.connecteSortantAVoie(aiguille9, SORTANT_DEVIE);
aiguille9.connecteEntrantAVoie(voieGarage9, SORTANT);
voieGarage0.connecteAVoie(aiguille1, ENTRANT);
aiguille1.connecteSortantDroitAVoie(voie5, ENTRANT);
aiguille1.connecteSortantDevieAVoie(voie4, ENTRANT);
voieGarage1.connecteAVoie(aiguille2, SORTANT_DEVIE);
voie4.connecteSortantAVoie(aiguille2, SORTANT_DROIT);
aiguille2.connecteEntrantAVoie(voie7, ENTRANT);
voie7.connecteSortantAVoie(aiguille5, ENTRANT);
aiguille5.connecteSortantDevieAVoie(voieLibre9, ENTRANT);
aiguille5.connecteSortantDroitAVoie(aiguille6, ENTRANT);
aiguille6.connecteSortantDroitAVoie(voieLibre8, ENTRANT);
aiguille6.connecteSortantDevieAVoie(aiguille7, ENTRANT);
aiguille7.connecteSortantDroitAVoie(voie14, ENTRANT);
aiguille7.connecteSortantDevieAVoie(voie13, ENTRANT);
voie13.connecteSortantAVoie(tjd13, ENTRANT);
voie23.connecteSortantAVoie(tjd13, ENTRANT_BIS);
tjd13.connecteSortantAVoie(voie36, ENTRANT);
tjd13.connecteSortantBisAVoie(voie35, ENTRANT);
voie35.connecteSortantAVoie(aiguille13, ENTRANT);
aiguille13.connecteSortantDroitAVoie(voieGarage10, SORTANT);
aiguille13.connecteSortantDevieAVoie(voieLibre7, ENTRANT);
Je vous livre le sketch complet avec la recherche de deux chemins. Je n'ai pas tout testé, je viens de le terminer. Il peut être modifié pour ajouter des requêtes de chemin. Pour l'instant l'algorithme ne cherche qu'un seul chemin. Je vais rajouter la recherche de tous les chemins possibles, le calcul de l'intersection des chemins et donc l'établissement de plusieurs chemins simultanément.
Ça tourne sur un Uno en bouffant 33% de la flash et 52% de la SRAM
1121
Modélisation, Architectures logicielles et matérielles / Modélisation logicielle d'un réseau - le système de Jean-Luc
« le: mars 07, 2016, 05:58:11 pm »
Bonjour,
Ma petite contribution à la modélisation.
Ayant travaillé sur l'approche objet pour la gestion d'un gare cachée, les articles sont en attente de publication, j'ai fait des classes pour chaque type de voie : aiguille, voie d'extrémité de la gare et voie en gare. Les classes en question sont instanciées et les objets sont connectés pour former un graphe. Une recherche de chemin est ensuite faite pour trouver une voie libre ou pour relier l'entrée à une voie ou bien une voie à la sortie. Le défaut est que le graphe est orienté ce qui fait qu'un aiguillage va connaître les voies en aval mais pas en amont. Donc partant de l'entrée, on trouve une voie en gare, idem partant de la sortie mais on ne trouve pas un chemin de l'entrée vers la sortie par exemple.
Titillé par DDEFF, j'ai généralisé l'idée à un graphe où chaque nœud (bout de voie) connaît ses voisins. Comme exemple, j'ai choisi la gare de DDEFF que j'ai re-dessinnée en PECO code 55 (gare dont on peut déduire deux choses d'ailleurs : 1) Ça va coûté un bras à DDEFF, rien qu'en appareils de voie, il y en a pour 1300€, 2) DDEFF a de la place, la gare fait 4,2m de long. Bref je suis jaloux !)
Je vous mets le lien vers le PDF : La gare de DDEFF en PDF
J'ai donc défini une classe abstraite de base, Voie :
Une voie a : 1) un identifiant, 2) une direction. On l'instancie en lui donnant un identifiant et par défaut il n'y a pas de direction fixée. La direction est fixée plus tard lorsque le graphe est construit.
connecteDeVoie permet d'établir une connexion entre deux voies, j'explique ci-dessous. creeCheminVers permet de trouver un chemin entre deux nœuds du graphe (entre deux bout de voies) en suivant une direction.
Ensuite, j'ai 5 classes :
1) les voies de garage qui n'ont qu'un seul connecteur : SORTANT
2) les voies normales qui ont 2 connecteurs : ENTRANT et SORTANT
3) les aiguillages qui ont 3 connecteurs : ENTRANT, SORTANT_DROIT et SORTANT_DEVIE
4) les traversées de jonction double (on peut ajouter également les simples) qui ont 4 connecteurs : ENTRANT, SORTANT, ENTRANT_BIS et SORTANT_BIS
5) les croisement qui ont également 4 connecteurs
Un sens normal de parcours est également défini : de entrant vers sortant.
Ma petite contribution à la modélisation.
Ayant travaillé sur l'approche objet pour la gestion d'un gare cachée, les articles sont en attente de publication, j'ai fait des classes pour chaque type de voie : aiguille, voie d'extrémité de la gare et voie en gare. Les classes en question sont instanciées et les objets sont connectés pour former un graphe. Une recherche de chemin est ensuite faite pour trouver une voie libre ou pour relier l'entrée à une voie ou bien une voie à la sortie. Le défaut est que le graphe est orienté ce qui fait qu'un aiguillage va connaître les voies en aval mais pas en amont. Donc partant de l'entrée, on trouve une voie en gare, idem partant de la sortie mais on ne trouve pas un chemin de l'entrée vers la sortie par exemple.
Titillé par DDEFF, j'ai généralisé l'idée à un graphe où chaque nœud (bout de voie) connaît ses voisins. Comme exemple, j'ai choisi la gare de DDEFF que j'ai re-dessinnée en PECO code 55 (gare dont on peut déduire deux choses d'ailleurs : 1) Ça va coûté un bras à DDEFF, rien qu'en appareils de voie, il y en a pour 1300€, 2) DDEFF a de la place, la gare fait 4,2m de long. Bref je suis jaloux !
)Je vous mets le lien vers le PDF : La gare de DDEFF en PDF
J'ai donc défini une classe abstraite de base, Voie :
Code: [Sélectionner]
class Voie
{
private:
byte mIdentifiant;
byte mDirection;
protected:
void fixeDirection(byte dir);
public:
Voie(byte identifiant) { mIdentifiant = identifiant; mDirection = AUCUNE_DIRECTION; }
byte idVoie() { return mIdentifiant; }
byte direction() { return mDirection; }
virtual void connecteDeVoie(Voie *voie, byte connecteur) = 0;
virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL) = 0;
};
Une voie a : 1) un identifiant, 2) une direction. On l'instancie en lui donnant un identifiant et par défaut il n'y a pas de direction fixée. La direction est fixée plus tard lorsque le graphe est construit.
connecteDeVoie permet d'établir une connexion entre deux voies, j'explique ci-dessous. creeCheminVers permet de trouver un chemin entre deux nœuds du graphe (entre deux bout de voies) en suivant une direction.
Ensuite, j'ai 5 classes :
1) les voies de garage qui n'ont qu'un seul connecteur : SORTANT
2) les voies normales qui ont 2 connecteurs : ENTRANT et SORTANT
3) les aiguillages qui ont 3 connecteurs : ENTRANT, SORTANT_DROIT et SORTANT_DEVIE
4) les traversées de jonction double (on peut ajouter également les simples) qui ont 4 connecteurs : ENTRANT, SORTANT, ENTRANT_BIS et SORTANT_BIS
5) les croisement qui ont également 4 connecteurs
Un sens normal de parcours est également défini : de entrant vers sortant.
1122
Bibliothèques / Re : Souris DCC
« le: mars 06, 2016, 09:00:02 am »
La bibliothèque de Nicolas s'occupe du protocole XPressNet. Elle n'est donc pas limitée aux aiguillages.
1123
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: mars 05, 2016, 10:13:27 am »
Pour l'envoi des cartes, je vais utiliser une lettre suivie en prêt à poster. Une carte pèse 16g selon ma balance de ménage. Il y aura également quelques composants car, par exemple, pour la résistance R12 c'est 100 exemplaires minimum (3 centimes pièce). Les frais d'envoi se montent donc à 2,40€ si le tout tient en 50g (c'est probablement le cas), 3,06€ si c'est plus lourd.
Chaque carte revient à 1,5€ et pour les composants que j'ai en rab, ça sera moins de 1€
Envoyez moi en MP la quantité désirée et votre adresse postale ainsi que les composants que vous voulez monter. Je répondrai avec la somme exacte et mon adresse mail pour Paypal
Chaque carte revient à 1,5€ et pour les composants que j'ai en rab, ça sera moins de 1€
Envoyez moi en MP la quantité désirée et votre adresse postale ainsi que les composants que vous voulez monter. Je répondrai avec la somme exacte et mon adresse mail pour Paypal
1124
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: mars 05, 2016, 09:47:59 am »
Bonjour,
Je suis en attente de composants pour monter une carte. Je devrais les avoir lundi ou mardi.
Quelques infos sur le montage. Comme ils y a deux interfaces, CAN et DCC, tous les composants ne sont pas à monter selon les besoins.
Sur la figure suivante, j'ai colorié les composant par rôle :
Jaune : CAN
Bleu : DCC
Rose : ACK DCC
Vert : Contacts de fin de course
Bleu ciel : Connecteur I2C
Concernant le connecteur I2C, les deux résistances vertes doivent être montées si il est utilisé (Pullup I2C)
Concernant les connecteurs pour les servos. J'ai prévu des connecteurs 5 broches au pas de 2,54mm : 1 pour le signal de commande, 2 pour l'alimentation, 2 pour les contacts de fin de course. Si les contacts de fin de course ne sont pas employés, on peut souder un connecteur 3 broches type barre de broches mais il n'y aura pas de détrompeur. L'alimentation est sur les broches du haut. Donc à adapter également selon les besoins.
PS: Merci les gars
Je suis en attente de composants pour monter une carte. Je devrais les avoir lundi ou mardi.
Quelques infos sur le montage. Comme ils y a deux interfaces, CAN et DCC, tous les composants ne sont pas à monter selon les besoins.
Sur la figure suivante, j'ai colorié les composant par rôle :
Jaune : CAN
Bleu : DCC
Rose : ACK DCC
Vert : Contacts de fin de course
Bleu ciel : Connecteur I2C
Concernant le connecteur I2C, les deux résistances vertes doivent être montées si il est utilisé (Pullup I2C)
Concernant les connecteurs pour les servos. J'ai prévu des connecteurs 5 broches au pas de 2,54mm : 1 pour le signal de commande, 2 pour l'alimentation, 2 pour les contacts de fin de course. Si les contacts de fin de course ne sont pas employés, on peut souder un connecteur 3 broches type barre de broches mais il n'y aura pas de détrompeur. L'alimentation est sur les broches du haut. Donc à adapter également selon les besoins.
PS: Merci les gars
1125
Débuter / Re : Impossible trouver driver pour nano V3.0
« le: mars 04, 2016, 08:59:30 pm »
C'est avec plaisir Sergio