Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1267 connectés 

 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  21  22  23  ..  263  264  265  266  267  268
Auteur Sujet :

[arduino] Topic Unique blabla @ Arduino

n°4034
ooterreuro​o
'You could drift this car while reading a book'
Posté le 17-04-2012 à 01:26:22  profilanswer
 

Reprise du message précédent :
C'est bien ce que je me disait :jap:
 
Aucun souçi avec le mos, tout fonctionne parfaitement, le bruit PWM à été viré grâce a l'ajout d'un condo de 100µF (mais je crois qu'on pouvait le virer en changeant la fréquence du pwm... ce que je ne sait pas faire :d)
 
Pour recentrer les choses, j'ai un BEP électronique, mais je n'ai pas pratiqué depuis bien 6 ans.
 
Entre temps j'ai passé d'autres diplômes dans l'info, j'ai des restes de connaissances sur les composants de base du genre résistances, diodes, condos (Rah, les mauvais souvenirs des TP de calcul de charge et décharge :/ ), transistors, amplificateurs linéaires & portes logiques, un tout petit peu de traitement de signal et c'est presque tout.
 
Donc du coup je peux poser des questions qui sont à la limite du ridicule pour une personne expérimentée, et faire des conneries, mais bon il faut bien (re)commencer quelque part :d


---------------
204 - No Content
mood
Publicité
Posté le 17-04-2012 à 01:26:22  profilanswer
 

n°4035
Turkleton
I don't quite understand you
Posté le 19-04-2012 à 13:01:52  profilanswer
 

Quelqu'un a déjà utilisé la bibliothèque "Timer1" ?
J'ai un petit souci avec (même si facilement contournable, mais pas proprement).
Cette bibliothèque permet, entre autres, de choisir la fréquence à laquelle on veut qu'elle "tique", et d'attacher une interruption sur chaque tic.
 
Dans le code suivant, j'initialise le timer pour tiquer toutes les secondes, et pour m'afficher "Nouvelle seconde" sur la sortie série à chaque nouveau tic.
 

Code :
  1. #include "TimerOne.h"
  2. boolean nv_sec = false;
  3. void setup() {
  4.   Serial.begin(9600);
  5.   Timer1.initialize(1000000);  // tique toutes les 1 seconde
  6.   Timer1.attachInterrupt(prochSec); // fonction à lancer à chaque "tic"
  7. }
  8. void loop() {
  9.   while (1) {
  10.     //delay(1);  
  11.     if (nv_sec) {
  12.       Serial.println("Nouvelle seconde" );
  13.       nv_sec=false;
  14.     } //if
  15.   } //while
  16. } //loop
  17. void prochSec(){
  18.   nv_sec = true;
  19. }


 
Le problème, c'est que ça ne fonctionne pas... sauf si je rajoute un delay (celui commenté en ligne 13) :pt1cable:  
Si je ne passe pas par ma boucle "while", ça fonctionne également, même sans le delay, ce qui semblerait indiquer que le problème vient de cette boucle. Mais j'en ai besoin et j'aimerais bien dans l'absolu ne pas "perdre" une milliseconde pour rien.
 
Quelqu'un comprend ce qui se passe ? La boucle while va-t-elle "trop vite" pour que l'interruption ait le temps de se lancer ? Je précise que je ne peux pas débugger en affichant la valeur d'une variable vu que le temps de traitement de cet affichage va avoir le même effet que le delay et va faire fonctionner le sketch (c'est d'ailleurs de cette manière que je me suis rendu compte de ce qui n'allait pas).


Message édité par Turkleton le 19-04-2012 à 13:05:25

---------------
If you think it could look good, then I guess it should
n°4036
Gruber Han​s
Posté le 20-04-2012 à 19:02:53  profilanswer
 

Bonjour
 
Depuis déjà un bon moment je voudrais mettre en œuvre un capteur CCD linéaire ; c'est d'ailleurs en partie pour cette raison que je me suis intéressé aux µC, seulement ça dépasse largement le cadre de mes compétences.
Voici un lien vers un capteur de ce type : http://www.datasheetcatalog.com/da [...] X511.shtml
Pensez vous qu'il serait possible d'exploiter les informations à l'aide d'un Arduino ? Je n'ai pas besoin d'une vitesse de lecture démentielle, il faudrait juste que je puisse lire le niveau de tous les pixels en quelques secondes.

n°4037
xdc360
Rond point expert...
Posté le 20-04-2012 à 23:51:37  profilanswer
 

je drap, j'ai une idée derrière la tête  
(une de plus :D)


---------------
Mon topic de vente | Mon feedback
n°4038
ooterreuro​o
'You could drift this car while reading a book'
Posté le 22-04-2012 à 13:24:25  profilanswer
 

Quelqu'un connait un site qui permet de réaliser ses PCB pas trop cher?
 
J'en ai trouvé quelques uns, mais les tarifs sont  [:canard rouge:4]


---------------
204 - No Content
n°4039
Natopsi
☄️Just end it already!☄️
Posté le 22-04-2012 à 18:59:46  profilanswer
 

Olimex
http://www.olimex.com/pcb/index.html


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4040
ooterreuro​o
'You could drift this car while reading a book'
Posté le 23-04-2012 à 00:57:30  profilanswer
 

Donc environ 35€/pcb si je ne me trompe pas, ça reste vachement cher je pense que je vais m'acheter du pcb de prototypage pour les trucs de base :/
 
A la limite pour la production d'un "produit finit" pourquoi pas :o


---------------
204 - No Content
n°4041
sorg
trop sur HFR depuis 2001
Posté le 23-04-2012 à 07:23:21  profilanswer
 

ooterreuroo a écrit :

Quelqu'un connait un site qui permet de réaliser ses PCB pas trop cher?

 

J'en ai trouvé quelques uns, mais les tarifs sont  [:canard rouge:4]


fait une recherche, j avais fait un catch de 10 Pcb pour une trentaine d euros... Bon par contre j ai plus le nom du site en tête.

n°4042
ooterreuro​o
'You could drift this car while reading a book'
Posté le 23-04-2012 à 11:45:26  profilanswer
 

trouvé: http://www.seeedstudio.com/depot/f [...] ?cPath=185
 
15$ pour 10 PCB 5*5 de base avec les FDP, c'est bien plus intéressant je trouve :d
 
Bon sinon je viens de retrouver un petit moniteur 7" je vais voir ce que je peux faire avec :d


---------------
204 - No Content
n°4043
Natopsi
☄️Just end it already!☄️
Posté le 23-04-2012 à 13:33:46  profilanswer
 

Seeedstudio ils sont au même prix qu'olimex pour le format europe du coup  [:zytradance]


Message édité par Natopsi le 23-04-2012 à 13:33:55

---------------
ACH/VDSHFRCoin◈1435mm⚡
mood
Publicité
Posté le 23-04-2012 à 13:33:46  profilanswer
 

n°4044
ooterreuro​o
'You could drift this car while reading a book'
Posté le 23-04-2012 à 21:05:00  profilanswer
 

Bon, je me suis un peu amusé avec le moniteur 7" (un peu pété) que j'ai retrouvé, je ne savais même pas qu'on pouvais sortir un signal composite de l'arduino :d
 
Du coup j'en ai profité pour tenter une représentation graphique de la lecture d'un HC-SR04 :  
 
http://www.exen.fr/images/temp/index.html
 
Bon il y a encore des améliorations à faire (il faudrait faire une moyenne de deux mesures pour avoir un truc plus stable je pense).
 
Par contre pour une raison que j'ignore, c'est précis jusqu'a environ 30cm, puis après c'est n'imp, genre a 50cm réels il m'indique 37cm, et il a du mal a faire sa mesure.
 
Si je vire le signal composite, j'arrive à nouveau a mesurer tranquile jusqu'a quasi 2M :??:


---------------
204 - No Content
n°4045
Guill_P
Posté le 23-04-2012 à 21:29:00  profilanswer
 

Turkleton a écrit :

Quelqu'un a déjà utilisé la bibliothèque "Timer1" ?
J'ai un petit souci avec (même si facilement contournable, mais pas proprement).
Cette bibliothèque permet, entre autres, de choisir la fréquence à laquelle on veut qu'elle "tique", et d'attacher une interruption sur chaque tic.
 
Dans le code suivant, j'initialise le timer pour tiquer toutes les secondes, et pour m'afficher "Nouvelle seconde" sur la sortie série à chaque nouveau tic.
 

Code :
  1. #include "TimerOne.h"
  2. boolean nv_sec = false;
  3. void setup() {
  4.   Serial.begin(9600);
  5.   Timer1.initialize(1000000);  // tique toutes les 1 seconde
  6.   Timer1.attachInterrupt(prochSec); // fonction à lancer à chaque "tic"
  7. }
  8. void loop() {
  9.   while (1) {
  10.     //delay(1);  
  11.     if (nv_sec) {
  12.       Serial.println("Nouvelle seconde" );
  13.       nv_sec=false;
  14.     } //if
  15.   } //while
  16. } //loop
  17. void prochSec(){
  18.   nv_sec = true;
  19. }


 
Le problème, c'est que ça ne fonctionne pas... sauf si je rajoute un delay (celui commenté en ligne 13) :pt1cable:  
Si je ne passe pas par ma boucle "while", ça fonctionne également, même sans le delay, ce qui semblerait indiquer que le problème vient de cette boucle. Mais j'en ai besoin et j'aimerais bien dans l'absolu ne pas "perdre" une milliseconde pour rien.
 
Quelqu'un comprend ce qui se passe ? La boucle while va-t-elle "trop vite" pour que l'interruption ait le temps de se lancer ? Je précise que je ne peux pas débugger en affichant la valeur d'une variable vu que le temps de traitement de cet affichage va avoir le même effet que le delay et va faire fonctionner le sketch (c'est d'ailleurs de cette manière que je me suis rendu compte de ce qui n'allait pas).


 
Le problème est sur la variable nv_sec, qui est partagée entre le thread principal ( fonction loop() ), et le thread de l'interruption ( fonction prochSec() ): il faut déclarer la variable partagée en volatile:
 

Code :
  1. volatile boolean nv_sec = false;


 
Cela fait que le thread principal va lire la valeur directement dans la mémoire, et ne garde pas de "cache" (en tout cas, c'est comme cela que fonctionne les threads en c++ sous windows, je m'y connais moins en arduino).
 
Ref: http://arduino.cc/en/Reference/Volatile
 
 

n°4046
SquiZZ
Posté le 23-04-2012 à 21:42:41  profilanswer
 

Guill_P a écrit :


en tout cas, c'est comme cela que fonctionne les threads en c++ sous windows, je m'y connais moins en arduino).


Voir http://en.wikipedia.org/wiki/Volatile_variable

Citation :

The volatile keyword is basically worthless as a portable threading construct.


Bon c'est du wikipedia, mais y a quelques références et une simple recherche sur "volatile thread" dans google retourne plein de résultats.


Message édité par SquiZZ le 23-04-2012 à 21:42:53
n°4047
Guill_P
Posté le 23-04-2012 à 22:14:35  profilanswer
 

Effectivement, en c++, ça fait un bail qu'on n'utilise plus le mot clef volatile pour la synchronisation entre threads, vu qu'il y a les MemoryBarrier, les CriticalSections, les opérations atomiques et tout et tout. Mais volatile existe toujours, et son but est d'éviter de se retrouver avec une variable qu'on lit dans le cache du processeur, alors qu'elle est modifiée par un autre thread, ou autre.
 
Et sur arduino, je ne crois pas avoir vu grand chose coté multithreading, à part les interruptions et le mot clef volatile. Je ne sais d'ailleurs pas ce qu'on a le droit de faire sur la callback d'interruption: peut-on appeler directement la méthode Serial.println("Nouvelle seconde" ), ou elle risque de rentrer en conflit avec un autre appel a une des méthode de Serial dans la boucle principale ?

n°4048
Gruber Han​s
Posté le 23-04-2012 à 22:38:13  profilanswer
 

C'est bien beau tout ça, mais pour ma barrette CCD vous avez des infos ? vous avez déjà utilisé quelque chose de similaire ?

n°4049
SquiZZ
Posté le 23-04-2012 à 23:27:55  profilanswer
 

Gruber Hans a écrit :

C'est bien beau tout ça, mais pour ma barrette CCD vous avez des infos ? vous avez déjà utilisé quelque chose de similaire ?


Bon ça a pas l'air sorcier comme ça. J'ai jamais touché d'arduino mais je me jette à l'eau.
Je n'ai pas vu de durée max pour les durées d'impulsions, on peut tenter à la barbare et générer CLK avec une tempo assez élevée pour pouvoir négliger la durée de sampling de l'ADC.
un digital out pour ROG et CLK, un analog in pour VOUT (attention il faut que ton arduino soit en 5V)
Comme on a 2086 valeurs à lire ca va pas tenir en ram, en première approche on peut sampler une valeur sur 10 par exemple -> déclarer un tableau int val[201]
 
initialiser les sorties à l'état haut  

Code :
  1. DigitalWrite(ROG, HIGH);
  2. DigitalWrite(CLK, HIGH)
  3. delay(5); // attendre un peu


 
Lancer l'acqisition :

Code :
  1. DigitalWrite(ROG, LOW)
  2. delay(1);
  3. DigitalWrite(ROG, HIGH)
  4. delay(1);


 
Lire une valeur tous les 10 :

Code :
  1. for(int i=0; i<201; i++)
  2. {
  3.   // 9 clocks pour rire
  4.   for(int j=0; j<9; ++j)
  5.   {
  6.      DigitalWrite(CLK, LOW);
  7.      Delay(2);
  8.      DigitalWrite(CLK, HIGH);
  9.      Delay(2);
  10.   }
  11.   // acquisition
  12.   DigitalWrite(CLK, LOW);
  13.   Delay(1); // laisser le temps au capteur de réagir (voir schéma en bas de la page 3 du datasheet)
  14.   val[i] = AnalogRead(VOUT); // temps d'acquisition 100 microsecondes négligeable
  15.   Delay(1); // finir le créneau bas de l'horloge
  16.   DigitalWrite(CLK, HIGH);
  17.   Delay(2);
  18. }


 
Voila, codé à la barbare sur un coin de nappe, pas testé, vendu sans garantie ;)
 
[edit] bon je viens de voir en première page de la datasheet ( :sarcastic: ) que la fréquence max est de 2MHz, on peut utiliser des tempos beaucoup plus petites.


Message édité par SquiZZ le 23-04-2012 à 23:34:53
n°4050
Gruber Han​s
Posté le 23-04-2012 à 23:51:16  profilanswer
 

Merci, ça me donne déjà une base sur laquelle travailler. Je reçois ma barrette CCD dans quelques jours, je vais pouvoir essayer ton code.

n°4051
Natopsi
☄️Just end it already!☄️
Posté le 24-04-2012 à 00:02:20  profilanswer
 

ooterreuroo a écrit :

Bon, je me suis un peu amusé avec le moniteur 7" (un peu pété) que j'ai retrouvé, je ne savais même pas qu'on pouvais sortir un signal composite de l'arduino :d
 
Du coup j'en ai profité pour tenter une représentation graphique de la lecture d'un HC-SR04 :  
 
http://www.exen.fr/images/temp/index.html
 
Bon il y a encore des améliorations à faire (il faudrait faire une moyenne de deux mesures pour avoir un truc plus stable je pense).
 
Par contre pour une raison que j'ignore, c'est précis jusqu'a environ 30cm, puis après c'est n'imp, genre a 50cm réels il m'indique 37cm, et il a du mal a faire sa mesure.
 
Si je vire le signal composite, j'arrive à nouveau a mesurer tranquile jusqu'a quasi 2M :??:


Le composite ça doit te bouffer pas mal de temps processeur, du coup niveau traitement derrière tu doit en baver.
 
Prend un RPI pour interfacer l'écran :o


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4052
ooterreuro​o
'You could drift this car while reading a book'
Posté le 24-04-2012 à 00:11:31  profilanswer
 

un RPI?
 
Sinon j'y ai pensé, mais ça m'étonne un peu car j'ai pas mal optimisé le truc et c'est relativement fluide, mais dès que j'arrive vers 30CM réels, il commence a y avoir ce foutu décalage et les mesures sont très erratiques voir impossible a 1M :d
 
Si le truc avait pas assez de patate pour traiter l'info, ça foirerais même entre 5 et 30 cms non :??:


---------------
204 - No Content
n°4053
SquiZZ
Posté le 24-04-2012 à 00:42:39  profilanswer
 

T'a codé comment la mesure de distance ?

n°4054
ooterreuro​o
'You could drift this car while reading a book'
Posté le 24-04-2012 à 01:56:57  profilanswer
 

salut :)
 
Voici le code source du programme, c'est moche car j'ai fait ça en 20 minutes rapidement.
 
Je maitrise malheureusement pas bien l'électronique et l'arduino, dont j'ignore encore bien des trucs (les interrupts et quelques pins).
 
code:  (le processing de la mesure de distance est tout en bas)

Code :
  1. #include <stdio.h>
  2. #include <TVout.h>
  3. #include <fontALL.h>
  4. #include "Ultrasonic.h"
  5. #define US_TRIG_PIN 13
  6. #define US_ECHO_PIN 4
  7. Ultrasonic ultrasonic( US_TRIG_PIN,US_ECHO_PIN );
  8. TVout TV;
  9. long last_distance_sensor_ts = 0;
  10. int distance_sensor_delay = 150;
  11. boolean is_oor = false; //out of range flag
  12. boolean draw_ui_flag = true;
  13. int pos = 10; //Position de la progressbar par défaut
  14. void setup() {
  15.   delay(5000);
  16.   TV.begin(PAL,128,96);
  17.   TV.select_font(font6x8);
  18.   TV.println("INIT..." );
  19.   TV.delay(2500); 
  20.   TV.clear_screen();
  21. }
  22. void loop() {
  23.   TV.select_font(font6x8);
  24.   //Labels
  25.   TV.println(0,0,"Capteur de distance" );
  26.   TV.print(2,20,"MIN" );
  27.   TV.print(108,20,"MAX" );
  28.   //Indicateurs
  29.   //Min
  30.   TV.draw_column(10,28,36,1);
  31.   //Max
  32.   TV.draw_column(116,28,36,1);
  33.   //Conteneur
  34.    TV.draw_rect(10,38,106,10,WHITE);
  35.    //Distance processing
  36.    if(millis() > last_distance_sensor_ts+distance_sensor_delay){
  37.        double ds_cms = process_distance();
  38.        if(ds_cms < 5){
  39.          if(!is_oor){
  40.            TV.draw_rect(10,38,106,10,1,0);//masque noir progressbar
  41.            TV.draw_rect(26,18,75,10,1,0); //masque noir (clear)
  42.            TV.println(27,20,"Out of range!" ); //Texte
  43.            TV.draw_rect(26,18,75,10,1,2); //Masque inversé
  44.            is_oor = true;
  45.          }
  46.        }
  47.        else{
  48.         is_oor = false;
  49.         TV.draw_rect(26,18,75,10,0,0);//masque noir display mesure
  50.         TV.print(40,20,ds_cms); //Display mesure
  51.         TV.print(75,20,"CMS" ); //Display unité
  52.         //Remplissage barre
  53.         //Calcul du remplissage
  54.         int fill_value = (ds_cms*115)/50;
  55.         if(pos<fill_value){ //évite la création d'un gap après passage par out of range (moche a revoir)
  56.           pos=10;
  57.         }
  58.         if(fill_value>105){
  59.           fill_value = 105;
  60.         }
  61.         while (pos!=fill_value){   
  62.           if(pos<fill_value){
  63.             TV.draw_column(pos,39,47,1);
  64.             pos++;
  65.           }
  66.           else if(pos>fill_value){
  67.             TV.delay_frame(1);
  68.             TV.draw_column(pos,39,47,0);
  69.             pos--;
  70.           }
  71.         }
  72.       }
  73.    }
  74.    //TV.delay_frame(1);
  75. }
  76. double process_distance(){
  77.   double cmMsec;
  78.   long microsec = ultrasonic.timing();
  79.   cmMsec = ultrasonic.convert(microsec, Ultrasonic::CM);
  80.   last_distance_sensor_ts = millis();
  81.   return cmMsec;
  82. }


 
Il n'y a rien d'important la dedans, je voulais juste voir si j'étais capable de faire un truc sympa avec le moniteur que j'ai retrouvé, et puis je suis tombé sur cet os, c'est pas trop grave si je trouve pas la solution du problème, mais ça me travaille quand même car au final j'aurais voulu comprendre pourquoi.
 
D'ailleurs, si vous avez des "best practices" à me donner quand on utilise des capteurs et qu'on fait des traitements, n'hésitez pas :)


---------------
204 - No Content
n°4055
Turkleton
I don't quite understand you
Posté le 24-04-2012 à 15:35:19  profilanswer
 

Guill_P a écrit :


 
Le problème est sur la variable nv_sec, qui est partagée entre le thread principal ( fonction loop() ), et le thread de l'interruption ( fonction prochSec() ): il faut déclarer la variable partagée en volatile:
 

Code :
  1. volatile boolean nv_sec = false;


 
Cela fait que le thread principal va lire la valeur directement dans la mémoire, et ne garde pas de "cache" (en tout cas, c'est comme cela que fonctionne les threads en c++ sous windows, je m'y connais moins en arduino).
 
Ref: http://arduino.cc/en/Reference/Volatile
 
 

Bien vu, j'ai testé et ça fonctionne :)  
 
Je me suis demandé à un moment s'il perdait pas la valeur de nv_sec quand il passait dans l'interruption et qu'il revenait à la fonction principale, mais comme elle est déclarée en globale, je me suis dit que ça devait être bon.
Je connaissais pas ce mot-clef "volatile", j'essaierai de m'en souvenir.
 
Merci pour ton aide :jap:  


---------------
If you think it could look good, then I guess it should
n°4056
SquiZZ
Posté le 24-04-2012 à 20:25:15  profilanswer
 

ooterreuroo a écrit :


D'ailleurs, si vous avez des "best practices" à me donner quand on utilise des capteurs et qu'on fait des traitements, n'hésitez pas :)


C'est difficile de poser des grandes règles quand on fait de la programmation micro-controleur, du fait des ressources limitées.
Il faut identifier :
- les contraintes externes, par exemple dans ton cas les docs de ton capteur indiquent que le temps mini conseillé entre deux acquisitions est de 60 ms
- les contraintes internes, genre si ta lib TVout utilise des timers ou des interruptions (de ce que j'ai compris elle utilise un timer seulement)
- ce que t'apporte tes libs (par exemple le frame_delay de la lib TVout)
 
En posant que l'on a une interruption externe dispo, je l'utiliserais pour faire l'acquisition, ce qui donne :
 
des variables

Code :
  1. unsigned long acqStart;
  2. volatile unsigned long pulseTime;
  3. unsigned long lastAcq;
  4. float distance;


 
une fonction pour lancer l'acquisition

Code :
  1. StartAcquisition()
  2. {
  3.   DigitalWrite(TRIG, HIGH);
  4.   delaymicroseconds(10);
  5.   DigitalWrite(TRIG, LOW);
  6. }


 
une interruption sur changement d'état  

Code :
  1. AcquisitionInterrupt()
  2. {
  3. if(DigitalRead(ECHO) == HIGH)
  4.   {
  5.     // acq start
  6.     acqStart = micros();
  7.   }
  8.   else
  9.   {
  10.     // acq end
  11.     pulseTime = micros() - acqStart;
  12.   }
  13. }


 
une fonction de calcul de la distance  

Code :
  1. float CalculDistance()
  2. {
  3.   float res;
  4.  
  5.   NoInterrupts(); // désactiver les interruption pendant le calcul, voir si c'est nécessaire
  6.   if(pulseTime == 0 || pulseTime > 40000)
  7.     res = 0; // première acquistion ou out of range
  8.   res = pulseTime  * CONSTANTE; // voir doc du capteur pour la constante
  9.  
  10.   Interrupts(); // réactiver les interruptions, voir commentaire sur le NoInterrupts ci-dessus
  11.  
  12.   return res;
  13. }


 
après en pseudo code :

Code :
  1. void setup()
  2. {
  3.   // faire toutes les inits comme dans ton code, puis
  4.   lastAcq = millis();
  5.   acqStart = 0;
  6.   pulseTime = 0;
  7.   distance = 0;
  8. }
  9. void loop()
  10. {
  11.   // calculer la distance
  12.   distance = CalculDistance();
  13.  
  14.   // faire tout l'affichage (utiliser frame_delay(1) de TVOut à la fin de l'affichage pour synchroniser l'affichage)
  15.   Affichage();
  16.  
  17.   // tester si la dernière acquisition date de plus de 60 ms
  18.   if(millis() - lastAcq > 60)
  19.   {
  20.     lastAcq = millis();
  21.     StartAcquisition();
  22.   }
  23. }


 
Voila, pas compilé, pas testé (j'ai toujours pas d'arduino ;) )
[edit] mise à jour du code éclair et il manque l'init des pins et de l'interruption.


Message édité par SquiZZ le 24-04-2012 à 20:41:53
n°4057
ooterreuro​o
'You could drift this car while reading a book'
Posté le 24-04-2012 à 21:03:58  profilanswer
 

Ok je vois que tu veux te passer de la lib et faire le processing toi-même si je me trompe pas, bon j'ai déplacé tout ce qui affiche l'interface hors du loop pour faire un peu de ménage dans ce dernier, ça fait plusieurs fois que je vois le mot "volatile" apparaitre sur cette page :d , et pour les interruptions je suis en train de lire la page sur arduino.cc afin de comprendre de quoi il en retourne :)
 
Bon en tout cas ça me change du php... c'est fou ce que j'arrive a me faire jeter par le compilateur, sans compter les trucs qui passent mais qui ne marchent pas :whistle:
 
edit: tu n'a pas, ou plus d'arduino?
 
Pour ma part j'en ai commandé un autre, pour les trucs client/serveur/sans fils ça sera pas un luxe :o


Message édité par ooterreuroo le 24-04-2012 à 21:04:40

---------------
204 - No Content
n°4058
SquiZZ
Posté le 24-04-2012 à 21:26:47  profilanswer
 

ooterreuroo a écrit :

Ok je vois que tu veux te passer de la lib et faire le processing toi-même si je me trompe pas


la lib fait pas grand chose non plus, elle appelle un pulseIn pour mesurer la durée à l'état haut et fait la division pour calculer la distance ;)
 

ooterreuroo a écrit :


, bon j'ai déplacé tout ce qui affiche l'interface hors du loop pour faire un peu de ménage dans ce dernier,


C'est toujours bien de structurer ton programme : dans ton code initial le truc qui me génait par exemple c'est que tu mettais à jour last_distance_sensor_ts dans ta fonction de calcul alors que c'est pas vraiment lié au calcul de la distance, ca complique la lecture du programme.
 
 

ooterreuroo a écrit :


Bon en tout cas ça me change du php... c'est fou ce que j'arrive a me faire jeter par le compilateur, sans compter les trucs qui passent mais qui ne marchent pas :whistle:


faut perseverer, c'est fun  [:lyloo]  
 

ooterreuroo a écrit :


edit: tu n'a pas, ou plus d'arduino?


j'ai jamais eu d'arduino, j'ai un peu d'expérience professionnelle sur les micro-controleurs et je préfère coder en C pour avoir directement accès à tous les périphériques (timers, interruptions, i2c, usb, port séries). Alors je raconte peut-être n'importe quoi quand je parle d'arduino ;)


Message édité par SquiZZ le 24-04-2012 à 21:28:57
n°4059
ooterreuro​o
'You could drift this car while reading a book'
Posté le 24-04-2012 à 21:35:25  profilanswer
 

Et comment que c'est fun :love:
 
Bon de mon coté l'arduino c'est parce que je suis autant une quiche en électronique qu'en C, C#, C++ et tout langage a fort typage :/  
 
(et mouarf mouarf pour les µC pour lesquelles je n'ai aucune base :d )
 
Je compte me fabriquer un petit robot a partir d'une voiture rc, d'abord piloté a la mano, puis compliquer le truc pour le faire devenir plus ou moins autonome, donc je me fait un peu la main sur les capteurs/actionneurs et le language arduino avant de commencer un truc sérieux :)


---------------
204 - No Content
n°4060
ooterreuro​o
'You could drift this car while reading a book'
Posté le 25-04-2012 à 20:32:29  profilanswer
 

Bon, je viens de recevoir ma voiture rc made in china (ils ont fait vite amazon  :ouch: ), pour mon projet de robot autonome.
 
Grosse déception la commande n'est pas proportionnelle, c'est du ultra basique ultra chinois quoi :/
 
J'ai démonté le truc et pas de surprises au niveau du circuit, comme le reste c'est très... cheap, un pauvre RX-2, un h-bridge moisi :(
 
Bref je comptais au début foutre l'arduino sur le pin 2 et simuler un signal, mais je crois plutôt que je vais dessouder le RX-2 et connecter l'arduino sur les pinouts qui m'intéressent (avancer/reculer droite/gauche).
 
Par contre la ou je coince, c'est que je sait pas si le montage va apprécier si j'y envoie du pwm pour tenter de contrôler la vitesse du truc :??:
 
J'aimerais conserver le circuit actuel car j'ai pas les composants pour faire un h-bridge maison (sinon ça aurait certainement été plus simple... enfin je pense :d )
 
Voici la tronche du circuit :
 http://www.gopix.fr/thumb-8857_4F984110.jpg
 
Si vous avez des conseils je vous écoute, c'est mon premier essai en la matière sur des consommateurs, j'aimerais pas cramer un truc ou mon arduino :o


---------------
204 - No Content
n°4061
Gruber Han​s
Posté le 25-04-2012 à 20:56:24  profilanswer
 

Bonjour
 
Pourquoi conserver le circuit si tu ne veux plus la télécommander ? Le plus simple est de couper tout ce fatras et de commander directement les moteurs (avec du PWM éventuellement) par l’intermédiaire de nmos.

n°4062
ooterreuro​o
'You could drift this car while reading a book'
Posté le 25-04-2012 à 21:26:43  profilanswer
 

Disons que je suis très limité niveau composants, j'ai un optocoupleur, un irf540n, un uln2803, quelques petits transistors et des condos/résistances en plus grand nombre :d


---------------
204 - No Content
n°4063
Natopsi
☄️Just end it already!☄️
Posté le 25-04-2012 à 21:33:53  profilanswer
 

Il existe des modules pont en H (regarde sur ebay). Sinon bah essaie de tirer un schéma de tout ça, tu te retrouvera avec 2 à 4 fils pour la commande du pont en H.


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4064
ooterreuro​o
'You could drift this car while reading a book'
Posté le 25-04-2012 à 21:50:02  profilanswer
 

vu le peu de composants, une fois la partie réception retirée ça doit pas être sorcier, j'ai du 3V en sortie des pins du RX-2, donc je vire le RX-2, 4 fils pour avancer/reculer gauche/droite et c'est réglé, du moins c'est mon idée de base pour utiliser le matos existant :o
 
Ce que tu parle c'est ceci: http://www.ebay.com/itm/L298N-Dual [...] 2a1c6682d0 ?
 
Pas trop mal effectivement, mais bon ce serait du gâchis vu la daube que c'est cette voiture rc :d (par contre si j'arrive a un truc bien j'en achèterais une bien mieux et je ferais un truc plus propre).
 
edit: bon en envoyant du 3v sur les bons pins ça réagit :o


Message édité par ooterreuroo le 25-04-2012 à 21:57:21

---------------
204 - No Content
n°4065
330tdx2
Deal with it mofo
Posté le 26-04-2012 à 22:30:27  profilanswer
 

Ça y est j'ai commandé mon arduino [:jar jar]  
 
Je vais commencer par des trucs basiques à bases de LEDs puis ensuite je voudrais piloter un LCD type HD44780, bon par contre mes notions de programmation remonte au lycée... on verra par la suite :)

n°4066
ooterreuro​o
'You could drift this car while reading a book'
Posté le 30-04-2012 à 20:57:36  profilanswer
 

Bon, j'ai reçu mon second arduino, l'occasion de faire des tests avec virtualwire, je suis arrivé à contrôler la voiture RC que j'ai moddée avec une manette d'xbox 360 et un set 433Mhz, ça marche vraiment bien... tellement bien d'ailleurs que j'ai sans le vouloir brouillé mes prises télécommandées, l'ouverture centralisée de ma bagnole et du garage, et même l'ouverture du portail du voisin ( [:ooterreuroo] )
 
Du coup, je comprends que le set en 433Mhz est réservé pour une utilisation non continue, vu que tout le monde doit se partager le gâteau, mais donc pour la partie commande a distance je me demande par quoi je peux le remplacer :/
 
Les shields wifi sont vraiment trop chers, il existe des dérivés des modules 433mhz en 315Mhz je crois mais j'ai peur que ça n'affecte d'autres équipements, il existe d'autres alternatives pas trop chères?
 
Idem pour de la vidéo, une caméra ip wifi par ex c'est bien mais la portée c'est vraiment pas le top, j'aurais aimé avoir au moins 300 a 400M de portée en champ libre et 200M en intérieur :/


---------------
204 - No Content
n°4067
Natopsi
☄️Just end it already!☄️
Posté le 30-04-2012 à 21:16:39  profilanswer
 

Pour le brouillage, communique par paquets genre toutes les secondes pour laisser un intervalle libre pour les autres systèmes ;)


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4068
ooterreuro​o
'You could drift this car while reading a book'
Posté le 30-04-2012 à 21:23:10  profilanswer
 

Oui mais pour contrôler une voiture RC, c'est pas le top d'avoir des datas toutes les secondes :d


---------------
204 - No Content
n°4069
dafunky
Posté le 02-05-2012 à 00:05:41  profilanswer
 

ooterreuroo a écrit :

Les shields wifi sont vraiment trop chers, il existe des dérivés des modules 433mhz en 315Mhz je crois mais j'ai peur que ça n'affecte d'autres équipements, il existe d'autres alternatives pas trop chères?


 
Ceci colle bien à ton besoin :  
 

dafunky a écrit :

J'ai acheté un kit RF 2.4Ghz pour faire communiquer deux arduinos, c'est une puce très optimisée qui a du potentiel, cependant je n'ai pas encore pris le temps de la tester. Elle gère la répétition des paquets perdus, les connexions point à point entre arduinos. C'est le chip NRF24L01


 


---------------
xPLduino, la domotique DIY deluxe - - - - Sigma 85mm F1.4
n°4070
ooterreuro​o
'You could drift this car while reading a book'
Posté le 02-05-2012 à 01:50:36  profilanswer
 

Mais ça a l'air super ce truc, la portée semble pas mal, jusqu'a 2mb/s, faible conso :love:


---------------
204 - No Content
n°4071
Natopsi
☄️Just end it already!☄️
Posté le 02-05-2012 à 08:34:27  profilanswer
 

J'en ai en stock je n'ai toujours pas pris le temps de les exploiter. Sache que tu n'aura pas tout en même temps, si tu veut une portée pas mauvaise il faudra passer avec des débits relativement faibles.
 
Tiens faudra que j'en flanque un sur le raspberry pi et un autre sur arduino  [:maxvirtuel]


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4072
ooterreuro​o
'You could drift this car while reading a book'
Posté le 02-05-2012 à 12:05:59  profilanswer
 

je peux espérer environ 1mb/s sur 500M avec un nRF24L01p+ PA+ LNA? ( http://www.elecfreaks.com/store/nr [...] p-142.html )
 
Je vais d'abord m'acheter la version low cost a deux balles pour mes tests pour commencer mais ça me semble assez intéressant coté portée.


---------------
204 - No Content
n°4073
Natopsi
☄️Just end it already!☄️
Posté le 02-05-2012 à 12:57:00  profilanswer
 

Dans ces modules il y a un ampli pour passer la puissance d'émission à 100mw, et un amplificateur de gain 10 (si j'interprète bien), multipliant par 10 (puissance reçue en 1/(r^3) en supposant l'antenne isotrope) la portée par rapport à un module de base.


---------------
ACH/VDSHFRCoin◈1435mm⚡
n°4074
mimix
cool member
Posté le 06-05-2012 à 21:58:13  profilanswer
 

bonjour tout le monde !
je suis en train de finaliser un projet de controlleur rgb pour escalier, et j'ai un soucis avec le led strip de test...
 
quand le microcontrolleur (un teensy usb 2.0++) boot, il me met d'office la sortie marchetest à l'état haut... donc allumé !
et impossible de l'éteindre ! alors que ma syntaxe me parrait bonne  :pt1cable:  
 

Code :
  1. //declaration des pins
  2.   int redPin =  24; //sortie analogique rouge
  3.   int greenPin =  26; //sortie analogique verte
  4.   int bluePin =  25; //sortie analogique bleue
  5.   int modedepan = 17; //bouton pour activer/desactiver le led strip de test sans changer de couleur
  6.   int Cmoinspin = 18; //changement de couleur decroissant
  7.   int Cpluspin = 19; //changement de couleur croissant
  8.   int Bpluspin = 2; //changement de luminosite decroissant
  9.   int Bmoinspin = 3; //changement de luminosite croissant
  10.   int activity = 6; //led interne permettant de verifier l'activitee du teensy 2.0 ++
  11.   int marche[] = {
  12.   4, 5, 29, 7, 8, 9, 10, 11, 12, 13, 28, 23, 22, 21}; //sorties ou sont reliees les marches, en partant de bas en haut
  13.   int marchetest = 20; //led strip de test
  14.   int capteurbas = 0; //capteur de presence en bas de l'escalier
  15.   int capteurhaut = 1; //capteur de presence en haut de l'escalier
  16. //initialisation du mode de connection des pins
  17.   // initialisation des variables
  18.   unsigned int ColorR = 255; //unsigned int permet de garder un codage positif et donc d'exploiter toutes les possibilites des 16bits  
  19.   unsigned int ColorG = 255;   //avec des valeurs pouvant aller jusqu'a 65536, utile dans notre cas avec la bidouille lors de l'integration de la gestion de luminosite
  20.   unsigned int ColorB = 255;
  21.   unsigned int Bright = 50;
  22.   unsigned int CodeR = 0;
  23.   unsigned int CodeG = 0;
  24.   unsigned int CodeB = 0;
  25.   int Veille = 0;
  26.   int Verrou = 0;
  27.   int activitycount = 0;
  28.   //paramètres pour le cadencement
  29.   int nbrmarche = 14; //nombre de marches
  30.  
  31.   //temps d'allumage des leds
  32.   int tpsattente = 25000; //temps d'allumage une fois tout éclaire
  33.   int tpsallum= 98; //temps de cadencement d'une marche
  34.   int marcheN;
  35. void setup() 
  36. {
  37.   Serial.begin(9600); //utile au debug
  38.   pinMode(redPin, OUTPUT); // configuration en mode sortie pour l'entree/sortie nommee
  39.   pinMode(greenPin, OUTPUT);
  40.   pinMode(bluePin, OUTPUT);
  41.   pinMode(activity, OUTPUT);
  42.  
  43.   pinMode(marchetest, OUTPUT); //led strip a l'interieur de la boite pour configuration de couleur meme si l'escalier n'est pas visible de la boite
  44.   pinMode(Cmoinspin, INPUT_PULLUP);
  45.   pinMode(Cpluspin, INPUT_PULLUP);
  46.   pinMode(Bmoinspin, INPUT_PULLUP);
  47.   pinMode(Bpluspin, INPUT_PULLUP);
  48.   pinMode(capteurbas, INPUT_PULLUP);
  49.   pinMode(capteurhaut, INPUT_PULLUP);
  50.   pinMode(modedepan, INPUT_PULLUP); // permet d'allumer tous les led strip en vue d'un depannage
  51.  
  52.     for (int marcheN = 0; marcheN < nbrmarche; marcheN++)  {
  53.     pinMode(marche[marcheN], OUTPUT);     
  54.   }
  55. }
  56. //programme
  57. void loop()
  58. {               
  59.   codergb();
  60.  
  61. //verif activite du teensy
  62. activitycount++;
  63. delay(1);
  64. if ( activitycount == 1000)
  65.   {
  66.     digitalWrite(activity, HIGH);
  67.   }
  68. if ( activitycount == 2000)
  69.   {
  70.     digitalWrite(activity, LOW);
  71.     activitycount = 0;
  72.   }
  73. // allumage marche test à l'intérieur du boitier pour configuration
  74.   if ((digitalRead ((Cpluspin) == LOW || (Cmoinspin) == LOW || (Bpluspin) == LOW || (Bmoinspin) == LOW)) && Verrou == 0)
  75.   {
  76.     digitalWrite(marchetest, HIGH);
  77.     Veille=0; //annulation veille
  78.   }
  79.  
  80.   if (digitalRead (Cpluspin) == LOW && (Cmoinspin) == LOW && (Bpluspin) == LOW && (Bmoinspin) == LOW && Verrou == 0)
  81.   {
  82.     delay(20);
  83.     Veille++;
  84.     if (Veille = 250) //tempo de 5s avant extinction marche test si aucune pression
  85.       {
  86.         digitalWrite(marchetest, LOW);
  87.      
  88.       }
  89.      
  90.   }
  91.  
  92. //mode depannage
  93.   if ((digitalRead (modedepan) == LOW )&& (Verrou == 0)) //condition de verrouillage
  94.   {
  95.     delay(1000);
  96.     Verrou = 1;
  97.   }
  98.   if ((digitalRead (modedepan) == LOW )&& (Verrou == 1)) //condition de deverrouillage et extinction du forcage d'allumage
  99.   {
  100.     delay(1000);
  101.     Verrou = 0;
  102.     for (int marcheN = 0; marcheN < nbrmarche; marcheN++) 
  103.     {
  104.       digitalWrite(marche[marcheN], LOW);
  105.     }
  106.     digitalWrite(marchetest, LOW);
  107.   }
  108.   if (Verrou == 1)
  109.   {
  110.     for (int marcheN = 0; marcheN < nbrmarche; marcheN++) // condition du forçage d'allumage
  111.     {
  112.     // allumer la marche
  113.       digitalWrite(marche[marcheN], HIGH);
  114.     }
  115.     digitalWrite(marchetest, HIGH);
  116.   }
  117. // allumage si montée de personne   
  118.   if ((digitalRead (capteurbas) == LOW) && Verrou == 0)
  119.   {
  120.     for (int marcheN = 0; marcheN < nbrmarche; marcheN++)
  121.     {
  122.     // allumer la marche
  123.       digitalWrite(marche[marcheN], HIGH); 
  124.       delay(tpsallum);
  125.     }   
  126.     delay(tpsattente);
  127.    
  128.     for (int marcheN = 0; marcheN < nbrmarche; marcheN++)
  129.     {
  130.       digitalWrite(marche[marcheN], LOW);
  131.       delay(tpsallum);
  132.     }
  133.    
  134.   }
  135. // allumage si descente de personne
  136.   if ((digitalRead (capteurhaut) == LOW) && Verrou == 0)
  137.   {
  138.     for (int marcheN = nbrmarche - 1; marcheN >= 0; marcheN--) 
  139.     {
  140.     // allumer la marche
  141.       digitalWrite(marche[marcheN], HIGH); 
  142.       delay(tpsallum);
  143.     }   
  144.     delay(tpsattente);
  145.    
  146.     for (int marcheN = nbrmarche - 1; marcheN >= 0; marcheN--)
  147.     {
  148.       digitalWrite(marche[marcheN], LOW);
  149.       delay(tpsallum);
  150.     }
  151.    
  152.   }
  153. }
  154. void codergb() //fonction de configuration des couleurs et de la luminosite
  155. {
  156.       //conditions augmentation de couleur selon un code GRAY maison.
  157.    if (digitalRead (Cpluspin) == LOW)
  158.    {
  159.       if ((ColorR == 255) && (ColorG <= 254) && (ColorB == 0)) 
  160.       {
  161.        ColorG++;
  162.        delay(20);
  163.       }
  164.       if ((ColorR >= 1) && (ColorG == 255) && (ColorB == 0)) 
  165.       {
  166.        ColorR--;
  167.        delay(20);
  168.       }
  169.       if ((ColorR == 0) && (ColorG == 255) && (ColorB <= 254)) 
  170.       {
  171.        ColorB++;
  172.        delay(20);
  173.       }
  174.       if ((ColorR == 0) && (ColorG >= 1) && (ColorB == 255)) 
  175.       {
  176.        ColorG--;
  177.        delay(20);
  178.       }
  179.       if ((ColorR <= 254) && (ColorG == 0) && (ColorB == 255)) 
  180.       {
  181.        ColorR++;
  182.        delay(20);
  183.       }
  184.       if ((ColorR == 255) && (ColorG <= 254) && (ColorB == 255)) 
  185.       {
  186.        ColorG++;
  187.        delay(20);
  188.       }
  189.    }
  190.   //conditions diminution de couleur selon un code GRAY maison.
  191.   if (digitalRead (Cmoinspin) == LOW)
  192.   {
  193.     if ((ColorR ==255) && (ColorG >= 1) && (ColorB == 255)) 
  194.     {
  195.       ColorG--;
  196.       delay(20);
  197.     }
  198.     if ((ColorR >= 1) && (ColorG == 0) && (ColorB == 255)) 
  199.     {
  200.       ColorR--;
  201.       delay(20);
  202.     }
  203.     if ((ColorR == 0) && (ColorG <= 254) && (ColorB == 255)) 
  204.     {
  205.       ColorG++;
  206.       delay(20);
  207.     }
  208.     if ((ColorR == 0) && (ColorG == 255) && (ColorB >= 1)) 
  209.     {
  210.       ColorB--;
  211.       delay(20);
  212.     }
  213.     if ((ColorR <=254) && (ColorG == 255) && (ColorB == 0)) 
  214.     {
  215.       ColorR++;
  216.       delay(20);
  217.     }
  218.     if ((ColorR ==255) && (ColorG >= 1) && (ColorB == 0)) 
  219.     {
  220.       ColorG--;
  221.       delay(20);
  222.     }
  223.   }
  224.   //augmentation et diminuion luminositee
  225.   if (digitalRead (Bpluspin) == LOW)
  226.   {
  227.     if ((Bright <= 127))  // valeur max de bright fixee a 128 pour faciliter la division de ColorR en effectuant un pourcentage qui n'en est pas vraiment un mais sans virgule flottante.
  228.     {
  229.       Bright++;
  230.       delay(50);
  231.     }
  232.   }
  233.   if (digitalRead (Bmoinspin) == LOW)
  234.   {
  235.     if ((Bright >= 1)) 
  236.     {
  237.       Bright--;
  238.       delay(50);
  239.     }
  240.  
  241.   }
  242.  
  243.   //gestion de la luminosite et du code RGB avant la sortie
  244.   CodeR = (ColorR * Bright )>>7;// décalage de 7 bits vers la droite, equivaut a une division par 128.
  245.   CodeG = (ColorG * Bright )>>7;
  246.   CodeB = (ColorB * Bright )>>7;
  247.   //activation des sorties PWM et données serial
  248.   analogWrite(redPin, CodeR);
  249.   analogWrite(greenPin, CodeG);
  250.   analogWrite(bluePin, CodeB);
  251.  
  252.   //debug
  253.   Serial.print("Verrou =" );
  254.   Serial.println(Verrou);
  255.   delay(50);
  256.   Serial.print("Veille =" );
  257.   Serial.println(Veille);
  258.   delay(50);
  259.  
  260. }

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  21  22  23  ..  263  264  265  266  267  268

Aller à :
Ajouter une réponse
 

Sujets relatifs
* Réparations de vos appareils électroniques & electromenager * 
Plus de sujets relatifs à : [arduino] Topic Unique blabla @ Arduino


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR