Quoi de neuf 2014

From Eric

• 11/06/2011
  • La carte "réveil" est achevée. Elle ne présente aucune difficulté particulière au niveau matériel. Par rapport à ce que je décrivais précédemment, j'ai supprimé le LS138 pour une bonne raison : ça marche pas... en effet, une lecture un peu attentive de la documentation du 138 (et surtout : un peu de bon sens) m'aurait permis de voir que les sortie du démux sont actives au niveau bas... ce qui se justifie, le 138 étant utilisé en général pour faire du décodage d'adresse, mais qui ne convient pas à l'utilisation que j'en fais. J'ai donc simplement supprimé le démux --- qui me permettait de n'utiliser que 3 sorties de l'Atmega pour piloter la colonne active --- et j'utilise bêtement 8 sorties pour les cathodes et 8 sorties pour les anodes (via l'ULN2803).
  • Il me reste à réaliser le logiciel de pilotage de la chose, à savoir :
    • un séquenceur cyclique cadencé par un timer de l'ATMEGA
    • la tâche cyclique de rafraichissement de la matrice (8 octets correspondant aux 8 colonnes, une colonne est rafraichie par cycle)
    • la tâche cyclique de scrolling de l'affichage, afin de pouvoir afficher des messages un peu longs...
    • la tâche de contrôle du réveil (programamtion de l'IT du PCF8583)
    • la tâche de programmation et de réglage du réveil
    • une tâche d'animation de l'affichage
    • une tâche de génération de son (utilisant le deuxième timer...)
• 06/04/2011
  • J'ai délaissé un peu le problème de la lecture des données en provenance de ma caméra (voir le précédent billet) pour bricoler un petit réveil à base d'Atmega32. Outre le microcontrôleur, la carte comprend une horloge temps-réel sur I2C, un FT232RL afin de pouvoir charger les heures de réveil à partir d'un PC, un buzzer, une horloge temps réel sur I2C (PCF 8583), et une matrice de LEDs (8x8) pilotée par le couple 74LS138+ULN2803 d'un côté et par le microtronrôleur de l'autre. L'ULN2803 me permet de drainer le courant des 8 LEDs d'une même ligne (soit environ 8x10mA=80mA). A la date d'aujourd'hui, les composants sont placés sur la carte et il reste à souder le tout... et à écrire le logiciel.
  • Jeter un oeil sur le composant SAA7113H de NXP, qui permet de faire de l'acquisition vidéo... peut-être une voie intermédiaire entre la caméra numérique (type OV7670) et le couple caméra analogique + micro-contrôleur.
• 02/04/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...
  • La gestion de la ligne série côté ARM7 n'est pas difficile. Je n'utilise pour l'instant pas les interruptions... on verra plus tard.
  • La lecture des données côté PC est plus laborieuse : j'utilise la "Java Communication API" et son implémentation pour Windows RXTX (dont on trouvera la FAQ, [ici]).
  • J'ai acheté un XR2206 (6€) pour faire un petit générateur BF pas cher. On trouvera bientôt le montage dans la rubrique Générateur BF à XR2206.
  • J'ai commencé la réalisation d'un petit moniteur TR pour l'Atmega, à grand coup de setjmp / longjmp. Ca n'est pas bien compliqué, mais la gestion de la pile lors des commutation de tâches me laisse encore un peu perplexe... A creuser.
  • J'ai rajouté une rubrique "poésies" (non pas que je sois grand amateur, loin s'en faut), mais certains poèmes sont de véritables soulagements...
• 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. En voici la photo:
    

    

• • 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 :
    

    
    qu'il faut comparer à l'objet filmé...
    

    
  • 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...
      

      
  • 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
  • Ajout d'une page sur les coupleurs bluetooth BTM-5
  • Ajout d'une page sur la caméra OV7670 et son couplage à la FIFO AL422.
• 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".

--192.54.144.229 13:10, 11 April 2011 (CEST)