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 ...
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.
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 ...
[^] # Re: mon humble avis
Posté par Obsidian . En réponse au message Port série. Évalué à 2.
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 ...