Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Embarqué

Boîtes aux lettres :présentation et services de base


Voir la série RTOS Revealed

Les boîtes aux lettres ont été introduites dans un article précédent. Ils sont peut-être la deuxième méthode de communication inter-tâches la plus simple – après les signaux – prise en charge par Nucleus SE. Ils offrent un moyen peu coûteux, mais flexible, de transmettre des messages simples entre les tâches.

Utilisation des boîtes aux lettres

Dans Nucleus SE, les boîtes aux lettres sont configurées au moment de la création. Il peut y avoir un maximum de 16 boîtes aux lettres configurées pour une application. Si aucune boîte aux lettres n'est configurée, aucune structure de données ou code d'appel de service appartenant aux boîtes aux lettres n'est inclus dans l'application.

Une boîte aux lettres est simplement un emplacement de stockage, assez grand pour contenir une seule variable de type ADDR , dont l'accès est contrôlé afin qu'il puisse être utilisé en toute sécurité par plusieurs tâches. Une tâche peut écrire dans une boîte aux lettres. Il est alors plein et aucune tâche ne peut lui être envoyée tant qu'une tâche n'a pas effectué une lecture sur la boîte aux lettres ou que la boîte aux lettres n'a pas été réinitialisée. Essayer d'envoyer vers une boîte aux lettres pleine ou de lire à partir d'une boîte vide peut entraîner une erreur ou une suspension de tâche, selon les options sélectionnées dans l'appel d'API et la configuration Nucleus SE.

Boîtes aux lettres et files d'attente

Dans certaines implémentations de système d'exploitation, les boîtes aux lettres ne sont pas implémentées et l'utilisation d'une file d'attente à entrée unique est recommandée comme alternative. Cela semble raisonnable, car une telle file d'attente fournirait les mêmes fonctionnalités qu'une boîte aux lettres. Cependant, une file d'attente est une structure de données un peu plus complexe qu'une boîte aux lettres et comporte considérablement plus de temps système en termes de données (pointeurs de tête et de queue, etc.), de code et de temps d'exécution.

Avec Nucleus SE, comme Nucleus RTOS, vous avez le choix entre les deux types d'objets et pouvez prendre la décision vous-même.

Il vaut la peine d'envisager l'approche alternative si votre application comprend plusieurs files d'attente, mais peut-être une seule boîte aux lettres. Le remplacement de cette boîte aux lettres par une file d'attente entraînera une petite surcharge de données, mais élimine tout le code API lié à la boîte aux lettres. Il serait très facile de configurer l'application dans les deux sens et de comparer les empreintes mémoire et les performances.

Les files d'attente seront abordées dans les prochains articles.

Configuration des boîtes aux lettres

Nombre de boîtes aux lettres

Comme pour la plupart des aspects de Nucleus SE, la configuration des boîtes aux lettres est principalement contrôlée par #define déclarations dans nuse_config.h . Le paramètre de clé est NUSE_MAILBOX_NUMBER , qui détermine le nombre de boîtes aux lettres configurées pour l'application. Le paramètre par défaut est 0 (c'est-à-dire qu'aucune boîte aux lettres n'est utilisée) et vous pouvez le définir sur n'importe quelle valeur jusqu'à 16. Une valeur erronée entraînera une erreur de compilation, qui est générée par un test dans nuse_config_check.h (ceci est inclus dans nuse_config.c et donc compilé avec ce module) résultant en une #error déclaration en cours de compilation.

Le choix d'une valeur différente de zéro est l'« activation principale » pour les boîtes aux lettres. Il en résulte que certaines structures de données sont définies et dimensionnées en conséquence, dont plus dans le prochain article. Il active également les paramètres d'activation de l'API.

Activation de l'API

Chaque fonction API (appel de service) dans Nucleus SE a un #define d'activation symbole dans nuse_config.h . Pour les boîtes aux lettres, ce sont :

NUSE_MAILBOX_SEND
NUSE_MAILBOX_RECEIVE
NUSE_MAILBOX_RESET
NUSE_MAILBOX_INFORMATION
NUSE_MAILBOX_COUNT

Par défaut, tous ces éléments sont définis sur FALSE , désactivant ainsi chaque appel de service et empêchant l'inclusion de tout code d'implémentation. Pour configurer les boîtes aux lettres pour une application, vous devez sélectionner les appels d'API que vous souhaitez utiliser et définir leurs symboles d'activation sur TRUE .

Voici un extrait du nuse_config.h par défaut fichier.

/* Nombre de boîtes aux lettres dans le  système - 0-16 */ #define NUSE_MAILBOX_NUMBER 0  /* Facilitateurs d'appels de service :*/ #define NUSE_MAILBOX_SEND FALSE  #define NUSE_MAILBOX_RECEIVE FALSE  #define NUSE_MAILBOX_RESET FALSE  #define NUSE_MAILBOX_INFORMATION FALSE  #define NUSE_MAILBOX_COUNT FALSE  

Une erreur de compilation se produira si une fonction API de boîte aux lettres est activée et qu'aucune boîte aux lettres n'est configurée (sauf pour NUSE_Mailbox_Count() ce qui est toujours autorisé). Si votre code utilise un appel API, qui n'a pas été activé, une erreur de temps de liaison se produira, car aucun code d'implémentation n'aura été inclus dans l'application.

Appels de service de boîte aux lettres

Nucleus RTOS prend en charge neuf appels de service qui appartiennent aux boîtes aux lettres, qui fournissent les fonctionnalités suivantes :

  • Envoyer un message à une boîte aux lettres. Implémenté par NUSE_Mailbox_Send() dans Nucleus SE.

  • Recevoir un message d'une boîte aux lettres. Implémenté par NUSE_Mailbox_Receive() dans Nucleus SE.

  • Restaurez une boîte aux lettres à l'état inutilisé, sans aucune tâche suspendue (réinitialisation). Implémenté par NUSE_Mailbox_Reset() dans Nucleus SE.

  • Fournir des informations sur une boîte aux lettres spécifiée. Implémenté par NUSE_Mailbox_Information() dans Nucleus SE.

  • Renvoyer le nombre de boîtes aux lettres (actuellement) configurées pour l'application. Implémenté par NUSE_Mailbox_Count() dans Nucleus SE.

  • Ajouter une nouvelle boîte aux lettres à l'application (créer). Non implémenté dans Nucleus SE.

  • Supprimer une boîte aux lettres de l'application (supprimer). Non implémenté dans Nucleus SE.

  • Renvoyer des pointeurs vers toutes les boîtes aux lettres (actuellement) dans l'application. Non implémenté dans Nucleus SE.

  • Envoyer un message à toutes les tâches suspendues sur une boîte aux lettres (diffusion). Non implémenté dans Nucleus SE.

La mise en œuvre de chacun de ces appels de service est examinée en détail.

Services d'écriture et de lecture de boîtes aux lettres

Les opérations fondamentales, qui peuvent être effectuées sur une boîte aux lettres, consistent à y écrire des données - ce qui est parfois appelé envoi ou publication – et en lire les données – ce qui est également appelé réception . Nucleus RTOS et Nucleus SE fournissent chacun deux appels d'API de base pour ces opérations, qui seront abordés ici.

Écrire dans une boîte aux lettres

L'appel de l'API Nucleus RTOS pour l'écriture dans une boîte aux lettres est très flexible, vous permettant de suspendre indéfiniment, ou avec un délai d'attente, si l'opération ne peut pas être terminée immédiatement ; c'est-à-dire que vous essayez d'écrire dans une boîte aux lettres pleine. Nucleus SE fournit le même service, sauf que la suspension des tâches est facultative et que le délai d'expiration n'est pas implémenté.

Nucleus RTOS offre également une fonction de diffusion vers une boîte aux lettres, mais cela n'est pas pris en charge par Nucleus SE. Il sera décrit sous API non implémentées dans le prochain article.

Appel API Nucleus RTOS pour l'envoi vers une boîte aux lettres

Prototype d'appel de service :

STATUT NU_Send_To_Mailbox(NU_MAILBOX *boîte aux lettres, VOID *message,  UNSIGNÉ suspendre );

Paramètres :

boîte aux lettres – pointeur vers la boîte aux lettres à utiliser

message – un pointeur vers le message à envoyer qui est quatre non signé éléments

suspendre – spécification pour la suspension de la tâche; peut être NU_NO_SUSPEND ou NU_SUSPEND ou une valeur de délai d'attente

Retours :

NU_SUCCESS – l'appel s'est terminé avec succès

NU_INVALID_MAILBOX – le pointeur de la boîte aux lettres est invalide

NU_INVALID_POINTER – le pointeur de message est NULL

NU_INVALID_SUSPEND – la suspension a été tentée à partir d'un thread sans tâche

NU_MAILBOX_FULL – la boîte aux lettres est pleine et la suspension n'a pas été spécifiée

NU_TIMEOUT – la boîte aux lettres est toujours pleine même après une suspension pendant la période spécifiée

NU_MAILBOX_DELETED – la boîte aux lettres a été supprimée alors que la tâche était suspendue

NU_MAILBOX_WAS_RESET – la boîte aux lettres a été réinitialisée alors que la tâche était suspendue

Appel API Nucleus SE pour l'envoi vers une boîte aux lettres

Cet appel d'API prend en charge la fonctionnalité clé de l'API Nucleus RTOS.

Prototype d'appel de service :

STATUS NUSE_Mailbox_Send(boîte aux lettres NUSE_MAILBOX, ADDR *message,  U8 suspend);

Paramètres :

boîte aux lettres – l'index (ID) de la boîte aux lettres à utiliser

message – un pointeur vers le message à envoyer, qui est une variable unique de type ADDR

suspendre – spécification pour la suspension de la tâche; peut être NUSE_NO_SUSPEND ou NUSE_SUSPEND

Retours :

NUSE_SUCCESS – l'appel s'est terminé avec succès

NUSE_INVALID_MAILBOX – l'index de la boîte aux lettres est invalide

NUSE_INVALID_POINTER – le pointeur de message est NULL

NUSE_INVALID_SUSPEND – la suspension a été tentée à partir d'un thread sans tâche ou lorsque le blocage des appels d'API n'était pas activé

NUSE_MAILBOX_FULL – la boîte aux lettres est pleine et la suspension n'a pas été spécifiée

NUSE_MAILBOX_WAS_RESET – la boîte aux lettres a été réinitialisée alors que la tâche était suspendue

Implémentation Nucleus SE de Mailbox Send

La majeure partie du code du NUSE_Mailbox_Send() La fonction API - après vérification des paramètres - est sélectionnée par compilation conditionnelle, selon que la prise en charge du blocage (suspension des tâches) des appels API est activée. Nous allons examiner les deux variantes séparément ici.

Si le blocage n'est pas activé, la logique de cet appel d'API est assez simple et le code nécessite peu d'explications :

if (NUSE_Mailbox_Status[mailbox]) /* boîte aux lettres pleine */{ return_value =NUSE_MAILBOX_FULL;}else /* boîte aux lettres vide */{ NUSE_Mailbox_Data[mailbox] =*message; NUSE_Mailbox_Status[mailbox] =TRUE ; return_value =NUSE_SUCCESS;}

Le message est stocké dans l'élément approprié de NUSE_Mailbox_Data[] et la boîte aux lettres marquée comme étant en cours d'utilisation.

Lorsque le blocage est activé, le code devient plus complexe :

do{ if (!NUSE_Mailbox_Status[mailbox]) /* boîte aux lettres vide */ { NUSE_Mailbox_Data[mailbox] =*message; NUSE_Mailbox_Status[mailbox] =TRUE ; if (NUSE_Mailbox_Blocking_Count[mailbox] !=0) { indice U8 ; /* vérifie si une tâche est bloquée */ /* sur cette boîte aux lettres */ NUSE_Mailbox_Blocking_Count[mailbox]--; for (index=0; index 

Quelques explications peuvent être utiles :

Le code est entouré d'un do…while boucle, qui continue pendant que le paramètre suspend a la valeur NUSE_SUSPEND .

Si la boîte aux lettres est vide, le message fourni est enregistré et l'état de la boîte aux lettres est modifié pour indiquer qu'elle est pleine. Une vérification est effectuée pour savoir si des tâches sont suspendues (en attente de réception) sur la boîte aux lettres. S'il y a des tâches en attente, la première est réveillée. Le suspendre la variable est définie sur NUSE_NO_SUSPEND et l'appel d'API se termine avec NUSE_SUCCESS .

Si la boîte aux lettres est pleine et suspendez est défini sur NUSE_NO_SUSPEND , l'appel d'API se termine avec NUSE_MAILBOX_FULL . Si suspendre a été défini sur NUSE_SUSPEND , la tâche est suspendue. Au retour (c'est-à-dire au réveil de la tâche), si la valeur de retour est NUSE_SUCCESS , indiquant que la tâche a été réveillée parce qu'un message avait été lu (par opposition à une réinitialisation de la boîte aux lettres) le code revient en haut.


Embarqué

  1. Une introduction aux serrures à came et à leur fonctionnement
  2. Une introduction aux vis à œil et à leur fonctionnement
  3. Une introduction aux œillets et à leur fonctionnement
  4. Une introduction à l'acier inoxydable et à sa fabrication
  5. COVID 19 et Cloud ; COVID 19 et son impact sur les entreprises
  6. Entrée et sortie de base C#
  7. Sémaphores :services utilitaires et structures de données
  8. Sémaphores :introduction et services de base
  9. Groupes d'indicateurs d'événement :services publics et structures de données