# Microcontrôleur et périphériques #### Comprendre les caractéristiques principales des interfaces de communication (I2C, SPI, UART) et être capable de les comparer et de les câbler avec les principales connexions. ![](https://i.imgur.com/MKkrh4G.png) - UART : 1 fils TX -> RX simplex ou 2 fils TX/RX <---> RX/TX - I2C : 2 fils de données SDA / SCL et 2 fils d'alim + / - - SPI : 4 fils SCK (clock) / SDI (Serial data input) / SDO (Serial data output) / CS (Chip select) #### Comprendre les mécanismes d’interruption et de Timer sous Mbed OS. Être capable de réaliser des programmes simples impliquant ces mécanismes. Interruptions ```cpp= #include "mbed.h" constexpr int kLedOn = 0; constexpr int kLedOff = 1; DigitalOut led(PE_0, kLedOff); void handler() { led = !led; } int main() { InterruptIn button(PA_0, PullDown); button.rise(&handler); while (true) { asm("nop"); } } ``` Timer ```cpp= #include "mbed.h" constexpr int kLedOn = 0; constexpr int kLedOff = 1; void toggle(DigitalOut* led) { *led = !*led; } int main() { DigitalOut led(PE_0, kLedOff); Ticker flipper; flipper.attach(callback(&toggle, &led), 500ms); while (true) { asm("nop"); } } ``` #### Être capable de programmer des mécanismes GPIO avec Mbed OS. ```cpp= #include "mbed.h" constexpr int kLedOn = 0; constexpr int kLedOff = 1; constexpr int buttonReleased = 0; constexpr int buttonPressed = 1; int main() { DigitalOut led(PE_0, kLedOff); DigitalIn button(PA_0, PullDown); int prevState = button; while (true) { int state = button; if (prevState == buttonReleased && state == buttonPressed) { led = !led; } prevState = state; } } ``` # Modèles de programmation #### Expliquer les principes essentiels et les besoins des systèmes temps-réel. Les systèmes temps-réel sont des systèmes qui doivent respecter certaines contraintes temporelles et assurer que certaines tâches soient accomplies dans les limites de temps définies. Ces systèmes sont souvent catégorisés en : - systèmes hard real-time qui doivent garantir que les tâches critiques sont toujours exécutées dans les limites de temps imparties. Pour ces systèmes, ne pas respecter une limite de temps équivaut à une erreur qui peut avoir un effet catastrophique. On peut citer les systèmes de contrôle de moteur par exemple. Ces systèmes sont souvent réalisés à l’aide d’architecture et de processeur spécialisés, qui souvent combinent la redondance, comme par exemple les systèmes réalisant l’architecture Cortex-R. - systèmes soft real-time qui respectent les limites de temps la plupart du temps et au mieux des possibilités. Ces systèmes autorisent le fait qu’une limite de temps ne soit pas respectée sans pour autant produire une erreur catastrophique. Les systèmes que nous développerons dans ce cours appartiennent évidemment à cette catégorie. #### Expliquer les principes essentiels du problème de l’ordonnancement. Un programme pour systèmes embarqués doit accomplir un certain nombre de tâches de manière concurrente, ces tâches pouvant être périodiques ou événementielles. Chaque tâche peut être caractérisée par les spécifications temporelles suivantes: - C (computation time): le temps processeur le plus long consommé pour l’exécution de la tâche. - T (period): pour les tâches périodiques, la période de la tâche. - a (arrival time): moment auquel la tâche est prête pour exécution. - s (start time): moment auquel la tâche débute effectivement son exécution. - f (finishing time): moment auquel la tâche termine son exécution. - D (deadline): moment auquel la tâche doit avoir complété son exécution. ![](https://i.imgur.com/0wYn7Ot.png) #### Être capable de résoudre un problème d’ordonnancement pour un problème spécifié (tâches spécifiées avec leurs caractéristiques), selon les mécanismes d’ordonnancement statique cyclique et de machines d’état. ![](https://i.imgur.com/RT3YFA9.png) #### Expliquer les mécanismes permettant la programmation multi-tâches sous Mbed OS (ordonnancement, Thread, EventQueue, mécanismes de synchronisation et de partages de ressources). #### Programmer une application simple impliquant plusieurs threads et permettant leur synchronisation. # Les systèmes de communication sans fil #### Nommer les critères importants qui interviennent dans le choix d’une technologie sans fil et expliquer leur importance. Les critères permettant d’évaluer les différentes technologies sans fil et d’effectuer un choix approprié en fonction du scénario de mise en œuvre sont nombreux. Parmi ceux-ci, nous pouvons citer : - la **portée** du signal radio qui est définie comme la distance possible entre l’émetteur et le récepteur permettant un transfert d’informations. - la **topologie** du réseau qui définit la manière dont les nœuds du réseau sont connectés entre eux. - la **taille** possible du réseau qui définit le nombre de nœuds qui peuvent être connectés simultanément au réseau. - la **standardisation** possible du réseau par un organisme réunissant des acteurs publics ou privés comme l’IEEE (Institute of Electrical and Electronics Engineers) ou l’IETF (Internet Engineering Task Force). - l’**interopérabilité** du réseau permettant aux appareils de différents fabricants de fonctionner dans une même infrastructure et d’opérer dans les infrastructures existantes. #### Nommer les technologies sans fil importantes pour l’Internet des Objets et les systèmes embarqués. La technologie Wi-Fi La technologie Bluetooth La technologie Bluetooth Low Energy La technologie Zigbee Les technologies LPWAN #### Expliquer les caractéristiques importantes de ces technologies et positionner ces caractéristiques sur des diagrammes. | Critère | Wi-Fi | Bluetooth | BLE | Zigbee | Thread | LoRa | NB-IoT | LTE-M | |----------------------------|-----------------------------------|------------------------------------|---------------------------------------|------------------------------------------|---------------------------------------|-----------------------------------|--------------------------------|--------------------------------| | Débit | &lt;&nbsp;72 Mbps | &lt;&nbsp;3&nbsp;Mbps | &lt;&nbsp;2&nbsp;Mbps | &lt;&nbsp;250&nbsp;kbps | &lt;&nbsp;250&nbsp;kbps | &lt;&nbsp;22&nbsp;kbps | &lt;&nbsp;127&nbsp;kbps | &lt;&nbsp;4&nbsp;Mbps | | Portée | &lt;&nbsp;100&nbsp;m | &lt;&nbsp;10&nbsp;m | &lt;&nbsp;750&nbsp;m | &lt;&nbsp;150&nbsp;m &lt;&nbsp;1&nbsp;km | &lt;&nbsp;100&nbsp;m | &lt;&nbsp;20&nbsp;km | &lt;&nbsp;20&nbsp;km | &lt;&nbsp;20&nbsp;km | | Courant moyen | &lt;&nbsp;1&nbsp;an (batterie AA) | &lt;&nbsp;1&nbsp;an (batterie AAA) | &gt;&nbsp;1&nbsp;an (batterie bouton) | &gt;&nbsp;1&nbsp;an (batterie bouton) | &gt;&nbsp;1&nbsp;an (batterie bouton) | &gt;&nbsp;1&nbsp;an (batterie) | &gt;&nbsp;1&nbsp;an (batterie) | &gt;&nbsp;1&nbsp;an (batterie) | | Courant maximum | &lt;&nbsp;300&nbsp;mA | &lt;&nbsp;30&nbsp;mA | &lt;&nbsp;15&nbsp;mA | &lt;&nbsp;15&nbsp;mA | &lt;&nbsp;15&nbsp;mA | &lt;&nbsp;100&nbsp;mA | &lt;&nbsp;500&nbsp;mA | &lt;&nbsp;500&nbsp;mA | | Topologie | Étoile | Point-à-point | Étoile Maille | Étoile Maille | Étoile Maille | Étoile | Étoile (cellulaire) | Étoile (cellulaire) | | IP réalisé sur le nœud | Oui | Non | Non | Non | Oui | Non | Oui | Oui | | Support sur smartphone | Oui | Oui | Oui | Non | Non | Non | Non | Non | | Infrastructures existantes | Oui (Points d’accès) | Oui (smartphones) | Oui (smartphones) | Non | Non | Oui (réseau citoyen) (opérateurs) | Oui (opérateurs) | Oui (opérateurs) | # Bluetooth Low Energy #### Expliquer les caractéristiques principales de la technologie Bluetooth Low Energy, y compris ses propres avantages et limitations. Afin de pouvoir développer une technologie à basse consommation et bas coût, les concepteurs de la technologie ont tenu compte des points suivants : - La bande de fréquences utilisée devait être sans licence afin de minimiser les coûts. L’utilisation d’une bande de fréquences disponible dans le monde entier est un autre facteur d’économie. Le choix de la bande 2.4 GHz s’imposait donc. - Les coûts de licence de la technologie devaient être aussi faibles que possible. - Réduire la consommation d’énergie contribue à réduire les coûts puisque les besoins en capacité de batterie sont limités. #### Nommer et différencier les différentes configurations de systèmes Bluetooth 4.X. ![](https://i.imgur.com/tBRbw1j.png) #### Expliquer et représenter le « protocol stack » de Bluetooth Low Energy, différencier les différentes couches. ![](https://i.imgur.com/0JSHzmz.png) Comme on peut le voir dans cette figure, la pile est divisée en trois parties bien distinctes : - La couche Application est la couche dans laquelle chaque application BLE est écrite. Aucune architecture particulière n’est fixée par le standard BLE pour cette couche, qui est distincte d’un fabricant à l’autre. - La couche Host inclut parmi d’autres les couches GAP et GATT, qui sont les couches que tout développeur BLE doit connaître en détail. Cette couche contient également la partie Host de la couche HCI (Host Controller Interface) qui est la couche d’interface avec le Controller. - La couche Controller contient bien sûr la couche de liaison et la couche physique, mais aussi la partie Controller de la couche HCI. #### Expliquer la topologie « Broadcasting » et « Connection », y compris les rôles des appareils dans ces topologies. #### Déterminer les topologies adaptées à des cas d’utilisation concrets. Broadcasting : envoi à plusieurs appareils simultanément et petite données Connection : envoi de données à un seul master, canal privé et données plus conséquentes #### Expliquer le mécanisme du frequency hopping utilisé dans la couche physique et les raisons pour la mise en œuvre d’un tel mécanisme. ![](https://i.imgur.com/q1nb2bk.png) #### Représenter la machine d’état de la couche de liaison, y compris les transitions possibles dans les différents rôles. Vite fait : ![](https://i.imgur.com/LHfZOus.png) #### Expliquer la structure générale des packets utilisés dans la couche de liaison. ![](https://i.imgur.com/JNkyoju.png) Avec le standard BLE 4.2, la taille du PDU a également été étendue à 257 octets. Dès la version 4.2, le format 4 du paquet est donc : ![](https://i.imgur.com/9EgvXX6.png) Pour les paquets d’advertising, le PDU a la forme générale 4 : ![](https://i.imgur.com/eqszbwN.png) #### Expliquer le fonctionnement de l’ «advertising» et du «scanning» au niveau de la couche de liaison. ![](https://i.imgur.com/IlpO2bo.png) - plus la valeur d’advertising interval (comprise entre 20 ms et 10.24 s) est grande, moins la consommation du dispositif broadcaster sera importante. Dans le même temps, plus la valeur d’advertising interval sera grande, plus la valeur de scan interval sur le dispositif observer devra être petite, afin d’assurer une réception des données suffisamment bonne. - plus la valeur de scan interval sera petite et la valeur de scan window grande, meilleures seront les chances que l’observer reçoive un paquet émis par le broadcaster. Dans le même temps, la consommation augmentera. ![](https://i.imgur.com/f51rmBK.png) #### Expliquer le principe des connexions et de l’établissement d’une connexion. Le type PDU CONNECT_REQ est le type utilisé par le scanner lorsque celui-ci veut établir une connexion. Ce type de paquets appartient encore à la famille des paquets d’advertising et le format du paquet est le suivant 3 : ![](https://i.imgur.com/Wg5Yrv9.png) Le champ LLData contient les informations permettant de configurer la connexion 3 : ![](https://i.imgur.com/JSyrl22.png) Les informations les plus importantes dans le champ LLData sont : - l’intervalle de connexion, défini comme le temps entre le début de deux événements de connexion consécutifs. Ce temps est compris dans la plage de 7.5 ms à 4 s. - la slave latency, définie comme le nombre d’événements de connexion qu’un slave peut choisir de manquer sans risquer une déconnexion. - le connection supervision timeout, défini comme le temps maximal entre deux réceptions de paquets valides avant qu’une connexion soit considérée comme perdue. - le hop increment, défini comme le nombre utilisé dans la séquence de hopping que le master et le slave suivront pour toute la durée de la connexion. Le mécanisme de connexion entre un master et un slave est illustré dans la figure 1 ci-dessous : ![](https://i.imgur.com/713sfPz.png) # Protocoles de communication IP #### Expliquer les critères principaux permettant de différencier les technologies de communication basées sur IP. #### Expliquer les caractéristiques principales des protocoles IP présentés dans le cours et leur modèle de communication. #### Savoir sélection un protocole adapté à un cahier des charges simple. # MQTT #### Expliquer l’architecture d’un système MQTT et la manière dont les messages sont échangés. ![](https://i.imgur.com/cCP9de1.png) ![](https://i.imgur.com/hGeYitR.png) #### Expliquer le concept des topics et l’appliquer à un cas simple. Les topics permettent d’organiser les messages dans MQTT. Lorsqu’un client publie un message, il l’associe à un topic. C’est un peu comme une clé ou un URI qui donne une identité au message. #### Connaitre les différentes options de QoS et les options de élémentaires disponibles. MQTT définit 3 niveaux de qualité de service - Niveau 0 (At most once) : Le client envoie le message, mais le broker ne quittance pas la réception et il n’y a aucune garantie que le broker a bien reçu le message. Vous pouvez utiliser ce niveau si la perte d’un message n’a pas vraiment d’importance pour votre système. Par exemple, pour une station météo qui envoie la température toutes les 10 secondes, on peut sans problème tolérer la perte d’un paquet. - Niveau 1 (At least once) : Cette fois le broker quittance la réception du message, mais si cette quittance est perdue, alors le client décide de renvoyer le message une seconde fois. On est donc sûr que le message a bien été reçu par le broker, mais il se peut que les abonnées reçoivent plusieurs fois ce message. Pour la plupart des applications, le niveau 1 est le niveau de QoS recommandé. - Niveau 2 (Exactly once) : Dans de rares cas où on doit être sûr que le broker reçoive tous les messages et qu’on ne peut pas tolérer des duplicatas, alors on utilise le niveau 2. Dans ce niveau, les échanges sont plus compliqués, plus lents, et consomment plus de bande passante. # CoAP #### Expliquer l’architecture d’un système CoAP et la manière dont les messages sont échangés. ![](https://i.imgur.com/gbQEsbf.png) Le protocole CoAP a donc été réalisé en respectant les exigences suivantes : - permettre le scale up en respectant les principes RESTful. - être compact et permettre un décodage/encodage de faible complexité. - réaliser un comportement adéquat dans le cas de liens de communication avec pertes. - réaliser les mécanismes de découverte et de communication bi-directionnelle. Pour rappel, les principes RESTful signifient : - une architecture client-serveur permettant le caching et le proxying. - des ressources adressables par des URI. - une réalisation stateless (le serveur ne sauvegarde pas l’état du client). - l’utilisation des Internet Media Types pour représenter les ressources #### Expliquer les différences importantes en comparaison du protocole HTTP/1.1. La réponse peut se résumer aux éléments suivants : - Le protocole HTTP n’est pas approprié aux dispositifs à ressources limitées, car il est un protocole basé texte qui requiert beaucoup de mémoire pour l’encodage et le décodage et utilise de la bande passante inutilement sur les réseaux basse consommation. - Il est basé sur la couche de transport TCP, qui est connu pour un comportement problématique sur les réseaux sans fil avec pertes 1. - Il ne réalise pas certains mécanismes importants pour les scénarios du Web of Things, comme la communication bi-directionnelle ou la découverte des ressources ou des dispositifs. Un protocole proposant une approche similaire à HTTP mais résolvant les problèmes mentionnés ci-dessus doit donc : - permettre un scale down pour une réalisation sur des appareils à ressources limitées. - permettre un scale up pour un fonctionnement avec des milliards d’appareils connectés. #### Connaître le rôle et le fonctionnement des deux sous-couches de protocole Coap. ##### Message La sous-couche Message est responsable de la retransmission et de la déduplication des messages. Pour ce faire, le standard définit 4 types de messages différents : - Les messages de type CON (Confirmable Message): le message est retransmis jusqu’à ce que le destinataire confirme sa réception ou jusqu’à l’atteinte d’un timeout. - Les messages de type ACK (Acknowledgement Message) : le message confirmant la réception d’un message de type CON. Ce message doit utiliser le même MID que le message CON correspondant. Il peut également être piggybacked et contenir le contenu de la réponse au message CON. - Les messages de type NON (Non-confirmable Message) : le message est délivré une seule fois. Les réponses à une requête de type NON peuvent être des messages de type NON ou CON. - Les messages de type RST (Reset Message) : le message signale une erreur de traitement d’un message reçu de type CON ou NON. ##### Request/Reponse La sous-couche Request/Response réalise une architecture RESTful et partage les mêmes bases que HTTP/1.1. Les messages CoAP contiennent tous un code, qui représente une méthode pour une requête et un statut pour une réponse. L’ensemble des codes de méthode est un sous-ensemble de 4 méthodes définies également par HTTP/1.1 : GET, PUT, POST, et DELETE. La sémantique est la même et cette similitude permet de construire facilement un mapping de et vers HTTP. Dans la sous-couche Request/Response, la correspondance entre une requête et une réponse est effectuée au moyen du token et non du MID (qui est lui utilisé par la sous-couche Message). Cela signifie que dans une réponse piggybacked, les MID et les token du message de requête CON et du message de réponse ACK doivent correspondre. Dans une réponse séparée, les token de la requête et de la réponse doivent correspondre. # Mémoire des systèmes embarqués #### Connaitre l’utilisation des différents espaces mémoire d’un microcontrôleur en C/C++ et sous Mbed OS. ![](https://i.imgur.com/z4zGB3Y.png) ![](https://i.imgur.com/g2xJ6qi.png) Nous trouvons en mémoire ROM: - la table des vecteurs (ro), - le code de l’application, - les données de l’application, - en option le ‘bootloader’. Nous trouvons en mémoire RAM: - Les éléments statiques du programme: - une table de vecteurs (rw), - une zone de récupération de données en cas de crash expliquée dans le traitement des erreurs de Mbed OS, - les données globales et statiques du programme, - les piles pour les threads globaux (main, timer, idle, scheduler, ISR). - Les éléments en zone dynamique: - le tas (heap) pour les allocations dynamiques, - les piles (stack) associées à chaque thread utilisateur. Mbed OS alloue dynamiquement une nouvelle pile (stack) sur le tas (heap) pour chaque nouveau thread. #### Connaître les différents modes de démarrage du processeur. Nous disposons de plusieurs modes de démarrage (boot) sur les processeurs. Ceci nous permet de résoudre plusieurs problématiques : - le démarrage ‘normal’ du programme déjà chargé en mémoire, le mode par défaut, simple et rapide usuel des systèmes embarqués, - le démarrage sur un ‘chargeur de programme’ (bootloader) qui permet de charger un nouveau programme sur le système via un port de communication (UART, SPI, USB, LAN, etc.), - le démarrage en mode ‘développeur’ pour faire du déverminage de code (debugging) en mémoire. | Boot1 | Boot0 | Mode | Commentaire | |-------|-------|----------------|----------------------------------------------------------| | X | 0 | Flash Memory | La mémoire Flash utilisateur est liée à l’espace de Boot | | 1 | 0 | Système Memory | La mémoire Système est liée à l’espace de Boot | | 1 | 1 | Embedded SRAM | La mémoire SRAM est liée à l’espace de Boot | #### Décrire l’utilité du MPU et son fonctionnement sous Mbed OS. La protection mémoire avec la MPU sous Mbed OS: - protège de l’exécution de code en RAM, - protège de l’écriture en ROM. Mbed OS gère automatiquement la MPU dans les situations suivantes: - la protection mémoire est activée au démarrage (séquence de boot), - la protection mémoire est désactivée au démarrage d’une nouvelle application, - la protection mémoire est désactivée pour permettre la programmation en mémoire flash. # Langage de développement C/C++ #### Manipuler correctement les types de base de C/C++. #### Manipuler correctement les concepts static, const et constexpr. #### Coder des déclarations et des réalisations de classes simples en C++, en mettant en œuvre des mécanismes simples d’héritage, de méthodes (pure) virtual et d’interfaces. #### Être capable de définir et d’initialiser correctement les attributs d’une classe pour une spécification donnée. #### Analyser un programme C++ pour décrire son comportement et corriger d’éventuelles erreurs/défauts.