summaryrefslogtreecommitdiff
path: root/2004/n/fpga/doc/dossierconception/ovcam.tex
diff options
context:
space:
mode:
Diffstat (limited to '2004/n/fpga/doc/dossierconception/ovcam.tex')
-rw-r--r--2004/n/fpga/doc/dossierconception/ovcam.tex120
1 files changed, 120 insertions, 0 deletions
diff --git a/2004/n/fpga/doc/dossierconception/ovcam.tex b/2004/n/fpga/doc/dossierconception/ovcam.tex
new file mode 100644
index 0000000..b686b02
--- /dev/null
+++ b/2004/n/fpga/doc/dossierconception/ovcam.tex
@@ -0,0 +1,120 @@
+
+\section{Gestion de la caméra}
+u
+
+\subsection{Comment fonctionne la caméra ?}
+
+La camera produit un flot de donnée incessant. elle fournit aussi des
+signaux de synchronisation. Ceux-ci nous permettent de savoir quand est-ce
+qu'une nouvelle image commence, quand est-ce que l'on change de ligne. De
+cette manière nous pouvons reconstitué une information cohérente avec
+notre vision.
+
+\begin{figure}[htbp]
+\caption{La camera}
+\includegraphics[width=\textwidth]{ov6620.pdf}
+\label{schema1}
+\end{figure}
+
+Pour vérifier que nous avions bien compris le fonctionnement de la camera,
+nous avons écrit un programme pour micro-contrôleur qui saisie une image.
+
+Pour réaliser cette application teste, nous avons utilisé une carte à base
+de 68HC11F1 à 8MHz doté de 64Ko de mémoire. Voici le résultat: figure
+\ref{image_test} page \pageref{image_test}.
+
+\begin{figure}[htbp]
+\caption{L'image test}
+\includegraphics[]{image.png}
+\label{image_test}
+\end{figure}
+
+Pour obtenir cette image nous avons écrit un programme en C avec gcc pour
+68HC11. Ce programme prend 72 lignes d'une première image puis les envoie
+à l'ordinateur à 9600 baud (c'est très lent) puis attend une nouvelle
+image, saute les 72 premières lignes et enregistre les 72 lignes
+suivantes puis les envoie. Ainsi de suite 4 fois par image car Le
+microcontroleur n'a pas assez de mémoire pour enregistrer l'image entière.
+Il faut donc la "tronçonner". En effet l'image fait normalement 352
+par 288 pixel et chaque pixel est codé sur 8 bits.
+
+La caméra dispose d'un réglage de gain automatique c'est pour cela que les 4
+parties ont des contrastes différents.
+
+Bien que l'on ait ralenti au maximum la fréquence de Pclk, nous
+n'arrivons à obtenir que 72 point par lignes au lieu de 288.
+Comme l'image reste "compréhensible" nous pouvons croire que le
+microcontroleur n'est pas assez rapide pour lire plus de points. Et du
+coups il fait un "sample régulié" de la ligne, ce qui nous donne cette
+impression d'image comprimé en largeur.
+
+Tout ceci nous laisse croire que nous maitrisons la capture d'une image.
+
+\subsection{Comment implémenter la récupération d'image dans un fpga ?}
+
+Le principe utilisé est simple, il s'agit de remplir une mémoire avec les
+données provenant de la caméra. Un compteur peut incrémenté l'adresse et
+ainsi parcourir la mémoire. Nous allons utilisé les macros que fournit
+Xilinx pour réaliser des DPRAMs : qui sont des mémoires ram à double
+ports, permettant une lecture et une écriture sur deux ports differents.
+
+Nous utiliserons 2 DPRAM afin que l'ordinateur puisse lire un bank mémoire
+alors que l'automate de récupartion de donnée caméra en remplit un autre.
+
+\begin{figure}[htbp]
+\caption{Synopitque d'implémentation}
+\includegraphics[width=\textwidth]{ovcam2.pdf}
+\label{ovcam}
+\end{figure}
+
+Ce système est ordonné par un séquenceur. Cette machine d'état aura la
+charge de choisir le bank à remplir, la gestion de la ligne d'interruption
+( moyen d'avertir d'ordinateur pour qu'il vienne lire) et le registre de
+contrôle avec ses quelques bits:
+\begin{itemize}
+\item Un bit disant quel bank doit être lu.
+\item Un bit disant si l'interruption est levé, c'est dire si le bit
+précédant est valide.
+\item Un bit disant s'il y a eu un écrasement d'un bank, dans le cas ou
+l'ordinateur ne serait pas venu suffsament tôt.
+\item un bit de reset pour remettre à zero la machine d'état les diffrents
+compteurs et convertisseur.
+\item Un bit servant à dire que l'odinateur va bientot lire un bank et
+donc, que le sequenceur doit baissé sa ligne d'interruption. Cette
+dernière fonction pourrait être remplacer par un système qui détecte la
+lecture du bank.
+\end{itemize}
+
+
+D'autres indicateurs pourraient être donné, par exemple : un flag pourrait se
+levé pour marqué que le bank de remplissage est déjà à moitier rempli.
+
+\subsection{Le driver}
+
+Avec le fonctionnement décrit si dessus, Le driver devra réaliser la
+sous-routine suivante:
+\begin{itemize}
+\item Détecter une interruption camera
+\item Lire le registre de la camera pour savoir si il y a bien eu une
+interruption, et connaitre le bank à lire.
+\item Ecrire dans le registre le bit correspondant à "lecture imminante"
+\item Lire le bank, le placé en mémoire, incrémenté une variable. Lorsque
+cette variable sera égal à 50, l'ordinateur aura récupéré une image
+complete.
+\end{itemize}
+
+Bien sûr, si la cadence des images est trop rapproché dans le temps, Une
+fois que l'on a récupérer une image complete, on peut ne pas écrire le bit
+"lecture imminante", ce qui aura pour conséquence de ne pas baissé la
+ligne d'interruption et de ne plus être déranger.
+Pour reprendre la capture, il suffit de faire un reset avec le bit prévu
+dans le registre de controle.
+\pagebreak
+
+\section{Réalisation de la carte }
+
+La principale difficulté provient du logiciel. Toutes fois cela avance,
+à en voir les documents produits. Ceux-ci encore tres incomplet. Toutes
+fois ils permettent de déceller les premières grosses erreurs.
+
+