Je tiens à remercier M.~Salanon pour ses conseils, son aide et pour m'avoir suivi tout au long de ce TM et M.~Gelsomino pour m'avoir permis de le réaliser.
J'ai décidé de faire mon \gls{TM}\footnote{Les mots en \textbf{gras} sont des mots définis dans le glossaire ou sont des acronymes.} sur ce sujet car je suis passionné de robotique depuis tout petit. J'ai commencé en participant à un atelier de soudure à 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 j'ai participé à deux ateliers (introduction à la programmation d'un microcontrôleur et soudure d'un robot DIDEL).
J'ai d'abord dû trouver un sujet plus précis. Suite à une discussion avec M.~Salanon, je me suis tourné vers l'étude d'un \gls{bus} de données (l'I²C) et la programmation d'une sorte de station météo.
J'ai dû choisir le matériel puis le commander depuis les États-Unis (le choix de matériel disponible en Suisse étant plus limité et pas forcément moins cher).
J'ai ensuite étudié le fonctionnement du \gls{bus} en théorie, puis \enquote{assemblé} et programmé la station. J'ai aussi réalisé un programme pour tester le fonctionnement de l'I²C à l'aide d'un oscilloscope.
\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 \gls{code source} est une condition nécessaire ;
\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 \gls{code source} est une condition nécessaire.
On retrouve aussi le terme \enquote{\emph{open source}}. Le terme logiciel libre est défini par la \gls{FSF} tandis celui d'open source est défini par l'\gls{OSI}. En pratique, ces deux termes désignent la même chose.
Les sources des 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}).
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.
Ce chapitre est basé sur un article de Wikipédia\footcite{i2c-wikipedia} ainsi qu'un autre article\footcite{i2c-aurel32}. 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)}.
Il faut toutefois une troisième ligne pour avoir une masse commune à tous les équipements.
Ceux-ci 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. Cependant, rien n'empêche à un équipement de passer du statut de maître au status d'esclave et vice-versa.
Pour permettre à plusieurs maîtres de pouvoir imposer un niveau haut ou un niveau bas sur les lignes en même temps, des sorties à collecteur ouvert (ou à drain ouvert pour des circuits CMOS) sont utilisées. Deux résistances \enquote{pull-up} ($R_P$) tirent les lignes au niveau haut ($V_{DD}$).
Les états logiques sont définis proportionnellement à la tension de la ligne et de la masse (tableau \ref{tab:etat-niveau}).
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 \enquote{LOW}.
\begin{table}[h]
\begin{center}
\begin{tabular}{|c|c|}
\hline
État & Niveau \\
\hline
\enquote{LOW} ou \enquote{0}&$-0.5$~V à $0.3\cdot{}V_{DD}$\\
\hline
\enquote{HIGH} ou \enquote{1}&$0.7\cdot{}V_{DD}$ à $V_{DD}$\\
Tout d'abord, en informatique, les informations sont envoyées sous forme de \enquote{0} et de \enquote{1}. Un \enquote{0} ou un \enquote{1} s'appelle un bit. Souvent, les informations sont envoyées sous forme de paquets de huit bits. On appelle ces huit bits un octet (ou \emph{byte} en anglais).
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 (\enquote{LOW} pour transmettre un \enquote{0} ou \enquote{HIGH} pour transmettre un \enquote{1}). Ensuite, il place la ligne SCL au niveau \enquote{HIGH} attend un temps défini par la vitesse et la norme utilisées puis replace la ligne SCL au niveau \enquote{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.
La commande RESTART est une transgression à la règle d'encodage. Elle est utilisée pour signaler le début d'une nouvelle \gls{trame} sans passer par une condition STOP.
Pour envoyer un RESTART, la ligne SDA doit passer de l'état \enquote{HIGH} à \enquote{LOW} pendant que la ligne SCL est à l'état \enquote{HIGH}.
En fait, il s'agit de la commande START qui est envoyée entre un START et un STOP.
Quand le récepteur a 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 peut envoyer un NACK pour demander l'arrêt de la lecture avant d'envoyer un STOP.
À tout moment, l'esclave peut bloquer la ligne SCL à \enquote{LOW} pour signaler qu'il est occupé.
Pour faire une 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 ait libéré la ligne.
Il y a quelques adresses \enquote{spéciales}\footnote{Les X tout à droite correspondent au bit R/W. Les autres X, l'y et le z peuvent être soit un \enquote{1}, soit un \enquote{0}.}~:
\item Le premier est l'octet \enquote{11110yz0}. Les bits y et z sont les bits de poids fort de l'adresse (autrement dit, ceux le plus à gauche). Le bit R/W est toujours à \enquote{0}.
\item Le deuxième octet contient la suite de l'adresse sur huit bits. Il n'y a donc pas de bit R/W.
\caption{Adressage d'un esclave I²C sur 10 bits en écriture}
\label{fig:I2C_Adresse10bitsEcriture}
\end{figure}
Plusieurs esclaves peuvent avoir une adresse qui commence par yz. Si c'est le cas, ils répondent tous par un ACK en même temps. Une fois la suite de l'adresse envoyée, un seul esclave répondra par un ACK, l'adresse étant unique.
Si le maître veut demander une lecture, il doit envoyer un RESTART à la fin du deuxième octet de l'adresse, puis envoyer l'octet \enquote{11110yz1}. Cette fois-ci, le bit R/W est à \enquote{1} et l'esclave saura que le maître demande une lecture.
Tout d'abord, tous 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).
\item Le maître qui veut parler attend que le \gls{bus} soit libre si ce dernier est occupé.
\item Le maître envoie la commande START.
\item Le maître envoie un octet~: les 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 peut 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 peut demander une pause.
\item Le maître envoie la commande RESTART.
\item Le maître envoie un octet~: les 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 peut 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 peut demander une pause.
\item Le maître envoie la commande STOP pour libérer le \gls{bus}.
Si deux maîtres (ou plus) prennent le contrôle du \gls{bus} simultanément 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 en même temps. Toutefois, ils écoutent tous les deux pendant qu'ils écrivent. Tant qu'ils envoient 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 peut être détecté lors de l'écriture de l'adresse, du bit R/W ou lors de l'envoi d'une commande.
Il existe de nombreuses \glspl{plate-forme} en robotique~: par exemple, le Boe-Bot de Parallax, utilisé dans les cours facultatifs de robotique de M.~Gardon. J'ai fait le choix d'un Arduino car c'est une plate-forme de plus en plus répandue, peu chère (20 € pour une carte programmable). On trouve de nombreux exemples de \gls{DIY}\glsadd{DIYg}, elle est programmable en \gls{C++} (il est donc possible d'utiliser des \glspl{bibliotheque}) et c'est du \gls{materiel libre}.
Pour pouvoir afficher les mesures des capteurs en direct et à travers le réseau, j'ai choisi un Arduino Ethernet (voir la photo de couverture).
J'ai décidé de faire une station météo. Nous avons 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és sur le site d'Adafruit. L'hygromètre ne se connecte malheureusement pas en I²C, aucun capteur de ce type n'étant disponible.
J'ai vite été confronté à une limitation~: la mémoire de l'Arduino ne peut contenir seulement 32'256 octets de code compilé. Il ne peut donc pas contenir en même temps les \glspl{bibliotheque} pour utiliser les capteurs en I²C, le port RJ45 et 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.
Les 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 à initialiser et configurer les capteurs et les puces tandis que la deuxième sert à traiter les informations.
Plusieurs \glspl{bibliotheque} sont utilisées. Comme bibliothèques internes\footnote{Fournies avec l'Arduino.}, sont utilisées~: \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. Comme bibliothèques tierces\footnote{Fournies par d'autres personnes/enterprises/projets sur Internet.}, sont utilisées~: \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.
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}.
Un troisième programme sera utilisé pour tester en pratique le protocole I²C à l'aide d'un oscilloscope et vérifier si la théorie correspond à la pratique. Le \gls{code source} est disponible à l'annexe \ref{app:i2cpractise}.
La fonction \verb|setup()| commence par initialiser la carte SD, puis initialise les différents capteurs. Elle configure ensuite le capteur de luminosité et finit par vérifier si le fichier \enquote{DATA.TSV} existe. S'il n'existe pas, elle le crée et y enregistre les en-têtes (un exemple de ce fichier est disponible à l'annexe \ref{app:data}).
La fonction \verb|setup()| commence par initialiser la puce de contrôle du port RJ45 et le serveur web, configure ce dernier, puis initialise les différents capteurs. Elle 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 peut 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|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}.
Une fois la page 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.
Une capture d'écran de la page est disponible à l'annexe \ref{app:screenshot}.
J'ai tenté de réunir les deux programmes en un seul en allégeant les \glspl{bibliotheque} concernant la partie web. J'ai essayé de supprimer toutes les références au \gls{DHCP}\glsadd{DHCPg} et au \gls{DNS}\glsadd{DNSg}. Cela a permis de faire passer le programme final en dessous des 32'256 octets, mais il est apparu de drôles de choses~: le 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 pour qu'il puisse charger les programmes depuis la carte SD, mais je n'ai rien trouvé.
La fonction \verb|loop()| va envoyer en boucle le nombre 0, 170 ou 255 à un esclave (ici, l'horloge) en écriture. L'opération est effectuée en boucle car un seul envoi est trop rapide pour être lu sur l'oscilloscope.
Les trois nombres envoyés ont été choisis à cause de leur écriture en binaire\footnote{Voir tableau \ref{tab:dec-bin}.}. Ce sont des cas \enquote{extrêmes} qui permettent de bien voir certains éléments sur les graphes de l'oscilloscope.
Pour pouvoir analyser les graphes plus facilement, j'ai rajouté le numéro ou le nom des bits sur la ligne d'horloge et le bit envoyé sur la ligne de données ainsi que le START et le STOP.
Les originaux sont disponibles à l'annexe \ref{app:oscillo}.
La figure \ref{fig:oscillo-0} montre l'écriture d'un 0 vue à l'oscilloscope. Le premier canal (en orange) montre la ligne des données (SDA) et le deuxième canal montre la ligne d'horloge (SCL).
On voit que la communication commence par l'envoi d'un START par le maître, suivi des sept bits de l'adresse (ici, \enquote{1101000}) puis du bit d'écriture (l'avant-dernier \enquote{0}). L'esclave envoie ensuite le bit d'acquittement (le dernier \enquote{0}). On remarque une crête, mais elle ne correspond pas à un RESTART. En effet~: cette crête se situe alors que la ligne d'horloge est au niveau \enquote{LOW}. Après, on voit l'envoi du 0 (les huit premiers \enquote{0}) par le maître puis du bit d'acquittement par l'esclave. Le maître termine la communication par un STOP.
La communication commence de la même manière~: envoi du START, de l'adresse, du bit d'écriture et pour finir, du bit d'acquittement. Pour le deuxième octet, on voit l'envoi du 255 (les huit premiers \enquote{1}), puis le bit d'acquittement. Mais cette fois-ci, ce dernier est positionné à \enquote{1}. L'esclave envoie donc un NACK (autrement dit, un non-acquittement). Le maître termine la communication avec un STOP. On remarque un creux entre le deuxième octet et le STOP. C'est pour pouvoir effectuer ce dernier. En effet~: la ligne de données doit passer du niveau bas au niveau haut quand la ligne d'horloge est au niveau haut. La crête est toujours présente, mais \enquote{fusionnée} avec les \enquote{1} du deuxième octet.
Encore une fois, la communication commence de la même manière. Pour le deuxième octet, on voit l'envoi du 170 (le \enquote{10101010}), puis le bit d'acquittement. Mais cette fois-ci encore, ce dernier est positionné à \enquote{1}. L'esclave envoie à nouveau un NACK. Le maître termine la communication avec un STOP.
L'horloge possède un registre contenant les valeurs qui correspondent à l'heure, la date, la température et à deux alarmes. Ici, deux cas sont possibles~: la lecture et l'écriture.
Si on veut lire une partie du registre, il faut commencer par envoyer en écriture la case à partir de laquelle on veut commencer à lire puis un STOP. Ensuite, on envoie une demande de lecture. L'horloge va répondre en envoyant un octet contenant les informations de la case sélectionnée. Ensuite, on peut soit envoyer un ACK pour recevoir la case suivante, soit envoyer un NACK pour arrêter la lecture.
Si l'on veut écrire, après avoir sélectionné la case, il faut continuer à écrire un octet. Cet octet sera écrit à l'endroit sélectionné. Deux choix s'offrent ensuite~: écrire encore un octet qui sera placé dans la case suivante ou envoyer un STOP.
Les nombres envoyés pour mes essais sont donc des sélections de case. L'horloge a renvoyé un NACK car la case n° 170 ou 255 n'existe pas et la sélection a par conséquent échouée. Elle a, au contraire, renvoyé un ACK pour la case n° 0 car celle-ci existe. En effet~: en informatique, les tableaux et les registres sont numérotés à partir de 0 et non de 1.
Pour accomplir 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 mes premières constatations~: premièrement, l'humidité ne dépassait jamais 70~\%, deuxièmement, la température ne descendait jamais au dessous de 8~°C (voir la figure \ref{fig:1}).
Un deuxième essai a é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~°C 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 augmentant une fois sortie du frigo (voir la figure \ref{fig:2}).
Un autre essai a ensuite été réalisé. Cette fois-ci, les piles ont été remplacées par un adaptateur qui fournissait du 9~volts. La station météo a été placée dans le frigo, pendant une nuit. Cette fois-ci, l'expérience s'est bien déroulée~: il n'y a pas eu de perte de puissance.
Tout d'abord, la température commence par descendre d'une manière qui semble exponentielle (ce n'est pas très visible ici mais l'est clairement sur un agrandissement) puis oscille de manière périodique entre 4~°C et 7.5~°C. On voit une légère augmentation de la température vers huit heures du matin.
L'humidité oscille aussi de manière périodique entre environ 40~\% d'humidité et 70~\% d'humidité après deux heures dans le frigo. On voit un grand pic vers huit heures du matin.
La luminosité est nulle tout au long de l'expérience sauf quand la station a été placée et retirée du frigo. On remarque un pic vers huit heures du matin. Cette augmentation et ces pics nous indiquent que la porte a été ouverte à cette heure-ci.
La figure \ref{fig:t-h} représente l'humidité en fonction de la température entre trois heures et quart du matin et sept heures et demi du matin. D'après les cours de M.~Bonnaz, je m'attendais à voir une courbe de pente négative, symétrique à celle-ci. En effet~: plus l'air est chaud, plus il peut accueillir d'humidité, donc l'humidité relative devrait diminuer. Mais ça ne fonctionne que si l'on part du principe que l'eau ne se condense que lorsque l'humidité atteint 100~\% (ce qui était fait dans les exercices du cours).
Sachant que le frigo fait environ 200~litres et que~:
\begin{itemize}
\item à 4~°C l'humidité relative est de 43~\% et la pression à l'équilibre\footnote{Information que l'on trouve dans des tables.} est de 813~Pa;
\item à 6.6~°C l'humidité relative est de 70~\% et la pression à l'équilibre est de 975~Pa;
\end{itemize}
on peut calculer la quantité de vapeur dans le frigo à 4 et 6.6~°C.
À~4 °C, le frigo contient environ 0.55~gramme de vapeur et à 6.6~°C, il en contient 1.06~gramme.
Si l'on part du principe que le frigo est étanche, la pente de la courbe peut donc s'expliquer par le fait que 0.51~gramme d'eau s'évapore et se condense à chaque cycle, ce qui est une quantité raisonnable.
