move medias

infotro/Eln/ADDA.md

@@ -19,20 +19,20 @@ Il existe 4 méthodes principales pour une conversion Analogique vers Digital:
 
 ## Parallèle
 
-![AD Parallèle](parallele.png ':size=200')
+![AD Parallèle](medias/parallele.png ':size=200')
 
 ## Par comptage
 Un seul switch mais avec une fréquence de commutation très rapide  
 $$
 V_{a} = \frac{t_{on}}{T}\cdot V_{ref}
 $$
-![AD par comptage](comptage.png ':size=300')
+![AD par comptage](medias/comptage.png ':size=300')
-![Graph AD par comptage](comptage-graph.png ':size=200')
+![Graph AD par comptage](medias/comptage-graph.png ':size=200')
 
 ## Par pesée
 Un switch par bit.
 
-![AD par pesée](pesee.png ':size=300')
+![AD par pesée](medias/pesee.png ':size=300')
 
 Pour un $V_{red} = 1[V]$ on a:
 

infotro/Eln/Sigma-Delta.md

@@ -2,7 +2,7 @@
   <h1>Sigma / Delta</h1>
 </header>
 
-[sigma-delta.drawio](sigma-delta.drawio ':include :type=code')
+[sigma-delta.drawio](medias/sigma-delta.drawio ':include :type=code')
 
 
 # Principe
@@ -75,4 +75,4 @@ précision.
 cccccckrhltvbdnvjilbnrchidectlggreetcdrehlet
 
 
-![img.png](snr_by_osr.png)
+![img.png](medias/snr_by_osr.png)

infotro/PTR/RealTime.md

@@ -64,7 +64,7 @@ Le timing des tâches cycliques est planifié précisément.
 Ces dernières sont synchronisées (démarrées) par un signal d'une horloge.
 La scéquence des tâches est déterminé à l'avance
 Le temps cumulée de l'execution des tâches ne doit pas dépasser le temps d'un cycle.
-![Programmation synchrone](system_synchron.png)
+![Programmation synchrone](medias/system_synchron.png)
 
 <u>*Avantages*</u><br>
 - Timing précis
@@ -80,7 +80,7 @@ Le timing des tâches est contrôlé soit par un RTOS soit par un XF.
 Les tâches sont contrôlées par des événements et des appels de méthodes.
 Des tâches parallèles sont sérialisées.
 Le séquencement des tâches n'est pas déterminé.
-![Programmation asynchrone](system_asynchron.png)
+![Programmation asynchrone](medias/system_asynchron.png)
 
 <u>Avantages</u><br>
 - Flexibilité face aux changements de spécification du système.

infotro/README.md

@@ -21,3 +21,23 @@
 - [PLA - Programmation en langage assembleur](/infotro/SEm/PLA.md)
 - [ASM - Assembleur ARM](/infotro/SEm/ASM.md)
 
+
+# TODOs
+- [ ] PTR - add layer diagram in RTOS
+- [ ] PTR - redesign picture "system_asynchron.png"
+- [ ] PTR - redesign picture "system_synchron.png"
+
+- [ ] SDi - add pictures for transmission process
+- [ ] SDi - redesign picture "coap_example.png"
+- [ ] SDi - redesign picture "coap_overview.png"
+- [ ] SDi - redesign picture "http_notifications.png"
+- [ ] SDi - redesign picture "http_reminder.png"
+- [ ] SDi - redesign picture "json_syntaxe.png"
+- [ ] SDi - redesign picture "qos_mqtt.png"
+- [ ] SDi - redesign picture "xml_example.png"
+
+- [ ] Eln - redesign picture "comptage.png"
+- [ ] Eln - redesign picture "comptage-graph.png"
+- [ ] Eln - redesign picture "parallele.png"
+- [ ] Eln - redesign picture "pesee.png"
+- [ ] Eln - redesign picture "ssnr_by_osr.png"

infotro/SDi/iot_technologies.md

@@ -101,7 +101,7 @@ La validité d'un document XML peut être vérifiée en le comparant à un sché
 </disco>
 ```
 
-![xml_example.png](xml_example.png)
+![xml_example.png](medias/xml_example.png)
 
 </details>
 
@@ -173,13 +173,13 @@ et traitable dans de nombreux langages de programmation.
 }
 ```
 
-![xml_example.png](xml_example.png)
+![xml_example.png](medias/xml_example.png)
 
 </details>
 
 ***Syntaxe***
 
-![json_syntaxe.png](json_syntaxe.png)
+![json_syntaxe.png](medias/json_syntaxe.png)
 
 En résumé, JSON offre une syntaxe simple et lisible pour représenter des données structurées, favorisant
 l'interopérabilité entre différentes plates-formes et langages.
@@ -280,7 +280,7 @@ Les ressources peuvent avoir différentes représentations, telles que HTML, JSO
 Les clients spécifient les formats acceptables via l'en-tête "Accept", tandis que les serveurs déclarent le format de
 la réponse avec "Content-Type".
 
-![http_reminder.png](http_reminder.png)
+![http_reminder.png](medias/http_reminder.png)
 
 | Satus codes | Description                  |
 | --- |------------------------------|
@@ -291,7 +291,7 @@ la réponse avec "Content-Type".
 | 5xx | Server Error                 |
 
 ### Méthodes de notification serveur
-![http_notifications.png](http_notifications.png)
+![http_notifications.png](medias/http_notifications.png)
 
 #### Long polling
 Le long polling, ou long polling HTTP, est une technique de communication asynchrone utilisée dans le développement web
@@ -477,9 +477,9 @@ et à faible bande passante, comme les capteurs, les actionneurs et les microcon
 Il est conçu pour être simple et léger, avec un faible encombrement mémoire et une faible utilisation de la bande passante.
 CoAP est basé sur le protocole UDP et utilise le format de message binaire de HTTP.
 
-![coap_overview.png](coap_overview.png)
+![coap_overview.png](medias/coap_overview.png)
 
-![coap_example.png](coap_example.png)
+![coap_example.png](medias/coap_example.png)
 
 # MQTT
 MQTT (Message Queuing Telemetry Transport) est un protocol de transport de messages léger et ouvert, conçu pour les
@@ -510,12 +510,12 @@ ressources limitées.
 
 - **Niveaux de Qualité de Service (QoS) :** Propose trois niveaux de QoS, permettant de gérer la fiabilité de la
 livraison des messages en fonction des besoins de l'application.
-    - QoS 0: "At most once" (au plus une fois) : Le message est envoyé une seule fois, sans garantie de livraison.
+    - QoS 0 : "At most once" (au plus une fois) : Le message est envoyé une seule fois, sans garantie de livraison.
-    - QoS 1: "At least once" (au moins une fois) : Le message est envoyé au moins une fois, garantissant la livraison,
+    - QoS 1 : "At least once" (au moins une fois) : Le message est envoyé au moins une fois, garantissant la livraison,
     mais permettant les doublons.
-    - QoS 2: "Exactly once" (exactement une fois) : Le message est envoyé exactement une fois, garantissant la livraison,
+    - QoS 2 : "Exactly once" (exactement une fois) : Le message est envoyé exactement une fois, garantissant la livraison,
     sans doublons.
-  ![qos_mqtt.png](qos_mqtt.png)
+  ![qos_mqtt.png](medias/qos_mqtt.png)
 
 - **Sessions Persistantes :** Les sessions persistantes conservent les abonnements et les files d'attente même après
 la déconnexion, assurant la continuité du traitement des messages.
@@ -525,17 +525,17 @@ par exemple, pour assurer l'interopérabilité entre différentes technologies d
 
 ## Fonctionnalités MQTT
 - **Retained Messages :**
-Les messages MQTT peuvent être conservés par le courtier et envoyés aux nouveaux abonnés.
+Les messages MQTT peuvent être conservés par le broker et envoyés aux nouveaux abonnés.
 Cela permet aux abonnés de recevoir les dernières informations sans avoir besoin d'attendre la prochaine mise à jour.
 
-- **Last Will and Testament (LWT) :**
-Les clients peuvent définir un message LWT qui sera publié par le courtier si le client se déconnecte de manière inattendue.
-Cela permet aux clients de signaler leur état aux autres clients.
-
 - **Keep Alive :**
-Les clients peuvent envoyer des messages de ping au courtier pour maintenir la connexion active.
+Les clients peuvent envoyer des messages de ping au broker pour maintenir la connexion active.
 Cela permet de détecter les connexions perdues et de les rétablir.
 
+- **Last Will and Testament (LWT) :**
+Les clients peuvent définir un message LWT qui sera publié par le broker si le client se déconnecte de manière inattendue.
+Cela permet aux clients de signaler leur état aux autres clients.
+
 - **Sécurité :**
 MQTT prend en charge le chiffrement TLS pour sécuriser les communications.
 Il prend également en charge l'authentification par nom d'utilisateur et mot de passe.