Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Tick adjustment due to critical section

Posted 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 section

Posted 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 section

Posted 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 section

Posted 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists