Salut!
J’ai besoin de pouvoir coder des informations sur le port parallèle du PC depuis un programme C.
J’ai entendu parler de fonctions pin et pout je crois, mais je n’en sais pas plus. QUelles fonctions et quelles librairies utiliser?
PS: je suis sous Linux, je n’ai donc pas besoin du driver de Windows XP à ajouter pour contrôller le port parallèle, directement accessible sous Linux.
Merci pour vos informations!
Oui, je pense que ça m’aidera beaucoup!
Merci 
Tu sais bluelambda, il n’est pas interdit que tu fasses des recherches personnelles avant de poster sur cafzone…
J’en ai fait.
J’ai même réuni de la doc à l’IUT de montages de protection pour réaliser une isolation galvanique, etc…
Mais ensuite je ne savais pas trop comment faire en C (je l’ai toujours fait en BASIC avant), et je n’avais rien trouvé d’intéressant sur Google.
Tu n’as qu’à penser que je ne sais pas chercher si tu veux. En tout cas le lien de TwinSidE m’a beaucoup aidé.
En passant, quelle est la meilleure méthode, avec la technique décrite sur le site donné ci-dessus, pour autoriser les utilisateurs normaux de Linux à exploiter via un programme C le port parallèle? Sans avoir à changer le suid de l’exécutable?
[quote name=‘bluelambda’ date=’ 5 Jun 2005, 02:06’]J’en ai fait.
[right][post=“365521”]<{POST_SNAPBACK}>[/post][/right][/quote]
Bon, unreal, t’es un peu injuste la, parce que si bluelambda connait pas bien le noyau linux, il aura du mal a comprendre que les reponses dans ton lien google parlent de parport, le driver bas niveau du port paralelle de linux, et que c’est ca qu’il faut utiliser.
Maintenant bluelambda, tu aurais du nous linker les resultats de tes recherches, pour qu’on t’explique pourquoi tu n’as pas trouve.
Et pas le truc crade du lien de twinside. C’est la maniere de faire quand t’es sous MSDOS ca, acces direct au materiel. Mais ca necessite le SUID root (encore heureux).
Et l’acces direct au matos sous linux, c’est MAL.
La bonne methode, bluelambda, c’est ca: parport
Et notamment User-level device drivers.
Alors attention, ca va etre plus complique au premier aborde que l’acces direct au materiel, mais c’est la BONNE maniere de faire, et ca te simplfiera la vie par la suite, je pense.
Pour info: premier lien, on garde l’adresse du developpeur de parport et on clique sur la doc. Easy.
LoneWolf
Tu vas bien t’amuser, bluelambda
Ah ben merci bien pour toutes ces infos LoneWolf
Une question tout de même: pourquoi l’accès direct au matériel c’est mal?
L’ordinateur sur lequel tournera ce programme aura pour seule fonction de commander les moteurs pas à pas d’un robot, pour information. Il aura Linux installé, mais sans rien d’autre quasiment.
Je vais regarder de près les documentations de parport.
Un autre problème est que j’ai besoin de réaliser une temporisation ultra précise.
Sur un lien du site donné par TwinSidE, j’ai lu que pour faire des temporisations précises on peut se connecter directement au port 0x80 et envoyer n’importe quel octect sur ce dernier, ce qui serait d’après l’auteur de l’article sans conséquences.
Voici l’article: http://www.freenix.org/unix/linux/HOWTO/mi…rt-2.html#ss2.1
J’entends par temporisations précises des temporisations extrêmement courtes (de l’ordre de la microseconde) et extrêmement régulières.
Je m’étais renseigné il y a quelques temps pour savoir si il y avait des solutions pour réaliser des temporisations ultraprécises. J’avais notamment testé certaines sources C de cppfrance.com, et j’avais aussi posté une demande d’aide sur leur forum, j’avais un peu cherché sur Google, mais sans rien trouver de convaincant, la plupart du temps on me disait que c’était impossible sur un OS multitaches. Et toutes les sources, même en assembleur parfois, ne donnaient rien d’intéressant sous un OS multitaches.
Le problème avec un OS multitaches c’est que l’ordonanceur du système nous empèche de créer des temporisations précises, selon la charge de calculs du processeur. C’est d’ailleurs expliqué sur le site où il y a la méthode du port 0x80.
J’ai expérimenté la méthode du port 0x80, voir ce que ça donnait. C’est de toutes les méthodes que j’ai testées, de loin, la plus convaincante
Pour celà, j’ai réalisé une temporisation avec une boucle infinie dans mon programme C. A chaque boucle, il envoie un seul bit (0x00) sur le port 0x80, et change l’état d’un bit sur le port parallèle.
A l’aide d’un oscilloscope j’ai visualisé le signal de sortie sur la broche du port parallèle où je fais varier le bit.
J’obtiens un signal carré quasi parfait, et quasi régulier, de demi-periode égale à 3.5 microsecondes! Sous un OS multitaches avec KDE et tout lancé, plus des programmes qui travaillent en fond! Bref, exactement ce que je cherchais!
Mais une question: cette méthode est-elle propre? Qu’en pensez-vous? Il n’existe donc rien de mieux pour obtenir des temporisations précises? Ca fait un peu brouillon comme méthode je trouve…
[quote name=‹ bluelambda › date=’ 5 Jun 2005, 19:05’]Ah ben merci bien pour toutes ces infos LoneWolf 
Une question tout de même: pourquoi l’accès direct au matériel c’est mal?
L’ordinateur sur lequel tournera ce programme aura pour seule fonction de commander les moteurs pas à pas d’un robot, pour information. Il aura Linux installé, mais sans rien d’autre quasiment.[/quote]
C’est mal parce que tu casse la regle qui regie un BON systeme d’exploitation: Faire une couche d’abstraction totale entre le materiel et le logiciel. En faisant ca, tu courcicuite tout.
[quote name=‹ bluelambda › date=’ 5 Jun 2005, 19:05’]Un autre problème est que j’ai besoin de réaliser une temporisation ultra précise.
Sur un lien du site donné par TwinSidE, j’ai lu que pour faire des temporisations précises on peut se connecter directement au port 0x80 et envoyer n’importe quel octect sur ce dernier, ce qui serait d’après l’auteur de l’article sans conséquences.[/quote]
C’est mal aussi.
En meme temps, c’est un peu logique. Essaye avec QNX
[quote name=‹ bluelambda › date=’ 5 Jun 2005, 19:05’]J’ai expérimenté la méthode du port 0x80, voir ce que ça donnait. C’est de toutes les méthodes que j’ai testées, de loin, la plus convaincante B)
Pour celà, j’ai réalisé une temporisation avec une boucle infinie dans mon programme C. A chaque boucle, il envoie un seul bit (0x00) sur le port 0x80, et change l’état d’un bit sur le port parallèle.
A l’aide d’un oscilloscope j’ai visualisé le signal de sortie sur la broche du port parallèle où je fais varier le bit.
J’obtiens un signal carré quasi parfait, et quasi régulier, de demi-periode égale à 3.5 microsecondes! Sous un OS multitaches avec KDE et tout lancé, plus des programmes qui travaillent en fond! Bref, exactement ce que je cherchais![/quote]
Sigh. La, tu me decois, franchement. Tu sais comment ca marche, un oscillo?
Il fait une moyenne du signal, et l’affiche a l’ecran, c’est IMPOSSIBLE de voir s’il y a des defauts dans le signaux, et de connaitre leur frequence (la frequence des erreurs). Reflechis un peu, putain!
Pour bien comprendre, tu fais un programme qui stocke, dans une grande chaine, « 1\n » pendant 2 secondes, a la frequence de 10 microsecondes (prevois la taille de la chaine AVANT, la reallocation faussera tes resultats) puis sauvegarde le fichier, et compte le nombre de lignes.
Pense a synchroniser l’horloge en faisant :
temptime=time();
while(temptime==time());
/*start your test here*/
Fait aussi le code sans le wait, pour voir. Si t’as presque autant de ligne, no way.
[quote name=‹ bluelambda › date=’ 5 Jun 2005, 19:05’]Mais une question: cette méthode est-elle propre? Qu’en pensez-vous? Il n’existe donc rien de mieux pour obtenir des temporisations précises? Ca fait un peu brouillon comme méthode je trouve…
[right][post=« 365638 »]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est pas la bonne methode d’utiliser une temporisation pour faire une horloge. The Worst one, en fait, mais malheureusement, je ne sais pas comment faire sous linux pour utiliser la vrai methode.
La vrai methode, je la connais de MSDOS et du BIOS PC: Sur PC, tu as une interruption logiciel qui se declenche toutes les 18.2 secondes par defaut, et cette frequence est reglable (je sais pas si ca va a la micro seconde, ceci dit). Il suffit de remplacer le code de l’interuption par son propre code, et ca roule (il faut conserver le code d’origine aussi, c’est lui qui gere l’horloge de la machine).
Bref, ca va pas etre simple. Je sais pas ce que tu dois faire avec ce truc, mais une vieille becane avec MSDOS serait plus facile a utiliser pour faire ce genre de truc, mais je sais pas ce que tu veux faire avec ton machin.
LoneWolf
Ralala, ces jeunes, faut tout leur dire
[quote]Sigh. La, tu me decois, franchement. Tu sais comment ca marche, un oscillo?
Il fait une moyenne du signal, et l’affiche a l’ecran, c’est IMPOSSIBLE de voir s’il y a des defauts dans le signaux, et de connaitre leur frequence (la frequence des erreurs). Reflechis un peu, putain! [/quote]Non désolé, c’est toi qui ne sais pas utiliser un oscillo B)
Je sais reconnaitre un signal régulier et un singal non-régulier à l’oscillo, un oscillo ne fait en [B]AUCUN CAS[B] une moyenne, c’est faux, et j’insiste, je ne sais pas où c’est que tu as vu ça!
Peut être que tu parle de certaines fonctions d’oscillos numériques qui font une moyenne en vue d’obtenir des signaux plus propres à l’écran? Un oscilloscope normal (ou en mode normal) ne fait pas celà.
Si tu as un signal qui n’est pas parfait, c’est à dire qui n’est pas [B]strictement identique[B] à lui même à chaque periode, la visualisation sera floue, ou alors il y aura plusieurs traits sur ton écran, étant donné qu’il s’agit d’un point qui balaye très vite l’écran, et retrace en temps réel la forme du signal d’entrée.
Le signal que nous observons en utilisant la temporisation basée sur le port 0x80 n’est d’ailleurs pas parfait dans ce cas.
Il est parfait pour ce que je veux faire B)
Premièrement un signal carré n’existe pas, c’est irréalisable, ça n’existe qu’en théorie. On peut tendre vers un signal carré, mais on ne l’atteint jamais.
Dans notre cas, nous sommes en présence un signal de forme carrée (psedo carrée), les fronts montants du signal carré que nous obtenons sont « légèrement courbés », et représentées par plusieurs traits à l’écran.
On voit nettement sur l’écran que le signal n’est pas strictement identique à lui même à chaque periode, mais la marge d’erreur est tout à fait négligeable pour ce que je souhaite faire.
La periode du signal n’est pas précise, et on voit nettement à l’écran que le signal oscille autour de cette periode.
Je te fais un petit exemple rapide de ce que j’observe sur l’écran pour t’expliquer mieux:
Cette image représente une periode du signal, visualisée à l’écran. Bon je sais, c’est mal fait
On voit que le signal n’a pas une periode très précise. Mais on est quand même en présence d’une temporisation précise, sachant que la periode couvre 7 microsecondes en gros, si je me souviens bien. Ce signal que j’ai dessiné n’est évidement pas à l’échelle, c’est juste une schématisation.
Donc, ce signal permet de commander des moteurs pas à pas qui tournent extrèmement vite. Ces moteurs subissent une accélération exponentielle qui leur permet d’atteindre leur vitesse maxi sans perte de pas. Si pendant qu’un moteur tourne il perd un seul pas, dû à une erreur de la temporisation qui a émis un signal une milliseconde trop tard parce que l’OS multitache l’a empéché, alors le moteur va s’arrêter de tourner trop longtemps, et rester bloqué sur place, ne pouvant répondre au régime de rotation extrème que l’on lui demande. D’où la phase d’accélération (cette phase d’accélération est d’ailleurs invisible, quasi instantanée).
Alors effectivement, j’avais développé avec un pote un petit programme DOS en BASIC qui tournait sur un PC exclusivement sous DOS. La temporisation était faite grâce à une boucle for, et c’était très précis.
Je souhaitais juste pouvoir faire une version du logiciel sous un OS multitache
De plus cette méthode est temporaire, plus tard on aura juste à envoyer une commande sur port parallème pour définir la vitesse du moteur, et un circuit électronique avec une horloge bien précise s’occupera des signaux de commandes, comme ça plus de problèmes.
Mais bon, ça me permet d’apprendre quelques trucs intéressants de me casser la tête avec ces problèmes « àlacon »
[quote]Je sais pas ce que tu dois faire avec ce truc, mais une vieille becane avec MSDOS serait plus facile a utiliser pour faire ce genre de truc, mais je sais pas ce que tu veux faire avec ton machin.[/quote]Il s’agit en réalité simplement d’un projet de robot de bras articulé qui occupe nos vacances à un ami et moi
Actionné par 6 moteurs pas à pas.
D’ailleurs le principal objectif actuel est de réaliser une alimentation via un circuit composé entre autres de hacheurs pour commander chaque moteur, ce qui nous permettra d’établir le courrant plus rapidement dans les bobines, et donc de fournir le couple qui va avec la vitesse.
Actuellement à grande vitesse, si le bras articulé transporte une charge, il peut perdre des pas, car les bobines des moteurs sont alimentées pendant trop peu de temps et le courant a à peine le temps de s’atablir, sans atteindre sa valeur maximale. Donc faible couple.
Bon voilà !
Sur ce, bonne nuit à tous!!
Hum ok ok, au temps pour moi, mais sur les oscillo que j’ai utilise, ca marchait pas comme ca. J’ai appris a les utiliser il y a plus de 10 ans, et a l’epoque, le prof nous parlait d’oscillo electronique qui etait super plus mieux.
Une fonction des oscillo electroniques? Je suis quasi sur que, sur les oscillo qu’on avait, voir ce genre d’erreur etait impossible a voir, sauf si elle etait tres frequente.
LoneWolf
Pfff je suis plus a la page en electronique
Pour autant que je me rappelles ce truc la marche sur tout les oscillos: suffit d’augmenter la fréquence de rafraichissement et de ne prendre qu’une petite partie de la courbe…
En général pour activer une boucle ultra précise, le mieux est de faire une attente active dans une boucle et on récupère le timer hardware (doit y avoir un équivalent sous Unix). Et pour éviter d’être préhempté, on augmente la priorité de la tâche. Et là on obtient de forts bons résultats…
Pour Lonewolf, on est malheureusement dans un cas d’utilisation qui impose peut être le dialogue direct avec le hardware pour atteindre le niveau de perf.De toute façon faire des entrées sorties sur du temps réel dur, impose généralement une solution très proche du hardware (soit par driver spécifique, soit par extension matérielle).
Ceci étant il existe des solutions à base de Matlab/Simulink + carte hardware qui donneront d’excellent résultats tout en restant réaliste d’un point de vue industrielle. Pour un projet de robotique, cela aurait complétement un sens.
[quote]Une fonction des oscillo electroniques? Je suis quasi sur que, sur les oscillo qu’on avait, voir ce genre d’erreur etait impossible a voir, sauf si elle etait tres frequente.[/quote]Là tu as raison. Si le signal a une très haute fréquence et qu’une fois comme ça par hazard sa periode change, même nettement, puis revient juste après à sa valueur normale, même si le point dessine sur l’écran ce déplacement, tu ne le verras pas, c’est trop rapide.
Mais quand quelque chose se répète, ce qui est le cas ici, et où l’imperfection est régulière, on le voit assez facilement.
Ici la periode n’est pas très précise et elle oscille autour d’une valeur à chaque fois, ce qui explique que les traits soient un peu dédoublés. Je n’ai pas encore testé sur les moteurs, mais je pense que ce doit être bon.
[quote]on augmente la priorité de la tâche[/quote]Oui, c’est une autre possibilité que je n’ai pas encore testée, elle est expliqué sur le même lien je crois.
[quote]Ceci étant il existe des solutions à base de Matlab/Simulink + carte hardware qui donneront d’excellent résultats tout en restant réaliste d’un point de vue industrielle. Pour un projet de robotique, cela aurait complétement un sens.[/quote]Effectivement on pense réaliser un circuit qui va lui même générer un signal d’horloge très précis, ce signal sera juste calibré par le PC qui codera la valeur de sa periode via une information sur port parallèle transmise au circuit. Ce sera nettement plus propre comme méthode
Bon ben merci pour votre aide à tous
Pour avoir des temps d’executions garantis, vaudrait peut-etre mieux te tourner vers un OS en temps-reel, genre RTLinux ou autres (va falloir chercher, je me souviens plus des noms…)
Ca fonctionne comme un Linux, mais l’ordonnanceur te garantit des delais d’execution sur certaines taches…
[quote name=‘unreal’ date=’ 4 Jun 2005, 22:20’]Tu sais bluelambda, il n’est pas interdit que tu fasses des recherches personnelles avant de poster sur cafzone…
[right][post=“365496”]<{POST_SNAPBACK}>[/post][/right][/quote]
Et s’il l’avait fait, ce thread ne serait pas allé plus loin que là, et la discussion qui s’ensuit, truffée d’infos diverses et variées n’aurait jamais eu lieu.
A la limite, toute personne qui pose une question sur n’importe quel forum est en tort d’après toi ? C’est vrai, on trouve tout sur le net en se donnant un peu de mal. Et même en dehors du net, d’ailleurs.
Le plus ou moins newbie dans un domaine est donc condamné à souffrir parce que les “éveillés” restent entre eux à discuter de sujets hautements plus élevés ?
A priori, je dirais que ça n’est pas la philosophie de la Zone. Sinon Titan et d’autres ne m’auraient pas donnés des astuces pour faire une bête planche contact sous ToShop.
Oui, il y a des questions un peu con-con. Et ça ne prend que 20 secondes pour balancer un lien ou une info. Et c’est autrement plus constructif que “vas faire des recherches personnelles”.
Antoine
Amen To That.
Et pis vas falloir vous detendre un peu les enfants, parce qu’en ce moment, je suis enerve, et quand je suis enerve, c’est mauvais pour mon coeur… et vous voudriez pas que sur ma tombe il y est ecrit "
“c0unt0, mort avec ses bottes, car LoneWolf a encore flamme un newb”.
Si ?
Donc on se detends, on est gentil, on aide les gens, et on ne cite pas GNU pour justifier son flame.
[quote name=‘AntoineViau’ date=’ 16 Jun 2005, 14:27’]A la limite, toute personne qui pose une question sur n’importe quel forum est en tort d’après toi ?
[right][post=“368924”]<{POST_SNAPBACK}>[/post][/right][/quote]
Je pense que tu devrais regarder un peu les participations passees de notre ami bluelambda pour comprendre pourquoi j’ai dit ca…