Timer problem

[waleedkadry]

Hi,

In my project, we cerate three tasks as follow:

const adl_InitTasks_t adl_InitTasks [] =
{
	{main_task,3000,"Main",3},
	{Tools_task,3000,"Tools",2},
	{IEC62056_task,3000,"IEC62056",1},

	{ 0, 0, 0, 0 }
};

In IEC62056 task, I subscribed a timer as in the following code but timer doesn’t expire.
After debugging, I found that timer not work because it subscribed from stopped context
because adl_eventWait stops IEC62056 context.
Question is “how can I use timer inside tasks?”

void tmr_handler( u8 ID, void * Context ) {
 	adl_eventSet(IEC62056_event_hdl,1);
 }

void IEC62056_task(void)
{
	u32 IEC62056_events;
	s32 ret;

	//init_IEC62056();

	adl_tmrSubscribe( TRUE, 100, ADL_TMR_TYPE_100MS,tmr_handler);
	IEC62056_event_hdl = adl_eventCreate(0);
	for(;;)
	{
		ret=adl_eventWait(IEC62056_event_hdl,
		                  7,
		                  &IEC62056_events,
		                  ADL_EVENT_WAIT_ANY,
		                  ADL_EVENT_NO_TIMEOUT);

		 if(IEC62056_events&1)
			adl_eventClear(IEC62056_event_hdl,1,NULL);
		 else
			 wip_debug("wrong event");

	}
}

[mosama]

Which Open AT OS version are you using?

[waleedkadry]

@mosama

Which Open AT OS version are you using?

My OS version is R74_00-cus-q26-01

[mosama]

My OS version is R74_00-cus-q26-01

This is the Firmware version 7.4. I mean the OS version, it should be 6.something

If you are not sure get your modem information in the target tab of the M2M studio.

[waleedkadry]

OS version 6.30

[mosama]

First: I think you should upgrade to verion 6.34.
It’s better in handling tasks. Also older versions don’t support tasks initialization table (not sure about 6.30)

Second: using infinite loops inside tasks is highly not recommended. Why do you need a for(; when you have a timer subscribed?!!
move your code to the timer subroutine

This is a quote from the ADL User Guide for Open AT® OS 6.34 P30:

Note: A task entry point function is NOT like a standard “C” main function. The task does not end when returns. An Open AT® application is stopped only if the AT+WOPEN=0 command is used. Such a callback function is only the application entry point, and has to subscribe to some services and events to
go further. In addition the whole software is protected by a watchdog mechanism, the application shall
not use infinite loops and loops having a too long duration, the embedded module will reset due to the
watchdog hardware security (please refer to Hardware Security: Watchdog Protection for more
information).

[josepvr]

Event-Driven Programming paper

[waleedkadry]

@josepvr

Event-Driven Programming paper

In event driven, as I think,when call back rises, you should rise events to responsible task and return and you shouldn’t stay long time inside call backs.
also if I do all my code event driven, then I don’t need the ability to cerate many tasks. I need only one task to do initialization and the wait events.(then why firmware give us the ability to cerate many tasks).
so I don’t accept with you.

@mosama

First: I think you should upgrade to verion 6.34.
It’s better in handling tasks. Also older versions don’t support tasks initialization table (not sure about 6.30)

I didn’t find version6.34. please tell me any link for it.
did you know if this version handle the call backs in new context or not?

@mosama

Second: using infinite loops inside tasks is highly not recommended. Why do you need a for(; when you have a timer subscribed?!!
move your code to the timer subroutine

This is a quote from the ADL User Guide for Open AT® OS 6.34 P30:

Note: A task entry point function is NOT like a standard “C” main function. The task does not end when returns. An Open AT® application is stopped only if the AT+WOPEN=0 command is used. Such a callback function is only the application entry point, and has to subscribe to some services and events to
go further. In addition the whole software is protected by a watchdog mechanism, the application shall
not use infinite loops and loops having a too long duration, the embedded module will reset due to the
watchdog hardware security (please refer to Hardware Security: Watchdog Protection for more
information).

As I told you above, it isn’t correct to handle all your work inside call backs.
this part of ADL user guide, that you attached , talks about the highest priority task only which run in context 0.
where context 0 is responsible to handle subscription call backs.

[mosama]

In event driven, as I think,when call back rises, you should rise events to responsible task and return and you shouldn’t stay long time inside call backs.

No that’s not true. event handlers are not like normal ISRs you use in sequential code or normal RTOSs. To make things easier you can treat event handler as a blocked task waiting for certain event(s). Please read the Event-Driven Programming paper carefully for further understanding of the differences. I know it is not easy to switch to event-driven programming.

I didn’t find version6.34. please tell me any link for it.

Download the last version of Sierra_Wireless_Software_Suite and you’ll find it inside.

this part of ADL user guide, that you attached , talks about the highest priority task only which run in context 0.
where context 0 is responsible to handle subscription call backs.

From where did you get this information?