Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 124 063 vues
- 130 followers
Anonyme
Anonyme
[ Dernière édition du message le 07/03/2017 à 08:00:40 ]
Jimbass
C'est pourtant ça.
Le truc, c'est qu'il faut être précis quand on utilise ces termes qui ont plein de sens différents selon de quoi on parle. Je côtoie plein de softeux/modéliseurs qui ne se rendent pas compte que leur jargon n'est pas universel. Moi je bosse sur l'architecture matérielle, des drivers et des RTOS, et j'ai pris l'habitude de toujours définir de quoi je parle avant de commencer.
Une fois, j'en ai même eu un qui voulait étendre le concept d'architecture logicielle à composants ... au hardware ! Je l'ai renvoyé vers les archives du JEDEC ...
Oui c'est ça en gros je voudrais que les boucles servant à écouter un signal en entrée ou envoyer un signal en sortie tournent en arrière plan et ne bloque pas le reste du code.
Il te faut donc un OS (ou assimilé) qui gère le multithread. Cf. mon post précédent.
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts
Truelle est un manchot
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
É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
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.
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)
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.
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 :.
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
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
... Et effectivement ça devient un gros plat de spaghetti parce les mécanismes sous-jacents sont mal connus de certains softeux. (mais c'est quand même génial : Plus besoin de gérer explicitement la sauvegarde de contexte, de table d'exception, etc.).
Je ne connais pas Arduino mais vu le concept hardware du bidule je serais très surpris qu'il n'y ait pas des lib déjà toute prêtes et bien documentée pour gérer les interruptions et les prioriser.
[ Dernière édition du message le 07/03/2017 à 14:34:02 ]
redpill
rumorofsmoke.github.io/
[ Dernière édition du message le 07/03/2017 à 21:54:38 ]
tropdeg'
man 2 select
- < Liste des sujets
- Charte