cosmetics master
authorPaul Kocialkowski <contact@paulk.fr>
Mon, 18 May 2015 18:25:18 +0000 (20:25 +0200)
committerPaul Kocialkowski <contact@paulk.fr>
Mon, 18 May 2015 18:25:18 +0000 (20:25 +0200)
aspects-informatique.tex
references.tex

index 1bab8ae..371e0fa 100644 (file)
@@ -118,7 +118,7 @@ Afin de réaliser l'expérience, nous avons modifié le code source (écrit en l
 
 Une fois les aspects matériels et logiciels en place, on peut commencer la réalisation du programme propre à l'Arduino. Celui-ci sera réalisé en langage C natif, c'est à dire sans sur-couche propre à l'Arduino. Il existe en effet un IDE\notetraduction{Integrated Development Environment}{environnement de développement intégré} propre à l'Arduino, contenant un certain nombre de sur-couches au langage C++ utilisé. Comme notre application est fortement dépendante du temps, on cherchera à écrire du code au plus proche du langage machine afin de ne pas ralentir l'exécution. Le système de compilation sera basé sur de traditionnels $Makefiles$, très couramment utilisés pour le développement au sein de systèmes de type \bsc{Unix}. Le compilateur utilisé est une variante de \bsc{GCC} propre à l'architecture matérielle \bsc{AVR} : \bsc{avr-gcc}. On utilisera une librairie C standard propre à l'\bsc{AVR}, qui fournit également des définitions propres au microcontrôleur : l'\bsc{avr-libc}. De plus, le logiciel sera envoyé sur la carte en utilisant l'utilitaire \bsc{avrdude}. Enfin, on utilisera l'outil de gestion de code source \bsc{git} pour garder trace des modifications. Tous ces logiciels sont des logiciels libres et on donne d'ailleurs comme licence d'utilisation à notre logiciel, astucieusement nommé $ardui2c$, la Licence Publique Générale GNU en version 3 ou plus récente\footnote{Texte complet de la licence : \url{https://www.gnu.org/licenses/gpl.html}.}, ce qui en fait également un logiciel libre.\\
 
-Le code source lui-même est rédigé avec une terminologie (noms des fonctions, des variables) en Anglais, afin qu'il soit techniquement compréhensible (et modifiable) par le plus grand nombre, mais on attache tout de même des commentaires en Français, afin de faciliter sa compréhension dans le cadre de notre projet. Afin d'analyser l'exécution étape par étape du programme au cours de son écriture, on cherche à utiliser un dispositif d'entrée/sortie simple à utiliser. L'Arduino dispose d'un contrôleur UART permettant d'envoyer au cours de l'exécution des informations de débogage (typiquement, des chaînes de caractères) à un ordinateur relié à la carte par USB (un convertisseur UART/USB est déjà intégré à la carte Arduino). Cependant, la vitesse de transmission des informations est au maximum de $115200$ bits/s (on parle de bauds), qui n'est pas suffisante pour transmettre suffisamment rapidement ces informations tout en relevant les changements des lignes du bus. En effet, une première expérience montre que le microcontrôleur n'arrive pas à correctement détecter les changements d'états de la ligne d'horloge, qui a une fréquence que l'on a fixée à $50$ kHz, soit $2 * 50 000 = 100 000$ changements d'état logique par seconde. Il est donc évident que cette solution n'est pas utilisable.\\
+Le code source lui-même est rédigé avec une terminologie (noms des fonctions, des variables) en Anglais, afin qu'il soit techniquement compréhensible (et modifiable) par le plus grand nombre, mais on attache tout de même des commentaires en Français, afin de faciliter sa compréhension dans le cadre de notre projet. Afin d'analyser l'exécution étape par étape du programme au cours de son écriture, on cherche à utiliser un dispositif d'entrée/sortie simple à utiliser. L'Arduino dispose d'un contrôleur UART permettant d'envoyer au cours de l'exécution des informations de débogage (typiquement, des chaînes de caractères) à un ordinateur relié à la carte par USB (un convertisseur UART/USB est déjà intégré à la carte Arduino). Cependant, la vitesse de transmission des informations est au maximum de $115200$ bits/s (on parle de bauds), qui n'est pas suffisante pour transmettre suffisamment rapidement ces informations tout en relevant les changements des lignes du bus. En effet, une première expérience montre que le microcontrôleur n'arrive pas à correctement détecter les changements d'états de la ligne d'horloge, qui a une fréquence que l'on a fixée à $50$ kHz, soit $2 \cdot 50 000 = 100 000$ changements d'état logique par seconde. Il est donc évident que cette solution n'est pas utilisable.\\
 
 Pour palier à ce problème, on a utilisé une sortie numérique du microcontrôleur que l'on dédie au débogage ($DEBUG$) et dont on inversera l'état logique à un moment donné de l'exécution du programme (par exemple à la détection d'un événement en particulier). Il s'agit de la fonction $debug$, que l'on appellera avec un test que l'on souhaite vérifier à l'exécution. Certains événements, tels que les conditions de départ ou de fin ont ainsi pu être détectés, mais on remarque un décalage entre la fin des événements et l'apparition du changement sur la ligne de débogage. L'optimisation du code produit lors de la compilation (argument $-Os$ du compilateur \bsc{avr-gcc}) permet de gagner en temps d'exécution (moins d'instructions à exécuter) et donc de rapprocher le changement d'état de la ligne de débogage de l'événement. On utilise encore une fois l'analyseur logique pour relever l'état des lignes $SDA$, $SCL$ et $DEBUG$.\\
 
index 8d89342..325fc6e 100644 (file)
@@ -11,7 +11,7 @@
 
 Les cours suivants auxquels nous avons assisté ont permis d'assimiler de nombreuses notions retranscrites au travers de ce document :
 \begin{itemize}
-\item[--] Cours de Génie Électronique 2011-2013, J-P. Feuray, Lycée Max Linder
+\item[--] Cours de Génie Électronique, J-P. Feuray, Lycée Max Linder de Libourne
 \item[--] Cours d'Électromagnétisme 1, J. Cayssol, Cycle Prépératoire de Bordeaux
 \item[--] Cours d'Électrocinétique 1, M. Aiche, Cycle Prépératoire de Bordeaux
 \item[--] Cours d'Électromagnétisme 2, P. Langot, Cycle Prépératoire de Bordeaux