Merci !
Non, ça va, c'est bien expliqué (plus ça aurait été trop....) : je vois bien l'idée !
Donc si je comprend bien, il faudrait que je rajoute une fonction wifi2led2 (par exemple) copie de wifi2led pour wlan1
et de rajouter son appel dans la fonction main pour rajouter un second test (et donc une deuxième LED) !
En ce qui concerne les threads, j'ai un collègue qui me saoul avec ça à longueur de journée mais j'y comprend rien du tout (raison de plus pour m'y mettre...).
D'ailleurs, il me demande si le nombre de threads lancés ne va pas devenir exponentiel si on en relance un à chaque fois...
(En somme on démarre un thread dans un thread sans vérifier s'il boucle déjà hors du thread principal. Donc on en démarre a chaque fois que le timer appelle wifi2led, alors soisla fonction Timer de python attend 1 seconde fait le taff et finis,sois si la fonction Timer boucle toutes les secondes sans s'arrêter, le nombre de thread démarré par le 1er, puis le 2eme, puis le .... vas devenir énorme.).
Et si la fonction threading.timer.start était executée dans le main (en supprimant l'autre) ?
Bon je regarde ça à l'occasion mais merci beaucoup pour la piste, c'est sympa !
Allumage conditionnel d'une LED
Modérateur : Francois
-
- Raspinaute
- Messages : 1089
- Enregistré le : lun. 15 août 2016 21:38
Re: Allumage conditionnel d'une LED
Tu peux ajouter des fonction dans le thread.timer ou en créer d'autres séparées, ca c'est suivant tes besoin. L'important, c'est le principe car il te permet de faire des programmes qui pourront évoluer alors qu'avec une boucle dans un batch tu te mets des limites avant même d'avoir commencé. Par contre attention, ce n'est qu'un exemple vite fait pour décrire le procédé, à toi de te pencher sur le langage pour comprendre la porté de chaque chose.Nico a écrit : Donc si je comprend bien, il faudrait que je rajoute une fonction wifi2led2 (par exemple) copie de wifi2led pour wlan1
et de rajouter son appel dans la fonction main pour rajouter un second test (et donc une deuxième LED) !
Et Il a bien raison ton collègue. Même s'il est miteux (en comparaison des ses homologues), python est un langage de haut niveau qui permet de gérer les thread et les évènement asynchrone assez facilement et cela devient très vite ridicule de ne pas utiliser ces facilités. Si tu as lu l'article que j'avais fait la dessus, tu aurais pu remonter à l'origine et comprendre pourquoi je l'avais écrit. Crois moi, pour des petits programmes avec ce type de langage, il est beaucoup plus facile de comprendre le fonctionnement des threads que de vouloir s'en passer.Nico a écrit : En ce qui concerne les threads, j'ai un collègue qui me saoul avec ça à longueur de journée mais j'y comprend rien du tout (raison de plus pour m'y mettre...).
Non, dans l'exemple, tu n'as jamais plusieurs timer qui tourne en même temps. La procedure commence par dire qu'elle créer une nouvelle instance d'elle même, puis fait son boulot et le thread disparaît de lui même une fois arrivé à la fin. C'est la façon la plus simple de gérer du multi-thread temporisé en python mais on pourrait faire beaucoup mieu. La bonne solution, ca aurait été d'instancier un thread qui contiendrait une boucle temporisé ou dépendante de l'évent d'un timer extérieur, mais le code tiendrait plus dans une imageNico a écrit :D'ailleurs, il me demande si le nombre de threads lancés ne va pas devenir exponentiel si on en relance un à chaque fois...
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).