Problème d'interruption avec la librairie IRremote

[lemat]

Bonjour, je réalise actuellement un système de laser game a base d'arduino et je rencontre un problème avec la librairie IRremote comme la doc précise l'envoie et la réception de donnée infrarouge ne peut s'effectuer en même temps car les deux fonction utilise le même timer.

Cela me pose un gros problème car lorsque un joueur est entrain de tirer il ne peut par conséquent plus être touché.

Est t'il possible de bidouiller cette librairie pour que la réception soit toujours prioritaire  ? j'ai essayer de bidouiller les timer mais je ne m'y connais pas suffisamment ça ne ma apporter que des beug.

Voici mon sketch :
http://pastebin.com/ZFrbXjFC

Merci d'avance

[B@tto]

Ah mon avis c'est toute l'architecture de ton code qu'il faut reprendre : je vois des buzz, des delay() ... Une émission IR ne prend que quelques centaines de µs, le risque de coïncidence est extrêmement minime, le coupable à mon avis n'est pas la librairie.

Essaye en commentant tous les buzz et autres delay() pour vérifier si ça refonctionne correctement. Autre méthode : utiliser des Serial.print() ou ton écran et des millis() pour chronométrer tes fonctions. tu te rendras compte à mon avis que ton émission est bien trop longue par rapport à ce qu'elle devrait

[lemat]

Je comprend bien mais en mode rafale ça tire presque 10 coups/seconde le récepteur n'a pas le temps de se réactiver, si je descend la cadence a environ 2-3 coups/seconde ça réagit a peut près mais pas instantanément.

Lorsque le joueur ne tire pas par-contre ça réagit immédiatement, vous m'aviez aider il y'a quelques temps a optimiser cette partie la.

Je vais tenter de ne rien faire d'autre que l'émission ir pendant que l'on presse la gâchette, mais étant donner que la doc précise de base que la librairie ne peut pas emmètre et recevoir en même temps car ça utilise le même timer je ne pense pas que ça change grand chose.

Je vous tiens au courant merci de ton aide B@tto

[Artouste]

Je comprend bien mais en mode rafale ça tire presque 10 coups/seconde le récepteur n'a pas le temps de se réactiver, si je descend la cadence a environ 2-3 coups/seconde ça réagit a peut près mais pas instantanément.

Lorsque le joueur ne tire pas par-contre ça réagit immédiatement, vous m'aviez aider il y'a quelques temps a optimiser cette partie la.

Je vais tenter de ne rien faire d'autre que l'émission ir pendant que l'on presse la gâchette, mais étant donner que la doc précise de base que la librairie ne peut pas emmètre et recevoir en même temps car ça utilise le même timer je ne pense pas que ça change grand chose.

Je vous tiens au courant merci de ton aide B@tto

bonjour
c'est comprehensible que la lib ne fasse qu'une des deux taches emission ou reception
ton probleme peu peut etre etre géré avec de la priorisation :
si cible activée (touchée) = interdire l'emission (tir) du tireur touché pendant X µs (à determiner)

[lemat]

bonjour
c'est comprehensible que la lib ne fasse qu'une des deux taches emission ou reception
ton probleme peu peut etre etre géré avec de la priorisation :
si cible activée (touchée) = interdire l'emission (tir) du tireur touché pendant X µs (à determiner)

Bonjour Artouste, en rajoutant une interruption sur le front du capteur par exemple ? une variable d'autorisation de tir que je set a 0 lorsque un front et détecter pourrait fonctionner ?

Par contre j'ai peur qu'entre le moment ou l'interruption détectera le front du récepteur et coupera l'émission pour activer la réception, le code moduler soit déjà terminer.

Je ne sais pas non plus si les autre librairie que j'utilise n'utilise pas l'interruption restante au quel cas il y aura un conflit.

[Artouste]

bonjour
c'est comprehensible que la lib ne fasse qu'une des deux taches emission ou reception
ton probleme peu peut etre etre géré avec de la priorisation :
si cible activée (touchée) = interdire l'emission (tir) du tireur touché pendant X µs (à determiner)

Bonjour Artouste, en rajoutant une interruption sur le front du capteur par exemple ? une variable d'autorisation de tir que je set a 0 lorsque un front et détecter pourrait fonctionner ?

Par contre j'ai peur qu'entre le moment ou l'interruption détectera le front du récepteur et coupera l'émission pour activer la réception, le code moduler soit déjà terminer.

Je ne sais pas non plus si les autre librairie que j'utilise n'utilise pas l'interruption restante au quel cas il y aura un conflit.

je ne regarde pas ton code
le tir d'un projectile c'est une trame unique ? ou plusieurs trames identiques (avec detection de redondance ? )
une rafale c'est X trames uniques ou X fois Y trames identiques ?

[lemat]

Une rafale correspond à X trame unique :

Code: [Select]


  int frequence = (1000 / rpm)/3;
  if(millis() > lasttir+frequence){
            IRsend irsend;
            irsend.enableIROut(56);
            balle --;
            valIR = "222"+String(myteam)+String(NumArme);
            hexvalIR = valIR.toInt();
            hexvalIR = hexvalIR,HEX;
            irsend.sendRC5(hexvalIR, 20);
            buzz(8, 2500, 60);
            buzz(8, 2200, 20);
            lasttir = millis();
            irrecvTete.enableIRIn(); // Start the receiver
  }


[Artouste]

Une rafale correspond à X trame unique :

A discuter et à reflechir , mais je pense à chaud que c'est une "pas tres bonne option"

pour "coller" à la realité chaque projectile devrait etre signé
dans la vraie vie , une rafale c'est tirer X fois un projectile unique avec un delai entre chaque tir à peu pres connu et  +/- homogene et pour un nombre determiné de projectiles, tout ça contraint par la capacité d'enmagasinage .

Le principe vaut autant pour un Phalanx qu'une autre automatique. 

pour ton projet , il faut déjà determiner la durée d'un tir unique (temps necessaire de formatage et d'emission arduino)  et le temps necessaire en reception (temps d'acquisition et de decodage )
apres c'est de l'organisation de programme

[B@tto]

Je comprend bien mais en mode rafale ça tire presque 10 coups/seconde le récepteur n'a pas le temps de se réactiver, si je descend la cadence a environ 2-3 coups/seconde ça réagit a peut près mais pas instantanément.

Je vais tenter de ne rien faire d'autre que l'émission ir pendant que l'on presse la gâchette, mais étant donner que la doc précise de base que la librairie ne peut pas emmètre et recevoir en même temps car ça utilise le même timer je ne pense pas que ça change grand chose.

Je crois que tu saisis pas bien la mesure des choses : le tir en lui même ne prend que quelques centaine µS.  µS !! 

Même si je suis pessimiste et que je dis 1 ms et je tire 10 coups, ça fait 10 ms "aveugle". Donc la probabilité pour qu'un tir ne soit pas reçu est de 1%. Visiblement tu en es très loin, donc il y a un souci dans ton code, et pas dans la lib

[lemat]

Mea culpa désoler si j'ai pu sans le vouloir remettre ta parole en doute b@tto je n'avait pas très bien saisis le fonctionnement que tu ma décris, tu avait mis dans le mille car quand je commente :

Code: [Select]


buzz(8, 2500, 60);
buzz(8, 2200, 20);


Ça fonctionne très bien, sauf que du coup je ne voit pas comment jouer mes son sans pénaliser la reception 

[Artouste]

Mea culpa désoler si j'ai pu sans le vouloir remettre ta parole en doute b@tto je n'avait pas très bien saisis le fonctionnement que tu ma décris, tu avait mis dans le mille car quand je commente :

Code: [Select]


buzz(8, 2500, 60);
buzz(8, 2200, 20);


Ça fonctionne très bien, sauf que du coup je ne voit pas comment jouer mes son sans pénaliser la reception  

le "buzz"  est par definition  un gros consommateur de temps quasi exclusif
il te faut peut etre deleguer ailleurs cette tache = voir peut etre du coté des buzzers autonomes

[B@tto]

Comme l'évoque Artouste il y a des buzzer avec oscillateur intégré

[skywodd]

Je passe en coup de vent

Vu le code de buzz() il serait peut être intéressant de passer par une solution non bloquante à base d'interruption et de buffer circulaire.

L'idée en gros c'est que buzz() ne fait plus de bruit, mais ajoute simplement une note dans un buffer circulaire (FIFO) qui est ensuite lu note par note par une interruption dédié.
C'est le principe employé pour Serial.read() par exemple, tu places tes octets dans un buffer qui est ensuite lu par une interruption du port série.
Bon par contre pour être très franc si tu n'as jamais codé un buffer circulaire et jamais touché à une interruption sur AVR ça risque d'être un peu casse tête à mettre en place. La solution d'un buzzer hardware séparé pourrait être tous aussi bien dans ce cas.

[lemat]

Un buzzer autonome vous parlez bien de buzzer a ton continue type sirène d'alarme ? Si c'est ça le problème est que je perdrais tout mes "effet" sonore obtenue grâce au variation de fréquence.

Je passe en coup de vent

Vu le code de buzz() il serait peut être intéressant de passer par une solution non bloquante à base d'interruption et de buffer circulaire.

L'idée en gros c'est que buzz() ne fait plus de bruit, mais ajoute simplement une note dans un buffer circulaire (FIFO) qui est ensuite lu note par note par une interruption dédié.
C'est le principe employé pour Serial.read() par exemple, tu places tes octets dans un buffer qui est ensuite lu par une interruption du port série.
Bon par contre pour être très franc si tu n'as jamais codé un buffer circulaire et jamais touché à une interruption sur AVR ça risque d'être un peu casse tête à mettre en place. La solution d'un buzzer hardware séparé pourrait être tous aussi bien dans ce cas.

Je voit a peu près de quoi tu parle l'idée est intéressante, mais j'avoue ne jamais avoir fait ça   je vais essayer de me renseigner mais c'est pas gagner  XD

Si tu a d'autre infos doc ou peut être même une librairie (la je rêve surement lol)  je suis preneur

[B@tto]

Après tu peux peut-être également envisagé d'utiliser un lecteur de mp3, au moins la ça devient encore mieux que du tone()