Auteur Sujet: Un Arduino par module....ou pas.  (Lu 67036 fois)

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #45 le: février 20, 2015, 05:04:24 pm »
Ca intéresserait quelqu'un une bibliothèque permettant d'ordonnancer des appels de fonction à des intervalles dans le temps ?
Cordialement

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #46 le: février 21, 2015, 06:56:51 pm »
tu veux dire de gerer une timeline avec des analogWrite qui se chevauchent?
Moi, je serais bigrement intéressé....

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #47 le: février 22, 2015, 09:22:46 am »
Ok, je m'occupe de ça :)
Cordialement

fking

  • Newbie
  • *
  • Messages: 3
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #48 le: février 22, 2015, 09:57:00 am »
Et se baser sur un module RTC genre DS1307 ??? Il suffit de tester l'heure, et en fonction, de gérer les sorties.

Guillaume

  • Global Moderator
  • Full Member
  • *****
  • Messages: 204
    • Voir le profil
    • Locoduino
Re : Un Arduino par module....ou pas.
« Réponse #49 le: février 22, 2015, 11:27:49 am »
Sauf qu'un tel truc donne l'heure IRL, ici ce serait plus pour faire un cycle jour/nuit rapide un peu à la manière du wonderland d'Hamburg.
G.

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #50 le: février 22, 2015, 12:09:50 pm »
Le problème est surtout de gérer plusieurs « timelines » simultanément pas tellement d'avoir une base de temps :)
Cordialement

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #51 le: février 22, 2015, 01:31:31 pm »
Oui, je vois plus une time line ou on peut régler les " tics" et la durée.
Après des fonctions OUT digitalWrite(), analogWrite(), que l'on peut placer et paramètrer comme on veut dans la time line.
Par exemple, on passe en paramètre le tempsDébut, la DuréeMonté ou DuréeDescente, la hauteurPWM, etc...
La bibliothèque devient universelle pour un tas de cas dans les automatismes liés à notre hobby. Pour les entrées( capteurs, boutons), faudra-t-il prévoir des fonctions supplémentaires ou lier à des interruptions?

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #52 le: février 25, 2015, 06:00:13 pm »
Bonjour,

Voilà, la bibliothèque est implémentée. Il s'agit d'un implémentation des tables d'ordonnancement.

J'explique la philosophie.

Il s'agit d'ordonnancer des actions dans le temps. À cet effet on définit une période qui a une durée avec un instant initial qui est l'instant de démarrage et un instant final qui est l'instant initial + la durée. Entre cet instant initial et cet instant final, on place des actions. Une action est l'appel d'une fonction que l'utilisateur fournit. La période peut ensuite être répétée entre 1 et 65535 fois ou bien infiniment.

La bibliothèque offre une classe ScheduleTable que l'on peut instancier pour créer ces périodes où des actions sont ordonnancées. Pour déclarer une ScheduleTable, on écrit par exemple :

ScheduleTable myTable(3, 200);

Le premier argument est le nombre d'actions que peut contenir la table, ici 3. Le 2e est sa durée, ici 200. Par défaut, il s'agit de millisecondes. On peut fournir un 3e argument qui donne la base de temps. Par exemple :

ScheduleTable myTable(3, 200, 100);

précise une base de temps de 100 ms. Par conséquent 200 représente 200 x 100 ms de durée. Toutes les durées relative à myTable seront exprimées en centaines de millisecondes.

Ensuite dans setup(), on place des actions à des dates relative par rapport au début de la période. Par exemple si sur notre période de 200 unités de temps on veut placer une action à 50, 60, 120, on écrira dans setup :

myTable.at(50, action1);
myTable.at(60, action2);
myTable.at(120, action3);

action1, action2 et action3 sont des fonctions définies comme suit :

void action1()
{
    Serial.print(millis());
    Serial.println(" : action 1");
}

void action2()
{
    Serial.print(millis());
    Serial.println(" : action 2");
}

void action3()
{
    Serial.print(millis());
    Serial.println(" : action 3");
}

Il faut ensuite lancer la table on peut faire ça dans setup pour que ça soit en route pour toute l'application :

myTable.start()

Ensuite, il n'y a pas de miracle, il faut appeler répétitivement la méthode update() dans loop pour que la schedule table fonctionne :

myTable.update()

On peut également stopper une schedule table :

myTable.stop();

Je poste la bibliothèque et du code exemple plus tard
« Modifié: février 25, 2015, 06:15:14 pm par Jean-Luc »
Cordialement

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #53 le: février 25, 2015, 11:36:33 pm »
Bonsoir jean luc,
je viens de lire ton descriptif, ta bibliothèque a l'air bien alléchante et simple à prendre en main. Je ne pourrais, malheureusement, pas la tester tout de suite car je pars demain matin pour 3 semaines en Bretagne ( loin du réseau et de l'Arduino).
Je pense que tu vas faire plus d'un heureux avec ça, car beaucoup d'animations  sur les réseaux sont gérés selon ce principe...
à bientôt,

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #54 le: février 26, 2015, 02:46:16 pm »
Bonjour,

Une petite modif, la mise à jour des schedule tables se fait via une méthode de classe. Donc il suffit d'un appel pour tout mettre à jour :

  ScheduleTable::update();

Le github est ici : https://github.com/Koryphon/ScheduleTable

J'ai mis 3 exemples. Voici un exemple simple de feux tricolores utilisant les schedule table (j'ai écrit les commentaires en anglais, désolé)

/*
 * More complex example of the use of the ScheduleTable library
 *
 * This example uses 2 ScheduleTable with 3 actions each.
 * Each schedule table manages a traffic light.
 *
 * Each traffic light has a 30s period.
 * - Green light lasts for 13s
 * - Yellow light lasts for 2s
 * - Red light lasts for 15s
 * Schedule tables are shifted so that one light switches from
 * red to green when the other one shift from yellow to red.
 */

#include <ScheduleTable.h>
 
/* Both light cycle has 3 actions, lasts 30 time unit and has a 1000ms time base */
ScheduleTable firstLightCycle(3,30,1000);
ScheduleTable secondLightCycle(3,30,1000);

struct trafficLight {
  byte greenPin;
  byte yellowPin;
  byte redPin;
};

const struct trafficLight firstLight  = { 3, 4, 5 };
const struct trafficLight secondLight = { 6, 7, 8 };

enum { GREEN, YELLOW, RED };

void setLightState(const struct trafficLight& light, const byte state)
{
  digitalWrite(light.greenPin, LOW);
  digitalWrite(light.yellowPin, LOW);
  digitalWrite(light.redPin, LOW);
  switch (state) {
    case GREEN:  digitalWrite(light.greenPin, HIGH);  break;
    case YELLOW: digitalWrite(light.yellowPin, HIGH); break;
    case RED:    digitalWrite(light.redPin, HIGH);    break;
  }
}

void firstLightGreen()   { setLightState(firstLight, GREEN);   }
void firstLightYellow()  { setLightState(firstLight, YELLOW);  }
void firstLightRed()     { setLightState(firstLight, RED);     }
void secondLightGreen()  { setLightState(secondLight, GREEN);  }
void secondLightYellow() { setLightState(secondLight, YELLOW); }
void secondLightRed()    { setLightState(secondLight, RED);    }

void setup()
{
  pinMode(firstLight.greenPin,   OUTPUT);
  pinMode(firstLight.yellowPin,  OUTPUT);
  pinMode(firstLight.redPin,     OUTPUT);
  pinMode(secondLight.greenPin,  OUTPUT);
  pinMode(secondLight.yellowPin, OUTPUT);
  pinMode(secondLight.redPin,    OUTPUT);
 
  /* Green at start for first light */
  firstLightGreen();
  /* at 13s first light switches to yellow */
  firstLightCycle.at(13,firstLightYellow);
  /* at 15s, it switches to red */
  firstLightCycle.at(15,firstLightRed);
  /* at 30s, it switches back to green */
  firstLightCycle.at(30,firstLightGreen);

   /* Red at start for second light  */
  secondLightRed();
  /* at 15s, it switches to green */
  secondLightCycle.at(15,secondLightGreen);
  /* at 28s, it switches to yellow */
  secondLightCycle.at(28,secondLightYellow);
  /* at 30s, it switches to red */
  secondLightCycle.at(30,secondLightRed);
 
  /* starts both light forever */
  firstLightCycle.start();
  secondLightCycle.start();
}

void loop()
{
  /* update all the schedule tables at once */
  ScheduleTable::update();
}

Et l'exemple de la DEL verte de petitrain


/*
 * A third complex example of the use of the ScheduleTable library
 *
 * This example uses 3 ScheduleTable with 4 actions for the first one
 * and 1 action of the other two.
 *
 * The first schedule table manages the whole cyle with:
 * - a first action to start led dimming from 0 to 255
 * - a second action to start led dimming from 255 to 0
 * - a third action identical to the first one to start led dimming from 0 to 255
 * - a fourth action to start led dimming from 255 to 0 at faster pace
 *
 * The sketch is supposed to do the cycle in 24h but the execution is sped 1000 times
 * To change the speed, change the time base of each schedule table.
 */

#include <ScheduleTable.h>

/*
 * The Green LED cycles.
 */

/* 4 actions, period duration in seconds = 24h */
ScheduleTable greenLEDCycle(4,86400);
/* 1 action, period duration = 7200 / 255 = 28 */
ScheduleTable greenLEDPWMIncreaseCycle(1,28);
/* 1 action, period duration = 10800 / 255 = 42 */
ScheduleTable greenLEDPWMDecreaseCycle(1,42);

byte pwmGreenLED = 0;
byte pinGreenLED = 3;

/*
 * This function is called to start the increase of the PWM
 */
void startPWMIncrease()
{
  /* start the schedule table for 255 periods */
  greenLEDPWMIncreaseCycle.start(255);
}

/*
 * This function is called to start the decrease of the PWM
 */
void startPWMDecreaseFast()
{
  /* start the schedule table for 255 periods of 28s */
  greenLEDPWMDecreaseCycle.setPeriod(28);
  greenLEDPWMDecreaseCycle.start(255);
}

/*
 * This function is called to start the decrease of the PWM
 */
void startPWMDecreaseSlow()
{
  /* start the schedule table for 255 periods of 42s */
  greenLEDPWMDecreaseCycle.setPeriod(42);
  greenLEDPWMDecreaseCycle.start(255);
}

/*
 * This function is called to increase the PWM of the green LED
 */
void increaseGreenLEDPWM()
{
  pwmGreenLED++;
  analogWrite(pinGreenLED, pwmGreenLED);
}

/*
 * This function is called to decrease the PWM of the green LED
 */
void decreaseGreenLEDPWM()
{
  pwmGreenLED--;
  analogWrite(pinGreenLED, pwmGreenLED);
}

void setup() {
  pinMode(pinGreenLED,OUTPUT);
  pwmGreenLED = 0;
  analogWrite(pinGreenLED,pwmGreenLED);

 
  greenLEDCycle.at(27000,startPWMIncrease);     /* at 7:30 */
  greenLEDCycle.at(34200,startPWMDecreaseSlow); /* at 9:30 */
  greenLEDCycle.at(63000,startPWMIncrease);     /* at 17:30 */
  greenLEDCycle.at(75600,startPWMDecreaseFast); /* at 21:00 */
 
  greenLEDPWMIncreaseCycle.at(0,increaseGreenLEDPWM);
  greenLEDPWMDecreaseCycle.at(0,decreaseGreenLEDPWM);
 
  greenLEDCycle.start();
}

void loop() {
  // put your main code here, to run repeatedly:
  ScheduleTable::update();
}
Cordialement

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #55 le: mai 17, 2015, 11:58:21 pm »
Bonsoir à tous,
  Je reprends un peu l'Arduino et mon projet.
  J'ai relu les pages du forum, les observations et les commentaires de chacun et j'ai repensé mon projet dans ce sens :
  Je vous joints le synoptique modifié. Quelques observations explicatives:
  - Toujours une carte sous chaque module. Elle commande les différents éclairages, les aiguillages,etc...
  - L'éclairage général des modules est confié à une carte ( via des mosfets de puissance) qui gère aussi l'affichage.
  - Une carte Horloge déjà faite.
  - L'Alim est assurée par une alimentation de PC ( le 5v ne sert que pour des petits lecteurs MP3)
  - Eventuellement, je peux rajouter des cartes d'extension si le besoin de broches se fait sentir (en I2c).
 J'ai prévu quatre boutons : 2(incrémentation et decrémentation) pour sélectionner différents programmes signalés par 8 leds.
 1 bouton de validation et 1 bouton que j'appelle programmation ( j'ai imaginé pouvoir changer directement quelques variables sans passer par l'ordinateur).
  - Un Afficheur 4*20 en I2c permet d'afficher les indications et messages dont j'aurai besoin.
Avant de commencer mes cartes, j'aurai aimé avoir vos avis, voir si c'est réaliste .
 J'ai dessiné un mini sur mes cartes mais ne vaut-il pas mieux mettre un nano qui a la liaison USB ( j'en ai vu un chez Electrodragon pas très cher mais le micro-controleur n'ait pas le même que sur la carte Arduino uno,est-ce gênant?)
  J'ai testé mes boutons sur une entrée analogique, ça a l'air de bien marcher. J'ai testé aussi l'afficheur avec une bibliothèque,
l'affichage scintille... J'ai vu sur des sites qu'il faut mettre des résistances de rappel au +, je vais essayer.
  Voilà, j'arrête là mon bavardage...
Je n'arrive pas à passer mon fichier image, j'ai un message qui me dit qu'il est trop gros, pourtant il ne fait que 106k, désolé....
 

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #56 le: mai 18, 2015, 01:35:47 pm »
Voilà le croquis

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #57 le: décembre 28, 2015, 10:58:50 pm »
Bonjour,
Je sais que Jean Luc est très pris, aussi, j'espère que quelqu'un d'autre pourra répondre à mon questionnement...
Voilà, je travaille sur les "ScheduleTable". J'ai bien compris comment tout cela marchait pour des sorties digitales.
Pour les sorties PWM, on crée la Table principale(nbre d'actions,nbre de périodes), puis on crée des Tables filles pour la montée et la descente de la PWM. Pour définir le nbre de périodes, il divise la durée de montée ou de descente souhaitée par 255 ( surement la valeur max de la PWM).
On a donc:
ScheduleTable greenLEDPWMIncreaseCycle(1,28);    // 1 action, period duration = 7200 / 255 = 28
ScheduleTable greenLEDPWMDecreaseCycle(1,42);// 1 action, period duration = 10800 / 255 =42
mais, après, dans ces fonctions, il démarre ses Tables avec 255 périodes imposées. Pouquoi?
Voilà, si quelqu'un peut m'éclairer.
A part cette incompréhension, c'est un plaisir de se servir de ces tables . J'ai vu qu'on peut démarrer les Tables ailleurs que dans le setup(), il faut que j'essaye de les démarrer avec des boutons ( on pourra ainsi choisir différents choix d'animation). 
 

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #58 le: janvier 01, 2016, 07:50:11 pm »
Bonsoir et meilleurs vœux pour 2016.

Le but est de passer de 0 à 255 sur une durée de T. On calcule donc l'intervalle de temps entre deux augmentations (ou diminutions) de 1. C'est T/255. En effectuant ceci 255 fois, on passe de 0 à 255 (ou l'inverse) et ça dure T. C'est pourquoi la ScheduleTable est lancée pour 255 cycles.
Cordialement

petitrain

  • Jr. Member
  • **
  • Messages: 86
    • Voir le profil
Re : Un Arduino par module....ou pas.
« Réponse #59 le: janvier 06, 2016, 07:17:19 pm »
Tout d'abord merci pour tes vœux. A mon tour, je souhaite à toute l'équipe une Bonne et Chaleureuse Année 2016 avec beaucoup de joie à manipuler les Arduinos et les petits trains.
Pour les ScheduleTables, bravo et merci: C'est très pratique...
J'avais trouvé entre-temps l'explication pour les montées/descente de la PWM.
Dans un programme plus important, (mais je pense qu'il n'y aura pas de problème, il faut juste que j'essaye..), je peux démarrer les ScheduleTables dans un switch(compteur)....case:0...1....x...., le compteur étant incrémenter par un BP.
Ça me permettra d'avoir plusieurs animations lumineuses sur mon réseau.