Bonjour,
 
je suis électronicien et familier des langages C++, VB et Assembleur 8051
 
grâce au petit programme porttalk, j'ai conservé mes programmes d'accès aux ports de la machine et cela fonctionne très bien sous XP.
 
mes programment écrivent directement sur le port, en d'autre termes, c'est un seul programme qui fait du bas niveau jusqu'à l'interface utilisateur.
 
cela présente plusieurs inconvénients :
- lenteur du débit de données
- manque de précision dans le timing des impulsions électriques envoyées sur le port, risque de voir le programme ralentit par le PC ce qui aboutit à un dysfonctionnement du montage
- bas et haut niveau dans le même programme -> pbs de sécurité
- bas et haut niveau dans le même programme -> aucun langage n'est adapté pour faire cela
 
je souhaites donc aller plus loin et créer un "driver"; en fait mes applications seraient coupées en deux parties :
- un programme bas niveau (le driver) taillé sur mesure pour gérer le transfert de données entre le PC et le montage électronique
- un programme haut niveau : l'application utilisateur
 
Le programme haut niveau ne ferai que d'envoyer des consignes évoluées (par ex un bloc de xxx octets à graver dans une puce) au programme bas niveau qui lui générai scrupuleusement les trames à envoyer sur le port.
 
De petite taille et avec une priorité d'exécution élevée, le driver consommerai peu de ressources systèmes et ne serai pas perturbé par un ralentissement de windows. De plus le driver pourrai gérer des interruptions correspondant au montage piloté.
 
Dans un premier temps je compte mettre au point un driver "générique", que j'adapterai ensuite pour chaque montage, c'est à dire résoudre les pb suivants :
- écriture sur le port
- communication entre le driver et le programme haut niveau
- intégration du driver dans windows, obtenir les résultats escomptés en terme de rapidité, de précision et d'immunité au ralentissement
 
Je ne vous demande pas une solution clef en main (de toute façon trop facile et pas intéressant), mais quelques conseils pour "débroussailler" mon projet et partir dans la bonne direction :
- quel(s) langages choisir
- quel(s) implémentation choisir (dll/exécutable, mode de communication driver/app)
- quel(s) outils de développements préférer
- quel(s) docs ou exemples de codes sources consulter
 
Je souhaites privilégier une solution utilisant des logiciels libres (par ex. nasm) et gratuits (application utilisateur faite avec VB, VC++ express ou autre)
 
Merci

 
alors la rien n'est moins sur, je peux même dire que tu peux te brosser martine
 
si la question des timings est si importante, je te conseillerai de faire un montage électronique qui se chargera de faire ça avec un µC.
D'un côté tu le branche au pc, et tu lui envoie des ordres simples ("ecrit 1 octet", "passe telle broche à l'état X", ...) et de l'autre il se charge de les ressortir sur un port on va dire standard, similaire a celui ou ceux que tu voudrais utiliser directement (//, série, etc ...)
 
il te restera la partie driver bas niveau à faire, mais là tu n'auras plus à te préocuper des timings
sinon, pour des driver bas niveau pas très complexe sous win, C ou C++.
et pour relier ton driver à ton appli, bah, comme bcp de driver, en dll (ou en ocx si tu fais ton frontend en VB)

 
Salut,
 
Merci pour ta réponse, je vais d'ici là brosser mes cheveux longs    
 
Donc même en bas niveau, un PC serai donc incapable de générer des signaux numériques à fréquence élevée et une précision pas trop mauvaise ?
 
Prenons par exemple un scanner, à qui on demande de scanner une page A4 en résolution maxi (le bitmap fait environ 20Mo), et le transfert sur port // dure 1 minute (on considère que c'est le port qui ralentit la transmission de données); cela fait donc 333Ko de données utiles transférées; il faut tenir compte également du protocole utilisé (bits de synchro, d'horloge, accussé de réception, sommes de contrôles, ect); le port doit alors tourner à environ 400KHz.
 
De même pour tout ce qui est matériel, les débits sont aujourd'hui élevés, et le bon fonctionnement des périphériques impose le respect de fréquences et délais précis; les softs qui gérent tout cela doivent bien accomplir cette tâche.
 
Je me suis renseigné un peu partout, je viens de downloader le DDK et pas mal de docs sur developpez.com et win32assembly.online.fr
 
A+
 
EDIT : je pense avoir trouvé quelque chose de très interessant sur http://www.logix4u.net/inpout32.htm, je vais étudier les codes sources de sa DLL

 
Un pc en est capable, mais pas sous windows
Pour cela, il faut un OS temps réel (ex: QNX).

oui, voilà, il faut un os temps réel.
windows est passable en temps réel je crois, mais c'est la merde à installer  
 
ton port // peut pê aller à 400KHz, il n'en reste pas moins que rien ne soit assurer que ce soit bien périodique (et donc que ce ne soit pas des Hz  au passage )
 
pour les trucs genre ports usb, bah il se passe la même chose que ce que je t'ai expliqué. Y'a le controleur usb sur la carte mère, à qui on envoie des bouts de données, et la le contrôleur usb peut faire marcher le port usb bien comme il faut, sur toute la période ou les timings sont critiques.
 
C'est pareil dans l'autre sens. Pour recevoir correctement ce qui vient de ton clavier ou de ta souris ça passe par un contrôleur (maintenant dans le cipset) spécialisé qui décode et fournit des infos de manière moins dépendente d'une synchronisation quelconque au reste du pc.

 
salut !
 
le port // possède - il un contrôleur ? si oui la plupart des montages électroniques et leur soft associés doivent le contourner puisqu'ils écrivent directement octet par octet sur le port.
 
par ex. le port série lui possède un contrôleur, d'ailleurs des ocx ou des appli genre terminal permettent d'envoyer et recevoir des données via le port série en respectant un protocole précis
 
A+

bah oui mais le protocol il est pas regardant quand au timings, du moins tant que tu reste dans les bauds donnée, et si jamais tu en sort bah le protocole série possède 2 broches, rts et cts, qui permettent de justement contrôler le flux

et oui le port // a un contrôleur, puisque tu lui envoie l'octet de donnée, et le ou les 2 octets de control
mais le port // est encore moins regardant quand aux timings ! Vu que de toute façon il envoie l'octet d'un seul coup, les seuls timing que tu as sur le port // c'est entre 2 octets, et la c'est du ressort de l'application qui l'utilise