D.IZQUIERDO - Stage ERASMUS
INTRODUCTION *
PRÉSENTATION DE L’ENSEIRB. *
OBJECTIFS ET SUJET DU STAGE. *
DESCRIPTION DE L’ENVIRONNEMENT MATERIELLE. *
DEVELOPPEMENT DU STAGE. *
1.-MICROCONTRÔLEUR DE MOTOROLA 68HC11. *
Qu’est ce que le Microcontrolatuer Motorola 68HC11? *
MIS AU POINT AVEC LE 68HC11. *
PCBUG11. *
BUFFALO. *
EXÉCUTION DES PROGRAMMES. *
2.-LA MACHINE VIRTUELLE. *
EN QUOI CELA CONSISTE? *
1.- Analyse des requises fonctionnelles. *
2.- Codification de l’application en Java. *
3.- Processus d’optimisation des classes Java. *
4.- Code des méthodes natives. *
5.- Vérification du logiciel. *
L’AIDE DES THREADS. *
1.- En étendant la classe Thread. *
2.- En mettant en oeuvre l’interface Runnable. *
MÉTHODES NATIVES. *
1.-Déclaration des méthodes natives dans la classe d’application. *
2.-Méthodes natives en assembleur. *
3.-Ecriture de méthodes natives en C. *
4.-Limitations des méthodes natives. *
PROBLÈMES RENCONTRÉS AVEC LES MÉTHODES NATIVES. *
PAQUETAGES. *
JAVA.LANG PAQUETAGE.- *
HW.MOT68HC11 PAQUETAGE.- *
RESUME DE LA MACHINE VIRTUELLE. *
LIMITATIONS. *
3.-LA COMMUNICATION API DE JAVA. *
L’OBJECTIF ET LA FIN DU PROJET. *
CONCLUSIONS *
Mots Clés :
Microcontrôleur, Assembleur, Machine virtuelle JAVA, méthodes natives, Threads, API, Client/Serveur.
Travail effectué :
Réalisation d’une application en Java pour tester la machine virtuelle JAVA dans le microcontrôleur Motorola 68HC11 et réalisation d’une application pour pouvoir contrôler la carte microcontrôleur via le port série avec une serveur Web.
Je remercie l’ENSEIRB où j’ai pu effectuer mon stage et plus particulièrement:
Je suis un étudiant ERASMUS venant d’Espagne, de l’Université de Saragosse. J’ai eu la possibilité de faire ma dernière année de mes études d’Ingénierie de Télécommunications dans le cadre ERASMUS à l’ENSEIRB.
Mon stage a débuté le 6 septembre et s’est terminé le 30 novembre 1998 au sein de l’ENSEIRB, dans le laboratoire de Traitement de Signal et Télécommunications (Salle S016).
Le but de ce stage a été l’implémentation de la machine virtuelle de Java dans le microcontrôleur Motorola 68HC11. De cette façon nous pouvons à partir d’un ordinateur quelconque (par exemple un PC que nous avons dans notre bureau et que nous avons connecté à Internet) se connecter à un Serveur Web qui pilote la carte 68HC11 et exécuter des commandes que nous voulons (par exemple prendre la température d’un capteur).
L’objectif de ce rapport est de retracer fidèlement le déroulement de ce stage en présentant et en expliquant le sujet en lui-même, puis en présentant les outils utilisés et testés et enfin, en décrivant l’application de la machine virtuelle utilisée. Avant cela, il est nécessaire de présenter rapidement le lieu du stage.
Comme tout le monde sait, l’ENSEIRB (ÉCOLE NATIONALE d’INGÉNIERIE SUPERIEURE d’ELECTRONIQUE et RADIOELECTRICITÉ de BORDEAUX) est une école d’ingénieurs qui se spécialisent dans l’électronique ou dans l’informatique. Actuellement ces deux types de spécialités sont très recherchés grâce à l’essor des télécommunications (par exemple les mobiles, la télévision numérique, les réseaux, ... ).
Cela fait que l’ENSEIRB est une école orienté vers le futur.
En plus, la disponibilité des moyens et la facilité d’accès à tous ces moyens font de cette école un centre dans lequel l’investigation et le développement de projets sont des valeurs en hausse.
Ce stage consiste à l’implémentation d’une machine virtuelle Java dans le microcontrôleur 68HC11 de Motorola. De cette façon, nous avons fait un programme en Java que nous avons introduit dans le microcontrôleur grâce à la machine virtuelle. Avec ce programme, nous voulons qu’au moment de donner une commande au microcontrôleur via le port RS-232 de notre ordinateur (via le port série) on exécute ce que nous avons prévu dans le programme Java. Un exemple d’utilisation est de connecter la carte microcontrôleur Motorola à un capteur de température qui nous mesure tout le temps la température, de telle sorte qu’au moment d’écrire dans l’écran de l’ordinateur le suivant instruction : "lis", le microcontrôleur comprenne grâce au programme que nous avons mis en oeuvre dans lui, qu’il doit lire la température que le capteur va lui donner et la retourner vers le port série.
Mais nous avons fait toujours un pas en plus dans la réalisation de ce projet, puisque l’objectif attendu a été de connecter la carte à un Serveur Web (un ordinateur qui est connecté à un réseau, comme par exemple Internet, qui est le plus répandu, pour donner quelque service) on peut avoir accès à la carte dans quelconque "client" (un ordinateur qui utilise les services donnés par le Serveur) dans n’importe où, rien qu’en ayant une connexion à Internet.
Pour que la communication entre le Serveur et la carte soit possible, nous avons utilisé la "communication API" de Java, de sorte que nous contrôlons parfaitement le port RS-232 de notre Serveur qui communique avec la carte (pour l’envoi des commandes et la réception des résultats qui doivent s’imprimer dans l’écran du navigateur Web)
DESCRIPTION DE L’ENVIRONNEMENT MATERIELLE.
Ce stage a été réalisé pour l’ENSEIRB. Le lieu du travail se situe dans le laboratoire du traitement du signal et télécommunications de l’ENSEIRB, dans le pôle Electronique.
Le stage a consisté à programmer en Java, mais aussi en assembleur (assembleur du Motorola 68HC11) et en langage C.
Pendant le stage on a travaillé avec des différents logiciels :
L’équipement avec lequel s’est fait tout le stage a été :
1.-MICROCONTRÔLEUR DE MOTOROLA 68HC11.
Qu’est ce que le Microcontrolatuer Motorola 68HC11?
Le microcontrôleur 68HC11 de Motorola est un microcontrôleur de 8 bits, cela semble vraiment moins puissant et dépassé par rapport aux processeurs 32 et maintenant 64 bits. Mais il trouve largement sa place dans des applications de la vie quotidienne où l’on n’a pas besoin de "MIPS" et de "MFLOPS" : micro-onde, lave vaisselle, TV, domotique..., alors leur étude est toujours d’actualité.
Un microcontrôleur est simplement un microprocesseur. Un programmeur réalise un programme qu’on mette en oeuvre dans le micro, de forme que celui-ci (le programme) quand on s’exécute, on obtient une séquence de sortie qu’on aide à porter une série d’actions simples qu’en même temps on sert d’entrée au microcontrôleur pour continuer à exécuter le programme. Et ainsi de suite.
Dans la figure adjointe on peut voir comme est le structure du microcontrôleur de Motorola 68HC11.
On peut souligner les éléments suivants :
Les modes du fonctionnement du 68HC11 sont résumés dans le tableau suivant :
La cartographie mémoire (mapping mémoire) du microcontrôleur 68HC11 est la suivante :
Dans notre projet, le 68HC11 a été utilisé de deux manières différentes :
Nous allons voir un peu plus en détail comment fonctionnent ces deux logiciels.
Les autres deux formes de travail du microcontrôleur (special test et single chip) n’ont pas été utilisées pendant le stage puisqu’ils correspondent à deux formes de travail spéciaux, donc nous n’avons pas eu besoin.
Une fois avoir présenté la carte mère du 68HC11, nous allons présenter la façon de l’utiliser.Pour tout cela, nous avons fait les huit TP qu’on nous a proposé au début du stage (nous pouvons voir à ensuite un exemple d’un programme développé en assembleur). On nous indiquait l’utilisation du PCBUG11 et du moniteur Buffalo
*******************************************************************
* Programme de test d'entrée-sortie sur carte d'affichage 68HC11 *
* Configuration de la carte : *
* - PORTE : 8 bits en entées *
* - PORTA : entées = PA0, PA1, PA2 *
* sorties = PA3, PA4, PA5, PA6, PA7 *
******************************************************************* DEBRAM EQU $0000
DEBPROG EQU $B600
PORTA EQU $1000
PORTE EQU $100A
ORG DEBPROG
LDS #$FF * initialisation de la pile
START
LDX PORTA * selon l'état de PA0, on fait :
BRCLR 0,X, #%00000001,chenill * PA0=0 -> chenillard 5leds
recopi
LDAA PORTE * PA0=1 -> recopie des 5bits de poids fort
STAA PORTA * du PORTE sur PORTA
BRA START
chenill
LDAA #8 * routine chenillard AR
GCHE STAA PORTA * allume la LED PA3
JSR TEMPO * routine de temporisation
ROLA * rotation vers la gauche d'1 bit
CMPA #128 * on regarde si on est arrive à PA7
BNE GCHE * si non on reboucle
LDAA #128 * allume la LED PA7
DRTE STAA PORTA
JSR TEMPO * routine de temporisation
RORA
CMPA #8 * on regarde si on est arrive à PA3
BNE DRTE
BRA START * on a termine un cycle AR
TEMPO
LDY #100000 * tempo de xx µs
DEY
CPY #0
BNE TEMPO
RTS
END
Nous allons voir un peu plus en détail comme ces deux logiciels peuvent travailler :
PCBUG11 est un logiciel qui permet de télécharger et débugger des programmes que l’utilisateur désire faire exécuter par le 68HC11. Mais comment procède-t-on pour télécharger son programme dans la mémoire du 68HC11?
Lors de l’écriture d’un programme en assembleur 68HC11, une directive d’assemblage (ORG + adresse en hexadécimale) permet de définir l’adresse de base du programme dans la mémoire. Il faut donc placer le programme dans une zone libre et inscriptible. Par exemple la RAM (interne ou externe) ou l’EEPROM interne.
Un moniteur est un programme beaucoup plus gros (8 Ko. environ) que l’on programme dans une EPROM externe. Les avantages sont multiples puisque le moniteur occupe très peu de RAM (uniquement pour quelques variables). Dans la figure suivante nous pouvons voir la cartographie mémoire avec le moniteur BUFFALO :
Il permet de débugger le programme utilisateur grâce à des commandes intégrées et le moniteur dialogue avec l’utilisateur par l’intermédiaire d’un simple terminal (que dans notre cas va être l’émulateur Hyperterminal de Windows).
L’exécution du moniteur se fait lors du Reset en mode étendu et rend libre l’utilisation du port série après le lancement du programme utilisateur. Ici nous pouvons voir comme est la présentation du logiciel en cours d’utilisation :
Pour cela, nous devions créer des programmes en assembleur (avec l’extension .ASC) ou en langage c (avec l’extension .C), qu’ils correspondant au code source du programme. L’utilisation d’un langage dépendait de l’utilisation de la carte. Dans le cas du langage C, nous utilisons des fonctions déjà définies dans une librairie (LIBHC11) qui contrôlait les entrées/sorties en même temps que la gestion de la liaison série.
Une fois que ces deux programmes sont créés, on peut les assembler (dans le cas d’utilisation de langage assembleur), ou on peut les compiler et linker. Et pour les deux, on doit créer à la fin, des fichiers Srecord (avec l’extension .S19) qui sont des fichiers qui sont chargés dans la carte du 68HC11.
Une fois que nous avons chargé ces fichiers, nous les exécutons et les déverminons (débugger) jusqu’à obtenir les résultats que nous cherchions.
La machine virtuelle de Java pour le 68HC11 est un logiciel qui nous permet mettre en oeuvre le langage Java dans le microcontrôleur. C’est un programme qui va faire les fonctions de traducteur et qui va traduire les programmes en Java que l’usager a définis, dans un code que le micro 68HC11 peut comprendre. Ce qu’on fait avec le développement de la machine virtuelle de Java est mis en oeuvre au maximum le langage Java dans les possibilités du microcontrôleur. Malheureusement, pas tous les paramètres, ni toutes les classes avec les que nous pouvons être habitués à travailler en Java ne peuvent être mis en oeuvre puisque le micro 68HC11 dispose de ressources limités comparés par exemple à ceux d’un PC.
Il faut tenir en compte, en plus, des limitations qui simplifient la mis en oeuvre de la machine virtuelle:
Avec tous ces éclaircissements ici exposés, un programmeur d’applications en Java pour tous ces petits systèmes d’intégrés doit réaliser un code en tenant compte toutes les limitations de la machine virtuelle. Tout ce qui peut marcher sur un PC ne peut pas marcher dans le système d’intégrés. On peut le faire mais de manière très pauvre.
Le développement d’une application Java pour un système d’intégrés dans lequel le Motorola 68HC11 soit contenu peut être divisé suivant les points suivants:
1.- Analyse des requises fonctionnelles.
Normalement le développement commence avec une analyse des contraintes fonctionnelles. Dans cette analyse le programmeur/développeur doit décider entre autres choses quels composants software doit mettre en oeuvre en Java et quels doivent être programmés comme les méthodes natives. C’est évident que les actions qui sont critiques dans le temps ou qui demandent l’accès au hardware de la carte mère devraient être mis en oeuvre avec des méthodes natives (nous verrons un peu plus tard que ces méthodes peuvent être écrites en assembleur 68HC11 ou en langage C).
2.- Codification de l’application en Java.
Une fois que l’analyse est complète, nous passons à la codification (écriture) de l’application java.
L’unique limitation est que le programmeur/développeur doit garder en tête que le software va s’exécuter dans un système d’intégrés de 8 bits, et une mémoire heap très limitée. C’est aussi pour ça que le nombre des classes de la librairie est limité. Pour le moment, la librairie inclut des classes dans les paquetages java.lang et hw.mot68hc11.
Le programmeur devra prendre l’option de créer des "threads" dans l’application, de sorte que chaque thread réalise une tâche isolée. De cette façon, quand un thread est en train d’attendre qu’une condition soit vraie, on appelle la méthode yield( ) de sorte qu’autre thread puisse suivre à s’exécuter. De cette façon, nous améliorons beaucoup le rendement de notre système.
Les programmes d’application peuvent être écrits et compilés avec les beaucoup outils qui ont été créés pour cela. Nous avons pris dans notre stage le SUN’s JDK.
3.- Processus d’optimisation des classes Java.
Le processus d’optimisation se mène à bien avec l’outil ClassLinker et implique une lecture de toutes les classes que comprend l’application, en remplaçant les références symboliques aux objets et indices et en engendrant les fichiers de sortie. Résoudre les références symboliques simplifiera l’architecture d’exécution dans le temps de la machine virtuelle de Java, et c’est qui est le plus important, une amélioration significative du temps d’exécution du code java.
Un des fichiers de sortie créé pour l’outil ClassLinker est une "image d’application" qu’après sera chargé (avec la machine virtuelle de java et les méthodes natives) dans la mémoire du dispositif. Dépendant de l’architecture hardware, le processus de chargement peut être le chargement du programme en mode bootstrap ou la programmation dans l’EPROM.
Un autre fichier important généré pour le ClassLinker est le fichier de la table des méthodes natives (avec la liste de méthodes natives). Ses nom et position sont spécifiés dans le fichier de l’application de contrôle. Deux fichiers sont générés: la version en langage C et la version en assembleur. Le fichier de la table des méthodes natives fait la liste de toutes les méthodes natives que l’application Java référence. Les méthodes natives qui sont définies déjà dans le paquetage java.lang sont exclues et sont mis en oeuvre pour la propre machine virtuelle de java.
4.- Code des méthodes natives.
La plupart de fois, les méthodes natives proportionnent accès aux périphériques hardware qui sont trouvés dans un certain système d’intégrés.
Le code des méthodes natives supporte l’écriture de sousroutines, la plupart d’elles en assembleur. Le ClassLinker engendre le fichier de la table des méthodes natives en enregistrant toutes les méthodes dont l’application a besoin. Le nom de la méthode native doit se trouver avec le nom spécifié dans ce fichier de liste/table.
Toutes les personnes qui développent une application ne doivent jamais changer l’ordre dans la liste des méthodes natives puisque ce fichier fait partie du processus de construction du code natif.
Beaucoup de composants d’une application Java peuvent être testés a priori en chargeant une image finale dans la mémoire du dispositif.Le comportement de beaucoup de méthodes natives peut être simulé par logiciel. Ces techniques permettent au développeur du software de tester et débugger une application avec les outils de développement Java comme par exemple le JDK (dans notre cas). En étant capable de vérifier la plupart des fonctionnalités de l’application que l’on appelle temps de code (temps que coûte le développement de la part du code pour qu’il marche correctement) réduira surtout le temps de développement.
Tester les composants software qui ont besoin d’une interaction hardware est quelquefois plus compliqué. Le mode dans lequel le test se mene à bien dépend de la configuration hardware du dispositif.
Le schéma
des étages qu’on doit suivre est le suivant.
Les threads de Java sont un moyen idéal pour exécuter plusieurs tâches indépendantes de façon concurrente. La façon de mettre en oeuvre ces threads dépend de la plate-forme hardware sur laquelle s’exécute la machine virtuelle Java.
Le mode naturel de mise en oeuvre les threads pour un système d’intégrés fondé sur le 68HC11 est d’utiliser les interruptions temps réel. Le temporisateur temps réel peut être configuré pour générer des interruptions par intervalles de 8 à 32 ms, ce qui est dans la plus part des cas suffisant pour mettre en oeuvre la commutation de threads "répartis dans le temps" et avec priorité.
Tous les threads sont créés comme "non-daemon threads", ce qui signifie que la machine virtuelle Java finira l’exécution du code seulement si tous les threads sont sortis de la méthode run( ).
Dans cette mise en oeuvre de la machine virtuelle Java, tous les threads ont la même priorité. Quand un thread n’a rien à faire, il devra appeler régulièrement au méthode yield( ) pour lancer la commutation de threads et ainsi permettre aux autres threads pouvoir s’exécuter plus fréquemment.
Il y a deux façons pour un programmeur de créer les threads:
1.- En étendant la classe Thread.
Les sousclasses de la classe Thread doivent ignorer la méthode run( ). Par exemple:
class CommThread extends Thread
{
int baudRate;
CommThread(int baudRate)
{
this.baudRate = baudRate;
}
public void run()
{
while (true)
{
// wait for data
if (charIn())
{
// process data
}
else
{
// nothing to do - force thread switching
yield();
}
}
}
private native boolean charIn();
}
2.- En mettant en oeuvre l’interface Runnable.
Les classes qui mettent en oeuvre l’interface Runnable doivent mettre en oeuvre aussi la méthode run( ). Le même exemple peut être écrit comme suivant:
class CommRun implements Runnable
{
int baudRate;
CommRun(int baudRate)
{
this.baudRate = baudRate;
}
public void run()
{
// La même chose que dans l’exemple en haut.
. . .
}
private native boolean charIn();
}
Pour maintenir une taille compacte de la machine virtuelle Java, on a pris quelques limitations:
On espère que les futures versions de la machine virtuelle de Java éliminent toutes les limitations qui sont mentionnées en haut.
Les méthodes natives sont une part importante de l’application java. Les méthodes natives permettent au développeur du software de mettre en oeuvre les sections de temps critique du code sous forme native (on soit bien en langage assembleur du 68HC11 ou C) et pourvoir un accès aux composants hardware présents dans le dispositif.La machine virtuelle Java met en oeuvre un schéma d’invocation des méthodes natives qui est rapide et n’utilise pas beaucoup de sources système.
1.-Déclaration des méthodes natives dans la classe d’application.
Dans l’exemple suivant, la méthode native charIn( ) a été déclarée. Cette méthode teste l’état du buffer de réception et elle rend vrai si le buffer contient un caractère à lire:
package hw.io;
class Comm implements Runnable
{
public void run()
{
while (true)
{
// wait for data
if (charIn())
{
// process data
}
else
{
// nothing to do - force thread switching
yield();
}
}
}
private native boolean charIn();
}
2.-Méthodes natives en assembleur.
Il faut suivre les étapes suivantes:
ARG2 equ 2 location of the 2nd argument on stack
LO equ 2 position of low word in 32 bit operand
HI equ 0 position of high word in 32 bit operand
**************************************************************
* Checks if there are any characters in the receive buffer.
* Java prototype: boolean charIn();
* Input: ARG1 (D) - pointer to native methods arguments
* ARG2 (SP+2) - pointer to 32-bit return value
**************************************************************
hw_io_Comm_charIn:
tsx retrieve ptr. to return value
ldx ARG2,x
clra set default response as false
clrb
std HI,x
std LO,x
ldd rx_len check the receive buffer length
beq _ret
ldd #1 set response to true
std LO,x
_ret
rts
L’ordre des noms dans la liste du fichier de la table des méthodes natives est très important et personne doit le changer.
3.-Ecriture de méthodes natives en C.
Le prototype de fonction C pour une méthode native est :
Void aNativeMéthode (long natParams[], long *returnVal);
Où:
Les méthodes natives ne doivent pas retourner directement une valeur.
Alors, la méthode charIn( ) serai en C:
#define TRUE 1
#define FALSE 0
void hw_io_Comm_charIn(long natParams[], long *returnVal)
{
*returnVal = (rx_len == 0) ? FALSE : TRUE;
}
4.-Limitations des méthodes natives.
PROBLÈMES RENCONTRÉS AVEC LES MÉTHODES NATIVES.
Pour mettre en oeuvre les méthodes natives en C sous la forme que l’on m’avait proposée, nous avions traduit en langage C toutes les méthodes natives que nous avons besoin pour développer le projet, mais au moment de les compiler et ainsi obtenir les fichiers de sortie .S19 et la table de méthodes, nous avions une erreur dans la version du logiciel. Alors, nous avons envoyé un mail au département de SUN qui est responsable de la machine virtuelle Java, pour exposer le problème que nous avions détecté dans sa version.
À cause de ce problème, nous ne pouvions pas exécuter les méthodes natives en C, qui est un langage plus facile à comprendre que le langage assembleur. Voici des méthodes natives que nous avions réecrites en C :
#include <stdio.h>
#include "libhc11.h"
#define TRUE 1
#define FALSE 0
/* programme principal*/
void CommThread_byteReceived (long natParams[], long *returnVal) {
char c;
*returnVal = (read_com(&c)==0)?FALSE:TRUE;
}
void CommThread_getByte (long natParams[], long *returnVal) {
char c;
if (read_com(&c)) {
*returnVal =c ;
}
}
void CommThread_putByte (long natParams[], long *returnVal) {
char c;
c=natParams[0];
write_com(c);
*returnVal = TRUE;
}
void CommThread_setBaudRate(long natParams[], long *returnVal) {
int i;
i=natParams[0];
baudrate(i);
}
À cause de la limitation de mémoire, seulement a été mise en oeuvre une part de la fonctionnalité du paquetage java.lang. Les classes et méthodes qui n’étaient pas remarquables pour le 68HC11 ont été supprimées.
Le programmeur doit tenir compte que l’application Java est compilée avec les classes java.lang qui sont incluses avec la machine virtuelle de Java pour le 68HC11. Ceci est fait, en ajoutant la variable d’environnement Classpath ou en spécifiant le classpath comme argument dans la ligne de commande.
Le paquetage hardware pour le 68HC11 propose une collection de méthodes basiques pour l’accès mémoire et aux registres hardware du micro 68HC11. La classe additionnelle "Timer" propose des opérations simples de "timing" (temporisation) qui peuvent être utilisées avec l’application.
RESUME DE LA MACHINE VIRTUELLE.
3.-LA COMMUNICATION API COMMAPI DE SUN.
L’API (Application Programming Interface) de Java est une interface pour programmer des applications. Mais, qu’est ce que cela signifie? La communication API de Java peut être utilisée pour écrire des applications de communications plates-formes indépendantes, tel que le courrier de voix, fax,...La version de la communication API de Java avec laquelle nous avons travaillé renferme un support pour le port série RS-232 et les ports parallèles IEEE-1284. Avec la fonctionnalité actuelle, on peut:
Avec cette interface nous avons contrôlé le port série RS-232 de l’ordinateur (PC) avec lequel la carte mère qui contient le micro 68HC11 était connecté. De cette façon, nous configurions tous les paramètres du port, tels que la vitesse (en b/s), bits de parité, bits d’arrêt, et des autres caractéristiques qui sont nécessaires pour une parfaite communication entre les deux dispositifs. De plus, nous utilisions l’API pour pouvoir visualiser quelconque évènement qui puisse succéder dans le port en cours d’exécution du programme, par exemple l’envoi et re-envoi (ping-pong) de caractères ou au moment d’envoyer une commande que doit exécuter le micro 68HC11.
Pour pouvoir développer tout ceci, nous nous sommes basés sur les exemples d’applications qui étaient dans la version 2.0 de la Comm API.
L’OBJECTIF ET LA FIN DU PROJET.
Une fois que nous nous étions familiarisé avec le microcontrôleur et avec tous les composants de la carte mère, ça veut dire, avec toutes les différentes mémoires qu’il y avait (ROM et RAM, externes et internes), l’échange de données entre les ports et le micro et l’interface entre l’usager et la carte (comment on peut dialoguer) et que nous avions fait les 8 TP proposés et après nous avions fait des autres programmes avec la collaboration d’un ami, qui était en train de faire un DRT et qui était en train de travailler aussi avec le Motorola 68HC11, pour bien comprendre tout le fonctionnement, nous passions à étudier le langage Java. Java a été le support principal avec la machine virtuelle pour le développement du projet. Nous avons fait des programmes en Java jusqu’à la totale compréhension du langage.Après, nous commençons à comprendre le fonctionnement de la machine virtuelle de Java, avec toutes ses limitations, qui ont été un vrai problème à l’heure de développer les applications en Java, parce que nous ne devions pas penser seulement au langage Java, mais nous le devions faire en considérant les limitations que nous.
Au moment où tout ça a été bien compris, nous avons commencé à voir la communication API de Java. Nous avons vu comment elle travaille avec le port de communication série RS-232, et nous avons utilisé ce logiciel pour pouvoir contrôler le port qui servait de liaison entre l’ordinateur (notre poste de travail PC) et la carte mère avec le micro de Motorola.
Une fois que nous avions étudié et bien compris tous ces logiciels, langages et les différentes formes d’opérer avec la carte, nous avons développé les applications qui avaient été établies comme objectif de ce projet. À la fin, les résultats du stage sont ces deux programmes en Java:
import java.lang.*;
import hw.mot68hc11.*;
class tst
{
static void main()
{
// create instance of communication thread and start it
CommThread comm = new CommThread();
// an attempt to initialize the communication port
try
{
comm.initComm(9600);
}
catch (Exception excep)
{
// fatal error - stop the application running
return;
}
// transmit a welcome message
comm.send("\r\nHello World !!! ");
// now, start the communication thread running
comm.start();
// Exiting the main() will not stop your application running.
// ExampleApp will stop running if also all exit their
// run() method.
}
}
/**
* Communication thread that echoes incoming characters.
* If a Carriage Return (0x0D) is received it transmits also
* Line Feed (0x0A) character.
*
* CommInitException exception is thrown on incorrect initialization
* parameters.
*/
class CommThread extends Thread
{
// static initialization of exception objects
private static String strExcep = "Wrong baud rate";
private boolean initialised = false;
int i;
/**
* Method will first check if the correct baud rate has been
* specified, then it calls native method that performs low
* level initialization.
*
* @param Baud Baudrate for the communication port.
* @exception CommInitException is thrown when incorrect
* baud rate was specified.
*/
void initComm(int Baud) throws Exception
{
if (Baud != 9600)
{
throw new Exception();
}
setBaudRate(Baud);
initialised = true;
}
/**
* This method is started when a new instance of CommThread is
* created. Method will in the infinite loop echo characters that
* were received via SCI port.
*/
public void run()
{
// do not start thread running until intialisation
// is done by the initComm() method;
while (!initialised) ;
byte comando[] = new byte[5];
byte cadena[] = new byte[100];
String mot = "write";
String apag = "erase";
int i = 0;
int encender = 1;
int apagar = 1;
int resultado=0;
String s=new String("");
send("\r\nWrite whatever you want: ");
CPU led = new CPU(0x1000);
led.writeRegByte(0x26,0x80);
while (true)
{
while (byteReceived())
{
// read the received character
byte ch = getByte();
// echo the received character
putByte(ch);
if (ch==0x0D)
{
i=0;
encender=1;
apagar=0;
while ((encender==1) && (i<5))
{
if (cadena[i]==mot.charAt(i))
{
i++;
}
else encender=0;
}
i=0;
if (encender==0)
{
apagar=1;
while ((apagar==1) && (i<5))
{
if (cadena[i]==apag.charAt(i))
{
i++;
}
else apagar=0;
}
}
send("\r\nNew Line: ");
if ((encender==1) && (cadena[5]==' '))
{
for(i=6; i<8; i++)
{
switch (cadena[i])
{
case '0':
{
if (i==6)
resultado=0;
else
resultado=resultado+0;
break;
}
case '1':
{
if (i==6)
resultado=16;
else
resultado=resultado+1;
break;
}
case '2':
{
if (i==6)
resultado=16*2;
else
resultado=resultado+2;
break;
}
case '3':
{
if (i==6)
resultado=16*3;
else
resultado=resultado+3;
break;
}
case '4':
{
if (i==6)
resultado=16*4;
else
resultado=resultado+4;
break;
}
case '5':
{
if (i==6)
resultado=16*5;
else
resultado=resultado+5;
break;
}
case '6':
{
if (i==6)
resultado=16*6;
else
resultado=resultado+6;
break;
}
case '7':
{
if (i==6)
resultado=16*7;
else
resultado=resultado+7;
break;
}
case '8':
{
if (i==6)
resultado=16*8;
else
resultado=resultado+8;
break;
}
case '9':
{
if (i==6)
resultado=16*9;
else
resultado=resultado+9;
break;
}
case 'A':
{
if (i==6)
resultado=16*10;
else
resultado=resultado+10;
break;
}
case 'B':
{
if (i==6)
resultado=16*11;
else
resultado=resultado+11;
break;
}
case 'C':
{
if (i==6)
resultado=16*12;
else
resultado=resultado+12;
break;
}
case 'D':
{
if (i==6)
resultado=16*13;
else
resultado=resultado+13;
break;
}
case 'E':
{
if (i==6)
resultado=16*14;
else
resultado=resultado+14;
break;
}
case 'F':
{
if (i==6)
resultado=16*15;
else
resultado=resultado+15;
break;
}
}
}
}
if (encender==1)
{
led.writeRegByte(0, resultado);
encender=1;
apagar=1;
}
else if (apagar==1)
{
led.writeRegByte(0, 0x00);
apagar=1;
encender=1;
}
i=0;
}
else
{
cadena[i]=ch;
i++;
}
if (ch=='\010')
{
i=i-2;
}
}
}
}
/**
* Writes a string message to COM port.
*
* @param Msg message that will be transmitted
* @return true if message has been put into the transmit buffer,
* otherwise false is returned
*/
boolean send(String Msg)
{
if (Msg == null || Msg.length() == 0)
return false;
for (int i=0; i < Msg.length(); i++)
{
if (putByte((byte)Msg.charAt(i)) == false)
return false;
}
return true;
}
/**
* Writes a character array to COM port.
*
* @param Msg Reference to character array
* @return true if message has been put into the transmit buffer,
* otherwise false is returned
*/
boolean send(char[] Msg, int Start, int Length)
{
if (Msg == null || Msg.length == 0 || Start+Length > Msg.length)
return false;
for (int i=0; i < Length; i++)
{
if (putByte((byte)Msg[Start+i]) == false)
return false;
}
return true;
}
/**
* Writes a byte to SCI port.
*
* @param Val byte value that has to be transmitted
* @return true if byte has been put into the transmit buffer,
* otherwise false is returned
*/
private native boolean putByte(byte Val);
/**
* Reads the byte from the receive buffer. Prior calling this
* method programmer must make sure that there are characters
* available in the receive buffer by calling the byteReceived
* method.
*
* @return character retrieved from the receive buffer.
* If there are no characters available zero will be
* returned.
*/
private native byte getByte();
/**
* Checks if there are any bytes in the receive buffer.
*
* @return true if there is at least one unread character,
* otherwise false is returned
*/
private native boolean byteReceived();
/**
* Performs low level initialization of SCI port and sets the
* baud rate to requested value.
*
* @param Baud SCI baud rate value
*/
private native void setBaudRate(int Baud);
}
et l’autre programme qui a été développé est :
import java.io.*;
import java.util.*;
import javax.comm.*;
public class SimpleWrite {
static Enumeration portList;
static CommPortIdentifier portId;
static String messageString = "Write 55";
static SerialPort serialPort;
static OutputStream outputStream;
public static void main(String[] args) {
portList = CommPortIdentifier.getPortIdentifiers();
while (portList.hasMoreElements()) {
portId = (CommPortIdentifier) portList.nextElement();
if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
// if (portId.getName().equals("COM2")) {
if (portId.getName().equals("/dev/term/a")) {
try {
serialPort = (SerialPort)
portId.open("SimpleWriteApp", 2000);
} catch (PortInUseException e) {}
try {
outputStream = serialPort.getOutputStream();
} catch (IOException e) {}
try {
serialPort.setSerialPortParams(9600,
SerialPort.DATABITS_8,
SerialPort.STOPBITS_1,
SerialPort.PARITY_NONE);
} catch (UnsupportedCommOperationException e) {}
try {
outputStream.write(messageString.getBytes());
} catch (IOException e) {}
}
}
}
}
}
Le premier est l’application en Java qui a été inséré avec la machine virtuelle de Java dans le micro et qui est le programme principal puisqu’il exécute ce que nous voulons, ce que nous envoyons à travers des commandes qui voyagent par le port série entre le PC (qui va faire d’interface entre nous (l’usager et la carte avec le micro) et la carte mère.
Le deuxième est une application qui est fondé dans la COMM API et qui contrôle le port série (sa vitesse, les bits de parité, d’arrêt,...) et qui fait aussi l’envoi des commandes que nous voulons à travers du port.
Dans notre cas, les commandes que nous envoyons sont des commandes pour illuminer les leds qu’il y a dans la carte du micro et pour les éteindre. Ceci est seulement un exemple, parce que nous pourrions faire de même si nous avions eu un capteur de température, que le micro va acquérir. Le principe est d’avoir fait un programme qui donne un ordre au micro pour exécuter ce que nous voulons, et que cet ordre est bien accompli.
De plus, à travers une architecture client/serveur, nous avons installé notre programme d’application (celui de la COMM API) dans un serveur web qui est connecté via la RS-232 avec la carte du micro. Maintenant nous pouvons accéder avec n’importe quel ordinateur qui est connecté au réseau Internet, pour exécuter la commande que nous voulons dans la carte du microcontrôleur 68HC11.
Le schéma d’utilisation de ces logiciels et la forme de travail pourrait être le suivant:
En plus, la façon que M. Kadionik a eu de mener à bien le projet, avec tous les étapes que nous avons fait, tous les deux, pour bien envisager toutes les difficultés qui se sont posés, et les très bons résultats que nous avons obtenus à la fin, tout cela fait beaucoup plaisir quand on regarde ce qui était fait au début du stage et que l’on voit tout ce que nous avons fait.
C’est le moment aussi de dire que toutes les choses n’ont pas été faciles. Nous avons eu beaucoup de difficultés, surtout dans tout ce qui concerne la machine virtuelle, puisque c’est un sujet très récent et ça signifie qu’il y a encore beaucoup d’erreurs (comme par exemple ce que nous avions trouvé dans les méthodes natives écrites en langage C) et beaucoup de choses de compréhension difficile, mais que grâce à notre effort et notre persévérance nous avons su les surpasser.
Le bilan que je fais de ce stage est vraiment positif et très bon, et que j’ai trouvé un projet très intéressant et très bien mis au point.