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.