[RESOLU] Aide sur dialogue avec un PIC

Bonjour a tous, je ma frotte a un problème depuis quelque temps que je n'arrive pas à résoudre.
En fait, je cherche à dialoguer entre une UNO et un pic16f873(sur lequel je n'ai pas la main).
J'ai besoin d'envoyer une trame (7 bytes) en permanence (~toute les 50ms) au pic pour le maintenir "éveillé". là pas de soucis.
Lorsque celui ci me renvoi une trame (9bytes), mon UNO la prends bien en compte. Là il répond directe (n principe) par une autre trame (11bytes) mais celle-ci n'est pas reconnu par le pic....

J'ai fais des essais avec un terminal, en envoyant la trame de 11bytes et juste après avoir reçus celle de 9, et j'ai bien un retour du pic par une nouvelle trame.
Mais mon arduino n'y arrive pas...

Voici un code pour mieux comprendre :

#include <SoftwareSerial.h>

int iCmd;
byte byXor;
byte byCmd[40];
byte byRoutine[7] = {0x0b, 0x02, 0x41, 0x01, 0x26, 0x0f, 0x60};
byte byAskNumber[11] = {0x0b, 0x02, 0x42, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x41};
byte b = 0x00;
bool boCmd = false;

SoftwareSerial pic(10, 11); // RX, TX

void setup() {
  Serial.begin(115200);
  pic.begin (115200);
}

void loop() {
   if (pic.available()) {
    b = pic.read();
    if (!boCmd && b == 0x0b) {		//Là j'attends la reception d'une trame
      byCmd[0] = b;
      boCmd = true;
      iCmd = 1;
      byXor = 0x00;
    }
    else if (boCmd) {				//J'enregistre la trame
      byCmd[iCmd] = b;
      iCmd++;
    }
    if (byXor == b && byCmd[iCmd - 2] == 0x0f) {	//Je regarde si elle est finie-
      boCmd = false;					//son dernier octet est un xor-
      InputCmd(byCmd);					//du reste, précédé par l'octet 0F
    }
    else byXor ^= b;					//Sinon je mets à jour mon comparateur de xor
  }
  else {
	delay(50);
	pic.write(byRoutine, sizeof(byRoutine));		//Pour maintenir "éveillé" le pic
  }
}

void InputCmd(byte b[]) {						//Ici je répond en fonction des trames reçues
  if (b[2] == 0x41) pic.write(byAskNumber, sizeof(byAskNumber));
}

Voila, à savoir que je n'utilise plus SoftwareSerial...
Je m'en servait pour garder le debug sur Serial mais il n'a pas l'aire de bien gérer les 115200 bauds...
Par exemple si je reçois 0x40 il comprend 0xc0, 0x41 > 0xc1 etc...

En espérant avoir été suffisamment claire sur ma requête, merci d'avance pour votre aide!

ricolewis:
Bonjour a tous, je ma frotte a un problème depuis quelque temps que je n'arrive pas à résoudre.
En fait, je cherche à dialoguer entre une UNO et un pic16f873(sur lequel je n'ai pas la main).
J'ai besoin d'envoyer une trame (7 bytes) en permanence (~toute les 50ms) au pic pour le maintenir "éveillé". là pas de soucis.
Lorsque celui ci me renvoi une trame (9bytes), mon UNO la prends bien en compte. Là il répond directe (n principe) par une autre trame (11bytes) mais celle-ci n'est pas reconnu par le pic....

J'ai fais des essais avec un terminal, en envoyant la trame de 11bytes et juste après avoir reçus celle de 9, et j'ai bien un retour du pic par une nouvelle trame.
Mais mon arduino n'y arrive pas...

bonsoir
L'arduino repond peut etre trop vite au PIC ?

essayer un "petit" délai avant l'envoi de la trame de 11 bytes ?

Bonsoir, oui j'y ai pensé, et essayé plusieurs delay un peu partout et plus ou moins long :S
Sans succés... Mais effectivement j'ai beaucoup centré mes recherches de ce coté là.

Mettons que je glisse un delay500 à ma Routine, ça va fonctionné mais forcément se sera pas très réactif.
Donc il y a ce delay de 500 ms, si je stimule le pic il m'envoi bien la trame (il faut insister parce qu'il attend la routine pour envoyer sa trame).
Donc j'ai bien la réponse du PIC, ensuite j'ai essayer divers delay pour envoyer ma réponse, j'ai aussi essayé de bloquer la routine mais rien a faire...
Je ne penses pas non plus qu'il faille etre plus rapide que sans delay parce que j'y arrive mano avec un terminal. (Bon il faut que je bourrine sur l'envoi de ma commande tout en faisant la bonne action coté PIC) mais sa fini par passer sans trop de mal...

J'ai fais des essais avec un terminal, en envoyant la trame de 11bytes et juste après avoir reçus celle de 9, et j'ai bien un retour du pic par une nouvelle trame.
Mais mon arduino n'y arrive pas..

un petit analyseur logique permettrait de repérer la choronologie qui va bien pour la reproduire

Si SofwareSerial n'est plus utilisé quelle sortie Tx envoie la trame au PIC ? (la sortie TX reliée au PC via l'USB ?)

al1fch:
un petit analyseur logique permettrait de repérer la choronologie qui va bien pour la reproduire

Oui c'est vrai... malheureusement je n'ai pas ça sous la main :frowning:

al1fch:
Si SofwareSerial n'est plus utilisé quelle sortie Tx envoie la trame au PIC ? (la sortie TX reliée au PC via l'USB ?)

Oui je l'ai branché aux pin 0 & 1, et finalement je fais mon débug via softwareSerial avec un adapateur usb/ttl.

ricolewis:
Bonsoir, oui j'y ai pensé, et essayé plusieurs delay un peu partout et plus ou moins long :S
Sans succés... Mais effectivement j'ai beaucoup centré mes recherches de ce coté là.

Mettons que je glisse un delay500 à ma Routine, ça va fonctionné mais forcément se sera pas très réactif.
Donc il y a ce delay de 500 ms, si je stimule le pic il m'envoi bien la trame (il faut insister parce qu'il attend la routine pour envoyer sa trame).
Donc j'ai bien la réponse du PIC, ensuite j'ai essayer divers delay pour envoyer ma réponse, j'ai aussi essayé de bloquer la routine mais rien a faire...
Je ne penses pas non plus qu'il faille etre plus rapide que sans delay parce que j'y arrive mano avec un terminal. (Bon il faut que je bourrine sur l'envoi de ma commande tout en faisant la bonne action coté PIC) mais sa fini par passer sans trop de mal...

comme Al1 vient de le suggerer
puisque à la "mano" çà marche :grin: , l'ideal est d'utiliser un analyseur logique pour determiner où et quand cela cela coince :wink:
un petit analyseur clone Salae à 7/8 € est parfaitement adapté là
il y a plusieurs delais où cela pourrait etre critique ( delai inter byte par exemple )

Bon aller, je viens d'en commander un. C'est vrai que ça a l'air sympas comme joujou et ça risque de me servir pas mal.

Artouste:
il y a plusieurs delais où cela pourrait etre critique ( delai inter byte par exemple )

Oui, j'ai pas trop creusé par là. Enfin, j'ai essayé d'envoyer les bytes une par une mais sans delay... (je savais plus quoi faire) :smiley:

envoyer une trame (7 bytes) en permanence (~toute les 50ms) au pic pour le maintenir "éveillé". là pas de soucis.

Bonjour,
et si tu pervertis cette trame (valeurs bidon), ça marche quand-même (par hazard) ?

trimarco232:
Bonjour,
et si tu pervertis cette trame (valeurs bidon), ça marche quand-même (par hazard) ?

Bonjour! Non, il veux vraiment celle ci.
Et si je ne lui envoi pas, je ne reçois rien de lui pas même la première trame qui déclenche mon envoie de "byAskNumber"....

Aujourd'hui j'ai essayé avec un méga (des foies que...) sans succès. Je vais attendre de recevoir l'analyseur logique pour en apprendre plus. (d'ici 2 semaines avec de la chance l'envoie n'a pas encore été confirmé :frowning: ).

Bonsoir!
Je reviens après avoir observé de plus près avec un analyseur logique.
Donc, il semblerait que mon programme envoi un byte (byRoutine) avant le byte de réponse (byAskNumber).... ce qui évidement doit entrainer une incompréhension coté pic...
Je ferais quelques essais pour solutionné cela... une petite image pour mieux comprendre :IMAGE

Sur ce, à bientot et bonne nuit!

EDIT : C'est bon!! J'ai déplacé le Delay après l'envoi de la routine, mis une condition à cette routine qui la stoppe dès réception d'un byte, et la reprend après InputCmd().
Je suis persuadé d'avoir déjà essayer quelque chose de similaire... à un détail près faut croire :wink:

ricolewis:
Bonsoir!
Je reviens après avoir observé de plus près avec un analyseur logique.
Donc, il semblerait que mon programme envoi un byte (byRoutine) avant le byte de réponse (byAskNumber).... ce qui évidement doit entrainer une incompréhension coté pic...
Je ferais quelques essais pour solutionné cela... une petite image pour mieux comprendre :IMAGE

Sur ce, à bientot et bonne nuit!

EDIT : C'est bon!! J'ai déplacé le Delay après l'envoi de la routine, mis une condition à cette routine qui la stoppe dès réception d'un byte, et la reprend après InputCmd().
Je suis persuadé d'avoir déjà essayer quelque chose de similaire... à un détail près faut croire :wink:

Bonsoir
:grin:

dicton populaire :

Les bons outils font les bons ouvriers :wink: