Rapport de projet de JAVAdonpichol.free.fr/IFITEP/JAVA/Simulator8051.pdf · Matthieu SIMON 8051 Simulator v0.2 Structure générale du contreur d'interruption du noyau 80C51 : 2.4

Rapport de projet de JAVA

8051 Simulator v0.2

Matthieu SIMON

IFITEP 3

Juin 2005

Matthieu SIMON 8051 Simulator v0.2

Sommaire :

1/ Présentation du sujet Page 1

2/ Fonctionnement d'un microcontrôleur 80C51 Page 22.1/ La mémoire de données (RAM) Page 3

2.2/ L'unité centrale de traitement (CPU) Page 4

2.3/ Le contrôleur d'interruption (IC) Page 5

2.4/ Autres périphériques Page 7

3/ Méthode de conception du simulateur Page 83.1/ CORE_AsmLine & CORE_AsmParser : l'analyseur de syntaxe Page 10

3.2/ CORE_CPU8051 : le coeur du simulateur Page 10

3.3/ Opcode & Opcode... : les instructions Page 12

3.4/ CORE_HEXLoader : le support de l'instruction MOVC Page 12

3.5/ CORE_Timers & CORE_Interrupts : les périphériques Page 13

4/ Interface graphique utilisateur Page 13

5/ Le projet avec un peu de recul Page 15

6/ Annexes Page 16

Projet de JAVA 2005 IFITEP 3 Sommaire


1\ Présentation du sujet

Le but est de réaliser un simulateur de microcontrôleur, ceci consiste en réalité à reproduire lefonctionnement du circuit électronique par le biais d'un programme informatique écrit en JAVA. Cedernier doit pouvoir fonctionner sur un ordinateur, il est alors possible de développer une applicationciblée sans pour autant nécessiter le matériel adéquate. Limitant ainsi les coûts de conception pour lesentreprises.

Dans notre cas il s'agit de pouvoir simuler un programme écrit par l'utilisateur et de l'informer sur sondéroulement. Il peut alors déceler et modifier rapidement son programme en cas de problèmes. Il estdonc nécessaire d'intégrer des objets de visualisations et d'informations de l'état général du circuit. Lesnouveaux microprocesseurs intègrent désormais des interfaces dites de « debug » qui permet de scruterles différents paramètres afin de contrôler le fonctionnement d'un programme. Ces interfaces sont alorstotalement matérielles et sont intégrées directement dans les masques du circuit.

Le microcontrôleur que nous souhaitons simuler est un 80C51, coeur 8 bits conçu il y a quelquesannées par Intel, il n'offre pas d'interface de debug dans sa version de base. Dans un premier tempsnous pouvons dire qu'il suffirait de scruter la mémoire de données du circuit afin de se renseigner surson état.

Ce circuit est un standard de l'industrie, de nombreux fondeurs ont développés des microcontrôleursbasés sur un coeur de 80C51. Il propose par défaut une unité centrale de traitement (CPU), de lamémoire et quelques périphériques standards tels que des compteurs, des entréessorties parallèles etainsi qu'un contrôleur de liaison série asynchrone fullduplex (UART). Ces différents modules serontprésentés par la suite.

Projet de JAVA 2005 IFITEP 3 Page 1 sur 16


Le principe du simulateur va donc être d'interpréter et d'exécuter à la volée le code source d'unprogramme, en l'occurrence du code assembleur. Il doit pouvoir aussi être capable d'afficher l'état de lamémoire de données (RAM) par l'intermédiaire d'une interface graphique. Afin d'avoir plus de contrôlesur le déroulement du programme il est nécessaire de pouvoir exécuter le programme pas à pas etmodifier la mémoire de données. Les différents périphériques internes doivent aussi être fonctionnels.Des composants graphiques sont souvent disponibles, ils permettent de modéliser rapidement despériphériques élaborés comme un écran à cristaux liquides ou encore un terminal de liaison série.

2/ Fonctionnement d'un microcontrôleur 80C51

Cidessous, la représentation de l'architecture interne d'un microcontrôleur 8 bits Intel 80C51 :



Comme vu précédemment, le circuit se compose par défaut de (liste exhaustive) :– 256 octets de mémoire de données (RAM), dont 128 pour les registres.– 4k octets de mémoire programme (ROM).– Une unité de centrale de traitement (CPU).– Un contrôleur d'interruption.– Un étage « oscillateur » pour générer l'horloge du circuit.– Un contrôleur de bus.– 2 compteurs 16 bits.– 4 ports parallèles 8 bits d'entrées/sorties.– Une interface série fullduplex.– Un contrôleur de bus externe permettant d'extraire du circuit le bus de données et d'adresses

afin d'étendre par exemple la mémoire.

2.1/ La mémoire de données (RAM)

La mémoire se décompose en 2 blocs distincts. Le premier, partant de l'adresse 0 et d'une taillede 128 octets, représente l'espace utilisable par le programme pour allouer la pile (STACK) et le tas(HEAP). On trouve au début de ce bloc quatre banques de 8 registres dis à usages généraux. Cettedénomination est trompeuse car on appelle typiquement « registres à usages généraux » les registresutilisés par l'unité centrale de traitement qui sont, quand à eux, contenus dans le second bloc. On trouveégalement une plage adressable au niveau du bit.Le second, de 128 octets également, est appelé SFR pour Special Function Registers. On trouve ici tousles registres internes qui régissent le fonctionnement du circuit comme l'indique la figure suivante :



On retrouve les registres appelés généralement GPR pour General Purpose Registers :– ACC : Accumulateur 8 bits, utilisé pour les transferts mémoire et les calculs.– PSW : (Program Status Word) Registre d'état du microprocesseur qui contient les bits de

retenue, de dépassement, de parité, ... . On retrouve ce registre dans tous lesmicroprocesseurs sous le nom de PSW ou CCR pour Code Condition Register.

– B : Accumulateur utilisé pour les multiplications et divisions.– SP : (Stack Pointer) C'est le pointeur de pile.– DPHDPL : (DPTR) Registre 16 bits utilisé pour les transferts avec la mémoire externe.

A noter que le PC (Program Counter) n'est pas accessible via l'adressage mémoire. Il ne peut donc pasêtre modifier par programme, seuls les instructions de branchement peuvent modifier le compteurordinal.

2.2/ L'unité centrale de traitement (CPU)

C'est en réalité le microprocesseur du circuit, il se compose des différents éléments que l'onretrouve couramment dans ces derniers. On l'appelle souvent « coeur » (ou CORE) car elle forme lapièce maîtresse de tout système à microprocesseur, avec la mémoire.

Les documentations techniques fournies par les constructeurs ne présentent pas énormément de détailssur l'architecture du coeur, on peut donc considérer qu'elle ressemble étroitement à une architecture 8bits standard. Elle a donc la particularité de pouvoir exécuter son propre jeu d'instructions, le 80C51étant de type CISC, le jeu est conséquent (une quarantaine d'instructions) et la longueur de cesdernières n'est pas fixe. Comme tout microprocesseur, une unité de contrôle est présente permettant derécupérer une instruction depuis la ROM (Fetch), de la décoder (Decode) et de l'exécuter suivant sontype. Trois types d'exécutions se distinguent vraiment et sont communes à tous les microprocesseurs :

– Transferts de mémoire ROM et RAM : toutes les instructions qui écrivent/lisent la mémoire.– Branchements vers une sousroutine : sauts relatifs et absolus, consiste à modifier le

compteur ordinal (PC), en l'ayant sauvegardé auparavant dans la pile (uniquement lors desauts absolus).

– Calculs en nombres entiers : réalisés par l'unité arithmétique et logique (ALU), unitématérielle spécialement dédiée pouvant réaliser des opérations booléennes, additions,soustractions, multiplications et divisions sur 8 bits. A noter que l'ALU d'un 80C51 proposedes opérateurs logiques au niveau des bits.



Le diagramme cidessous représente l'architecture du CPU d'un 80C51 :

A chaque front montant de l'horloge système, cette machine d'état est active, il faut alors 12 périodesd'horloge pour réaliser un cycle machine complet. En outre, les instructions ne nécessitent pas toutes lemême nombre de cycles machines pour être exécutées, le temps passé dans chaque état n'est donc pas lemême.

2.3/ Contrôleur d'interruption (IC)

Il est en relation avec les deux périphériques principaux, les deux compteurs et l'interface série.Deux sources externes d'interruption, sur état logique ou sur front descendant, sont aussi disponibles, cequi porte à cinq le nombre de vecteurs d'interruptions. Outre les registres de configuration despériphériques, deux sont présent pour autoriser les interruptions (IE) et modifier leur niveau de priorité(IP).



Table des vecteurs d'interruptions :

Adresse du vecteur Source d'interruption Indicateur

0x0003 Externe 0 IE0

0x000B Timer 0 TF0

0x0013 Externe 1 IE1

0x001B Timer 1 TF1

0x0023 RxTx UART RI + TI

A chaque cycle machine, le contrôleur résout les interruptions en attente ainsi que leur priorité etprovoque un saut absolu au vecteur d'interruption correspondant au résultat de cette résolution. Lors dece saut, une sauvegarde de contexte est effectuée, la valeur du compteur ordinal est sauvegardée dans lapile et le pointeur de pile (SP) est incrémenté. La routine d'interruption est alors exécutée jusqu'àrencontrer l'instruction RETI, qui signifie retour d'interruption, le contexte précédent est ensuiterechargé depuis la pile.

Les indicateurs d'interruption sont échantillonnés durant chaque cycle machine, l'échantillon est alorsanalysé au cycle suivant. Si un des indicateurs est actif lors de cette échantillonnage, le systèmed'interruption génère l'appel au sousprogramme, cet appel est bloqué si l'une des conditions suivantesest détectée :

– Une interruption de même niveau de priorité ou de niveau supérieur est déjà en cours.– Le cycle machine correspondant à l'analyse n'est pas le dernier de l'instruction en cours

d'exécution.– L'instruction en cours d'exécution est un ordre de retour de sousprogramme (RETI) ou une

instruction correspondant à une écriture dans l'un des registres IE ou IP.

Cette dernière condition assure l'exécution d'une instruction après modification des registres définissantle mécanisme des interruptions et après le saut correspondant au retour de traitement de l'interruption.Si une interruption n'est pas prise en compte, alors l'indicateur est écrasé au cycle suivant par le nouveléchantillon.



Structure générale du contreur d'interruption du noyau 80C51 :

2.4/ Autres périphériques

Les trois blocs cidessus, la RAM, le CPU et l'IC, forment le microcontrôleur dans sa version laplus basique. En ajoutant de la ROM, le système peut alors fonctionner en autonomie cependant sonutilisation reste limitée à du calcul et des transferts mémoires. Comme vu plus haut, le 80C51 proposedes périphériques de bases :

– Compteurs 16 bits (TIMER) : comme tous les compteurs, ils peuvent fonctionner en mode :– Output Compare (temporisateur) : à chaque cycle machine, le registre interne est

incrémenté. Permet de générer de signaux de type PWM par exemple.– ou Input Capture (compteur) : A chaque front descendant du signal d'entrée, le

registre interne est incrémenté. Permet par exemple de mesurer le rapport cycliqued'un signal.

Il y a en réalité quatre modes fixés par le biais des bits M0 et M1du registre TMOD :– Mode 0 : Comparable aux compteurs de la famille MCS48. Il fonctionne en

compteur 8 bits et propose un prédiviseur de 0 à 32 (5 bits).– Mode 1 : Compteur sur 16 bits.– Mode 2 : Compteur sur 8 bits à rechargement automatique. Lorsque le compteur



déborde (passe de 0xFF à 0x00), il est automatiquement rechargé avec une valeur pardéfaut. Ceci permet de générer des temporisations très précise.

– Mode 3 : Le compteur 0 fonctionne en double compteur 8 bits, le premier est contrôlépar le registres du TIMER0 et le second par ceux du TIMER1.

– Ports d'entrées/sorties (IO) : Il y a quatre ports parallèles d'une largeur de 8 bits chacun. Ceslignes sont bidirectionnelles et fonctionnent en tout ou rien. Quatre registres internes P0 à P3permettent de lire/écrire l'état des ports.

– Interface série fullduplex : Elle permet d'émettre et de recevoir simultanément. Elle possèdequatre modes de fonctionnement et le taux de transfert est paramétrable par le TIMER1.

3/ Méthode de conception du simulateur

La présentation du fonctionnement du microcontrôleur 80C51 cidessus propose une premièrevision du simulateur. Il reprend globalement le fonctionnement décrit plus haut avec la différencenotable que le code simulé est directement le code assembleur écrit par le programmeur, et non le codemachine compilé et dont les liens sont édités.

Ceci pose le premier problème, doiton simuler du code de haut niveau ou du code machine ?Il n'y a pas de réponse juste, dans les deux cas un traitement préliminaire est nécessaire. Dans celui d'uncode de haut niveau, il faut nécessairement passer par une phase de précompilation. Par analogie, dansle cas d'un code machine, une phase de similidésassemblage est obligatoire. Ce qui revient donc aumême. Mon choix a été de prendre la solution du code de haut niveau, j'aurais très bien pu opter pourl'autre solution mais il fallait bien choisir. Par ailleurs, ce choix fixe l'architecture du simulateur, il estdonc primordial de se fixer sur une solution pour toute la suite du problème.

Au niveau de la hiérarchie on trouve le coeur (classes CORE_*) qui est totalement indépendant del'interface graphique. En théorie, il serait tout à fait possible de reprendre ce coeur tel quel et del'intégrer dans une autre application. Au dessus se trouve l'interface utilisateur, elle comporte une et uneseule instance du coeur.

J'ai commencé par concevoir un analyseur de code assembleur (Parser), il permet de récupérer chaqueinstruction contenue dans un fichier source sans tenir compte des différents commentaires et autreschoses qui sont susceptible d'être présent dans le fichier.A partir de ce Parser, j'ai pu commencer à réaliser le coeur du système en partant par le décodage desdifférentes instructions et modes d'adressages de base. Je me suis fortement inspiré de la machine d'étatvu précédemment en ajoutant quelques modifications au moment de l'implémentation.



Une base a vite été opérationnelle, à partir de ce moment j'ai pu facilement développer toutes lesinstructions et modes d'adressages.

J'ai ensuite commencé à réaliser une ébauche de l'interface graphique actuelle. En effet, auparavantj'utilisais un terminal pour la visualisation, le coeur commençant à être de plus en plus complet, ildevenait difficile de tout visualiser sur la console.Je me suis consacré enfin à la conception des différents périphériques internes et ainsi qu'auxcomposants graphiques.

Cidessous le diagramme des différentes classes JAVA qui forment le coeur, elles seront développéespar la suite :



3.1/ CORE_AsmLine & CORE_AsmParser : l'analyseur de syntaxe

La classe CORE_AsmLine représente une ligne de code assembleur. On distingue pour cettedernière trois types :

– OPCODE : c'est une instruction, elle possède des opérandes et une adresse dans la mémoireprogramme. Une instruction peut être sujette à un point d'arrêt.

– LABEL : c'est une étiquette, représente une adresse en mémoire programme.– DIRECTIVE : c'est une directive assembleur, utilisée uniquement par le logiciel qui

assemble le code source.

La classe CORE_AsmParser permet de récupérer chaque ligne de code à partir d'un fichier sourceprésent sur le disque dur de l'ordinateur. A chaque appel de la méthode « getAsmLine » le Parser renvoila ligne suivante contenue dans le fichier sous forme d'objet de type CORE_AsmLine. Le principe estde lire le fichier ligne par ligne, d'enlever les différents commentaires (symbolisés par un « ; ») et dedéterminer quel type de ligne vient d'être lu. Dans le cas d'une instruction, il faut ensuite récupérertoutes les opérandes.

3.2/ CORE_CPU8051 : le coeur du simulateur

Cette classe est en réalité le coeur de tout le programme. Elle fonctionne à partir d'un codesource généré par le Parser, un objet de type ArrayList contenant toutes les lignes de typeCORE_AsmLine est nécessaire. Comme on peut le voir sur le diagramme de classe, CORE_AsmParserne dépend par directement de CORE_CPU8051, c'est donc à la classe instanciant le CPU de faire appelau Parser pour générer l'ArrayList.A partir de cette ArrayList, une phase de similiassemblage est réalisée où toutes les directivesd'assemblages sont résolues et où les adresses sont calculées sauf celles des registres SFR. Par exemple,toutes les étiquettes sont résolues et affectées aux instructions de branchement, toutes les variablesutilisateurs de type « equ » sont remplacées par leur adresse respective.Ensuite, cette ArrayList est chargée dans la mémoire dite « virtuelle », d'une taille de 2^15 instructionsde type CORE_AsmLine, elle représente une mémoire simulée où toutes les instructions sont d'unelongueur de 1 CORE_AsmLine. On ne peut pas parler d'octets ici car on ne connaît pas la taille dechaque instruction puisqu'elle peut varier en fonction de son mode d'adressage (caractéristique desCISC).

Par ailleurs, la classe CORE_CPU8051 intègre des champs statiques qui sont les 256k octets demémoire de données (RAM) ainsi que la définition des différents registres SFR. Elle intègre aussi 64koctets de mémoire ROM utilisés pour l'instruction MOVC (voir CORE_HEXLoader) et 8k octets demémoire RAM externe.



La pièce maîtresse de cette classe est l'ordonanceur (Scheduler) qui reprend intimement celui d'un« vrai » 80C51 :

Le cycle commence par l'état « Update Timers », à chaque appel de la méthode « scheduleCPU » lecycle complet est effectué. Chaque instruction ne nécessite pas le même nombre de cycles machinepour être exécutée, or le cycle cidessus exécute toutes les instructions en une fois, il faut donc corrigerles compteurs du nombre de cycles réels moins un. Ce cycle pose un autre problème, dans le mêmeesprit, les interruptions ne sont pas échantillonnées aussi souvent qu'elles devraient l'être, il en résulteun comportement non déterministe. Un décalage sur l'exécution des routines d'interruptions peutintervenir mais il ne peut pas dépasser 3 cycles machines.

Le décodage de l'instruction se fait par l'intermédiaire d'un tableau associatif, de type Opcode,contenant une référence vers chaque classe Opcode... . Un autre tableau, contenant lui le nom (sousforme d'une chaîne de caractères) de toutes les instructions, permet de faire correspondre les index desdeux tableaux et donc d'appeler automatiquement la méthode « execute » de la bonne instruction parpolymorphisme. Il suffit juste de trouver le nom de l'instruction pour connaître l'index dans le tableau.



3.3/ Opcode & Opcode... : les instructions

La classe Opcode, déclarée comme étant abstraite, forme le squelette d'une implémentationstandard d'une instruction. Seule la méthode « execute » doit être redéfinie dans chaque classe héritantde Opcode, en l'occurrence toutes les instructions. Deux méthodes de type « protected » sontprésentent, l'une pour le décodage du mode d'adressage de chaque opérandes et l'autre pour effectuéesun saut relatif vers une adresse en mémoire programme.

La méthode « decodeAddressingMode » réalise une analyse syntaxique de l'opérande et en fonction dumode d'adressage elle retourne l'adresse dans la RAM.

– Immédiat : présence d'un « # » devant l'opérande. Une case mémoire à l'adresse 0x100, quin'est donc pas dans la plage d'adressage interne, contient la valeur à affecter. La méthoderetourne alors l'adresse 0x100.

– Indirect par registre : présence d'un « @ » devant l'opérande. Résolution de l'adresse duregistre via une table (Cf. resolveRegisterAddress).

– Par registre : L'opérande est le nom d'un registre. Résolution de l'adresse comme cidessus.– Au niveau du bit : Présence d'un « . » dans l'opérande (P0.1). Sauvegarde le bit pointé dans

une case mémoire à l'adresse 0x101 à l'instar de l'adressage immédiat et appellerécursivement la méthode « decodeAddressingMode ». Il s'agit ensuite, au moment del'exécution, de vérifier que la case 0x101 contient une valeur de 0 à 7 indiquant le rang dubit.

– Indexé : Présence d'un « + » dans l'opérande (REG+1). Ajoute le nombre à droite du « + » aurésultat de l'appel récursif de « decodeAddressingMode » pour la partie à gauche du « + ».

– Direct : C'est directement l'adresse écrite en base 10 ou 16.

Chaque classe représentant les instructions a été déclaré héritant de Opcode et la méthode « execute »surchargée par l'opération propre à l'instruction. Elles suivent toutes le même schéma :

– Décodage de toutes les opérandes.– Réalisation du travail du l'instruction.– Incrémentation du compteur de cycle machine suivant l'instruction.

3.4/ CORE_HEXLoader : le support de l'instruction MOVC

Puisque le simulateur exécute le code source assembleur à la volée, le code machine n'est pasdirectement accessible pour réaliser des transferts avec la ROM. L'instruction MOVC est d'ailleursfaites pour cela, elle permet de réaliser des transferts de le sens mémoire programme > mémoire dedonnées. Afin de supporter cette instruction, il faut pouvoir avoir le code machine, le fichierhexadécimal généré par un compilateur fait très bien l'affaire, c'est d'ailleurs celuilà même qui est



généralement chargé dans le circuit par l'intermédiaire d'un « Loader ». D'où le nom de cette classe quipermet de charger le code, lu à partir d'un fichier HEX, dans la mémoire de 64k octets décriteprécédemment.

La classe CORE_HEXLoader permet de charger un fichier source, au format INTEL 16 bit IHX,présent sur le disque dur. Le principe est très simple, chaque ligne du fichier commence par « : », ontrouve ensuite différents champs comme la taille des données contenues sur la ligne et les données àproprement parler. Un champs permettant de vérifier la validité des données est aussi présent. A laconstruction d'un objet de type CORE_HEXLoader, les lignes du fichier sont lues unes par unes et leCRC (Cyclic Redundancy Check) est vérifié. Si ce dernier est valide on écrit dans la mémoireprogramme.

3.5/ CORE_Timers & CORE_Interrupts : les périphériques

Le contrôleur d'interruption et les compteurs bénéficient de leurs propres classes.

Comme expliqué plus haut, à chaque appel de « scheduleCPU », les interruptions sont servis. Laméthode « checkPendingINT » vérifie les interruptions en attente, ensuite la méthode« interruptHandling » permet de servir l'interruption de plus haut niveau de priorité demandée.A noter que les interruptions imbriquées (Nested Interrupts) ne sont pas supportées.

Quand aux compteurs, la classe ne possède qu'une seule méthode « updateTimer » qui met à jour lesdeux compteurs l'un après l'autre. En fonction des bits de configuration contenus dans les registres descompteurs, le registre de comptage est incrémenté suivant le mode de fonctionnement sélectionné.A noter que le Mode 3 n'est pas supporté.

4/ Interface graphique utilisateur

L'interface utilisateur (GUI) se base sur cinq fenêtres par défaut, une console, un affichage ducode source, ainsi que des registres, de la mémoire de données interne et externe et enfin des portsd'entrées/sorties.

La classe principale est « Simulatro8051 », elle est la seule à comporter une méthode « main ». Héritantde la classe JFrame, elle forme l'application, toutes les autres fenêtres héritent de la classe JDialog. Elleimplémente également l'interface « Runnable » afin de créer un nouveau processus utilisé lorsque lesimulateur est en mode « Run » (Cf. 8051 Simulator v0.2 Documentation). A noter que l'instance duCORE est présente dans cette classe.



Cidessous le diagramme de classe de l'interface graphique :

L'interface graphique constitue un gros travail de recherche dans la documentation de l'API JAVA, iln'est pas très intéressant de la développer dans ce rapport. Quelques particularités sont quand même ànoter :

– Simulator8051 : Possède un Thread pour le mode Run, les différentes erreurs émisent par leCORE sont réceptionnées et affichées dans la console, le Thread est alors stoppé.

– GUI_SourceCodeDialog : Affiche le code source directement depuis le fichier et non pas lamémoire du CORE. On trouve dans cette classe les méthodes pour mettre/enlever les pointsd'arrêts dans la mémoire du coeur cette fois ci.

– GUI_DataMemoryDialog : Affiche le contenu de la mémoire par groupe de 8 octets, chaquegroupe se situe sur une ligne. Des méthodes sont prévues pour pouvoir modifier directementla mémoire du coeur (déclarée statique).



– GUI_SFRDialog : Se comporte exactement comme GUI_DataMemoryDialog en plussimple.

– GUI_IOPorts : Affiche l'état des ports d'entrées/sorties sous forme de JCheckBox. trèsbasique.

– GUI_7SegDisplay : Simule un afficheur 7 segments sur 4 bits. C'est le seul composant quifait intervenir du graphisme. Il est possible d'en ouvrir 4 au maximum, cette valeur estfacilement modifiable.

– GUI_UART : Simule un terminal UART. Son fonctionnement est très simple, il détecte leslecture/écriture sur le registre SBUF. Lorsque SBUF est écrit par programme, le terminalattrape la valeur et l'affiche dans la fenêtre. Par ailleurs, lorsque l'utilisateur envoi descaractères par le biais de cette même console, SBUF reçoit ces derniers.

La création de l'interface graphique est longue et fastidieuse, je vous invite à regarder la documentationJAVADOC pour de plus ample détails.

5/ Le projet avec un peu de recul

Ce premier projet de JAVA m'a permis d'apprendre beaucoup sur le langage, j'ai pu mettre àprofit mes acquis lors des différents travaux pratiques effectués. J'ai encore énormément de choses àapprendre mais je commence vraiment à me rendre compte de sa puissance et de ses défauts. Dansl'ensemble je retiens une facilité d'écriture et de debug du code ainsi que la puissance de laprogrammation orientée objet.

J'ai pu aussi travailler sur une nouvelle architecture qui m'était alors uniquement connue de nom. Eneffet, avant ce projet, je n'avais jamais travaillé sur un microcontrôleur 80C51, je n'ai heureusement paseu de problème pour la compréhension de son fonctionnement interne.

Ce qui m'amène aussi à noter que j'ai énormément utilisé mes connaissances en électronique numériqueet en langage C pour l'appréhension du sujet et tous les algorithmes spécifiques au coeur du simulateur.J'ai su tout de suite comment partir et je n'ai jamais été bloqué, je me suis posé beaucoup de questions.Je suis passé par des phases structurées de réflexions en posant les problèmes mais je n'ai jamais étévraiment en grande difficulté pour ce qui est de l'avancement.

J'ai beaucoup travaillé, non pas parce que le sujet été difficile mais parce qu'il est très vaste et devaittenir dans un laps de temps très court. Je n'est malheureusement pas pu faire tout ce que je m'étais fixé,le coeur n'est pas fonctionnel à cent pour cent à cause du nonsupport du Mode 3 des compteurs et desinterruptions imbriquées. D'autres composants graphiques auraient été également judicieux.



Dans l'ensemble, je suis très satisfais d'avoir eu à travailler sur ce sujet, je l'ai trouvé vraimentintéressant. Cette satisfaction est encore plus forte quand je m'aperçois que mon application est assezperformante dans cette version peu évoluée.

6/ Annexes

– Documentation utilisateur de la version 0.2 du logiciel 8051 Simulator. En anglais.


8051 Simulator v0.2 Documentation

This program is free software; you can redistribute it and/or modify it under the terms of the GNUGeneral Public License as published by the Free Software Foundation; either version 2 of the License, or

(at your option) any later version. This program is distributed in the hope that it will be useful, butWITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Youshould have received a copy of the GNU General Public License along with this program; if not, write to

the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 021111307 USA

The file COPYING contains the full text of the GNU General Public License, Version 2.

TABLE OF CONTENTS

● What is this ? ● How does it work ? ● What do i need to use it ? ● How to use it ? ● Assembly Source Code specifications ● HEX disassembler ● Windows OS specifications ● Linux OS specifications ● Links – Books ● Author

1/ What is this ?

8051 Simulator is an Intel 80C51 Core Simulator wrote in JAVA. It provides a complete emulated 80C51core with some restrictions such as the source code syntax. Above this core, there is a Graphical UserInterface which offers useful features as source code window, memory edit, step by step debug andgraphical components.Core supports :

● Complete 80C51 Instructions and Registers Sets● 256 bytes of Internal RAM● 8k bytes of External RAM● 64k bytes of ROM● Five Interrupts Fixed Vectors (Two external sources)● Two 16 bit Timers● Four Parallel IO● UART

2/ How does it work ?

8051 Simulator is able to simulate ASCII Assembly Source Code on the fly. It assembles the code into aspecific simulator understandable form where all the addresses are calculated but the mnemonics still inan ASCII format.

This sets the first restriction of this simulator, a fake program memory area is simulated where allinstructions (composed by a mnemonic and some operands) have a fixed length; 1 byte. The special ORGassembly directive (syntax .or) is provided to fix this restriction in order to set interrupt vectors orspecial routines.Because of the simulated program memory, the MOVC instruction needs the HEX assembled code, it isloaded automatically with the ASM file if it exists. In order to have the MOVC instruction supported youhave to assemble your source code with an Assembler as ASX8051. The simulator provides an internalHEX loader which understands INTEL IHX 16bit format.The internal core is based on a scheduler; each time the scheduler runs, the timers are updated, theinterrupts are resolved and serviced, the next instruction pointed by the Program Counter is fetched fromthe fake internal memory. This one is then decoded depending on its addressing mode and executed. Afterthat, the machine cycles counter is incremented by the corresponding number of cycles depending on theexecuted instruction. Since the 80C51 instructions do not need the same amount of machine cycles to beexecuted, the interrupt latency is not deterministic; nested interrupts are not supported either.

3/ What do I need to use it ?

Since it has been written using JAVA 1.4.2, you only need version 1.4.2 or above JVM. You can find oneat http://java.sun.com/The main class is Simulator8051.classSee compatibility sections (Linux/Windows) for more details depending on your operating system.

4/ How do I use it ?

The GUI is based on a master window which provides a Menu and a Console. Four other windows arelaunched by default :

● Source Code : Shows the assembly source code and the address of each instruction. It is possibleto easily set Breakpoints on instructions. The current value of the PC is shown by highlighting thecorresponding line.

● Data Memory : Shows the internal (top of the frame) and external (bottom) RAM. Values areeditable by doubleclicking on the cell. Numbers are in hexadecimal base.

● SFR : Shows the 80C51 Special Function Registers. As Data Memory window, values are editableand represented in HEX base.

● IO Ports : Shows/edits the state of the four general purpose I/O ports.

Two types of graphical components are also provided :● 7 Segments Display : Allows the user to easily configure a 7 segment display using a 4 bit bus

connected to general purpose I/O ports. Four displays maximum at the same time.● UART Terminal : Simulates the UART module, it logs characters received from the core and

transmits the userinput ones, as a simple RS232 terminal. Only one terminal is possible.

Since source code editing is not possible directly through the simulator window, there is a Reloadcommand to refresh the source code and reset the core.The Debug feature is composed of four types of commands :

● Reset : Resets the core registers by default.● Run : Puts the core in a free running mode. Only the Cycles Counter is still being updated, as the

graphical components. When a breakpoint or an error is caught, the core automatically returns toan idle mode, updating all of the graphical views.

● Break : Puts the core into an idle mode.

● Step : Executes an instruction and updates the GUI.In the case of a caught error, Run and Step commands are disabled, the core must be reset in order to reenable these commands.Errors are echoed in the Console, they usually append in the case of instruction fetch, instruction decodeor addressing mode errors.

5/ Assembly Source Code specifications

A LABEL MUST NOT BE ON THE SAME LINE AS AN INSTRUCTION.e.g. :

LABEL:MNEMONIC <operand1>, <operand2>, <operand3>

Numbers can be represented in Decimal or Hexadecimal Base, Binary Base is not supported. Two syntaxare possible for the Hex Base :

● Ox prefix : 10 > 0xA● h suffix : 10 > Ah

8051 Simulator can interpret three different Assembly directives :● EQU : Defines a user variable. Example : MY_VAR .eq 0x30● ORG : Sets the location of the next instruction into program memory. Example : .or 0x3● DB : Reserves space in RAM at the address contained in the above label. Example :

X0040:

.db 0xF ; reserve 15 bytes space @ 0x40

The label must be named as shown above : X<hex_address>

6/ HEX disassembler

There is a hex disassembler provided in the package called d52m.It is modified from http://home.pacbell.net/theposts/d52manual.html to meet 8051 Simulator Source Codespecifications.Modifications are :

● Assembly directives have now a fixed length about three characters.● There is a dot before each assembly directive.● Instructions can not be on the same line as a label.

Sample bash script to produce assembly and hex files from a C program (with d52m executable file in thesame directory) :

#!/bin/shif [ n "$1" ]thenfile=$1elseecho "No source code"exitfiif [ n "$2" ]thenout=$2elseout="out.asm"

fiecho "SDCC Compilation"sdcc $filerm *.lnk *.lst *.map *.mem *.rel *.rst *.sym *.asmmv *.ihx out.hexecho "Disassemble Binary File"./d52m outmv out.hex $out.hexmv out.d52 $out

7/ Windows OS specifications

To run 8051 Simulator, launch the script Simulator8051.bat.You have to add to your environment variable the J2RE binaries path in order to get the JAVA command.

8/ Linux OS specifications

To run 8051 Simulator, launch the bash script Simulator8051.There is a way to simulate C source code using SDCC compiler. It generates IHX code, which can bedisassembled with d52m. Pay attention to the corresponding script to see how to use SDCC.

9/ Links Books

● JAVA : http://java.sun.com/● SDCC : http://sdcc.sourceforge.net/● D52 : http://www.8052.com/users/disasm/● 80C51 documentations : http://www.pjrc.com/tech/8051/datasheets.html

Bernard ODANMicrocontrôleurs 8051 et 8052, description et mise en oeuvre,Editions DUNOD, ISBN 2100017640

10/ Author

My name is Matthieu SIMON, 23 years old, I am a French undergraduate engineer of “Université Pierre& Marie CURIE” (Paris – France). This 8051 simulator is part of a school project I did. Although thereare already a lot of 80C51 simulators, this JAVA one can interest some people, which is why I released iton General Public License.Please, feel free to contact me : [email protected] questions or feedback is welcomed.

Powered By IFITEP – July 2005

Documents

Rapport de projet de JAVAdonpichol.free.fr/IFITEP/JAVA/Simulator8051.pdf · Matthieu SIMON 8051 Simulator v0.2 Structure générale du contreur d'interruption du noyau 80C51 : 2.4