I am trying to send data through GPRS via SIM300 modem. The logic of my program should be. 1) it should send the data till it receives "dieman" from the server. 2) the modem is such that after every command there is a reply. 3) all the communication takes place serially.
Firstly the GPRS commands as tried in hyperterminal
AT OK AT+CGATT=1 OK AT+CGDCONT=1,"IP","airtelgprs.com" OK AT+CSTT="airtelgprs.com","","" OK AT+CIICR OK AT+CIFSR 212.22.22.22 //EG OF AN IP ADDRESS AT+CIPSTART="TCP",""80"">http://www.google.com","80" OK CONNECT OK AT+CIPSEND >THIS IS THE DATA I WANNA SEND // YOU CAN SEND THE DATA VIA GPRS NOW [CTRL+Z] SEND OK
this is what i want to implement in C in 8052. here OK are the response from the modem.
now i implemented the C version but my code is very inefficient. I could have ignored the response from the modem by simply inserting delays but i want my code such that if the reply from the modem is not "OK" it should transmit the command again.
the C code is as follows
#include<reg52.h> #include<string.h> unsigned char msg1[100],x=0; unsigned char *s1="AT"; unsigned char *s2="AT+CGATT=1"; unsigned char *s3="AT+CGDCONT=1,\”airtelgprs.com\”"; unsigned char *s4="AT+CSTT=\”airtelgprs.com\”,\""\",\"""\"; unsigned char *s5="AT+CIICR"; unsigned char *s6="AT+CIFSR"; unsigned char *s7="AT+CIPSTART=\”TCP\”,\”www.google.com\”,\”80\””; unsigned char *s8="AT+CIPSEND"; unsigned char *s9="AT+CLOSE"; unsigned char *s10="AT+SHUT"; void send(unsigned char *x) { while(*x!='0') tx(*x); } void tx(unsigned char x) { SBUF=x; while(TI==0); TI=0; } void delay(void) { unsigned int i; for(i=0,i<=65535;i++); } void serialinit() { IE=0X90; TMOD=0X20; TH1=0XFD; SCON=0X50H; TRI=1; } void serialrx(void) interrupt 4 { msg1[x]=SBUF; RI=0; x++; } void main() { char ch; serialinit(); do { send(s1); //send AT delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s2); //send AT+CGATT=1 delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s3); //send AT+CGDCONT=1,"IP","airtelgprs.com" delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s4); //send AT+CSTT="airtelgprs.com","","" delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s5); //send AT+CIICR delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s6); //send AT+CIFSR delay(); if(msg[3]>=48 || msg<=57) // its an ip address so it has to be a no. so ascii value compared ch=1; else ch=0; } while(ch==0); send(s7); // SEND AT+CIPSTART="TCP",""80"">http://www.google.com","80" delay(); // now here there are 2 responses OK CONNECT OK i dont how to compare // and hence i am just waiting for sometime send(s8); while(msg(0)!='>'); while(strncmp(msg,"\r\ndieman")!=0) send("this is what i want to send"); do { send(s9); //send AT+CIPCLOSE delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0); do { send(s10); //send AT+CIPSHUT delay(); if(!strncmp(msg,"\r\nOK",4)) //compare if OK is received ch=1; else ch=0; } while(ch==0);
pls help me find the correct code
No, that would be a very bad idea indeed!
See my comment on "Arbitrary delays" in this thread: http://www.keil.com/forum/18684/
"i want my code such that if the reply from the modem is not "OK" it should transmit the command again"
That isn't a very good idea, either!
You should really make some attempt to determine the reason for the failure and, from that, determine what recovery action is appropriate.
As also mentioned in the above-mentioned thread, look-up AT+CMEE in your AT Commands manual...
Time for you to improve your coding style a bit.
Why do you have variables named s1 to s10? Do you really think that is good names?
Don't use busyloops as delays. They can change their speed very, very much depending on compiler version, optimization levels, linker optimizations etc.
Don't you see a problem when you have code like:
send(s5); //send AT+CIICR
Doesn't it feel silly that first you have code using the non-meaningful name "s5" and then you need to add a comment AT+CIICR just to remember what you are sending?
Why do you have so many code sequences containing a call to send() a call to delay() and then checking the result? Why haven't you combined this into a single function call?
delay(); // now here there are 2 responses OK CONNECT OK i dont how to compare // and hence i am just waiting for sometime
Do you really think the above is acceptable? It's just time you do learn how to receive and process data. Just relying in a delay does not work. I repeat - it does not work! You have already been told that in a different thread, so why do you still do it?
Have you thought about the difference in answers if you let the modem send an echo back or not? What have you done about it?
Similarly for your functions 'send' and 'tx' - do those names clearly describe precisely what those functions do and, in particular, the difference between the two functions?
OK, if i use the above code with improved quality of names assigned to variables is the code fine. And for generating a delay if i use TIMER in 8051. then is the problem solved.
is my logic for checking whether OK is received is correct?
No.
Walk through it by hand - with pencil and paper.
Or use the simulator.
The first usage might work - but what about the 2nd and subsequent...?
As Per said, what about echo from the modem?
Again, you are using arbitrary delays to guess when the response is complete...
See: http://www.keil.com/forum/18568/
See: http://www.keil.com/forum/16641/
On WikiBooks:
Serial Programming/Modems and AT Commands en.wikibooks.org/.../Modems_and_AT_Commands
In particular:
"People unfamiliar with the theory and practice of state machines often try to circumvent the issue by "tough coding". Which means, they throw more and more code onto the problem (wrapped in a heap of if/the/else/otherwise/maybe/... statements), until things seem to work - sort of. If they are lucky they have implicitly managed to create a state machine which works. If they are unlucky, they end up with a partial state machine, which breaks down should something unusual happen in the communication. This usually comes with the problem that the software was not designed to recover if things break down. So such software tends to hang or crash."
You code falls into that category.
And I heartily support their recommended solution:
"It is much more efficient to first spend a few hours to to learn the basics of simple state machines, and then spending a few more hours to describe the communication with the modem as a state machine. The result of this planning serves as a nice template for implementing the DTE software." (my emphasis)
On one thing I disagree, though: "a few hours" is very optimistic: as a novice, you should look to dedicate significantly longer to master State Machines - also known as Finite State Machines, or FSM for short.
Direct link to the bit about State Machines:
en.wikibooks.org/.../Modems_and_AT_Commands
is their any possibilities of sending mails through GSM? please tell me how it is? first of all we need to login to the gmail or XXXmail.... how it is?
GSM itself can't send mails.
Some GSM modules contains a TCP/IP stack and special AT commands to send mails, or access web services. It would then be up to you to figure out how.
Or your device may contain a TCP/IP stack and connect using GPRS. Still up to you to figure out how.
i am using SIM300 modules supports TCP/IP stack and connect using GPRS
Why are you hijacking this thread with your unrelated question?
"i am using SIM300 modules"
Then you obviously have to read the SIM300 Manuals to find out how to use the specific features of those modules!
The SIM300 is a SIMCOM product - this has absolutely nothing whatsoever to do with Keil or the 8051.
For questions & support on SIMCOM products, you obviously need to contact SIMCOM (and/or your local distributor)
Thank you,
I will go through the links and would let u know if other doubts happen to occur.
Thnx once again