grmbl ça commence à faire chaud au cul
authorPaul Kocialkowski <contact@paulk.fr>
Sun, 3 May 2015 21:34:56 +0000 (23:34 +0200)
committerPaul Kocialkowski <contact@paulk.fr>
Sun, 3 May 2015 21:34:56 +0000 (23:34 +0200)
12 files changed:
annexes.tex
applications-logiques.tex
aspects-informatique.tex
biblio.bib
images/axp209.png [new file with mode: 0644]
images/chronogramme-ardui2c.png [new file with mode: 0644]
images/ne555-systemes.png [new file with mode: 0644]
images/schmitt.png
images/systeme-alarme.png [new file with mode: 0644]
images/systeme-led.png [new file with mode: 0644]
main.tex
phenomenes-circuits-temps.tex

index 5b20cad..6c398b6 100644 (file)
@@ -31,7 +31,7 @@
 
 \begin{figure}[h]
 \centering
-\includegraphics[width=7cm]{bouton-rebond.png}
+\includegraphics[width=5cm]{bouton-rebond.png}
 \caption{Montage desuppression des rebonds électriques du bouton poussoir}
 \label{bouton-rebond}
 \end{figure}
 \label{incrementation-final-nand}
 \end{figure}
 
+\begin{figure}[h]
+\centering
+\includegraphics[width=5cm]{systeme-led.png}
+\caption{Système d'affichage du décompte des secondes en représentation binaire}
+\label{systeme-led}
+\end{figure}
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=\linewidth]{systeme-alarme.png}
+\caption{Système d'alarme sonore pour la cuisson d'un œuf à la coque avec rappel clignotant de période $30$ secondes}
+\label{systeme-alarme}
+\end{figure}
+
 \chapter{}
 
 \lstinputlisting[caption=Ardui2c,label=ardui2c]{ardui2c.c}
index 71f03cd..f23d59d 100644 (file)
@@ -299,20 +299,36 @@ Système d'affichage du décompte des secondes en représentation binaire :
 \item[--] Module de sortie : ensemble d'afficheurs sept-segments\footnote{Les afficheurs sept-segments permettent d'afficher tous les chiffres décimaux.} avec circuits de commande pour les afficheurs. Pour $n$ bits, on cherche le plus petit $k$ tel que $10^k \geq 2^n - 1$ : k représente alors le nombre d'afficheurs nécessaires.\\
 \end{itemize}
 
-\indent Système alarme pour la cuisson d'un œuf à la coque avec rappel clignotant de période $30$ secondes
+\indent Système d'alarme sonore pour la cuisson d'un œuf à la coque avec rappel clignotant de période $30$ secondes
 \begin{itemize}
 \item[--] Module d'entrée : multivibrateur de période correspondante à $30$ secondes, soit une fréquence de $\frac1{30}$ Hz, avec interrupteur pour le départ
 \item[--] Nombre de bits : on veut un décompte de $3$ minutes, soit jusqu'à $6 \cdot 30$ secondes, donc une valeur jusqu'à 6 et on a l'encadrement : $2^3 - 1 = 7 > 6 > 2^2 - 1 = 3$ donc $3$ bits.
-\item[--] Module de sortie : LED pour le rappel toutes les minutes, bipeur piézo-électrique\footnote{Il s'agit d'un composant pouvant-être utilisé simplement pour émettre un son strident, souvent utilisé dans les alarmes.} quand les $3$ minutes sont écoulées et bouton poussoir pour stopper la sonnerie et redémarrer le décompte.\\
+\item[--] Module de sortie : LED pour le rappel toutes les minutes, bipeur piézoélectrique\footnote{Il s'agit d'un composant pouvant-être utilisé simplement pour émettre un son strident, souvent utilisé dans les alarmes.} quand les $3$ minutes sont écoulées et bouton poussoir pour stopper la sonnerie et redémarrer le décompte.\\
 \end{itemize}
 
-On cherchera à réaliser la première et la dernière proposition pour concrétiser ces montages de décompte du temps. On réalise les horloges avec des composants NE555 et des valeurs des composants périphériques pour obtenir les fréquences désirées, d'après les formules énoncées dans la partie \ref{signal-carre-montages} en page \pageref\{signal-carre-montages}. En particulier, il sera souhaitable d'obtenir un rapport cyclique $\alpha$ égal à $\frac12$ (par exemple pour obtenir des clignotements de LEDs équilibrés). Si on prend une valeur de $R2$ faible devant $R1$ (on souhaitera une valeur au moins 100 fois plus faible, par exemple), $R2$ est négligeable devant $R1$, et deux fois plus négligeable devant $2R1$ et donc :
+On cherchera à réaliser la première et la dernière proposition pour concrétiser ces montages de décompte du temps.
+
+\begin{figure}[!h]
+\centering
+\includegraphics[width=9cm]{ne555-systemes.png}
+\caption{Circuit intégré NE555 utilisé pour les systèmes complets}
+\label{ne555-systemes}
+\end{figure}
+
+On réalise les horloges avec des composants (figure \ref{ne555-systemes}) NE555 utilisé en mode multivibrateur et des valeurs des composants périphériques pour obtenir les fréquences désirées, d'après les formules énoncées dans la partie \ref{signal-carre-montages} en page \pageref{signal-carre-montages}. En particulier, il sera souhaitable d'obtenir un rapport cyclique $\alpha$ égal à $\frac12$ (par exemple pour obtenir des clignotements de LEDs équilibrés). Si on prend une valeur de $R2$ faible devant $R1$ (on souhaitera une valeur au moins 100 fois plus faible, par exemple), $R2$ est négligeable devant $R1$, et deux fois plus négligeable devant $2R1$ et donc :
 $$\alpha = 1 - \frac {R1} { (R2 + 2R1) } \approx 1 - \frac{R1}{2R1} = \frac12$$
-En pratique, on prendra pour $R2$ une valeur de 500 \ohm.
+En pratique, on prendra pour $R2$ une valeur de 500 \ohm.\\
+
+Le premier montage est réalisé avec en entrée un horloge de fréquence environ égale à $1$ Hz, obtenue avec les valeurs des composants suivantes : $R1 = 72$ k\ohm\ et $C1 = 10$ \microf. On réalise le compteur sur $4$ bits, soit un décompte jusqu'à $15$ secondes. Le module de sortie, dont le schéma électronique du système est reporté en annexe \ref{systeme-led}, utilise un transistor NPN (avec un pont diviseur de tension) pour chaque LED, afin d'éviter que le courant nécessaire pour la LED ne passe par le circuit logique. De plus, On utilisera une résistance variable de l'ordre de $10$ k\ohm\ en série avec la LED pour régler la luminosité (et donc le courant consommé). Les valeurs nécessaires de résistance dépendront de la couleur de la LED et de l'intensité souhaitée.\\
+
++ref photo ici
+
+Pour le dernier système dont le schéma électronique est reporté en annexe \ref{systeme-alarme}, on souhaite tout d'abord faire clignoter une LED avec une période de $30$ secondes (pour attirer l'attention de l'usager), qui correspond à la période du signal d'horloge. On obtient cette période avec les composants suivants : $R1 = 98$ k\ohm et $C1 = 220$ \microf. On connecte donc la LED en série avec une résistance variable au travers d'un transistor (vu les considérations faites pour le premier montage) et la LED sera déclenchée avec l'état haut du signal d'horloge. Afin de détecter que les $3$ minutes sont écoulées, on s'intéresse aux bits $D_1$ et $D_2$. En effet, on veut un décompte jusqu'à six, exprimé $110$ en binaire : on teste donc les bits de poids 1 et 2, avec une porte logique ET. La sortie de cette porte est reliée à une bascule RS de sorte que dès que les bits de poids 1 et 2 sont à $1$, l'entrée S de la bascule soit activée et passe $Q$ à 1 et $\overline{Q}$ à 0. On relie alors la sortie de $\overline{Q}$ à l'alimentation $VH$ de l'horloge, de sorte que dès que les $3$ minutes sont écoulées, le décompte s'arrête. La sortie $Q$ de la bascule sera reliée à l'alimentation d'un multivibrateur astable réalisé avec un $NE555$ de période $1$ seconde (avec les valeurs déjà évoquées), dont la sortie est elle-même reliée à l'alimentation d'un second multivibrateur astable. Ce dernier multivibrateur, toujours réalisé avec un $NE555$ avec une fréquence adaptée pour commander un bipeur piézoélectrique, qui émet un son quand il est stimulé par une fréquence proche de sa fréquence de résonance, de l'ordre de quelques kHz. On ne connaît pas la fréquence de résonance précise du composant utilisé : on utilisera alors une résistance variable pour déterminer expérimentalement une valeur qui produit un son satisfaisant.\\
+
+Pour ce dernier multivibrateur, on utilise un condensateur de $0,22$ \microf\ et une résistance $R8 = 500$ \ohm. On trouve alors des fréquences de l'ordre de quelques kHz pour des valeurs de $VR2$ de l'ordre de l'ordre de quelques k\ohm. De cette façon, on entendra un son émis en alternance sur une fréquence de $1$ Hz, qui correspondra à l'alarme sonore. Le bipeur est connecté à la sortie du dernier multivibrateur au travers d'un transistor (même considération que pour la LED) avec une résistance variable en série, pour contrôler son volume (et donc la consommation en courant).\\
 
-Le premier montage est réalisé très simplement. On obtient une fréquence d'environ $1$Hz avec les valeurs des composants suivantes :
+L'alarme sonore pourra être désactivée avec un bouton poussoir, relié d'une part au 5V et d'autre part à l'entrée R de la bascule RS, qui réinitialisera le système en plaçant l'état $Q$ à 0 et $\overline{Q}$ à 1 (l'horloge redémarre, les deux autres multivibrateurs ne sont plus alimentés). On remarque que les rebonds du bouton ne sont pas importants puisque seul un état haut sera actif sur l'entrée R (on réalisé un bascule à base de portes NON-OU/NI). Afin d'éviter un état indéterminé quand le bouton n'est pas pressé, on relie l'entrée R de la bascule à la masse, avec un faible résistance (on prendra $R5 = 500$\ohm).\\
 
-Pour le dernier montage, on cherchera plutôt à faire cuire un œuf à la coque (en $3$ minutes), toujours avec une base de temps de 30 secondes, de sorte à n'avoir besoin que d'un décompte jusqu'à $6$ que l'on peut obtenir avec $3$ bits. Le rappel lumineux sera émis toutes les $30$ secondes avec un durée de $15$ secondes (une demi-période de l'horloge) aura une durée de $30$ secondes
++ref photo ici
 
-insister sur VH et que quand la bascule a ~Q = 1 et bah le compteur y tourne et que quand c'est pas le cas que le compteur il tourne pas
-le potard c'est pour le volume (genre ça régule le courant)
+Expérimentalement, on pourra ajuster les valeurs des composants choisis, qui ne correspondent pas exactement aux valeurs indiquées (par exemple, un condensateur peut perdre de sa charge après un certain temps d'utilisation). Les composants utilisés ne sont d'ailleurs pas tous neufs : une grande partie provient de récupération sur des circuits quelconques.
index 9a6f607..096133a 100644 (file)
@@ -83,9 +83,16 @@ Au sein de la Cubieboard2, la communication avec le circuit intégré responsabl
 \item[--] Avec résistances de rappel au niveau haut\\
 \end{itemize}
 
-La ligne de données est notée $SDA$ et la ligne d'horloge $SCL$. Le schéma électrique de connexion de l'\bsc{AXP209} au SoC est détaillé en annexe \ref{axp209-i2c}.\\
+La ligne de données est notée $SDA$ et la ligne d'horloge $SCL$. Le schéma électrique de connexion de l'\bsc{AXP209} au SoC est détaillé avec la figure \ref{axp209} :
 
-On souhaite alors faire communiquer la Cubieboard2 avec le microcontrôleur Arduino, en utilisant le protocole \iic. La Cubieboard2 dispose de 5\footnote{Ref sur leA20 datasheet} composants dédiés à la gestion du bus \iic\ intégrés au sein de son SoC : il s'agit de contrôleurs \iic\ \bsc{Marvell MV64xxx}\footnote{Référence biblio: http://linux-sunxi.org/Used_IP_cores}. L'Arduino ne dispose par contre pas de contrôleur intégré. Il va s'agir d'implémenter la gestion du protocole \iic\ dans un programme qui sera exécuté sur l'Arduino, en utilisant deux lignes numériques d'entrée/sortie dont dispose le microcontrôleur de l'Arduino.\\ Ces lignes d'entrée/sortie se comportent d'après la logique trois états, avec un état haut, un état bas et un état hi-Z qui permettra la lecture. On pourra configurer le mode de chaque ligne avec des instructions. Les entrées/sorties sont plus précisément contrôlées en écrivant à des adresses mémoire précises (on parle de MMIO\footnote{Memory-Mapped Input/Output en Anglais, soit entrée/sortie cartographiée en mémoire en Français}) plutôt qu'avec des instructions directes pour le processeur (on parle de PIO\footnote{Programmed Input/Output en Anglais, soit entrée/sortie programmée en Français}).\\
+\begin{figure}[!h]
+\centering
+\includegraphics[width=9cm]{axp209.png}
+\caption{Schéma de connexion de l'\bsc{AXP209} au SoC}
+\label{axp209}
+\end{figure}
+
+On souhaite alors faire communiquer la Cubieboard2 avec le microcontrôleur Arduino, en utilisant le bus et le protocole \iic. La Cubieboard2 dispose de 5\footnote{Ref sur leA20 datasheet} composants dédiés à la gestion du bus \iic\ intégrés au sein de son SoC : il s'agit de contrôleurs \iic\ \bsc{Marvell MV64xxx}\footnote{Référence biblio: http://linux-sunxi.org/Used_IP_cores}. L'Arduino ne dispose par contre pas de contrôleur intégré. Il va s'agir d'implémenter la gestion du protocole \iic\ dans un programme qui sera exécuté sur l'Arduino, en utilisant deux lignes numériques d'entrée/sortie dont dispose le microcontrôleur de l'Arduino : ils'agit de la technique dite de bit banging.\\ Ces lignes d'entrée/sortie se comportent d'après la logique trois états, avec un état haut, un état bas et un état hi-Z qui permettra la lecture. On pourra configurer le mode de chaque ligne avec des instructions. Les entrées/sorties sont plus précisément contrôlées en écrivant à des adresses mémoire précises (on parle de MMIO\footnote{Memory-Mapped Input/Output en Anglais, soit entrée/sortie cartographiée en mémoire en Français}) plutôt qu'avec des instructions directes pour le processeur (on parle de PIO\footnote{Programmed Input/Output en Anglais, soit entrée/sortie programmée en Français}).\\
 
 Afin de relier les deux systèmes, on cherchera à connecter deux lignes, entre deux entrées/sorties numériques de l'Arduino et des connecteurs reliés aux points $SDA$ et $SCL$ de la Cubieboard2. Si les entrées/sorties numériques de l'Arduino sont disponibles en grande quantité, seul le contrôleur \iic\ identifié par l'index 1 est accessible par les connecteurs externes de la carte (dans la littérature spécifique au SoC \bsc{A20}, il est appelé $TWI1$\footnote{Two Wire Interface en Anglais, soit interface à deux fils en Français, terme équivalent à \iic.}). On relie alors les connecteurs reliés à $TWI1-SDA$ et $TWI1-SCK$\footnote{Référence : http://linux-sunxi.org/Cubieboard/ExpansionPorts}à l'Arduino.\\
 
@@ -102,20 +109,56 @@ Une fois les aspects matériels et logiciels en place, on peut commencer la réa
 
 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.\\
 
-Pour palier à ce problème, on a alors 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$.
+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$.\\
+
+Une fois tous les moyens de déterminer l'état du système en place, il a été possible de commencer l'implémentation du protocole \iic\footnote{La compréhension du protocole est basée sur les explications et les exemples de la référence \cite{WikipediaI2C} et des connaissances antérieures.}. On choisit de réaliser le programme sous la forme d'une machine à états\citenote{WikipediaAutomateFini}, avec un variable $state$ décrivant l'état du système. Les différents états possibles sont définis au début du programme et chaque état est décrit dans un commentaire associé. Dans la fonction principale ($main$) du programme, une boucle infinie ($while (1)$) assure l'interprétation du protocole en continu et contient un disjonction des cas sur l'état du système ($switch (state)$) attribue à chaque état les actions à réaliser, après avoir lu l'état des lignes du bus et gardé référence de l'état précédent.\\
+
+Les entrées/sorties sont effectuées par des lectures ou des écritures sur des ports données, formalisés par des adresses mémoire. On utilise les opérations booléennes du langage C pour effectuer les actions de lecture et d'écriture de bits aux adresses et aux bits nécessaires, tel qu'indiqué par la documentation du microcontrôleur\citenote{AVRDatasheet} et les déclarations de l'\bsc{avr-libc}. Ainsi, pour forcer l'état logique de la ligne de données, on écrira un bit dont le poids est défini par la définition $PORTB4$ à l'adresse donnée par la définition $PORTB$, soit en C : $PORTB |= (1 << PORTB4)$. Lors de l'implémentation, on fera attention à ne changer l'état du bus de données que sur un temps bas d'horloge et de ne lire l'état logique du bus imposé par le maître que sur un temps haut d'horloge, comme indiqué dans les spécifications du protocole I2C\citenote{WikipediaI2C}.\\
+
+Avec les protocole \iic, les données de l'esclave sont référencées par des adresses : on parle alors de registres, dont la taille vaut un octet. Le maître pourra lire ou écrire les données d'un registre en spécifiant son adresse. Notre implémentation dispose de $5$ registres, représentant $CPBx$ au format ASCII\acrotrad{American Standard Code for Information Interchange}{Code américain normalisé pour l'échange d'information} avec un octet final nul pour terminer la chaîne de caractères.\\
+
+L'ensemble du code source ainsi réalisé est reporté en annexe \ref{ardui2c}. Il est également disponible sur Internet\footnote{Le code source d'Ardui2c est disponible à l'adresse : http://git.paulk.fr/gitweb/?p=ardui2c.git;a=summary} au travers du système de gestion de version $git$, qui garde trace des modifications et permet de dupliquer aisément le code source. C'est un outil de gestion de code source aux visées communautaires, initialement développé par \bsc{Linux Torvalds} pour la gestion du code du noyau \bsc{Linux}, dont il est également l'auteur initial.
 
+\subsubsection*{Utilisation du programme}
 
-C'etst à \ref{ardui2c}.
+On montre l'utilisation du programme à partir de la Cubieboard2. Dans l'interpréteur de commandes \bsc{U-Boot}, il faudra tout d'abord sélectionner l'index du bus que l'on souhaite utiliser et la vitesse de l'horloge (on choisit $50$ kHz) :
+\begin{verbatim}
+sunxi# i2c dev 1
+Setting bus to 1
+sunxi# i2c speed 50000
+Setting bus speed to 50000 Hz
+\end{verbatim}
 
-écriture ardui2c,
-+ référence wikipedia sur le protocole
-+ on écrit sur les ports en mettant ou enlevant des bits (on utilise les opérations booléennes du langage C)
-+ on a le droit de changer que sur le temps bas et on lit sur le temps haut, donc on vérifie l'état de l'horloge avant chaque opération et si besoin on attend l'état de la ligne nécessaire.
-+ machine à états (penser à masse commenter le code comme ça pas besoin de l'expliciter dans le mémoire)
-+ parler un peu des registres
+On pourra alors détecter la présence de l'Arduino sur le bus avec la commande $i2c\ probe$ :
+\begin{verbatim}
+sunxi# i2c probe
+Valid chip addresses: 42
+\end{verbatim}
+L'adresse 0x42\footnote{Le préfixe $0x$ indique l'utilisation de la base 16, c'est donc $66$ en décimal.} est bien l'adresse attribuée à l'Arduino.\\
+
+On pourra alors lire les 5 premiers registres :
++TODO avec 4
+\begin{verbatim}
+sunxi# i2c md 0x42 0x00 0x5
+0000: 43 50 42 78 00    CPBx
+\end{verbatim}
+
+De même, il est possible de changer la valeur d'un registre et d'observer ce changement :
+\begin{verbatim}
+sunxi# i2c mw 0x42 0x00 0x50
+sunxi# i2c md 0x42 0x00 0x5
+0000: 50 50 42 78 00    PPBx
+\end{verbatim}
+
+On relève également l'activité sur le bus avec l'analyseur logique et le logiciel \bsc{PulseView}, qui offre en plus un décodage visuel du protocole \iic, présenté dans la figure \ref{chronogramme-ardui2c} :
+
+\begin{figure}[!h]
+\centering
+\includegraphics[width=\linewidth]{chronogramme-ardui2c.png}
+\caption{Chronogramme de transaction \iic\ entre la Cubieboard2 et l'Arduino}
+\label{chronogramme-ardui2c}
+\end{figure}
 
-+ montrer le prompt u-boot où ça marche et ça renvoie cpbx et on peut modifier
-+ chronogrammes AVEC l'interprétation de l'i2c dans pulseview
 \section{Optimisation des temps d'exécution des programmes}
 \subsection{Efficacité du traitement informatique et complexité}
 * Algorithmes et complexité, efficacité rapport au temps, qu'on peut optimiser mais ça dépend toujours de la visse d'exécution
@@ -128,4 +171,5 @@ C'etst à \ref{ardui2c}.
 \subsection{Explicitation du gain en efficacité et contraintes}
 + et bah la cubieboard2 elle est multicoeur et que pas la cubieboard1!
 * Conception de programmes parallèles c'est mieux, plus rapide => encodage + single coeur, 4 coeurs, cremi!
+* cependant tous les algos de s'y prètent pas (diviser pour régner c'est le cas)
 * Contraintes de synchronisation
index ac02443..fddcae5 100644 (file)
@@ -33,3 +33,21 @@ note={http://cubieboard.org/}
 title={Arduino},\r
 note={http://www.arduino.cc/}\r
 }\r
+\r
+@misc{WikipediaI2C,\r
+author={Wikipédia},\r
+title={I2C},\r
+note={https://fr.wikipedia.org/wiki/I2C}\r
+}\r
+\r
+@misc{WikipediaAutomateFini,\r
+author={Wikipédia},\r
+title={Automate fini},\r
+note={https://fr.wikipedia.org/wiki/Automate_fini}\r
+}\r
+\r
+@misc{AVRDatasheet,\r
+author={Atmel},\r
+title={Atmel 8-bit microcontroller with 4/8/16/32 kbytes in-system programmable flash datasheet},\r
+note={http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf}\r
+}\r
diff --git a/images/axp209.png b/images/axp209.png
new file mode 100644 (file)
index 0000000..bcb89f0
Binary files /dev/null and b/images/axp209.png differ
diff --git a/images/chronogramme-ardui2c.png b/images/chronogramme-ardui2c.png
new file mode 100644 (file)
index 0000000..87113f5
Binary files /dev/null and b/images/chronogramme-ardui2c.png differ
diff --git a/images/ne555-systemes.png b/images/ne555-systemes.png
new file mode 100644 (file)
index 0000000..dd5a5cb
Binary files /dev/null and b/images/ne555-systemes.png differ
index 501cf6c..39639a1 100644 (file)
Binary files a/images/schmitt.png and b/images/schmitt.png differ
diff --git a/images/systeme-alarme.png b/images/systeme-alarme.png
new file mode 100644 (file)
index 0000000..7a34109
Binary files /dev/null and b/images/systeme-alarme.png differ
diff --git a/images/systeme-led.png b/images/systeme-led.png
new file mode 100644 (file)
index 0000000..bb0748b
Binary files /dev/null and b/images/systeme-led.png differ
index 66c9455..e0c527a 100644 (file)
--- a/main.tex
+++ b/main.tex
 \newcommand{\derivd}[3][\null]{\frac{{\rm d}^{#1}#2}{{\rm d}#3^{#1}}}
 \newcommand{\e}[1]{\text{e}^{#1}}
 \newcommand{\ohm}{$\mathrm{\Omega}$}
+\newcommand{\microf}{$\mathrm{\mu}$F}
 \newcommand{\iic}{$\mathrm{I^2C}$}
 \newcommand{\citenote}[1]{\footnote{\label{#1-\thepage}Référence bibliographique \cite{#1}}}
 \newcommand{\cinenoteagain}[1]{\footnotemark[\getrefnumber{#1-\thepage}]}
 \newcommand{\citenotepage}[2]{\footnote{\label{#1-#2-\thepage}Référence bibliographique \cite{#1} page #2}}
 \newcommand{\citenotepageagain}[2]{\footnotemark[\getrefnumber{#1-#2-\thepage}]}
 \newcommand{\toldat}[1]{\footnote{\label{#1-\thepage}Cette notion sera détaillée dans la partie \ref{#1} en page \pageref{#1}.}}
+\newcommand{\acrotrad}[2]{\footnote{#1 en Anglais, soit #2 en Français.}}
 
 \captiondelim{~--~}
 \renewcommand{\figurename}{\textbf{Figure}}
 \renewcommand{\arraystretch}{1.3}
 
+\interfootnotelinepenalty=10000
+
 \graphicspath{{images/}}
 
 \lstset{language=C, numbers=left, basicstyle=\small, frame=lines, tabsize=2, breaklines=true, aboveskip=0.5cm, belowskip=0.5cm}
index 3e40bbd..c05dfc7 100644 (file)
@@ -448,9 +448,9 @@ La période du signal carré de sortie ne dépend que des paramètres choisis po
 
 Nous avons réalisé le montage de ce multivibrateur avec les paramètres suivant :
 \begin{itemize}
-       \item[--] $R_1=R_4=100$ $\Omega$
-       \item[--] $R_2=R_3=5.4$ k$\Omega$
-       \item[--] $C_1=C_2=120$ $\mu$F
+       \item[--] $R_1=R_4=100$ \ohm
+       \item[--] $R_2=R_3=5.4$ k\ohm
+       \item[--] $C_1=C_2=120$ \microf
 \end{itemize}\\
 
 Ce qui nous amène à une période théorique de $T\approx 1$ s, c'est-à-dire que notre signal a une fréquence théorique de $1$ Hz.\\