FR2684465A1 - Carte a microprocesseur avec debogueur deporte. - Google Patents

Abstract

L'invention concerne un dispositif de débogage en temps réel d'applications à microprocesseur conçu sur une nouvelle architecture. Le dispositif est une extension de l'invention No. 90 00200. Il comprend un éditeur multi-fichiers qui dispose d'une mémoire principale servant à éditer des fichiers non exclusivement "texte", un assembleur à listing différé à formattage dynamique, un éditeur à vérificateur de syntaxe, un débogueur avec des procédures de dialogue optimisées, des fonctions de lecture-écriture mémoires en plusieurs formats différents ainsi que diverses autres fonctions secondaires.

Description

Dans la technique actuelle, on appelle "kit" une carte à microprocesseur destinée essentiellement à l'enseignement du logiciel et du matériel. La présente invention concerne des améliorations que l'on peut apporter à un tel kit microprocesseur en vue d'une plus grande maniabiIité.

Dans l'état de la technique, les kits sont autonomes ou bien dialoguent avec des terminaux. Le brevet d'invention 90 00200 concerne un kit microprocesseur connecté à un ordinateur du type PC/AT. Les innovations décrites dans le présent brevet d'invention sont en quelque sorte des additions au brevet qui vient d'être cité.

Dans la précédente invention, il existait un problème: le temps de transfert entre le kit et le PC/AT. La méthode envisagée ici est la suivante. Lors de la mise en route de la carte, le contexte du microprocesseur (registre, état de certaines zones mémoire, état de la pile, etc.) est mémorisé dans la mémoire de la carte elle-même. Lorsque le
PC/AT effectue la première opération, le kit lui renvoie le contexte intégral en vue de son affichage sur l'écran. Par la suite, à chaque nouvelle opération, le kit compare le nouveau contexte avec l'ancien et ne renvoie au PC/AT que les registres ou les éléments qui ont été modifiés. Par exemple, à la mise sous tension, les registres peuvent avoir une valeur prédéterminée. Si le PC/AT demande par exemple l'exécution d'une instruction du type MOVEQ (cas du 68000 pris comme exemple) d'une valeur en adressage immédiat dans le registre D4, il est évident que les autres registres n'auront pas été modifiés. Dans ce cas, le kit ne renvoie au PC/AT que le registre D4. Le fait de ne renvoyer que les registres modifiés réduit considérablement les temps de transfert.

En ce qui concerne la mise en pratique, il y a deux solutions. La première consiste à doter chaque registre ou chaque élément du contexte d'un code (caractère ASCII par exemple). Lorsque le kit envoie ce code au PC/AT, ce dernier sait de quel registre il s'agit. La valeur hexadécimale du registre suit le code et est exprimée soit en 32 bits, soit en 16 bits. Les transmissions d'un registre quelconque en 16 bits auront un code différent des transmissions en 32 bits. Par exemple, la lettre R voudra dire le registre
DO en 32 bits, tandis que la lettre r voudra dire le même registre mais en 16 bits. Dans le cas d'une transmission en 16 bits, les 16 bits de poids fort seront supposés être inchangés par rapport à la transmission précédente. Lors de la mise sous tension, on supposera que ces 16 bits de poids forts sont à 0.

A chaque fois qu'un message est ainsi transmis du kit vers le PC/AT, il y a en fin de message une vérification par somme (appelé plus couramment "checksum"). Le type de message qui vient d'être décrit est supposé être en ASCII. Toutefois, pour des raisons d'efficacité (toujours dans le but de réduire le nombre d'octets transmis), il est souhaitable que le message soit transmis en binaire et non en ASCII. Le principe est le même, chaque message comprendra un ou plusieurs ensembles constitués d'un code et de la valeur du registre. De même, à chaque fin de message se trouve une vérification (somme de vérification, CRC16...) qui valide ainsi la transmission.

Lorsque le PC/AT reçoit le contexte ainsi modifié, il l'affiche sur l'écran. L'une des innovations très intéressantes consiste à modifier la couleur des registres ou des éléments ainsi modifiés. Par exemple l'ensemble des registres 68000 pourra être affiché en jaune à l'exception du ou des registres modifiés, qui seront affichés en blanc.

L'utilisateur peut ainsi beaucoup mieux suivre l'évolution des registres et, par voie de conséquence, son programme.

Toujours dans le domaine du débogage, une innovation intéressante consiste à modifier en temps réel le format de la visualisation. A l'aide d'une touche du clavier du PC/AT, l'utilisateur peut passer d'un mode d'affichage à un autre. Principalement on retiendra les modes suivants:
a) Hexadécimal. Dans ce mode, l'instruction est affichée en hexadécimal.

b) Mnémonique. Dans ce mode, l'instruction est désassemblée ou prise directement de l'éditeur ou de l'assembleur, puis affichée telle quelle, en langage symbolique.

c) Une combinaison des deux modes précédents où le PC est affiché en hexadécimal, et le reste de l'instruction en mnémonique.

d) Dans certains cas, il peut être intéressant de modifier les mémoires du kit en mode débogage. Pour ce faire, l'écran de débogage est divisé en plusieurs parties, dont une affichant la mémoire ou les périphériques du kit. L'utilisateur, par simple déplacement du curseur, peut modifier en temps réel, les registres du microprocesseur tout en restant sur son PC/AT. Lorsqu'une telle modification est demandée, le PC/AT envoie un message au kit comprenant l'adresse ainsi que le nouveau contenu de la mémoire ou du périphérique.

Le débogueur comprend une autre particularité qui consiste à préserver en mémoire le traçage de l'instruction. Principalement, les informations suivantes seront préservées en mémoire : l'instruction en binaire, l'instruction désassemblée ou le code source, les différents registres du microprocesseur, et les informations qui ont été altérées. En fait, celà revient à préserver en mémoire l'instruction en binaire et en source ainsi que la trame renvoyée par la carte. Il est très avantageux de faire un formattage de toutes ces informations et de les conserver en mémoire dans un fichier ASCII ouvert dans l'éditeur. Une telle procédure est utile dans deux cas:
1) Si l'utilisateur souhaite revenir en arrière dans le débogage
2) Pour l'impression des documents. Du fait que les informations de débogage sont mises dans un fichier texte ordinaire, l'utilisateur a toute faculté soit de les imprimer, d'en sélectionner des zones à imprimer, ou de les fusionner avec un autre fichier quelconque, comme par exemple avec le listage d'un assemblage.

L'invention comprend également un éditeur multi-fichiers dont la mémoire fonctionne d'une façon particulière. En fait, une grande partie de l'invention est axée autour de cette mémoire de l'éditeur. Dans un éditeur classique, l'édition multi-fichiers ne concerne que des fichiers TEXTE. Ici, un fichier pourra être également une trame binaire, le résultat d'un listage d'assemblage, un histogramme provenant du débogueur ou n'importe quel autre information ASCII. Le terme fichier est donc pris dans un sens beaucoup plus large. Ainsi lorsque l'assembleur produit une trame binaire, celle-ci n'est pas mise dans une portion de mémoire traditionnelle, mais est créée dans l'édi teur sous la forme d'un fichier traditionnel. Par la suite, si ce fichier binaire doit être utilisé (par exemple pour télécharger la carte), il suffira de lire le fichier dans l'éditeur qui a été créé. Cette procédure a deux avantages:
1/ I1 n'y a qu'une seule procédure de gestion mémoire. Les informations sont écrites ou lues dans la mémoire par des fonctions standards qui peuvent être appelées de n'importe quel module. Celà introduit donc une sorte de standardisation, mais également une meilleure occupation de la mémoire. En effet, au lieu d'avoir un certain nombre de mémoires spécialisées, il n'en existe pratiquement qu'une seule, de grande capacité, mais utilisable par n'importe quelle fonction. Puisque les fichiers sont mis les uns à la suite des autres, le gain de mémoire est réduit en conséquence.

2/ Le deuxième intérêt provient du fait que l'utilisateur a accès à ces fichiers sans l'utilisation de fonctions spécialisées. En fait, l'utilisateur devra connaître principalement cinq fonctions:
a/ Lecture d'un fichier du disque dur
b/ Ecriture d'un fichier sur le disque dur
c/ Fusion
d/ Suppression de la mémoire d'un fichier existant et dont on ne se sert plus.

e/ Création d'un nouveau fichier
I1 est donc extrèmement pratique au niveau de l'utilisateur de ne pas avoir à utiliser des fonctions spécialisées mais tout simplement un groupe de fonctions standardisées.

Cette standardisation de la gestion mémoire apporte également une certaine souplesse dans la conception des fonctions. En effet, lorsqu'une fonction a besoin d'une grande quantité de mémoire (comme par exemple pour mémoriser la trace des instructions), cette quantité de mémoire doit être prise dans la mémoire principale de l'éditeur. Une fois la fonction réalisée, la place occupée est libérée et l'éditeur retrouve sa mémoire initiale. Dans le cas où la mémoire n'est pas suffisamment importante, la fonction concernée peut très bien prévoir un stockage de certains fichiers qui ne sont pas en cours d'édition afin de se libérer de la place. A la fin de son processus, la fonction récupèrera les fichiers ainsi stockés temporairement sur le disque dur.

L'éditeur sera doté d'un vérificateur de syntaxe que l'utilisateur pourra mettre en oeuvre ou non. Le principe est le suivant: à chaque fois que l'utilisateur a introduit une ligne au clavier, au moment de la validation de celle-ci, la syntaxe de la ligne est examinée. Les erreurs sont immédiatement décelées. En fait, il s'agit d'une partie de l'assembleur accessible à partir de l'éditeur. Bien entendu, cette vérification n'est pas complète car au moment de l'introduction de la ligne, toutes les étiquettes ne sont pas encore présentes dans la table des symboles et ne peuvent être résolues. Il ne s'agit donc pas d'un assemblage pendant l'édition. Le vérificateur de syntaxe est destiné à l'apprentissage du jeu d'instructions du microprocesseur et vérifie si la syntaxe de l'instruction est correcte. Cette fonction peut également procéder à d'autres vérifications comme par exemple si une nouvelle étiquette introduite au clavier n'a pas déjà été introduite précédemment.

L'éditeur comprendra également des fonctions de mise en page de titres et commentaires. Pour la mise en page d'un titre, l'utilisateur introduit au clavier son texte, appuie sur une touche spécialisée et l'éditeur le formatte automatiquement en l'entourant d'astérisques. On sait que si la ligne d'instructions commence par un astérisque dans certains microprocesseurs, tout ce qui le suit est considéré comme ligne-commentaire. Dans d'autres microprocesseurs il s'agira de barres de fraction mais le principe reste le même.

Il en est de même pour les commentaires. Il est intéressant d'avoir une touche spécialisée qui, en début de ligne, met par exemple, 8 astérisques suivis d'un espace.

Les 8 astérisques ont la même largeur de champ que les 8 caractères d'une étiquette traditionnelle. Le curseur va donc automatiquement se positionner en colonne 10, ce qui est enprincipe le début du champ instruction. Toutefois, puisque la ligne a été commencée par un astérisque, il s'agit d'un commentaire. Ces deux fonctions de mise de titres et de commentaires sont très intéressantes pour la mise en page.

Toujours dans l'éditeur, une touche spécialisée fera apparaître un écran comprenant la carte mémoire du système matériel connecté au PC. Le fait d'avoir immédiatement par pression sur une touche spécialisée la carte mémoire du système est un avantage intéressant au niveau de l'utilisateur. Il sait ainsi en permanence où se trouve les différents périphériques et les zones de mémoire qui lui sont allouées. Cet accès à la carte mémoire du système dans l'éditeur pourra également se faire dans d'autres fonctions, comme par exemple à partir du débogueur.

En ce qui concerne l'assembleur, l'innovation intéressante consiste à prévoir la condition CASE dans l'assemblage conditionnel. Jusqu'à présent, les instructions du type CASE n'étaient disponibles que dans les langages évolués (langage C notamment). Dans les langages d'assembleur, une telle instruction peut être prévue à condition de modifier également le type de condition. La méthode envisagée est Ia suivante. L'assemblage conditionnel est toujours conçu autour de trois conditions : IF,
ELSE, et ENDIF. Au lieu d'avoir des variables binaires comme dans la technique actuelle, les variables sont soit numériques, soit du type chaine de caractères. Un autre type peut également être envisagé. Le format d'écriture de la variable est issu du langage C. Par exemple, on pourrait mettre:
IF (A > 4)
Dans cette éventualité, l'instruction CASE peut être envisagée. Avant de lancer l'assemblage conditionnel, il faut mettre tout simplement les conditions. Ainsi, dans l'exemple précédent, si le programmeur met comme condition initiale A = 3 la ligne concernée ne sera pas assemblée tandis que s'il met A = 6, elle le sera. Dans ce procédé, l'instruction CASE est utilisée pour assembler telle ou telle portion de programme en fonction d'une variable initiale. Elle suit la directive IF ou bien un au tre CASE. Cette directive doit obligatoirement être suivie d'une autre CASE ou d'un
ENDIF.

En ce qui concerne les symboles, généralement ceux-ci sont mis dans une mémoire appelée "table des symboles". Dans l'invention, ces symboles sont enregistrés dans la mémoire centrale de l'éditeur sour forme de fichier. Cette procédure permet, par la suite, d'éditer cette table, de la sauvegarder sur disques ou de faire n'importe quelle autre opération d'édition.

Le fonctionnement de l'assembleur est également différent sur le point suivant: lors de la passe 1, selon la disponibilité de la mémoire de l'éditeur, les fichiers à entête sont chargés dans la mémoire. Lors de la passe 2, l'assembleur regarde d'abord si ces fichiers sont présents en mémoire ; si oui, évidemment, il ne lit pas le disque dur. A la fin de l'assemblage, la mémoire qui contenait les fichiers d'entête est simplement effacée et rendue à l'éditeur. Cette procédure permet un gain de temps appéciable.

L'une des parties les plus importantes de l'invention concerne le listage en mémoire. Dans les assembleurs traditionnels, le résultat de l'assemblage (c'est-à-dire les codes d'opération, le compteur ordinal, l'instruction...) est affiché ligne par ligne sur l'écran. A la place de celà, l'invention prévoit de stocker en mémoire toutes ces différentes informations. Pour celà, un tableau de structures destiné à enregistrer les différentes informations résultant de l'assemblage est créé en mémoire. Chaque structure comprend des octets, des chaînes de caractères, des pointeurs ainsi que des entiers courts et longs. Ainsi, le nombre de cycles de l'instruction, le compteur ordinal, l'instruction elle-même en binaire, le pointeur vers la chaîne de caractères de l'instruction source ainsi que quelques informations spécialisées seront écrits dans ces structures.

Chaque structure du tableau s'associera à une ligne-source dans l'éditeur de façon à former le résultat complet de l'assemblage.

L'utilisateur peut soit écrire en mémoire sous forme de fichier les lignes ainsi créées (éléments de structure + ligne source), ou afficher directement sur l'écran ces lignes.

La visualisation sur l'écran du résultat de l'assemblage est une innovation réellement intéressante car elle permet à l'utilisateur d'avoir une visualisation très souple du résultat de son assemblage. Ainsi, il pourra voir une portion de programme se situant à la ligne 200, revenir au début des lignes, aller vers la ligne 1000, etc. De plus, l'invention prévoit quelques fonctions de défilement qui lui permettent de faire défiler l'écran, soit verticalement, soit horizontaIement et d'avoir ainsi une meilleure visualisation de son texte assemblé.

Cette fonction de visualisation du résultat de l'assemblage comprend également un formattage dynamique. Cette innovation très intéressante est basée sur le principe suivant: Certaines touches de fonction, comme par exemple les touches F2, F3, F4,..., sont affectées à des champs de l'instruction assemblée. Par exemple, respectivement, les touches F2, F3 et F4 peuvent être affectées aux champs suivants : numéro de lignes globales, numéro de lignes locales, nombre de cycles de l'instruction. Chaque champ particulier de l'instruction pourra avoir une touche de fonction spécialisée. Si l'utilisateur appuie sur l'une des touches de fonction, il visualise le champ concerné. Une autre pression sur la même touche de fonction enlève cette visualisation. Ainsi, c'est l'utilisateur qui décide de façon dynamique des différents champs de l'instruction qu'il souhaite visualiser. Ce point est très important, car dans les microprocesseurs 16 bits modernes, les instructions peuvent avoir plusieurs mots de long. Ainsi, par exemple, le 68000 peut avoir jusqu'à cinq mots de 16 bits de long (instruction MOVE), ce qui correspond à 20 caractères. Si l'on souhaite visualiser toutes les informations en même temps sur l'écran, on aura près de 45 caractères pris par le résultat de l'assemblage et le reste, soit 35 caractères, seront affectés à la ligne source. Nous nous plaçons évidemment dans le cas d'un écran standard de 80 caractères par ligne. Affecter 35 caractères à la ligne source est trop peu car les commentaires sont tronqués. Cette méthode qui consiste à conserver ou éliminer certains champs permet à l'utilisateur de personnaliser sa visualisation. Par exemple, dans un programme normal, il n'est pas utile de connaître le nombre de cycles de chaque instruction. Celà est utile dans les portions de programme qui ont une exécution en temps réel très critique. En éliminant ainsi le champ "nombre de cycles de l'instruction", on récupère six caractères. On pourrait avoir le même raisonnement sur les autres champs de l'instruction. Enfin, il est intéressant de ne visualiser que les trois ou quatre premiers mots de l'instruction, sachant que, si besoin est, un reformattage dynamique peut être instantanément réalisé.

Une touche spécialisée permet également de faire du défilement horizontal. Si la ligne est trop longue, le défilement horizontal permet de visualiser les caractères qui ne sont pas affichés à l'écran, sur sa droite.

Toujours dans le souci d'avoir le moins de caractères possibles inutiles à l'écran, certains espaces entre les champs seront supprimés. Les champs seront simplement délimités par les couleurs d'affichage sur l'écran. Nous supposerons donc que l'utilisateur possède un écran couleur.

Enfin, signalons que le fait d'enregistrer le résultat de l'assemblage dans la mémoire de l'éditeur est très pratique. L'utilisateur peut en effet éditer ce résultat, par exemple pour en faire une impression. Il peut par exemple supprimer des lignes inutiles, faire des mises en pages etc...

L'invention comprend également des fonctions de lecture et écriture en mémoire. Lorsque l'utilisateur veut écrire dans la mémoire de la carte connectée au PC, tous les octets ou demi octets introduits au clavier se mettent en surbrillance. Ce procédé permet à l'utilisateur de voir quelles ont été les modifications. De plus, lors des modifications, les anciennes valeurs sont sauvegardées dans la mémoire de l'éditeur (histogramme) sous forme de fichier. Une touche spéciale permet de récupérer l'ancienne donnée.

Par ailleurs, lorsque l'utilisateur met le curseur sous un octet ou un mot, un désassemblage en temps réel a lieu. Ainsi, l'utilisateur a trois formes de visualisation:
1) en hexadécimal
2) en ASCII,
3) en mnémonique (désassemblage symbolique).

Certains microprocesseurs comprennent des vecteurs, et le dés assembleur reconnaîtra automatiquement ces vecteurs. Le désassemblage symbolique aura lieu avec le nom d'origine du vecteur.

Dans la technique actuelle, l'affichage d'une page mémoire s'effectue généralement sur 256 octets. L'invention prévoit d'en visualiser 288, soit 2 lignes de 16 octets supplémentaires, mis en sous-brillance. Une première ligne est visualisée avant la page, et permet à l'utilisateur de voir les 16 octets précédant le début de page, et une deuxième ligne de 16 octets est visualisée après la page et permet de voir les 16 octets situés après la page. Ainsi, si une instruction ou une chaine de caractères se trouve tout à fait en début de page ou en fin de page, l'utilisateur pourra facilement visualiser les quelques octets environnants.

Des touches de fonction sont affectés au format de visualisation des informations en mémoire. La page de 256 octets pourra être affichée soit en octets, soit en mots de 16 bits (dans ce cas il y aura 128 mots de 16 bits), soit en mots de 32 bits, ou encore soit en mots de 16 ou 32 bits avec les bits de poids forts remplacés par des tirets. Dans ce dernier mode de visualisation, on ne conserve que les 8 bits de poids faibles. Cette visualisation est surtout intéressante pour les périphériques, car on sait que ceux-ci sont connectés généralement sur les 8 bits de poids faibles du bus de données. L'utilisateur pourra donc changer en temps réel et immédiatement son mode de visualisation. Une option permet toutefois de préciser si l'affichage a lieu sur les bits de poids faibles ou les bits de poids forts.

La fonction de lecture-écriture en mémoire sera pourvue d'un décodage complet des périphériques du système. L'utilisateur choisit dans une base de données les périphériques qui sont implantés sur la carte et indique au PC-AT leurs adresses d'implantation. Une touche de fonction permet alors de visualiser les adresses des registres de chaque périphérique, leur nom symbolique (CRA, DDRA...) ainsi que leur contenu. Cette dernière procédure évite à l'utilisateur d'avoir à décoder les registres des périphériques.

Le dés assembleur comprend une petite innovation sur les vecteurs. Certains microprocesseurs comme le 68000 disposent de vecteurs "câblés". Lors du désassemblage, l'étiquette symbolique de ces vecteurs est créée, même si celle-ci ne réside pas dans la table des symboles.

En ce qui concerne les problèmes d'impression, une innovation intéressante consiste à avoir dans le logiciel lui-même un délai. Ce délai existe déjà dans le DOS mais celui qui est proposé fonctionne d'une façon différente sur trois points.

1) Le délai initial est visualisé sur l'écran, ce qui donne à l'utilisateur une idée des temps écoulés.

2) Ce délai est multiplié par une fraction puis inclus dans une boucle qui effectue des tentatives de dialogue avec l'imprimante.

3) Les état sont affichés à l'écran et donnent également à l'utilisateur une idée de ce qui se passe.

Le nombre de tentatives que doit effectuer l'utilisateur pour amorcer un dialogue ainsi que le délai sont programmables. Concrètement, celà se passe de la façon suivante. Lorsque l'utilisateur veut lancer une impression et que l'imprimante n'est pas disponible, il s'écoule d'abord un certain délai. Ce délai est à peu près équivalent au temps écoulé pour faire un saut de page. A la fin de ce délai (donc pratiquement à la fin d'un saut de page éventuel), si l'imprimante n'est toujours pas disponible, on entre alors dans une boucle de tentatives. Le nombre de tentatives pourra être par exemple égal à 100. Entre deux tentatives, il y aura un second délai qui sera calculé en multipliant le délai initial par une fraction. Ce deuxième délai ainsi calculé sera donc nécessairement inférieur au premier (celui du saut de page). Ainsi, puisque à la fois le délai initial et le nombre de tentatives sont tous les deux programmables par l'utilisateur, ce dernier peut réellement décider du temps au bout duquel il considèrera que la liaison est défectueuse. Il optimisera son imprimante et son unité centrale de façon à avoir le moins d'attente possible.

Ce phénomène d'attente est connu de tous les utilisateurs du DOS et est d'autant plus critique qu'il n'existe qu'une information visuelle. Dans l'invention, l'utilisateur voit le délai initial se décrémenter sur l'écran ainsi que le nombre de tentatives. Il peut ajuster ces deux valeurs d'après les informations qu'il visualise, ce qui est quand même très intéressant. De plus, l'état de la transmission est affiché non seulement en hexadécimal, mais également décodé bit à bit et en symbolique, ce qui lui donne des informations supplémentaires. L'objectif de ce procédé est donc de fournir à l'utilisateur un moyen efficace de gestion sur l'imprimante.

Avec le DOS actuel, lorsque l'utilisateur rencontre un problème de dialogue avec son imprimante, très souvent il est condamné à agir au hasard. De plus, il n'existe qu'un seul délai entre deux tentatives de dialogue et un saut de page est considéré comme erreur de transmission...

Enfin, le procédé suivant est prévu de façon à permettre à la carte connectée au
PC de disposer d'un noyau en temps réel du genre OS9. Dans ces noyaux, il est souvent nécessaire de sauvegarder des fichiers. Si la carte ne comprend pas de contrôleur de disques, celà est impossible. Dans ce cas, il est possible de prévoir sur la carte une sauvegarde des fichiers, non pas en mode RBF (fichier de blocs à accès aléatoire ou "Random Bloc File"), mais en mode SCF (fichier de flux de communication ou "Stream
Communication File). En fait, le même canal d'entrée sortie qui sert au dialogue avec le PC sera utilisé pour faire des lectures-écritures sur disques. Le driver d'écriture lecture sur disque aura la particularité suivante. A chaque fois qu'un dialogue est initialisé, ce driver envoie sur le canal de transmission un code spécial. De l'autre côté de la transmission, c'est-à-dire au niveau du PC, lorsque celui-ci reçoit ce code il sait qu'il ne s'agit pas d'un dialogue terminal ordinaire mais d'un dialogue RBF simulé. Le PC passe alors dans une portion de programme qui dessérialise les informations et les enregistre sur disque s'il s'agit d'un dialogue d'écriture, ou qui fait l'inverse s'il s'agit d'un dialogue de lecture. Le schéma global du dialogue est donc le suivant: le PC effectue des lectures-écritures sur disque dur, puis il sérialise ou dessérialise les informations, il les transmet ou les reçoit par son canal série (la RS 232) et la carte les lit ou les écrit à l'aide d'un driver spécialisé simulant le RBF. L'intérêt de cette procédure est que l'utilisateur peut implémenter un noyau en temps réel sur une carte rudimentaire ne comprenant aucun dialogue avec les disques. Evidemment, ce procédé n'est pas sans avoir un inconvénient: celui de la vitesse. Le fait de transmettre des fichiers par liaison-série à 9600 bauds est effectivement une procédure extrèmement lente. Toutefois, cette procédure peut très bien s'appliquer avec une grande efficacité dans des cas précis comme par exemple lorsque la carte doit avoir un budget restreint, ou lors de l'enseignement du microprocesseur, etc.

Une variante de ce procédé consiste à réaliser dans le PC une carte qui est connectée à la carte extérieure par une liaison parallèle. Le principe reste le même mais la vitesse sera nettement plus grande du fait que les informations seront transmises en parallèle et non en série.

Claims (17)

REVENDICATIONS

1. Dispositif de débogage en temps réél caractérisé en ce qu'il comprend deux parties scindées, d'une disposée sur une carte à microprocesseur et l'autre sur un ordinateur du genre PC renfermant des procédures de gestion de messages et un environnement complet de développement d'applications.

2. Dispositif selon la revendication 1, caractérisé en ce que la carte à microprocesseur comporte une mémoire pour mémoriser le contexte du microprocesseur.

3. Dispositif, selon la revendication 1, caractérisé en ce que l'ordinateur comporte une mémoire d'éditeur multifichiers comprenant en outre les fichiers TEXIE, le fichier de trames binaires, le fichier des codes résultant de l'assemblage, un fichier d'histogramme des instructions exécutées, un fichier de trace de la mémoire de la carte, un fichier conservant les étiquettes du code source, les fichiers à entête et des fichiers de n'importe quelle information ASCII.

4. Dispositif, selon la revendication 1, caractérisé en ce que la carte est conçue pour recevoir un noyau en temps réel ayant comme périphérique le PC et communicant avec lui soit par la liaison série, soit par une carte mise à l'intérieur du PC mais assurant la même fonction.

5. Dispositif selon la revendication 3 caractérisé en ce que l'éditeur est doté d'un vérificateur de syntaxe des instructions, des directives et autres données, ainsi que des fonctions de mise en page de titres et de commentaires.

6. Procédé pour réduire le temps de transfert entre les deux parties du dispositif de débogage selon l'une des quelconques revendications 1 à 3, caractérisé en ce qu'il consiste à:

- Mémoriser dans la mémoire de la carte le contexte du microprocesseur,

- Renvoyer vers l'ordinateur, lorsque celui-ci effectue la première opération, le contexte intégral avec somme de vérification en vue de son affichage sur l'écran,

- Comparer à chaque nouvelle opération, le nouveau contexte et l'ancien contexte mémorisé,

- Ne renvoyer vers l'ordinateur que les registres ou éléments qui ont été modifiés avec des codes distincts pour les données en 8, 16 et 32 bits.

7. Procédé, selon la revendication 6, caractérisé en ce que les informations entre la carte et l'ordinateur peuvent être transmises soit en mode TEXIE, soit en mode binaire pur avec, dans les deux cas, une vérification par somme.

8. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la visualisation sur l'écran du contexte modifié et non modifié s'effectue avec des couleurs différentes de façon à mettre visuellement en évidence toute modification dudit contexte.

9. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend une étape consistant à modifier en temps réél le format, l'emplacement ou la représentation des données lors de la visualisation.

10. Procédé, selon la revendication 3, caractérisé en ce que chaque ligne de code issu de l'assembleur et enregistré en mémoire comprend, outre le code-objet, un pointeur vers la ligne-source correspondante, le nombre de cycles, le compteur ordinal ainsi que d'autres informations spécialisées relatives à la ligne qui vient d'être assemblée.

11. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend, lors des commandes de lecture-écriture en mémoire, une étape de désassemblage symbolique en temps réél de l'octet pointé par le curseur avec identification symbolique des vecteurs ou adresses, et de visualisation du résultat dudit désassemblage.

12. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend, lors des commandes de lecture-écriture en mémoire, une étape consistant à visualiser les quelques octets ou mots précédents le début de la page affichée ou situés après la fin de page.

13. Procédé, selon l'une quelconque des revendications 11 ou 12, caractérisé en ce qu'il comprend, dans la commande de débogage, une étape qui consiste à appeler la commande de lecture-écriture et de pouvoir ainsi modifier en temps réél, par l'intermédiaire de ladite commande, les données du contexte.

14. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'on peut appeler, de n'importe quel endroit du système, un écran d'aide indiquant la carte mémoire du système.

15. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la commande de lecture-écriture dispose de plusieurs formats d'affichage, 8 bits, 16 bits, 32 bits ou en mode périphérique 16 ou 32 bits, lequel mode a 8 ou 16 bits actifs et les autres bits ignorés.

16. Procédé, selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'assembleur reconnaît une nouvelle instruction conditionnelle de l'assembleur,

CASE qui, conjointement aux instructions IF-ELSE, accepte toutes sortes de valeurs de condition, aussi bien binaires que du type texte ou chaînes de caractères et dont le rôle est de faire un choix de 1 parmi n.

17. Procédé, selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend les étapes suivantes en cas d'impossibilité de communication avec l'im primante:

- Ecoulement d'un délai initial programmable

- A la fin de ce délai et en cas d'échec, mise en oeuvre de tentatives de communications dont le nombre est programmable et la durée est une fraction du délai initial.

- Parallèlement à ces deux temporisations, affichage sur l'écran du délai initial, du nombre de tentatives, du délai de chaque tentative et des états de la ligne décodés en clair.