384 lines
22 KiB
TeX
384 lines
22 KiB
TeX
\documentclass{scrreprt}
|
||
%\documentclass[draft]{scrreprt}
|
||
\usepackage{fontspec}
|
||
\usepackage{xunicode}
|
||
\usepackage{polyglossia}
|
||
\usepackage{csquotes}
|
||
\usepackage{caption}
|
||
\usepackage{subcaption}
|
||
\usepackage{appendix}
|
||
\usepackage{color}
|
||
\usepackage{minted}
|
||
\usepackage[singletitle=true,citestyle=verbose-trad2,bibstyle=verbose,backend=biber,citepages=omit]{biblatex}
|
||
\usepackage[hidelinks]{hyperref}
|
||
\usepackage[acronym,toc,xindy]{glossaries}
|
||
\usepackage{glossary-list}
|
||
|
||
\setmainlanguage{french}
|
||
|
||
\title{La lumière s'éteint-elle dans le frigo ?}
|
||
\subtitle{ou bla bli blu}
|
||
\author{Nathanaël \textsc{Restori}}
|
||
\date{\today}
|
||
|
||
\bibliography{bibliographie.bib}
|
||
|
||
\renewcommand*{\glstextformat}{\textbf}
|
||
\makeglossaries
|
||
\input{glossaire.tex}
|
||
|
||
\renewcommand{\appendixname}{Annexes}
|
||
\renewcommand{\appendixtocname}{Annexes}
|
||
\renewcommand{\appendixpagename}{Annexes}
|
||
|
||
\begin{document}
|
||
|
||
\input{couverture.tex}
|
||
|
||
\chapter*{Remerciements}
|
||
\thispagestyle{empty}
|
||
Je remercie bla bla bla...
|
||
\vfill
|
||
Image de couverture par \enquote{oomlout}, sous licence \emph{Creative Commons Attribution-Share Alike 2.0 Generic (CC BY-SA 2.0)}.
|
||
|
||
\tableofcontents
|
||
|
||
\chapter{Introduction}
|
||
\section{Motivations}
|
||
J'ai décidé de faire mon travaille de maturité sur ce sujet car je suis passionné de robotique depuis tout petit. J'ai commencé en participant à un atelier de soudures à la Maison Picson\footnote{Établissement servant de cantine proposant aussi des activités à Blonay}. Je suis aussi allé à la première édition du Festival de Robotique à l'EPFL en 2008 et ai participé à deux ateliers (introduction à la programmation de microcontrôleur et soudure d'un robot DIDEL).
|
||
|
||
Je suis aussi passionné par l'informatique en général, la programmation ainsi que les logiciels libres.
|
||
|
||
\section{Présentation du travail}
|
||
TODO
|
||
|
||
\section{Les principes du logiciel libre}
|
||
Un logiciel libre est un logiciel qui respecte quatre libertés essentielles\footcite{free-sw}~:
|
||
\begin{enumerate}
|
||
\item la liberté d'exécuter le programme, pour tous les usages (liberté 0) ;
|
||
\item la liberté d'étudier le fonctionnement du programme, et de le modifier pour qu'il effectue vos tâches informatiques comme vous le souhaitez (liberté 1) ; l'accès au code source est une condition nécessaire ;
|
||
\item la liberté de redistribuer des copies, donc d'aider votre voisin (liberté 2) ;
|
||
\item la liberté de distribuer aux autres des copies de vos versions modifiées (liberté 3) ; en faisant cela, vous donnez à toute la communauté une possibilité de profiter de vos changements ; l'accès au code source est une condition nécessaire.
|
||
\end{enumerate}
|
||
|
||
On retrouve aussi le terme \enquote{\emph{open source}}. Le terme logiciel libre est définit par la \gls{FSF} tandis que le terme open source est définit par l'\gls{OSI}. En pratique, ces deux termes désignent la même chose.
|
||
|
||
Les sources du logiciels sont soumis à des licences spécifiques garantissant ces libertés. Les plus connues sont la \gls{GPL}, la \gls{BSD} ou la MIT (une copie de cette dernière est disponible à l'annexe \ref{app:mit}).
|
||
|
||
Quelques logiciels libres connus sont Firefox, LibreOffice/OpenOffice.org, Linux, Thunderbird et VLC.
|
||
|
||
Ce \gls{TM} est donc entièrement articulé autour de logiciels et matériels libres : \LaTeX et vim pour l'écriture de ce rapport, Arduino comme plate-forme, CMake et gcc pour la \gls{compilation}, gnuplot pour les graphiques. Tout le code produit est donc placé sous licence MIT.
|
||
|
||
\section{Conventions d'écriture}
|
||
Les mots en \textbf{gras} sont des mots expliqués dans le glossaire ou des acronymes.
|
||
|
||
Les textes écrits avec \verb|cette police d'écriture| sont des extraits de code.
|
||
|
||
\chapter{L'I²C}
|
||
\section{Le bus I²C}
|
||
Le bus l'I²C a été développé par Philips en 1982. La première norme (notée 1.0) a été publiée en 1992 et la dernière (noté 4.0) en 2012.
|
||
|
||
\section{Les caractéristiques}
|
||
L'I²C a plusieurs caractéristiques intéressantes :
|
||
\begin{itemize}
|
||
\item il n'utilise que deux lignes (en réalité trois, la masse devant être commune à tous les maîtres et les esclaves)
|
||
\item il est multi-maîtres : plusieurs objets peuvent contrôler le bus
|
||
\item il est multi-esclaves : plusieurs objets peuvent répondre à un maître
|
||
\item c'est un bus série : chaque information est découpée en plusieurs morceaux de taille fixe
|
||
\item c'est un bus synchrone : possède une horloge propre (imposée par les maître qui veux parler)
|
||
\item c'est un bus bidirectionnel half-duplex : les informations peuvent circuler dans les deux sens mais dans un seul sens à la fois
|
||
\item il peux communiquer à des vitesses allant de 100 kbit/s à 5 Mbit/s
|
||
\end{itemize}
|
||
|
||
\section{Topologie}
|
||
Tout d'abord, plusieurs équipements peuvent être connectés au bus en même temps (qu'ils soient maîtres ou esclaves).
|
||
|
||
Les équipement sont connectés entre eux à l'aide de deux lignes :
|
||
\begin{itemize}
|
||
\item SDA (Serial Data Line) : ligne de données bidirectionnelle,
|
||
\item SCL (Serial Clock Line) : ligne d'horloge de synchronisation bidirectionnelle
|
||
\end{itemize}
|
||
Il faut toute fois une troisième ligne pour avoir une masse commune à tous les équipements.
|
||
Tous les équipements doivent être alimentés avec le même potentiel (pour avoir la même référence comme niveau haut) mais peuvent être alimentés par différentes sources.
|
||
|
||
Les échanges ont toujours lieu entre un maître et un esclave et sont toujours débutés par le maître. Toute fois, rien n'empêche à un équipement de passer du status de maître au status d'esclave et vice-versa.
|
||
|
||
L'état logique \enquote{0} ou \enquote{LOW} est l'état \enquote{dominant} tandis que l'état logique \enquote{1} ou \enquote{HIGH} est l'état \enquote{récessif}. Cela veux dire que si un équipement impose l'état \enquote{LOW} et qu'un autre impose l'état \enquote{HIGH} la ligne sera à l'état LOW.
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/I2C/I2C_Architecture.eps}
|
||
\caption{Architecture I²C avec plusieurs maîtres et plusieurs esclaves}
|
||
\label{fig:I2C_Architecture}
|
||
\end{figure}
|
||
|
||
\section{Le protocole I²C}
|
||
Toutes les images ont été faites par \enquote{Emiaille} et sont sous licence \emph{Creative Commons paternité – partage à l’identique 3.0 (non transposée)}.
|
||
|
||
\subsection{L'encodage}
|
||
Pour transmettre un bit, le maître doit d'abord placer la ligne SCL au niveau \enquote{LOW} puis placer la ligne SDA au niveau voulu (LOW pour transmettre un 1 ou \enquote{HIGH} pour transmettre un 0). Ensuite, il place la ligne SCL au niveau \enquote{HIGH} attend un temps défini par la vitesse et la norme utilisée puis replace la ligne SCL au niveau LOW. Un bit vient d'être transmis. Il recommence pour transmettre le bit suivant. Tant que la ligne SCL est au niveau \enquote{HIGH} la ligne SDA ne doit pas changer d'état.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_Encodage.eps}
|
||
\caption{Encodage d'un bit I²C}
|
||
\label{fig:I2C_Encodage}
|
||
\end{figure}
|
||
|
||
\subsection{La commande START}
|
||
La commande START est un transgression à la règle d'encodage. Elle est utilisé pour signaler le début d'une trame.
|
||
Pour envoyer un START, la ligne SDA doit passer de l'état \enquote{HIGH} à \enquote{LOW} pendant que la ligne SCL est à l'état \enquote{HIGH}.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_START.eps}
|
||
\caption{Condition de START I²C}
|
||
\label{fig:I2C_START}
|
||
\end{figure}
|
||
|
||
\subsection{La commande STOP}
|
||
La commande STOP est un transgression à la règle d'encodage. Elle est utilisé pour signaler la fin d'une trame.
|
||
Pour envoyer un STOP, la ligne SDA doit passer de l'état \enquote{LOW} à \enquote{HIGH} pendant que la ligne SCL est à l'état \enquote{HIGH}.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_STOP.eps}
|
||
\caption{Condition de STOP I²C}
|
||
\label{fig:I2C_STOP}
|
||
\end{figure}
|
||
|
||
\subsection{La commande RESTART}
|
||
La commande RESTART est un transgression à la règle d'encodage. Elle est utilisé pour signaler le début d'une nouvelle trame sans passer par une condition STOP.
|
||
Pour envoyer un RESTART, la ligne SDA doit passer de l'état \enquote{LOW} à \enquote{HIGH} pendant que la ligne SCL est à l'état \enquote{HIGH}. En fait, il s'agit que la commande START qui est envoyée entre un START en un STOP.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_RESTART.eps}
|
||
\caption{Condition de RESTART I²C}
|
||
\label{fig:I2C_RESTART}
|
||
\end{figure}
|
||
|
||
\subsection{L'acquittement}
|
||
Quand le récepteur à reçu un octet, il envoie la commande ACK pour signaler qu'il l'a bien reçu ou la commande NACK pour signaler un problème lors de la réception.
|
||
Quand le récepteur est un maître, il peux envoyer un NACK pour demander l'arrêt de la lecture avant d'envoyer un STOP.
|
||
Pour envoyer un ACK, le récepteur envoie simplement un bit \enquote{0}. Pour envoyer un NACK, le récepteur envoie simplement un bit \enquote{1}.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_ACK.eps}
|
||
\caption{Acquittement I²C}
|
||
\label{fig:I2C_ACK}
|
||
\end{figure}
|
||
|
||
\subsection{La pause}
|
||
A tout moment, l'esclave peux bloquer la ligne SCL à \enquote{LOW} pour signaler qu'il est occupé.
|
||
Pour aire un pause, l'esclave maintient la ligne SCL au niveau \enquote{LOW} tandis que le maître maintient la ligne au niveau \enquote{HIGH}. Le maître va détecter l'écrasement et maintenir la ligne au niveau \enquote{HIGH} jusqu'à ce que l'esclave est libéré la ligne.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics{figures/I2C/I2C_Pause.eps}
|
||
\caption{Pause I²C}
|
||
\label{fig:I2C_Pause}
|
||
\end{figure}
|
||
|
||
\subsection{Un échange complet}
|
||
Tout d'abord, tout les maîtres écoutent en permanence les deux lignes. S'ils détectent un START, ils savent qu'ils doivent attendre un STOP avant de tenter de parler à un esclave. Cette écoute permanente permet aussi de détecter les pauses et les conflits (plusieurs maîtres qui tentent de parler en même temps).
|
||
|
||
Voici un exemple d'échange complet :
|
||
\begin{enumerate}
|
||
\item le maître qui veux parler attend que le bus soit libre s'il est occupé
|
||
\item le maître envoie la commande START
|
||
\item le maître envoie un octet : le sept premiers bits correspondent à l'adresse et le huitième permet de savoir si le maître demande une lecture ou une écriture (ici, une écriture)
|
||
\item l'esclave envoie un bit d'acquittement (ici, un ACK)
|
||
\item l'esclave peux demander une pause
|
||
\item le maître envoie un octet qui contient une commande
|
||
\item l'esclave envoie un bit d'acquittement (ici, un ACK)
|
||
\item l'esclave peux demander une pause
|
||
\item le maître envoie la commande RESTART
|
||
\item le maître envoie un octet : le sept premiers bits correspondent à l'adresse et le huitième permet de savoir si le maître demande une lecture ou une écriture (ici, une lecture)
|
||
\item l'esclave envoie un premier octet qui contient le début des données
|
||
\item le maître envoie un bit d'acquittement (ici, un ACK)
|
||
\item l'esclave peux demander une pause
|
||
\item l'esclave envoie un deuxième octet qui contient la suite des données
|
||
\item le maître envoie un bit d'acquittement (ici, un NACK)
|
||
\item l'esclave peux demander une pause
|
||
\item le maître envoie la commande STOP pour libérer le bus
|
||
\end{enumerate}
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/I2C/I2C_EchangeMaitreEsclave.eps}
|
||
\caption{Exemple d'échange I²C entre un maître et un esclave}
|
||
\label{fig:I2C_EchangeMaitreEsclave}
|
||
\end{figure}
|
||
|
||
\subsection{Le cas de conflit}
|
||
Si deux maîtres (ou plus) prennent le contrôle du bus en même temps ou presque, les deux START et les lignes SCL vont se superposer et aucun des deux maîtres ne va se rendre compte qu'un autre est en train de parler un même temps. Toute fois, ils écoutent tous les deux en même temps qu'ils écrivent. Tant qu'ils envoient tous les deux un bit \enquote{1} ou \enquote{0} en même temps, il n'y aura pas de conflit entre les deux. Par contre, si l'un envoie un \enquote{1} et l'autre un \enquote{0}, le \enquote{0} va écraser le \enquote{1} et le maître envoyant le \enquote{1} va détecter le conflit. Il va donc arrêter de parler et laisser l'autre continuer. Le conflit peux être détecter lors de l'écriture de l'adresse, du bit R/W ou lors de l'envoi d'un commande.
|
||
Si les deux maîtres on envoyer exactement la même chose, il n'y aura pas de conflit et ils liront ou écriront la même chose.
|
||
|
||
\chapter{Le matériel}
|
||
\section{Le choix de la plate-forme}
|
||
Il existe de nombreuse \gls{plate-forme} en robotique~: par exemple, le Boe-Bot de Parallax, utilisé dans les cours facultatifs de robotique de M. \textsc{Gardon}. J'ai fait le choix d'un Arduino car cette un plate-forme de plus en plus répandue, peu chère (20 € pour une carte programmable) et puissante. On trouve de nombreux exemples de \gls{DIY}, elle est programmable en \gls{C++} (donc il est possible d'utiliser des \glspl{bibliotheque}) et c'est du \gls{materiel libre}.
|
||
|
||
\section{Les capteurs}
|
||
Il a été décidé de faire une station météo. Nous avons donc besoin d'un thermomètre (figure \ref{fig:BMP085}), d'un hygromètre (figure \ref{fig:BMP085} aussi), d'un baromètre (figure \ref{fig:TSL2561}) et d'un capteur de luminosité (figure \ref{fig:DHT22}). J'ai ajouté une horloge (figure \ref{fig:ChronoDot}) qui nous permettra d'avoir l'heure à laquelle les mesures ont été prises. Tous les capteurs ont été commandé sur le site d'Adafruit. L'hygromètre ne se connecte malheureusement pas en I²C, aucun capteur de ce type n'étant disponible.
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\begin{subfigure}[b]{0.23\textwidth}
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/perso/BMP085.JPG}
|
||
\caption{BMP085}
|
||
\label{fig:BMP085}
|
||
\end{subfigure}
|
||
~
|
||
\begin{subfigure}[b]{0.23\textwidth}
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/perso/ChronoDot.JPG}
|
||
\caption{ChronoDot}
|
||
\label{fig:ChronoDot}
|
||
\end{subfigure}
|
||
~
|
||
\begin{subfigure}[b]{0.23\textwidth}
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/perso/DHT22.JPG}
|
||
\caption{DHT22}
|
||
\label{fig:DHT22}
|
||
\end{subfigure}
|
||
~
|
||
\begin{subfigure}[b]{0.23\textwidth}
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/perso/TSL2561.JPG}
|
||
\caption{TSL2561}
|
||
\label{fig:TSL2561}
|
||
\end{subfigure}
|
||
\caption{Les capteurs}
|
||
\caption*{Photos personnelles}
|
||
\end{figure}
|
||
|
||
\section{Les limitations}
|
||
J'ai vite été confronté a quelques limitations : la mémoire de l'Arduino ne peux contenir seulement 32256 octets de code compilé. Il ne peux donc pas contenir en même temps les \glspl{bibliotheque} pour utiliser les capteurs en I²C, utiliser le port RJ45 et utiliser la carte SD. La solution a été de couper le programme en deux : il y a donc un code pour afficher les mesures en direct à travers un navigateur web et un code pour prendre des mesures de manière régulière et les enregistrer.
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics[width=1\textwidth]{figures/perso/montage.JPG}
|
||
\caption{Montage complet}
|
||
\caption*{Photo personnelle}
|
||
\label{fig:montage}
|
||
\end{figure}
|
||
|
||
\chapter{Le logiciel}
|
||
\section{En général}
|
||
Les deux programmes sont composés de deux fonctions principales. La fonction \verb|setup()| qui s'exécute une fois au démarrage du programme et la fonction \verb|loop()| qui est exécutée en boucle. La première sert donc à initialiser et configurer les capteurs et les puces. La deuxième sert à traiter les informations.
|
||
|
||
Plusieurs \glspl{bibliotheque} sont utilisées. Comme bibliothèques tierces, sont utilisés : \verb|BMP085| pour le capteur de température et de pression, \verb|Chronodot| pour l'horloge, \verb|DHT| pour le capteur d'humidité, \verb|TSL2561| pour le capteur de luminosité et, pour finir, \verb|WebServer| pour servir les pages web. Comme bibliothèques internes (fournie avec l'Arduino), sont utilisés : \verb|Ethernet| pour la puce de contrôle du port RJ45, \verb|SD| ainsi que \verb|SPI| pour la carte SD et \verb|Wire| pour l'I²C.
|
||
|
||
La partie logicielle est coupée en deux programmes : un enregistreur et un serveur web. Les sources sont disponibles respectivement à l'annexe \ref{app:logger} et à l'annexe \ref{app:web}.
|
||
|
||
\section{L'enregistreur}
|
||
La fonction \verb|setup()| commence par initialiser la carte SD puis initialise les différents capteurs. Il configure ensuite le capteur de luminosité et finit par vérifier si le fichier DATA.TSV existe, le crée si il n'existe pas et y enregistre les en-tête (un exemple de se fichier est disponible à l'annexe \ref{app:data}).
|
||
|
||
La fonction \verb|loop()| récupère les différentes données des capteurs puis les enregistre. Elle finit en faisant une pause d'un temps définit.
|
||
|
||
\section{Le serveur web}
|
||
La fonction \verb|setup()| commence par initialiser la puce de contrôle du port RJ45 et le serveur web et configure ce dernier, puis initialise les différents capteurs. Il configure ensuite le capteur de luminosité. Elle finit par appeler \verb|sendNtpPacket()| qui va interroger un serveur \gls{NTP} pour mettre à jour l'heure de l'horloge.
|
||
|
||
La fonction \verb|loop()| se contente de demander au serveur de s'occuper des connections entrantes. Ce dernier peux appeler deux fonctions : \verb|defaultCmd()| si la page d'index est demandée ou \verb|sensorsJsonCmd()| si c'est la page \enquote{sensors.json} qui est demandée.
|
||
|
||
La fonction \verb|defaultCmd()| se contente d'envoyer la page d'index dont le code source est disponible à l'annexe \ref{app:index}.
|
||
|
||
La fonction \verb|sensorsJsonCmd()| récupère les valeurs des capteurs puis les envoie dans le format \gls{JSON}. Un exemple est fourni à l'annexe \ref{app:sensors}.
|
||
|
||
\subsection{La page d'index}
|
||
Une fois téléchargée par le navigateur web, du JavaScript est exécuté. Ce JavaScript va télécharger la page \enquote{sensors.json} de manière régulière, analyser son contenu puis mettre à jour le tableau qui contient les valeurs.
|
||
|
||
\section{Tentative de réunion}
|
||
J'ai essayé de réunir les deux programmes en un seul en allégeant les \glspl{bibliotheque} concernant la partie web. J'ai essayé de supprimer tous les références au \gls{DHCP} et au \gls{DNS}. Cela a permis de faire passer le programme final en dessous des 32256 octets, mais il est apparu de drôles de choses : la programme gelait au bout de quelques secondes et la fonction \verb|setup()| était appelée en boucle.
|
||
|
||
J'ai aussi cherché s'il était possible de mettre un système d'exploitation sur l'Arduino et qu'il puisse charger les programmes sur la carte SD, mais je n'ai rien trouvé.
|
||
|
||
\chapter{Le cas du frigo}
|
||
\section{Les mesures}
|
||
Pour réaliser cette expérience, la station météo a été placée dans un sachet plastique contenant du silica gel ainsi qu'une rallonge pour l'hygromètre pour qu'il puisse être exposé à l'humidité du frigo. La station météo a ensuite été placée pendant une heure au frigo. Voici les premières constatations : premièrement, l'humidité ne dépassait jamais 70\%, deuxièmement, la température ne descendait jamais au dessous de 8° (voir la figure \ref{fig:1}).
|
||
|
||
Un deuxième essais a donc été réalisé, sans sachet plastique cette fois ci. Le montage a été placé deux heures au frigo. Cette fois ci, la température s'est stabilisée à environ 5° Celsius mais on constate une chute de la puissance après environ une heure. Cela est probablement dû au fait que les piles ne fournissent plus d'énergie à basse température, la puissance raugmentant une fois sortie du frigo (voir la figure \ref{fig:2}).
|
||
|
||
Un autre essais a ensuite été réalisé. Cette fois-ci, les piles ont été remplacées par un adaptateur qui fournissait du 9 volts. La satation météo a été placée dans le frigo, pendant une nuit. Cette fois-ci, l'expérience c'est bien déroulée : il n'y a pas eu de perte de puissance.
|
||
|
||
\section{Les résultats}
|
||
Premièrement, les graphiques sont disponibles à la figure \ref{fig:graphiques}
|
||
|
||
\begin{figure}[b]
|
||
\centering
|
||
\input{data/3/data.tex}
|
||
\caption{Les quatre graphiques}
|
||
\label{fig:graphiques}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\input{data/3/T-H.tex}
|
||
\caption{Humidité en fonction de la température}
|
||
\label{fig:T-H}
|
||
\end{figure}
|
||
|
||
\listoffigures
|
||
|
||
\chapter*{Bibliographie}
|
||
\addcontentsline{toc}{chapter}{Bibliographie}
|
||
\nocite{*}
|
||
\section*{Sites web}
|
||
\printbibliography[heading=none,keyword=website]
|
||
\section*{Images}
|
||
\printbibliography[heading=none,keyword=image]
|
||
|
||
\printglossary[type=\acronymtype,title=Acronymes,toctitle=Acronymes,style=altlist]
|
||
\glsadd{DHCPg}
|
||
\glsadd{DIYg}
|
||
\glsadd{DNSg}
|
||
\newpage
|
||
\printglossary[type=main,title=Glossaire,toctitle=Glossaire,style=altlist]
|
||
|
||
\appendix
|
||
\appendixpage
|
||
\addappheadtotoc
|
||
|
||
\chapter{Licence MIT}
|
||
\label{app:mit}
|
||
|
||
\inputminted{text}{input/mit.txt}
|
||
|
||
\chapter{WeatherStationLogger.ino}
|
||
\label{app:logger}
|
||
\inputminted[linenos]{cpp}{../arduino/WeatherStationLogger/WeatherStationLogger.ino}
|
||
|
||
\chapter{DATA.TSV}
|
||
\label{app:data}
|
||
\inputminted[obeytabs]{text}{input/DATA.TSV}
|
||
|
||
\chapter{WeatherStationWeb.ino}
|
||
\label{app:web}
|
||
\inputminted[linenos]{cpp}{../arduino/WeatherStationWeb/WeatherStationWeb.ino}
|
||
|
||
\chapter{index.html}
|
||
\label{app:index}
|
||
\inputminted[linenos]{html}{../arduino/WeatherStationWeb/index.html}
|
||
|
||
\chapter{sensors.json}
|
||
\label{app:sensors}
|
||
\inputminted[linenos]{json}{input/sensors.json}
|
||
|
||
\chapter{Graphiques}
|
||
\label{app:graphs}
|
||
|
||
Voici les graphiques des autres essais réalisés. À cause de leur taille, le premier est à la page suivante.
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\input{data/1/data.tex}
|
||
\caption{Premier essai dans le frigo}
|
||
\label{fig:1}
|
||
\end{figure}
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\input{data/2/data.tex}
|
||
\caption{Deuxième essai dans le frigo}
|
||
\label{fig:2}
|
||
\end{figure}
|
||
|
||
\end{document}
|