Discussion :

[Bébar]

Bonjour,
Je m'intéresse depuis peu à l'écriture de driver sous linux, nottament grâce à "Linux Device Driver" (ver. 3) . Je n'ai donc que peu de connaissance à ce propos et il est possible que mes questions soient triviales...


Il y a un point qui me pose problème :
quand on fait plusieurs lecture/écriture sur un port parallele à l'aide de "void outb(unsigned char byte, unsigned port);" par exemple, l'auteur écrit dans sa méthode "write" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while (count--) {
    outb(*(ptr++), port);
    wmb( );
}

Or, je me dis que si on échange des données avec un mirco-controlleur par exemple, rien ne nous garantie que les deux échangent leur données à la même vitesse. L'auteur ne se préocuppe pas de ça parce qu'il branche un fil entre la sortie et l'entrée.

Mais 'en vrai', dans le cas où l'ordinateur est "plus rapide" que le materiel, j'imagine qu'on peut lire X fois le bit, ce qui peut créer quelques problèmes.
Donc vient ma question : comment synchroniser l'ordinateur avec le périphérique ?
Est-ce que l'utilisation d'une interruption est appropriée (autre méthode, comme un timer?) ?
Si on reçoit 1MB de données, n'est-ce pas un peu lourd de créer 1 interruption/bit ?

Merci d'avance de vos réponses.

[LittleWhite]

Bonjour,

Je vois le problème un peu différemment. En théorie, le matériel d'entrée sortie possède un tampon. Le programme envoie des données dans ce tampon et c'est le contrôleur de la sortie qui traitera le tampon. Le controlleur permettra d'envoyer une interruption ou une indication pour savoir si le tampon est vide ou pas et s'il doit être lu ou pas.
Il envoie une interruption dès la réception de données, mais il ne le fait qu'une fois. Tant que le tampon n'est pas lu, il n'enverra plus l'interruption.

Si le tampon se remplit, alors le code d'écriture que vous montrez se bloque (j'imagine), ou se synchronise à la vitesse à laquelle le tampon se vide (flux tendu, ralentissement de la machine la plus rapide du coup ...).

[Bébar]

Merci de la réponse, elle m'eclaire un peu plus.
Mais, quand tu dis, "En théorie, le matériel d'entrée sortie possède un tampon." il y a un truc que je ne vois pas : ce buffer, il "existe déjà (materiellement ?)" ou c'est à moi de la programmer ?

Parce que justement, l'auteur ecrit justement un buffer en écriture et un autre en lecture dans les méthodes "read" et "write" qui renvoient une erreur (return -EAGAIN) si :
-celui de lecture est vide
-celui d'écriture est plein

Mais dans ce cas le buffer, c'est le programmeur qui le créé (et d'ailleurs l'auteur ne fais pas mention d'une quelconque vitesse de lecture : il lit la mémoire RAM qu'il a alloué avec un kmalloc).

Si jamais il existe déjà, on peut le "configurer" ?

Pour mieux exposer mon probleme, je me mettais dans le cas où, à l'aide d'un µ-controlleur "tout bête", j'envoie sur des séquences de X bits sur un pin du port parrallele. Si jamais, pour une raison x ou y j'envoie la sequence "111000111000", comment l'ordinateur peut bien savoir que c'est "111000111000" et pas "1010".

Voilà j'espère avoir été assez clair.

Merci

[Bébar]

Bon bhé je m'auto-répond, au cas ou quelqu'un d'autre à le même problème.

J'ai trouvé une réponse qui me semble correcte avec les sources de "plip.c", un driver réseau qui utilise le port parrallèle (qui permet 8 bits en émission mais 5 en reception).
Du coup pour recevoir un octet il les recoit en 2 parties (4+4) et le 5ème port, sert à :
-recevoir une interruption pour alerter le processeur qu'il reçoit un paquet (première partie)
-de simple signal de synchronisation entre les deux machines : l'interruption est désactivé (disable_irq) pour la 2ème moitié, sinon "les performances seraient catastrophique" (dixit Linux Device Driver 3).

Donc j'imagine que dans le cas où on attend obligatoirement un flot de x octets successifs, on peut se limiter à une seule interruption au début (ce qui n'est pas très très flexible comme solution). C'est donc en effet bien ce que disait Little White (et que je n'avait pas tout à fait saisi), merci .

Pour ce qui est des mémoires tampon, visiblement c'est purement logiciel...

[_MicP_]

…(qui permet 8 bits en émission mais 5 en reception)…

En fait, on peut même faire beaucoup mieux ( entrées et sorties sur 8 bits, par exemple ) et même beaucoup plus rapide (si c'est le but recherché) en fonction du mode de configuration du port parallèle: SPP EPP ECP.

Voir :

IEEE1284
8255 datasheet
unixgarden : Programmation du port parallèle