Forum Programmation.c Contrôler le port parallèle

Posté par .
Tags : aucun
0
28
avr.
2005
Bonsoir à tous,

Je cherche à contrôler le port parallèle depuis un programme C, et notamment les lignes de contrôle (Strobe, Ack ...).

L'idée est de développer une interface de programmation pour programmateur PIC (des microcontrôleurs assez sympa) de type PROPIC2, qui change un peu de ça : http://www.propic2.com/ScreenShot.htm(...) et qui fonctionne sous Linux. Le programmateur lui-même se branche sur le port parallèle.

Le problème est que je souhaite produire quelque chose de relativement portable et que je n'ai que peu d'expérience en bas niveau sous Linux.

Il y a-t-il un moyen de contrôler ces lignes à l'aide de ioctl et assimilés, ou faut-il se résoudre à attaquer directement les ports I/O en assembleur, ce qui est très motivant en soi, mais pas pour un logiciel qui se veut portable, encore moins s'il s'agit de faire des opérations aussi « élémentaires » ?

Merci !

PS: Le dictionnaire ne connaît pas « microcontrôleurs ».
  • # Controller le port parallèle

    Posté par . Évalué à 3.

    Il existe des bibliothèques qui permettent d'attaquer les ports parallèles de manière assez simple. Si tu as peu d'expérience en programmation de bas niveau, c'est plutot par là que je commencerai à chercher. (rien ne sert de réinventer la roue - sauf si c'est pour apprendre).

    Si tu veux faire du portable, il existe une petite api, développée en C, disponible sous Linux et Windows et qui peut être attaqué en Java : http://www.geocities.com/Juanga69/parport/(...)
    Sur leur page d'accueil, tu trouveras pas mal d'infos intéressantes (particulièrement dans la section links).
    • [^] # Re: Controller le port parallèle

      Posté par . Évalué à 2.

      En fait, je suis au contraire assez axé sur le bas niveau : J'ai fait beaucoup d'assembleur sur toutes sortes de microprocesseurs et microcontrôleurs, j'ai tendance à réduire le nombre de couches et de bibliothèques utilisées par mes applications, je programme principalement en C et en C++, et je m'élève que rarement à des langages de plus haut niveau (sauf pour l'exercice). J'ai également quelques notions d'électronique même si je reste résolument un coder :-)

      Par contre, je ne suis descendu que rarement en dessous du userland sous Linux, d'où mon message. Je pense que je n'aurais pas trop de mal à piloter ces interfaces directement, mais la difficulté est justement d'utiliser ce qui existe déjà, et au bon niveau.

      Exemple : Il y a quelques temps, j'avais voulu écrire un pilote pour lire les disquettes de mon vieux TO8D de 1985. Celui-ci utilisait un lecteur qui était pratiquement celui du PC, mais avec un formattage un peu différent (640 Ko, 256 octets par secteur). Le lecteur en question proposait déjà les fonctions de base (polling) et celles dites « intelligentes » comme la recherche automatique de secteur, le tout au travers de 13 ports d'entrées/sorties hardware. Connaissant bien le pilote de mon TO8D pour l'avoir désassemblé et commenté, je me suis mis en tête d'en faire un sous Linux. J'ai très vite rencontré des difficultés, mais surtout je me suis aperçu que quelqu'un en avait déjà réalisé un, en utilisant exactement les mêmes ports, de la même façon, mais le tout en userland via ioctl. Cela m'a paru évident lorsque j'ai eu les sources sous les yeux, mais je n'y aurais jamais pensé seul.

      C'est pour cela que je me suis dit que, le format de port parallèle étant relativement constant d'une architecture à l'autre, dans le sens où il faut piloter les mêmes imprimantes, et le modèle restant simple (8 bits de données, une ligne de strobe, une ligne de ack), il devait exister quelque chose pour faire cela.
      • [^] # Re: Controller le port parallèle

        Posté par (page perso) . Évalué à 2.

        J'ai vu plusieurs propositions pour utiliser les ioperm et inb/outb directement. NON. Sous Linux il y a le module "ppdev" qui gere le "device" /dev/parport0 (pour LPT1), /dev/parport2, etc...

        Exemple de prog de test pour controler le registre de donnees :

        static int init_parport()
        {
        int fd_pp, i;

        fd_pp = open("/dev/parport0", O_WRONLY);
        if (fd_pp < 0)
        {
        perror("open lp");
        return 0;
        }

        ioctl(fd_pp, PPCLAIM);
        i = PARPORT_MODE_COMPAT;
        ioctl(fd_pp, PPSETMODE, & i);
        i = IEEE1284_MODE_COMPAT;
        ioctl(fd_pp, PPNEGOT, & i);

        return fd_pp;
        }


        void send_parport(int fd_pp, unsigned char data)
        {
        ioctl(fd_pp, PPWDATA, & data);
        }

        /* Et pour relacher le port :
        unsigned char data;

        data = 0;
        ioctl(parport_fd, PPWDATA, & data);
        ioctl(parport_fd, PPRELEASE);

        return close(parport_fd);
        */


        Evidemment, cet exemple est facilement adaptable pour controler les 2 autres registres (remplacer DATA par STATUS et CONTROL). Pour modifier ce source, voir l'API definie dans ppdev.h de include/linux/ . Dans le source, on utilise le mode de base du port // : tous les autres modes sont dispo (en particupier EPP).

        Sous windows, j'ai pas trouve mieux que d'utiliser inpout32.dll qui permet de se ramener au niveau inb/outb a la main. Peut-etre qu'une ecriture toute bete sur le "fichier" "LPT1" suffit.
  • # De mémoire

    Posté par (page perso) . Évalué à 3.

    il y a un périphérique /dev/parport possible (je me souviens rien d'autre mais je penes que ca doit être facil de retrouver)
    Sinon tu peux attaquer directement les IO sans assembleur (mais en root)
    (man ioperm/inb/outb)
  • # Manière simple

    Posté par . Évalué à 1.

    Attaqué le port (378) directement comme phh a dit est simple, par contre sous windows c pas la mm histoire pour discuter avec le port parallele (donc portabilité 0)

    http://mykey57.free.fr/?rub=documents&page=cours&mat=inform(...)
    ou en simplifié: http://mykey57.free.fr/rubriques/documents/cours/bts_iris/informati(...)

    Amuse toi bien ++

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.