Wait for AT response

Legacy Open AT
1

Hi All…
I want my program to wait for the IMEI at response, but this quite difficult.

Sleep is not working…

How do i force the program to wait for the IMEI code?

static bool imei_callback(adl_atResponse_t *Rsp)
{
    wip_debug ("Retreiving IMEI..\n");
    strncpy(imei,Rsp->StrData+10,15);
    wip_debug(imei);
}

static void start_services( u8 Id )
{

	adl_ctxSleep(200);
	wip_channel_t socket;

	wip_debug( "[SAMPLE]: connecting to client %s:%i...\n", PEER_STRADDR, PEER_PORT);
	  socket = wip_TCPClientCreate( PEER_STRADDR, PEER_PORT, evh, NULL);
	  if( ! socket) { wip_debug( "[SAMPLE] Can't connect\n"); return; }
}

void appli_entry_point()
{
  wip_debug("IST Modem starting up...\n");
  adl_atCmdCreate("at+wimei?",TRUE,(adl_atRspHandler_t)imei_callback,"+WIMEI",NULL);
  start_services(2);

}

Thanks

2

Open-AT is naturally event-driven, so you don’t have to do anything to make it wait:

after you issue the AT Command, the response handler will be called when the response becomes available.

3

Hi there.

Basically my program works as follows, or so i have designed it…

  1. Get IMEI code, store inside char[].
  2. Open TCP client and send IMEI code.

Now, my problem is step 2 happens before step 1 sometimes…

Should i open the TCP client connection from my response handler?

Regards,
Johan Simpson

4

You don’t necessarily need to do it directly from the response handler itslef;
But the response handler is the one and only thing that confirms that you have received the response - so it clearly has to be used to control the process…

BTW: you are only checking for the “+WIMEI” success result - what happens if the command should fail for some reason…?

5

If it fails, then i have problems… But i guess a reset would be the most economical way to solve that problem since developing for the wavecom modem is not proving to be straight forward and predictable…

What way would you suggest solving this problem and doing things in the correct sequence?

6

The classic way to sequence things in any Event-Driven environment is to use a State Machine or, more specifically, a Finite State Machine - or “FSM”.

See: https://forum.sierrawireless.com/t/good-paper-on-event-driven-programming/3848/1

7

We have a very similar problem and have tried several methods (including those in this thread and others) in search of a solution. No matter our approach, we always seem to get the response from the event handler after the main code has executed. Does anyone have a working solution or a new approach to solving this problem?

8

But what problem, exactly, do you have :question:

What methods, exactly, have you tried :question:

What response :question:

What event handler :question:

What “main code” :question:

Have you understood the nature of Event-Driven programming?
See: Good paper on Event-Driven Programming (as mentioned earlier).

Again, you haven’t actually stated what problem you’re having - so it’s impossible to give a solution :exclamation:

9

Trigger start of your service from the response handler (you can call it directly, you can send message, set event, etc…)
If your application must wait for the response, why do you bother with guessing? Response handler will be called when data is ready.

Rudolf

10

I am impressed by the willingness of some people to help!

I have an application similar to yours … maybe the correct solution, or one of them, is to use semaphoring. Ask for IMEI set the semaphore red. TCP routine will check the semaphore and if it is red will wait and check again.
If you get a proper IMEI in routine 1 you turn green the semaphore. If you get an error you turn it yellow (so that TCP is not stuck but also now that data is uncorrect). And to be sure to be sure you can set up a timer that if after a while the semaphore is still red you will force it yellow.

But … if it suits you (it does for me) you can simply save the IMEI in flash (it doesn’t change, does it) and only the first time and only if step 2 occours before step 1 … you will have a blank one … and still you could issue a timer to autorelaunch step 2.

I hope I was not too concise … otherwise I can post some code :slight_smile:

11

That’s basically a state machine; with the semaphore encoding just 3 states - red, yellow, and green.

It would probably be better to use more meaningful state names; eg IMEI Requested, IMEI Not Available, IMEI Available.