Parlons Arduino > Vos projets
Warning dans véhicule HO / animation de décor réseau
Jean-Luc:
Bonjour,
--- Citation de: BB9004 le juin 02, 2018, 09:06:56 am ---Dans le prog "Warning", je m'interroge sur la logique de gestion des entrées : vos avis seraient utiles ...
Q1 : il y a un choix multiples d’entrées, la majorité est exclusive ("OU") (1 entrée = 1 seule action de sortie), mais il y aura éventuellement 1 entrée = 2- ou 3 - actions/sorties simultanées ("ET")
(ex : warning + phares allumés) et même "warning + phares + éclairage cabine" : possible ?
> est-ce le moment de s’intéresser aux bibliothèques, afin de ne pas ré-écrire ces sous-ensemble à chaque fois ?
>> les choix potentiels actuels :
* option 1 : warning normal : rédigé : à tester
* option 2 : cycle du warning de type "SOS" : rédigé : a tester
* option 3 : gestion d'1 ampoule HS : rédigé : a tester
* option 4 : liaison et pilotage du choix du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
* option 5 : allumage des phares seuls : a ecrire
* option 6 : allumage des phares ET du warning normal : a ecrire
* option 7 : éclairage de la cabine du véhicule : a ecrire
Q2 > si la sélection en entrée se fait par un bouton rotatif sur TCO : le "pôle" choisi alimentera une SEULE Pin dédiée, en entrée, qui, elle, conditionnera la Pin de sortie : possible ?
>nota : cette option semble empêcher les choix "ET" : ?
Q3 > si la sélection en entrée se fait par différents boutons sur le TCO : risque de superposition des choix si on oublie, par fonction, "d'éteindre" l'ensemble avant de lancer la fonction choisie
> petit inconvénient : plus de cablage sur le TCO
> avantage : devrait permettre les choix "ET" : ?
--- Fin de citation ---
Je vais faire une seule réponse à toutes :
Peu importe ces choix du point de vue fonctionnel puisqu'au bout du compte le programme décidera de la combinaison d'entrées qui sont valides. Je ne pense pas qu'il y ai besoin de bibliothèques.
La question est plutôt de savoir si l'utilisateur a besoin d'une information retour sur le TCO ou pas ? Observer le véhicule suffit-il ou non ?
Si la réponse est non, il ne suffit pas d'observer le véhicule, alors deux options :
* commutateur qui fournit un retour physique
* affichage géré par le programme (LEDs, LCD)
Dans le premier cas, tu as le choix entre un commutateur à l'ancienne qui nécessite autant de sorties (fils) que de fonctions ou bien un codeur qui sort l'information codée en binaire (16 positions/fonctions = 4 fils par exemple) :
Comme tu l'as souligné, ne permet pas à priori de choisir une option mais on peut aussi décider que les combinaisons valides sont prédéterminées et dans ce cas une position du bouton leur est affectée.
Dans le second cas, une paire de boutons poussoir et des LED font l'affaire.
Si observer le véhicule suffit, une paire de poussoir fait l'affaire. Après tout, les LED dans le véhicule peuvent servir à renseigner sur l'option sélectionnée. Par exemple 3 flash rapide pour signaler qu'on passe en DCC.
--- Citer ---Q4 > si la sélection se fait par décodeur DCC (je n'ai pas encore étudié les possibilités du décodeur Locoduino, que j'envisage de mettre en oeuvre), le nombre de choix possibles sera limité au nombre de possibilités de fonction de ce décodeur .
L'idée est d'associer 1 choix "warning" à une fonction DCC : réaliste ?
--- Fin de citation ---
Là je pense que tu es large
--- Citer ---- Autres questions, concernant les "loop" :
L1 : peut-on conditionner leur "lancement" par un "index" ?
> genre : IF xx= YY, alors GOTO loop1, sinon goto loop2, etc ... : possible ?
L2 : peut-on avoir plusieurs loop dans un même programme ?
si oui, comment les gere-t-on ?
le IF le permet-il ? (si le "goto" est impossible)
Merci de vos conseils, bonne journée à tous
--- Fin de citation ---
Les GOTO c'est mal.
Il n'y a qu'une loop, mais tu peux mettre chacune des options dans une fonction et, dans loop, appeler la fonction correspondant à l'option sélectionnée.
BB9004:
Merci again !
je digère tout ça (j'essaie de comprendre et de mettre en oeuvre) ...
Quand tu écris, pour l'option DCC : "tu es large" : que veux tu dire ?
(j'imaginais que le DCC supprimerait du cablage au TCO, puisque piloté par une manette type roco, via la centrale DCC)
ps : le "goto c'est mal " m'a bien fait rire, sans en comprendre la raison !
Jean-Luc:
--- Citation de: BB9004 le juin 02, 2018, 10:00:34 am ---Quand tu écris, pour l'option DCC : "tu es large" : que veux tu dire ?
(j'imaginais que le DCC supprimerait du cablage au TCO, puisque piloté par une manette type roco, via la centrale DCC)
--- Fin de citation ---
Je veux dire que tu as un choix beaucoup plus large de valeurs envoyées via une trame DCC. Au programme d'en déduire l'option.
msport:
--- Citation de: BB9004 le juin 02, 2018, 10:00:34 am ---ps : le "goto c'est mal " m'a bien fait rire, sans en comprendre la raison !
--- Fin de citation ---
le goto c'est pas structuré, ça part dans tous les sens, mais pour devenir un real programmer, lire aussi :
http://www.bernstein-plus-sons.com/RPDEQ.html
Thierry:
Je m’immisce dans la conversation...
Le GOTO représente la façon de programmer des années 80 parce qu'il n'y avait pas le choix, en assembleur ou en Basic.
Et puis sont venus les langages évolués comme le C et ses descendants qui offraient de bien meilleures possibilités de structuration du code avec les fonctions, les while(), do-while(), switch, etc... Si le GOTO reste possible et peut être justifié dans de très rares cas comme la gestion d'erreur si on ne veut pas utiliser d'interruptions, il est reconnu aujourd'hui comme un générateur du code 'spaghetti', du code qui part dans tous les sens avec une lisibilité et une maintenabilité faible.
Donc oui, je pense que le code bootloader de l'Enfer est plein de GOTOs, que celui de Trump aussi, ce qui rend sa pensée aussi volatile et imprévisible...
Le GOTO c'est LE mal !
Grillé par msport...
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique