Principe fondamental : utiliser des "pilotes d'appareils de mesure", spécifiques de l'appareil utilisé, pour faire des logiciels généralistes.

Très (trop ?) grande diversité du matériel

Lorsqu'un programmeur rédige un logiciel de mesure, il ne peut pas le concevoir d'emblée capable de fonctionner avec tous les appareils ou interfaces de mesure. Même si il a la liste de tous les appareils existant actuellement, il ne peut pas prévoir ceux qui seront inventés l'année prochaine. Il faut donc qu'il rédige un logiciel "adaptable", qui pourra s'adapter aux appareils à venir.
C'est le même problème que pour les logiciels de traitement de texte et les imprimantes : il est impossible de faire un logiciel qui tienne compte des particularités de toutes les imprimantes. C'est pourquoi ces logiciels fonctionnent avec des "pilotes d'imprimantes", ou "drivers", qui sont spécifiques du matériel en question.

Pour ce qui est du matériel de mesure connectable à l'ordinateur, il y a une grande diversité : certains appareils sont des cartes à enficher à l'intérieur de l'ordinateur, d'autres sont des appareils à brancher sur une prise sérielle RS232, d'autres sur la prise parallèle, ou bien sur la prise "manettes de jeux", etc.

Dans les explications qui suivent, il sera surtout question du boitier ADES, diffusé par la Maison des Enseignants de Provence. C'est un petit boitier à brancher sur la prise parallèle (prise "imprimante"), et qui a deux entrées analogiques sur 10 bits (normalement entre 0 et 5 V) et 4 sorties logiques sous forme de relais. Des adaptateurs lui permettent d'utiliser les capteurs de Calibration, fondamentalement conçus pour être utilisés avec les calculettes de la série TI82 (mesure d'oxygène, de pH, etc).
Il sera aussi question de l'interface Orphy-GTS, diffusée par Micrelec, et qui possède un grand nombre d'entrées et de sorties logiques et analogiques. Cet appareil doit être connecté sur une prise série.
A partir de ces deux appareils, on peut imaginer que les solutions envisagées sont universelles.

Ce que sont les DLL ("Dynamic linked library" = librairies à liaison dynamique) de Windows

Les DLL sont des morceaux de programme que l'on rédige à l'aide d'un langage de programmation de type Delphi, C++ ou Basic. Ces DLL contiennent des fonctions que l'on peut appeler à partir d'un logiciel d'application exécutable, lui aussi rédigé à l'aide d'un langage de programmation.

Dans le système proposé ici, chaque DLL de mesure sera caractéristique d'un appareil de mesure (ou d'une façon d'utiliser cet appareil). La DLL contiendra les fonctions de communication avec l'appareil de mesure : lecture des entrées analogiques et logiques, commande des sorties logiques et analogiques, ainsi que des fonctions de service : indication du nom de l'appareil, de la version du pilote, du nom et du nombre des voies d'entrée et de sortie, de l'état des sorties, etc. C'est la DLL qui est capable d'envoyer les bons signaux sur la voie RS232, ou bien de changer l'état des ports de l'ordinateur... Par contre, la DLL ne fera pas les travaux compliqués tels que le traçage des graphiques des points de mesure, ou bien la sauvegarde des résultats dans un fichier compatible avec les tableurs...

Le logiciel d'application lui-même appellera les fonctions de la DLL (lecture des entrées et commande des sorties...). Il ne se posera pas le problème de savoir comment faire les mesures : il enverra simplement l'ordre à la DLL de faire la mesure et de lui renvoyer le résultat. Ensuite, c'est ce logiciel d'application qui utilisera les résultats pour les présenter à l'utilisateur, soit sous forme d'un tableau, soit sous forme d'un graphique, soit sous forme d'un cadran à aiguille, soit par une alarme qui se déclenche lorsqu'un seuil est dépassé, etc.

Ce système fonctionne correctement depuis plusieurs années avec les logiciels de la famille Mesugraf pour Windows. Ce logiciel est développé en Delphi 1, qui est un langage de type Pascal, conçu pour les versions 16 bits de Windows (Windows 3.1). Il fonctionne avec un grand nombre d'appareils de mesures (Orphy GTS et portable, Jeulin ESAO3, ADES, Pierron SMF10 et Expert, et un grand nombre de multimètres, luxmètres, thermomètres, balances... à brancher sur une prise sérielle).
Je propose de développer ce système pour faire des logiciels avec les versions 32 bits de Windows, ainsi qu'avec Linux. Les DLL développées pour Windows 16 bits ne sont pas utilisables avec ces systèmes. Bien que basées sur le même principe, les librairies pour ces systèmes doivent être légèrement modifiées et recompilées pour pouvoir fonctionner.

Où trouver des renseignements sur les bibliothèques dynamiques ?

Malheureusement, les livres de programmation documentent rarement les fonctions permettant de créer ou d'utiliser des bibliothèques de fonctions extérieures à chargement dynamique.
Un bon site internet sur ces bibliothèques dynamiques, aussi bien pour Windows que pour Linux, en allemand, est :
http://www.wachtler.de/dynamischeBibliotheken/dynamischeBibliotheken.html

Problèmes des «conventions d'appel»

Dans le détail, il y a quelques complications, en particulier à cause du passage des paramètres.
Selon la façon dont l'échange est fait entre le programme principal et la librairie, on peut distinguer plusieurs possibilités :

Directive en C++Builder	Directive en Delphi-Pascal	Ordre des paramètres	Nettoyage	Transfert de paramètre dans les registres	transformation du nom de la fonction «mafonction» par C++Builder
__fastcall	register (par défaut)	De gauche à droite	Routine	Oui	@mafonction
pascal ou __pascal	pascal	De gauche à droite	Routine	Non	pascal : mafonction __pascal : MAFONCTION
cdecl ou __cdecl (par défaut)	cdecl	De droite à gauche	Appelant	Non	cdecl : @mafonction __cdecl : _mafonction
__stdcall	stdcall	De droite à gauche	Routine	Non	mafonction
	safecall	De droite à gauche	Routine	Non	(pour des «méthodes d'interface dual», sans intérêt ici)

Il y a donc un double problème :
D'une part, il faut que la convention d'appel soit la même pour la librairie et le programme appelant.
D'autre part, il faut qu'il n'y ait pas de problèmes de nom, c'est à dire que le programme appelant trouve bien la fonction avec le nom qu'il cherche. Or C++Builder change souvent le nom des fonctions ! Si, dans le texte-source, on déclare une fonction avec le nom mafonction (par la syntaxe int __fastcall mafonction(int n) ), en fait, le programme écrit en Delphi devra chercher la fonction @mafonction !
C'est une source d'embrouilles multiples.
Par conséquent, le mieux est de choisir d'utiliser une convention d'appel possible à la fois en Delphi et en C++, et qui ne pose pas de problème de nommage. Le mieux est de choisir la convention «stdcall», d'autant plus que std signifie «standard», et que la standardisation est justement notre propos.