![[PNG] Mon logo Zite !](view.php/1.png "[PNG] Mon logo Zite !")
Principales fonctions du système Mensura, et quelques contraintes.
De nombreux langages de programmation sont "sensibles à la casse", c'est à dire qu'ils font la distinction entre majuscules et minuscules dans le nom des identificateurs, et en particulier dans les noms de fonctions. Par exemple, une variable nommée "mavariable" sera différente d'une variable nommée "MaVariable". Au contraire, d'autres langages ne font pas une telle différence.
La règle employée ici est de nommer les fonctions en lettres minuscules.
Les valeurs numériques entières seront de type "signé", codé sur 4 octets ("longint" des langages Pascal, "int" des langages C/C++,
Les valeurs réelles seront codées sur 8 octets ("double précision").
Les chaînes de caractères sont de type "pointeur de chaîne à zéro terminal". Fondamentalement, ce système peut fonctionner aussi bien avec le codage ANSI (1octet par caractère) qu'avec le codage Unicode (2 octets par caractère) mais dans la pratique, pour éviter les incompatibilités entre le programme d'application et le pilote, le mieux est d'utiliser par défaut le codage ANSI, et d'indiquer par un affixe spécifique le codage en Unicode-UTF8.
Le résultat des mesures est renvoyé comme un paramètre de sortie.
Les fonctions seront du type « function » de Pascal, ou des procédures renvoyant quelque chose pour C/C++, ou des fonctions renvoyant quelque chose pour les langages Basic. Les paramètres d'entrée sont transmis par valeur = par copie (pas d'indication particulière en Pascal, avec le mot-clé BYVAL en divers langages Basic).
Néanmoins, certains langages de programmation veulent les résultats sous forme de paramètre d'entrée-sortie transmis par référence (= par adresse = par variable), ce qui correspond à des « procédures » au sens du langage Pascal. On peut faire des fonctions ayant un suffixe « ref » qui auront des paramètres de ce type (mot clé var en Pascal, BYREF en Basic).
Fonctions numériques d'entrée et de sortie
Un appareil de mesure doit envoyer des mesures à l'ordinateur. par des fonctions d'entrées (les nombres entrent dans l'ordinateur à partir de l'appareil). Elles sont notées par la lettre E (comme Entrée)
Souvent, l'ordinateur peut commander à l'appareil de changer d'état, par exemple allumer une lampe ou un moteur.. Il faut donc des fonctions de sortie (les nombres sortent de l'ordinateur pour aller dans l'appareil, et modifier son fonctionnement). Elles sont notées par la lettre S (comme Sortie, ou Set).
Ces fonctions d'entrée et de sortie peuvent être binaires ou analogiques.
"Binaires" signifie qu'elles ne peuvent prendre seulement deux états (0/1), et on note ces fonctions par la lettre B.
"Analogiques" signifie qu'elles peuvent prendre une multitude de valeurs, par exemple une tension en volts ou millivolts, une température en degrés Celsius, une valeur de pH. On les note par la lettre A.
Souvent, ces valeurs analogiques sont fondamentalement des nombres entiers positifs, donnés par un convertisseur analogique/numérique ; elles peuvent aussi être des nombres entiers positifs ou négatifs, comme des millivolts : il n'y a pas de suffixe spécial pour ces valeurs entières. Dans d'autres cas, les valeurs analogiques peuvent être des "nombres réels", positifs ou négatifs, et qui ne sont pas des valeurs entières ;, en général, en informatique, ces nombres réels sont codés en "double précision", et on note ce dernier cas par un suffixe, la lettre D (comme "Double").
On a donc des fonctions notées eb, ea, ead, sb, sa, sad, qui portent un numéro.
En suivant une convention habituelle en informatique, les numéros commencent à zéro. eb(0) sera donc la première entrée binaire, et sad(1) la seconde sortie analogique, à laquelle on fixera une valeur codée comme un nombre réel
Normalement, ces numéros sont des nombres entiers, ainsi que les paramètres des fonctions binaires, alors que les entrées et sorties analogiques peuvent avoir des paramètres de type réel codés en double précision. Certains logiciels n'acceptent de travailler qu'avec des nombres de type "double précision", y compris pour les numéros des voies ; pour ce cas, on peut faire des fonctions se terminant par "double" : pour ces logiciels, on a ainsi les fonctions eadouble, ebdouble, sadouble, sbdouble (peu important : voir chapitre 6).
Noms de ces fonctions
Lorsque l'appareil n'a qu'une fonction, on ne peut utiliser que celle-ci ; par exemple avec un pHmètre, on ne peut que mesurer le pH. Lorsqu'un appareil a plusieurs fonctions, on doit choisir une de ces fonctions parmi plusieurs. Même pour un appareil à une seule fonction, on peut prévoir plusieurs variantes, selon les unités de mesures employées (température en degrés Celsius, ou en kelvins, ou en degrés Fahrenheit...)
Il est pratique d'associer une chaîne de caractère à chaque fonction numérique : ce sera le nom de la fonction. Lorsque le nom existe, cela signifie que la fonction numérique existe ; lorsque le nom n'existe pas (chaîne de caractères de longueur nulle), cela signifie que la fonction numérique n'existe pas. Ici, les fonctions donnant le nom des fonctions numériques sont notées par la lettre n : nead(0) signifie le nom de la première voie d'entrée analogique donnant un nombre réel, et nsb(1) est le nom de la deuxième sortie binaire.
Ainsi, on pourra faire apparaître ces noms dans des menus déroulants et des boites de dialogue.
Par défaut, ces fonctions utilisent le codage ASCII-ANSI ; si elles utilisent le codage Unicode-UTF8, ce sera indiqué par l'affixe « utf8 », par exemple cutf8nead, stdutf8detail...
Titre de l'appareil, et détail de cet appareil
La fonction "titre" sera une petite chaîne de caractères donnant le titre de l'appareil de mesure, que l'on pourra mettre au début de la boit de dialogue destinée au choix des voies.
"detail" sera une chaîne de caractères plus longue, pouvant donner des informations supplémentaires par rapport à "titre" : nom du programmeur, date de réalisation du pilote, etc.
Cal et calibration : fonctions facultatives
Certains appareils peuvent nécessiter des réglages supplémentaires. Par exemple, un appareil mesurant la teneur du milieu en dioxygène nécessite de "faire le zéro" en étalonnant la sonde, ou bien un spectrophotomètre nécessite de "faire le blanc" sur un témoin non coloré avant de mesurer une coloration. Dans ces cas là, une fonction de calibration peut ouvrir des boites de dialogue permettant ces réglages.
De nombreux appareils peuvent être réglés sans avoir besoin d'une telle fonction, par exemple en utilisant des fonctions fictives : une sortie binaire peut correspondre au choix d'un calibre, ou bien deux sorties analogiques peuvent permettre de régler le zéro et la pente d'un appareil.
Le plus simple est de faire une fonction « cal », sans aucun paramètre (c'est donc une procédure au sens du langage Pascal).
Les anciennes versions de Mensurasoft prévoyaient une fonction « calibration » avec ses deux variantes stdcalibration et ccalibration, avec une chaîne de caractères en entrée, et une chaîne de caractères en sortie. Dans la pratique, la chaîne de caractères était peu utile, et obligeait à tenir compte du problème des paramètres, alors que la fonction « cal », sans paramètres, est plus simple à utiliser.
Deux types de passage de paramètres : stdcall et cdecl
Pour que le programme principal et le pilote puissent échanger leurs informations, il faut qu'ils utilisent la même convention pour le passage des paramètres des fonctions. Malheureusement, il existe différentes possibilités, et les deux principales sont "stdcall" et "cdecl".
Pour que ce système de pilotes puisse fonctionner avec tous les langages de programmation, il faut qu'il puisse utiliser les deux types. De nombreux langages de programmation peuvent utiliser les deux conventions, mais certains ne peuvent en utiliser qu'un seul type. Dans le monde Windows, divers langages (Panoramic, FnxBasic...) ne peuvent utiliser que les fonctions stdcall, et les compilateurs C et C++ font beaucoup plus simplement les fonctions cdecl que les fonctions stdcall.
Les fonctions utilisant la convention cdecl commencent par la lettre c, et celles utilisant la convention stdcall commencent par std. Elles font exactement la même chose, et ne se distinguent que par le type de passage des paramètres.
On aura donc stdead et cead, stdeb et ceb, etc.
Attention à l'incompatibilité entre les bibliothèques dynamiques "32 bits" et "64 bits"
Les micro-ordinateurs ("PC") ont un microprocesseur travaillant sur un certain nombre de bits simultanément. Les premiers Apple II travaillaient sur 8 bits, les PC de 1990 travaillaient sur 16 bits, ceux de 2000 fonctionnaient sur 32 bits, et les nouveaux ordinateurs peuvent fonctionner avec 64 bits.
Pour exploiter au mieux ces microprocesseurs, les systèmes d'exploitation évoluent aussi, ainsi que les logiciels pouvant fonctionner avec ces systèmes d'exploitation.
Depuis Windows95 jusqu'à WindowsXP, les systèmes de Microsoft étaient en 32 bits, mais Windows7 est en 64 bits. Dans le monde Linux, actuellement (2014), on diffuse simultanément des versions 32 bits et 64 bits. Normalement, les systèmes d'exploitation en 64 bits peuvent quand même faire fonctionner les programmes compilés pour 32 bits.
De même, les compilateurs peuvent fonctionner soit en 32 bits, soit en 64 bits. Par exemple, PureBasic existe dans deux versions "x86" et "x64", pour chaque type de système d'exploitation.
Une bibliothèque dynamique 32 bits ne sera pas appelable par un programme principal conçu pour 64 bits, et une bibliothèque dynamique en 64 bits ne sera pas appelable par un programme en 32 bits.
Pour l'expérimentation par ordinateur, jusqu'à maintenant, il n'y a pas d'avantage net à faire des programmes pour 64 bits. Les logiciels développés jusqu'à maintenant sont conçus en 32 bits ("x86"). C'est donc la même chose pour les pilotes d'appareils de mesure, qui doivent être compatibles avec ces logiciels : ils doivent être compilés pour 32 bits.
Néanmoins, le principe de ces bibliothèques dynamiques est valable aussi bien en 32 bits qu'en 64 bits : il faut simplement les compiler avec des programmes différents.
Attention au problème de codage des chaînes de caractères : ANSI-ASCII ou Unicode-UTF8
En informatique, le codage ASCII-ANSI est le plus traditionnel, et fait correspondre à chaque caractère un octet, soit nombre entre 0 et 255. Ceci ne permet pas de représenter un grand nombre de caractères.
Le codage Unicode offre un beaucoup plus grand nombre de caractères possibles, puisque chaque caractère peut être codé sur deux ou plusieurs octets. Ceci permet d'utiliser, en plus de l'alphabet latin, les alphabets grec, cyrillique, arabe, japonais, etc. Une variante très utilisée du codage Unicode est appelée UTF8.
Fondamentalement, le système Mensurasoft travaille en mode ASCII-ANSI, le plus simple, où chaque caractère est codé par un octet. Ceci oblige à n'utiliser que les caractères latins dans les chaînes de caractères envoyées par le pilote, mais ce n'est normalement pas un gros problème ; les unités du système international étant en caractères latins, on peut imaginer que la plupart des noms des fonctions sont en caractères latins, par exemple des noms de voies de type « pH », ou « T (°C) », ou « T (K) », ou « mV », etc.
Ceci n'empêche pas le logiciel d'application de travailler en mode Unicode, avec des menus déroulants et des boites de dialogue en caractères cyrilliques ou arabes.
Si l'on veut introduire des caractères Unicode dans les chaînes de caractères transmises par les pilotes, c'est possible. Mais il y a des difficultés lorsqu'un logiciel attend des caractères Unicode et qu'il communique avec un pilote en ASCII-ANSI : les chaînes de caractères affichées sont de type idéogrammes. Il y a aussi des difficultés lorsqu'un logiciel attend des caractères ASCII-ANSI et qu'il communique avec un pilote en Unicode : les chaînes de caractères sont tronquées car il existe des octets de valeur 0 dans les caractères Unicode.
Donc le mieux est de considérer que les logiciels Mensurasoft doivent fonctionner fondamentalement en ASCII-ANSI, et qu'il faut faire des fonctions spéciales pour communique en Unicode-UTF8 ; ces fonctions spéciales auront le même nom que les fonctions normales, avec un affixe UTF8 placé vers le début. On aura ainsi UTF8detail, UTF8titre, UTF8nead, UTF8nsb, avec les variantes std et c selon la transmission des caractères : stdUTF8nsb, cUTF8nead, etc.
Ceci permet d'utiliser les mêmes pilotes avec tous les logiciels d'application.
Il n'est pas toujours simple de faire des pilotes ayant les deux types de codage. C'est possible, assez simplement, avec FreePascal/Lazarus, en utilisant l'unité lazutf8.
Dernière modification le 10/03/2018