GESTION DES PÉRIPHÉRIQUES

GESTION DES PÉRIPHÉRIQUES
INF-1019 Programmation en temps réel GESTION DES PÉRIPHÉRIQUES Sujets Gestion des périphériques Périphériques Techniques de lecture des données Acquisition des données Entrées/Sorties de périphériques Lectures: Approche du temps réel industriel, De Geeter Développer sous Win95 et Win NT, Richter

Gestion des périphériques
Pour accéder à un périphérique, il faut savoir : Comment utiliser ces registres de contrôle, de données et d’état. Ce qui cause la génération d’une interruption. Comment il transfère ses données. S’il utilise de la mémoire dédiée. S’il peut se configurer automatiquement. S’il peut et dans quelle condition il devient maître du BUS.

Schéma général d ’une interface de périphériques

Techniques de lecture de données (Modes de fonctionnement) Scrutation (polling) Pour l’envoi d’une donnée, le CPU vérifie dans le registre d’état si le périphérique est disponible. Si oui, il place la donnée dans le registre de transmission du périphérique. Sinon, il attend que le périphérique soit prêt. Pour la réception d’une donnée, le CPU interroge le registre d’état pour savoir s’il a une donnée disponible. Si oui, il la lit dans le registre de réception. Si non, il attend et interroge le registre d’état de nouveau un peu plus tard.

Techniques de lecture de données (Modes de fonctionnement) Scrutation (polling)

Techniques de lecture de données (Modes de fonctionnement) Interruption Lorsque le périphérique reçoit une donnée, il active IRQ pour avertir le CPU. Le CPU interroge alors le registre d’état du périphérique pour savoir si c’est lui qui l’a interrompu et s’il s’agit d’une interruption de réception ou de transmission. Réception: Avec une interruption de réception, le CPU lit la donnée dans le registre de réception du périphérique. Transmission: Avec une interruption de transmission, le CPU place une nouvelle donnée à transmettre dans le registre de transmission du périphérique. S’il n ’a plus de données à transmettre, il doit désactiver l’interruption en transmission, sinon il sera interrompu immédiatement par la même interruption.

Techniques de lecture de données (Modes de fonctionnement) Interruption Les interruptions matérielles (Les fameux IRQ utilisés par les périphériques de votre PC) et leur traitement sont une des principales caractéristiques des programmes temps réels (Geeter p53) car elles permettent d'interrompre le traitement en cours pour faire face à un événement extérieur qu'il peut être urgent de traiter en priorité. Le traitement d'une interruption matérielle est géré comme un appel implicite de procédure en utilisant une adresse stockée en mémoire dans la table des descripteurs des interruptions. Ces adresses sont les vecteurs d'interruptions. A partir de ce moment, le traitement est passer à une procédure appelée ISR (interrupt service routine). Si le traitement du ISR est court et ne nécessite pas d'appels système le ISR peut gérer seul l'interruption. Cependant, la plupart du temps, le ISR appellera une tâche d'interruption car pendant que le ISR s'exécute les autres interruptions sont masquées et ne peuvent être "vue" par le système.

Techniques de lecture de données (Modes de fonctionnement) Interruption Lorsque le traitement de l'interruption est terminé, le traitement interrompu reprend son exécution. Les interruptions logicielles ressemblent aux interruptions matérielles sauf qu'elles sont générées par le processeur. Les interruptions logicielles utilisent une table de vecteurs qui contient les adresses des routines correspondantes. Cette technique nous permet d'appeler des fonctions sans savoir ou elles sont localisées et facilite la compatibilité entre les différentes générations d'ordinateurs. Elles n'ont pas une importance capitale pour des programmes en temps réel mais sont souvent utilisées par les systèmes d'exploitation.

Techniques de lecture de données (Modes de fonctionnement) Interruption (fonctionnement)

Techniques de lecture de données (Modes de fonctionnement) Interruption (fonctionnement) Le processeur réagit aux interruptions et aux exceptions essentiellement de la même façon. Quand une interruption ou une exception est signalée, le processeur arrête l’exécution du programme ou de la tâche en cours d’exécution et passe à une procédure de traitement (ISR ou Interrupt Service Routine) spécifique pour l’interruption ou l’exception en cause. Le processeur accède à cette procédure de traitement via une entrée dans la table de descripteurs d’interruptions (IDT). Quand la procédure de traitement a terminé son travail, le processeur retourne à l’exécution du programme interrompu.

Techniques de lecture de données (Modes de fonctionnement) Interruption (fonctionnement: PIC)

Techniques de lecture de données (Modes de fonctionnement) Interruption (fonctionnement: PIC) Le 8259A peut accepter les interruptions de 8 sources externes, et on peut gérer jusqu’à 64 sources différentes en cascadant plusieurs 8259A. Il gère la priorité entre les interruptions simultanées, interrompt le processeur et lui passe un code pour identifier la source d’interruption. Une source d’interruption est connectée à chacune des 8 entrées IR0 à IR7. Selon sa priorité, et s’il n’y a pas d’autre interruption en cours, le PIC décide s’il peut transmettre l’interruption au CPU. Si oui, il achemine un signal sur la ligne INT, qui est connectée l’entrée INTR du CPU. Si le CPU est prêt à accepter l’interruption, il répond au PIC via la ligne INTA.

Techniques de lecture de données (Modes de fonctionnement) Interruption (fonctionnement: PIC) Le PIC répond à son tour en envoyant le numéro d’interruption sur les lignes D0 à D7. Ce numéro est un index dans la table des vecteurs d’interruptions (IDT). Le CPU est maintenant prêt à appeler le sous-programme de traitements d’interruptions (ISR) approprié. Quand le sous-programme de traitements d’interruptions (ISR) a terminé son exécution, il en avertit le PIC pour qu ’il puisse permettre à d’autres interruptions d ’atteindre le CPU.

Acquisition de données Afin de lire tous les signaux provenant des procédés ou de l’environnement extérieur, il nous faut bien sûre des cartes d'entrées/sortie spécialisées. Il existe plusieurs types de cartes et de moyens de communiquer les données. : On peut se procurer une multitude de configurations différentes. Cartes d'entrée, de sortie, entrée/sortie pour les signaux suivant: digitaux (120Vac, 24Vdc), analogique 4-20mA, analogique avec entrée pour sonde de température (pas besoin de transmetteur de température). Certaines cartes peuvent même avoir un "buffer" interne de 128Mo.

Acquisition de données Échantillonnage C’est l’opération qui permet de transformer un signal analogique en signal numérique. C’est l’acquisition des données en vue d’un traitement numérique. La fréquence d’échantillonnage doit être plus de deux fois plus grande que la fréquence la plus élevée retrouvée dans le signal analogique échantillonné.

Acquisition de données Cartes d’acquisition Plusieurs compagnies produisent maintenant des cartes d’acquisition de signal, s’installant dans un ordinateur personnel. Ces cartes comportent toutes un ou des ADC, de la mémoire, une logique de contrôle et une interface de communication.

Acquisition de données Cartes d’acquisition

Acquisition de données Cartes d’acquisition Caractéristiques Propriétés des ADC Grandeur et vitesse de la mémoire Fonctionnalités de l’électronique de contrôle Interface de communication Plug and Play Esclave ou maître Interruptions

Acquisition de données Cartes de génération Ces cartes comportent toutes un ou des DAC, de la mémoire, une logique de contrôle et une interface de communication.

Acquisition de données Cartes de génération

Acquisition de données Exemples de cartes Cartes sur bus ISA ou PCI. Ces cartes sont habituellement vendues avec un "driver" qui permet de lire facilement les entrées et de changer les valeurs en sortie. L'inconvénient majeur de ces cartes provient du nombre très limité de slot sur la carte mère du PC.

Acquisition de données Exemples de cartes Carte: PCI-MIO-16XE-50 Produite par National Instruments ( 16 entrées analogiques 2 sorties analogiques Logique de contrôle avancé Interface PCI (maître ou esclave, génère des interruptions) Caractéristiques des entrées – Plage des signaux : -10 V à +10 V – Type : référencée, non référencée ou différentielle – Convertisseur : 16 bits – Fréquence maximale d’échantillonnage : 20 KHz – Étage d’amplification ajustable (x1, x2, x10 ou x100)

Acquisition de données Exemples de cartes Carte: PCI-MIO-16XE-50 Caractéristiques des sorties – Plage des signaux : -10 V à +10 V – Convertisseur : 12 bits – Fréquence maximale : 20 KHz Logique de contrôle – Trigger analogique – Acquisition synchronisée sur une horloge externe – Génération synchronisée sur une horloge externe – 2 compteurs Mémoire – 2048 échantillons par entrées

Acquisition de données Exemples de cartes Carte avec communication sur port série Ces cartes communiquent avec l'ordinateur via le port série. Il est possible d'étendre la capacité de la carte (nombre d'entrée/sortie) en reliant des cartes d'expansion à la carte principale. Il existe aussi des instruments de mesures, comme les balances, qui peuvent communiquer leurs données directement à un ordinateur via un port série. L'inconvénient majeur de ces cartes est bien sûre la vitesse de transmission des données.

Acquisition de données Exemples de cartes Système de cartes avec châssis Toutes les cartes sont enfichées sur un châssis qui sert de bus de communication entre les cartes I/O et une carte de communication dédiée au châssis. Une autre carte de communication est enfichée dans l'ordinateur hôte afin de lui permettre de communiquer avec le châssis.

Entrées/Sorties de périphériques Win32 permet de faire des opérations d'entrée/sortie sur plusieurs types de périphériques. On peut citer entre autre les fichiers, port série, port parallèle, Mailslot, "named pipe", "socket", console (Richter p683). Win32 tente de masquer les différences entre ces périphériques en offrant la même fonction de lecture ou d'écriture pour tous ces périphériques. Cependant les fonctions utilisées pour ouvrir un handle sur périphérique et pour le configurer sont différentes afin de s'adapter aux spécificités de chacun (Richter p685 voir le tableau des différentes fonctions). La plupart des périphériques utilisent la fonction CreateFile() pour ouvrir un périphérique, même si ce nom peut sembler bizarre dans le cas d'un port série. Notez qu'il est possible de lire et d'écrire dans un fichier en utilisant deux méthodes. Premièrement, on peut utiliser ReadFile() et WriteFile(). Dans ce cas on utilise habituellement un bloc de mémoire tampon pour lire et écrire des blocs de données, ce qui est évidemment plus efficace.

Entrées/Sorties de périphériques Une autre méthode consiste à utiliser les fichiers mappés (Richter p229). Dans ce cas le système d'exploitation utilise son système de mémoire virtuelle pour mapper le ficher dans l'espace d'adressage virtuelle du processus. Ici on ne fait que lire et écrire en mémoire, et le système se charge de transcrire les données de la zone de mémoire vers le fichier. Il existe deux modes d'utilisation des entrées/sorties de périphériques, soit le mode synchrone et le mode asynchrone. En mode synchrone, si on fait un appel à la fonction de lecture ReadFile(), la fonction bloquera jusqu'à ce que la lecture soit terminée. Dans un programme multithread cela ne pose pas trop de problème à première vue car, pendant que le thread est bloqué, un autre thread peut continuer son travail. En mode asynchrone, la fonction d'entrée/sortie retourne immédiatement même si l'opération n'est pas terminée. Un événement est utilisé pour nous avertir lorsque l'opération d'entrée/sortie est terminée (Richter p701). Le programme Serial_IO fourni en exemple, utilise la fonction ReadFile() en mode asynchrone pour lire les données provenant du port série.

Entrées/Sorties de périphériques (Serial_IO)

Entrées/Sorties de périphériques (Communication série) Le programme Serial_IO montre comment utiliser le port série. Pour plus de détails voir l'article Serial Communication in Win32.

Entrées/Sorties de périphériques (Simulateur de la carte d’acquisition uMac) La carte d'acquisition de donnée uMac-4000 de la compagnie Analogue Device est une carte d'entrée/sortie analogique et digitale. Elle possède 12 entrées analogiques configurable (4-20mA, entrée pour thermocouples, millivoltages etc.), 8 entrées digitales et 8 sorties digitales. On peut y brancher jusqu'à 3 cartes d'expansions pour augmenter le nombre d'entrées/sorties. Le programme Serial_IO développé utilise le port série pour lire des données provenant de cette carte. Le programme uMac est un mini simulateur la carte uMac-4000. Ce simulateur utilise le même protocole de communication que la vrai carte. Le nombre de commandes disponibles est minimale et le simulateur n'a que 10 entrées analogiques. Deux configurations sont possibles pour faire de l'acquisition de données avec le simulateur. Premièrement, deux PC reliés avec un câble RS-232 NULL MODEM, et exécuter le simulateur sur une des machines et exécuter un programme d'acquisition de données (comme Serial_IO fourni en exemple) sur l'autre machine.

Entrées/Sorties de périphériques (Simulateur de la carte d’acquisition uMac) Si vous n'avez qu'une seule machine et deux ports série disponible (ce qui est souvent le cas avec une sourie PS-2), vous pouvez exécuter les deux programmes dans la même machine. N'oubliez surtout pas de relier les deux ports avec un câble série RS-232 NULL MODEM.

Entrées/Sorties de périphériques (Fonctionnement du simulateur) Exécuter le programme uMac.exe . Sélectionner le port désiré et la vitesse de transmission. Peser le bouton "départ communication". Le simulateur se met alors en attente de recevoir une commande sur le port série. La commande reçue lui indiquera combien de données il devra retourner. Notez que la carte uMac n'envoie qu'une série de lectures à la fois. Si vous voulez une autre série de lectures vous devrez lui envoyer une autre commande.

Entrées/Sorties de périphériques (Protocole de communication) La commande SCAN n, m demande à la carte de retournée les dernières valeurs lues des canaux n à m inclusivement. Notez qu'il y a dix canaux identifiés de 0 à 9. Ainsi, pour recevoir les valeurs des canaux 2 à 4 envoyez la commande *0:SCA/2/4:(cr) Notez que les commandes débutent toujours avec un astérisque * , suivi du numéro de cluster ici toujours 0 (zéro) car il n'y pas de cartes d'expansion. Vient ensuite un séparateur : et la commande sur trois caractères SCA pour "scan". Un autre séparateur / puis le premier canal (de 0 à 9), un autre séparateur / suivi du dernier canal (de 0 à 9) et d'un dernier séparateur : suivi d'un "carriage return". Le simulateur répondra à cette commande avec l'envoie d'une chaîne de caractères ayant le format suivant *00:(data)/(data)/(data):FF(cr)(lf) * est toujours le premier caractère, deux caractères pour le numéro de cluster, ici toujours 00. Un séparateur : précède les données. Chacun des blocs de données est séparé par un /

Entrées/Sorties de périphériques (Protocole de communication) Les blocs de données possèdent tous 7 caractères. Le séparateur de fin de données : est suivi d'un "checksum" qui aura toujours la valeur FF dans notre cas, suivi enfin par un "carriage return" et un "linefeed". Voici un exemple de chaîne de caractères retournée par le simulateur: *00:( )/( )/( ):FF(cr)(lf) Notez que l'utilisation des caractères (cr) et (lf) à la fin des messages permet de communiquer avec la carte (simulateur) à l'aide un terminal, ce qui est bien pratique pour vérifier le fonctionnement du système. L'autre commande acceptée est la commande HALT qui demande au simulateur d'arrêter de transmettre. *0:HAL/0/0:(cr) Si le simulateur reçoit une commande inconnue il répondra Commande Invalide.

Entrées/Sorties de périphériques (Protocole de communication) Le simulateur n'est pas une application multithread et n'utilise pas le mode asynchrone pour lire le port contrairement au programme d'acquisition Serial_IO. Ainsi, une fois le bouton départ communication enfoncé, il effectue une lecture sur le port en attente d'une commande. Puisque cette lecture est synchrone (bloquante) le programme ne réagit plus tant qu'une commande n'arrivera pas sur le port. Si aucune commande n'arrive, il ne sera pas possible d'arrêter le programme, sauf bien sûre en tuant la tâche. Vous devez donc envoyer la commande HALT pour qu'il débloque et stoppe la communication. Si votre programme d'acquisition de données fonctionne avec une boucle qui envoie sans cesse une commande SCAN il est possible d'arrêtez le simulateur avec le bouton Arrêt communication. En effet le programme fait un "PEEK MESSAGE" après la lecture du port et avant de retourner la réponse. Cette fonction permet de passer la main à la pompe à messages de Windows qui peut alors traiter la demande d'arrêt de communication. Le simulateur est donc un bel exemple des inconvénients des entrées synchrones dans un programme à un seul thread.

Entrées/Sorties de périphériques (Test de performance) Le programme Serial_IO permet l'acquisition de données provenant de la carte uMac-4000. Le programme fonctionne en utilisant quatre threads. Le thread principal s'occupe de l'interface graphique, le second thread sert à l'acquisition des données, le troisième a comme fonction d'afficher les données et enfin le dernier thread qui archive les données sur le disque dur. La boite de dialogue de l'application permet de sélectionner la priorité du processus et des threads. Si on sélectionne l'option synchroniser, l'accès aux variables globales est protégé. L'option Voir temps d'exécution autorise le thread d'acquisition de données à afficher à la fin de sa boucle le temps d'exécution de la dernière boucle. Le thread d'acquisition de données ouvre un port série en entre ensuite dans une boucle où il effectue sans cesse le cycle "Envoyer commande / lire résultats / lecture de l'heure / formatage du résultat / écriture du résultat dans buffer / affichage du temps d'exécution (si demandé) ".

Entrées/Sorties de périphériques (Test de performance) Notez que le thread rempli un buffer circulaire de 4Ko. Lorsque les deux premier kilo octets sont remplis il signal l'événement "bufferReady" qui réveille le thread d'écriture. Pendant ce temps le thread d'acquisition continu d'envoyer des données dans la deuxième partie du buffer. Lorsque cette deuxième partie est pleine il signale encore l'événement "bufferReady", et se positionne au début du buffer. Le thread d'affichage ne fait que lire une variable globale mise à jour par le thread d'acquisition et l'affiche dans la boîte de dialogue

Entrées/Sorties de périphériques (Résultats) La communication série s'effectue à 9600 Baud. Le fichier ouvert par le thread "archiveur de données" se nomme serial_io.txt et est écrasé lorsque le thread débute. Vous pouvez donc renommer chacun des fichiers avant d'effectuer le test suivant et ajouter au début des fichiers les conditions du test. Dans tous les cas, le système prend un certain temps à se stabiliser. En effet lorsque le programme est démarré, les temps d'acquisition ne sont pas stables et prennent plus de temps. Après quelques secondes le système prend sa vitesse de croisière. Voici la liste des tests effectués et le nom du fichier contenant les données. Veuillez noter que la priorité du thread principal est fixée à "time critical" dans le programme afin de s'assurer que le programme pourra toujours répondre aux commandes de l'utilisateur.

Entrées/Sorties de périphériques (Résultats) Liste des tests Test1.txt: Toutes les priorités à normale, aucune condition externe. Test2.txt: Toutes les priorités à normale, en bougeant constamment la souris. Test3.txt: Toutes les priorités à normale, recherche sur le "c:" les fichiers contenant un certain mot. Serial_io.exe en avant plan Test4.txt: Toutes les priorités à normale, recherche sur le "c:" les fichiers contenant un certain mot. Serial_io.exe en arrière plan Test5.txt: Processus = priorités normales, Affichage = priorité idle, Archivage = priorité normale, acquisition = priorité Temps critique, recherche sur le "c:" les fichiers contenant un certain mot. Serial_io.exe en avant plan Test6.txt: Processus = priorité temps réel, Affichage = priorité idle, Archivage = priorité normale, acquisition = priorité Temps critique, recherche sur le "c:" les fichiers contenant un certain mot. Serial_io.exe en avant plan Test7.txt: Processus = priorité temps réel, Affichage = priorité idle, Archivage = priorité normale, acquisition = priorité Temps critique. Aucun autre programme, bougé la souris pendant les trois dernières secondes

Entrées/Sorties de périphériques (Résultats) Liste des tests Voici maintenant les faits saillants de ces tests. Si le processus à une priorité normale, les temps d'acquisitions ne sont pas stables surtout si un autre programme qui utilise beaucoup de ressources travail en même temps. Les meilleurs temps d'acquisition ont été obtenus avec le thread d'affichage à basse priorité, ce qui fait du sens car l'utilisateur n'a pas le temps de tout voir. le thread d'archivage à moyenne priorité le thread d'acquisition à haute priorité,. Le fait de bouger la souris n'influence pas les temps d'acquisition. Lorsque le processus est en temps réel il n'est plus influencé par les autres programmes.

GESTION DES PÉRIPHÉRIQUES

Présentations similaires

Présentation au sujet: "GESTION DES PÉRIPHÉRIQUES"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

GESTION DES PÉRIPHÉRIQUES

Présentations similaires

Présentation au sujet: "GESTION DES PÉRIPHÉRIQUES"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back