Multiple calls to adl_atSendResponse


#1

Hi All,

I’m just wondering if anyone else has experience this, and whether it’s a known problem.

I’ve ported some old OAT 2.10 code up to OAT 3.13, and have noticed a difference in behaviour of adl_atSendResponse. The code has a “display all settings” command handler, that calls adl_atSendResponse repeatedly to display all of the stored settings for the application. On the old code, this worked fine. On the new code, after 8 or so lines the output lines start missing/disappearing. Another aspect of this behaviour is that the output seems to be complete on higher baud rates (115200), and has missing output at lower baud rates (9600).

I’ve put together a test application, and built it in 3.13 to reproduce this behaviour.

#include "adl_global.h"

/***************************************************************************/

u32 wm_apmCustomStack [ 512 ];
const u16 wm_apmCustomStackSize = sizeof ( wm_apmCustomStack );

/***************************************************************************/

void TestCommandHandler(adl_atCmdPreParser_t *paras)
{
    u8 i;
    ascii sTemp[255];

    adl_atSendResponse(ADL_AT_PORT_TYPE ( paras->Port, ADL_AT_RSP ), "\r\n");
    for(i=0;i<50;i++)
    {
        wm_sprintf(sTemp, "%d\r\n", i);
        adl_atSendResponse(ADL_AT_PORT_TYPE ( paras->Port, ADL_AT_RSP ), sTemp);
    }

    adl_atSendResponse(ADL_AT_PORT_TYPE ( paras->Port, ADL_AT_RSP ), "OK\r\n");
}

/***************************************************************************/
void adl_main ( adl_InitType_e InitType )
{
    TRACE (( 1, "Embedded Application : Main" ));
    adl_atCmdSubscribe("AT^ITEST", TestCommandHandler, ADL_CMD_TYPE_ACT);
}

I’ve managed to “fix” the ported application, by buffering the output into a character array (255 characters in size), and only writing the output via adl_atSendResponse when the buffer is full, or at the end of the event handler by calling a “flush” method. But I’m not sure why I have to do this, and whether this technique will fail if the amount of output grows, or if the baud rate is slowed down even lower than 9600.

Any thoughts?

Regards,
Geoff.


#2

Hi Geofft !

Firstly, from Wavecom FAQ :

"Is it recommended to send responses (using adl_atSendResponse () API) to the external application in a loop?

It is not recommended to send responses to the external application (using adl_atSendResponse () API) in a loop. This is because, if adl_atSendResponse () API is used inside a “for” loop, the Open-AT task upon its timeslice will send all the responses (issued using adl_atSendResponse) to the V24 layer. However, the V24 layer will process the response only after it receives it timeslice. Before, it receives it timeslice, the responses to be sent will be buffered. Now, if a lot of responses (greater than 75) are sent, the module will try to find a free cluster in the pool to buffer the responses. In case, the data constituting the response is larger than the largest free cluster in the pool, the module gives RTK exception 151 and reboots. To overcome this , the Open-AT application can use a timer and on timer expiry, from the timer handler function, call the adl_atSendResponse () API to send the responses. This will provide enough time to V24 task to flush the responses to the external application "

I think the problem of losing data is about the buffer. Maybe the buffer is overwritten with new data when the module has not enough time to send the previous one. Or some data are lost (flushed) when the buffer is full…

About the Open AT versions, i dont think it’s the problem. This function (adl_atSendResponse) is probably running the same (but i can be wrong…). The difference is maybe more about the module (CPU speed?).

Concerning the baud rate problem, the problem is the same…data are lost because the buffer is full. With baud rate set to 9600, your application try to send much more data that what can be sent. Which is not the case with baud rate set to 115200…
The same happen with the TRACE macro.


#3

Ah, OK. Thanks. I hadn’t discovered the FAQ yet. I had searched the forum, read the ADL programming docs, but hadn’t found the FAQs.

Because of the buffering fix that I implemented, I suspect it’s more the number of packets, more than the size of the data that I’m responding with.

I’ll keep with my “buffered output” approach for now, to keep the number of adl_atSendResponse calls to a minimum. One day I’ll re-work it to incorporate a timer to iterate over the list. But for now, while I’m unlikely to have lists of more than 30 or so items, I’ll run with what I’ve currently got.


#4

For the FAQs, go to wavecom web page, product section. There you’ll see a menu on the left. The FAQs link is on the bottom of the list.