du raph en veux-tu en voila
authorPaul Kocialkowski <contact@paulk.fr>
Mon, 4 May 2015 21:55:41 +0000 (23:55 +0200)
committerPaul Kocialkowski <contact@paulk.fr>
Mon, 4 May 2015 21:55:41 +0000 (23:55 +0200)
aspects-informatique.tex

index c4a0f88..c9022f6 100644 (file)
@@ -10,9 +10,9 @@ Il s'agit d'expliciter les procédés par lesquels deux systèmes informatiques
 \subsection{Concepts et définitions}
 \label{echanges-concepts-definitions}
 
-On considère deux systèmes informatiques physiquement distincts : on parle de puces ou de circuits intégrés. Il s'agit fondamentalement de circuits logiques. On distinguera les circuits intégrés dont le mode de fonctionnement est unique, on parle alors d'ASIC\footnote{Application-specific integrated circuit en Anglais, soit circuit intégré propre à une application en Français.}, des circuits que l'on peut programmer au travers d'un jeu instructions qui correspondent à diverses opérations offertes par le circuit, on parle alors de microprocesseur\footnote{On distingue le microprocesseur du processeur (plus générique) : le microprocesseur est un processeur construit en un seul circuit intégré.}. C'est la composition d'un microprocesseur avec un certain nombre d'éléments externes tels que différents types de mémoire, diverses entrées-sorties, des circuits de contrôle de l'alimentation électrique, etc, que l'on appellera un ordinateur. Quand la plupart des éléments essentiels d'un ordinateurs est rassemblée en un seul circuit intégré, on parle alors de microcontrôleur.\\
+On considère deux systèmes informatiques physiquement distincts : on parle de puces ou de circuits intégrés. Il s'agit fondamentalement de circuits logiques. On distinguera les circuits intégrés dont le mode de fonctionnement est unique, on parle alors d'ASIC\footnote{Application-specific integrated circuit en Anglais, soit circuit intégré propre à une application en Français.}, des circuits que l'on peut programmer au travers d'un jeu d'instructions qui correspondent à diverses opérations offertes par le circuit, on parle alors de microprocesseur\footnote{On distingue le microprocesseur du processeur (plus générique) : le microprocesseur est un processeur construit en un seul circuit intégré.}. C'est la composition d'un microprocesseur avec un certain nombre d'éléments externes tels que différents types de mémoire, diverses entrées-sorties, des circuits de contrôle de l'alimentation électrique, etc, que l'on appellera un ordinateur. Quand la plupart des éléments essentiels d'un ordinateur sont rassemblés en un seul circuit intégré, on parle alors de microcontrôleur.\\
 
-De la même façon qu'il est nécessaire de synchroniser certains types de circuits logiques (en particulier lorsque le système dépend de son état précédent), les microprocesseurs sont synchronisés avec un signal d'horloge. Par abus de langage, on parlera de fréquence du microprocesseur pour parler de la fréquence l'horloge de synchronisation des opérations. En règle générale, une opération sera effectuée à chaque cycle d'horloge.\\
+De la même façon qu'il est nécessaire de synchroniser certains types de circuits logiques (en particulier lorsque le système dépend de son état précédent), les microprocesseurs sont synchronisés avec un signal d'horloge. Par abus de langage, on parlera de fréquence du microprocesseur pour parler de la fréquence de l'horloge de synchronisation des opérations. En règle générale, une opération sera effectuée à chaque cycle d'horloge.\\
 
 \begin{figure}[!h]
 \centering
@@ -20,7 +20,7 @@ De la même façon qu'il est nécessaire de synchroniser certains types de circu
 \caption{La carte Cubieboard2}
 \end{figure}
 
-La carte Cubieboard2\citenote{Cubieboard} est un exemple particulier d'ordinateur complet. On retrouve en effet tous les composants constituants un ordinateur sur une carte de petite taille : on parle d'ordinateur à carte unique, de l'Anglais \emph{Single Board Computer}, parfois abrégé par ses initiales : \emph{SBC}. Le processeur de l'ordinateur est intégré au sein d'une puce de type SoC\footnote{System on a Chip en Anglais, soit système sur une puce en Français} : il s'agit d'un seul circuit intégré rassemblant, en plus du processeur principal, un certain nombre d'autres composants utiles tels que diverses entrées sorties, des processeurs auxiliaires, etc. Pour autant, il ne contient pas la mémoire principal de l'ordinateur : il ne s'agit donc pas d'un microcontrôleur. Le SoC utilisé dans la Cubieboard2 est un \bsc{A20} produit par la société chinoise \bsc{Allwinner}. Le processeur utilisé dans le \bsc{A20} est un \bsc{Cortex A7}, qui utilise un jeu d'instructions \bsc{ARM} et opère avec un fréquence d'horloge de $1$ GHz.\\
+La carte Cubieboard2\citenote{Cubieboard} est un exemple particulier d'ordinateur complet. On retrouve en effet tous les composants constituants un ordinateur sur une carte de petite taille : on parle d'ordinateur à carte unique, de l'Anglais \emph{Single Board Computer}, parfois abrégé par ses initiales : \emph{SBC}. Le processeur de l'ordinateur est intégré au sein d'une puce de type SoC\footnote{System on a Chip en Anglais, soit système sur une puce en Français} : il s'agit d'un seul circuit intégré rassemblant, en plus du processeur principal, un certain nombre d'autres composants utiles tels que diverses entrées sorties, des processeurs auxiliaires, etc. Pour autant, il ne contient pas la mémoire principale de l'ordinateur : il ne s'agit donc pas d'un microcontrôleur. Le SoC utilisé dans la Cubieboard2 est un \bsc{A20} produit par la société chinoise \bsc{Allwinner}. Le processeur utilisé dans le \bsc{A20} est un \bsc{Cortex A7}, qui utilise un jeu d'instructions \bsc{ARM} et opère avec un fréquence d'horloge de $1$ GHz.\\
 
 \begin{figure}[!h]
 \centering
@@ -28,9 +28,9 @@ La carte Cubieboard2\citenote{Cubieboard} est un exemple particulier d'ordinateu
 \caption{La carte Arduino Uno}
 \end{figure}
 
-Quand aux microcontrôleurs, on pourra s'intéresser à la carte Arduino\citenote{Arduino} Uno : il s'agit également d'une carte au format réduit, contenant un microcontrôleur. Le microcontrôleur en question est un \bsc{ATmega328p} de la société \bsc{Atmel} et son processeur utilise un jeu d'instructions \bsc{AVR} et opère avec une fréquence d'horloge de $16$ MHz.\\
+Quant aux microcontrôleurs, on pourra s'intéresser à la carte Arduino\citenote{Arduino} Uno : il s'agit également d'une carte au format réduit, contenant un microcontrôleur. Le microcontrôleur en question est un \bsc{ATmega328p} de la société \bsc{Atmel} et son processeur utilise un jeu d'instructions \bsc{AVR} et opère avec une fréquence d'horloge de $16$ MHz.\\
 
-Ces deux cartes se prètent particulièrement à l'étude de leur fonctionnement :
+Ces deux cartes se prêtent particulièrement à l'étude de leur fonctionnement :
 \begin{itemize}
 \item[--] Du point de vue matériel, il est possible (et autorisé) d'étudier le fonctionnement de ces cartes avec les schémas électriques associés, mais également de les modifier et de redistribuer ces schémas, modifiés ou non, en plus de ne présenter aucune restriction formelle d'usage. On parle alors de matériel au design de circuit imprimé libre.\\
 \item[--] Du point de vue logiciel, on peut de même étudier le fonctionnement de ces cartes avec le code source des logiciels associés, mais également modifier ce code et le redistribuer, modifé ou non, en plus de ne présenter aucune restriction formelle d'usage. On parle alors de logiciels libres.\\
@@ -43,14 +43,14 @@ De manière générale, il n'est pas garanti que ces libertés sont accordés av
 La communication entre plusieurs circuits intégrés a lieu en reliant des dispositifs d'entrée/sortie entre eux avec des conducteurs (des pistes sur un circuit imprimé ou de simples fils), que l'on pourra appeler lignes. Lorsqu'on peut relier plus que deux appareils sur les mêmes lignes, on parle alors de bus, qui désigne à la fois l'ensemble des lignes reliant les points d'entrée/sortie et de manière plus générale, l'ensemble du système de communication.\\
 Des informations vont alors être échangées au travers de ces conducteurs, le plus généralement\footnote{Certaines normes de transmision utilisent d'autres modes de communication, tels que le LVDS pour Low Voltage Differential Signaling en Anglais ou  transmission différentielle basse-tension en Français, que l'on n'abordera pas en détail.} sous forme numérique : il s'agira de bits, dont les valeurs traduisent des états logiques qui sont physiquement caractérisés par certaines tensions\footnote{Ces concepts sont détaillés dans la partie \ref{systemes-logiques}}. Le potentiel de référence utilisé pour la mesure des tensions devra donc être commun entre les deux circuits : chaque bus de données contiendra alors généralement une ligne dédié à la mise en commun de la masse.\\
 
-L'échange de données proprement dit consistera en un alternance de lectures et d'écritures sur le bus de communication. Plus précisément, un bit sera émis par un des circuits intégrés quand l'état logique est forcé par ce circuit. Il est alors nécessaire que le circuit intégré souhaitant recevoir l'information « lise » l'état logique d'une ligne, c'est à dire qu'il relève cet état logique sans l'influencer. On parlera alors d'un troisième état pour le circuit, dit état déconnecté ou de haute impédance\footnote{On parle d'impédance comme équivalent complexe de la résistance, dans le cas de variations sinusoïdales des grandeurs.} (hi-Z)\footnote{Le symbole Z représente l'impédance et le préfixe hi signifie high en Anglais, soit haut en Français}. Cet état correspondra à une forte résistance entre le point considéré et la masse, qui ne perturbe alors pas la tension appliquée en ce point par un circuit externe. Ainsi, en état hi-Z, il sera possible pour le circuit recevant l'information de relever l'état logique de la ligne sans le changer.\\
+L'échange de données proprement dit consistera en une alternance de lectures et d'écritures sur le bus de communication. Plus précisément, un bit sera émis par un des circuits intégrés quand l'état logique est forcé par ce circuit. Il est alors nécessaire que le circuit intégré souhaitant recevoir l'information « lise » l'état logique d'une ligne, c'est à dire qu'il relève cet état logique sans l'influencer. On parlera alors d'un troisième état pour le circuit, dit état déconnecté ou de haute impédance\footnote{On parle d'impédance comme équivalent complexe de la résistance, dans le cas de variations sinusoïdales des grandeurs.} (hi-Z)\footnote{Le symbole Z représente l'impédance et le préfixe hi signifie high en Anglais, soit haut en Français}. Cet état correspondra à une forte résistance entre le point considéré et la masse, qui ne perturbe alors pas la tension appliquée en ce point par un circuit externe. Ainsi, en état hi-Z, il sera possible pour le circuit recevant l'information de relever l'état logique de la ligne sans le changer.\\
 
 Si tous les circuits reliés au bus sont en état hi-Z (c'est à dire qu'aucun circuit n'impose d'état logique), l'état du circuit sera à priori indéterminé. C'est pour cela que l'on connecte généralement aux lignes des résistances dites de rappel, de valeur faible devant la résistance interne du circuit, que l'on porte à un potentiel correspondant au niveau logique souhaité. Si on souhaite qu'une ligne du bus soit dans un état haut quand il n'y a pas d'activité, on reliera alors cette ligne avec une résistance de rappel à la tension positive de référence.
 
 \subsubsection*{Écrasement, arbitrage et rôles}
 
 Dans le cas où tous les circuits intégrés utilisent la même ligne à la fois pour la lecture et l'écriture, on peu se retrouver dans le cas où deux circuits intégrés cherchent à écrire sur la ligne simultanément : on parle alors d'écrasement des données. C'est une des raisons qui conduit à la nécessité d'attribuer des temps réservés à la lecture et à l'écriture pour chaque puce et donc de synchroniser les communications.\\
-Cependant, il est également possible de mettre en place un arbitrage : les deux circuits doivent alors lire l'état de la ligne après avoir écrit un bit. Si l'état ne correspond pas au bit envoyé, le circuit perd la main et doit cesser d'écrire sur le bus : on dit qu'il a perdu l'arbitrage. Cela n'est possible que quand un état logique a priorité sur l'autre (il s'agit d'une caractéristique du bus) : si un circuit inscrit un état haut alors qu'un autre circuit inscrit simultanément un été bas, la ligne prendre systématiquement l'un des deux états. On qualifie alors cet état de dominant et l'autre état de récessif. Par exemple, pour le bus CAN\footnote{Controller Area Network en Anglais, soit contrôleur de zone de réseau en Français}, très utilisé dans les automobiles, l'état logique bas est dominant et l'état haut est récessif.\\
+Cependant, il est également possible de mettre en place un arbitrage : les deux circuits doivent alors lire l'état de la ligne après avoir écrit un bit. Si l'état ne correspond pas au bit envoyé, le circuit perd la main et doit cesser d'écrire sur le bus : on dit qu'il a perdu l'arbitrage. Cela n'est possible que quand un état logique a priorité sur l'autre (il s'agit d'une caractéristique du bus) : si un circuit inscrit un état haut alors qu'un autre circuit inscrit simultanément un été bas, la ligne prendra systématiquement l'un des deux états. On qualifie alors cet état de dominant et l'autre état de récessif. Par exemple, pour le bus CAN\footnote{Controller Area Network en Anglais, soit contrôleur de zone de réseau en Français}, très utilisé dans les automobiles, l'état logique bas est dominant et l'état haut est récessif.\\
 
 Plutôt que de permettre à tous les circuits intégrés d'écrire en même temps, certains bus attribuent également des rôles, maître ou esclave à chaque circuit. C'est par exemple le case du bus \iic\footnote{\iic/IIC pour Inter Integrated Circuits en Anglais, soit inter circuits intégrés en Français}, très utilisé pour la communication entre le processeur et les puces dans les ordinateurs. Généralement, le circuit dédié à la gestion de l'\iic\ attaché au processeur (on parle de contrôleur \iic) est maître du bus alors que toutes les autres puces reliées au bus sont esclaves. Dans cette configuration, seul le maître peut commencer à écrire sur le bus et les esclaves ne pourront écrire sur le bus qu'en réponse à une demande du maître.\\
 
@@ -58,9 +58,9 @@ Quand plusieurs esclaves sont connectés au même bus, des adresses pourront leu
 
 \subsubsection*{Protocole de communication}
 
-Il s'agit bien là de règles formelles qui doivent-être respectées par chaque puce utilisant le bus : l'ensemble de ces règles constitue le protocole de communication utilisé sur le bus. En particulier, le protocole va permettre de définir quel puce peut lire ou écrire à quel moment. Cela n'est cependant possible qu'avec un signal de synchronisation permettant de découper le temps en quantités discrètes : on utilise donc un horloge comme tel signal de synchronisation, qui fait partie intégrante du bus et qui doit être prise en compte par tous les circuits connectés au bus. Par exemple, dans le cas du bus \iic, il n'est permis de changer l'état de la ligne de données que sur un temps bas de l'horloge. Le temps haut est alors réservé à la lecture de l'état du bus (sauf exceptions telles que le signalement d'un début ou d'une fin de transaction). Le protocole définit par ailleurs la signification de la succession des bits envoyés sur le bus, à partir du signalement du début de la transaction. On détaillera en partie ce protocole dans la partie \ref{communication-i2c}.\\
+Il s'agit bien là de règles formelles qui doivent être respectées par chaque puce utilisant le bus : l'ensemble de ces règles constitue le protocole de communication utilisé sur le bus. En particulier, le protocole va permettre de définir quelle puce peut lire ou écrire à quel moment. Cela n'est cependant possible qu'avec un signal de synchronisation permettant de découper le temps en quantités discrètes : on utilise donc une horloge comme tel signal de synchronisation, qui fait partie intégrante du bus et qui doit être prise en compte par tous les circuits connectés au bus. Par exemple, dans le cas du bus \iic, il n'est permis de changer l'état de la ligne de données que sur un temps bas de l'horloge. Le temps haut est alors réservé à la lecture de l'état du bus (sauf exceptions telles que le signalement d'un début ou d'une fin de transaction). Le protocole définit par ailleurs la signification de la succession des bits envoyés sur le bus, à partir du signalement du début de la transaction. On détaillera en partie ce protocole dans la partie \ref{communication-i2c}.\\
 
-Certains bus n'utilisent cependant pas d'horloges de synchronisation mais une configuration explicite de la vitesse de changement d'état du bus, commune à tous les circuits reliés au bus. La communication sera synchronisée par un bit ou un ensemble de bits donnés que le circuit de réception pourra identifier. Des horloges internes aux composants seront de cette manière synchronisées entre-elles pour permettre de donner sens à la communication. Ce principe est exploité dans les composants UART\footnote{Universal Asynchronous Receiver Transmitter en Anglais, soit émetteur-récepteur asynchrone universel en Français.}.\\
+Certains bus n'utilisent cependant pas d'horloge de synchronisation mais une configuration explicite de la vitesse de changement d'état du bus, commune à tous les circuits reliés au bus. La communication sera synchronisée par un bit ou un ensemble de bits donnés que le circuit de réception pourra identifier. Des horloges internes aux composants seront de cette manière synchronisées entre-elles pour permettre de donner sens à la communication. Ce principe est exploité dans les composants UART\footnote{Universal Asynchronous Receiver Transmitter en Anglais, soit émetteur-récepteur asynchrone universel en Français.}.\\
 
 Il existe donc une grande variété de bus, chacun avec un certain nombre de caractéristiques :
 \begin{itemize}
@@ -100,14 +100,14 @@ Afin de relier les deux systèmes, on cherchera à connecter deux lignes, entre
 
 Du point de vue du logiciel, on utilisera directement la ligne de commande du chargeur de démarrage \bsc{U-Boot}. Il s'agit du premier logiciel exécuté par la carte (avant le chargement du système d'exploitation) et qui offre un interpréteur de commandes proposant de multiples fonctionnalités, y compris la gestion du bus \iic. Cependant, au jour de réalisation de l'expérience, \bsc{U-Boot} ne prenait en charge que le premier contrôleur \iic, noté $TWI0$ (utilisé pour communiquer avec le PMIC \bsc{AXP209}).\\
 
-Afin de réaliser l'expérience, nous avons modifié le code source (écrit en langage C) d'\bsc{U-Boot}, ce-qui a été possible comme il s'agit d'un logiciel libre. En particulier, il aura été nécessaire de mettre en place une gestion dynamique de l'index du bus à utiliser, de configurer les points d'entrée/sortie dédiés à l'\iic\ et de définir l'emplacement en mémoire de ces contrôleurs. Le développement d'\bsc{U-Boot} est conduit de manière communautaire (comme c'est souvent le cas pour un logiciel libre) et les contributions externes sont les bienvenues, ce-qui nous aura poussé à proposer notre modification aux mainteneurs du logiciel, au travers de la liste de discussion\footnote{Liste de discussion du projet \bsc{U-Boot} : http://lists.denx.de/mailman/listinfo/u-boot} prévue à cet effet. Après 5 différentes itérations de la proposition\footnote{Archives de la liste de discussion du projet \bsc{U-Boot} pour le mois d'Avril 2015 : http://lists.denx.de/pipermail/u-boot/2015-April/}, résultats des commentaires émis par la communauté et les mainteneurs des parties du code concernés par la modification, celle-ci a finalement été approuvée et intégrée au code source officiel du projet\footnote{Modification "i2c: mvtwsi: Support for up to 4 different controllers" : http://git.denx.de/?p=u-boot.git;a=commit;h=dd82242b4dd7d251ef9ba43563cf9a0017d6f98e}\footnote{Modification "sunxi: Complete i2c support for each supported platform
+Afin de réaliser l'expérience, nous avons modifié le code source (écrit en langage C) d'\bsc{U-Boot}, ce qui a été possible comme il s'agit d'un logiciel libre. En particulier, il aura été nécessaire de mettre en place une gestion dynamique de l'index du bus à utiliser, de configurer les points d'entrée/sortie dédiés à l'\iic\ et de définir l'emplacement en mémoire de ces contrôleurs. Le développement d'\bsc{U-Boot} est conduit de manière communautaire (comme c'est souvent le cas pour un logiciel libre) et les contributions externes sont les bienvenues, ce qui nous aura poussé à proposer notre modification aux mainteneurs du logiciel, au travers de la liste de discussion\footnote{Liste de discussion du projet \bsc{U-Boot} : http://lists.denx.de/mailman/listinfo/u-boot} prévue à cet effet. Après 5 différentes itérations de la proposition\footnote{Archives de la liste de discussion du projet \bsc{U-Boot} pour le mois d'Avril 2015 : http://lists.denx.de/pipermail/u-boot/2015-April/}, résultats des commentaires émis par la communauté et les mainteneurs des parties du code concernés par la modification, celle-ci a finalement été approuvée et intégrée au code source officiel du projet\footnote{Modification "i2c: mvtwsi: Support for up to 4 different controllers" : http://git.denx.de/?p=u-boot.git;a=commit;h=dd82242b4dd7d251ef9ba43563cf9a0017d6f98e}\footnote{Modification "sunxi: Complete i2c support for each supported platform
 " : http://git.denx.de/?p=u-boot.git;a=commit;h=6c739c5d8a3466f8ef2f8543636484957bcca6ee}. On aura vérifié le bon fonctionnement du code en utilisant l'analyseur logique et en lançant un sondage du bus avec la commande $i2c\ probe$, qui fait apparaître des signaux sur la lignes de donnée et la ligne d'horloge.
 
 \subsubsection*{Réalisation du programme}
 
 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\footnote{Integrated Development Environment en Anglais, soit environnement de développement intégré en Français} 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}. Enfin, 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 : 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 un terminologie en Anglais, afin qu'il soit techniquement compréhensible (et modifiable) par le plus grand nombre, mais on attache toute 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 également 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 un terminologie 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 également 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.\\
 
 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 associera à 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$.\\