Développement des outils logiciels

III.1. Intégration à l’environnement PC

L’intégration de la carte DATEL à l’environnement PC se fait suivant trois couches logicielles distinctes organisant le dialogue entre l’électronique de la carte, l’architecture matérielle et logicielle du PC et les applicatifs.

- Le device driver ou pilote de périphérique est un ensemble de procédures, chargées en même temps que le système d’exploitation, permettant un dialogue de bas niveau avec l’électronique de la carte de conversion. C’est en intervenant à ce niveau que l’on peut modifier, comme nous allons le voir dans ce qui suit, le comportement de la carte.

- La bibliothèque DLL rend accessible à toute application les différentes fonctions du device driver.

Cette bibliothèque permet d’effectuer un lien dynamique, c'est-à-dire au moment de l’utilisation et non à la compilation, entre les fonctions du pilote et le programme DOS ou Windows qui devra les utiliser.

- L’applicatif enfin, est en ce qui nous concerne le programme LabView que nous avons réalisé pour piloter la carte et automatiser les relevés de mesures.

Matériel Device driver Bibliothèque Dynamique

DLL

Application DOS ou Windows (Exemple Labview)

III.2. Modification du device driver :

La figure suivante fournit l’extrait du code relatif à la configuration du trigger interne de la carte DATEL. C’est cette partie du pilote que nous avons été amenés à modifier pour répondre précisément à nos besoins.

62

Le signal de déclenchement est obtenu par la division de l’horloge à 10 MHz. Cette division est opérée par un compteur programmable de type 82C54, dont deux timers 16 bits sont cascadés. La fréquence de sortie s’exprime donc par :

= où timer0 et timer1 sont les facteurs de division de chacun des deux compteurs.

Naturellement, il n’y a pas unicité de la solution et deux valeurs différentes du couple (timer0, timer1) peuvent satisfaire l’équation précédente.

L’organigramme ci-dessous présente la détermination du rapport de division nécessaire pour obtenir la fréquence de trigger désirée appelée ici ft. Dans l’organigramme, les deux variables hword et lword contiennent respectivement les valeurs à placer dans le timer0 et dans le timer1.

/******************************************************************************

@func set_pt_ad_clock_rate

@parm index of board : numéro de la carte (plusieurs cartes peuvent être installées dans un même PC

@parm trigger rate : fréquence de déclenchement demandée

@parm actual trigger Rate : fréquence de déclenchement obtenue, réellement produite par le hard

@rdesc (1) if error

@comm Set A/D Trigger Rate (timers 0,1)

*******************************************************************************/

UINT LIB_TYPE set_pt_trigger_rate(DWORD brdindex,REALTYPE ft, REALTYPE *actual)

lword = UROUND((REALTYPE)count / (REALTYPE)hword);

} else{

hword = UROUND((REALTYPE)count / (REALTYPE)0xffffL);

lword =0xffff;

}

if (pci416_set_timer(brdindex, TM_CONT_TRIGGER, hword, lword) != NOERROR) return (1);

if( (hword | lword)) {

*actual = 10.0e6 / ((REALTYPE)hword * (REALTYPE)lword);

return(0);

}else{

return(2);

} }

Figure 27 : Extrait du code source original DATEL

63

Le premier test a pour vocation de vérifier que la fréquence de trigger désirée est réalisable. La documentation constructeur indique que le facteur de division minimum par compteur ne peut être inférieur à deux. Ainsi la fréquence maximum de déclenchement réalisable par notre horloge est-elle de 2,5MHz (10 MHz/4). Si la valeur demandée ne se situe pas dans cette plage de fréquence, alors le pilote retourne le code d’erreur 1. Il retourne également ce même code d’erreur dans le cas où une erreur se produit dans l’initialisation des compteurs au moment de l’appel de la fonction pci_set_timer.

On calcule ensuite en fonction de la valeur globale du rapport de division les deux valeurs à placer dans timer0 et timer1.

Le dernier test permet de s’assurer que les deux valeurs timer0 et timer1 ne sont pas nulles. Le drivers retourne alors la fréquence de trigger réellement programmée. Dans le cas contraire, la fréquence demandée est impossible à réaliser et le driver retourne le code d’erreur 2.

Début

Figure 28 : Principe de détermination du diviseur

64

Dans le pilote d’origine, aucune précaution particulière n’est prise pour minimiser l’erreur entre la fréquence demandée et la fréquence réellement produite. Or, comme nous l’avons indiqué en préambule, il est primordial pour nous de pouvoir balayer au moins au centième de hertz près la fréquence de commande du moteur pas à pas afin d’obtenir une résolution suffisante des relevés. C’est sur ce point qu’a porté la modification des pilotes. L’organigramme de la Figure 29 décrit la stratégie optimisée de détermination du rapport de division des compteurs. La méthode choisie est une méthode itérative. Les bornes de recherche choisies pour hword, l’ont été de façon à ce que les rapports de division des deux timers soient du même ordre de grandeur sur la plage de fréquence d’utilisation courante du banc d’acquisition.

L’algorithme consiste dans un premier temps, dans la gamme des valeurs autorisées pour hword, à trouver celle qui se rapprochera le plus possible de la division entière de count par hword, autrement dit, celle qui générera le plus petit reste. Une fois cette valeur identifiée, il suffit de déterminer la valeur de lword correspondante pour obtenir le rapport de division souhaité. Naturellement nous aurions tout à fait pu balayer l’intégralité de la plage des valeurs comprises entre 2 et 2^16 pour hword, cependant cette solution nous est

Figure 29 : Optimisation du rapport de division

65

apparue beaucoup trop gourmande en temps de calcul. De plus cela s’est avéré inutile car nous avons bien vérifié a postériori que la solution retenue satisfaisait parfaitement au cahier des charges.

Le code C ainsi modifié est présenté Figure 30.

Alors que le PC hôte, sur lequel nous avons implanté notre banc d’acquisition automatisé, fonctionne sous Windows 98 Se, le code source des pilotes avait été écrit pour le système Windows 95. Ces deux systèmes présentant des différences fondamentales quant à la gestion du matériel et à la prise en compte des interruptions, nous avons dû également adapter des portions du code relatives à l’interfaçage de la carte avec le système d’exploitation. Cependant, ces modifications n’ayant pas d’incidences directes sur les caractéristiques fonctionnelles de notre banc d’acquisition, nous n’en parlons pas davantage.

UINT LIB_TYPE set_pt_trigger_rate(DWORD brdindex,REALTYPE ft, REALTYPE *actual) {

DWORD count;

UINT minhword,hword,lword;

double diff,min,quotient;

if( (ft < 0.0) || (ft > 2.5e6)) return(1);

count = (DWORD) ((10e6 /ft) + 0.5);

min = 10000; // Initialisation de la boucle for ( hword = 200; hword < 301; hword++ ) // Optimisation du facteur de division {

lword = UROUND((REALTYPE)count / (REALTYPE)hword);

// Configuration de la carte

if (pci416_set_timer(brdindex, TM_CONT_TRIGGER, hword, lword) != NOERROR)

return (1);

if( (hword | lword)) { // Valeur réelle de la fréquence de trigger

*actual = 10.0e6 / ((REALTYPE)hword * (REALTYPE)lword);

return(0);

}else{

return(2);

} }

Figure 30 : Extrait du code modifié du pilote

66