Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 119 107 vues
- 130 followers
Afficher le premier post
Je n'ai jamais mis en oeuvre (sinon sur Amiga il y a trèèèèès longtemps), mais c'est abordé dans la seconde partie des liens donnés par Jimbass :
https://learn.adafruit.com/multi-tasking-the-arduino-part-2/interrupt-etiquette?view=all
On trouve pas mal de code Arduino utilisant ce principe, pour du MIDI notamment.
https://cs.gmu.edu/~sean/projects/gizmo/
y a des programeurs sur AF si oui vous bossez sous quoi ?Anonyme
31097
Jimbass
11602
Drogué·e à l’AFéine
Truelle est un manchot
10522
Drogué·e à l’AFéine
Pt: Ça à l'air super intéressant ce dont tu me parle (d'ailleurs je vais regarder ça ce soir ça a l'air cool 
). Mais là ça à l'air de concerner plutôt les cas du type "Périphérique <=> Périphérique", genre [Arduino1/PC1/autre1] [Arduino2/PC2/autre2].
Là ce qui m'intéresse vraiment c'est que l'arduino écoute/envoi en boucle des signaux sur plusieurs de ses broches en arrière plan (ça peut-être des boutons, led, LCD, ou d'autre conneries).
Admettons que je veuille demander un truc à la con sur un afficheur LCD du type "dessine moi un hélicobite et fait moi bouger tout ça pour la gloire du lol", là ce qui m'intéresserait serait de ne pas attendre la fin de ce bloc pour continuer à exécuter le reste du code.
Après désolé si j'ai du mal à me faire comprendre. Je reste un gros newbie dans le domaine. Assimiler le jargon technique et bien l'utiliser c'est pas une monde affaire.
J'ai pas encore lu tous les posts j'vais le faire promis.
Edit: Merde crosspost.
Jimbass: Ok dac, donc faudra que je me contente d'écouter/envoyer avec l'arduino sans en faire plus et que je laisse mon pc ou un raspberry faire le reste si je veux pas que ça soit bloquant en gros?
). Mais là ça à l'air de concerner plutôt les cas du type "Périphérique <=> Périphérique", genre [Arduino1/PC1/autre1] [Arduino2/PC2/autre2].Là ce qui m'intéresse vraiment c'est que l'arduino écoute/envoi en boucle des signaux sur plusieurs de ses broches en arrière plan (ça peut-être des boutons, led, LCD, ou d'autre conneries).
Admettons que je veuille demander un truc à la con sur un afficheur LCD du type "dessine moi un hélicobite et fait moi bouger tout ça pour la gloire du lol", là ce qui m'intéresserait serait de ne pas attendre la fin de ce bloc pour continuer à exécuter le reste du code.
Après désolé si j'ai du mal à me faire comprendre. Je reste un gros newbie dans le domaine. Assimiler le jargon technique et bien l'utiliser c'est pas une monde affaire.
J'ai pas encore lu tous les posts j'vais le faire promis.
Edit: Merde crosspost.
Jimbass: Ok dac, donc faudra que je me contente d'écouter/envoyer avec l'arduino sans en faire plus et que je laisse mon pc ou un raspberry faire le reste si je veux pas que ça soit bloquant en gros?
[ Dernière édition du message le 07/03/2017 à 09:55:09 ]
Anonyme
31097
Teum > ha dans ce cas tu as besoin de code d'interruption. Comme leur nom l'indique ce sont des petites portions de codes qui se déclenches à la venue d'un événement (elles ne sont pas dans le programme principal et interrompent ce dernier à la venue de l'événement) je sais pas comment c'est géré en Arduino mais ça se fait sans aucun doute 
Édit : ça marche que pour l'écoute par contre. Pour l'envoie la il faudra soit passer par des périphériques (comme l'uart ou un timer) soit par un os temps réels (compliqué et je crois pas que ça existe pour Arduino)
Édit : ça marche que pour l'écoute par contre. Pour l'envoie la il faudra soit passer par des périphériques (comme l'uart ou un timer) soit par un os temps réels (compliqué et je crois pas que ça existe pour Arduino)
[ Dernière édition du message le 07/03/2017 à 10:04:30 ]
Jimbass
11602
Drogué·e à l’AFéine
Microscopiquement, un cœur de processeur ne fait qu'une chose à la fois. On arrive quand même à donner l'impression qu'il se passe plusieurs choses en même temps, en passant suffisamment vite d'une tâche à une autre. C'est ce qu'on appelle le "temps partagé", et c'est la base de tous les systèmes d'exploitation modernes.
C'est l'ordonnanceur (scheduler) qui décide de passer d'une tâche à une autre au bout d'un certain temps (typiquement quelques ms) ou quand un événement se produit (interruption ou appel système). Une tâche peut décider de rendre la main quand elle attend une durée ou la disponibilité d'une ressource.
Une bonne introduction : http://www.freertos.org/implementation/a00004.html
(et en plus ca parle de FreeRTOS sur AVR)
Ca permet de réagir à des événements matériels (appui sur un bouton, réception sur une UART, expiration d'un timer), et donc on peut construire pas mal de choses avec ca. Mais quand on commence à vraiment gérer des tâches ayant un état interne et des appels de sous-fonctions (donc une stack à gérer), on est déjà en train d'écrire un OS.
C'est l'ordonnanceur (scheduler) qui décide de passer d'une tâche à une autre au bout d'un certain temps (typiquement quelques ms) ou quand un événement se produit (interruption ou appel système). Une tâche peut décider de rendre la main quand elle attend une durée ou la disponibilité d'une ressource.
Hors sujet :
Après quand on a plusieurs cœurs, on peut faire du vrai parallélisme ... avec ses difficultés propres.
Une bonne introduction : http://www.freertos.org/implementation/a00004.html
(et en plus ca parle de FreeRTOS sur AVR)
Citation de Patrick :
tu as besoin de code d'interruption.
Ca permet de réagir à des événements matériels (appui sur un bouton, réception sur une UART, expiration d'un timer), et donc on peut construire pas mal de choses avec ca. Mais quand on commence à vraiment gérer des tâches ayant un état interne et des appels de sous-fonctions (donc une stack à gérer), on est déjà en train d'écrire un OS.
Citation de un :
un os temps réels (compliqué et je crois pas que ça existe pour Arduino)
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts
[ Dernière édition du message le 07/03/2017 à 10:22:44 ]
.: Odon Quelconque :.
10707
Drogué·e à l’AFéine
Citation de Patrick :
Teum > ha dans ce cas tu as besoin de code d'interruption. Comme leur nom l'indique ce sont des petites portions de codes qui se déclenches à la venue d'un événement (elles ne sont pas dans le programme principal et interrompent ce dernier à la venue de l'événement) je sais pas comment c'est géré en Arduino mais ça se fait sans aucun doute
Je n'ai jamais mis en oeuvre (sinon sur Amiga il y a trèèèèès longtemps), mais c'est abordé dans la seconde partie des liens donnés par Jimbass :
https://learn.adafruit.com/multi-tasking-the-arduino-part-2/interrupt-etiquette?view=all
On trouve pas mal de code Arduino utilisant ce principe, pour du MIDI notamment.
https://cs.gmu.edu/~sean/projects/gizmo/
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
Dr Pouet
52152
Membre d’honneur
Par contre la programmation multitâche est super casse-gueule. Énormément de développeurs ne s'en rendent pas compte, se lancent la fleur au fusil dans un truc délicat, et à la fin on a un plat de spaghettis indémerdable et bon pour la poubelle.
Le plus gros problème est le "race condition", mais dans un gros logiciel le "dead lock" n'est pas mal non plus. Et plein d'autres possibilités de naufrage aussi.
Voir déjà :
https://en.wikipedia.org/wiki/Race_condition#Example
Et en l'occurrence, les interruptions sont une deuxième tâche déclenchée n'importe où au milieu de la tâche courante.
Take care, comme on dit !
Le plus gros problème est le "race condition", mais dans un gros logiciel le "dead lock" n'est pas mal non plus. Et plein d'autres possibilités de naufrage aussi.
Voir déjà :
https://en.wikipedia.org/wiki/Race_condition#Example
Et en l'occurrence, les interruptions sont une deuxième tâche déclenchée n'importe où au milieu de la tâche courante.
Take care, comme on dit !
[ Dernière édition du message le 07/03/2017 à 12:44:36 ]
EraTom
2282
AFicionado·a
redpill
2341
AFicionado·a
tropdeg'
969
Posteur·euse AFfolé·e
- < Liste des sujets
- Charte