Plop les pingouins.
Voilà, j'aimerai savoir si une ame charitable pourrait me donner le résultat de cette commande. Peut importe les valeurs, c'est simplement la syntaxe qui m'interesse :) (savoir si a sort un 25 fois 1 bit, ou 2 octet ... )
Éventuellement si vous pouvez me le faire avec une fois ACK=1 et ACK=0 (broche 10) et me montrer les fichiers correspondant, ca m'avancerai beaucoup.
Merci d'avance !
# Un peu plus d'explication
Posté par Calve . Évalué à 1.
En fait le script doit lancer un timer quand la bit ACK passe de 1 à 0, et l'arreter quand elle repasse de 1 à 0.
[^] # Re: Un peu plus d'explication
Posté par Christophe --- . Évalué à 2.
Je n'ai pas encore fait d'essais, mais il y a plusieurs point qui m'embêtent dans ta requete:
- historiquement, le port parralèle est en sortie seulement... donc pour ce qui est d'espérer y lire...
- le mode bidirectionnel dépend de comment il est configuré (EPP, ECP, ...), donc ce que tu vas lire vas dépendre de ce format...
- il n'y a aucune raison pour que ce que tu lises ne soit pas du binaire;
- si rien n'écrit sur ce port parralèle, le cat devrait bloquer;
- sauf autre configuration, le ACK signifie que le périphérique en face à bien reçu ce qui lui a envoyé, donc je doute que tu puisse lire ce status en shell (sous réserve du mode configuré)
[^] # Re: Un peu plus d'explication
Posté par Calve . Évalué à 1.
Il n'est en aucun cas question d'imprimante :D
- Il y a 5 entrées qui servent (-aient) à signaler une erreur, plus de papiers ...
- Aucune idée de la configuration du mode ... tout ce que je sais c'est que sous Windows ACK change d'etat suivant que le faisceau soit coupé ou non
- J'aurai donc une suite du style 10001 (5 bits car 5 broches d'entrées) ?
- Cat ne me donne pas l'etat des bits ? Si le cable est juste branché sans que rien ne se passe, il ne me sort pas une suite de 0 ?
- Ah ? Pas possible de lire l'etat de ACK ? Y'a-t-il un moyen simple en bash de le lire ?
Merci :)
[^] # Re: Un peu plus d'explication
Posté par Christophe --- . Évalué à 2.
Je te rassure, je me doutais bien qu'il s'agissait d'une bidouille :)
Comme je vais être ammené moi aussi à jouer avec le port parallèle, j'ai fait quelques recherches pour étudier la question...
- Ah ? Pas possible de lire l'etat de ACK ? Y'a-t-il un moyen simple en bash de le lire ?
En bash, ça va pas être possible comme cela. Je n'arrives pas à remettre le neurone sur le nom de l'utilitaire en ligne de commande qui permet de configurer le port parallèle, mais une fois configuré dans un des modes IEEE 1284 (nibble?) la valeur que tu peux lire avec le cat correspondra à ces bits... mais en plus je n'ai pas de quoi essayer sous la main :(
La méthode "traditionelle" en C est de faire un appel ioctl:
// on suppose que le device à été ouvert
unsigned char Status;
Error = ioctl(fd_device, PPRSTATUS, &Status);
if (Error == 0) {
Valeur = Status & PARPORT_STATUS_ACK;
}
[^] # Re: Un peu plus d'explication
Posté par Calve . Évalué à 1.
Pourtant on dit ici meme ( http://linuxfr.org/comments/724530.html#724530 ) que c'est possible en ligne de commande ... J'aurai accès a la machine une dernière fois demain matin avant mon oral, j'essaierai les deux méthodes.
[^] # Re: Un peu plus d'explication
Posté par Christophe --- . Évalué à 2.
En même temps, tu as dis plus haut que sous Windows tu arrivais à lire des choses, donc c'est pas exclu que cela passe tel-quel, même si j'en doute.
Je ne peux malheureusement faire plus que te souhaiter bon courage pour demain.
[^] # Re: Un peu plus d'explication
Posté par totof2000 . Évalué à 2.
http://linux.dd.com.au/quest/os-perl/parallelport/
Donc au pire si tu n'es pas un expert perl, tu dois pouvoir trouver un code d'exemple que tu pourras intégrer dans un script shell ( et si tu ne connais pas Perl, je te conseille fortement pour profiter de l'occasion pour apprendre un peu, ça ne peut pas te faire de tort).
[^] # Re: Un peu plus d'explication
Posté par Old Geek . Évalué à 1.
tentes plutot un "hexdump" un "od" etc ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.