how much efficient software timer is

Kernel
1

ephobb wrote on Saturday, January 30, 2016:

Hi,
I need three software timer for my application.
I was thinking to use software timer. but i have doubt regarding this.
How much efficient software timers are as compare to hardware?
if i use it for 100 ms then, how much error can be?

2

davedoors wrote on Saturday, January 30, 2016:

All software timers use the same task, so RAM is used for the task stack, but after that there is little extra RAM used for 3 tasks than 1. If the period is 100ms then use a software timer and the resolution will be one tick period if the timer task has the highest priority http://www.freertos.org/Configuring-a-real-time-RTOS-application-to-use-software-timers.html. If the period was a lot less, 500us say then use an interrupt.

3

ephobb wrote on Sunday, January 31, 2016:

Ok thanks.
means software timer and hardware both are same, correct?
But for small period i have to use hardware and rest i can use software timer.
is there any limitation for software timer?

4

rtel wrote on Sunday, January 31, 2016:

means software timer and hardware both are same, correct?

I don’t understand that sentence.

Software timers are under the control of the FreeRTOS scheduler. How
they are scheduled depends on the FreeRTOSConfig.h settings (link
already provided). Their time resolution is basically the same as that
for tasks - which is whatever configTICK_RATE_HZ is set to. If the
resolution is adequate for your application, then you can use a software
timer.

The resolution of hardware timers is dependent on the clocks available
on whatever hardware you are running your application on.

5

ephobb wrote on Monday, February 01, 2016:

means software timer and hardware both are same, correct?

Here i meant to say, is software timer are same as hardware timer?
Means as Hardware timer overflows and gave interrrupt.
Again, i want to know specifically about latancy.
what is time latancy after overflow and timeout function being called?
Actually, i have some such task.

6

heinbali01 wrote on Tuesday, February 02, 2016:

Again, i want to know specifically about latency.

Richard already answered this question:

    Their time resolution is basically the same as that
    for tasks - which is whatever configTICK_RATE_HZ is set to

There are many ways to implement “a timer”. Here are some examples:

  1. Using timers.c : this is convenient if you want a function to be called at a certain moment or regularly at fixed intervals. If the tick-rate is 1000 Hz, then the expected latency is at most a ms, unless your CPU is busy running higher-priority tasks.
    Note that the call-back function will be called from the timer task. So it will not have the usual stack and priority of your own task.

The properties of the timer task are configurable:

    configTIMER_TASK_STACK_DEPTH    // The size of the stack
    configTIMER_TASK_PRIORITY        // The priority of the timer task
  1. Construct your own timer using these functions:
TickType_t xTaskGetTickCount( void )
void vTaskSetTimeOutState( pxTimeOut )
BaseType_t xTaskCheckForTimeOut( pxTimeOut, pxTicksToWait )
or read-out some Timer/Counter (a so-called hardware timer).

In C++ I often use two classes: CTimer and CAlarmTimer. The former is used to measure time, the latter is used as an alarm clock.
The advantage of these “timers” is that they can be used directly in my own tasks. The downside is that these objects must be polled.

  1. Create your own TC interrupt. This is probably what you call a hardware-timer.
    This can give the best time resolution.

As an example:

    /* An example of a Timer/Counter interrupt that wakes up a task. */
    void TC3_Handler ()
    {
    BaseType_t xHigherPriorityTaskWoken = 0;

        /* Send a message to the task to unblock it. */
< EDIT >
Use one of these solutions: TaskNotify or 
QueueSend
< EDIT >

    vTaskNotifyGiveFromISR( xEMACTaskHandle, &xHigherPriorityTaskWoken )
    xQueueSendFromISR( xMyQueue, pxItem, &xHigherPriorityTaskWoken );
        portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
    }

    void vMyTask( void *pvParameters )
    {
        for( ;; )
        {
            /* No events to process now, wait for the next. */
< EDIT >
Use one of these solutions: either TaskNotify
or use a queue, not both.
< EDIT >
            ulTaskNotifyTake( pdFALSE, ulMaxBlockTime );
            xResult = xQueueReceive( xMyQueue, pvBuffer, ulMaxBlockTime )
            if( xResult != pdFALSE )
            {
                /* TC3 expired: do something urgent. */
            }
        }
    }

It is not recommended to write a lot of code within an ISR. It is best to wake-up (unblock) a task. The latency (the time between the ISR and the task waking up) is very short, normally much less than a ms. Again: unless your CPU is busy running higher-priority tasks.

These are just some examples, the choice is yours.

Regards.