Messages

316

Discussions ouvertes / Re : Locoduino à Orleans

« le: novembre 12, 2018, 09:46:40 am »

Oui, une journée et demi pour moi, avec une pleine brassée de motivation, d'encouragements, de remerciements aussi. Ce genre d'événements, qui plus est partagé avec des amis, reboost pour repartir 'au boulot' plein d'entrain et de bonne volonté !
C'était effectivement un plaisir de pouvoir enfin mettre un visage devant un pseudo ou un prénom, et de pouvoir échanger de vive voix avec vous.  Enfin passer tout un week end ou presque à tenter de partager notre passion commune, c'est un gros kif comme disent les jeunes.

Les démonstrations prenaient toujours le même chemin:

- Émerveillement : l'explication de ce que sont capables de faire nos montages...
- Surprise: On ne vend rien chez Locoduino !
- Abattement: Il faut tout faire vous même.
- Joie mesurée: On est tous là pour vous aider
- Franche joie: et tout ça ne coûte qu'une fraction du matériel du commerce équivalent !   

Au delà de l'événement en lui-même, il va être temps pour nous de tirer les enseignements de ce salon, pour la publication de nouveaux articles, pour les solutions à mettre en place pour faciliter l'accès a nos montages, pour l'avenir du site et surtout pour nous améliorer encore et toujours.

Donc restez à l'écoute sur le forum, et guettez les nouveaux articles qui vont reprendre un rythme de publication plus important après la pause d'Orléans. Et h'hésitez pas à porter la bonne parole comme nous avons tenté de le faire pendant deux jours.

 

317

Présentez vous ! / Re : nouveau dans le monde arduino

« le: novembre 09, 2018, 09:48:35 pm »

Bienvenue parmi nous. Le forum est calme parce que nous préparons activement le salon d'Orléans de ce week end, mais nul doute que les messages reprendront leur rythme habituel dès la semaine prochaine.
En tout cas, n'hésitez pas à nous montrer votre travail, nous détailler vos projets et à nous poser des questions si besoin !

318

Vos projets / Re : gestion PN par infrarouge

« le: novembre 06, 2018, 11:38:28 am »

A noter que point n'est besoin de passer par GitHub pour récupérer nos plus célèbres bibliothèques : le gestionnaire de bibliothèque de l'IDE Arduino les connait et les installe plus simplement !

319

Bus DCC / Re : Perte des fonctions

« le: octobre 31, 2018, 01:45:32 pm »

Malheureusement, il n'y a pas de doc très claire sur le sujet. Par contre ce n'est pas très compliqué. Sur une config normale, il y a douze registres permis, de 0 à 11. Un registre, c'est juste une commande DCC prête à être envoyée. On a donc dans le logiciel une liste de 12 commandes DCC.

- Le registre 0 ne concerne que les ordres transitoires : fonctions, réglage CV, accessoires.
- Les autres, 1 à 10, répètent simplement inlassablement leur contenu sur la ligne DCC.

A charge pour celui qui utilise DCC++ de gérer lui-même l'affectation d'un registre à une loco particulière, ou à la répétition d'autre chose, comme les fonctions d'une loco. J'avais par exemple envisagé de pouvoir gérer cinq locos, avec les registres impair pour la vitesse (1, 3, 5, 7, 9) et les pairs pour les fonctions (2, 4, 6, 8, 10), le 0 restant pour les accessoires. Ce n'est qu'une affaire de convention, DCC++ ne décide de rien, juste de répéter ou pas les commandes selon le registre.

320

Bus DCC / Re : Perte des fonctions

« le: octobre 31, 2018, 11:58:44 am »

Bonjour

Dans cette fonction, le 1 est effectivement le numéro de registre. Mais comme je le disais précédemment c'est plutôt le 0 qui devrait être utilisé ici, parce que le 1 est probablement utilisé par une machine pour sa vitesse, ce qui signifie qu'au lieu de répéter la vitesse comme c'est la norme, on répète l'état des fonctions ! Le 13 est l'adresse DCC de la loco, et gLocoFonction est une structure qui connait l'état de l'ensemble des fonctions d'une loco. En effet, le DCC ne permet pas d'activer les fonctions une par une. A la place il faut envoyer l'état voulu par groupes de quatre, ce qui fait que l'on doit se souvenir de l'état des autres fonctions du groupe à chaque envoi...
Accessoirement, il faudra que je change l'aide de la fonction qui dit de ne pas utiliser le registre 0...

321

Bus DCC / Re : Perte des fonctions

« le: octobre 29, 2018, 03:35:44 pm »

Pourquoi pas toutes les cinq secondes, mais il faut le faire pour toutes les machines qui sont pilotées en vitesse par ailleurs.
Le nombre de machines pilotables est limité par le nombre de registres de répétition de commande DCC utilisés par DCC++. La version de Greeg déclare 12 registres par défaut, un pour les ordres temporaires comme les fonctions, l'interrogation de CVs ou la commande d'accessoires, 11 pour les ordres répétitifs comme la vitesse d'une machine. C'est un moyen terme entre un Nano limité par sa mémoire et un Mega moins limité. Dans DcDccNanoController, j'ai limité à beaucoup moins puisque le but n'est que de piloter une machine. Et puis moins de canaux, c'est moins de mémoire utilisée !

322

Bus DCC / Re : Perte des fonctions

« le: octobre 29, 2018, 10:19:07 am »

La non répétition des fonctions fait partie de la norme DCC, la conservation de cette info est à la charge des décodeurs pour des micro-coupures. Malheureusement, si la machine n'est pas équipée avec des condensateurs, dès que l'on 'plante un choux' l'info est perdue.

La solution de renvoyer périodiquement les fonctions est possible, le problème est d'identifier le bon moment...

L'autre solution me parait pourtant acceptable. Utiliser deux registres par machine, avec un registre pour la vitesse et l'autre pour les fonctions, ça marche. Par contre il faut supporter de n'avoir que six machines à piloter.  C'est la stratégie que j'ai employée dans DcDccNanoController, sachant que c'est fait pour un Nano et donc pour une toute petite centrale.

323

Vos projets / Re : Réalisation de carte pour compléter le shield ATTiny

« le: octobre 24, 2018, 12:06:15 pm »

Merci, c'est bien ce que je pensais. Mais tu sais tout le monde ne lit pas la schématique dans le texte aussi facilement que vous. Je m'améliore, mais j'ai encore des progrès à faire...

324

Bus DCC / Re : Nouvelle souris sans fil à mémoire

« le: octobre 24, 2018, 09:14:25 am »

Oui, ce type de tri va plus vite, mais il prend un peu plus de mémoire programme (on est déjà à 98%!) et la vitesse ne semble pas le critère déterminant.

325

Vos projets / Re : Réalisation de carte pour compléter le shield ATTiny

« le: octobre 23, 2018, 09:10:23 pm »

Petite question sur le programmateur. Comment insérer un atTiny85 dans son support ? Le point vers le levier ? C'est le seul point de repère que j'ai...

326

Bus DCC / Re : Nouvelle souris sans fil à mémoire

« le: octobre 18, 2018, 09:21:54 am »

De rien.

Pour aller un peu plus loin et faire profiter tout le monde, voici un bout de code pour expliquer:

On commence par déclarer une liste, et la remplir avec un numéro croissant:

Code: [Sélectionner]

byte listeTriee[255];

for (int i = 0; i < 255; i++)
listeTriee[i] = i;

On a ainsi la liste des locos non triée, désignée par leur position dans l'EEPROM.
Puis on réalise le tri proprement dit par la méthode dite du tri à bulle: (https://fr.wikipedia.org/wiki/Tri_%C3%A0_bulles)

Code: [Sélectionner]

for (int i = 255 - 2; i >= 0; i--)
{
for (int j = 0; j <= i; j++)
{
if (loco[listeTriee[j+1]].adresse < loco[listeTriee[j]].adresse)
{
byte t = listeTriee[j + 1];
listeTriee[j + 1] = listeTriee[j];
listeTriee[j] = t;
}
}
}

Si l'ordre entre deux locos n'est pas le bon, on échange simplement les octets de la liste triée.
Pour tester sur le nom ou autre chose, il suffit de remplacer le '.adresse' par autre chose. Pour trier dans l'ordre inverse, changer le '<' par un '>' !
Je n'ai ni compilé ni testé ce code...

327

Bus DCC / Re : Nouvelle souris sans fil à mémoire

« le: octobre 17, 2018, 05:02:43 pm »

Un autre moyen est de créer une liste d'entiers ou d'octets (si on se limite à 255 machines maxi) qui représente la liste triée des locos présentes en EEPROM. Il "suffit" de créer cette liste au démarrage une fois pour toutes. L'autre solution si l'on veut éviter d'utiliser de la mémoire centrale ou de la mémoire programme est de créer cette liste directement en mémoire EEPROM grâce à un autre programme sur Arduino ou sur ordinateur, et de mettre ces 255 octets dès le début de l'EEPROM, avant les locos. Pour atteindre une loco, une simple indirection suffit : je veux la loco 3 dans l'ordre, je lis l'octet 3 de la liste qui me dit c'est l'enregistrement EEPROM 17, je lis la loco à l'emplacement 17 !

328

Bus DCC / Re : Re : Fonctions DCC de 21 à 28

« le: octobre 11, 2018, 03:03:20 pm »

1 ou -1 that is the question. Je passerai par des essais, merci pour ta réponse claire sur les pas.

Sans vouloir fâcher qui que ce soit, c'est tout vu ! N'oublions pas que l'on parle d'arguments passés en DCC sous forme de bits. Or lorsqu'on parle de -1 sur un champs de bit qui n'a pas de signe comme ici, dire -1 revient à mettre tous les bits à 1 ! En clair si tu mets -1 tu iras à fond !

329

Bus DCC / Re : Fonctions DCC de 21 à 28

« le: octobre 11, 2018, 03:00:34 pm »

La réponse est visible à deux endroits : le fichier include concernant le type utilisé, ici un RegisterList puisque tu utilises DCCpp::progRegs, c'est à dire en clair PacketRegister.h . Si tu cherches readCV() tu verras que le type de retour est fixé à 'int'. writeCVByte() et assimilés n'ont pas de valeur de retour : 'void' pour vide en Français. Donc tu ne peux pas récupérer d'information suite à l'écriture. C'est conforme à l'implémentation originale de DCC++ par Gregg .
L'autre endroit, c'est la documentation livrée avec la bibliothèque, visible depuis son répertoire 'extras' en cliquant sur le fichier index.html , toujours en cherchant RegisterList et writeCVByte().
Enfin, il n'y a que très peu de besoins justifiants de passer par autre chose que les fonctions de DCCpp, et ton utilisation n'en fait pas partie. Ce n'est pas faux, mais DCCpp est justement là pour masquer la complexité de ce qu'il y a derrière. Tu devrais utiliser DCCpp::readCVProg() et DCCpp::writeCVProg() ...

330

Bus DCC / Re : Fonctions DCC de 21 à 28

« le: octobre 11, 2018, 10:50:34 am »

Pour être plus précis, il faut se référer à la norme NMRA https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf qui définit les valeurs possibles pour la vitesse. Extraits :

Mode 14 pas de vitesse:

In this mode, Speed U0000 is stop, speed U0001 is emergency stop, speed U0010 is the
first speed step and speed U1111 is full speed. This provides 14 discrete speed steps in each direction.
250 If a decoder receives a new speed step that is within one step of current speed step, the Digital Decoder may select a
step half way between these two speed steps. This provides the potential to control 56 speed steps should the
command station alternate speed packets.

Mode 128 pas

CCCCC = 11111: 128 Speed Step Control - Instruction "11111" is used to send one of 126 Digital Decoder speed
steps. The subsequent single byte shall define speed and direction with bit 7 being direction ("1" is forward and "0"
is reverse) and the remaining bits used to indicate speed. The most significant speed bit is bit 6. A data-byte value
of U0000000 is used for stop, and a data-byte value of U0000001 is used for emergency stop. This allows up to 126
210 speed steps.

Il me semble que dans tous les cas, 0 signifie vitesse 0 donc arrêt normal, 1 impose un arrêt immédiat à l'engin moteur concerné, et le reste donne les différents crans de vitesse.