lecture via pic de commande AT

[invitebd358db9]

Bonjour,

j’utilise un pic 18F46K22 pour communiquer avec un module gsm/gprs FX100 de sierra wireless.
celui-ci se pilote via des commande AT.

j'utilise donc un port uart du pic en 115000 baude pour la communication (via Rs232)
j'ai ecris mes propres procédure pour l’écriture (sortie) sur le port uart (gestion des interupte d'émission), pas de problème de ce coté là.
j'ai aussi écris mes propres procédure (gestion aussi des interuptes de réception) et je reçois bien les byte que je place pour l'instant dans un tableau (procedure faite dans l'interupt).

le problème c'est que je ne sais pas pas trop comment m'y prendre pour interpréter les trame reçues en langage c.

sans oublier le passage de l'information de l'interupt au main programme qui tourne tout les 10ms.

pour l'instant j'utilise une procédure pour le protocole cctalk,
ce protocole a une structure de trame bien définie
adresse de destination, nombre de byte de data (n), adresse source, header, data 0 , ..., data n, check sum

à chaque interupt j’incrémente une variable qui m'indique le numéro du byte reçus, et j'attribue donc ainsi les valeurs au variable correspondante et remplis un tableau pour les data reçues
une fois la trame reçue en entier je met un flag à 1 qui indique à la procédure du main () (qui tourne toute les 10ms) qu'une réponse valide à été reçues.

mais pour les commande AT, les réponse ne sont pas très formatées.

du style :
'CR' 'LF' +CSQ:13,0 'CR' 'LF'
'CR' 'LF' OK 'CR' 'LF'

de plus il peut même y avoir 2 trames de réponse.


Avez vous une idée ou une expérience a partager?
-----

[vincent66]

Bonsoir,
Les commandes AT çA date de mathusalem, une époque où les périphériques étaient le plus souvent connectés à un simple terminal...
Point étonnant donc que le module renvoie d'abord un écho de ce qu'il reçoit puis un OK d'acquittement, le tout avec des Carriage Return et Line Feed...
Ensuite après le OK, en fonction de la commande il peut renvoyer un message spécifique ou un flux de données...
Les commandes AT sont loin d'être standardisées, chaque fabricant y va de sa petite spécialité ou particularité...
La datasheet du module doit bien préciser ce que renverra le module pour chaque commande...

[invitee05a3fcc]

On peut supprimer l'écho et avoir une réponse par un nombre (plus simple a interpréter par un µC) et pas par un texte .
http://fr.wikipedia.org/wiki/Commandes_Hayes

[invitebd358db9]

Bonjour,

j'ai d'un un interupt sur chaque réception de byte sur le port uart (115200 baude).
dans cet interupt, j'ajoute le byte reçus à une trame (buffer_trame_rx[100] par exemple).
ceci soit en recherchant le byte /0 fin de string ou en mémorisant la position du byte (incrémenter à chaque réception).

vu que je peux recevoir plusieurs trame de réponse pour une seul réponse de commande "CR LF" +CNMI:0,1,0,0,0 "CR LF" "CR LF" OK "CR LF" (par exemple)
je pensais accumuler les byte reçus dans l'interupt en recherchant à chaque fois le premier byte à 0 (null terminated string) du tableau et inscire le byte reçus à cet emplacement.
peut-être en même temps calculer la longueur du buffer de réception.

dans la boucle programme (cadencée tous les 10ms) vérifier si des byte sont présent dans le buffer de réception,
si oui tester la trame pour voir si une commande valide à été reçue.
si une commande valide est reçue, retirer la partie de la trame du buffer de réception.
en dés-autorisant d'abord l'interupt, effacer (mettre à 0 les bytes de la trame valide et utilisés pour ensuite décaler les bytes pas encore validés vers la gauche)
et ensuite autoriser l'interupt.

ou alors tester dans l'interupt après chaque "CR LF" la trame et empiler les commande validée (tableau de string par exemple) mais cela prendrais beaucoup de place en ram.

qu'en pensez vous?

[A voir en vidéo sur Futura]

[RISC]

Salut,
Lorsque des trames peuvent être incluses dans d'autres trames cela devient très vite une usine à gaz en temps de traitement si on utilise pas des méthodes éprouvées.
Une des méthodes possible est la machine d'état.
Dans tous les cas, l'erreur à ne pas faire est de traiter cela dans le corps de l'interruption.
Le traitement principal doit se faire dans le programme principal et l'interruption lit et mémorise simplement les octets et active un flag pour signaler cela au programme principal
a+

[invitebd358db9]

Merci pour votre aide,

donc on garde la première solution qui me paraissait aussi la mieux. (buffer de trame de réception)
donc en utilisant une null terminated string

char buffer_trame_rx[100];

et une variable pour sa taille.

unsigned char size_buffer_trame_rx;

on purrais ecrire ceci:

void initialisation () {
 for (i=0, i<100,i++) {
  buffer_trame_rx [i] = 0;
  size_buffer_trame_rx = 0;
 }
}
si un byte est reçus (interupt de réception)
on ecrit le caractère reçu sur le premier à 0

interupt_reception_uart () {
 for (i=0, i<100; i++) {
  if (buffer_trame_rx[i] == 0) {
   buffer_trame_rx[i] = rx;   //(rx est le byte reçu)
   size_buffer_trame_rx = i;  //memoriser taille du buffer
   i = 100;  //forcer fin de boucle
  }
 }
}
enfin c'est l'idée quoi!


void main (void) {

   initialisation ();

   while (1) {

      //test si buffer reception contient quelque chose
      if (size_buffer_trame_rx != 0) {
         gestion_buffer_reception ();
      }
  
      while (pause) {      //pause est mis à 0 par interupt fixé tout les 10ms ceci afin de cadencer le programme à une vitesse fixe, constante et connue
      }
      pause = 1;
   }
}

maintenant je me demande comment faire pour extraire les données du buffer de réception après leur utilisation et ceci sans perturber la réception des byte qui pourrais arriver en rx pendant le traitement
du buffer de reception dans la boucle programme principale ?

[Jack]

Tu peux essayer avec un buffer circulaire qui permet la lecture et l'écriture "simultanée" de données sans qu'il y ait de carambolage entre celles-ci, à condition d'utiliser un buffer de taille adaptée.

[invitebd358db9]

je vais essayer avec cette idée, merci beaucoup

de plus je ne pense pas que je doivent interdire l'interupt de reception pendant le traitement du buffer de reception.

je vais tout de même ajouter (on n'en parle pas dans le lien mais ca coule de source je pense ...) 3 variables pour le gérer

index_reception (index du byte dans le tableau ou la lecture commence)
index_ecriture ((index du byte dans le tableau ou la l'ecriture doit se faire)
buffer_size (taille ou nombre de byte valide dans la trame)

j'ajouterais peut-être même un 0 à chaque ecriture sur l'index suivant index_ecriture pour pouvoir utiliser les null terminated string (à voir).

[RISC]

Salut,
Avec des buffers circulaires tu devrais pouvoir gérer ton buffer de réception (méthode très cournate pour laquelle tu pourras trouver du code sur internet) :
un pointeur (A) pointe la partie libre du buffer
un pointeur (B) pointe l'adresse du premier octet qui attend dans le buffer

La condition est que (B) peut rattraper (A) mais jamais l'inverse...sinon c'est que tu as un overflow ;=)
a+

[Jack]

Assure-toi de ne revalider les interruptions qu'après avoir effectué la gestion des pointeurs. Dans le cas contraire, tu vas te retrouver avec le problème de gestion de sections critiques liés à la programmation de tâches concurrentes. Il y a une probabilité très faible que le problème se présente, mais autant programmer proprement.

A+