Quoi de neuf 2014

From Eric

Revision as of 10:30, 22 June 2011

• 18/06/2011
  • Well, well... Après avoir réalisé la partie "décodeur MP3" à base de VS1053b, j'ai branché le tout et appliqué la procédure de vérification de VLSI Solution. Premier test : premier échec. La partie analogique ne fonctionne pas. Après vérification, il s'est avéré que les broches n'étaient pas convenablement soudées. Tentative de resoudage et échec. Finalement, j'ai découpé la plaquette pour supprimer la partie MP3. Je vais faire une nouvelle tentative avec le chip ST013 de STMicro et le convertisseur DAC CS4334 sur I2C de je-ne-sais-plus-qui. Je mettrais le tout sur une carte fille connectée par un HE10 à 10 fils (ça tombe bine, j'en ai...). Bref, c'est pas une réussite.
  • Je commence à regarder comment réaliser un quadricoptère. Ca me permettrait de faire un peu d'autom. La partie mécanique n'est pas trop complexe (une plateforme en alu ou fibre de verre et quatre branches en fibre de carbone) ; les moteurs brushless ne sont pas trop onéreux, pas plus que les cartes de contrôle. A suivre.
• 04/06/2011
  • J'ai commencé la réalisation d'un lecteur MP3/WMA sur la base du VS1053b de VLSI Solution, d'un PIC32MX360F512 (512KB de flash, 32K de RAM) et d'un écran LCD couleur 240x320à contrôleur ILI9325. A la date d'aujourd'hui, je suis simplement parvenu à faire fonctionner le PIC sous FreeRTOS (OS que j'ai déjà utilisé pour le montage comportant une caméra vidéo et un ARM7), ainsi que l'écran couleur... après les quelques déboires habituels.
  • J'ai tenté d'utiliser le mode PMP du PIC32 qui permet de générer automatiquement les signaux d'adresse, de donnée, de contrôle (RD, WR, ENB) utilisés lors de l'accès à un composant mémoire, par exemple. Bon, je ne suis pas parvenu à faire fonctionner l'écran ainsi, alors que les signaux semblent bien générés. Il s'agit (peut-être) d'un problème de vitesse (le PIC fonctionne à 80MHz, obtenu par multiplication de la fréquence de 8Mhz générée par un circuit RC interne). Finalement, je gère les différents signaux "à la main", ce qui n'est ni très élégant ni très efficace...
  • J'utilise la bibliothèque graphique fournie par MicroChip. Elle ne demande que l'écriture de quelques lignes de code d'accès au matériel (driver). Je suis parti d'un code existant que j'ai adapté pour procéder à des accès sur 16 bits ; j'ai fait aussi quelques modifications des paramètres d'initialisation du chip pour "coller" au code qui m'a été fourni avec l'écran.
• 30/05/2011
  • Le télémètre à ultrasons est achevé. J'ai rajouté un petit PIC 10F200 (8 broches) pour contrôler l'émission du top et "filtrer" l'écho. J'avais pour idée de transmettre la distance sous forme numérique. C'est faisable mais, pour l'instant, je me contente d'émettre un créneau dont la durée est proportionnelle à la distance. Voici une photo de la chose, une fois terminée :
    

    
  • A noter qu'il est important de réduire les fils de connexion du transducteur émetteur. Des fils trop longs (environ 20 cm), agissaient comme des antennes : je recevais un "pic" sur l'entrée (côté récepteur) même en l'absence de capteur. J'ai raccourci les fils et ai utilisé des fils blindés... ça marche beaucoup mieux...
• 21/05/2011
  • J'ai abandonné l'idée d'utiliser une PLL (NE567) pour détecter l'écho dans mon télémètre à ultrasons : la PLL met un temps assez variable pour détecter le signal, ce qui induit une grande incertitude sur la mesure. En outre, un transducteur US constitue un filtre (mécanique) suffisant centré autour de sa fréquence de résonance (44Khz). Il n'est donc pas indispensable de rajouter un filtre hyper sélectif sur le signal après amplification.
  • Aussi, je me contente désormais d'amplifier le signal reçu par le transducteur US, à y appliquer un seuil et un monostable. Le monostable n'est pas franchement indispensable dans la mesure où on utilise un microcontroleur.
  • Le monostable est obtenu en rebouclant la sortie de l'ampli-op de seuil (inverseur) sur l'entrée non inverseuse. On trouvera le schéma complet dans la rubrique. On y trouvera aussi une petite vidéo explicative.
  • J'ai décidé de m'essayer à la réalisation de petites vidéos explicatives. J'utilise Movie Maker de Microsoft, qui a le mérite d'être simple et rapide. J'ai essayé l'outil Cinerella sur Linux : c'est très puissant. L'IHM est inhabituelle (euphémisme) et la stabilité incertaine (comme d'habitude). Les aficionados de Linux expliqueront en long, large et en détails pourquoi ça marche beaucoup mieux que sous Windows, pourquoi c'est beaucoup plus stable, etc., etc. L'OS est stable, c'est sûr ; quant aux applications, c'est une autre affaire... or ce qui m'intéresse, ici, c'est l'application.
  • J'ai aussi essayé Blender, qui propose aussi un moyen de "réaliser des films" à partir de diverses sources. Là, le problème n'est pas la stabilité, mais simplement la complexité : l'outil est excessivement riche et, pour ma part, je n'ai que des besoins modestes...
• 15/05/2011
  • J'ai repris le télémètre à ultrasons, l'un de mes premiers montages... L'émission du signal ultrasonore et la réception de son écho fonctionnent relativement bien.
  • Je n'utilise pas de filtre en sortie de l'amplificateur (côté récepteur), mais un détecteur à base de PLL (NE567) de fréquence centrée sur 44KHz. On constate que ce détecteur introduit un retard non négligeable sur la réception de l'écho (voir les illustrations dans la rubrique). Ce retard n'est malheureusement pas constant : la PLL a parfois un peu de mal à "s'accrocher".
  • Une solution plus simple pourrait consister à introduire un filtre passe bande centré sur 44KHz, à redresser sommairement le signal en sortie du redresseur et à l'appliquer à un comparateur. A essayer.

• 13/05/2011
  • J'ai terminé la partie "numérique" du générateur BF à base d'XR2206 : il est désormais capable d'afficher (une approximation de) la fréquence générée. En voici une photo :
    

    
  • J'ai du modifier légèrement la valeur des résistances utilisées pour le acquérir le signal d'indication de fréquence [+5v, -6.0v] produit par l'XR2206. J'explique en détail pourquoi dans la rubrique dédiée à ce générateur BF : en substance, il ne faut pas oublier qu'une diode est aussi une capacité...

• 8/05/2011
  • J'ai mis en oeuvre mon générateur BF à base d'XR2206 pour mesurer la valeur d'une inductance (ouawww! cf. cours de terminale...). Voir la section inductances où je narre cette bien belle histoire...
  • Au passage, j'ai trouvé un chip assez intéressant pour faire un lecteur MP3/Ogg Vorbis/etc. Il s'agit du VS1053b de VLSI Solution. Il prend un flux de données en entrées et s'occupe sagement du reste...

• 7/05/2011
  • Un site intéressant sur les mathématiques : metamath.

• 4/05/2011
  • Le générateur BF à base d'XR2206 est achevé du point de vue électronique : j'ai rajouté un PIC et un petit écran LCD pour afficher la fréquence générée. Il ne manque désormais qu'un petit bout de logiciel. La difficulté réside dans la largeur du spectre des fréquences à mesurer, qui court de 0 à 1MHz. Deux solutions :
    • Le signal rectangulaire de l'XR est utilisé pour déclencher / arrêter un timer. Cette solution est parfaite pour des fréquences pas trop élevées.
    • Le signal rectangulaire de l'XR est utilisé comme horloge d'un timer. Dans ce cas, la mesure de fréquence consiste à compter le nombre de "tics" entre deux instants (par exemple: 10ms). Cette solution est parfaite pour des fréquences élevées (car le compteur peut s'incrémenter un nombre significatif de fois entre les deux instants), mais est inefficace (imprécise) lorsque le signal varie très lentement car, la plupart du temps, le nombre d'impulsions entre les deux mesures va être égal à zéro.
  • Une solution intermédiaire consiste à utiliser deux compteurs Ccal et C : l'un dont la source est calibrée de fréquence FC, l'autre dont la source est le signal dont on cherche la fréquence F. A chaque instant, une approximation de F est F#FC*CCal/C. Si on ne cherche pas une précision trop grande (et à mesurer une fréquence trop élevée), on peut prendre FC correspondant à l'exécution de la boucle qui incrémente CCal. On peut alors facilement faire varier FCal pour s'ajuster à la gamme de fréquence de F.
  • J'ai commandé le petit composant (oscillateur) qui permettra de générer les 100MHz en entrée du DDS AD9850. J'ai rajouté un nouvelle rubrique sur ce Générateur de fréquence à base de DDS AD9850.

• 30/04/2011
  • Je viens de terminer le générateur BF à base d'XR2206. J'ai très bêtement suivi la note d'application d'Exar. Ca marche merveilleusement bien (après les habituels atermoiements liés aux soudures oubliées... fort heureusement le brave XR est robuste). J'ai rajouté un ampli-op de puissance (un L272, 0.7A) en sortie... sans trop de succès : le signal est assez bruité, malgré l'ajout d'une capacité de filtrage de 100nF en sortie et deux capacités de découplage sur les alimentations... Dans tous les cas, vu les performances de cet AOP (slew rate de 1V/us), la fréquence max. du GBF va être (très) réduite... Il faut utiliser un ampli-op rapide, tel l'AD818).
  • La prochaine étape va consister à afficher la fréquence sur un petit écran LCD. Ca ne devrait pas être trop difficile dans la mesure où l'Exar, dans sa grande bonté, pilote une sortie à collecteur ouvert avec un signal carré de fréquence égale à celle de sa sortie principale.
  • Au passage, j'ai rajouté une rubrique sur les inductances. Un composant un peu paradoxal car c'est probablement le seul que l'on puisse facilement réaliser, mais c'est aussi celui qu'on évite d'utiliser. On trouvera dans cette rubrique les différents codages utilisés sur les inductances, ainsi qu'un paragraphe sur la mesure d'une inductance avec les moyens du bord.
  • Je me suis mis à ocaml : un langage bien de chez nous qui est utilisé par nombre d'universitaires. On trouve de l'ocaml dans le générateur KCG d'Esterel, mais aussi dans le prouveur Coq, notamment. C'est un langage dans la lignée d'ML, comme son nom l'indique. Il comporte des traits des langages fonctionnels, procéduraux et objets. Un peu déroutant au début...

• 26/04/2011
  • La version de base --- et probablement la seule à tout jamais...--- de la carte réveil à base d'Atmega32 est achevée. Elle offre des fonctionnalités parfaitement extraordinaires telles diverses formes d'affichage de l'heure (hh:mm:ss et matrice de points), le réglage de l'heure et de la date et la consultation, activation, déactivation des alarmes. C'est merveilleux : tout un tas de fonctions que n'importe quel réveil à 5€ réalise fort bien et sans doute mieux. Mais je l'ai fait avec mes petits doigts et mon esprit gourds.
  • Les mélodies des alarmes sont générées à partir de fichiers MIDI dont j'extrais simplement les événements "NOTE ON" (avec un vilain bout de Java). Je ne me soucie pas plus que d'une guigne de la durée des événements (durée entre "NOTE ON" et "NOTE OFF"), ce qui rend les mélodies particulièrement désagréables ce qui est, somme toute une bonne propriété pour un réveil.
  • J'ai commencé à nettoyer un peu le code et à le commenter en utilisant doxygen (une forme de javadoc multi-langages).
  • A faire :
    • Actuellement, les alarmes sont configurées par une constante dans le code... C'est très pratique : tout changement ou ajout d'une alarme requiert la modification et la recompilation du code ainsi que son re-flashage via la sonde ATMEL. L'interface USB-Série est bien là mais je ne l'utilise pas encore.
    • Assurer la continuité de l'aliementation du PCF8553 : ajouter une alimentation par pile (deux petites diodes plus un support de pile)
  • Au passage, j'ai fait un tout petit petit petit montage assurant le déclenchement d'un ventilateur lorsque la température de consigne est dépassée : un ampli-op en comparateur, un transistor de commande du moteur, une diode et deux résistances. Si j'étais un peu plus compétent, je pense que j'aurais pu écraser la mouche sans ampli-op...
    

    
    

    
  • J'ai essayé de trouver une PLL en remplacement du 4046 de mon générateur-BF-qui-fonctionne-à-moitié. S'il fonctionne mal, c'est que je tente d'utiliser le VCO sur une largeur de 1MHz, ce que le pauvre animal ne sait pas faire. Bon, je n'ai rien trouvé pour l'instant, si ce n'est le synthétiseur AD9850 qui ferait exactement ce dont j'ai besoin si je le muni d'un diviseur (le bougre étant un peu rapide pour moi...).
  • Je n'ai toujours pas commencé le générateur à base de XR2206... mais environ 1 million de bricoleurs géniaux l'ont fait avant moi : il n'y a donc pas urgence pour l'humanité.
• 17/04/2011
  • La carte réveil à base d'Atmega32 est désormais capable d'afficher des messages sur la matrice de LEDs. Bon, ça c'est pas très difficile.
    

    
  • Pour l'instant, le logiciel comporte trois "tâches" :
    • une tâche de rafraîchissement de l'écran de période 1ms,
    • une tâche d'affichage des messages, environ 50 fois plus lente,
    • une tâche de gestion des mélodies.
  • Les tâches sont cadencées par une interruption timer (1ms). A chaque interruption, on parcourt une table contenant une liste de descripteurs (pointeur sur fonction, période, valeur du décompteur). Dès qu'un décompteur est nul, on appelle la fonction correspondante. En bref, c'est un ridicule ordonnanceur statique, bien pratique.
  • Pour ce qui est des mélodies, on utilise un autre timer, de façon à éviter de monopoliser le CPU pour générer une fréquence.
• 11/04/2011
  • La carte réveil à base d'Atmega32 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)