Quoi de neuf 2014

From Eric

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
 +
* 02/03/2011
 +
** Pas de progrès phénoménaux, mais la carte à caméra OV7670 est désormais capable de transmettre une image vers un PC via une connexion Bluetooth. Curieusement, le coupleur BT installé sur la carte n'est reconnu par un PC disposant d'un coupleur BT que très rarement (pour tout dire, je n'y suis parvenu qu'une fois!).
 +
Aussi, pour contourner le problème, j'ai réalisé une petite carte comportant le coupleur BT et un FT252RL, mais ça, je l'ai déjà dit...
 +
** J'ai acheté un XR2206 (6€) pour faire un petit générateur BF pas cher. On trouvera bienôt le montage dans la rubrique "Générateur BF à XR2206".
* 27/03/2011
* 27/03/2011
** Rien de bien neuf, la semaine ayant été laborieuse et le week-end sous aspirine. Néanmoins, j'ai réussi à faire la petite carte me permettant de connecter le coupleur Bluetooth à un PC via le bus USB. J'utilise le FT232 RL de FTDI, soudé au toaster. Je vais bientôt pouvoir récupérer l'image de ma caméra sur un PC standard pour visualiser une image complète (640x480)  avec un rendu correct des couleurs (l'écran Nokia - [[écrans LCD]] - n'est pas terrible de ce point de vue).
** Rien de bien neuf, la semaine ayant été laborieuse et le week-end sous aspirine. Néanmoins, j'ai réussi à faire la petite carte me permettant de connecter le coupleur Bluetooth à un PC via le bus USB. J'utilise le FT232 RL de FTDI, soudé au toaster. Je vais bientôt pouvoir récupérer l'image de ma caméra sur un PC standard pour visualiser une image complète (640x480)  avec un rendu correct des couleurs (l'écran Nokia - [[écrans LCD]] - n'est pas terrible de ce point de vue).

Revision as of 20:00, 2 April 2011

  • 02/03/2011
    • Pas de progrès phénoménaux, mais la carte à caméra OV7670 est désormais capable de transmettre une image vers un PC via une connexion Bluetooth. Curieusement, le coupleur BT installé sur la carte n'est reconnu par un PC disposant d'un coupleur BT que très rarement (pour tout dire, je n'y suis parvenu qu'une fois!).

Aussi, pour contourner le problème, j'ai réalisé une petite carte comportant le coupleur BT et un FT252RL, mais ça, je l'ai déjà dit...

    • J'ai acheté un XR2206 (6€) pour faire un petit générateur BF pas cher. On trouvera bienôt le montage dans la rubrique "Générateur BF à XR2206".
  • 27/03/2011
    • Rien de bien neuf, la semaine ayant été laborieuse et le week-end sous aspirine. Néanmoins, j'ai réussi à faire la petite carte me permettant de connecter le coupleur Bluetooth à un PC via le bus USB. J'utilise le FT232 RL de FTDI, soudé au toaster. Je vais bientôt pouvoir récupérer l'image de ma caméra sur un PC standard pour visualiser une image complète (640x480) avec un rendu correct des couleurs (l'écran Nokia - écrans LCD - n'est pas terrible de ce point de vue).
  • 19/03/2011
    • Alléluia! Ma caméra a enfin produit une image. la voila :
      Ov7670-first-picture.jpg
      qu'il faut comparer à l'objet filmé...
      Ov7670-first-model.jpg
    • Ce (relatif) succès a été obtenu après quelques soucis essentiellement dus à ma mauvaise gestion des interruptions. En effet, le LPC1768 offre une gestion assez sophistiquée, bien éloignée de ce que j'avais jusqu'ici utilisé (Z80,...). Ainsi, lors de l'occurrence d'un front montant du signal VSYNC, une interruption de type EINT3 est levée. Pour que le processeur soit interrompu il faut activer la génération d'une IT sur front montant du signal, démasquer l'interruption EINT3 et activer les interruptions (et réciproquement pour inhiber l'interruption).
    • Le résultat n'est pas génial... pour diverses raisons dont l'une ne m'appartient pas : la caméra est affublée d'un objectif de très faible profondeur de champ. Je devrais pouvoir réduire ce problème en mettant un diaphragme (un masque percé d'un trou) devant la lentille... à voir. En tout cas, je ne suis pas certain que je puisse distinguer proprement un point lumineux issu d'un laser.
    • Les détails sur la carte de contrôle de la caméra se trouve dans la rubrique Caméra OV7670.
  • 18/03/2011
    • Tremblement de terre, tsunami et catastrophe nucléaire imminente au Japon. Kadhafi s'accroche. Aristide revient. Tout va bien dirait Pangloss.
    • Je n'arrive toujours pas à obtenir une image de ma caméra. Un petit passage sur analyseur logique m'a permis de comprendre l'une des raisons de cet échec (il y en a certainement d'autres à découvrir).
      • Je rappelle que j'utilise les fronts montant du signal VSYNC de la caméra pour réaliser l'acquisition d'une image.
      • Lorsque je veux acquérir une image, je réinitialise les pointeurs de la FIFO, je signale (dans la variable d'état du handler d'IT) que je souhaite faire une acquisition et, enfin, j'autorise les interruptions sur l'IT EINT3.
      • Lors du prochain front montant sur VSYNC, le signal WE est activé (ce qui va permettre l'écriture dans la FIFO, sachant que le signal WCLK est quant à lui toujours actif pour permettre le rafraîchissement de la DRAM de l'AL422), et la variable d'état est modifiée pour indiquer une acquisition en cours.
      • Lors du prochain front montant de VSYNC, l'acquision est arrêtée : le signal WE est désactivé et la variable d'état reprend la valeur correspondant à une attente.
      • De son côté la fonction appelée pour réaliser l'échantillonnage scrute cette variable et abandonne la scrutation dès qu'elle reprend la valeur correspondant à une attente (ce qui signifie la fin de l'échantillonnage). (Naturellement, ce schéma de scrutation sera remplacé par quelque chose d'un peu plus efficace basé sur les services de l'OS, mais c'est suffisant pour l'instant.)
      • Le problème réside dans le fait que VSYNC génère des fronts en permanence donc, dès que j'autorise les interruptions, je pars immédiatement dans le handler d'IT, de façon complètement asynchrone avec le signal VSYNC! La solution est simplement d'effacer le bit indiquant la présence d'une éventuelle (voire certaine) IT pending avant de libérer les interruptions! C'est effectivement évident, mais en l'abscence de moyen de mesure / debug adapté, l'erreur est difficile à identifier...
      • Un petit schéma ci-après pour illustrer tout ça...
        Ov7670 sync it.jpg
    • J'ai rajouté des capas de découplage un peu partout... on ne sait jamais...
  • 15/03/2011
    • Les premiers essais d'affichage des données de la caméra ne sont pas concluants, loin s'en faut : l'image est parfaitement incohérente et même la relecture de la FIFO sans modification du contenu (et après réinitialisation du pointeur de lecture) ne donne pas une "image" stable... [Edit au 18/03: il s'agissait d'un problème de câblage : le signal WE était activé inopinément...]
    • Si on fait l'hypothèse que le chip n'est pas défaillant, la seule bonne raison pour que le contenu "varie" lors de deux lectures successives est que le contenu a effectivement changé entre ces deux lectures, et la seule bonne raison pour qu'il ait changé sans opération d'écriture est que le rafraichissement n'ait pas été assuré.
      • En ragardant mon schéma, je m'aperçois que le signal WCLK, qui est utilisé (dans mon cas) pour assurer le rafraichissement de la DRAM de la FIFO n'a pas toujours une fréquence supérieure ou égale à 2MHz (voir notice du composant) puisqu'il est obtenu par un ET entre PCLK et HREF. Tout va bien lorsque HREF est à l'état haut (transmission des pixels d'une ligne), mais que ce passe-t-il lorsqu'il passe à l'état bas entre deux lignes?
    • La correction consiste à connecter directement PCLK sur WCLK (ce qui assure une horloge constante pour le rafraichissement) et à contrôler l'écriture à l'aide de WE (comme cela est d'ailleurs clairement dit dans la notice). Le signal WE de la mémoire est obtenu par un ET entre HREF et un signal WEc (positif) issu du microcontrôleur, suivi d'une inversion : WE = non (HREF et WEc). A suivre..."
  • 14/03/2011
    • J'ai intégré la mémoire FIFO (Avermedia) sur la carte d'acquisition vidéo. Pour l'instant, je ne peux afficher l'image aussi ne suis-je donc pas certain que le stockage se passe parfaitement, mais ce que j'observe à l'oscilloscope est de bonne augure.
    • J'ai réalisé les 4 lignes de code qui permettent de capturer une image : j'utilise le signal de début de trame (frame) pour générer une interruption sur le LPC1768 ; la routine d'interruption correspondante vérifie l'état d'un indicateur positionné par la fonction de demande d'acquision d'image ; si cet indicateur est positionné, le signal d'autorisation d'écriture (WREN) est activé, ce qui permet le stockage des données dans la FIFO ; il est désactivé à la prochaine interruption.
    • J'ai branché un petit écran Nokia 3510 sur la carte. J'ai écrit le driver qui permet de l'initialiser et d'afficher une chaîne de caractère. Il ne reste désormais plus qu'à l'utiliser pour afficher le contenu de la FIFO...
    • Au passage : j'ai ajouté d'une section sur les écrans LCD. Pour l'instant, on y décrit que le Nokia 3510 utilisé sur la carte d'acquisition vidéo.
  • 08/03/2011
    • Après pas mal de déboires avec l'I2C sur LPC1768 (essentiellement du au non respect de la règle : "quand tu modifies une ligne de code, c'est pas parce que ça marchait avant que ça marchera après, surtout après avoir changé un "|" en "||"), je suis parvenu à faire sortir une trame I2C à la bête.
    • Après m'être rendu compte que la caméra avait besoin d'un signal d'horloge externe (nommé XCLK), de fréquence 24MHz ; après avoir réalisé un petit oscillateur à 74HC04 et branché le tout, la caméra daigne comprendre les commandes que je lui envoie. C'est un grand jour.
    • La simple présence d'un signal d'horloge suffit à ce que la caméra génère un flot de données : la valeur de défaut des registres semble être cohérente.
    • J'ai utilisé le driver Linux de l'OV7670 pour récupérer les valeurs de registre permettant une initialisation correcte. La séquence d'initialisation se déroule bien. Il reste à placer la mémoire de stockage...
  • 04/03/2011
    • La nouvelle carte, destinée à recevoir la caméra OV7670 prend forme. Elle dispose du connecteur permettant d’accueillir la carte LPC1768 nue. Elle comporte les deux alimentations, 2.8V (caméra) et 3.3V (logique), et trois petites LEDs.
    • J'ai rencontré quelques difficultés à faire fonctionner cette carte avec ma configuration de la sonde JTAG (500KHz) et ma configuration de l'horloge du LPC1768 (100MHz). J'ai réduit tout ça à des valeurs plus raisonnables (100KHz, et 40MHz). Ouf, ça fonctionne.
    • Je débute les tests de l'I2C sur LPC1768 et l'OS FreeRTOS...
  • 28/02/2011
    • Ai rajouté la page A retenir pour collecter toutes les bonnes leçons dont il faut que je me souvienne pour éviter que mon cimetière de composants ne s'accroîsse dangereusement...
  • 26/02/2011
    • Kyrie Eleison! : j'ai enfin connecté la carte de commande de "puissance" des moteurs de Trobot1 le-bien-nommé avec la carte de contrôle (Atmega32). Le "radar" (c'est-à-dire le coupleur optique Sharp utilisé pour la mesure distance monté sur le moteur pas-à-pas) fonctionne, ainsi que tout le reste. Il s'agit maintenant d'écrire un peu de logiciel pour que la bête s'anime. Au passage, on s'aperçoit bien vite de l'intérêt d'un moniteur temps-réel...
    • J'ai fait ma deuxième tentative de soudage d'un SSOP28 (toujours le même chip de FTDI). Un succès! Le "truc" : (i) utiliser le moins de soudure possible, quitte à enlever le surplus ; (ii) faire préchauffer le four. Je comprends maintenant pourquoi la pâte à souder est vendu en si petit conditionnement : j'en ai pour 10 ans. En une minute zou! la soudure est faite, et sans ponts intempestifs. Je peux désormais m'attaquer à du "lourd" : TQFP64 dont le "pitch" est le même que le SSOP28 : 0.8mm. (Mise à jour : en voulant tester le dit FTDI, je me suis trompé d'orientation (hum...). Bilan : un "doigt qui pique" (comme dirait Victor) et un FTDI qui fonctionne encore (robuste l'animal)... Les dégâts auraient pu être plus graves : un doigt brûlé, un FTDI brûlé et un PC brûlé.
    • J'ai attaqué la carte destinée à contrôler la caméra OV7670 : le support est réalisé ainsi que l'alimentation 3.3V et 2.8V. La leçon du jour : se souvenir qu'un régulateur qui n'est pas low-drop ne peut pas réguler si Vo = Vi - 0.5V !!!
    • Je suis parvenu à connecter l'un de mes PC au coupleur Bluetooth embarqué, mais une seule fois... Il est impossible de parvenir à une connexion systématique, même avec le magnifique dongle Blutooth à 2€80 que j'ai déniché !
  • 22/02/2011
  • 20/02/2011
    • Urobot1est pratiquement opérationnel : les roues sont montées sur le "chassis" et une petite carte d'interface a été créée pour connecter les moteurs à la carte Arduino.
    • J'ai essayé les cartes de communication Bluetooth : un demi-succès puisque si l'une des deux cartes fonctionne bien et s’appaire gentiment avec mon téléphone portable, l'autre ne donne aucun signe de vie.
  • 15/02/2011
    • Ajout d'une section concernant la génération de signaux PWM (ou MLI en français) dans la page sur l'Atmega32.
  • 14/02/2011
    • La carte de contrôle de Trobot1 est achevée et est connectée avec la carte de commande de puissance. Le code de génération des signaux PWM pour les moteurs (droit et gauche) fonctionne (10 lignes!). Il reste à finaliser la commande des moteurs pas-à-pas...
    • Les servo-moteurs du robot sur base Arduino ont été modifiés et les supports de fixation sur le chassis ont été réalisés.
    • J'ai commandé quelques dSPic 30F4011 ; ce type de microcontrôleur est un compromis, en terme de capacités, entre un Arm7 (qu'il est impossible de souder soi-même...) et un Atmega32.
    • Création de la page sur Urobot1, le robot de Frédéric.
  • 02/02/2011: Ajout d'un petit paragraphe sur les caméras... sur la page intitulée "Utilisation d'une caméra avec un microcontrôleur".
  • 01/02/2011: autoréférence car il s'agit de l'événement de création de la page "quoi de neuf".
Personal tools