Partage
  • Partager sur Facebook
  • Partager sur Twitter

Retour d'experiences avec arduino en haute fréq

pour l'arduino :p

    18 août 2013 à 16:31:20

    Salut, je me présente, je suis un parisien de 18 ans venant de passer son bas STI2D SIN (= STI electronique) et j'ai beaucoup travaillé avec arduino, notamment pour mon projet de fin d'année. Mon équipe devait faire un véhicule commandé par un Smartphone android via liaison bluetooth. Je me suis occupé de la partie arduino (commande MLI via interface de puissance et bluetooth Shield). Cette partie à vite été terminé, ça à été super simple et le robot répondait bien au cahier des charges. Je me suis donc dis :"On va ajouter une caméra et transférer le flux du véhicule vers le smartphone !". Et là les problèmes on commencés. Vous pourrez avoir des info supplémentaires dans mon wordpress : http://nicolasfley.fast-page.org/?page_id=35... Ya de grosses lacunes d'informations mais j'avoue que j'ai vite eu la flemme de finioler :/ (au départ c'était que pour m'aider personnellement, une sorte de carnet de bord...

    Pour faire simple : j'utilise une caméra OV7670 24Mhz que je paramètre en QQCIF, la fréquence du data output descend à 1Mhz, théoriquement l'arduino UNO à 16Mhz peut lire...

    Toutes ces choses m'ont emmenés à travailler avec les registres de ports et à, au final, 16Mhz... J'ai vu quelques trucs bizarres, vous auriez des explication ? :)

    1) while(1){PORTB=255;PORTB=0;} donne un signal vraiment bizarre où le port est à l'état haut qu'un petit temps dans la période. bien sur c'est à cause de la boucle while qui prend tu temps à se faire... mais pourquoi tellement de temps ? environ 10 clocks je dirais.

    2) var = PINB; (var étant de type byte) est quelque fois hyper rapide, comme si l'instruction était sauté... et au final j'ai bien l'impression que cette instruction est sauté, je n'ai malheureusement aucun cas précis en tête :/

    3) à un moment j'ai du travailler avec un nombre supérieur à 255, au début j'ai choisi d'utiliser un short mais j'ai vu que c'était ultra long, au final l'utilisation de deux byte était plus efficace [while(byte1!=0x4A && byte2!=0x04) plus court que while(short1!=0x4A04)] ... ? WTF

    4) sortir d'une boucle prend forcément énormément de temps... ? J'avais essayé de faire un truc de ce genre :

    byte bool,incH,incL;
    while(bool)
    {
    if(incH==0x10&&incL==0x20)bool=1;
    }

    la même latence ce produit sur ce cas :

    byte incH,incL;
    while(incH==0x10&&incL==0x20)
    {
    }

     5) Des latences aléatoires apparaissent comme si l'arduino freezai de temps à autre (le temps de quelques tours clocks) c'est très génant lorsque l'on tente de récupérer un flux continu.

    Alors ? Quelques idées ? :)

    • Partager sur Facebook
    • Partager sur Twitter
      18 août 2013 à 22:17:39

      Ben c'est simple.

      Sur un uC tu as des interruptions. C'est bien pratique. Pour un circuit non débile, on utilise tout le temps des interruptions pour tout un tas de trucs. Donc, tout traitement en temps réel dur (genre génération de signaux, etc) réalisé par le CPU doit se faire avec interruptions désactivées, justement pour ne pas se faire interrompre, vu que c'est du temps réel.

      Dans ton cas, tu peux pas, puisque ton traitement prend une énorme portion du temps cpu disponible, si tu le fais avec les interruptions désactivées, t'auras plus d'interruptions du tout, donc ton uC sera lobotomisé.

      Si tu as ce genre de débit à traiter (de la vidéo même pourrie), de nos jours il faut même pas se poser la question, prends un uC 32 bits avec DMA, par exemple un ARM Cortex M3 ou M4, ou un PIC32, ou autre. Choisis-en un avec une unité DMA pas trop décérébrée. Donc, tu paramètres le DMA pour que, quand la pin reliée à l'horloge de la caméra reçoit son signal, il prend un octet sur le port machin, l'écrit en mémoire, et incrémente l'adresse. Après il recommence, et quand il en a écrit assez, il envoie une interruption au cpu qui récupère le paquet et paramètre une autre unité DMA pour l'envoyer sur le bluetooth. J'ai sur mon bureau depuis un moment un uC à 5$ qui a genre 16 canaux DMA et une bande passante mémoire de 3 gigaoctets/s, il n'y a pas de raison de se faire chier avec du soft.

      Sinon, en désespoir de cause, mets une FIFO hardware.

      • Partager sur Facebook
      • Partager sur Twitter
        19 août 2013 à 12:36:13

        Tu crois que les freeze c'est des interruptions ? comment on fait pour les désactiver sur l'arduino ? J'en ai déjà utilisé a vrai dire mais ça devait être activé quoi...

        J'avais une fifo avec la cam ^^' mais le circuit état vraiment bizarre donc j'ai pas réussi à faire marcher la fifo correctement (à priori faut lire dans la fifo à au moins 1Mhz...) ... tu trouve ou des uC de traitement video à 5$ ? :o

        Merci pour les infos en tout cas ^^' c impossible de trouver des infos comme ça sur e web (quand comme moi on sait pas chercher) et c'est pas les profs qui ont e donner ce genre d'infos... ils vont te laisser galérer avec ton arduino 16Mhz et ses intéruption à 1us ^^'

        • Partager sur Facebook
        • Partager sur Twitter
          19 août 2013 à 23:21:37

          Eh ben si tu as une FIFO, alors...

          http://www.rpg.fi/desaster/blog/2012/10/20/ov7670-fifo-msp430-launchpad/

          > tu trouve ou des uC de traitement video à 5$ 

          je parlais de uC généraliste mais un peu puissant, ceux-ci ne conviennent pas forcément à ton application, mais par exemple :

          http://www.digikey.com/product-detail/en/ATSAM3S1CA-AU/ATSAM3S1CA-AU-ND/2238256

          http://www.digikey.com/product-detail/en/EFM32TG108F32-QFN24/914-1032-1-ND/2776188

          et si c'est "5$ en quantité" au lieu de "à l'unité", alors...

          http://www.digikey.com/product-detail/en/LPC4330FBD144,551/568-9450-ND/2840463

          • Partager sur Facebook
          • Partager sur Twitter
            20 août 2013 à 18:14:01

            Ouai j'ai fait ça mais ça marchait à moitié je crois que les branchements de la FIFO étaient bizarre... ptet qu'un autre jours je m'y remmetrai :D

            Mais... c'est du CMOS non ? fin quand je dis CMOS ça veut dire que tu peux pas mettre ça sur une platine d'essai et qu'en plus il te faut faire de la soudure de précision pour les utiliser ? :o (et je suis très mauvais pour ça ^^' surtout avec mon fer à 10€ et mon étain à 50%) ^^'

            • Partager sur Facebook
            • Partager sur Twitter
              21 août 2013 à 8:03:29

              Tu confonds avec du CMS, mais oui ça ne va pas trop sur les platines d'essais !...

              Si tu veux une carte de dév avec programmateur pour un uC 32 bits, regarde là :

              http://www.embeddedartists.com/products/lpcxpresso

              Il y en a aussi des pas chères pour les STM32 (ARM aussi) et il me semble qu'il y a des arduino-compatibles à base de 32 bits.

              Pour garder l'arduino, le mieux est d'utiliser la fifo, il me semble que le 1er lien que j'ai mis a du code en exemple...

              • Partager sur Facebook
              • Partager sur Twitter
                21 août 2013 à 17:34:03

                Ouaip ^^ mais ma fifo marche pas très bien ^^' fin je retcheckerai quand je rentrerai avec le lien que tu m'as donnés mais si j'avais fait exactement ce qui était écris dedans et ça marchait pas...

                http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php !? 

                LPC1769 Cortex-M3 120 MHz 512 kB 64 kB PIO0_22 On-board Ethernet MAC, but requires an external Ethernet RJ45 connector

                pour 20€ ?! j'ai raté un truc où ??? ça se programme aussi facilement qu'un arduino ? (tu parles de programmateur) je suis vachement intéressé ^^' mais j'y connais rien... juste arduino et rpi :)

                c'est 100€ à priori un STM32 120Mhz ... :/

                ... 'arduino-compatibles' ? je crois que j'ai rien compris --"

                • Partager sur Facebook
                • Partager sur Twitter

                Retour d'experiences avec arduino en haute fréq

                × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                • Editeur
                • Markdown