FR 2689991 A1 19931015 FR 9204603 A 19920413 La présente invention concerne un dispositif nouveau pour étudier et développer des applications à microprocesseur. I1 s'agit d'une carte et d'un logiciel qui fonctionnent conjointement avec un ordinateur hôte quelconque (du type PC par exemple). De telles cartes existent déjà dans l'état actuel de la technique mais leur fonctionnement est différent de celui décrit dans la présente invention. En effet, la-mise au point de programmes (édition, assemblage, débogage...) se fait généralement de deux façons: - Par simulation logicielle au niveau du PC. Cette méthode a l'inconvénient de n'être que de la simulation et l'aspect "temps réel" y est donc totalement absent. - Par des cartes appelés "kits" qui ont leur propre programme de gestion: éditeur, assembleur, débogueur... L'inconvénient de ce type de fonctionnement se situe surtout au niveau du stockage des informations. Les "kits" n'ayant pas de disques, le stockage se fait en envoyant les programmes vers une unité quelconque (PC ou autre), solution assez lourde. Par ailleurs, il faut noter que même si ces cartes sont reliées à un PC, ce dernier fonctionne alors en mode terminal et est donc dépourvu d'intelligence. Le simple fait de remplacer un terminal (VT1OO par exemple) par un PC ou vice-versa le prouve. I1 en est de même lorsque le PC sert de moyen de stockage : il est possible de remplacer ce dernier par un lecteur de cassettes par exemple, ce qui prouve que là aussi le PC est dépourvu "d'intelligence". Le procédé décrit ici est une troisième solution. Selon l'invention, le développement d'une application s'effectue à la fois par le PC et par la carte. Tout l'aspect "temps réel" (fonctions élémentaires de débogage notamment) est mis sur la carte tandis que toutes les fonctions non "temps réel" sont reportées sur le PC. Les logiciels (éditeur, assembleur, débogueur...) qui auparavant se trouvaient entièrement sur la carte sont ainsi partagées entre le PC et la carte. Les deux ensembles fonctionnent ainsi en parallèle, contrairement au mode "terminal" où chaque élément fonctionne l'un après l'autre. Selon l'invention, le PC dispose des logiciels suivants: - Un éditeur - Un assembleur/compilateur - La partie non "temps réel" du débogage - Un gestionnaire de messages La carte associée au PC comprend les logiciels suivants: - La partie "temps réel" du débogage - Un gestionnaire de messages L'invention est basée sur deux points fondamentaux: d'abord le débogueur est scindé en deux parties, l'une sur PC et l'autre sur la carte, et ensuite le PC et la carte disposent chacun d'un gestionnaire de messages décrit plus loin. L'éditeur et l'assembleur/compilateur qui se trouvent sur le PC n'entrent pas dans le cadre de cette invention. si le logiciel correspondant n'a pas été légalement acheté. De même, ce protocole permet au PC de s'assurer que la carte est présente. Ceci est particulièrement important pour éviter le piratage du logiciel. Ainsi, avec la carte seront vendus un débogueur, un éditeur, un assembleur, un désassembleur et d'autres logiciels divers. Ces différents logiciels ne seront pas protégés mais avant leur exécution, un contrôle de la présence de la carte sera effectué. Dans ce sens, la carte joue également le rôle d'une clé "anti-piratage". L'un des aspects innovants de cette invention est de faire du multi-tâches. En effet, la carte et le PC pourront exécuter dans le même temps deux tâches différentes. Par exemple, si un programme présente un bogue intermittent qui survient une fois toutes les 20 minutes, le PC envoie l'ordre d'exécution en temps réel du programme à la carte et passe à une autre tâche. La carte exécute alors le programme mis auparavant dans sa mémoire vive et attend le bogue (plus exactement la détection d'un point d'arrêt judicieusement placé). Pendant ce temps, le PC exécute un autre programme (édition, assemblage...). Une fois le bogue rencontré, une interruption sera envoyée au PC et celui-ci reprendra éventuellement le contrôle du débogage. L'invention prévoit également une procédure de génération de débogueur adaptée à une application particulière. Cette procédure est décrite ci-dessous. Le moniteur de la carte pourra être vendu en tant que tel. Un tel moniteur simplifierait considérablement les fonctions de débogage d'une nouvelle carte non testée. Dans bien des cas, les utilisateurs hésitent à acheter un émulateur toujours très coûteux. La procédure suivante qui est une suite logique de l'invention est destinée à fournir à moindre frais un dispositif fort simple de test d'une nouvelle carte. Dans cette optique, le moniteur est livré sur disquette, non adapté à la maquette de l'u- tilisateur. Un programme de configuration demande à l'utilisateur d'introduire les adresses de base de la carte qu'il veut faire fonctionner: adresses de la RAM, de la REPROM, de l'interface série... A partir de ces informations, le PC construit lui-même le moniteur qui dialoguera avec lui. Il s'agit du même moniteur que celui qui vient d'être décrit dans l'invention. Le moniteur ainsi construit sera tranféré dans une ou plusieurs REPROM qui se mettront sur la maquette à tester. Une fois ces REPROM mises en place, un dialogue s'instaurera entre le PC et la carte à tester puisque celle-ci contient un moniteur avec les adresses correctes. Les fonctions de débogage étant alors disponibles, la mise au point s'en trouverait considérablement accélérée. L'ensemble de la manipulation (adaptation, programmation...) ne devrait pas prendre plus d'une quinzaine de minutes et fournirait un moyen très efficace et peu coûteux de tester les cartes en temps réel. De plus, le logiciel du PC contenant un éditeur et un assembleur, les modifications du programme ainsi que les corrections d'erreurs s'en trouveraient également simplifiées. Enfin, il se peut que l'utilisateur n'arrive pas à déboguer son application à l'aide du débogueur carte/PC.-Dans ce cas, il devra avoir recours à un émulateur en temps réel. Pour faciliter les connexions avec ce type d'appareil, la carte disposera d'un connecteur sur l'un de ses bords. Ce connecteur, qui pourra être par exemple du type Dix41612, disposera de tous Ainsi, d'après l'invention, ni la carte ni le PC ne peuvent fonctionner d'une façon autonome l'un sans l'autre. Même si l'on remplace le PC par un terminal, la carte ne pourra pas fonctionner puisque la partie "non temps réel" du débogage est alors absente. La partie la plus lourde du débogage, et notamment le déroulement des menus, l'introduction des commandes, la visualisation des registres, les points d'arrêt etc..., se trouve sur le PC. La carte, quant à elle, contient principalement les logiciels d'écritùre/lecture en mémoire (ou interfaces), de pas à pas et de déroulement de programme. Le gestionnaire de messages a pour rôle d'assurer le dialogue entre le PC et la carte. Le PC envoie des ordres à la carte et celle-ci les exécute. La carte retourne éventuellement au PC les informations que ce dernier lui demande, comme par exemple le résultat d'une lecture en RAM. Ce gestionnaire de messages est basé sur un protocole pouvant s'inspirer de celui qui est décrit ci-dessous (le détail de ce protocole relève de l'art de l'ingénieur et n'a pas sa place dans le présent brevet d'invention). Chaque message (appelé également "trame") est formé d'un ou de plusieurs caractères ASCII. Les octets ou adresses sont également transmis en ASCII selon les procédures habituelles SIS9 ou Intel-Hex; chaque demi-octet est encodé en ASCII. Les principales commandes sont les suivantes: - Ordres de lecture de la mémoire de la carte. Le PC envoie vers la carte un identificateur, comme le point-virgule (";") par exemple, suivi d'une adresse, d'un compteur (nombre de caractères de la trame) et d'un moyen de vérification du type CROC16 ou "check-sum". A noter que le check-sum est mieux approprié à ce type de transmission. Après détection correcte du check-sum, la carte envoie au PC les données que celui-ci lui demande. La trame envoyée au PC par la carte se compose d'un identificateur, d'un compteur, des données et d'un check-sum. Le nombre d'octets est calculé d'après le compteur. - Ordres d'écriture dans la mémoire de la carte. Le PC envoie vers Ia carte un identificateur, comme par exemple le point ("."), suivi d'une adresse, d'un compteur et des données. A la fin de la trame se trouve un check-sum. - Ordres divers. Le PC peut envoyer à la carte des ordres divers avec ou sans argument, comme I'exécution d'une instruction (pas à pas), le déroulement rapide en temps réel, la remise à zéro et annulation d'une commande (lors de la détection d'une erreur de check-sum) ou la reconnaissance d'une information ("data acknowledge"). De même, la carte pourra envoyer au PC des ordres divers comme la reconnaissance d'une-information ou la détection d'une erreur. Afin de limiter au maximum les ordres, le PC devra connaître les différentes adresses stratégiques de la carte. Par exemple, pour visualiser les registres internes du microprocesseur, lire une zone de mémoire, de pile ou d'un périphérique, il lui suffit de procéder à une lecture de quelques adresses bien précises dans lesquelles le moniteur de la carte range ces différentes informations en temps réel. Ce même protocole sera également utilisé pour charger le programme en mémoire, de préférence au S1S9 ou à l'Intel-hex. La raison est simplement d'éviter l'utilisation de la carte les signaux du microprocesseur (bus d'adresses, de données, de contrôle...) et des principaux signaux stratégiques. Elle aura cependant les deux particularités suivantes. al Le signal de validation des REPROM sera disponible. Ce signal permet à l'émula teur qui lui est associé de simuler les REPROM par des RAM se trouvant dans l'émulateur. b/ Dans une application classique, les signaux du microprocesseur qui sont disponibles sur un connecteur quelconque sont distribués également vers la logique. Dans l'invention, certains signaux (R/W, E, RESET, DMA, HALT...) viennent directement du microproces seur et ne vont pas vers la logique. Par contre, le connecteur "fournit" ces mêmes signaux vers la logique. En fait, c'est à l'émulateur qui sera relié à ce connecteur de recevoir les si gnaux du microprocesseur et de les renvoyer vers la logique. Par exemple, le signal R/W n'est pas distribué directement du microprocesseur vers la logique. Ce signal va vers le connecteur, se dirige ensuite vers lémulateur, revient vers le connecteur (sur une autre cosse) et est enfin distribué à la logique. Cette particularité est nécessaire pour permettre à l'émulateur de disposer des bus du système pour faire différentes opérations comme du DMA. Ceci étant, il est évident que la carte pourra également fonctionner sans émulateur. Pour permettre celà, des liens seront prévus afin de permettre une distribution dans toute la logique des signaux du microprocesseur en l'absence d'émulateur. Bien entendu, ces liens pourront être remplaces par un interrupteur multiple (dip-switch) ou par une petite carte de simulation de présence d'émulateur. H est prévu dans le débogueur, uneprocédure de défilement horizontal du contexte du microprocesseur. Certains microprocesseurs ont un nombre important de registres et il n'est pas possible de les visualiser simultanément sur la même ligne. A l'aide d'une touche spé cialisée ou de la souris, l'utilisateur pourra faire défiler les registres dans le sens horizontal de façon à visualiser rapidement les informations qu'il souhaite obtenir. Pour celà > le débo gueur prépare déjà dans une mémoire tampon les informations à visualiser et les affiche avec un certain décalage (ou "offset") par rapport à l'origine. Ce décalage pourra être d'un ou de plusieurs caractères ou bien d'un ensemble de caractères. En effet, les registres sont géné ralement sur 8, 16 ou 32 bits, ce qui fait 2,4 ou 8 caractères. n est judicieux de prévoir un défilement non pas sur la base du caractère mais sur celle du registre. Cette procédure est entièrement programmable par l'utilisateur. Si ce dernier souhaite éliminer certains registres sans intérêt pour lui il pourra programmer le défilement hori zontal. lIen est de même avec l'ordre des registres qui pourra être modifié par rapport à l'ordre initial selon les souhaits de l'utilisateur. En ce qui concerne la gestion des fichiers, une amélioration intéressante consiste à in clure, dans la fenêtre de dialogue pour l'ouverture ou la fermeture d'un fichier, deux listes; la première concerne les fichiers présents sur le disque et susceptibles d'être ouverts ou fermés, et la deuxième concerne la fenêtre dans laquelle le fichier est chargé ou sauvegardé. Il devient ainsi possible de charger ou sauvegarder un fichier à partir d'une fenêtre précise et non par défaut comme c'est le cas dans la technique actuelle. Une procédure, par touche de fonction ou autre, permet en outre de remettre en séquence les numéros de fenêtres. En effet, certaines fenêtres peuvent être fermées, ce qui laisse un "trou" au niveau du numéro. Cette procédure permet de combler le trou et d'avoir un ensemble homogène de fichiers ouverts simultanément. Une procédure par touche de fonction permet de filtrer les fichiers édités et visualisés à l'écran selon l'extension ou un autre code quelconque. Les caractéristiques de chaque fichier sont écrites dans une structure et l'utilisateur sélectionnera tel ou tel type de fichier à l'aide d'une clé (menu d'options par exemple). Dans les systèmes actuels, les éditeurs multi-fenêtres n'opèrent que sur des fichiers texte. Al'aide de cette sélection, il sera ainsi possible d'éditer le listing d'un assemblage, les trames binaires HEX, les fichiers de macro-instructions ou tout autre fichier. Sur la carte, une innovation intéressante consiste à prévoir deux ou plusieurs emplacements pour certains circuits intégrés, et notamment les périphériques programmables. Les lignes d'entrées/sorties asynchrones et de dialogue sont mises en parallèle. La majorité des lignes de bus également. Pour éviter tout confit, l'utilisateur ne laissera sur le support qu'un seul circuit intégré à la fois. Par exemple, le 68000 pilote aussi bien des PIA que des PIT. Rien n'empêche de prévoir deux emplacements (deux supports) mis en parallèle, l'un pour le PIA et l'autre pour le PIT. L'utilisateur n'aura qu'à choisir son périphérique en enlevant simplement celui qu'il n'utilise pas (qui risquerait d'ailleurs de faire des conflits s'il n'était pas retiré). Enfin, la carte sera pourvue d'une dernière particularité qui consiste à disposer d'un ensemble de deux connecteurs, l'un synchrone et l'autre asynchrone. Ils'est pas indispensable que ces connecteurs soient séparés. Le connecteur synchrone comprend les signaux du microprocesseur, éventuellement amplifiés. On trouve notamment les lignes d'adresses, de données et de gestion. Quelques lignes asynchrones comme celle de la remise à zéro sont également présentes. Le mot "synchrone" doit donc être pris dans son sens large. Ce connecteur est du même type que celui que l'on trouve sur les PC ou autres ordinateurs. Le connecteur asynchrone comprend les lignes provenant de périphériques programmables comme DUART, PLA ou Pfr. H existe également des systèmes ayant un connecteur asynchrone, c'est la combinaison des deux qui n'existe pas dans l'état actuel de la technique. L'utilisateur qui souhaite réaliser des cartes d'entrées-sorties aura donc le choix de son bus, soit celui du microprocesseur, soit celui des interfaces programmables. L'intérêt d'un double bus est que certains types de circuits, notamment les convertisseurs analogiques-digitaux ou vice-versa, peuvent se connecter indifféremment sur un bus microprocesseur ou périphérique. Du fait de cette innovation, l'utilisateur a moins de câblage à réaliser puisqu'il choisit lui-même sa configuration optimale. REVENDICATIONS 1. Dispositif de débogage en temps réel d'applications à microprocesseur, caractérisé E)ar le fait qu'il comprend un débogueur scindé en deux parties, des procédures de gestion de messages, un générateur de débogueur pour les applications particulières, un connecteur appropric à l'émulation en temps réel et des courts-circuits de signaux. 2. Dispositif selon la revendication 1, constitué par une carte dc débogage comprenant son propre programme de gestion, caractérisé par le fait que l'ensemble des logiciels ne résident plus sur la carte elle-même mais sont reports partiellelllent sur un ordinateur. 3. Dispositif, selon l'une des revendications 1 et 2, dans lequel le débogueur est scindé en deux parties pouvant travailler simultanément, l'une des parties du type "temps récl" étant sur la carte qui scrt de support au débogage, l'autre partie du type "non temps réel" étant sur un ordinateur. 4. Dispositif, selon l'une des revendications 1 à 3, dans lequel chacunc des deux parties, ordinateur et carte, comprend un gestionnaire de messages dont le rôle est de transmettre des informations bi-directionnelles, principalement les accès mémoire et les commandes de déroulement de programme en pas à pas ou temps réel. 5. Dispositif, selon l'une des revendications 1 à 4, dans lequel les signaux du microprocesseur sur la carte de développement sont distribués vers la logique via un connecteur.dont le rôle est de recevoir un émulateur. 6. Dispositif, selon l'une des revendications 1 à 5, dans lequel Ics signaux qui vont vers l'extérieur par le connecteur et ceux qui reviennent par l'émulateur peuvent être court-circuités. 7. Dispositif, selon l'une des revendications 1 à 6, qui réalise un défilement horizontal des informations affichées sur l'écran lors d'un débogage, Iequel défilement est programma bIe et est établi sur une base modulo "n" caractères. 8. Dispositif, selon I'une des revendications 1 à 7, qui affiche deux boîtes de dialogue lors des commandes de gestion de fichiers, la première boîte comprenant le fichier ét la se- conde, la partie de mémoire ou fenêtre concernée par l'opération à effectuer sur le fichier. 9. Dispositif, selon l'une des revendications 1 à 8, constitué par une touche de fonction qui effectue une remise en séquence automatique des numéros de fenêtre et un filtre de fi chiers, qui permet de sélectionner les fichiers qui se trouvent dans les fenêtres et qui sont édités. 10. Dispositif, selon l'une des revendications 1 à 9, constitué par une mise en parallèle des signaux de plusieurs circuits intégrés, la validation de l'un d'eux se faisant par le retrait de l'autre mis en parallèle. 11. Dispositif, selon l'une des revendications 1 à 10, constitué par la combinaison de deux types de connecteurs, l'un comprenant les signaux du microprocesseur, l'autre compre nant les signaux d'interfaces programmables.