Il permet de brancher plusieurs modules entre eux. En prenant l’exemple d’un module pour un traitement quelconque, la configuration de celui-ci permettrait de pouvoir :
● fournir les ressources (interfaces) pour l’utilisation de ce module ;
● réaliser les raccordements sur les couches inférieures d’une manière non visible pour les modules faisant usage de celui-ci.
|
configuration maConfig {
provides interface interf1;
}
implementation {
components PlatformPlop;
components monDriver;
interf1 = monDriver.interf1;
monDriver.stdControl -> PlatformPlop.stdControl;
}
|
Figure 5 : Fichier de configuration d’un module
Dans la figure 5, deux types de relations sont présentées :
● celle liée par un
= fait transiter l’information si elle a le même type (
uses ou
provides),
● celle liée par un
-> pour lier l’interface d’un module utilisant celle-ci à l’interface d’un module la fournissant. La flèche va toujours de l’utilisateur vers le
fournisseur.
Dans le cas présenté, un utilisateur de
maConfig ne connaîtra que l’interface
interf1, les relations entre
monDriver et
PlatformPlop étant cachées.
Il permet de fournir l’implémentation du module en lui-même. Celui-ci va contenir :
● l’implémentation des
commands/
events définis dans les interfaces qu’il uses/provides ;
● des variables locales au module ;
● des fonctions elles aussi locales ;
● des
tasks, qui sont des fonctions appelées d’une manière asynchrone et dont la portée est limitée au module.
La création d’une plate-forme n’est nécessaire que lorsque la définition du circuit cible n’est pas fournie d’origine par TinyOS. Cependant, étant donné que les applications se compilent en spécifiant la plate-forme cible, il s’agit de l’étape obligatoire avant de pouvoir développer une application sur un nouvel environnement matériel.
La plate-forme est une description du matériel fournissant par la suite l’abstraction entre les applications et la partie matérielle. L’explication de la création d’une plate-forme se fera au travers de la réalisation de celle de l’architecture de la figure 1 et se nommera
projet, en suivant le tutoriel disponible à
[7].
L’ensemble des fichiers à créer/modifier/utiliser se trouvent dans le répertoire racine des sources de TinyOS, celui-ci dépend de la méthode d’installation. Le chemin est défini par la variable
TOSROOT. Dans la suite de ce document, les fichiers et répertoires seront toujours en chemin relatif vis-à-vis de cette racine.
Une plate-forme permet une couche d’abstraction entre les applications et la carte utilisée. En d’autres termes, pour une communication selon un protocole quelconque, la hiérarchie du système se compose de la manière suivante :
1. L’application utilise le type correspondant sans toutefois connaître son implémentation par le système, ni le câblage sur la carte. Il n’a besoin que de savoir les actions possibles.
2. Le module ne connaît pas non plus le câblage. Il se contente de faire les traitements liés au module et passe les " ordres " au fichier que le créateur de la plate-forme a réalisé.
3. Le fichier de la plate-forme définit la liaison avec les ports du microcontrôleur ainsi que les paramètres de configuration sans connaître les registres.
4. Le pilote du microcontrôleur fait au final l’opération adéquate selon le besoin.
|
|
|
6.2 Structure minimale d’une plate-forme
|
Celle-ci est définie en deux entités principales qui sont :
1. Un fichier se trouvant dans
support/make. Il est de la forme
NomPlatform.target. Ce fichier informe la commande
make de l’existence de la plate-forme.
2. Un répertoire se trouvant dans
tos/platforms, qui va contenir l’ensemble des fichiers de configuration de la plate-forme. Chaque module s’attend à trouver un fichier portant un nom bien spécifique, permettant de simplifier le travail d’intégration.
|
|
|
6.3 Mise en place de la nouvelle plate-forme
|
En tout premier lieu, il est nécessaire de créer un répertoire projet dans
tos/platforms, avec la commande
mkdir projet.
1.
.projet.target : dans le répertoire
support/make, nous créons un fichier
projet.target, qui va contenir les lignes présentes dans le listing 1 :
|
PLATFORM = projet
$(call TOSMake_include_platform,msp)
projet: $(BUILD_DEPS)
@:
|
Listing 1 : projet.target
La première ligne précise le nom de la plate-forme. Les lignes suivantes donnent les informations dynamiques sur les dépendances de la plate-forme ainsi que d’autres règles de compilation liées au microcontrôleur.
2.
.platform : pour la suite, tout se déroulera dans
tos/platforms/projet.
.platform concerne les spécifications sur les répertoires contenant les bibliothèques de fonctions et les options de compilation. Contrairement à un logiciel pour un système d’exploitation " classique ", où les configurations et informations passées au compilateur sont fournies avec les sources de l’application, ces informations sont, dans TinyOS, au niveau de la plate-forme.
|
push( @includes, qw(
%T/chips/msp430
%T/chips/msp430/adc12
%T/chips/msp430/dma
%T/chips/msp430/pins
%T/chips/msp430/timer
%T/chips/msp430/usart
%T/chips/msp430/sensors
%T/lib/timer
%T/lib/serial
%T/lib/power
));
push ( @opts, qw(
-gcc=msp430-gcc
-mmcu=msp430x149
-fnesc-target=msp430
-fnesc-no-debug
-fnesc-scheduler=TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask
));
|
Listing 2 : .platform
