appel periodique de fonction

**Médinoc** · 29/01/2008, 17h52

Les fonctions d'attente de Windows ont une granularité de l'ordre de 15 millisecondes, pour linux je ne sais pas.

**Sylar44** · 29/01/2008, 18h14

Je dois appeler des fonctions avec un intervalle de temps défini.
Le problème c'est que cette intervalle est de l'ordre de la microseconde (jusqu'à secondes).
Si j'ai bien compris je dois utiliser un multithread.
Un pour chaque période,je suppose.
Apparemment, le multithread n'est pas adapté à mon problème du fait de la rapidité d'execution des taches.

Envoyé par Medinoc

Les fonctions d'attente de Windows ont une granularité de l'ordre de 15 millisecondes, pour linux je ne sais pas.

Donc médinoc, tu m'avais dit sous windows c'est de l'ordre de 15millisecondes pour le multithread sous windows.
Le problème c'est que je suis sur linux
Et la fonction RDTSC ne convient pas pour ca sinon?

**Neitsa** · 29/01/2008, 18h28

Bonjour,

Pour ce qui est des unices, ça n'est pas mon domaine, je laisserais les personnes plus compétentes te répondre. (Je doute que sous PC on puisse atteindre une granularité inférieur à 15 ms comme le soulignait Médinoc).

Je voulais juste préciser que RDTSC est le mnémonique d'une instruction assembleur (Read Time Stamp Counter). Donc c'est utilisable en C uniquement via les instrinsics et ça ne fonctionnera que (et uniquement) sur un processeur compatible x86 (et encore...).

De plus RDTSC est source de problème sur les processeurs récents. Il faut alors utiliser un TSC constant via un MSR. A partir de là ca n'est plus du C mais de l'assembleur...

**Jean-Marc.Bourguet** · 29/01/2008, 18h43

Envoyé par Neitsa

Pour ce qui est des unices, ça n'est pas mon domaine, je laisserais les personnes plus compétentes te répondre. (Je doute que sous PC on puisse atteindre une granularité inférieur à 15 ms comme le soulignait Médinoc).

Pourquoi? J'ai le souvenir tres net d'avoir genere des interruptions a 1000HZ sous DOS.

Si j'ai bonne memoire, la granularite normale sous Linux est a 10 ms et est modifiable (j'ai un souvenir vague que ca a meme ete augmente sur les kernels recents -- peut-etre quelque chose propre a une distribution).

**Médinoc** · 29/01/2008, 18h47

Déjà, avant de crier "multithread", il faudrait être sûr que tu as AUSSI AUTRE CHOSE à faire qu'appeler cette fonction périodiquement.

Sinon, un seul thread avec des attentes (voire de l'attente active si ton programme est vraiment critique en temps) suffit...

**Sylar44** · 30/01/2008, 12h23

Donc, en gros je veux faire une application temps réel.
Ca doit controler les positions de bras,la vitesse ...
Donc, par exemple la fonction A doit être appelé toute les 10ms
la B toute les 100ms.
Donc, je me disais qu'il fallait un thread pour chaque fonction mais je suis pas un expert en la matière

**Stabia** · 30/01/2008, 23h21

Sous Linux je n'ai aucun compétence, sous XP j'ai eu beaucoup de mal à programmer une machine de positionnement 3 axes (avec deux camera de contrôle et de l'outillage !), le 50 htz est inatteignable (*).

Windows n'est pas fait pour cela, essayez par exemple de monter les valeurs de commutation, vous verrez toute l'interface ralentir puis se bloquer, même avec peu d'applications lancées (et beaucoup de mémoire).

Comme l'a dit "médinoc" la solution est, hélas, de traiter une boucle d'attente infinie dans une seule tâche, c'est pas très propre mais au moins ça tourne. RDTSC ne pose pas de problème particulier sous XP, ci aprés un petit bout de code qui me sert à initialiser un générateur de nombre aléatoires

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	__asm	{
				rdtsc
				mov dword ptr [val], eax
			}

Je sais c'est du C++.

Je suis entrain de développer (voir le forum assembleur) un système d'exploitation dédié justement à ce genre de problème que je rencontre souvent professionnellement ; la solution de faire une application sous MSdos est parfois encore un échappatoire.

(*) si vous avez la solution je suis preneur !

**Jean-Marc.Bourguet** · 31/01/2008, 09h38

Il y a deja des OS temps reels, certains bases sur Linux, d'autres pas.

**Sylar44** · 31/01/2008, 10h03

50Hz c'est rien ca

je m'étais dit que j'allais utilisé du code compilé pour accelerer le processus mais je peux pas le faire
Il aurait juste suffit de connaitre l'adresse et la fin du programme appelé et de faire un appel genre call return en assembleur

**Emmanuel Delahaye** · 31/01/2008, 12h55

Envoyé par Stabia

sous XP j'ai eu beaucoup de mal à programmer une machine de positionnement 3 axes (avec deux camera de contrôle et de l'outillage !), le 50 htz est inatteignable (*).

Windows n'est pas fait pour cela, essayez par exemple de monter les valeurs de commutation, vous verrez toute l'interface ralentir puis se bloquer, même avec peu d'applications lancées (et beaucoup de mémoire).

(*) si vous avez la solution je suis preneur !

Tu as essayé le Timer Multimedia ?

**Stabia** · 31/01/2008, 16h11

Oui, mais j'ai aussi à gérer le flux de mes deux caméras.
Pour l'instant le programme fonctionne en version bêta et le client est satisfait : donc =>
Axiome UN : on ne touche pas à un programme qui marche, même si l'on en sait pas pourquoi.

**Sylar44** · 31/01/2008, 17h33

une boucle d'attente infini?
tu veux dire faire un sleep(infini) c'est ca?
le problème c'est que je dois appelé d'autres taches,juste après et là plus rien ne sera periodisés normalement

PS: je suis pas sur d'avoir compris ton raisonnement

**contremaitre** · 31/01/2008, 17h47

L'implmentation actuelle de nanosleep est construite sur
le mécanisme de temporisation du noyau, qui dispose d'une
résolution valant 1/HZ s (10 ms sur Linux/i386 et 1 ms sur
Linux/Alpha). Ainsi, nanosleep dormira toujours pour une
durée au moins égale au temps spécifié, mais il peut pren
dre jusqu' 10 ms de plus (i386) avant de faire redémarrer
le processus

Par contre il me semble que les fonctions de mesure de temps (gettimeofday sous linux et QueryPerformanceCounter sous windows) sont bien plus précises.

**souviron34** · 31/01/2008, 18h18

Envoyé par pasdeface

Par contre il me semble que les fonctions de mesure de temps (gettimeofday sous linux et QueryPerformanceCounter sous windows) sont bien plus précises.

oui mais dans ce cas elles imposent une boucle infinie de verification...

**Stabia** · 01/02/2008, 11h00

Il y a déjà des OS temps réels, certains bases sur Linux, d'autres pas.

Certes, il y a déjà aussi des automobiles, des congélateurs, des ... cela n'empêche pas de travailler sur des innovations.

Pour ce qui est du problème principal il faudrait que "sylar44' nous dise sur quel système il cherche à implanter son application et dans quel cadre ?
Si la machine est mono-application (genre automate) c'est plus simple que si l'application peut être lancée concurremment à d'autres.

**Sylar44** · 02/02/2008, 17h45

oui c'est pour un automate relié à une base de donnée ruby on rails

**Stabia** · 03/02/2008, 16h48

Désolé de mon ignorance mais qu'est-ce-que "rubi on rails" ?

Je dois livrer dans trois mois un nouvel automate (services urbains) je pense que je vais franchir le pas et tourner avec mon amorce de système d'exploitation :
1/ passage en mode protégé
2/ récupération d'un mode graphique LFB (voir le forum assembleur)
3/ boucle mono-tache (mais avec TSS pour la gestion des IT)

La difficulté c'est qu'il va falloir que j'écrive toutes les couches USB, j'ai déjà fait le TCPIP (partiellement), et le PCI (il y a une carte-maison de servitude et d'entrées/sorties).

Peut être que cette approche pourrait vous convenir ?

Sinon, et s'il n'y a pas d'autres applications, voici un extrait du code du programme dont je parlais et qui tourne en production (mais en version de test). J'ai tout laissé pour donner une idée du jus, mais seules les dernières lignes concernent votre problème.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
	LireBase();
#ifdef _DEBUG
	#ifdef MILLINAV
		LireData("C:/Millinav/data3axes.ctt");
	#else
		LireData("F:/Millinav/data3axes.ctt");
	#endif
#else
	LireData("data3axes.ctt");
#endif
	InitOrthometrie();
	InitProvisoire();
 
	pCadre->ShowWindow(SW_SHOW);
	pCadre->UpdateWindow();
 
	TacheSequence = 0;
	InitializeCriticalSection(&SectionCritique); 
	TacheSequence = ::CreateThread(NUL, 0, &BoucleSequence, 0,
			CREATE_SUSPENDED, NUL);
//	if(!TacheSequence) return true;
//	::SetThreadPriority(TacheSequence, THREAD_PRIORITY_ABOVE_NORMAL );
	::SetThreadPriority(TacheSequence, THREAD_PRIORITY_HIGHEST);
//	::SetThreadPriority(TacheSequence, THREAD_PRIORITY_TIME_CRITICAL);
#ifdef MILLINAV
	::ResumeThread(TacheSequence);
#endif
	return TRUE;
erreur:
	return FALSE;

**Sylar44** · 04/02/2008, 10h49

Je m'en sers pour mettre mes variables dans une base de donnée et pour faire une page html

**Emmanuel Delahaye** · 04/02/2008, 11h40

Envoyé par Stabia

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
#ifdef _DEBUG

Identificateur réservé.

http://emmanuel-delahaye.developpez....htm#id_reserve

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	TacheSequence = ::CreateThread(NUL, 0, &BoucleSequence, 0,
			CREATE_SUSPENDED, NUL);

Pas du C.

**Emmanuel Delahaye** · 04/02/2008, 11h41

Envoyé par Sylar44

Je m'en sers pour mettre mes variables dans une base de donnée et pour faire une page html

Tu parles de quoi ? A qui ?

appel periodique de fonction

C

Discussions similaires

Partager

Partager