Discussion :

[Ldoppea]

Bonjour,

Je profite de mes vacances pour me pencher sur l'électronique (tout en restant à un niveau assez basique), ainsi qu'à la création de périphériques.

Jusqu'à maintenant, les notions électronique s'acquiert plutôt facilement, que ce soit de la programmation micro-processeur, de l'utilisation de capteurs, où de l'envoi d'informations sur un port (COMM ou USB).

Par contre, quand on passe du côté ordinateur, çà se complique : je ne sais pas du tout comment récupérer ces informations. J'ai beau chercher sur google, le peu de connaissance des termes techniques du domaine ne me permet pas de trouver des résultats pertinents.

Donc je fait appel à votre aide

Le but est donc de communiquer entre le périphérique et l'ordinateur. Par un port COMM, ou de préférence par un port USB. Je pense commencer simple au début pour m'entrainer, genre communiquer avec un capteur de température (pour faire dans l'extraordinaire ). Si vous avez des informations ou de la doc, je suis preneur. Mes principales questions sont les suivantes :

1. Comment recevoir le signal envoyé sur un port COMM ou USB côté ordinateur (bah ouai c'est la question de base quoi )
2. Vaut-il mieux communiquer avec le périphérique directement avec l'application? Ou par le biais d'un driver (qui n'existe pas encore bien sûr)?
3. Y a t'il un différence au niveau communication pure (simplement pc/périphérique, sans parler de communication avec un logiciel)
4. J'ai un peu entendu parler des WDK et DDK, mais çà reste très flou. Sont-il obligatoires? Quel rôles ont-il dans la création de drivers?
5. Quel est le langage le plus adapté pour ce genre de tache?

Merci d'avance

[JegnuX]

erf, je viens de parler de ça sur le chat, et comme cela fut sans succès je me suis tourné vers le forum, et oh... je vois que tu l'as déjà fait donc c'est cool.

Sinon je pensais à un truc. Ya pas moyen de regarder dans le code source de certains drivers libres histoire de se faire un peu peur ?

[bacelar]

Moi, j'y connais rien en électronique, on va peut-être faire la paire.

Sous WindowsNT (y compris 2000, 2003 2008, XP Vista), les applicatifs n'ont pas directement accès à l'électronique de la machine. Cela permet de rendre le système d'exploitation plus stable et pour qu'il puisse mener à bien sa tâche de virtualisation de la plateforme hardware.

L'architecture est, en gros, composé de trois couches, du plus proche du matériel au plus éloigné.

Un environnement, dit Kernel, des drivers qui a accès au hardware et est aidé par des fonctions Kernel du système d'exploitation. C'est un environnement d'exécution assez complexe car il faut gérer beaucoup de chose comme le mapping mémoire, les interruptions, les piles de drivers etc... A moins d'être un professionnel ou un amateur très éclairé féru d'électronique, je ne vous conseil pas de vous lancer dans le développement d'un driver. Pour faire ce genre de développement, on utilise des outils spécifiques à ces tâches qui sont regroupés dans un Kit : le DDK (Driver Developement Kit).

Le système d'exploitation qui virtualise toute cette usine à gaz qu'est in PC.

Un environnement applicatif où la quasi totalité des développements sous Windows sont fait. Cet environnement est bien plus simple pour le développement d'application sous Windows. Les outils fournis par Microsoft pour le développement sur sa plateforme sont regroupez dans un Kit: Le SDK (Software Developement Kit)

Je crois me souvenir que le WDK est le regroupement des deux Kit (DDK et SDK) mais comme le SDK est bien plus utilisé que le le DDK, il y a de bonne chance que le WDK soit le nouveau nom du SDK.

Pour votre cas, je serais d'avis d'utiliser un "driver générique" des périphériques RS232 et USB. Ces "drivers" fournissent une API d'accès aux périphériques mais dans l'environnement applicatif via la primitive du système "DeviceIoControl" qui serviras de tunnel entre votre applicatif et le driver à travers le système d'exploitation.
Selon votre environnement de programmation, vous pouvez avoir accès à des outils (classes, librairie, composant graphiques etc ) qui serviront de surcouche à la primitive "DeviceIoControl".

[Ldoppea]

Pour ce qui est des drivers, bien qu'apparemment compliqués, si c'est la meilleur solution niveau efficacité, elle mérite d'être étudiée. De toutes façons, nous devrons y toucher tôt ou tard de par nos études.

En fait, il y'aurait 3 solutions. En partant du principe que les données nécessaire au programme ne sont pas directement issues du périphérique. Par exemple un capteur de température (sans parler des capteurs de pro qui font tous eux mêmes) va retourner une tension analogique, qui va être convertie en numérique (bien sûr effectué au niveau du périphérique), puis qui va être analysée pour être convertie en °C.

Cette dernière conversion peut se faire côté périphérique, par un driver, ou directement dans l'application. Le périphérique, de par son processeur plus lent qu'un processeur d'ordinateur pourrait ne pas pouvoir gérer des capteurs plus complexes et plus nombreux sans être ralenti (simple déduction, je fait peut être erreur). Le driver ferait tout de son côté comme un grand, aidé de la puissance du pc, mais la programmation est plus compliquée. L'application devrait s'occuper d'une tache pour laquelle elle n'est pas prévue à la base (au lieu de récupérer simplement la donnée à chaque interruption, elle dois effectuer tout un processus de conversion).

Bref je n'ai aucune idée de laquelle est la plus adaptée. Le mieux est donc de tester les 3

Je vais essayer de toucher au DDK, sa doc est assez réputée, mais est elle suffisante pour commencer sans connaissances en driver?

Peux tu donner plus de précision sur les drivers génériques? Je n'ai pas trop compris le principe (pourquoi le driver générique gererait il mieux des données pour lesquelles il n'est pas prévu qu'un OS?)

Les question du premier post tiennent toujours

[sloshy]

Bonjour,
Ce n'est pas le role du driver de faire une conversion.
de fait un driver a access a l integralite de la ram sans restriction, il est donc tres sensible et peut faire bugger non pas seulement l applicatino mais l ense;ble du systeme.

De fait il est plus simple d'utiliser un driver uniquement conne d'un pipe pour rediriger les informations du peripherique vers le ring3 ou une application userland (qui a beaucoup plus de difficulte de mettre en peril tout le systeme) ce gere du traitement de l'information recue.

[bacelar]

Pour éviter de noyer les nouveaux venus, il faut éviter les nouveaux termes, sloshy.
Les machines Intel disposent de 4 mode de fonctionnement, dit "ring".
Windows n'utilise que 2 mode de fonctionnement, le ring0 dit mode Kernel permettant un accès à toutes l'électronique du PC mais dans un environnement extrêmement hostile pour la conception de programme fiable; et le ring3 dit mode User ou userland offrant toute la convivialité la fiabilité et la productivité nécessaire à une plateforme moderne.
Windows est à cheval sur ces 2 rings et est le seul à pouvoir passer d'un mode de fonctionnement à l'autre par le concept d'appels systèmes chers aux Unixiens et DOSiens. Pour Unix et Linux, c'est la même tambouille.
Les drivers fonctionnent en mode Kernel avec donc un accès à toute l'électronique mais en n'ayant pas de pile d'appel, devant gérer la réentrance, le niveau d'interruption, devant se battre pour que ces variables soient attachées à des "objets" du Kernel Windows pour ne pas les voir disparaître sur disque (et sans mémoire virtuel c'est coton), sans console ni fenêtre, avec un accès au système de fichier extrêmement complexe, surtout en multi-core ou multi-cpu.
J'ai terminé mes études d'informatiques il y a plus de 10 ans sans jamais faire de programmation de driver et Vista introduit la programmation de driver en mode User. Donc l'utilité de programmer un driver en mode Kernel durant les études n'est "que" pédagogique.

Je voudrais combattre une idée reçu, programmer un driver permet de piloté de l'électronique mais pas de gagner de la performance. En Ring0 ou en Ring3, c'est toujours le ou les même CPU qui exécute un jeu d'instruction quasi-identique. Cette idée à pour origine le coup important en CPU du passage d'un mode de fonctionnement à un autre. Donc le fait de passer en mode User est coûte mais il est obligatoire pour que l'utilisateur puissent voir et utiliser les données.

Pour les 3 solutions :
- Dans le périphérique, c'est hors de mon périmètre de compétence
- Dans un driver, comme le résultat doit être afficher à l'utilisateur, à quoi bon ?
- En Ring3, et pas dans l'application qui est trop réducteur, c'est ma préconisation. On a le cout du passage en mode User mais ont peut afficher les données, brutes et raffinées.
- Dans un service Windows
- Dans une librairie réutilisable (~un toolkit d'utilisation du périphérique)
- Dans une librairie dynamique (~un "driver logiciel" du périphérique)
- Dans des classes ou structure de code réutilisable, (~un couche logiciel d'accès au périphérique)

Donc, pour moi, le Ring3 est la seule solution envisageable pour l'efficacité (brut et TimeToMarket).

Si tu t'obstines à vouloir faire un driver, tu n'as qu'une option viable, le DDK (le WDK semble être son "nouveau" nom) qui est un kit de développement C (pas C++). Tu pourras toujours récupérer du code source de driver Kernel (assez rare sur Internet) pour les port COM et USB mais tu sera arrivé au même point que l'utilisation de driver générique COM et USB.

Si tu vas dans le mode User, tu as tous les langages et environnement imaginables pour te simplifier le pilotage d'une interface COM. La majorité de ces interfaces font de ces port des fichiers presque comme les autres et utilisent en sous main l'une des quatre techniques de structurations en couches présentés ci-avant adossé à un driver générique.

Un driver générique est un driver qui fait le strict minimum; pour un port COM, c'est accédé au dernier caractère envoyé et envoyé un caractère sur le port etc...
Le contrôle de flux de parité etc... sera pris en charge par le driver et configurable par des appels à "DeviceIoControl".
Mais les interfaces devraient de simplifier/masquer toutes cette tuyauterie.

1. Comment recevoir le signal envoyé sur un port COMM ou USB côté ordinateur (bah ouai c'est la question de base quoi )
   -> Le driver générique devrait temporiser la récupération des données sur les ports
2. Vaut-il mieux communiquer avec le périphérique directement avec l'application? Ou par le biais d'un driver (qui n'existe pas encore bien sûr)?
   -> Soit Windows, on ne peut pas directement communiquer avec un périphérique, c'est à un driver de le faire.
3. Y a t'il un différence au niveau communication pure (simplement pc/périphérique, sans parler de communication avec un logiciel)
   -> pas compris la question
4. J'ai un peu entendu parler des WDK et DDK, mais çà reste très flou. Sont-il obligatoires? Quel rôles ont-il dans la création de drivers?
   -> C'est obligatoire pour le développement d'un driver, mais pas pour l'utilisation d'un driver générique. Il (DDK=WDK) fabriquent les drivers (compilateur, linker et bibliothèques C pour la génération des driver .sys)
5. Quel est le langage le plus adapté pour ce genre de tache?
   -> Si driver C rien d'autre, si User/Ring3 tous les langages possibles. e te conseillerais un langages .NET comme C# ou VB.NET pour des raison de la disponibilité d'interface d'accès au port COM par des classes intégré au Framework .NET depuis la version 2, le niveau d'activité support des ces langages.

[sloshy]

Beau poste, je n'ai malheureusement pas le temps d'en faire des aussi long et explicatif, cela dit je pense qu'une fois passé un certains niveau dans l'informatique la recherche est indispensable et donc donner les mots clefs d'une recherche a effectuer ou des notions que le posteur devra approffondir n'est pas une si mauvaise solution, je pense.

Ensuite, le ring0 et ring3 utilise presque les même instructoins certes, mais il peut, dans certainq cas, qu'utiliser directement l'API native de microsoft soit plus rentable.
C'est de la simple logique, si on utilise une fonction du SDK, au final c'est une fonction de l'API native qui sera utilisée, donc si on appel l'api native on gagne du temps, même si dans 99% des cas c'est négligable il peut arriver que la performence soit au rendez-vous. (nottement dans tout ce qui touche au processus ou le temps gagner s'estime en seconde, ce qui est enorme).

http://www.techniques-ingenieur.fr/d...ourceName=true est un vieux dossier qui pourrait être utile.

[Ldoppea]

Merci pour vos réponses .

En fait, cette notion de ring3 reste encore un peu flou. En fait çà se présente sous quelle forme? C'est du code à insérer dans le programme final? Un programme externe qui s'occupe de communiquer avec le périphérique et qui envoie les informations au process du programme final?

D'ailleurs si je code en C# pour cette tache, dois-je rester en C# pour le reste de mon programme?

Y a t'il un différence au niveau communication pure (simplement pc/périphérique, sans parler de communication avec un logiciel)
-> pas compris la question

En fait je parlait de la communication entre le pc et le périphérique. Le protocole de communication reste le même logiquement non?

[Médinoc]

En fait, il y a une différence majeure entre port COM et port USB:

• Windows considère les port COM comme des ports de communication, donc il y a déjà un driver tout prêt pour s'en servir: Tu peux utiliser un port COM dans un programme normal (appelle ça "user-mode" ou "ring3" si tu veux), simplement en l'ouvrant avec CreateFile().
• Les ports USB par contre, sont considérés comme des ports de périphérique, tu ne peux donc les utiliser sans développer un driver exprès pour ça, un driver qui connaîtra le protocole de communication avec le périphérique en question. Il en est de même pour les ports parallèles (LPT1 etc.)

[bacelar]

sloshy, c'est quoi pour toi "l'API native de Microsoft" ?
Pour moi, il y a Win32/POSIX( et OS/2), NTAPI pour le mode User ou encore la RTAPI ou la ZAPI en mode Kernel.
La différence de performance entre les API sous-système (Win32, POSIX ...) et la NTAPI sont minimes (comme les différences de programmation) car le cout de l'appel système est la par la plus importante du temps et le passage l'api sous-système à NTAPI n'est qu'une indirection, pas d'appel système. Le gain de performance, c'est peanuts de peanuts.
La différence entre RTAPI et ZAPI, c'est les contraintes d'utilisation et elles ne sont pas interchangeables.
Entre les API User et Kernel, oui, il y a une énorme différence de performance (et de facilité de développement) mais pour que l'utilisateur puissent voir les informations, il faut une application. Les applications n'ont pas accès aux APIs Kernel et ne peuvent utiliser que les API User. Donc le cout de l'appel système qui fait passer du mode User au mode Kernel et retour sera toujours payé.
Un calcul de conversion ne fait pas appel à des primitive du système mais aux unités arithmétique du CPU qui vont aussi vite ne mode User que Kernel. Donc faire la conversion en mode Kernel ne donnera aucun gain de performance.
Donc, à moins de disposé d'une électronique, ou une API Kernel dédié à cette tâche, mais là j'en doute fort, la conversion devrait être faite en mode User.


Ldoppea, j'espère que tu as une vue un peu plus claire du model statique d'un OS pour CPU multi-ring tel que les Intel. Pour l'aspect dynamique, on va essayer de te l'expliquer.
Au démarrage de l'électronique de la machine, le BIOS de la machine, qui est en ROM, va initialiser les composants, CPU compris, dans un mode de fonctionnement. Pour un Intel sur "PC", c'est un mode 16bits antédiluvien qui n'as même pas de notion de ring ou de mémoire virtuelle. A la fin de la procédure d'initialisation du BIOS, il charge le loader de l'OS. C'est un programme capable de tourner sans système d'exploitation et sur le CPU Intel en mode16bits. Il va configurer le CPU en mode 32bits et en Ring0 et charger et lancer la partie Kernel de l'OS.
Une fois que le Kernel (couche base de l'OS) s'est initialisé et a chargé les drivers pour piloter l'électronique, il charge la partie User de l'OS et fait passer le CPU en Ring3. La partie User de l'OS s'initialise et c'est partie jusqu'au prochain reboot.

Donc, quand tu lances, dans l'interface utilisateur ou dans une console, un programme, le CPU sera toujours en Ring3.
Si tu fais un driver, on ne te lance pas mais c'est le Kernel de l'OS qui le charge en fonction de l'électronique découvert sur les bus. Le chargement sera fait par la partie Kernel de l'OS, donc toujours en Ring0.

Le passage d'un mode de fonctionnement à un autre est fait lors des appels systèmes. Les appels systèmes ne sont pas les appels de fonctions à une API des dll du système (partie User de l'OS) mais le passage via interruption logiciel d'un mode de fonctionnement à un autre. Le terme appel système vient du fait qu'avant l'interruption logiciel, les dll du système chargent les registres avec des valeurs spécifiant une action à mener et avec les paramètres de cette action. L'interruption logiciel sera récupérée par un gestionnaire qui lira ces valeurs et prendra en charge l'exécution de la tâche avant de laisser le processus appelant reprendre son exécution. Ce mécanisme est donc accès proche sémantiquement d'un appel de fonction mais ne l'est pas dans sa mise en oeuvre. L'interruption logicielle fera passer le CPU du Ring3 des dl du système (partie User de l'OS) au Ring0 dans le gestionnaire d'interruption (il est dans la partie Kernel de l'OS). Quand l'action demandée est terminée, le gestionnaire utilise un opcode (instruction CPU) réservé au Ring0 pour faire repasser le CPU en Ring3. La partie User de l'OS (dans les dll systèmes) reprend la main au retour en Ring3 et retour le résultat au programme appelant.

L'interruption logicielle a été remplacée récemment dans les nouveaux OS pour les nouveaux CPU Intel par un opcode spécial mais le mode de fonctionnement reste le même.

Voilà pour la dynamique, j'espère ne pas t'avoir noyé sous les détailles.

Normalement, avec cet exposé tu devrais pouvoir répondre à ta première question.

"En fait çà se présente sous quelle forme? C'est du code à insérer dans le programme final? Un programme externe qui s'occupe de communiquer avec le périphérique et qui envoie les informations au process du programme final?"
Une application tourne toujours en Ring3, un driver toujours en Ring0. Tu n'utilise pas les mêmes outils pour créer un driver ou une application. Les uns sont chargés automatiquement par le Kernel, les autres lancés par les utilisateurs ou par des tâches systèmes, comme les services Windows, qui sont des applications (Ring3).

"D'ailleurs si je code en C# pour cette tache, dois-je rester en C# pour le reste de mon programme?"
Non, mais ton programme sera forcement une application, pas un driver. Pour les drivers, c'est de l'assembleur ou du C.
De plus, C# est un langage .NET. L'application sera en Ring3 mais utilisera aussi une surcouche aux API Win32 appelé Framework .NET. Cette surcouche facilite grandement de développement mais complique un peu, voir beaucoup, le dialogue avec des composants n'utilisant pas ce Framework (de plus en plus rare cependant).
Mais pour une utilisation de base du port COM, le Framework .NET est déjà suffisant et de nombreux composants sont fournis dans cet environnement d'exécution pour des utilisations plus pointues ou pour les ports USB.

"En fait je parlait de la communication entre le pc et le périphérique. Le protocole de communication reste le même logiquement non? "
RS232 (ou port série ou port COM) et USB sont des protocoles hardware que l'électronique du PC est chargé d'implémenté au mieux, via des UART pour RS232 par exemple. Ces composants électroniques présentent une interface que les drivers utilisent pour configurer l'électronique et envoyer/recevoir des données. Ces drivers présentent une interface au Kernel de l'OS pour qu'il puisse envoyer/recevoir des données sur l'électronique piloté par le driver. Ces interfaces, de composant électronique et du driver, ne sont pas identique car l'interface du driver tend à simplifier l'utilisation du composant périphérique. Les drivers génériques sont les drivers pilotant les composants, RS232 par exemple, et fournissant une interface très simple et minimaliste au Kernel de l'OS.
Quand vous accédez, dans votre application (Ring3), via "DeviceIoControl" au driver du périphérique, vous utilisé l'interface que le driver montre au Kernel de l'OS. "DeviceIoControl" est une fonction des dll systèmes qui utilise en interne un appel système, donc passage en Ring0, cet appel système (action du gestionnaire d'exception) transmet les paramètres fournis par l'appel de la fonction "DeviceIoControl" au driver qui les interprétera pour piloter l'électronique périphérique. Dans un environnement comme .NET (C#, VB.NET ...) des classes .NET sont fournis pour simplifier l'utilisation du port RS232 (de base) et USB (il faudra chercher sur Internet des composants fournissant ces classes) et qui encapsule les appels à la fonction "DeviceIoControl".
Donc, sur le fil, c'est bien le protocole hardware qui est utilisé mais les couches logicielles entre votre application et l'électronique utilisent une logique d'appel de fonction et de fonction de rappel (callback) qui est fonctions des couches utilisées.