Caméra OV7670
From Eric
m (La caméra OV7620) |
m |
||
| Line 1: | Line 1: | ||
| + | Cette caméra est notamment utilisée sur le robot [[Trobot1]]. | ||
= Caractéristiques générales = | = Caractéristiques générales = | ||
Revision as of 11:25, 22 February 2011
Cette caméra est notamment utilisée sur le robot Trobot1.
Caractéristiques générales
Voici une vue du brochage de cette caméra.
L'OV7620 dispose d'un nombre important de fonctions accessibles via un bus compatible I2C (SCCB). L'image, quant à elle, n'est pas accessible sur le port I2C : elle est transmise de façon autonome sur un bus parallèle rapide.
Alimentation
L'OV7620 doit être alimentée en 2.8V (la tension du coeur numérique, 1.8V, est obtenue par un régulateur intégré à partir de la tension VIO).
Stockage et accès aux images
La caméra transmettant une image en "continu" avec un débit important, il conviendra de la connecter soit sur un microprocesseur suffisamment rapide pour acquérir les données, soit sur une mémoire tampon à partir de laquelle le microcontrôleur accèdera à l'image.
Cette mémoire tampon doit pouvoir être écrite d'un côté par la caméra et lue, de l'autre côté par le microcontrôleur. Cela assure, au moins, qu'une image pourra être traitée complètement avant acquisition de l'image suivante. La perte d'information porte sur les images successives, et non sur les pixels d'une image. A cette fin, j'utilise la mémoire AL422B [AL422B] produite par Avermedia.
A noter :
- En gros, on favorise la cohérence des pixels d'une image aux dépens de la latence minimale garantie entre un événement et son observation par la caméra.
- Avec un microcontrôleur type dsPic ou Arm7, il doit être possible d'échantillonner le signal vidéo sans perte (voir par exemple l'article <a compléter>). Cette solution impose dependant l'entière disponibilité du micro-contrôleur pendant la phase d'échantillonnage. En outre, je souhaite une solution aussi indépendante que possible des performances du microcontrôleur.
- On pourrait aussi utiliser directement de la DRAM (par ex. une barette de mémoire de PC, anciens modèles, dont mes tiroirs regorgent). Mais il faudrait alors générer les signaux de rafraîchissement, les signaux d'adresse, et gérer les accès multiples (quoique séquentiels)... Cette solution fera probablement l'objet d'une prochaine expérience...
La mémoire AL422B est une FIFO de 384K octets (3Mbits) à deux ports : un port d'écriture connecté à la caméra et un port de lecture connecté au microcontrôleur.
S'agissant d'une FIFO, cette mémoire n'a pas besoin qu'on lui fournisse l'adresse où stocker la donnée : celle-ci est simplement écrite en queue de la FIFO. La gestion des adresses est réalisée en interne par le composant. Il fournit cependant deux signaux de reset (en écriture et en lecture) pour repositionner le pointeur.
L'AL422B utilise une mémoire dynamique (DRAM) qui requiert donc un rafraîchissement périodique. Les signaux d'horloge en écriture (WCK) et en lecture (RCK) sont utilisés pour générer le signal de rafraîchissement de la mémoire (The faster one of WCK and RCK is used as the DRAM refresh timing clock). Ce signal doit avoir une fréquence d'au moins 1Mhz. Dans notre cas, la caméra fournit un signal vidéo permanent, cadencé par l'horloge PCLK (Pixel Clock). L'horloge PCLK fournissant le signal d'écriture en FIFO, il assure aussi le rafraîchissement de la RAM dynamique.
Dans cette configuration, la séquence d'opération est la suivante :
- le microcontôleur configure la caméra par le biais du bus I2C ;
- la caméra effectue l'acquisition vidéo et stocke l'image dans la FIFO ;
- le microcontrôleur attend la fin de la transmission ;
- le microcontrôleur récupère l'image dans la FIFO.
La caméra fournit les signaux nécessaires au pilotage direct de la FIFO :
- un signal d'horloge (pixel clock ou PCLK)
- un signal de synchronisation horizontale (HREF)
- un signal de synchronisation verticale (VSYNC)
- un bus de données de largeur 8 bits (D0 à D7)
La FIFO dispose quant à elle des signaux suivants (en entrée):
- Un bus de données de largeur 8 bits
- Un signal d'horloge en écriture (WCK). Si l'écriture est autorisée (signal WE actif), la donnée présente sur le bus est stockée en mémoire et le compteur interne (qui fournit l'adresse) est incrémenté. Le compteur peut être réinitialisé à zéro en activant le signal WRST (Write reset).
Voici le chronogramme d'accès en écriture de la FIFO :
Et voici le chronogramme de production des données par la caméra :
On constate que la caméra peut donc directement "piloter" la FIFO. Pour celà, il suffit de
- connecter les deux bus de données
- réaliser un ET logique entre le signal de synchronisation horizontale HREF et l'horloge pixel (PCLK) et connecter la sortie du ET à l'entrée WCK de la FIFO.
Le signal de synchronisation verticale, VSYNC, permet de détecter le début d'une image et, par conséquent, permet de générer le signal de reset de la FIFO (WRST).
Le schéma d'interconnexion est donné ci-après:
La AL422B ne permet pas la lecture d'une donnée immédiatement après son écriture : il faut attendre au moins 128 cycles de WCK pour être certain de lire une donnée récente. Ce comportement est du à la présence d'une mémoire cache statique au sein du composant.
Dans notre cas, nous pourrions espérer procéder ainsi :
- Le microcontrôleur réinitialise le pointeur d'écriture et de lecture.
- Le microcontrôleur demande l'acquisition d'une image ; l'image est stockée de façon autonome par la caméra. Après un délai correspondant à au moins 128 cycles de WCK, le microcontrôleur lit les données de la FIFO, les traite ou les transfère dans la mémoire centrale.
- Le cycle recommence.
Malheureusement, il n'est pas possible de demander à la caméra de ne réaliser qu'une image : celle-ci effectue ses acquisitions en boucle.
Une solution consiste à utiliser le signal "VSYNC" et à contrôler le signal WE (Write Enable) de sorte que, une fois le signal VSYNC reçu, on inhibe l'écriture en FIFO pour procéder à la lecture.
<A compléter>
