Hiya,
I’m using the adl_tmrSubscribeExt() call to pass a Context pointer into a Timer Handler Function.
If the handler is called, I get the opportunity to adl_memRelease() the memory.
If I unsubscribe from the timer before the timer fires (so the Handler is NOT called), where is the memory pointed to by the Context pointer released?
ciao, Dave
You have to keep the address of the dynamic area in a global variable which was provided to the function, if you want to release it.
Cheers,
tom
Hiya,
Then what’s the point of providing the Context method of passing data around - ignore it and just use global variables…
I’ve raised this issue with my distributor for escalation to Wavecom…
ciao, Dave
Hello David,
If I have to fire only one timer, I agree with you, it’s much easier to use global variables.
But let’s see another scenario: let’s suppose a timer is fired by a command that wants to do something with its argument, i.e. a minute later. I think to somenting like AT+DELAYPRINT=5,“hello world” that writes a “hello world” five seconds later…
You could have, at any time, more than one timer waiting for its execution, each one with its different argument.
In that case I think that using the context can be easier than using global variables.
Hiya,
Exactly.
My case is that I’m using a timer to create a data input timeout.
I create the timer, and put the current state into the context variable. If more data is recieved BEFORE the timer fires, the timeout timer has to be cancelled and then restarted - but the reference to the context variable is not available so the restart routine cannot release the memory, thus creating a memory leak. This makes using the context variable useless for me as the timer will not always timeout so the handler will not be called - and also means that I cannot reuse the same timer handler for multiple timeouts as I have to use a different global variable for each current state I wish to deal with.
And you can’t use Automatic variables (i.e. local variables declared in a function) as the memory is undefined once the function goes out of scope.
It’s ugly and annoying.
I’ve also recieved advice from Wavecom to use global variables as the context when calling timers.
Blast.
ciao, Dave
I think it is a fundamental weakness of the Open-AT timer API that there is nothing to re-start a timer! 
As you describe, this is such a common requirement - especially in comms applications - that it is truly amazing that Wavecom have not thought of it!
Hiya,
Oh yes - especally in an operating system/environment that is fundamentally event driven and busy-wait loops are not only frowned upon, but impossible to do without tripping the watchdog timer. (As they should do!).
Still, being able to restart a timer still wouldn’t solve my immediate problem, as I may never hit the timer handler if the comms is closed before a timeout occurs and the timer is manually unsubscribed.
Handling the context memory in the same fashion as memory in wm_lst() is (i.e. default to using adl_memRelease(), or user override with user defined function at list creation time) would be ideal.
Bump: Wavecom - please add this to the list of ‘TODO’ for upcoming versions of openAT.
ciao, Dave
If you know how to use C++ TR1 shared_ptr, then all problems you memtioned will be gone. Or you can use any smart pointer available in WEB. The latest M2M studio supports C++ and STL although it may have some problems when using C++ in ADl applications.