/*
* Programme pour arduino Nano ou Uno : à préciser
* par LLG Juin2018 V0.2
* Licence GNU GPLv3 - Version IDE 1.8.5
*
* Ce programme fait fonctionner des feux Warning sur un véhicule HO, plus 3 options (a ecrire)
* option 1 : gestion d'1 ampoule HS : a ecrire
* option 2 : cycle du warning de type "SOS" : a ecrire
* option 3 : liaison et pilotage du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
* 4 LED (oranges ou rouges) sont reliees aux sorties 4 a 7
* Les sorties 4 a 7 sont indépendantes, afin de simuler eventuellement (en option # 1) une ampoule cassée
*/
// Initialisation des variables
const byte AVD = 4 ; // cligno AVD
const byte AVG = 5 ; // cligno AVG
const byte ARD = 6 ; // cligno ARD
const byte ARG = 7 ; // cligno ARG
const byte TOUS = 7 ; // les 4 clignos ensemble
//Delai du Warning normal : duree on = off, rythme d'environ 1/2 seconde
const long TempsON = 500;
const long TempsOFF = 500;
// a completer pour l'option SOS (cf Titanic) et la condition IF, si decodeur DCC installe : ??
// Initialisation des lignes 4 a 7 en sortie
void setup () {
pinMode (AVD, OUTPUT) ;
pinMode (AVG, OUTPUT) ;
pinMode (ARD, OUTPUT) ;
pinMode (ARG, OUTPUT) ;
}
// Fonction loop
void loop () {
// Extinction de toutes les LED au depart
digitalWrite (AVD, LOW) ;
digitalWrite (AVG, LOW) ;
digitalWrite (ARD, LOW) ;
digitalWrite (ARG, LOW) ;
// Allumage des leds, en meme temps
digitalWrite (AVD, HIGH) ;
digitalWrite (AVG, HIGH) ;
digitalWrite (ARD, HIGH) ;
digitalWrite (ARG, HIGH) ;
// Debut de cycle 0 : mode warning Normal
delay (TempsON) ; // 4 Feux allumes
digitalWrite (AVD, LOW) ; // Extinction AVD
digitalWrite (AVG, LOW) ; // Extinction AVG
digitalWrite (ARD, LOW) ; // Extinction ARD
digitalWrite (ARG, LOW) ; // Extinction ARG
delay (TempsOFF) ; // 4 feux eteints
// et on boucle, jusqu'à la décision d'extinction DCC
// option 1 : gestion d'1 ampoule HS : a ecrire
// option 2 : cycle du warning de type "SOS" : a ecrire
// option 3 : liaison et pilotage du warning par un decodeur d'accessoires 4 fonctions DCC : a ecrire
}
/* warning sur rythme SOS : à ré-ecrire , copie du SOS Titanic
//
void loop() {
digitalWrite(pinLED, HIGH) ; // allumage du S = 3 fois point, avec delai entre chaque allumage
delay (point) ; // durée d'allumage de la led
digitalWrite (pinLED, LOW) ; // extinction
delay (interPointTrait) ; // attente
digitalWrite(pinLED, HIGH) ;
delay (point) ;
digitalWrite (pinLED, LOW) ;
delay (interPointTrait) ;
digitalWrite(pinLED, HIGH) ;
delay (point) ;
digitalWrite (pinLED, LOW) ;
delay (interPointTrait) ;
// fin du 1er "S"
delay (interlettres) ; // delai entre 2 lettres
// on allume pour le "O" : 3 fois trait de 0,6 s
digitalWrite(pinLED, HIGH) ;
delay (trait) ;
digitalWrite(pinLED, LOW) ;
delay (interPointTrait) ;
digitalWrite(pinLED, HIGH) ;
delay (trait) ;
digitalWrite(pinLED, LOW) ;
delay (interPointTrait) ;
digitalWrite(pinLED, HIGH) ;
delay (trait) ;
digitalWrite(pinLED, LOW) ;
// delay (interPointTrait);
// pause entre 2 lettres :
delay (interlettres) ;
// on allume le 2é S (recopie de la premiére fois)
digitalWrite(pinLED, HIGH) ; // allumage du S = 3 points, avec delai entre chaque allumage
delay (point) ;
digitalWrite (pinLED, LOW) ;
delay (interPointTrait) ;
digitalWrite(pinLED, HIGH) ;
delay (point) ;
digitalWrite (pinLED, LOW) ;
delay (interPointTrait) ;
digitalWrite(pinLED, HIGH) ;
delay (point) ;
digitalWrite (pinLED, LOW) ;
//delay (interPointTrait);
// fin du 2é "S"
// on attend entre 2 SOS
delay (entre2sos) ;
}
*/
PORTD |= 0xF0;
PORTD &= ~0xF0;
for (byte broche = 4; broche < 8; broche++) digitalWrite(broche, HIGH);
void clignotant(byte etat)
{
for (byte broche = 4; broche < 8; broche++) digitalWrite(broche, etat);
}
clignotant(HIGH);
delay(2000);
clignotant(LOW);
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" : ?
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 ?
- 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
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 !le goto c'est pas structuré, ça part dans tous les sens, mais pour devenir un real programmer, lire aussi :
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
1) essaye d'aller au bout de quelque chose de plus simple d'abord (enfin c'est mon conseil) parce que là tu complexifies au fur et à mesure : tu allonge le chemin sans le parcourir> oui, j'en suis conscient : quasi chaque matin je me réveille avec une nouvelle option :) ... ça augmente donc la "densité" du futur prog, mais ça m'oblige aussi à réfléchir sur les différents moyens pour la future mise en oeuvre, et donc de la future programmation ...
const byte pin[] = {4, 5, 6, 7}; // création du tbl pour les 4 Pin des clignotants - Attention Index du 4 = 0
// à ajuster au total des 12 sorties / leds utilisées > TODO : sélectionner les 12 Pin
void setup () {
for (int i = 0 ; i < 5 ; i++) { // 5 car 4 leds utilisées dans cet ex
pinMode (pin[i] , OUTPUT) ; // les 4 leds sont déclarées en même temps en sortie
digitalWrite (pin[i] , LOW) ; // on éteint ttes les leds avant de commencer une sélection au clavier
} // fin de la boucle FOR
}
Bonjour,
Oui, voir ici : http://modelleisenbahn.triskell.org/spip.php?article90
... ça va coincer au niveau du nombre de broches ...
onc il y aura autant de IF que de choix possibles au clavier : ??
Citerdonc il y aura autant de IF que de choix possibles au clavier : ??
Il faut utiliser le switch case dans ce cas !
Bonjour,
...
2) Plutôt un switch ... case qu'une séquence de if ... else if ...
3) Pour gérer beaucoup de LED il y a le charlieplexing
Tu affectes une variables "niveau_son" à la détection de "*"
A chaque appui sur * tu incrémentes "niveau_son" : 1, puis 2, puis 3, puis 0, puis 1, etc..
et tu modifies le niveau du son évidemment.
[/u]sur la gestion du SON :
> avec le module "carte SD" faut-il utiliser un ampli ? (qui serait alors "piloté" par "niveau_son" ?, mais son potar d'ampli ?)
ex : https://fr.aliexpress.com/item/PAM8406-Digital-Class-D-Stereo-Audio-Amplifier-Board-2-Channel-6W-2-AMP-Board/32665965317.html?spm=a2g0s.8937460.0.0.5cbd2e0eRLBpHA (https://fr.aliexpress.com/item/PAM8406-Digital-Class-D-Stereo-Audio-Amplifier-Board-2-Channel-6W-2-AMP-Board/32665965317.html?spm=a2g0s.8937460.0.0.5cbd2e0eRLBpHA)
??
(l'idée étant d'adapter la sortie sonore à l'environnement - imaginons cette mini animation dans une expo...)
J’ai pourtant été clair :
...
> ma réponse est : NON
ce n'est pas clair.
niveau_son ++;
if (niveau_son > 3) niveau_son = 0;-tester si un caractère reçu est « * » ?... une résistance de tirage, un condo de filtrage, une liste chaînée ou une fonction récursive, ça ne parle pas forcément à tout le monde !
> pour les curieux : propositions de lecture ...
- Waterfall : https://www.planzone.fr/blog/quest-ce-q ... -waterfall
n'aurais-tu pas raté une vocation ?