Updates from Overleaf

KevinJordil · Aug 10, 2023 · 63b036f · 63b036f
1 parent e923830
commit 63b036f
Show file tree

Hide file tree

Showing 4 changed files with 10 additions and 6 deletions.
diff --git a/sections/analysis.tex b/sections/analysis.tex
@@ -48,7 +48,10 @@ \subsection{SPI}
 
 \subsection{CAN}
 
-Le bus CAN possède une vitesse intéressante par rapport aux autres bus de communication. Cependant, lorsqu'un composant fonctionne avec CAN, il utilise CANOpen. CANOpen est complexe à mettre en place. De plus la majorité des microcontrôleurs qui possède un contrôleur CAN doivent être connecté à un transceiver CAN qui est un autre composant. Ce bus n'est donc pas adapté à ce projet.
+Le bus CAN possède une vitesse intéressante par rapport aux autres bus de communication.
+Cependant, lorsqu'un composant fonctionne avec CAN, il utilise CANOpen. CANOpen est complexe à mettre en place.
+De plus la majorité des microcontrôleurs qui possède un contrôleur CAN doivent être connectés à un transceiver CAN qui est un autre composant.
+Ce bus n'est donc pas adapté à ce projet.
 
 \subsection{I2C}
 
@@ -383,7 +386,7 @@ \subsection{Objectifs}
 
 \subsection{Fonctionnement}
 
-L'utilisation de GitHub pour mettre en place le système de CI/CD est pertinente en raison de sa vaste communauté et des nombreux paquets disponibles pour automatiser diverses tâches.
+L'utilisation de GitHub pour mettre en place le système de CI/CD est pertinente en raison de sa vaste communauté et des nombreux outils disponibles pour automatiser diverses tâches.
 Le processus comporte deux étapes principales.
 
 Dans un premier temps, l'objectif est de compiler le code afin de générer le fichier binaire du micrologiciel, qui pourra ensuite être téléversé sur un microcontrôleur.

diff --git a/sections/appendices/source_code.tex b/sections/appendices/source_code.tex
@@ -2,6 +2,7 @@
 Ils ont été rendus accessibles au public via une organisation Github.
 L'ensemble des ressources techniques du projet peut être trouvé à l'adresse suivante : \url{https://github.com/I2C-Framework}.
 Cette organisation se compose de quatre dépôts principaux, contenant des informations essentielles pour comprendre et utiliser l'écosystème développé dans le cadre de ce projet.
+Un tag a été généré pour chaque dépôt, symbolisant le code développé durant le travail de bachelor.
 
 \section{Chargeur de démarrage}
 
@@ -15,7 +16,8 @@ \section{Micrologiciel}
 Le dépôt \textit{slave\_basic\_firmware} contient le micrologiciel de base, intégrant toute la gestion de l'écosystème.
 Pour adapter ce micrologiciel, il suffit de créer une copie de ce dépôt en effectuant un \textit{fork}.
 Ensuite, il est possible d'adapter le fichier principal pour créer une nouvelle application.
-Des fonctions sont disponibles pour générer des réponses sur le bus de l'écosystème avec ses propres numéros de registres et ses fonctions de retour.
+Des fonctions sont disponibles pour générer des réponses sur le bus de l'écosystème avec ses propres numéros de registres et ses fonctions de retour.+
+Le numéro de commit au moment du rendu est 20a43d3
 
 \section{Outils du maître I2C}
 

diff --git a/sections/implementation.tex b/sections/implementation.tex
@@ -9,7 +9,7 @@ \section{Matériel}
 Dans ce cas, un Raspberry Pi modèle 3 a été utilisé.
 Il est possible d'utiliser une autre carte, à condition qu'elle permette d'installer un système d'exploitation capable d'exécuter du code Python.
 De plus, il est important d'avoir une connexion \gls{i2c} disponible.
-Dans ce projet, le Raspberry Pi est équipé de Raspbian.
+Dans ce projet, le Raspberry Pi est équipé de \textit{Raspberry Pi OS}.
 
 Ensuite, des cartes de développement sont nécessaires pour tester rapidement le code.
 STMicroelectronics fournit une gamme de cartes Nucleo équipées de microcontrôleurs STM32.
@@ -63,7 +63,6 @@ \section{Mise à jour du micrologiciel}
 La première méthode consiste à télécharger le nouveau micrologiciel à partir de l'application exécutée par le microcontrôleur.
 Cela nécessite que le microcontrôleur dispose d'une quantité suffisante de mémoire pour stocker les deux micrologiciels.
 Ainsi au redémarrage, le chargeur de démarrage remplace l'ancien micrologiciel par le nouveau.
-Cependant, cette méthode nécessite une capacité de mémoire plus importante, car elle nécessite le stockage des deux micrologiciels.
 
 La deuxième méthode consiste à aller dans le chargeur de démarrage pour effectuer la mise à jour.
 Dans ce mode, le microcontrôleur est capable de recevoir le nouveau micrologiciel et de le programmer en mémoire.

diff --git a/sections/improvements.tex b/sections/improvements.tex
@@ -44,7 +44,7 @@ \section{Interruption I2C}
 Cela est une mauvaise pratique, car d'autres interruptions pourraient être bloquées.
 Une approche plus appropriée consisterait à démarrer un processus lors de l'interruption, qui se chargerait de traiter toutes les opérations \gls{i2c} nécessaires.
 Cette approche permettrait de quitter rapidement l'interruption \gls{i2c} tout en effectuant des traitements plus complexes en parallèle.
-Mbed offre une gestion simplifiée des processus, ce qui rend cette mise en œuvre réalisable.
+Mbed offre une gestion simplifiée des processus, ce qui rend cette mise en \oe{}uvre réalisable.
 
 De plus, le microcontrôleur choisi possède une fonctionnalité intéressante.
 Sur le bus \gls{i2c} 1, il est possible de réveiller le microcontrôleur. Si le microcontrôleur est en veille et qu'une connexion \gls{i2c} démarre, il peut sortir de veille automatiquement.