hardware global timer retrigger problem

[ovrscout]

Hi,
   i have problem with use multiple hardware timer, i get timer event for timer which is  already retrigered.

Version is uTasker 1.4 for M5223X

Here is simplified example:

Code: [Select]

//this task is automaticaly called every 100ms
extern void fnMyLedControlTask(TTASKTABLE *ptrTaskTable)
{static int FirstInit=0;
 if (FirstInit==0)//Only be proceed on first run
{
FirstInit=1;
uTaskerGlobalMonoTimer((UTASK_TASK)(TASK_MY_TIMEOUT_CHECK | HARDWARE_TIMER),(550*MILISEC),E_TIMEOUT_TEST);
}
uTaskerGlobalMonoTimer((UTASK_TASK)(TASK_MY_TIMEOUT_CHECK | HARDWARE_TIMER),(550*MILISEC),TIMEOUT_CHECK_WD_LED_CONTROL);
 return ;
}
What i expect is that E_TIMEOUT_TEST will be called once and TIMEOUT_CHECK_WD_LED_CONTROL will never be called(because is retrigered every 100msec).
What i see is that both events is called:TIMEOUT_CHECK_WD_LED_CONTROL first and then E_TIMEOUT_TEST.

Note:The same code works well with SW timer

After some examination, i think that problem is in fnSetNewHWTimer function "GlobalTImer.c"
When another timer is running(with less or the same DelayTime) the actualy added timer  variable is set to

Code: [Select]

ptrNewTimer->TimerDelay=(requestedDelay-CurrentHwTimerRemainingTime);I think the right formula my be:

Code: [Select]

ptrNewTimer->TimerDelay=ActualHWTime->TimerDelay+(requestedDelay-CurrentHwTimerRemainingTime);because when firing HW timer all timers has been decreased by FiredTimerActualHWTime->TimerDelay so for new(or retrigered value) there is need to add this value.

the dirty patch{i actualy used) is add Actualy running HW timer->TimerDelay to New->TimerDelay
like this:

Code: [Select]

+static TIMER_BLOCK *fnGetHWFired(void);
+
 // Start hardware timer or queue the new timer
 //
 static void fnSetNewHWTimer(TIMER_BLOCK *ptrNewTimer)                    // {5} stop and adjust if retriggering HW monostable timer which is next to fire on its own
{
    CLOCK_LIMIT adjusted;
    uDisable_Interrupt();
    if (fnCheckHWFirst(ptrNewTimer) != 0) {                              // if we are adjusting the active HW timer that would fire as next, and alone
      ........
    }
     else {
-        uEnable_Interrupt();
+        TIMER_BLOCK  *ptrFirstFired=0;
+        uEnable_Interrupt();        
+        ptrFirstFired=fnGetHWFired();
+        ptrNewTimer->TimerDelay+=ptrFirstFired->TimerDelay;
     }
    adjusted = fnSetHardwareTimer(&ptrNewTimer->TimerDelay);
    ....
}

But i am not sure if this is correct.
Maybe also value which is compared in fnCheckHWFirst should be adjusted in some way.

P.S. I am sorry for my bad english

[mark]

Hi

The global HW timers are no longer supported in the project. It is now receommended to use the HW timer interfaces that are provided for the processor's peripherals. In the M522XX this means that free PITs and free DMA Timers can be used to achieve high accuracy timers (see the examples in ADC_Timers.h for each available module).

Global SW timers are still available - these have proven reliable in various projects for longer periods of time - when the delay accuracy and resolution are not of highest priority (the resolution is restricted to the system TICK value with an accuracy of x...x-1 TICKs (when not synchronised to the TICK)). The HW timers allow direct handling in the interrupt routine, when required, for highest accuracy.

Regards

Mark

[ovrscout]

Hi, Mark

I am sorry about no further support of HW timer, it is easier solution for my project.
I do not need high accuracy of PITs or DMA. I need only few timeout timers about 3-7msec, with miliseconds precision.So instead of use small system tick I use global HW Timer.
Howerver, I thank you for your advice and quick response.I wil try PIT timer in future

P.S. It would be nice if any notice about obsolete status for HW global timer will be added to document "µTasker Global Software and Hardware timers" and/or to Source code/Header file

Best regards

[mark]

Hi

I have updated the document in question and added a note that the global HW timer support is not included in all processor packages and that it is not recommended for geberal use - the document with details of processor specific timers is referenced.

Some extra background information:

- the global HW timer method is a compromise since it is in fact very similar to the Global SW timer method but with higher resolution time raster due to it using a second timer which is not synchronised to the system TICK.

- the operation is however still controlled by a single task which means that the task delay is still involved and so the HW timer interrupt resolution is not achieved.

- the main difficulty with the global HW timer method is that it relies on a HW timer with certain capabilities - like being able to freeze the HW timer while manipulating it (to avoid count values changing during the process) and being able to prime it with values.

- Since the processors have different type of HW timer peripherals not all support doing things as it would be liked and so in some cases workarounds are involved with some risks.

- The result was that not all of the solutions were found to be as reliable as others, each HW type could introduce its own difficulties and potential unreliability/problems.

- The fact that this was in some cases difficult to solve and prove that all situations were correct, the direct interrupt use of available timer resources became preferred. This proved to be a simple and efficient replacement in most cases and this is the reason why the global HW timer support has been reduced in recent times.

- The technique is however interesting and may enjoy a renaissance in the future, but this doesn't have high priority at the moment.

Regards

Mark