Pages : 1
#1 Le 07/08/2008, à 21:42
- gilbert
C temporisations assez précises
Salut tout le monde,
Existe-t-il d'une façon générale sous linux, une fonction qui permette de faire des pauses avec un timing assez précis ? Dans l'idéal à la microseconde près, au pire à la milliseconde près. Il y a sleep(3) de unistd.h mais ça prend un uint en argument et ça n'est précis qu'à la seconde près. autrement dit, totalement imprécis.
merci pour votre aide.
A+ Gilbert
Simplement moi-même..
Hors ligne
#2 Le 07/08/2008, à 21:44
- ®om
Re : C temporisations assez précises
Ça doit exister (ça existe en java), mais il faut bien savoir que la durée de la pause n'est absolument pas garanti (c'est une borne inférieure seulement), car au moment du "réveil", le thread peut ne pas avoir la main.
Hors ligne
#3 Le 07/08/2008, à 21:45
- gilbert
Re : C temporisations assez précises
ok
je m'y connais pas trop en programmation système. En fait j'ai une carte usb et je dois gérer des timings pour envoyer des signaux, je dois juste être précis au niveau du temps..
Simplement moi-même..
Hors ligne
#4 Le 07/08/2008, à 21:50
- gilbert
Re : C temporisations assez précises
Ok, j'ai trouvé nanosleep(2) qui a l'air pas mal. Les temps sont pas mal réguliers c'est bien. Par contre, je ne peux plus compiler ansi... 
Dernière modification par gilbert (Le 07/08/2008, à 22:03)
Simplement moi-même..
Hors ligne
#5 Le 07/08/2008, à 22:30
- gilbert
Re : C temporisations assez précises
Bon impossible d'être plus précis que 1 kHz... quelqu'un connait un autre moyen ?
Simplement moi-même..
Hors ligne
#6 Le 08/08/2008, à 04:02
- nicolas66
Re : C temporisations assez précises
Peut-être en jouant sur le timeslice du scheduler. Mais faudrait recompiler le noyau et ca n'est pas du tout garanti de fonctionner ...
"The computer was born to solve problems that did not exist before." (B. Gates)
Hors ligne
#7 Le 08/08/2008, à 07:16
- nicolas.sitbon
Re : C temporisations assez précises
Bon impossible d'être plus précis que 1 kHz... quelqu'un connait un autre moyen ?
Tu n'auras pas plus précis que nanosleep() et ce quel que soit le système, c'est directement lié timer du système. Tu es conscient que réellement tu n'as pas la précision annoncé par nanosleep()? Pour le -ansi, c'est normal, passe en gnu89.
Autrement dans les fonctions temps réel POSIX tu dois avoir des choses comme timer_create().
Hors ligne
#8 Le 08/08/2008, à 11:56
- claudius01
Re : C temporisations assez précises
Bonjour,
Si, si, au moyen d'un petit programme C s'appuyant sur la fonction 'gettimeofday()', il est possible d'avoir la microseconde 
cf. http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man2/gettimeofday.2.html
Cordialement, A+
--
Claudius
Hors ligne
#9 Le 08/08/2008, à 12:26
- robrob
Re : C temporisations assez précises
Le problème n'est pas que la résolution c'est surtout la précision de la temporisation.
En effet ton programme va régulièrement se faire interrompre par l'ordonnanceur de linux, ordonnanceur qui va éventuellement donner la main à un autre programme. Du coup ta tempo peut être juste, comme elle peut être à l'ouest (d'où la mention de borne inférieure par ®om).
Le fait d'avoir une priorité très haute sur ton programme limitera le risque de changement tache mais pas l'interruption régulière par l'ordonnanceur.
Tu pourrais avoir des délais très préçis si tu pouvais arrêter le ordonnanceur. Mais je ne crois pas que ce soit possible (ni que soit une bonne idée 
) avec linux.
Tu devrais cependant regarder au niveau de RT-Linux qui propose peut-être des solutions à ce genre de problème.
Dernière modification par robrob (Le 08/08/2008, à 12:28)
Hors ligne
#10 Le 08/08/2008, à 13:27
- nicolas.sitbon
Re : C temporisations assez précises
Bonjour,
Si, si, au moyen d'un petit programme C s'appuyant sur la fonction 'gettimeofday()', il est possible d'avoir la microseconde
cf. http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man2/gettimeofday.2.htmlCordialement, A+
--
Claudius
Hors sujet; il est question de temporisation ici!
Hors ligne
#11 Le 08/08/2008, à 14:06
- Karl_le_rouge
Re : C temporisations assez précises
Posix, t'offre 2 possibilités:
* clock_nanosleep() utilisant les timers "haute précision" (celà dépends du système)
* select() la seule façon portable de faire un sleep portable avec une précision < 1s.
Hors ligne
#12 Le 08/08/2008, à 14:17
- nicolas.sitbon
Re : C temporisations assez précises
Posix, t'offre 2 possibilités:
* clock_nanosleep() utilisant les timers "haute précision" (celà dépends du système)
* select() la seule façon portable de faire un sleep portable avec une précision < 1s.
Attentin toutefois, j'ai l'impression que l'on s'embrouille sur les termes, il y a une différence en un timer (une temporisation) et un sommeil (sleep). C'est au PO de savoir ce qu'il veut après tout.
Hors ligne
#13 Le 08/08/2008, à 14:47
- Karl_le_rouge
Re : C temporisations assez précises
s/timer/horloges Posix/
Vivement le week-end, la nuit dernière a été très courte et la journée fort longue.
Hors ligne
#14 Le 08/08/2008, à 19:54
- mutah
Re : C temporisations assez précises
Il y a aussi une question de timer noyau. Il faut peut être regarder du coté des noyaux realtime.
Pour faire de la musique avec ubuntu, j'utilise le paquet noyau linux-image-rt
Ce n'est pas le chemin qui est difficile, c'est le difficile qui est chemin.
Hors ligne
#15 Le 08/08/2008, à 19:57
- nicolas66
Re : C temporisations assez précises
Je ne sais pas si le fait de jouer sur le timeslice du scheduler peut apporter qq chose
"The computer was born to solve problems that did not exist before." (B. Gates)
Hors ligne
#16 Le 09/08/2008, à 16:26
- gilbert
Re : C temporisations assez précises
hello tout le monde!
merci pour toutes ces réponses. En effet, comme le dis nicolas.sitbon, je n'ai rien de plus précis que nanosleep(2). En fait je vous explique ce que je voulais faire :
Dès que je reçois une transition flanc descendant sur une IO de ma carte, je dois attendre entre 100ns et 1µs. Puis effectuer 4 pulses de 12µs avec un duty cycle de 50% +/- 5% (donc 4 fois 6µs à l'état haut). Je pensais que c'était quelquechose de simple à faire sous Linux, avec un OS si beau sur des machines si performantes. mais à paramment, je peux laisser la solution de piloter directement mes signaux depuis l'ordinateur, il faudra que j'ajoute probablement un autre µC entre l'usb et mes IO pour gérer ces timings.
merci pour votre aide. Là j'avoue que je suis un peu déçu d'ubuntu... Je vais regarder ce que c'est un peu RTLinux, une distro?
Enfin merci encore à tous.
A+
Simplement moi-même..
Hors ligne
#17 Le 10/08/2008, à 14:13
- Link31
Re : C temporisations assez précises
Habituellement pour ce genre de chose on code un driver qui tourne en mode noyau. Comme ça, pas de risque qu'il soit gêné par l'ordonnanceur.
Hors ligne
#18 Le 11/08/2008, à 08:37
- Karl_le_rouge
Re : C temporisations assez précises
+1 Link31
@gilbert: dans ton cas, tu peux essayer d'utiliser le patch d'Ingo Molnar et Thomas Gleixner PREEMPT_RT afin d'améliorer les latences de ton système.
Sinon,il faudra utiliser un vrai noyau temps-réel et utiliser Xenomai (de préférence) ou RTAI en concurrence avec le noyau Linux.
Je déconseille RTLinux (une autre extension temps-réel du noyau Linux) qui est propriétaire, qui n'évolue plus vraiment et qui est largement moins bon que les 2 solutions cités précédemment.
Hors ligne
#19 Le 11/08/2008, à 16:02
- aleph
Re : C temporisations assez précises
hello tout le monde!
merci pour toutes ces réponses. En effet, comme le dis nicolas.sitbon, je n'ai rien de plus précis que nanosleep(2). En fait je vous explique ce que je voulais faire :
Dès que je reçois une transition flanc descendant sur une IO de ma carte, je dois attendre entre 100ns et 1µs. Puis effectuer 4 pulses de 12µs avec un duty cycle de 50% +/- 5% (donc 4 fois 6µs à l'état haut). Je pensais que c'était quelquechose de simple à faire sous Linux, avec un OS si beau sur des machines si performantes. mais à paramment, je peux laisser la solution de piloter directement mes signaux depuis l'ordinateur, il faudra que j'ajoute probablement un autre µC entre l'usb et mes IO pour gérer ces timings.
merci pour votre aide. Là j'avoue que je suis un peu déçu d'ubuntu... Je vais regarder ce que c'est un peu RTLinux, une distro?
Enfin merci encore à tous.
A+
C'est assez surprenant comme façon de travailler. Je dirais qu'habituellement dans une situation comme celle qui est brièvement décrite et comme je la comprends, on utilise de l'appareillage électronique dédié, surtout dans cette plage de temps : générateur d'impulsions, horloge externe, ...
L'expérience n'est pas pilotée à proprement parler par un ordinateur, mais l'ordinateur sert plutôt à programmer, préparer, le générateur d'impulsions et à donner top le top de départ.
Dans ces conditions, l'ordinateur/système d'exploitation importe assez peu.
#20 Le 11/08/2008, à 20:26
- gilbert
Re : C temporisations assez précises
C'est assez surprenant comme façon de travailler. Je dirais qu'habituellement dans une situation comme celle qui est brièvement décrite et comme je la comprends, on utilise de l'appareillage électronique dédié, surtout dans cette plage de temps : générateur d'impulsions, horloge externe, ...
L'expérience n'est pas pilotée à proprement parler par un ordinateur, mais l'ordinateur sert plutôt à programmer, préparer, le générateur d'impulsions et à donner top le top de départ.
Dans ces conditions, l'ordinateur/système d'exploitation importe assez peu.
Oui, le but c'était d'avoir le minimum d'électronique pour que ça coûte le moins cher possible, mais j'ai rajouté un contrôleur, et j'ai recodé mon firmware et tout va pour le mieux dans le meilleur des mondes;) Enfin, quand on a une bête de course (encore une fois, je suis un nul en informatique et en programmation système), je m'étais dis qu'on aurait pu en profiter.. Enfin, ça apporte trop de complication et pour 10.- de plus, c'est tout à fait acceptable, et ça me permet d'avoir bien plus d'opportunités encore.
A+
Simplement moi-même..
Hors ligne
#21 Le 12/08/2008, à 07:00
- aleph
Re : C temporisations assez précises
> gilbert
Argument tout à fait valable.
A ce petit jeu, je ne ne serais pas du tout surpris si on me disait que le système le plus rapide avec les machines actuelles pour faire ce genre de travail ne serait tout simplement pas ... DOS. Aucune preuve de ce que j'affirme, mais mon expérience dans le domaine qui date un peu, il est vrai, me permet de le supposer.
#22 Le 12/08/2008, à 09:18
- yvan78
Re : C temporisations assez précises
utiliser Xenomai (de préférence)
Il est exact que pour faire du vrai temps réel avec linux, l'approche co-noyau de Xenomai est sans doute la meilleure et la seule qui le permet vraiment d'assurer le determinisme: Il se place en amont de linux sur le système et xenomai passe à Linux les évènements, quand il a le temps. Ainsi, le programmeur d'applications temps réel se concentre sur son métier... et peut bénéficier de Linux pour tout ce qui n'est pas trop son véritable travail (gestion système de fichiers, réseau...).
De plus, quand on porte une application venant d'un noyau temps réel (genre vxWorks), Xenomai inclus les API.
Un beau projet... celui que Windriver aurait du faire s'ils étaient moins c<BIIIPPPP>!
Mais là, visiblement, c'est un peu fort pour la demande initiale!
#23 Le 12/08/2008, à 18:11
- Link31
Re : C temporisations assez précises
A ce petit jeu, je ne ne serais pas du tout surpris si on me disait que le système le plus rapide avec les machines actuelles pour faire ce genre de travail ne serait tout simplement pas ... DOS. Aucune preuve de ce que j'affirme, mais mon expérience dans le domaine qui date un peu, il est vrai, me permet de le supposer.
Certainement pas.
Un environnement DOS, ça signifie (quasiment) pas d'environnement d'exécution et pas d'ordonnanceur. Je suis d'accord sur le fait que ça permette d'utiliser le processeur à 100% du temps et de sa vitesse, mais c'est justement ça aussi le problème. Sans noyau, n'importe quel programme peut planter le système complet.
En comparaison : Linux fournit un véritable environnement d'exécution (protection de la mémoire, entre autres), tout en ne sacrifiant que très peu les performances par-rapport à du code en mode noyau si certaines précautions sont prises, et/ou si certains patches sont utilisés.
C'est pourquoi le développement actuel se porte uniquement vers les noyaux en temps réel, plutôt que vers des systèmes 16-bits sans noyaux dépassés depuis longtemps.
Hors ligne
#24 Le 12/08/2008, à 20:25
- aleph
Re : C temporisations assez précises
> link31
Oh, je ne conteste pas et n'est pas les compétences pour juger de la valeur intrinsèque d'un os pour ce genre de travail. Mon intention était surtout de porter l'attention que pour bien des expériences comme celles décrites un machine style DOS peut ou pourrait être bien suffisante.
Pour un travail plus propre, une électronique dédiée comme proposée dans ma 1ère intervention est la meilleure des solutions.