IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

port serie virtuel


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2012
    Messages : 14
    Par défaut port serie virtuel
    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.

  2. #2
    Membre très actif
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    Mai 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Mai 2010
    Messages : 548
    Par défaut
    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.

  3. #3
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    18 258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 18 258
    Par défaut
    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation

  4. #4
    Membre averti
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2012
    Messages : 14
    Par défaut
    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);
    }

  5. #5
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    23
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 23
    Par défaut
    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.

  6. #6
    Membre très actif
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    Mai 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Mai 2010
    Messages : 548
    Par défaut
    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.

  7. #7
    Membre averti
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Santé

    Informations forums :
    Inscription : Mars 2012
    Messages : 14
    Par défaut
    Citation Envoyé par dagos Voir le message
    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 !

    Citation Envoyé par sambia39 Voir le message
    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 !

    Citation Envoyé par chrtophe Voir le message
    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 ?

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. port serie virtuel et java urgent
    Par never-land0 dans le forum Développement Mobile en Java
    Réponses: 0
    Dernier message: 05/09/2008, 17h23
  2. piloter un port usb via un port serie virtuel?
    Par passion_info dans le forum C++Builder
    Réponses: 2
    Dernier message: 10/10/2006, 12h56
  3. [DRIVER]Développer drivers port serie virtuel
    Par f.colo dans le forum Windows
    Réponses: 9
    Dernier message: 21/02/2006, 08h41
  4. [TP] port série rs232
    Par cyb33 dans le forum Turbo Pascal
    Réponses: 44
    Dernier message: 13/01/2003, 15h49
  5. [Kylix] Kylix / port serie
    Par Anonymous dans le forum EDI
    Réponses: 3
    Dernier message: 01/04/2002, 12h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo