No se puede escribir en el módulo GSM a través de la conexión serial desde la placa ARM

1

En nuestro proyecto de Graduación, se supone que debemos conectar un módulo GSM (ADH8066) a nuestra placa ARM (OK-6410) que ejecuta Linux incorporado (Qtopia) y comunicarnos con él.

Cuando operamos por primera vez en el módulo, envía un mensaje "Listo", luego podemos comunicarnos con él a través de comandos AT. Nos comunicamos con éxito usando Hyper-Terminal y logramos enviar un simple SMS.

El problema ocurre cuando intentamos comunicarnos con él desde la placa ARM.

Nos las arreglamos para recibir el mensaje "Listo", pero luego no tenemos ninguna respuesta.

Aquí está el código que hemos desarrollado hasta ahora:

int main(void){

    int fd;
    char *dev ="/dev/ttySAC3";
    struct termios options;

    char buffer[20];
    char buffer2[20];
    char *bufptr;
    char *bufptr2;
    bufptr = buffer;
    bufptr2 = buffer2;
    int nbytes,nbytes2=0;

    fd = open (dev, O_RDWR | O_NOCTTY);

    tcflush(fd, TCIOFLUSH);

    tcgetattr(fd, &options);

    cfsetispeed(&options, B115200); //Set Baud-rate to 115200
    cfsetospeed(&options, B115200);

    options.c_cflag |= CLOCAL | CREAD; //Enable the receiver and set local mode
    options.c_cflag &= ~PARENB; //No parity (8N1)
    options.c_cflag &= ~CSTOPB;
    options.c_cflag &= ~CSIZE;
    options.c_cflag |= CS8;
    options.c_cflag &= ~CRTSCTS; //Disable hardware flow control

    options.c_lflag |= (ICANON | ECHO | ECHOE); //enable input-canonical mode

    options.c_iflag = IGNPAR; //Ignore parity errors
    options.c_iflag &= ~(IXON | IXOFF | IXANY); //Disable software flow control

    options.c_oflag &= ~OPOST; //disable output-processing mode

    tcsetattr(fd, TCSANOW, &options);

    printf("Hello GSM\n");

    tcflush(fd, TCIOFLUSH);

    //capture the "Ready" message
    while(1){
        nbytes = read(fd, bufptr, 1);
        if (0!=strstr(buffer,"Ready")){
            printf("\nReady Found!\n");
            break;
        }
        bufptr += nbytes;
    }

    tcflush(fd, TCIOFLUSH);

    // send simple "AT" AT command
    int y = write(fd,"AT\r\n",4);
    if (y==4)
        printf("Written\n");

    //trying to capture the "OK" response for the above AT command
    while(1){
        nbytes2 = read(fd, bufptr2, 1);
        printf("%c\n",*bufptr2);
    }

    return 1;
}

obtuvimos esta respuesta:

Hello GSM


--- Ready Found! ---
Written: 3

y luego bloquea y permanece inactivo.

Si logramos capturar el mensaje "Listo", ¿no significa que "leer" funciona bien? y si "escrito" está impreso arriba, ¿no significa eso que "escribir" funciona bien?

Entonces, ¿por qué no podemos comunicarnos con el módulo?

Gracias.

    
pregunta ElOrabi

1 respuesta

1

Algunas cosas para verificar:

  • Siempre obtengo poco al usar UART / RS232 con el carácter de nueva línea & Caracteres de retorno de carro. Parece que estás usando \r\n para lo que puede o no ser lo que quiere el módulo. Una comprobación rápida de la hoja de datos del módulo no reveló nada especificando lo que quiere. Asegúrese de que eso es lo que está enviando en Hyper-Terminal al verificar qué caracteres (si corresponde) se adjuntan para usted. Vaya a File>Properties>Settings>ASCII Setup... para su sesión de HyperTerminal de trabajo y vea cuáles son las configuraciones. Puede que no esté agregando ningún salto de línea (pero lo dudo).

Aveces,losperiféricossoloquierenunouotro(yasea\ro\n).Además,asegúresedequeloshayacodificadocorrectamenteparasucompilador,yaquealgunoscompiladorestratanlosliteralesdecadenayamp;escapardelospersonajesdemaneradiferente.Sirealmentequieressaberquéestápasando,terecomiendoun COM port sniffer (no te preocupes, esto uno es realmente libre). De esa manera, puede llegar al meollo de lo que se está enviando para convencer al módulo para que funcione.

  • No estoy seguro de lo que hace la línea de código tcflush(fd, TCIOFLUSH); , pero puede intentar poner uno entre la lectura y la escritura en caso de que su El búfer de UART se está arruinando de alguna manera.

  • Asegúrese de estar en el UART correcto, hay dos UART en la parte, y uno es para enviar comandos AT, el otro está reservado.

  • Reduzca su velocidad de transmisión. Ahora mismo estás corriendo a 115200 baudios. Intenta correr a 9600 baudios. Esto podría ayudar a las cosas si hay un problema con el ruido en la línea, lo que podría ser una posibilidad real dependiendo de cómo lo conectó. El cable de la PC al módem está bastante bien blindado. Si su configuración es solo una placa de emparedado con cable de longitud diferente en todo el lugar, podría introducir / captar ruido. Operar a una frecuencia más baja ayudará a reducir esos efectos.

  • Verifique otras cosas como el número de bits de parada / paridad. Hay varias configuraciones en un UART que una computadora puede haber decidido por usted, que su controlador incorporado puede no tener. Algunas configuraciones comunes de UART (además de la velocidad en baudios) son el número de bits de parada y amp; Si usas bits de paridad o no. Si acaba de usar la configuración predeterminada para crear su sesión de HyperTerminal, es probable que tenga la configuración que se muestra a continuación. Verifique la documentación de su controlador HW y asegúrese de que su procesador esté haciendo lo mismo.

  • ConexióncorrectadelasseñalesUART.Esposiblequehayaestadoutilizandouncablecruzado(muycomún),quehizocoincidirlosparesRX/TXporusted.Compruebesisusseñalesestánconectadascomosemuestraacontinuación:

ARMUARTTX->MóduloGSMUARTRXD0

ARMUARTRX->MóduloGSMUARTTXD0

EDITAR

Siestáobteniendounresultadosimilaralapreguntamencionada,lomásprobableesquelavelocidadenbaudiosseasuproblema.Cadavezqueveounproblemaenelquetengocaracteresrepetidosquenotienensentido,siempreesunproblemadevelocidadenbaudios.ObtieneunUARTqueestátratandodemuestrearbitsquevienendemasiadorápido/lento,loquegeneralmenteseevidenciacomounreciborepetitivodevariosdelmismocarácter.Aveces,larupturaentreloscaracteresseveunpocoasuvelocidaddetransmisiónyluegoelUARTcomienzaasincronizarseenelrestodelosbits,muestreandotodoslosmáximosymínimosyaparecencaracteresdivertidosrepetidos.

MiraríatubúferdeRXymeaseguraríadequerealmenteentresenlapalabra"Listo". No solo haga una comparación usando strstr porque eso le da el desplazamiento de la posición en la que se encuentra la palabra de comparación, que en su caso, debería ser 0. Si puede, establezca un punto de interrupción y vea cada uno de los caracteres para asegurarte de que realmente tienes la palabra "Listo".

Zerioze cada uno de sus búferes ( buffer[20] y buffer2[20] ) con un valor conocido (por ejemplo, 0x00 ) antes de comenzar cualquier lectura / escritura usando un bucle for y escribiendo ese valor en cada uno de los elementos de la matriz. Eso te ayudará a ver si los caracteres de tu matriz realmente están cambiando y no solo estás imprimiendo lo que queda en la memoria cuando se inicia tu programa.

Intentaría cambiar la velocidad en baudios del UART RX / TX por separado. Parece que tienes esa habilidad de tu código

cfsetispeed(&options, B115200); //Set Baud-rate to 115200
cfsetospeed(&options, B115200);

Si está realmente convencido de que está recibiendo el "Listo" pero está transmitiendo errores, solo cambie la velocidad del TX UART. Varíe eso hasta que sus resultados cambien. No puedo imaginar que esta parte usaría diferentes velocidades para TX / RX, pero he visto más loco. En general, verifique el contenido del búfer real usando puntos de interrupción, no solo confíe en las funciones de comparación de cadenas y podría aprender algo de eso.

    
respondido por el Joel B

Lea otras preguntas en las etiquetas