Allumage conditionnel d'une LED

Le connecteur GPIO du Raspberry Pi, comment l'utiliser sur les Mode A, B et B+

Modérateur : Francois

Avatar du membre
Nico
Messages : 11
Enregistré le : sam. 25 juin 2016 23:07

Re: Allumage conditionnel d'une LED

Message par Nico » mer. 18 janv. 2017 14:44

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 sois
la 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 !

Bud Spencer
Raspinaute
Messages : 630
Enregistré le : lun. 15 août 2016 21:38

Re: Allumage conditionnel d'une LED

Message par Bud Spencer » mer. 18 janv. 2017 20:58

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) !
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 : 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...).
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 :D'ailleurs, il me demande si le nombre de threads lancés ne va pas devenir exponentiel si on en relance un à chaque fois...
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 image :lol:
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).

Répondre

Retourner vers « Le GPIO »