Brevet FR2656938A1 — publié le 19910712

La présente invention concerne un dispositif nouveau pour étudier et développer des applications à microprocesseur. Il 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 (VT100 par exemple) par un PC ou vice-versa le prouve. Il 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. 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'écriture/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 S1S9 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 CRC16 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 la 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 l'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 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'utilisateur. 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 diaioguera 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 DIN41612, disposera de tous 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. a/ Le signal de validation des REPROM sera disponible. Ce signal permet à l'émulateur 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 microprocesseur 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 signaux 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 remplacés par un interrupteur multiple (dip-switch) ou par une petite carte de simulation de présence d'émulateur. REVENDICATIONS 1. Dispositif de débogage en temps réel d'applications à microprocesseur, caractérisé par 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 approprié à l'émulation en temps réel et des courts-circuits de signaux. 2. Dispositif selon la revendication 1, constitué par une carte de 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 reportés partiellement 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éel" étant sur la carte qui sert 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 chacune 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 les signaux qui vont vers l'extérieur par le connecteur et ceux qui reviennent par l'émulateur peuvent être court-circuités.