summaryrefslogtreecommitdiff
path: root/2004/n/fpga/doc/dcd/ovcam/ovcam.tex
blob: e0ac5dff9fc676d9a4143a139424870f546de5a3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
\subsection{Gestion de la cam�ra}


\subsubsection{Fonctionnement de 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{Impl�mentation de la r�cup�ration d'une 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.