Salut Antoine, > Encore un message aujourd'hui (oui je sais ca fait beaucoup), mais j'ai > pas mal de problème pour comprendre comment utiliser proprement le > module base/scheduler avec le timer 0. Je ne comprend pas comment on > fait pour qu'une tache s'exécute à un moment donné. J'ai regardé le code > de test fourni, mais j'ai pas mal de peine à comprendre.
Le fichier .h sert de référence pour l'interface: http://cvs.droids-corp.org/cgi-bin/viewcvs.cgi/aversive/modules/base/scheduler/scheduler.h?revision=1.13&view=markup En gros, lorsque l'option CONFIG_MODULE_SCHEDULER_TIMER0 est levée, il n'y a rien d'autre à faire que: - scheduler_init() - sei() - scheduler_add_event(...) Tu trouveras d'autres exemples sur la documentation de notre asservissement, ou dans le code du robot 2009: http://wiki.droids-corp.org/mediawiki/index.php/Aversive/Asservissement_Microb_2008 http://cvs.droids-corp.org/cgi-bin/viewcvs.cgi/aversive_projects/microb2009/ Sinon voilà un copier/coller d'un mail que j'ai envoyé récemment en point à point pour expliquer le scheduler. Je ne sais pas si ça répond particulièrement à ta question, mais je pense que ça permettra déjà de bien comprendre quel est le but de ce module: En gros, voilà en quelques points ce que fournit ce module, qui s'apparente plus à une gestion de timer qu'un "scheduler" au sens OS du terme: - appel d'une fonction périodique - appel d'une fonction unique dans un certain temps - gestion de priorités - ajout/suppression dynamique, quel que soit le contexte (même dans un autre évènement) L'architecture du module est relativement simple: on se sert d'une interruption timer (dans aversive, il y a plusieurs options pour faire ça) pour appeler une fonction de management du scheduler. C'est là qu'on va appeler les fonctions de callback des évènements ajoutés. Lorsqu'un évènement est en train d'être éxecuté, les interruptions doivent être autorisées pour permettre l'execution de scheduler_interrupt(), qui peut décider qu'un nouvel évènement doit interrompre le courant. Les règles sont les suivantes: 1- si plusieurs tâches doivent être exécutées au même moment, alors elles sont placées dans une liste et sont exécutées dans l'ordre, selon leur priorité. 2- une tâche de priorité p ne peut être interrompue que par une tâche de priorité strictement supérieure. 3- si une tâche est en cours d'éxecution et a une priorité supérieure à toutes les autres tâches, il faut attendre que cette tâche termine (retour de fonction) pour qu'une autre tâche puisse être exécuté. Pendant ce temps, les autre tâches sont retardées. 4- il n'y a pas de "famine": si on reprend l'exemple juste au dessus: lorsque la tâche de haute priorité termine, alors au prochain appel de scheduler_interrupt(), toutes les tâches seront appelées (dans l'ordre, voir 1-). Celà signifie que même si les tâches durent plus longtemps que le temps CPU disponible, alors le scheduler fera au mieux pour appeler toutes les tâches. 5- le module respecte probablement certains aspects "temps réel": le temps pour exécuter la tâche la plus prioritaire pourrait être borné (selon le temps d'éxecution de scheduler_interrupt(), des autres interruptions, et du temps max pdt lequel les interruptions sont vérouillées dans le programme principal). Pour les tâches de priorité plus faible, il faut y ajouter la possibilité de se faire interrompre par les tâches de prio plus élevée. Olivier _______________________________________________ Avr-list mailing list Avr-list@droids-corp.org CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive WIKI : http://wiki.droids-corp.org/index.php/Aversive DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/ BUGZILLA : http://bugzilla.droids-corp.org COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
