summaryrefslogtreecommitdiff
path: root/2004/n/fpga/doc/dcd/ovcam/ovcam.tex
diff options
context:
space:
mode:
Diffstat (limited to '2004/n/fpga/doc/dcd/ovcam/ovcam.tex')
-rw-r--r--2004/n/fpga/doc/dcd/ovcam/ovcam.tex122
1 files changed, 122 insertions, 0 deletions
diff --git a/2004/n/fpga/doc/dcd/ovcam/ovcam.tex b/2004/n/fpga/doc/dcd/ovcam/ovcam.tex
new file mode 100644
index 0000000..274a551
--- /dev/null
+++ b/2004/n/fpga/doc/dcd/ovcam/ovcam.tex
@@ -0,0 +1,122 @@
+
+\subsection{Gestion de la caméra}
+
+
+\subsubsection{Comment fonctionne la caméra ?}
+
+La caméra produit un flot de données 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 reconstituer une information cohérente avec
+notre vision.
+
+\begin{figure}[htbp]
+\caption{La caméra}
+\includegraphics[width=\textwidth]{./ovcam/ov6620.pdf}
+\label{schema1}
+\end{figure}
+
+Pour vérifier que nous avions bien compris le fonctionnement de la caméra,
+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[]{./ovcam/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 ralentit 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égulier" 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.
+
+\subsubsection{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émenter 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{Synoptique d'implémentation}
+\includegraphics[width=\textwidth]{./ovcam/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ée, c'est dire si le bit
+précédent est valide.
+\item Un bit disant s'il y a eu é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 différents
+compteurs et convertisseur.
+\item Un bit servant à dire que l'ordinateur va bientot lire un bank et
+donc, que le sequenceur doit baisser sa ligne d'interruption. Cette
+dernière fonction pourrait être remplacée par un système qui détecte la
+lecture du bank.
+\end{itemize}
+
+
+D'autres indicateurs pourraient être donnsé, par exemple : un flag pourrait se
+lever pour marquer que le bank de remplissage est déjà à moitié rempli.
+
+
+\subsubsection{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 caméra
+\item Lire le registre de la caméra pour savoir si il y a bien eu une
+interruption, et connaitre le bank à lire.
+\item Ecrire dans le registre le bit correspondant à "lecture imminente"
+\item Lire le bank, le placer en mémoire, incrémenter une variable. Lorsque
+cette variable sera égale à 50, l'ordinateur aura récupéré une image
+complète.
+\end{itemize}
+
+Bien sûr, si la cadence des images est trop rapprochée dans le temps, Une
+fois que l'on a récupéré une image complète, on peut ne pas écrire le bit
+"lecture imminente", ce qui aura pour conséquence de ne pas baisser la
+ligne d'interruption et de ne plus être dérangé.
+Pour reprendre la capture, il suffit de faire un reset avec le bit prévu
+dans le registre de contrôle.
+\pagebreak
+
+\section{Réalisation de la carte }
+
+La principale difficulté provient du logiciel. Toutefois cela avance,
+à en voir les documents produits. Ceux-ci sont encore tres incomplet. Toutefois
+ils permettent de déceler les premières grosses erreurs.
+
+
+