Autor Tema: Funciones de respuesta a comando AT  (Leído 5211 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado cvargcal

  • PIC16
  • ***
  • Mensajes: 166
Funciones de respuesta a comando AT
« en: 03 de Abril de 2015, 15:47:41 »
Hola,
Alguien tiene alguna idea de como hacer una función para ir comprobando la respuesta a un comando AT,
para posteriormente continuar  con la configuración en caso de recibir la respuesta "Ok"
Se que se puede hacer con los IF pero no se si será la única opción.

Ejemplo:
AT x1,OK       >> si es verdadero continuo
AT x2,OK
AT x3,OK

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: Funciones de respuesta a comando AT
« Respuesta #1 en: 03 de Abril de 2015, 16:13:54 »
También puedes hacerlo con un switch case pasas el comando recibido por la función y realizas las tareas necesarias para lo que haga la aplicacion
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado cvargcal

  • PIC16
  • ***
  • Mensajes: 166
Re: Funciones de respuesta a comando AT
« Respuesta #2 en: 04 de Abril de 2015, 03:03:10 »
También puedes hacerlo con un switch case pasas el comando recibido por la función y realizas las tareas necesarias para lo que haga la aplicación

¿Algo así?

enviar(AT);

int enviar(char AT)
{
fprintf(uart1,AT)  
       switch(buffer){                        
         case 'OK': break;  
         default:   fprintf(uart1,AT)
}

(Es una idea, se que esta mal definida.)

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: Funciones de respuesta a comando AT
« Respuesta #3 en: 04 de Abril de 2015, 07:03:53 »
Mas o menos, ten en cuenta que esa función cuando termine continuara, aun que los mensajes sean correctos o no. Lo k si haces es asegurarte que han llegado los 3 oks. También la función seria void enviar pork no devuelve nada. Deberías  poner quizás 3 banderas y activarlas en el switch case, así cuando salgas de esa función puedes poner la condición de k si no se cumplen pase a recibir del siguiente comando. O para reducir el código una sola variable de error, si encuentra un error que se ponga a 1. Si no encuentra errores sera 0. De esta manera solo tienes una bandera y no 3.
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado juanelete

  • PIC12
  • **
  • Mensajes: 74
Re: Funciones de respuesta a comando AT
« Respuesta #4 en: 04 de Abril de 2015, 21:30:59 »
Hola a tod@s

Precisamente llevo un par de semanas experimentando con un teléfono (a la espera de un modulo sim900) enviando y recibiendo SMS y llamadas con un PIC16F1938 y CCS 5.43. He conseguido enviar y recibir SMSs y dependiendo de si el numero esta autorizado ejecutar los comandos indicados en el cuerpo del mensaje. Si alguien necesita alguna información puedo ayudarle en lo que yo sepa...

A mi parecer, la parte mas problemática es cuando como consecuencia de un comando AT enviado al modem, o porque se esta recibiendo un SMS o una llamada entrante, se reciben datos por el puerto serie del PIC, pero.. ¿Cuándo se ha terminado de recibir una trama completa?.

La respuesta de muchos comandos es <CR><LF>OK<CR><LF> ó <CR><LF>ERROR<CR><LF> con lo cual parece fácil, solo hay que controlar el segundo par de <CR><LF> y dar la trama por finalizada.

Pero otras veces la respuesta es del tipo <CR><LF>+CPAS: x<CR><LF><CR><LF>OK<CR><LF> ya no solo tenemos que controlar el par <CR><LF> sino si lo que hay antes del ultimo <CR><LF> es "OK" ó "ERROR" ó "RING"...etc antes de dar por finalizada la recepción de datos y pasar a procesar la cadena.

Aun se complica mas, la respuesta al comando AT+CMGS="+34123456789"<CR>  es  <CR><LF> seguida del carácter '>' y luego un espacio (carácter 32).

Al final la parte del código que lee del puerto serie y que solo debería poner los caracteres en el buffer de recepción y pasarlo a la función que se encargue de procesarlo se ha complicado mucho y se pierde mucho tiempo cada vez que se recibe un carcater .

Una solución diferente y mas sencilla para saber cuando se ha terminado de recibir una trama seria aprovechando como funciona el puerto serie, me explico. Si configuramos el puerto a 9600 baudios, significa que se reciben 9600 bits cada segundo, y haciendo la cuenta se recibe un carácter (8bit) cada 833us (micro segundos). Si en la rutina de recepción ponemos un contador, que ponemos a cero cada vez que se reciba un carácter, en el momento que recibamos el ultimo carácter, el contador sobrepasara los 833us y nos indicara el final de la trama. Rapido y sencilo.

He probado los dos sistemas y los dos parece que funcionan.

Mi pregunta (por fin después de tanto rollo) es:
- Hay alguna otra forma de hacerlo ?
- Usando el método del tiempo, ¿podría ser que se recibieran dos tramas diferentes tan juntas que la diferencia entre el ultimo carácter y el primero de la siguiente no excedieran de los 833us y se recibieran como una sola trama?

Me gustaría que me dierais vuestra opinión

Perdon por el rollazo.

Saludos a tod@s   :-/ :-/

Desconectado PalitroqueZ

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5474
    • Electrónica Didacta
Re: Funciones de respuesta a comando AT
« Respuesta #5 en: 04 de Abril de 2015, 21:46:35 »
yo lo he hecho asi, determino el ancho de la trama a recibir y un temporizador que funcione como un time-out

debes saber cuantos caracteres envia el modem en respuesta al comando AT.
configuras el buffer de recepción.
escribes una rutina que localice los caracteres "O" "K" .
si existen esos caracteres entonces procedes a la siguiente configuración.
sino, puedes optar por enviar nuevamente el caracter.
en todo caso, hay que activar un temporizador que se quede esperando por la respuesta del modem.
La propiedad privada es la mayor garantía de libertad.
Friedrich August von Hayek

Desconectado cvargcal

  • PIC16
  • ***
  • Mensajes: 166
Re: Funciones de respuesta a comando AT
« Respuesta #6 en: 05 de Abril de 2015, 03:04:19 »
Hola a tod@s

Precisamente llevo un par de semanas experimentando con un teléfono (a la espera de un modulo sim900) enviando y recibiendo SMS y llamadas con un PIC16F1938 y CCS 5.43. He conseguido enviar y recibir SMSs y dependiendo de si el numero esta autorizado ejecutar los comandos indicados en el cuerpo del mensaje. Si alguien necesita alguna información puedo ayudarle en lo que yo sepa...

A mi parecer, la parte mas problemática es cuando como consecuencia de un comando AT enviado al modem, o porque se esta recibiendo un SMS o una llamada entrante, se reciben datos por el puerto serie del PIC, pero.. ¿Cuándo se ha terminado de recibir una trama completa?.

La respuesta de muchos comandos es <CR><LF>OK<CR><LF> ó <CR><LF>ERROR<CR><LF> con lo cual parece fácil, solo hay que controlar el segundo par de <CR><LF> y dar la trama por finalizada.

Pero otras veces la respuesta es del tipo <CR><LF>+CPAS: x<CR><LF><CR><LF>OK<CR><LF> ya no solo tenemos que controlar el par <CR><LF> sino si lo que hay antes del ultimo <CR><LF> es "OK" ó "ERROR" ó "RING"...etc antes de dar por finalizada la recepción de datos y pasar a procesar la cadena.

Aun se complica mas, la respuesta al comando AT+CMGS="+34123456789"<CR>  es  <CR><LF> seguida del carácter '>' y luego un espacio (carácter 32).

Al final la parte del código que lee del puerto serie y que solo debería poner los caracteres en el buffer de recepción y pasarlo a la función que se encargue de procesarlo se ha complicado mucho y se pierde mucho tiempo cada vez que se recibe un carcater .

Una solución diferente y mas sencilla para saber cuando se ha terminado de recibir una trama seria aprovechando como funciona el puerto serie, me explico. Si configuramos el puerto a 9600 baudios, significa que se reciben 9600 bits cada segundo, y haciendo la cuenta se recibe un carácter (8bit) cada 833us (micro segundos). Si en la rutina de recepción ponemos un contador, que ponemos a cero cada vez que se reciba un carácter, en el momento que recibamos el ultimo carácter, el contador sobrepasara los 833us y nos indicara el final de la trama. Rapido y sencilo.

He probado los dos sistemas y los dos parece que funcionan.

Mi pregunta (por fin después de tanto rollo) es:
- Hay alguna otra forma de hacerlo ?
- Usando el método del tiempo, ¿podría ser que se recibieran dos tramas diferentes tan juntas que la diferencia entre el ultimo carácter y el primero de la siguiente no excedieran de los 833us y se recibieran como una sola trama?

Me gustaría que me dierais vuestra opinión

Perdon por el rollazo.

Saludos a tod@s   :-/ :-/


Yo uso algo así:


int find_string(char* buf,char* word)          
{
   char*srch_word;
   srch_word=strstr(buf,word);
   if(srch_word>0)return(1);
   else return(0);
}


fprintf(uart1,ID_IMEI);delay_ms(1000);      // Comando AT Solicitar IMEI
          if(find_string(buffer1,"$TTDEVID")){     // Buscar  Responde $TTDEVID:555555555512345
            disable_interrupts(int_rda);
             for(n=0;buffer1[n]!=0;n++){        // Recorrer Buffer1
                if(buffer1[n]==':'){            // Si encontro ":" TTDEVID:555555555512345  
                  i=0;                          //
                  do{                           // Extraer ID del buffer a partir ":" y hasta \0.
                    IMEI=buffer1[n+1]; n++;  //
                   }while(buffer1[++i]!=0x00);   //
                   fprintf(uart2,"ID:%s",IMEI);    // Enviar ID
                   IMEIOK=1;                       // ID Configurado
            }
         }

busco el inicio de la trama y lo recorro hasta el final o hasta donde deba ser el carácter final.

Desconectado juanelete

  • PIC12
  • **
  • Mensajes: 74
Re: Funciones de respuesta a comando AT
« Respuesta #7 en: 05 de Abril de 2015, 08:32:51 »
Hola a tod@s

PalitroqueZ, muchas gracias por responder

Citar
debes saber cuantos caracteres envia el modem en respuesta al comando AT.

Esto no siempre es posible con un 100% de fiabilidad, algunos comandos devuelven un numero variable
de caracteres. Por ejemplo la respuesta al envio de un SMS es <CR><LF>+CMGS: x<CR><LF><CR><LF>OK<CR><LF>,
siendo x un valor de 1 a 255 (de 1 a 3 caracteres). O cuando en la trama va un numero de teléfono, que puede
ir en formato local o internacional (+xx) osea 3 caracteres mas...

Citar
configuras el buffer de recepción.
escribes una rutina que localice los caracteres "O" "K".

Que pasaria si justo despues de configurar el buffer para recibir la respuesta a un comando, te entra
una llamada, o un mensaje... Evidentemente ni la longitud, ni los datos son los que esperabas...

Citar
en todo caso, hay que activar un temporizador que se quede esperando por la respuesta del modem.

Entiendo que ese temporizador o time-out actua solo para evitar que el programa se quede atascado
en la rutina de recepcion


cvargcal, muchas gracias a ti tambien por responder

Segun el trozo de codigo que has puesto, observo que despues de enviar el comando AT, esperas con un
delay_ms el tiempo suficiente para que la rutina de recepcion mediante la int_rda cargue en buffer todos
los caracteres que entran por el puerto serie y despues pasas a procesarlo comprobando previamente
que es la trama correcta.

No has incluido la rutina que maneja la int_rda, y no aclaras como determinas cuando la trama de recepcion
esta completa, o simplemente cargas en buffer todo lo que entre durante delay_ms(1000)...

Yo cambiaria un poco el codigo para evitar esas temporizaciones

#int_rda
void rs232_int()

   char c;
   
   if(kbhit(MODEM))
   {
      c=fgetc(MODEM);
     
      if(c>31 && c<127)    //Solo caracteres imprimibles       
      {
         c = toupper(c);   //lo paso a mayusculas
         
         buffer[i++]=c;
   
        flag_rda=TRUE;      //Bandera recepcion caracter
      }
   } 
}


y dentro del main()


while(true)  //Bucle infinito
{
    if(flag_rda)
    {
   //Aqui iria el codigo que determinaria cuando se ha recibido el ultimo
        //caracter de la trama, bien analizando lo recibido hasta el momento o
        //bien por tiempo entre caracteres

   if(trama_completa)
            flag_trama_recibida=TRUE;
       
        flag_rda=FALSE;
    }
         
    if(flag_trama_recibida)   //Recibida cadena de datos en el modem
    {
        //Codigo para procesar los datos recibidos

        flag_trama_recibida=FALSE;
    }
}

y te digo lo mismo que a PalitroqueZ, que pasaria si justo despues de enviar el comando AT y antes
de recibir la respuesta, te entra una llamada, o un mensaje... Evidentemente no seran los datos
que esperabas...

Puede parecer que es improbable que esto suceda, pero ya te digo que es posible...

Siento mucho parecer demasiado perfeccionista y sacarle pegas a todo, pero es que quiero hacer un
programa a prueba de fallos.

Para mi lo ideal seria hacer una rutina de recepcion que analizara los datos y actuara en consecuencia
independientemente de si el progarama estaba haciendo otra cosa, se interrumpiria, haria lo que
indicara la nueva trama y luego seguiria donde se interrumpio...

Mi pregunta sigue siendo la misma:
- Hay alguna otra forma de hacerlo ?
- Usando el método del tiempo, ¿técnicamente, podría ser que se recibieran dos tramas diferentes tan juntas que la diferencia entre el ultimo carácter y el primero de la siguiente no excedieran de los 833us y se recibieran como una sola trama?

Me gustaría que me dierais vuestra opinión


Saludos a tod@s   :-/ :-/

Desconectado PalitroqueZ

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5474
    • Electrónica Didacta
Re: Funciones de respuesta a comando AT
« Respuesta #8 en: 05 de Abril de 2015, 11:25:50 »
Citar
Esto no siempre es posible con un 100% de fiabilidad, algunos comandos devuelven un numero variable
de caracteres. Por ejemplo la respuesta al envio de un SMS es <CR><LF>+CMGS: x<CR><LF><CR><LF>OK<CR><LF>,
siendo x un valor de 1 a 255 (de 1 a 3 caracteres). O cuando en la trama va un numero de teléfono, que puede
ir en formato local o internacional (+xx) osea 3 caracteres mas...

es por ello es que sugerí revisar las tramas de respuestas del módem con un analizador por puerto serial. ahí se pueden precisar la longitud máxima de la trama de respuesta.

Citar
Que pasaria si justo despues de configurar el buffer para recibir la respuesta a un comando, te entra
una llamada, o un mensaje... Evidentemente ni la longitud, ni los datos son los que esperabas...

umm, no debería, porque para que el módem pueda responder, tendrías que enviarle un comando y eso no se hace hasta que se haya configurado el modulo USART del micro.



La propiedad privada es la mayor garantía de libertad.
Friedrich August von Hayek

Desconectado juanelete

  • PIC12
  • **
  • Mensajes: 74
Re: Funciones de respuesta a comando AT
« Respuesta #9 en: 05 de Abril de 2015, 18:09:38 »
Hola a tod@s

Citar
es por ello es que sugerí revisar las tramas de respuestas del módem con un analizador por puerto serial. ahí se pueden precisar la longitud máxima de la trama de respuesta.

Si es solo para saber la longitud maxima y asi dimensionar correctamente el buffer de recepcion, pues vale.

Pero a lo que yo me referia es que, en algunas tramas, no puedes saber "a priori" su tamaño exacto y no puedes utilizar su longitud como dato fiable para saber cuando se ha completado una trama, puesto que puede variar en vaios caracteres.

Citar
umm, no debería, porque para que el módem pueda responder, tendrías que enviarle un comando y eso no se hace hasta que se haya configurado el modulo USART del micro.

Partimos de que ya tenemos el PIC y el modem configurado y a la espera de recibir SMSs con instrucciones ó si salta alguna alarma enviar un SMS notificandolo. El PIC puede estar en un bucle infinito, o durmiendo, con la condicion de despertarse si salta la int_rda o alguna int_ext.

Normalmente el modem se configura para que cuando reciba un SMS lo almacene y te envie una trama indicandote en que posicion lo ha almacenado, ó directamente sin almacenarlo, que te envie todo el contenido del SMS. Asi mismo si recibes una llamada, el modem te lo notificara con otra trama. En estos casos recibes datos sin haber previamente enviado ningun comando al modem, por lo tanto si es posible, por ejemplo, que un usuario envie un SMS solicitando el numero de telefono del ultimo SMS recibido, entonces configurarias el buffer para enviar el correspondiente comando AT que te mostrara esos datos, pero justo antes de enviar el comando AT, cuando ya tienes configurado el bufer y los datos de la trama que esperas recibir, te entra otro SMS, o una llamada, los datos que esperabas ya no se corresponden...

Una posibilidad seria desabilitar la int_rda cada vez que recibes una trama y habilitarla solo despues de haber terminado todo lo que tuvieras que hacer... pero evidentemente, si el proceso requiere comunicarte con el modem, tienes que habilitarla... y si no lo requiere, tambien perderias cualquier comunicacion entrante.

Creo que es mejor dejar el proceso preparado para recibir cualquier trama, en cualquier momento, sin saber previamente que trama  sera, y una vez analizada actuar en consecuencia.


Nota aclaratoria:
No es mi intencion, ni muchisimo menos, enzarzarme en una discusion "haber quien la tiene mas larga",  :lol:  mi unico deseo es contrastar informacion
y aprender un poquito mas. Con ese "espiritu" en mente estoy encantado de seguir debatiendo contigo o con cualquier persona que quiera expresar su opnion...

Salud@s  :-/ :-/

Desconectado jorge luis

  • PIC10
  • *
  • Mensajes: 13
Re:Funciones de respuesta a comando AT
« Respuesta #10 en: 17 de Octubre de 2015, 04:11:03 »
hola, una consulta yo tengo implementado el siguiente codigo, pero al simular en proteus, el do while de la interrupcion RDA solo me esta capturando el valor del caracter que llega, la variable data se esta actualizando pero no se adiciona a la variable cadena, es decir no se esta juntando los caracteres en el array cadena. podrian ayudarme con esta duda por favor, probe en proteus simulando paso a paso y ahi pude ver que solo el valor de la variable "data" se va actualizando, mientras que la variable "cadena" no actualiza ninguno de sus caracteres ni siquiera el primer caracter, ayuda por favor.

Código: [Seleccionar]
#include <16f877a.h>
#include <string.h>
#include <stdlib.h>
#fuses NOWDT,HS,NOLVP
#use delay(clock=10M)

#use RS232(baud=9600,XMIT=PIN_C6,RCV=PIN_C7,stream=receptor)

#bit RB0=0x06.0
#bit RB1=0x06.1
#bit RC3=0x07.3
#bit RC4=0x07.4
#bit RC7=0x07.7

int i;
int const length=10;
char data;
char cadena[length];
short flagcomand=0;
signed int16 p=0;

#int_RDA
void  RDA_isr(void)
{
   do
   {
    data=fgetc(receptor);
    if(data=='\0')
      {
       break;
      }
    else
      {
       cadena[i]=data;
       i++;
      }
   }while(kbhit(receptor));
  flagcomand=1;
}


void limpiar_buffer()
 {
  int j;
  for(j=0;j<length;j++)
   {
    cadena[j]=0x00;
   }
 }

#INT_EXT                    // directiva de interrupcion por cambio de estado en RB0
void interrupcion_RB0()
{
 if(RB0==1)
   {
    ext_int_edge(H_TO_L);
    if(RB1==1)
      {
       p=p+1;
      }
   }
 else
   {
    ext_int_edge(L_TO_H);
    if(RB1==1)
      {
       p=p-1;
      }
   }
 //putc(p);
 //puts(p);
 printf("\r%Ld",p);
}

void main()
{
  //char valorRec[4];          //variable donde se recibira desde la cadena
  char c;
  int d;
 
 set_tris_b(0xFF);               //configuro portb=in
 set_tris_c(0x80);               //solo el Rx esta como entrada
 RC3=0;
 RC4=0;
 //configuracion pwm
 setup_ccp1(CCP_PWM);
 setup_timer_2(T2_DIV_BY_16,255,1);      //Tpwm=1.63ms--->el ciclo de trabajo sera de 0-255
 set_timer2(0);
 set_pwm1_duty(0);
 enable_interrupts(INT_RDA);
 enable_interrupts(INT_EXT);     //habilito interrupcion RB0
 ext_int_edge(L_TO_H);           //configuro interrupcion por flanco de subida
 enable_interrupts(GLOBAL);      // habilito interrupcion global
 
 
 while(TRUE)
  {
   //gets(valorRec);
   c=cadena[0];
   if(flagcomand==1)
    {
    flagcomand=0;
   switch(c)
     {
      case 's':
        {
         //printf("%3Lu",p);
         //putc(p);
         //printf("%3u",pv);
         //delay_ms(500);
         break;
        }
      case 'i':
         {
          RC3=0;
          RC4=1;
          break;
         }
      case 'd':
         {
          RC3=1;
          RC4=0;
          break;
         }
      default:
         {
          d=atoi(cadena);
          set_pwm1_duty(d);
          //putc(p);
          //printf("%3Lu",p);
          break;
         }
     }
   limpiar_buffer();
   }
 }

}

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re:Funciones de respuesta a comando AT
« Respuesta #11 en: 17 de Octubre de 2015, 04:21:40 »
El problema es simple de arreglar, te voy a decir unas cosas y si haces caso a eso y lo programas pensando en eso vas a lograrlo

- No podes tener un do..while en una interrupcion. Una interrupcion deberia durar lo menos posible, es hacer algo rapido y salir. Asi permitir que se pueda disparar de nuevo la interrupcion. (lo mismo ocurre con los printf entre otros, todos afuera de las interrupciones)
- Por cada interrupcion vas a recibir 1 byte ( 1 letra ) de tu respuesta. Asi que vas a necesitar algo que mantenga el indice del buffer que estas llenando, cuando entre a la interrupcion guardar y aumentas el indice. Cuando encontraste un \n o \r\n segun lo que mande el dispositivo que estas leyendo sabes que termino y das aviso a tu programa (ejemplo flagcomando) para que haga lo que sea con ese dato.

Espero que te des cuenta que estas haciendo mal en la interrupcion.
« Última modificación: 17 de Octubre de 2015, 04:30:31 por KILLERJC »

Desconectado jorge luis

  • PIC10
  • *
  • Mensajes: 13
Re:Funciones de respuesta a comando AT
« Respuesta #12 en: 11 de Noviembre de 2015, 04:02:30 »
Hola KILLERJC, estara atareado con otras cosas y recien me di tiempo para probarlo segun indicaste, es correcto tal como dijiste quite el bucle do while y funciona bien muchas gracias por la ayuda. una consulta has hecho comunicacion bluetooth con android studio y el modulo HC-05?? yo realice una app en app inventor y me logro comunicar con mi modulo bluetooth y controlo un pwm y envio de datos, pero ahora intento hacerlo con android studio pero no se bien como hacerlo. adjunto la imagen que hice en app inventor y pretendo hacer la misma funcionalidad pero en android studio, agradeceria si pudieras ayudarme.

por cierto la interrupcion lo deje asi:

#int_RDA
void  RDA_isr(void)
{
   static unsigned int8 i;
   data=fgetc(receptor);
   if(data=='\r')
   {
      cadena=0; //fin de cadena de texto
      i=0;
      flagcomand=1;
   }
   else
   {
      cadena[i++]=data;
   }
}

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re:Funciones de respuesta a comando AT
« Respuesta #13 en: 11 de Noviembre de 2015, 10:41:45 »
La verdad no tengo idea de android especialmente por que no tengo un celular con el mismo, siempre fue mi idea de comprarlo pero gastar una fortuna para tener un buen celular no va conmigo, me quedo con mi nokia y mando mensajitos y llamo xD.  Creo que es por lo unico que nunca hice nada con android

Desconectado jorge luis

  • PIC10
  • *
  • Mensajes: 13
Re:Funciones de respuesta a comando AT
« Respuesta #14 en: 11 de Noviembre de 2015, 13:38:57 »
ok entiendo, bueno yo estoy usando el celular de mi hermano, también soy de la idea de que no es necesario tener un celular tan caro al menos por ahora. Gracias por la ayuda KILLERJC.