Programmation.c : Port série
Posté par lem__mel () le 26 juin 2006
0
Bonjour,un petit branchement me permet de recevoir signal sur une des broches d'un port série, et le but du jeu est de déterminer quand il y a changement d'état sur cette broche.
J'ai donc réalisé un petit programme qui lit l'état de cette broche (sur code est inspiré de celui de statserial), et tout fonctionne bien lorsque le signal est lent, mais pas lorsqu'il est rapide.
J'ai fait différents essais (code release, réglage du port sur 115000 bauds, nice) mais rien n'y fait je ne vois pas tous les signaux.
Quelqu'un a-t-il une idée ?
PS :
- je suis sûr des signaux car ceux-ci sont générés par un générateur de signal
- pour mes tests de lecture, cela échoue à la valeur de 1280 tests par seconde, alors que j'aurai besoin au final de plus de test !
> Lire le message (16 commentaires, moyenne: 1,6).
Vous avez demandé le commentaire #727320.
Run by 
Cette page a été générée par Templeet en 0.0671s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
mon humble avis
tu ne peut pas fonctionner comme ca.
Tu utilise un programme tournant dans le user-space, donc soumis a la volonté du kernel-scheduler pour avoir du temps machine, autrement dit ton programme est souvent interrompu et ne peut donc pas servir a scruter l'etat d'un port en continu.
La seule solution est de reprendre/modifier le driver de ton port serie et d'utiliser l'interruption qui est généré sur le changement d'état de CTS ou DSR soit pour faire ton traitement soit pour t'interfacer avec ton appli.
en général sur un pc c'est un uart compatible 16c550 qui est monté voici un lien vers le datasheet
http://focus.ti.com/docs/prod/folders/print/tl16c550c.html#t(...)
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[ Répondre ]
[^]Re: mon humble avis
je m'en doutais un peu ...
Mais j'ai pas très envie de travailler côté noyau si je n'y suis pas strictement obligé ...
Penses-tu que je pourrais faire quelque chose côté utilisateur avec un autre port (j'ai un électronicien sous la main :-)) ?
[ Répondre ]
[^]Re: mon humble avis
Sans électronique à coté ça me semble impossible de detecter autant de fronts .... déjà 1280hz ça parait énorme...
Une autre solution simple serait de lire un compteur par le port parallèle par exemple.
Mais ça dépend de ce que tu veux faire.
-Compter le nombre de front ?
-Réaliser une opération à chaque front ? (>1280Hz sans intérruption ça parait impossible)
[ Répondre ]
[^]Re: mon humble avis
j'ai besoin de savoir quand arrivent ces fronts (je log leur date d'occurence) et ensuite avec cette information, je peux "rejouer" en tenant compte des moments d'arrivé de ceux-ci.
De toute façon, cela vous semble trop rapide ... Donc même en jouant avec les paramètres de latence du noyau (et la préemptivité), rien n'y ferait.
Côté noyau, cela sera fiable et assez rapide ?
[ Répondre ]
[^]Re: mon humble avis
vous me direz qu'il y a pas d'autres choix ......
Merci pour les conseils :-)
[ Répondre ]
[^]Re: mon humble avis
Arg ! Surtout pas ! On ne passe pas en mode noyau simplement parce que le reste a échoué, on essaie plutôt de résoudre le problème en amont ...
Si tu fais une scrutation active (polling) dans un pilote du noyau, c'est le système entier qui va être bloqué le temps que ton pilote se lasse (cela arrive avec certains pilotes propriétaires), et sans possibilité d'interrompre celui-ci avec un Ctrl-C ou un Kill. Je ne parle pas non plus de ce qu'il risque de se passer si ton programme contient des bugs, segfaults, ou autre. je passe également sur le fait que ton pilote va entrer en conflit avec les vrais gestionnaires des ports série et parallèle, et que c'est également lui qui sera chargé de déclarer les ressources comme utilisées ou non auprès du reste du noyau. Enfin, à ce niveau, tu travailles en dessous de toutes les bibliothèques de fonctions. Même un bête printf() te sera interdit. Il te faudra utiliser les fonctions dédiés du noyau ...
On va commencer par le début : c'est quelle broche ?
Autrement, plutôt que de faire une scrutation des ports, il faut essayer d'attaquer une ligne suceptible de déclencher une interruption (IRQ), et la lire à ce moment.
D'autre part, je sais que l'interruption 14h du BIOS propose exactement ce genre de choses : les bits 3 à 0 sont nommés bits "delta" pour cela.
* bit 7 : liaison avec le modem récepteur établie
* bit 6 : le téléphone sonne
* bit 5 : modem activé
* bit 4 : modem prêt à émettre
* bit 3 : le bit 7 a changé
* bit 2 : le bit 6 a changé
* bit 1 : le bit 5 a changé
* bit 0 : le bit 4 a changé
Par contre, je ne me souviens plus si c'est l'interruption elle-même qui gère le delta ou bien si c'est le contrôleur série qui les maintient dans son propre registre. De toutes façons, à partir du moment où c'est l'électronique qui nous prévient lorsqu'il est temps de le faire, il est aisé de les remettre en oeuvre ...
[ Répondre ]
[^]Re: mon humble avis
Je suis d'accord avec toi sur l'utilisation d'une interruption, mais côté utilisateur peut-on être à l'écoute d'une interruption (je pensais que l'on ne pouvais pas sous linux :-P) ?
Côté cable je peux brancher sur la broche de mon choix.
[ Répondre ]
[^]Re: mon humble avis
pour la gestion proprement dite il te faut etre dans le noyeau.
il y as un exemple simple dans le rubiny qui peut te servir pour base de depart pour ta separation en deux partie de ton projet, il utilise le port paralelle et une pin en particulier qui est suceptible de genere une IT (pour info l'irq latency sur un kernel 2.6 est quand meme au alentour de quelque milli sur un linux quelque peut charger).
1) driver qui date les changements d'etat de la pin
2)prog en espace utilisateur fait la lecture des donnée
Il ne me semble pas possible sans faire de point de blocage dans le kernel de rejoué tes mesures. A quel frequence max espere tu foncionner ?
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[ Répondre ]
[^]Re: mon humble avis
Rubini, c'est l'auteur de Linux Device Driver ?
Que veux-tu dire avec "l'Irq latency [...]" ?
"rejouer les mesures"
en fait, j'ai besoin de savoir comment se succèdent les signaux, pour ensuite générer des évènements à l'occurence de certains d'entre eux (par exemple, je fais quelque chose dès que les 40 premiers sont passés). Mon idée était donc de loguer les temps des impulsions, et lorsqu'il faudra y aller "pour de vrai", je n'écouterai plus les impulsions, mais m'appuyerai sur les temps relevés.
Pour l'heure, je n'ai pas d'idée réelle des fréquences (je vais bientôt pouvoir aller avec un oscillo sur la bête pour voir les signaux qu'elle émet), mais les signaux devraient être émis dans les alentours de 1280 fois par seconde (là encore c'est des hypothèses).
[ Répondre ]
[^]Re: mon humble avis
Rubini, c'est l'auteur de Linux Device Driver ?
oui
Que veux-tu dire avec "l'Irq latency [...]" ?
c'est le temps entre la generation du signal irq sur la carte mere et le temps ou le systeme donne la main a ta routine d'interruption.
en fait, j'ai besoin de savoir comment se succèdent les signaux, pour ensuite générer des évènements à l'occurence de certains d'entre eux (par exemple, je fais quelque chose dès que les 40 premiers sont passés). Mon idée était donc de loguer les temps des impulsions, et lorsqu'il faudra y aller "pour de vrai", je n'écouterai plus les impulsions, mais m'appuyerai sur les temps relevés.
ou commence le comptage des 40 ? je ne comprend pas vraiment le truc a faire. Sinon un driver est tout a fait capable de signaler (par un signal) a une application user que quelque chose c'est passé (ca evite les methodes de pooling ou les i/o bloquante)
Pour l'heure, je n'ai pas d'idée réelle des fréquences (je vais bientôt pouvoir aller avec un oscillo sur la bête pour voir les signaux qu'elle émet), mais les signaux devraient être émis dans les alentours de 1280 fois par seconde (là encore c'est des hypothèses).
cela fais environ 1 kilo-hertz, c'est limite pour traiter ca en soft pur a mon avis...
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[ Répondre ]
[^]Re: mon humble avis
cela fais environ 1 kilo-hertz, c'est limite pour traiter ca en soft pur a mon avis...
C'est ce dont j'ai peur également.
Encore merci pour les conseils :-)
[ Répondre ]