Discussion :

[Koko33]

Bonsoir,

Je me lance dans l'utilisation de driver d'un instrument et je ne sais pas par où commencer. Je dois en fait programmer en C non pas un driver mais un logiciel qui utilise un driver...D'habitude quand il y a des drivers je fait appel à LabView même si je n'aime pas ce langage je connais les rudiments. Mais pour ce qui est du C, comment peut-on récupérer des infos du drivers en continu ????? Ca s'intègre comment concrètement?

Y-a-t-il des bibli ou des tutos qui pourraient m'être utiles? Pour l'OS il faudrait que ce soit portable Linux et Seven même si dans l'absolu je peux me débrouiller avec un code pour chacun , le tout est que les deux cas soient traités. Merci d'avance pour vos idées et réponses.

[Obsidian]

Bonsoir,

Je me lance dans l'utilisation de driver d'un instrument

Quel est cet instrument ?

et je ne sais pas par où commencer. Je dois en fait programmer en C non pas un driver mais un logiciel qui utilise un driver...D'habitude quand il y a des drivers je fait appel à LabView même si je n'aime pas ce langage je connais les rudiments. Mais pour ce qui est du C, comment peut-on récupérer des infos du drivers en continu ????? Ca s'intègre comment concrètement?

Un pilote de périphérique (device driver) est simplement un logiciel qui permet d'exploiter un périphérique donné et propre à son constructeur à partir d'ordres génériques envoyés par le système d'exploitation que tu utilises.

Ça veut dire qu'en pratique, quand tu écris une application, tu n'appelles jamais directement les fonctions du pilote. C'est le système d'exploitation qui va le faire pour toi, en choisissant le bon en fonction des circonstances.

Ça signifie également qui n'existe pas une seule façon universelle d'écrire un pilote. Du côté du périphérique, il devra respecter les spécifications du constructeur (et sera donc ultra-spécialisé, par définition) et du côté du système d'exploitation, il devra respecter une interface commune à tous les pilotes mais spécialisée dans son domaine : on n'exploite pas de la même façon une carte réseau et une imprimante, par exemple.

En outre, chaque système d'exploitation a sa propre façon de gérer le matériel, et de travailler d'une manière générale. Donc, l'interface côté utilisateur du pilote sera propre à chaque système d'exploitation.

[Koko33]

Il s'agit d'un gros voltmètre en quelque sorte. Merci pour ces explications j'ai jamais travaillé sur driver en C et ca me rébute un peu sans trop savoir pourquoi je dois dire! Donc niveau pilote, je le lance comme un logiciel, ce sera OK s'il est adapté à l'OS mais après? Comment par exemple je peux aller voir dans le buffer de réception de données mettons? Où est-il accessible? Car je fais mon programme d'un côté, le driver tourne de l'autre mais j'ai du mal à voir où se fait le lien.

Si je simplifie mon problème, j'ai un voltmètre qui lit des valeurs et les stocke par paquet de 16 par exemple puis je veux les lire avant que le buffer du dit voltmètre ne soit détruit et renouvelé, où va-t-on les chercher? Il faut bien une passerelle entre les deux non?

[ternel]

Bonjour,
Normalement, tu as une spécification de l'interface programmatique/système/de développement/C (rayer les mentions inutiles), fournie par le constructeur.
Dedans, il y a une description du mode de communication. Ca peut être une liaison série (dont usb), une socket, un microcontroleur intermédiaire, ou autre.
Tout devrait être décrit dans ce document.

[Metalman]

Tu peux par ailleurs demander au constructeur de te donner des exemples de code par mail en plus de la documentation...

Parfois, tu devras peut être signer une NDA (Non Disclosure Agreement) et la renvoyer par courrier, car le constructeur t'envoie toutes les sources, et qu'il ne veut pas que cela fuite...

C'est ce que j'ai fais pour un device spécial, et cela m'a été très utile.

[Obsidian]

Il s'agit d'un gros voltmètre en quelque sorte.

À quel port de ta machine est relié ce voltmètre ? Le port série (RS/232) ? Le port parallèle (imprimante) ? L'USB ? Ou est-ce une carte directement installée dans le PC ?

Merci pour ces explications j'ai jamais travaillé sur driver en C et ca me rébute un peu sans trop savoir pourquoi je dois dire!

C'est rebutant parce que selon l'interface utilisée et le taux de complexité de ton appareil, cela peut être un travail d'amateur averti ou d'ingénieur logiciel confirmé.

Donc niveau pilote, je le lance comme un logiciel, ce sera OK s'il est adapté à l'OS mais après? Comment par exemple je peux aller voir dans le buffer de réception de données mettons? Où est-il accessible? Car je fais mon programme d'un côté, le driver tourne de l'autre mais j'ai du mal à voir où se fait le lien.

C'est bien ce que l'on dit : il faudra l'adapter à une interface existante.

Attention : si ton voltmètre fonctionne en USB, il y a deux possibilités : soit il utilise un protocole propriétaire, soit il utilise une des classes standard définies par la norme et, dans ce cas, ton système d'exploitation saura automatiquement le gérer sans avoir à écrire quoi que ce soit. Il y a de fortes chances pour que, par exemple, il se présente comme un port série. Dans ce cas, dès que tu le branches sur ton port USB, ton système déclarera disponible un nouveau port série et il te suffira de l'ouvrir depuis ton programme pour le lire.

Sous UNIX, ces ports prennent la forme de fichiers spéciaux (/dev/ttyS0, /dev/cua0 ou assimilés) et s'exploitent avec les primitives habituelles : open, read, close… Tu peux même les lire depuis le Shell.

Si je simplifie mon problème, j'ai un voltmètre qui lit des valeurs et les stocke par paquet de 16 par exemple puis je veux les lire avant que le buffer du dit voltmètre ne soit détruit et renouvelé, où va-t-on les chercher? Il faut bien une passerelle entre les deux non?

Même situation qu'au-dessus : soit ton appareil est déjà reconnu comme un « équipement terminal de transmission de données », comme on dit, et dans ce cas, il te suffira de faire une boucle avec un select() au milieu de ton programme pour tout lire (à condition que le flux de données ne soit pas trop important), soit il s'agit d'une périphérique plus « bas niveau » et là, il faudra écrire un pilote en mode noyau en gérant les interruptions et un buffer de la taille adéquate, ce qui est un gros boulot.

[Koko33]

Ok merci pour toutes vos réponses. Je connais bien les ports série en windows et en linux donc si ca passe par là il n'y aura pas de pb. Sinon je bucherai la doc pour titiller le driver et le code constructeur. Après dans le prot série je me dit qu'un appareil vendu ne doit pas forcément laisser ses données sans les encrypter ou bien les brouiller ain de pouvoir vendre ses logiciels qui font le boulot. Mais du coup je vais regarder en priorité cette histoire de port série car ca c'est mon élément. Merci, bonne soirée.