FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2017 Threads] Tick adjustment due to critical sectionPosted by lantczak on February 9, 2017 Hi,
In my system the flash erase/write action cause issue with system Tick precision. During flash writing the code is running from RAM and all interrupts are disabled.
Each write operation takes ~10ms and the Tick value is not incrementing. I plan to calculate system block time based on processor cycle counter and adjust Tick value.
I want to create own function similar to vTaskStepTick() byt without
configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );
In my case it can happen that Tick value is already bigger than xNextTaskUnblockTime.
I’m aware that my system is not true real time system.
Question:
1) Will system work properly (tasks to unblock will run / timers will expired) with next calling of xTaskIncrementTick() if Tick value is bigger than xNextTaskUnblockTime.
2) In my understanding the only issue with this design is that task switching from block to run time will be postponed. I’m I right?
I've seen similar topic:
https://sourceforge.net/p/freertos/discussion/382005/thread/edc6e9f0/
But I don't see direct answer to my questions
Best regards
Lukasz
Tick adjustment due to critical sectionPosted by rtel on February 9, 2017 vTaskStepTick() assumes that the tick count has not gone past the time
at which a task will leave the Blocked state because of a timeout. In
your case that probably won't be true. For example, if a task will
timeout in 3 ticks because the block time in a call to vTaskDelay()
expires (or any other blocking function), but you miss 10 ticks because
of the flash write operation, then you cannot just step the tick on by
10 ticks because the task will never get unblocked.
The simplest thing to do would be to call xTaskIncrementTick() for each
missed tick interrupt. The code would look something like the
following, where uxMissedTicks is the number of ticks that should have
occurred while the flash write was in progress.
if( uxMissedTicks > 0U )
{
do
{
if( xTaskIncrementTick() != pdFALSE )
{
xYieldPending = pdTRUE;
}
--uxMissedTicks;
} while( uxMissedTicks > 0U );
}
Tick adjustment due to critical sectionPosted by lantczak on February 10, 2017 Which approach is better from system point of view :
1) The xTaskIncrementTick() loop should be called inside critical section or it is not necessary?
2) If xYieldPending is TRUE then calling of taskYIELD() should be done immediately or it is allowed to do it at the end when all uxMissedTicks are already checked
Are you sure that task is leaving the block state only when current Tick value is equal task unblock tick. I thought that it is happening when current tick is equal or greater.
Tick adjustment due to critical sectionPosted by rtel on February 10, 2017 Yes it should be in a critical section - thanks for pointing that out.
It is only necessary to yield once, after exiting the loop.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|