Aller au contenu

TP02 : Station météo multi-tâches

Photo par Ralph Hutter sur Unsplash

Dans ce TP, nous transformerons l’application développée dans le TP 01 en programme multi-tâches.

Objectifs du TP

Ce TP a pour but de réaliser le programme de collecte de données comme application multi-tâches. Cette réalisation sera la base de l’application pour les TPs suivants qui permettront de publier ces données sur le cloud.

À la fin de ce TP, les étudiants :

  • auront pris connaissance des outils multi-tâches du système d’exploitation Mbed OS;
  • auront réalisé un test unitaire qui tourne sur une cible pour chaque composant logiciel développé;
  • auront rédigé un journal de travail et déposé le PDF sur Teams.

Les livrables sont :

  • la mise à jour du projet sur le dépôt de votre groupe sur gitlab.forge.hefr.ch avec le code du TP et le code du programme de test;
  • un release avec le tag “tp02” doit être créé sur votre dépôt.
  • la correction des issues du TP 01 qui ont été créés lors de la correction du TP 01.
  • une configuration CI/CD de gitlab pour valider votre TP;
  • un journal de travail déposé sur Teams.

Temps accordé : 4 périodes de 45 minutes en classe + travail personnel à la maison

Délai

Les dates de rendu des TPs sont indiquées sur le plan de cours.

Classe pour l’acquisition des données environnementales

Réalisez une classe nommée SensorDataServer (dans le dossier lib/sensor_data_server de votre projet) qui se charge de récolter les données du capteur et les mettre à disposition d’autres modules. La classe doit être réalisée selon les contraintes suivantes:

  • Les données doivent être échangées avec les clients de la classe à l’aide d’un Mail. Le constructeur de la classe SensorDataServer doit recevoir une référence à l’instance de Mail utilisée pour l’échange de données.
  • Concernant la réalisation à l’aide de l’API Mail, les contraintes de réalisation sont les suivantes:
    • Mail est une classe template avec les paramètres template T et queue_sz. T détermine le type de la structure de données des données échangées et queue_sz détermine le nombre d’éléments utilisés pour cet échange.
    • queue_sz doit être défini par une constante définie dans la classe SensorDataServer.
    • Un type de données est défini dans la classe SensorDataServer afin de représenter le type T du Mail utilisé. Ce type de données doit être une struct et doit permettre de sauvegarder les données provenant des capteurs avec un temps d’acquisition de ces données (de type time_t)
    • Le temps d’acquisition des données doit être obtenu à l’aide de la fonction time comme documenté sur Time API.
    • Si aucun mail n’est disponible afin de sauvegarder la dernière acquisition, les données les plus anciennes doivent être effacées.
  • Un thread dédié doit être créé afin d’obtenir les données des capteurs périodiquement.
  • La classe fournit une méthode start qui permet de démarrer l’acquisition de données des capteurs et qui reçoit en paramètre l’intervalle de temps avec lequel les données des capteurs doivent être récoltées.
  • La classe fournit une méthode stop qui permet de stopper l’acquisition de données.

Modification du programme main

Votre programme principal et votre fonction main doivent être modifiés de la façon suivante:

  • Dans la fonction main, vous devez créer une instance de SensorDataServer sur le stack et démarrer l’acquisition de données selon un intervalle de temps. L’instance SensorDataServer reçoit en paramètre une référence sur une instance de Mail qui sera également créée sur le stack.
  • Dans le programme principal, vous devez créer une fonction displaySensorData qui permet d’afficher les données environnementales sur l’écran LCD. Cette fonction utilise l’instance de Mail en tant que consommateur.
  • Dans la fonction main, vous devez appeler la fonction displaySensorData. Soyez attentifs au fait que le thread principal (le main thread) ne doit jamais se terminer pour un comportement adéquat de votre programme.

Mode d’acquisition urgente

Dans le but de mettre en pratique le mécanisme de priorité supporté par Mbed OS, vous devez réaliser le comportement suivant:

  • Lorsque l’utilisateur presse sur le bouton, une prise de mesures des données environnementales doit être effectuée le plus rapidement possible, sans interrompre le mécanisme mis en œuvre dans la classe SensorDataServer.
  • Pour réaliser ce mécanisme, vous devez réaliser une routine ISR qui confie (defer) le travail à un thread dédié qui travaille avec une priorité supérieure aux autres threads de l’application.
  • Comme ce thread est de plus haute priorité, il est possible que, dans votre réalisation, le système préempte un thread effectuant une opération de plus basse priorité. Si c’est le cas, et en vous inspirant de l’exemple vu en cours, vous devez identifier les sections critiques qui doivent être protégées dans les modules développés, de façon à éviter qu’une préemption produise un résultat erroné.

Important

Votre réalisation doit limiter le nombre de threads créés et exécutés par votre application à 2, à savoir le main thread et le thread démarré au moment où SensorDataServer::start() est appelé. Le traitement de l’acquisition urgente ne doit également pas créer de thread supplémentaire. Songez à utiliser le mécanisme d’‘EventQueue` afin que les mesures soient effectuées selon l’intervalle de temps spécifié.

Tests et validations

Vous devez d’abord valider votre réalisation en l’instrumentant de différentes manières :

  • Vous devez instrumenter votre code afin d’afficher la période d’acquisition des données. Au début de l’exécution de la tâche de lecture des données de capteurs, vous devez afficher le temps écoulé depuis la mesure précédente. Cette instrumentation peut être réalisée à l’aide d’un Timer.
  • Vous devez instrumenter votre code de façon à démontrer les proportions de temps que le CPU passe en mode actif, en mode sleep et en mode deep sleep. Cette instrumentation doit être réalisée à l’aide de l’API Mbed Statistics (voir également l’exemple sous example cpu-stats).

Comme votre réalisation a été modularisée et conçue en tâches concurrentes, il est utile de tester les modules et tâches de façon isolée des autres :

  • Pour le module SensorDataServer, vous devez valider que l’absence de capteur est détectée correctement par l’application. Vous pouvez choisir le comportement désiré dans ce cas-là et le comportement désiré doit être testé.
  • Pour le module SensorDataServer, vous devez valider que l’acquisition fonctionne correctement en absence de consommateur de données.
  • Pour le module SensorDataServer, vous devez valider que la dernière donnée acquise n’est pas plus ancienne que le temps courant moins la période d’acquisition, avec ou sans consommateur de données.
  • Pour le module LCDDisplay, vous devez valider que le comportement est correct en absence de données produites.
  • Pour votre application et les modules concernés, vous devez ajouter au moins 1 test supplémentaire que vous concevez et documentez dans le rapport.

Pour effectuer les tests en utilisant l’infrastructure CI/CD mise à disposition, vous pouvez reprendre la configuration .gitlab-ci.yml du tp01.

Corrections des “issues” du TP 01

Pour chaque issue créé avec le milestone “TP2” sur votre dépôt, vous devez

  • Créer une merge request à partir de l’issue, à l’aide du bouton associé de l’interface web et en choisissant Create merge request and branch. Choisissez un nom approprié MR-BRANCH-NAME (ici “2-test”) pour la branche:

  • La branche doit être créée à partir de la branche main et le merge doit se faire vers la branche main.
  • Affecter “tobias.moullet” comme reviewer du merge request. Le reviewer doit être optionnel afin que vous puissiez effectuer le merge sans attendre le review.
  • Modifiez les options de merge de sorte à ce que la branche ne soit PAS effacée au moment du merge:

  • Le résultat attendu de vos opérations doit être comme illustré ci-dessous:

  • Exécuter “git fetch” sur votre machine.
  • Exécuter “git checkout MR-BRANCH-NAME” sur votre machine.
  • Effectuer la correction, puis “git add…”, “git commit…”
  • Effectuer “git push MR-BRANCH-NAME”
  • Vérifier que le pipeline a effectué les jobs configurés avec succès.
  • Une fois toutes les corrections apportées avec succès, vous pouvez effectuer le merge. La branche MR-BRANCH-NAME sera alors fusionnée avec main et le merge request sera catégorisé comme “Merged”. L’issue sera également automatiquement fermé.
  • Lors des corrections, un commentaire sera ajouté dans l’issue correspondant afin de valider la correction. Si la correction ne devait pas être validée, alors l’issue sera réouverte et devra être corrigée pour le TP suivant.
  • Il faut noter qu’habituellement la revue du merge request aurait lieu avant que le merge soit effectué. Toutefois, afin de vous permettre d’intégrer les corrections au plus vite, dans notre cas le review est déclaré optionnel.

À ne pas oublier

  • Choisissez de bons noms pour les classes, les méthodes et les variables.
  • Implémentez les bibliothèques avec un haut niveau d’abstraction pour pouvoir réutiliser les méthodes dans d’autres projets.
  • Faites des “git commit” régulièrement avec de bons commentaires.
  • Configurez le CI/CD de gitlab correctement et validez votre réalisation le plus tôt possible à l’aide de l’infrastructure mise à disposition.
  • Utilisez des assertions dans votre code pour le documenter et le rendre plus robuste.

Journal de travail

  • Rédigez un rapport (journal de travail) avec les indications suivantes :
  • Une page de titre avec au minimum :
    • le nom et le logo officiel de l’école
    • le nom du cours : Module Acquisition et traitement de données : Internet des Objets
    • le titre de votre document : Travail Pratique 2 : Capteur météo, écran LCD et threads
    • le numéro de votre groupe
    • les noms des auteurs (vous) avec la classe dans laquelle vous êtes
    • la date à laquelle vous avez terminé le rapport
    • éventuellement la version du rapport
  • Une introduction pour poser le contexte
  • Un résumé des notions que vous avez apprises pendant ce TP en précisant si c’est
    • non acquis
    • acquis, mais encore à exercer
    • parfaitement acquis
  • Un résumé des points qui vous semblent importants et que vous devez retenir
  • Les réponses aux questions.
  • Le code source bien formaté et avec du “syntax highlighting” de votre code source.
  • Une conclusion par laquelle vous donnez vos impressions sur le TP, ce que vous avez aimé, ce que vous avez moins aimé, et éventuellement des suggestions pour des changements. Indiquez également le nombre d’heures que vous avez passées, par personne, en dehors des heures de TP en classe.

Important

Déposez votre rapport dans le devoir Teams correspondant avec le nom report02.pdf.