2011-10-19 1 views
1

J'ai une tâche qui est essentiellement une minuterie; donc il va dormir et est censé se réveiller périodiquement .. Donc la tâche de minuterie dort par exemple 10ms. Mais ce qui se passe, c'est qu'il est incohérent au réveil et ne peut pas être invoqué pour se réveiller correctement dans le temps.Linux RTOS sleep() - wakeup() pour la tâche de minuteur

En fait, dans mes courses, il y a une grande différence dans les temps de sommeil. Parfois, il peut varier de 1-2 ms en éveil et très peu de fois ne reviennent pas du tout. C'est parce que le planificateur du noyau place toutes les tâches en attente et en attente dans une file d'attente, puis quand il interroge pour voir qui doit être éveillé, je pense que c'est round robin. Donc parfois la tâche aurait expiré au moment où le programmateur interroge à nouveau. Parfois, lorsqu'il y a des interruptions, l'ISR prend le contrôle et retarde le réveil.

Quelle est la meilleure solution pour gérer ce genre de problème?

(détails supplémentaires: La tâche est une minuterie MAC pour un réseau sans fil, RTOS est un micronoyau u-velOSity)

+0

D'où vient le RTOS dans cette question? A la fin, vous mentionnez u-velOSity, mais cela ne semble pas du tout pertinent à la question posée, où elle n'est pas mentionnée du tout. – Clifford

Répondre

2

Vous devez utiliser l'API de minuterie fournie par le système d'exploitation à la place à compter sur le planificateur. Voici une introduction au timer API for Linux drivers.

+0

juste eu à upvote @ Micea, j'avais découvert la même chose en développant une application de l'espace utilisateur qui devait envoyer périodiquement des données sur un bus UART. Je me suis retrouvé en utilisant un minuteur de l'OS qui a déclenché un signal lorsque le minuteur a expiré. Le signal agit comme une interruption et dans votre application, vous exécutez simplement la tâche lorsque le signal est reçu. Cela a considérablement amélioré les choses pour moi. Je suis passé d'une fluctuation de ~ 3ms à moins de 1ms de fluctuations. – Eric

1

Si vous avez besoin d'un timing hardcore, le planificateur OS ne sera probablement pas assez bon (comme vous l'avez constaté).

Si vous le pouvez, utilisez une minuterie séparée périphérique et l'utiliser est ISR faire aussi peu que vous pouvez sortir avec (horodater des données critiques, fixer des drapeaux par exemple) et puis laisser votre routine plus gigue faire usage de ces données avec son timing moins garanti.

+0

Merci. Je vais probablement utiliser un périphérique comme vous l'avez suggéré. – mane

0

Linux n'est pas un RTOS, et c'est probablement la racine de votre problème.

Vous pouvez rendre Linux plus adapté à une utilisation en temps réel de différentes manières et dans une mesure variable. Voir A comparison of real-time Linux approaches pour certaines méthodes et une évaluation du niveau de performance en temps réel que vous pouvez vous attendre.