SW timer fires too early

[syakovlev]

Hi,

This problem has been discussed in January 2008:
http://www.utasker.com/forum/index.php?topic=158.0
The fix was suggested then and I have it incorporated into my code.
Can anybody confirm that suggested fix definitely cures problem.
Recently I’ve realized that in my project early firing happen very often
(but not in 100% cases) after timer was stopped before.

Thx,
Sergei.

[mark]

Hi Sergei

There are no known open problems with the global SW timers since the last patch on 03.01.2008.

However don't forget that the accuracy of these SW timers is one system TICK. That is ((delay - TICK) ... delay). If you are programming a delay of less than, or equal to one system TICK this gives a firing time of 0..TICK, which may 'look' like early firing since it can effectively immediately fire.
When programming 2 TICKs the range is TICK..2 TICKs, so it can also fire after only one TICK and again 'look' like early firing.

Note that the timers will however be accurate if they are set up "synchronised" to a TICK interval. A timer event starting another timer event is an example since it operates synchronised to the TICK. An external HW interrupt starting a timer can occur at any point in time and so is not synchronised, with increased tolerance.

When using non-synchronised timers this tolerance needs to be considered. The tolerance can be improved by reducing the system TICK rate (faster TICK interrupt). In cases where higher accuracy is required dedicated HW timers are the best choice.

Presently the global HW timers are not advisable since there are some known cases of them not operating correctly with multiple sources at the same time. This is an open point but hasn't been given high priority since usually dedicated HW timers can be used to achieve optimum results.

Regards

Mark

[syakovlev]

Hi Mark,

In my project system tick is 10ms and timer (100 or 200ms) is created is like this:

//uTaskerGlobalMonoTimer( (UTASK_TASK)(TASK_APPLICATION), (DELAY_LIMIT)(0.1*SEC), E_QUERY_TOUT);
uTaskerGlobalMonoTimer( (UTASK_TASK)TASK_APPLICATION, (CLOCK_LIMIT)(0.2*SEC), E_QUERY_TOUT );

When timer fired earlier firmware generats short beep. So one can hear beeps regularly but a periodically.
The strange thing is that when time-out is set for longer time (0.2*SEC), one can hear beeps more frequently.

Best regards,
Sergei.

[mark]

Hi Sergei

How many timers do you have in the system?
How does the firmware (generating the beep) detect that the timer has fired early?

Can you change this single timer to a monostable timer on a single task and see whether there is a change in behavior?

Regards

Mark

[syakovlev]

Hi Mark,

1.Total number of timers is 16.
TIMER_QUANTITY defined as 30.
2. Normally when application sends a query command it starts SW time-out timer E_QUERY_TOUT. Application stops the timer
as soon as reply has been received.
When sw timer E_QUERY_TOUT fired, it sends TIMER event to TASK_APPLICATION. When this event is being received it beeps.
This is how I know that timer was not stopped but really fired. That means application didn't receive a reply for query command
whithin time-out period.
3. I've  replaced SW E_QUERY_TOUT timer with a monostable E_QUERY_TOUT timer
 (special task has been created to own that timer).
Now I'am doing stress test and it seems like problem gone. Monostable timer never fired so far.

Best regards,
Sergei.

[mark]

Hi Sergei

It does sound as though the monostable timers are behaving better than the global SW timers in this case. I will have a try at building a test to verify reliability.

Could you tell me how many queries are actually being monitored at the same time? That is, how many of the timers are actually running in parallel?

Regards

Mark

[syakovlev]

Hi Mark,

To guarantee that query replies go out of instrument in the same order as input query commands,
the command execution queue is blocked when query command is taken out of the queue and executed. (time needed to generate query reply is different for different queries). Command execution queue stays blocked until query reply is ready and sent out or time-out timer fired.
Therefore only one query time-out timer is active. And normally it is stopped as soon as query reply sent out.

Best regards,
Sergei.

[mark]

Hi Sergei

In this case it seems as though a single mono-stable timer on a task is adequate for this application seeing as the task never has more than one of its own timers active at a time (?).

I have however put a reliability test with multiple such timers on my "to-do" list.

Regards

Mark

[syakovlev]

Hi Mark,

That's right. Dedicated monostable timer seems quite adequate for this specific purpose.
Thanks a lot.

Mark, it's off topic, but do you know any convenient terminal program (a la HyperTerminal) which allows to set
arbitrary baud rate? (~150kbs)

Best regards,
Sergei.

PS: one hour later I've found free terminal program which does the job.
Using usb<=>serial adapter program allows me to set baud rate 156250.
Its name is RealTerm and it could be found at
realterm.sourceforge.net

PPS: couple days later I've found terminal program HyperACCESS which could be configured
for arbitrary baud rate using simple script file. It's more robust then free RealTerm, but
it costs $140/150 USD. (15 days trial is available)