Discussion :

[-Willis-]

Bonjour,

dans le cadre d'un projet je souhaiterais écrire un "driver" qui permettrait de communiquer avec une carte comprenant 4 relais ON/OFF et une seconde carte d'acquisition de données via un port série virtuel.
La première carte commande l'état 4 alimentations haute tension (allumées ou éteintes) qui doivent être intégrées dans une machine plus complexe.
La deuxième carte permet de lire le courant débité par les alimentations.

J'ai déjà écrit un code en C qui permet de contrôler ces cartes.

Le constructeur de la machine complexe souhaite pouvoir contrôler les alimentations hautes tensions et lire les courants dans son programme principal (je ne connais pas le langage utilisé) à partir de commande ascii type "HV1 set ON" ce qui correspondrait à "met l'alimentation haute tension n°1 en marche" ou encore "HV2 read current" pour connaitre le courant débité par l'alimentation haute tension n°2.
L'idée étant de faire quelque chose qui soit complétement indépendant de l'environnement du constructeur d’où le port série virtuel.

Quelle est démarche à suivre pour faire cela à partir de mon code C ?

Merci pour votre aide.

[sambia39]

Bonsoir,
C'est plus un problème programmation système qu'orienté langage de programmation C et encore faudrait-il que l'on voie votre code source; sans oublier une information essentielle qui le système d'exploitation pour lequel le pilote va interagir, car d'un système d'exploitation à un autre, l'implémentation des pilotes n'est pas identique.
Il y a également des ressources sur le site dans la section tutoriels qui peut être un bon point de départ.
à bientôt.

[chrtophe]

On pars sur le postulat que tu as un port série installé (ou un port série via un adaptateur USB)

Il te faut un langage de communication entre l'ordi et ta carte.

Exemple, tu envois un octet ou les 4 premiers bits correspondant à la commande souhaitée et les 4 derniers bits à l'option de celle-ci.
Pour améliorer, tu peux aussi envoyer avant 1 ou 2 octets qui servent de signature nécessaire à la prise en compte, et idem pour la réception des données par l'ordi.

La logique de la ou des cartes devra correspondre à l’implémentation.

Vu que tu as deux cartes, soit tu relie chacune d'elles au pc via un port série autonome, soit relie les deux aux même port, et gère la communication avec le système de signatures évoqués.

L'arduino ou le rapberry seront deux bons candidats, tu auras aussi la logique de connexion aux cartes à gérer.

[-Willis-]

Tout d'abord, merci pour vos réponses respectives !

Effectivement mon post n'est peut être pas au bon endroit, je n'était pas sur de où poser ma question...

Pour préciser mon premier post, les 2 cartes que je possède sont des cartes du commerce (Phidget InterfaceKit 0/0/4 pour les relais et usb 231 pour les mesures) dont les constructeurs fournissent tout ce qu'il faut pour les piloter en C, ce que j'ai fait. Ces 2 cartes se branchent en USB.
C'est pour ça que j'ai mis driver entre guillemet car tout est prêt pour communiquer avec les cartes.

Mon client souhaite une couche supplémentaire pour dialoguer avec notre instrument (donc les 2 cartes) dans leur programme via des commandes simples et que tout ça soit indépendant du langage qu'ils utilisent.
En gros connaissant la bibliothèque de commandes que je leur fournit, il ouvre la communication avec notre instrument (qui est en fait les 2 cartes) à la manière d'un port série et lui envoie les instructions.
Leur PC de commande tourne sous Windows.

Ci-dessous un exemple de code qui permet de contrôler l'état d'une des 4 voies de la carte relai

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#include <stdio.h>
#include <C:/Program Files/Phidgets/Phidget22/phidget22.h>
 
 
//Declare any event handlers here. These will be called every time the associated event occurs.
 
static void CCONV onAttach(PhidgetHandle ch, void * ctx)
{
	int channel;
 
	//Getting the channel number to distinguish between Phidgets
	Phidget_getChannel(ch, &channel);
	printf("Attach [%d]!\n\n", channel);
}
 
static void CCONV onDetach(PhidgetHandle ch, void * ctx)
{
	int channel;
 
	//Getting the channel number to distinguish between Phidgets
	Phidget_getChannel(ch, &channel);
	printf("Detach [%d]!\n\n", channel);
}
 
int set_HV_State(channel,relayStatus)
{
    PhidgetDigitalOutput_setState(channel, relayStatus);
    return relayStatus;
}
 
int main()
{
    int hvState = 0;
 
	//Declare your Phidget channels and other variables
	PhidgetDigitalOutputHandle digitalOutput0;
 
	//Create your Phidget channels
	PhidgetDigitalOutput_create(&digitalOutput0);
 
	//Set addressing parameters to specify which channel to open (if any)
	Phidget_setDeviceSerialNumber((PhidgetHandle)digitalOutput0, 502246);
 
	//Assign any event handlers you need before calling open so that no events are missed.
	Phidget_setOnAttachHandler((PhidgetHandle)digitalOutput0, onAttach, NULL);
	Phidget_setOnDetachHandler((PhidgetHandle)digitalOutput0, onDetach, NULL);
 
	//Open your Phidgets and wait for attachment
	Phidget_openWaitForAttachment((PhidgetHandle)digitalOutput0, 5000);
 
	//Do stuff with your Phidgets here or in your event handlers.
	hvState = 1;
 
    set_HV_State(digitalOutput0,hvState);
 
	//Wait until Enter has been pressed before exiting
	getchar();
 
	//Close your Phidgets once the program is done.
	Phidget_close((PhidgetHandle)digitalOutput0);
 
	PhidgetDigitalOutput_delete(&digitalOutput0);
}

[dagos]

Salut,
Si je comprends bien, tu veux améliorer un programme qui permet déjà de dialoguer avec les 2 cartes.
Pour lui ajouter un serveur de commandes appelé par un autre programme dont tu ne connais pas le langage, je ferrais ça avec un socket TCP/IP en C puisque ton code est déjà en C.
Dans ton programme, à l'initialisation tu démarrer le socket serveur, puis tu viens lire en boucle le socket. Dès que ton client enverra une commande, il faudra la décoder et appeler les fonctions Phidget pour réaliser l'action correspondante.
C'est plus simple qu'avec un port série virtualisé à mon avis.

[sambia39]

Personnellement, passé en socket TCP/IP, c'est un peu excessif. Étant donné que le constructeur des cartes a fourni les différents codes sources (API) alors pourquoi ne pas écrire un programme qui fait appel directement aux différentes fonctions (API du constructeur) ? Et donc, plus besoin de pilote ou tout autres choses. Sauf si votre employeur souhaite vraiment utiliser un driver; alors dans ce cas, il faut écrire des pilotes pour les plateformes visées.

[-Willis-]

Salut,
Si je comprends bien, tu veux améliorer un programme qui permet déjà de dialoguer avec les 2 cartes.
Pour lui ajouter un serveur de commandes appelé par un autre programme dont tu ne connais pas le langage, je ferrais ça avec un socket TCP/IP en C puisque ton code est déjà en C.
Dans ton programme, à l'initialisation tu démarrer le socket serveur, puis tu viens lire en boucle le socket. Dès que ton client enverra une commande, il faudra la décoder et appeler les fonctions Phidget pour réaliser l'action correspondante.
C'est plus simple qu'avec un port série virtualisé à mon avis.

Oui c'est exactement ce que je cherche à faire.
La solution que tu proposes pourrait tout à fait convenir, merci !

Personnellement, passé en socket TCP/IP, c'est un peu excessif. Étant donné que le constructeur des cartes a fourni les différents codes sources (API) alors pourquoi ne pas écrire un programme qui fait appel directement aux différentes fonctions (API du constructeur) ? Et donc, plus besoin de pilote ou tout autres choses. Sauf si votre employeur souhaite vraiment utiliser un driver; alors dans ce cas, il faut écrire des pilotes pour les plateformes visées.

Merci pour ta réponse !

On pars sur le postulat que tu as un port série installé (ou un port série via un adaptateur USB)

Il te faut un langage de communication entre l'ordi et ta carte.

Exemple, tu envois un octet ou les 4 premiers bits correspondant à la commande souhaitée et les 4 derniers bits à l'option de celle-ci.
Pour améliorer, tu peux aussi envoyer avant 1 ou 2 octets qui servent de signature nécessaire à la prise en compte, et idem pour la réception des données par l'ordi.

La logique de la ou des cartes devra correspondre à l’implémentation.

Vu que tu as deux cartes, soit tu relie chacune d'elles au pc via un port série autonome, soit relie les deux aux même port, et gère la communication avec le système de signatures évoqués.

L'arduino ou le rapberry seront deux bons candidats, tu auras aussi la logique de connexion aux cartes à gérer.

En fait je suis en train de me demander si ce n'est pas la solution la plus simple : intégrer un raspberry ou un arduino dans notre rack qui servira d'interface entre le matériel du client et le mien. Mon programme tourne sur le rasp/arduino et récupère les commandes venant du système du client. Ainsi mon système est complétement autonome et indépendant du leur (c'est ce que le client veut).

Qu'est-ce que vous en pensez ?

[dagos]

Salut,
Effectivement une raspberry/arduino dans le rack semble pas mal, de cette façon tu n'auras plus qu'un seul câble entre le rack et le PC.
Par contre, je te déconseille de connecter les 2 UART des deux cartes ensemble sur le même port UART de la raspberry/arduino, car le lien série n'est pas un bus est n'est pas conçu pour communiquer entre 3 éléments, même avec un protocole comme proposé plus haut. Car dans ce cas, les 2 TX des 2 cartes seront reliés, ce qui peut au bout d'un moment finir par les cramer, même si ça fonctionnera au début.
Fais par contre attention, jusqu'à la Raspberry 3, il n'y a qu'un seul port UART. Donc il te faut au moins la 4 ou un arduino.
Pour la communication avec le PC, tu peux (au plus simple) soit passer par le port Ethernet (via un socket, effectivement peut être surdimensionné aux besoins), soit connecter un 3ème UART. Je dirais à voir ce que préfère ton client.

[sambia39]

Les deux équipements utilisent l'USB, ce qui veut dire en termes simples que tous équipements industriels ou autres qui utilisent de l'USB ont de facto un driver/pilote nécessaire pour communiquer et contrôler le matériel; on parle de stack USB, ce qui désigne l'API ou l'ensemble des microprogrammes, modules de noyau, pilotes ou de programmes qui permettent d'établir une communication entre le matériel et l'ordinateur via une liaison USB et de le contrôler. Vous ne pouvez donc pas demander à une application de faire des requêtes en dehors de celles acceptées par un driver, d'autant plus que c'est le driver qui a la capacité de connaitre les GUID; VID ou PID et de contrôler le matériel.


Donc, la fausse bonne idée de rajouter une stack network (qui désigne pile réseau) avec certaines fonctions de l'API du fabricant, sans oublier le choix complémentaire de la nano-ordinateur ou carte à microcontrôleur (Arduino), dans le but d'avoir une seule connexion avec le PC final (sachant que le fabricant propose une application serveur voire même les sources de l'application serveur) pour part la suite faire appel aux bonnes fonctions du driver, c'est une perte de temps. Je me permets donc, d'en douter pour la suite ; sans prendre en compte que si un Raspberry est utilisé, il va falloir sérieusement revoir les choses. Plus clairement, prendre en compte les problématique liée à la sécurité (pensé à la sécurité du système d'exploitation : identifications des points de sensibilité ; définir et appliquer une politique de sécurité efficace : déployer des configurations fortes ; isoler l'exécution des applications ; etc. ça rajoute des couches supplémentaires.) Bref, pour moi, Arduino/Raspberry n'ont pas lieu d'être.


Ceci dits; l'employeur souhaite avoir sa propre interface pour contrôler les deux équipements, et pour ça il y a à disposition non seulement les drivers, mais également un ensemble de codes sources fournis par les fabricants. A partir de là, le travail devient un peu plus souple. Pour comprendre, prenons le cas du système d'exploitation Windows (sans trop rentrer dans les détails) : quand un périphérique USB est connecté ou détecté par le système d'exploitation Windows, ce dernier procède alors à une énumération afin d'obtenir les informations d'identification vendeur et périphériques (les fameux VID et PID) pour trouver le pilote qui gère le périphérique et si ce dernier est connu, alors Windows va interroger sa base du registre. Cas contraire, il demandera s'il existe un pilote pour ce périphérique que vous devez fournir : soit le vôtre, soit celui du constructeur.


Considérant maintenant que le pilote existe et est installé, Windows va donc utiliser le driver "machinbidule.sys" ou autres pour dialoguer avec un programme qui va utiliser l'ensemble des codes source ou API fourni par le fabricant. Et a travers les diverses fonctions de cette API le système d'exploitation Windows va procéder a l'ouverture d'une liaison nommée, en utilisant les GUID (qui est un identifiant unique) respectives des deux périphériques connecter; pour que le programme puisse s'interfacer avec les drivers; d'où la raison de mon premier message : celui de connaître les codes sources de l'API et les sources de votre programme, qui aux finales, on a qu'une petite partie (pour le cas de Phidget Interface Kit 0.0.4 c'est-à-dire le relais quant à USB 231 aucune information), mais surtout évaluer s'il est possible à partir de tous ces éléments d'avoir la possibilité d'écrire un pilote générique idée de départ; capable de communiquer avec les deux équipements. En termes plus techniques, un driver pour périphériques multiples. Cependant, avec l'option d'un pilote générique, cela implique concrètement d'avoir un point d'entrée vers les différents pilotes et là aussi cela est peut envisageable.

Bref, de toute façon, c'est à vous de voir....

[-Willis-]

Salut,
Effectivement une raspberry/arduino dans le rack semble pas mal, de cette façon tu n'auras plus qu'un seul câble entre le rack et le PC.
Par contre, je te déconseille de connecter les 2 UART des deux cartes ensemble sur le même port UART de la raspberry/arduino, car le lien série n'est pas un bus est n'est pas conçu pour communiquer entre 3 éléments, même avec un protocole comme proposé plus haut. Car dans ce cas, les 2 TX des 2 cartes seront reliés, ce qui peut au bout d'un moment finir par les cramer, même si ça fonctionnera au début.
Fais par contre attention, jusqu'à la Raspberry 3, il n'y a qu'un seul port UART. Donc il te faut au moins la 4 ou un arduino.
Pour la communication avec le PC, tu peux (au plus simple) soit passer par le port Ethernet (via un socket, effectivement peut être surdimensionné aux besoins), soit connecter un 3ème UART. Je dirais à voir ce que préfère ton client.

Est-ce tu confirmes que par exemple un arduino mega pourrait gérer mes 2 cartes ?
Si j'équipe l'arduino avec un shield ethernet, je n'aurais plus qu'à écrire un programme embarqué sur l'arduino qui récupère les commandes de l'utilisateur et pilotent les 2 cartes.
Du côté de l'utilisateur, lui n'a qu'un socket à ouvrir et envoyer les bonnes lignes de caractères.

[-Willis-]

Les deux équipements utilisent l'USB, ce qui veut dire en termes simples que tous équipements industriels ou autres qui utilisent de l'USB ont de facto un driver/pilote nécessaire pour communiquer et contrôler le matériel; on parle de stack USB, ce qui désigne l'API ou l'ensemble des microprogrammes, modules de noyau, pilotes ou de programmes qui permettent d'établir une communication entre le matériel et l'ordinateur via une liaison USB et de le contrôler. Vous ne pouvez donc pas demander à une application de faire des requêtes en dehors de celles acceptées par un driver, d'autant plus que c'est le driver qui a la capacité de connaitre les GUID; VID ou PID et de contrôler le matériel.


Donc, la fausse bonne idée de rajouter une stack network (qui désigne pile réseau) avec certaines fonctions de l'API du fabricant, sans oublier le choix complémentaire de la nano-ordinateur ou carte à microcontrôleur (Arduino), dans le but d'avoir une seule connexion avec le PC final (sachant que le fabricant propose une application serveur voire même les sources de l'application serveur) pour part la suite faire appel aux bonnes fonctions du driver, c'est une perte de temps. Je me permets donc, d'en douter pour la suite ; sans prendre en compte que si un Raspberry est utilisé, il va falloir sérieusement revoir les choses. Plus clairement, prendre en compte les problématique liée à la sécurité (pensé à la sécurité du système d'exploitation : identifications des points de sensibilité ; définir et appliquer une politique de sécurité efficace : déployer des configurations fortes ; isoler l'exécution des applications ; etc. ça rajoute des couches supplémentaires.) Bref, pour moi, Arduino/Raspberry n'ont pas lieu d'être.


Ceci dits; l'employeur souhaite avoir sa propre interface pour contrôler les deux équipements, et pour ça il y a à disposition non seulement les drivers, mais également un ensemble de codes sources fournis par les fabricants. A partir de là, le travail devient un peu plus souple. Pour comprendre, prenons le cas du système d'exploitation Windows (sans trop rentrer dans les détails) : quand un périphérique USB est connecté ou détecté par le système d'exploitation Windows, ce dernier procède alors à une énumération afin d'obtenir les informations d'identification vendeur et périphériques (les fameux VID et PID) pour trouver le pilote qui gère le périphérique et si ce dernier est connu, alors Windows va interroger sa base du registre. Cas contraire, il demandera s'il existe un pilote pour ce périphérique que vous devez fournir : soit le vôtre, soit celui du constructeur.


Considérant maintenant que le pilote existe et est installé, Windows va donc utiliser le driver "machinbidule.sys" ou autres pour dialoguer avec un programme qui va utiliser l'ensemble des codes source ou API fourni par le fabricant. Et a travers les diverses fonctions de cette API le système d'exploitation Windows va procéder a l'ouverture d'une liaison nommée, en utilisant les GUID (qui est un identifiant unique) respectives des deux périphériques connecter; pour que le programme puisse s'interfacer avec les drivers; d'où la raison de mon premier message : celui de connaître les codes sources de l'API et les sources de votre programme, qui aux finales, on a qu'une petite partie (pour le cas de Phidget Interface Kit 0.0.4 c'est-à-dire le relais quant à USB 231 aucune information), mais surtout évaluer s'il est possible à partir de tous ces éléments d'avoir la possibilité d'écrire un pilote générique idée de départ; capable de communiquer avec les deux équipements. En termes plus techniques, un driver pour périphériques multiples. Cependant, avec l'option d'un pilote générique, cela implique concrètement d'avoir un point d'entrée vers les différents pilotes et là aussi cela est peut envisageable.

Bref, de toute façon, c'est à vous de voir....

Wow merci pour cette réponse très complète.
Effectivement dans l'idéal je suis d'accord que c'est la solution la plus propre.
Malheureusement je pense être trop limite en compétences compte tenu du temps imparti (en gros dans 2 mois ça doit être plié et je ne peux y consacrer que 15-20% de mon temps sachant que ce n'est pas mon métier du tout...).
Je m'étais posé la question du problème de sécurité sans trop creuser. Mais si on discute sur un réseau local avec un arduino quels sont les risques ?

[dagos]

Salut,
Je n'avais pas compris que les cartes étaient connectées en USB... Mon post précédent est du coup erroné.
Il y a effectivement 2 approches:

1. Développer une interface, avec une Raspberry/Arduino.
Dans ce cas, il faut s'assurer que le code fourni fonctionne bien sur Raspberry/Arduino pour commander les cartes.
En lisant les docs, les drivers fournis pour la carte USB-231 ne fonctionnent que sous Windows:
"The USB-231 is a high-speed data acquisition USB board supported under the Windows® operating system."
Donc c'est mort pour utiliser cette solution.

2. Développer un soft qui servira d'interface en s'appuyant sur les drivers USB des deux cartes (drivers que tu devra peut être produire à partir du code fourni).
Dans ce cas, il faut voir que, encore une fois, si le code fourni tourne uniquement sous Windows, ton soft tournera uniquement sous Windows.
Du coup il faudrait voir quel OS ton client veut utiliser. Car si ce n'est pas Windows, il faudra prévoir un PC Windows pour faire l'interface.
Tu peux aussi mettre un Hub USB alimenté dans ton rack, ce qui permet de n'avoir qu'un seul câble vers le PC.
Je ne connais pas bien le développement driver sous Windows mais je crois bien qu'il faut un outil genre Windows Driver Kit (payant).

[-Willis-]

Salut,
Je n'avais pas compris que les cartes étaient connectées en USB... Mon post précédent est du coup erroné.
Il y a effectivement 2 approches:

1. Développer une interface, avec une Raspberry/Arduino.
Dans ce cas, il faut s'assurer que le code fourni fonctionne bien sur Raspberry/Arduino pour commander les cartes.
En lisant les docs, les drivers fournis pour la carte USB-231 ne fonctionnent que sous Windows:
"The USB-231 is a high-speed data acquisition USB board supported under the Windows® operating system."
Donc c'est mort pour utiliser cette solution.

Effectivement si l'usb231 ne peut pas être piloté c'est mort. Apparemment il y a un package pour linux mais pas sur que cette carte en particulier soit supportée...

2. Développer un soft qui servira d'interface en s'appuyant sur les drivers USB des deux cartes (drivers que tu devra peut être produire à partir du code fourni).
Dans ce cas, il faut voir que, encore une fois, si le code fourni tourne uniquement sous Windows, ton soft tournera uniquement sous Windows.
Du coup il faudrait voir quel OS ton client veut utiliser. Car si ce n'est pas Windows, il faudra prévoir un PC Windows pour faire l'interface.
Tu peux aussi mettre un Hub USB alimenté dans ton rack, ce qui permet de n'avoir qu'un seul câble vers le PC.
Je ne connais pas bien le développement driver sous Windows mais je crois bien qu'il faut un outil genre Windows Driver Kit (payant).

Pour ce client en particulier ça sera windows mais il se peut demain nous ayons un autre client dont le système est sous linux.
Si on développe une solution multiplateforme/autonome ça serait nickel, c'est pourquoi l'embarqué est séduisant, quitte à choisir des cartes adaptées.

[-Willis-]

Après échange avec le client, la solution d'inclure un raspberry dans notre rack lui convient.
Je vais donc partir sur cette solution.
Merci pour votre aide !