\documentstyle[12pt,a4]{article} \begin{document} % % % % % % % \begin{center} \bf{ -------------------------------------------------------\\ % {\LARGE EUROGAM Project }\\ % {\LARGE Short Note\\ on\\ % VxWorks implementation}\\ -------------------------------------------------------}\\ \end{center} % % % \noindent {\Large Edition 0.1\\ September 1990\\} % % % \begin{center} {\bf \LARGE . . .\\ .\\} \end{center} % % % % \noindent {\bf CENBG BORDEAUX : P. Kadionik, M.M. Al\'eonard\\ CRN STRASBOURG : B. Humbert\\} \newpage % % P. Kadionik 09/90 % \begin{center} ------------- \end{center} % % % Ce document repr\'esente le compte-rendu de l'installation et de l'\'evaluation de VxWorks au CRN de Strasbourg pendant le mois d'ao\~ut 1990 \footnote{$\dag$ Le lecteur connaissant d\'ej\`a VxWorks pourra passer directement au chap\~{\i}tre 3.}$\dag$.\\ % % % \begin{center} ------------- \end{center} \section{Introduction \`a VxWorks :} \subsection{Consid\'erations g\'en\'erales :} VxWorks est un produit logiciel qui permet de r\'ealiser des applications Temps R\'eel (TR). VxWorks b\'en\'eficie de tous les avantages qu'offre UNIX pendant la phase de d\'eveloppement.\\ Ainsi, la phase de d\'eveloppement de l'application (\'edition du programme source, compilation, "make"...) est r\'ealis\'ee sous UNIX. Le code ex\'ecutable g\'en\'er\'e est ensuite t\'el\'echarg\'e via le r\'eseau Ethernet dans le ch\~assis cible pour y faire l'\'edition de liens, le chargement m\'emoire puis est ex\'ecut\'e en temps r\'eel.\\ \begin{displaymath} \begin{tabular}{lccc} & UNIX & & VxWorks \\ & & &\\ & & r\'eseau & \\ & & Ethernet & \\ & & &\\ MISE AU POINT & D\'eveloppement & & \\ & Debugging & $\Longleftrightarrow$ & Application TR \\ & & & \\ PRODUIT FINI & Application non TR & $\Longleftrightarrow$ & Application TR \\ \end{tabular} \end{displaymath} % % \noindent Des communications entre une t\~ache UNIX et une t\~ache VxWorks sont possibles.\\ \subsection{Les possibilit\'es de VxWorks :} {\it La partie r\'eseau} a \'et\'e particuli\`erement soign\'ee. VxWorks est com\-pa\-ti\-ble avec NFS (Network File System) de Sun (partie client seulement). On peut, par cons\'equent, avoir acc\`es au syst\`eme de fichiers Sun au niveau du ch\~assis cible VxWorks.\\ On peut aussi utiliser rsh et ftp si NFS n'est pas utilis\'e. NFS peut en effet, \~etre s\'electionn\'e ou non en modifiant les fichiers de configuration (le r\'epertoire des fichiers de configuration \'etant .../vw/config/).\\ Les RPC (Remote Procedure Call) ont \'et\'e implant\'es sous VxWorks. Les RPC permettent \`a une t\~ache sur une machine d'appeler une proc\'edure qui est ex\'ecut\'ee par une autre t\~ache sur la m\~eme machine ou sur une machine distante. Signalons que les RPC de VxWorks sont en fait les RPC Sun, et sont donc par la m\~eme, 100%\% compatibles RPC Sun...\\ \noindent {\it Le syst\`eme d'E/S} est compatible C du point de vue du programmeur. On retrouve les primitives classiques : creat(), delete(), open(), close(), read(), write(), ioctl(). On retrouve aussi les routines utilisant les tampons m\'emoires beaucoup plus performantes (fread(), fwrite()...).\\ \noindent {\it Les drivers} sont nombreux. On peut distinguer :\\ - les "tty drivers" (on peut attacher une console au ch\~assis cible).\\ - les "network drivers".\\ - les "pipe drivers" (communication inter-t\~aches).\\ - les "RAM disk drivers".\\ - les "pseudo-tty drivers".\\ - les drivers de disque dur. On attend d'ailleurs 3 drivers pour les 3 bo\~{\i}tiers standards SCSI pour la prochaine version de VxWorks courant septembre 1990.\\ \noindent {\it L'architecture du syst\`eme de fichiers} est bas\'ee sur la structure de fichiers RT11.\\ \noindent {\it Des primitives} de type timex() (system V) sont aussi utilisables pour r\'ealiser des mesures de temps.\\ \noindent {\it Le mode multi-t\~aches. La communication inter-t\~aches}. VxWorks est multi- t\~aches (mono utilisateur). On utilise des niveaux de priorit\'e de 0 \`a 255 (255 \'etant le niveau de priorit\'e le plus faible).\\ Les s\'emaphores sont \'egalement implant\'es pour r\'egler les probl\`emes d'acc\`es \`a une m\~eme ressource.\\ D'autre part, pour la communication inter-t\~aches, on retrouve des primitives comme pipe(), socket(), signal() bien connues sous UNIX.\\ \section{La force de VxWorks :} L'environnement UNIX utilis\'e pendant la phase de d\'eveloppement et de debugging est un point fort de VxWorks.\\ \noindent La partie r\'eseau a \'et\'e particuli\`erement d\'evelopp\'ee et soign\'ee.\\ \noindent La programmation sous VxWorks se fait en C standard en utilisant en plus la biblioth\`eque sp\'ecifique \`a VxWorks. La programmation se fait en \'ecrivant des fonctions qui seront ex\'ecut\'ees sous VxWorks en les appelant directement par leur nom (il n'y a pas de main() sous VxWorks !!!). Il faut seulement faire attention \`a la nature du code g\'en\'er\'e lors de la compilation qui doit rester compatible avec la nature du code ex\'ecutable par la CPU cible ! Le code que l'on a g\'en\'er\'e est t\'el\'echarg\'e en m\'emoire RAM (l'emplacement de ce code en m\'emoire est g\'er\'e par VxWorks) via le r\'eseau Ethernet puis on l'ex\'ecute en temps r\'eel. \noindent VxWorks est avant tout bas\'e sur l'utilisation d'une seule et unique Table des Symboles qui r\`egle tous les probl\`emes de r\'ef\'erence de symboles externes.\\ Outre les symboles propres \`a VxWorks, les symboles d\'efinis dans une application sont rajout\'es automatiquement \`a la Table des Symboles lors du chargement de l'application dans le ch\~assis cible (commande {\it ld $<$ filename.o}), et ainsi sont accessibles \`a n'importe quelle t\~ache ult\'erieurement.\\ On comprend aussi pourquoi pendant la phase de d\'eveloppement d'une application, l'on ne fasse pas appel au linker !\\ \noindent Un seul regret :\\ Comme sous UNIX, la documentation de VxWorks est vraiment trop pauvre en exemples...\\ \section{Mise en oeuvre de VxWorks :} VxWorks est livr\'e sous forme d'un jeu d'EPROM, d'une cassette contenant le source ainsi que de la documentation aff\'erente.\\ Les EPROM sont sp\'ecifiques \`a la cible (ex : MVME 147) car elles tiennent compte notamment de la configuration hard de la carte.\\ Les EPROM remplacent celles du debugger de la 147. Il faut aussi reconfigurer des jumpers de la carte pour tenir compte de la taille m\'emoire des EPROM. Il faut installer sur le disque de la station de d\'eveloppement le contenu de la cassette VxWorks, puis d\'eclarer sous /etc/hosts le nom du ch\~assis cible.\\ Au niveau du ch\~assis cible, il faut d\'eclarer le nom de la station de d\'e\-ve\-lop\-pe\-ment. Ensuite, le noyau VxWorks ainsi que la Table des Symboles sont charg\'es en RAM de la carte cible via le r\'eseau Ethernet. Cette phase d'installation et de configuration est tr\`es bien d\'ecrite dans la documentation VxWorks.\\ \section{Travail r\'ealis\'e au CRN :} \subsection{Mat\'eriel disponible :} Nous avions \`a disposition comme mat\'eriel :\\ - un ch\~assis VME.\\ - un ch\~assis VXI.\\ - la carte prototype Resource Manager.\\ - une carte CPU MVME 147 "prom\'ee" avec VxWorks.\\ - une carte d'adaptation MVME 712.\\ - une station Sun pour le d\'eveloppement.\\ - une liaison Ethernet entre le Sun et le ch\~assis VME.\\ \subsection{Acquisition sous VxWorks :} Une carte d'interface de lecture de codeurs (r\'ef CRN) a \'et\'e implant\'ee dans le ch\~assis VME cible. Les donn\'ees issues d'un codeur num\'erisant le signal d'un g\'en\'erateur d'impulsions (physiques) sont envoy\'ees sur la carte d'interface.\\ Pour l'acquisition, les programmes suivants ont \'et\'e \'ecrits :\\ - initialisation de la carte d'interface (configuration des registres).\\ - incr\'ementation d'un histogramme en m\'emoire RAM.\\ - mise \`a z\'ero d'une zone m\'emoire.\\ \noindent La carte d'interface a \'et\'e initialis\'ee (en s'assurant que l'on n'\'etait pas dans l'espace m\'emoire syst\`eme). Un "RAM disk" sous VxWorks a \'et\'e cr\'e\'e (par la commande {\it ramMkfs}) servant d'interm\'ediaire entre la station de d\'eveloppement Sun et le ch\~assis cible. Cet espace m\'emoire sert de stockage de l'histogramme\\ Le logiciel de visualisation de spectre sous UNIX que l'on avait \`a diposition ne permettait de visualiser qu'un fichier de spectre sous un certain format (pr\'esence d'un header dans le fichier spectre). Pour ne pas rester \`a ce niveau, on a rappatri\'e en zone RAM disk un fichier spectre utilisable par le logiciel de visualisation. Conservant le header du fichier, le reste du fichier en RAM disk est mis \`a z\'ero. C'est \`a cet emplacement m\'emoire que l'on construira le spectre par incr\'ementation \`a chaque \'ev\'enement.\\ L'acquisition est alors lanc\'ee...\\ On transfert ensuite ce fichier de donn\'ees vers la station Sun pour y \~etre visualis\'e (\`a l'aide de la commande {\it copy} de VxWorks).\\ Cette m\'ethode un peu "rustique" s'est montr\'ee n\'eanmoins tr\`es efficace car le but \'etait avant tout de mettre en place rapidement une acquisition et non de d\'evelopper la partie graphisme.\\ \subsection{Mise en oeuvre des RPC :} La mise en oeuvre des RPC sous Sun et sous VxWorks fera l'objet d'un autre article ("Using Sun RPC", CENBG-FRANCE, P. Kadionik, october 1990).\\ Signalons que la valeur du time-out des RPC est accessible au programmeur.\\ \subsection{Tests de la carte prototype Resource Manager :} \subsubsection{Le Resource Manager et la norme VXI :} Rappelons d'abord, que l'on peut ins\'erer dans un ch\~assis VXI, 12 cartes VXI, en plus de celle du slot 0. On peut avoir au total 256 devices VXI. Un device VXI r\'ealise une fonction particuli\`ere (conversion A/N par exemple).\\ Pen\-dant la pha\-se di\-te d'au\-to\-con\-fi\-gu\-ra\-tion dy\-na\-mi\-que qui doit \~etre e\-x\'e\-cu\-t\'ee im\-m\'e\-dia\-te\-ment apr\`es mi\-se sous ten\-sion, le Resource Manager va affecter un num\'ero logique de 0 \`a 255 aux diff\'erents devices VXI contenus dans le ch\~assis VXI.\\ A ce num\'ero logique correspond une adresse de base VME, le num\'ero logique 0 ayant une adresse de base \$FFFFC000 (short I/O). A chaque device VXI sont associ\'es des registres VXI r\'epartis sur 64 octets, soit 32 re\-gis\-tres de 16 bits.\\ les devices VXI sont soit :\\ - Dynamic Configured : ce que l'on vient de voir et qui est la solution retenue pour EUROGAM.\\ - Switch Configured : l'adresse logique du device VXI, donc l'adresse physique, est d\'ej\`a impos\'ee par un syst\`eme de switchs.\\ % % \noindent Nous avons ensuite test\'e la carte prototype Resource Manager qui sera utilis\'ee dans les ch\~assis VXI pour EUROGAM.\\ \subsubsection{Tests de la carte Resource Manager :} Nous a\-vons cou\-pl\'e la car\-te pro\-to\-ty\-pe Re\-sour\-ce Ma\-na\-ger \`a no\-tre car\-te MVME147 pro\-m\'ee a\-vec Vx\-Works. Nous avons install\'e le tout dans le ch\~assis VXI (nous n'avions pas d'autres cartes VXI dans le ch\~assis...).\\ Nous avons remarqu\'e que le slot 0 n'est pas accessible par le bus VME, car pour EUROGAM, le Resource Manager a \'et\'e noy\'e dans le slot 0 (la norme VXI le permet n\'eanmoins). Le Resource Manager ne permet pas un acc\`es octet. L'acc\`es est ici un acc\`es mot. La norme VXI recommande un acc\`es octet (recommandation C-2-1) mais l'acc\`es mot est permis.\\ L'acc\`es en lecture ainsi qu'en \'ecriture aux diff\'erents registres (en accord avec la norme VXI) de la carte Resource Manager s'est fait sans probl\`eme.\\ % % \noindent Nous pouvons dire, en conclusion de ces tests, que la carte prototype Resource Manager propos\'ee par les ing\'enieurs anglais, nous a donn\'e pleinement satisfaction. \subsubsection{Mise en place d'un logiciel de tests de cartes VXI :} Un serveur de RPC dont le r\~ole est de lire le contenu des re\-gis\-tres VXI d'un device VXI ou d'y \'ecrire aussi des donn\'ees a \'et\'e install\'e dans le ch\~assis VXI. Ce logiciel respecte la norme VXI au niveau de l'adressage m\'emoire (voir ci-dessus).\\ % \noindent Un logiciel fonctionnant sur la station Sun a \'et\'e \'ecrit pour r\'ealiser les appels RPC et traiter les r\'esultats issus des diff\'erentes op\'erations de Lecture/Ecriture des re\-gis\-tres VXI d'un device VXI. \\ Ceci a ainsi permis de mettre en place un outil tr\`es pr\'ecieux pour l'\'electronicien qui lui permettra de tester et d'initialiser ses cartes VXI.\\ Cet outil, d'utilisation tr\`es ais\'ee, permet de conna\~{\i}tre le contenu des 32 registres VXI d'un device. Il permet d'\'ecrire une donn\'ee (mot) dans un registre VXI d'un device. Il permet aussi de savoir, si le registre consid\'er\'e est un registre ayant deux fonctions distinctes (la valeur \'ecrite est diff\'erente de la valeur lue ensuite).\\ \subsection{VxWorks et la carte THEMIS :} Nous avons install\'e VxWorks (EPROM) sur une carte CPU 68030 (THEMIS). Nous avons fait quelques tests. Les performances de la carte THEMIS sont comparables \`a celles de la carte MVME147 (vitesse d'ex\'ecution...). Signalons un petit bug au niveau d'un fichier de configuration VxWorks pour la carte THEMIS, dans lequel on initialise le registre de cache comme pour un processeur 68020 et non comme pour un processeur 68030 ; d' o\`u une perte de 20\% en rapidit\'e de la carte sous VxWorks.\\ \subsection{Mise en PROM d'une application VxWorks :} Ces facilit\'es sont incluses dans le package.\\ - Il est possible de r\'ealiser d'autres EPROM VxWorks (moniteur) pour d'autres cibles du m\~eme type ( ici pour la carte MVME 147).\\ \noindent - Il est possible d'ins\'erer dans les EPROM une application (par exemple notre serveur VXI) et son activation.\\ \noindent - Enfin, on peut rajouter le noyau VxWorks ainsi que la Table des Symboles des symboles propres \`a VxWorks, en plus, en PROM (charg\'es par d\'efaut en m\'emoire RAM de la carte cible via Ethernet). On a alors un syst\`eme compl\'etement autonome et pr\~et \`a la mise sous tension (sys\-t\`e\-me em\-bar\-ca\-ble). Remarquons que la Table des Symboles prom\'ee contiendra les symboles propres \`a VxWorks ainsi que les symboles de l'application. Cet\-te der\-ni\`e\-re pos\-si\-bi\-li\-t\'e est en cours de r\'e\-a\-li\-sa\-tion...\\ \noindent En\-fin, si\-gna\-lons que l'on peut sup\-pri\-mer des op\-tions lors de la g\'e\-n\'e\-ra\-tion du fichier S-record ( suppression de l'option NETWORK dans les fichiers de configuration) si l'application ne n\'ecessite pas d'acc\`es au r\'eseau Ethernet.\\ \section{Conclusion :} L'installation et la mise en oeuvre de VxWorks est tr\`es facile pour une personne connaissant UNIX et le langage C. Mise \`a part le manque d'exemples dans la documentation, VxWorks nous a pleinement satisfait.\\ % % \noindent Une configuration minimale pour mettre en place une cellule de d\'eveloppement de logiciels sous VxWorks requiert :\\ - un ch\~assis VME.\\ - une carte CPU MVME147 \'equip\'ee des EPROM VxWorks.\\ - une carte d'interface pour la connexion Ethernet \`a installer dans le ch\~assis cible.\\ - une station Sun pour le d\'eveloppement des logiciels.\\ - un c\~able Ethernet.\\ % % \noindent Au niveau du travail \`a accomplir, il reste \`a :\\ - r\'ealiser une acquisition o\`u la partie visualisation serait active ("alive spectrum").\\ - tester le mode multi-t\~aches et les communications inter-t\~aches.\\ - mettre en place l'autoconfiguration VXI.\\ - am\'eliorer l'outil de tests des cartes VXI.\\ - avec la nouvelle version de VxWorks qui doit arriver courant septembre 1990, explorer le driver SCSI.\\ \noindent VxWorks est tout \`a fait adapt\'e pour implanter les logiciels "Crate Server" dans les ch\~assis VXI et VME dans le contexte de r\'eseau de l'acquisition EUROGAM. Son utilisation pour cr\'eer le Tape Server est \`a examiner de pr\`es que le driver SCSI aura \'et\'e \'etudi\'e.\\ Pour les cibles VXI "standalone" (pour des tests en labo), une version minimale pourrait \~etre mise au point. Ceci suppose que tout le logiciel de test mis au point soit accessible, par exemple, en incluant un disque dur (utilit\'e du driver SCSI de VxWorks) au ch\~assis cible. Mais, notons qu'il est souhaitable de ne pas se s\'eparer de la station Sun, la console de contr\~ole attach\'ee au ch\~assis cible ne servant en fait, que pour l'installation (saisie des diff\'erents param\`etres : adresse IP,...).\\ \end{document}