cofigUSETICK_RATE_HZ dynamic update

aerovish wrote on Thursday, May 16, 2019:

Is it possible to update the configTICK_RATE_HZ in the following manner :

    int tickHZ = 10;
    #define configTICK_RATE_HZ    (tickHZ)


I want to update this rate when my program is executing , but the approach keeps giving me comiplation errors. I am executing 2 matrix multiplication task of size 500x500 and 100x100. and need to vary the tick rate to 1 and 1000 respectively.

Thereason i want this to do is coz 100x100 is able to execute fine at 1000 HZ but 500x500 does not completes at all unless i use 1 Hz,

I tried using xTaskIncrementTick() but no use .

I am running FreeRTOS 10.2 for win32 port. (…/Demo/WIN32-MSVC)

richarddamon wrote on Thursday, May 16, 2019:

The biggest issue is that just changing your tickHz variable will not cause anything to happen to actually change the tick rate, so making it a variable will just cause the program to ‘lie’ to you.

FreeRTOS includes no code to actually change the tick-rate, (except somewhat in the tickless idle optional code) and this is actually somewhat hard to do and keep thing precise, and has a bit of a definition problem of what to do with all current timing going on, which FreeRTOS knows of in ticks, but likely many were converted from real times.

Lastly, I am not sure why you need to change the need to change the tick rate based on how long an operation will take, as tasks shouldn’t be affected by that unless YOU have coded something to try to enforce a requrement like that, at which point changing that requirement (of fixing the bug that implies that requirement) should be much easier than trying to get reliable tick rate changing code.

aerovish wrote on Thursday, May 16, 2019:

Hi Richard,

Please find the attached files. I am playing around with two task running at same priority and trying to see the behaviour. In the attached logs you’ll find how the process behaves at 1 Hz and 500 Hz. Thus i need to use diffferent tick rate to get the process executed properly. At the core I just want to bring down the rate value only for large matrix size and not always operate at such a low frequency. Please let me know if i can do something different there.

As i uderstand , the tick rate is more to do with frequency of timer ISR getting called. In my case , if i use a large size matrix this causes the process to not finish properly so need to vary the tick frequency rate to allow more time for process and less to timer interrupts. But once again optimize it as well within multiple process.

rtel wrote on Thursday, May 16, 2019:

Note that the kernel expects the rate at which it sees time passing to
be fixed. It measures time in ticks, which is the number of tick
interrupts that have executed. If a task enters the blocked state (for
example it calls vTaskDelay(), or xQueueReceive() or any other API
function with a block time) then the kernel calculates the tick count
value at which time that task should be unblocked. If the rate at which
ticks occur changes while the task is blocked, it won’t unblock at the
right time. The kernel behaves like this for efficiency - it knows when
the task has to unblock so doesn’t do anything until that time occurs.

richard_damon wrote on Thursday, May 16, 2019:

At a quick look at the code, it looks like you have global variables that both tasks are using without handling the fact that they are shared (i, j, k, l, …). THIS IS A PROGRAM BUG. It ‘works’ at slow ticks rates likely because one task completes its use before the other task runs, thus ‘eliminating’ the signs of the bug.

You don’t really want to change the tick rate, you want to make those variables not shared, so it can run at whatever tick rate happens to be used.

aerovish wrote on Friday, May 17, 2019:

Hi Richard, Thanks for that input. It did worked once all the variables were local to the task. Now my question is will it be good if i keep the Tick rate as high as 100000 or 1000 000 ? it executes the program faster now but I want to understand how this impacts the harware or processor ?

richarddamon wrote on Friday, May 17, 2019:

My guideline is that I run the Tick Rate high enough to get sufficent accuarcy for things that are measured in terms of it, but no higher. Too high, and the system loses processor time to fielding the Tick inteerupt too often, too low, and timer precision can suffer. The primary use of the Tick in most of my programs is to provide timeouts for waits, so generally it doesn’t need to be too fast, often on the order of 100 Hz. This provides that a timeotut value of 2 will delay for at least 10ms (if started just before a tick interrupt) and at most 20ms, which is sufficient for most of my work. If you need a finer grain to your timeouts, you need a faster tick.

Also, if youy have tasks that are software initiated that need to happen at a rate faster than that, you may want a faster timer tick, though in many cases these sort of things often end up tied to some other periodic interrupt in the system, so I don’t need to raise the Tick rate.