Hello all,
I am trying to send Command from 89S52 Controller to SIM900 GSM Modem
when i am sending command as
"AT" in response my Receive buffer is able to receive all bytes and code is working fine.
if request is "AT"Response is "AT 0X0D 0X0A 0X0D 0X0A OK " -> working fine
but if i send command as “AT+IPR=9600”
then expected response should be same "AT 0X0D 0X0A 0X0D 0X0A OK " but my buffer is not able to collect it.
it is receiving "AT " and after this it is receiving junk characters (in second attempt i tried to make buffer memory dynamically allocated but that is making program more dirty)
GSM is responding correctly (i verified it using hyperterminal), my code is not able to receive it correctly.
/*drivers.c*/ extern int buf_count; char Rec_buf[10] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; void serial_IT(void) interrupt 4 { if (RI == 1) { /* if reception occur */ RI = 0; /* clear reception flag for next reception */ Rec_buf[buf_count] = SBUF; /* Read receive data */ buf_count++; if(buf_count == 10) { buf_count = 0; } } } void Send_cmd(char *cmd) { while(*cmd != '\0') { Uart_send(*cmd); cmd++; } Uart_send(0x0D); Uart_send(0X0A); } void Uart_send(char data_snd) { TI = 0; SBUF = data_snd; while(TI==0); TI = 0; } /*application.c*/ int Check_rsponse_OK(void) { int ret_val = 0; if(Rec_buf[0] == 'A' && Rec_buf[1] == 'T' && Rec_buf[2] == 0x0D && Rec_buf[3] == 0X0A && Rec_buf[4] == 0x0D && Rec_buf[5] == 0x0A && Rec_buf[6] == 'O' && Rec_buf[7] == 'K') { port_0_0 = 1; port_0_1 = 0; ret_val = 1; } else { port_0_0 = 0; port_0_1 = 1; ret_val = 0; } return ret_val; } /*main.c*/ void main (void) { int ret_val = 0; init_app( ); Send_cmd(Check_cmd); do { ret_val = Check_rsponse_OK(); }while(ret_val != 1); Reset_receiver_Buffer(); while(1); }
Where is the forum edit when needed?
For some reason I had to write strpos() which is a non-standard function in C when intending to write strstr(). The disadvantage of doing too much PHP lately - in PHP strpos() gives the index of the hit while strstr() gives the remaining string.
Dear friend Andy Neil if you involve yourself to send some data over modem that my contain 0(NULL) and that’s not end of data you will face what I say for sure it's just take some time to face this for example for one transparent port project like RS232 or … that may send data that don't fit your expectations the you will face it ;) believe me man it is not that modem response that will get you it is what you send over media that will get you some day and that will be soon! And adding char substitute and ... won't be easy at all and it is unnecessary over head when you send data trough TCP link
" New! RE: don’t use those standard C string function for GSM modems "they just don’t fit the job"
Nonsense!
They are perfectly usable!
"they look for NUL at the end of string"
Yes, of course that is true.
"there is no NUL in GSM modem responses"
So just add one, then!
Whatever you do, you're going to have to provide some way to mark the end of the response - so you might as well choose one which is going to allow you to use standard functions!"
Remember that there is a big difference between being in AT command mode, and having established a session where you send data though the modem to the other side.
AT command responses are only relevant when being in the AT command mode. That's also a reason why there exists multiplexer commands to create multiple serial interfaces to GSM modules - to allow AT commands to query signal strength etc on one virtual serial port, while another serial channel is sending/receiving data.
And by the way my dear friend as you say " it's an issue behind the keyboard" because when you don’t understand what is your tool for it is for standard functions like cout cin puts … not for Buffering using modem involve buffering data and in buffer may (and it will be for sure include 0 null if it is not you own data) and it is not use for C string it is just like that you want to cut metal with plastic knife when you just have a saw! And you have only one media to you modem and that’s probably you USART and that need a buffer not string!
How buffering of incoming data is performed is totally irrelevant to how the code processes AT commands and AT command responses.
In this specific case, the OP is doing AT+IPR to change baudrate - which obviously also requires the OP to care about the result of that baudrate change. Changing from strchr() to memchr() isn't going to make much of a difference if the UART is listening at the wrong speed...
Yes sending command to switch baud rate with out of fixing MCU baud rate to receive response is yet another problem but in first place I told him to don’t use string for modem communications as advice not as solution to his problem!(and it was just a Advice generally for modem communication )
Let's finish this endless fight. Do what you want you will face it soon if you lucky enough. And about switching baud rate I think person who switching baud rate by force know the baud rate changing on response according to modem datasheet and fix it!
You are confusing arbitrary bytes streams which might contain NUL, with processing and parsing line responses from a modem in command mode. Once you have the data at a line level it's not going to have NUL, CR or LF, and standard library functions are perfectly usable without having to roll-your-own. Modem's don't return NUL in command responses unless their firmware has been written by idiots. In situations where raw byte streams might be returned, they would normally be delimited by a size or escape character, and documented to do such.
If the posters don't understand the difference between command and data mode, and can't parse data streams, then they have more problems than can be solved here. The problem is most people posting AT Modem questions here are totally clueless with respect to basic programming tasks. Failure to terminate strings, and understand the consequences of that, and the use of library functions goes to competency.