This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem in writing code which performs GPRS support action.

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.

Parents
  • 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.

Reply
  • 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.

Children