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

Problem changing Tick time from 1ms to 10ms

Posted by Ozzy Smith on November 21, 2012
My default project(ARM7_LPC2138) seem to be set up for a 1ms tick timer. I defined my hardware timer to be 1ms and everything works fine.

I wanted to now change my hardware timer to 10ms as this is the value of my original platform and I changed the following:

in FreeRTOSConfig.h :
(Changed from 1000 to 100)
#define configTICK_RATE_HZ( ( portTickType ) 100 )
in portmacro.h:
(Left Alone)
#define portTICK_RATE_MS( ( portTickType ) 1000 / configTICK_RATE_HZ )
In main.c:
(Left Alone)
#define mainLED_DELAY( ( portTickType ) 500 / portTICK_RATE_MS ) //500 for 1ms tick
#define mainERROR_LED_DELAY( ( portTickType ) 50 / portTICK_RATE_MS ) //50 for 1ms tick
#define mainCHECK_DELAY( ( portTickType ) 5000 / portTICK_RATE_MS ) // 5000 for 1ms tick


I changed the timer value on my system so that I would get 10ms interrupts.

What I am seeing is the first few LED_Delay are correct at 500ms each, but then the Check Task Fails and Led Flash every 50ms.

Why would my checkTask fail? (FAIL is printed on the debug Terminal screen)

With the timer set to 1ms tick in hardware, I pass 100% of the time.

Did I forget to change something else to go to a 10ms tick?

Thanks,
Ozmit

RE: Problem changing Tick time from 1ms to 10ms

Posted by Richard on November 21, 2012
It depends which of the standard demo tasks are being executed. Some include code that checks things happen within the time bounds they expect, and having courser time measurements can make these checks fail. In effect these are false positives.

Your changes look ok. Just changing configTICK_RATE_HZ should be enough by itself as the constant is used to configure the timer for the correct tick period.

If the LEDs are flashing at the correct rate when the check task is not running then I don't think you have any issue.

Regards.

RE: Problem changing Tick time from 1ms to 10ms

Posted by Ozzy Smith on November 21, 2012
I agree, It seems to work fine.

How would I fix the checkTask Fail problem? It seems like a nice feature to have.

My project has the following tasks:
/* Create the queue used to pass message to vPrintTask. */
xPrintQueue = xQueueCreate( mainQUEUE_SIZE, sizeof( char * ) );

/* Create the semaphore used to wake vButtonHandlerTask(). */
vSemaphoreCreateBinary( xButtonSemaphore );
xSemaphoreTake( xButtonSemaphore, 0 );

/* Start the standard demo tasks. */
vStartIntegerMathTasks( tskIDLE_PRIORITY );
vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
vStartDynamicPriorityTasks();
vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );

#if configUSE_PREEMPTION == 1
{
/* The timing of console output when not using the preemptive
scheduler causes the block time tests to detect a timing problem. */
vCreateBlockTimeTasks();
}
#endif

vStartRecursiveMutexTasks();

/* Start the tasks defined within this file. */
xTaskCreate( vLEDTask, ( signed char * ) "LED", configMINIMAL_STACK_SIZE, NULL, mainLED_TASK_PRIORITY, NULL );
xTaskCreate( vCheckTask, ( signed char * ) "Check", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );
xTaskCreate( vPrintTask, ( signed char * ) "Print", configMINIMAL_STACK_SIZE, NULL, mainPRINT_TASK_PRIORITY, NULL );
xTaskCreate( vButtonHandlerTask, ( signed char * ) "Button", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

/* Start the scheduler. */
vTaskStartScheduler();


And I am using the follwoing checkTask():

static void vCheckTask( void *pvParameters )
{
portBASE_TYPE xErrorOccurred = pdFALSE;
portTickType xLastExecutionTime;
const char * const pcPassMessage = "PASS\n";
const char * const pcFailMessage = "FAIL\n";

/* Just to remove compiler warnings. */
( void ) pvParameters;

/* Initialise xLastExecutionTime so the first call to vTaskDelayUntil()
works correctly. */
xLastExecutionTime = xTaskGetTickCount();

for( ;; )
{
/* Perform this check every mainCHECK_DELAY milliseconds. */
vTaskDelayUntil( &xLastExecutionTime, mainCHECK_DELAY );

/* Has an error been found in any task? */

if( xAreIntegerMathsTaskStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xArePollingQueuesStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreSemaphoreTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreDynamicPriorityTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreBlockingQueuesStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

#if configUSE_PREEMPTION == 1
{
/* The timing of console output when not using the preemptive
scheduler causes the block time tests to detect a timing problem. */
if( xAreBlockTimeTestTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}
}
#endif

if( xAreRecursiveMutexTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

/* Send either a pass or fail message. If an error is found it is
never cleared again. */
if( xErrorOccurred == pdTRUE )
{
xLED_Delay = mainERROR_LED_DELAY;
xQueueSend( xPrintQueue, &pcFailMessage, portMAX_DELAY );
}
else
{
xQueueSend( xPrintQueue, &pcPassMessage, portMAX_DELAY );
}
}
}

I should probably set a break point to see which one fails, however I am away from my developement platform at the moment.

Ozmit

RE: Problem changing Tick time from 1ms to 10ms

Posted by Richard on November 21, 2012
The demo tasks are not required, they are literally just that, there for demonstration so don't worry about taking them out.

Having said that, some actually do some useful tests too, and it is those that are likely to be causing you a problem with a different tick value.

The prime suspect will be the tasks created by the vCreateBlockTimeTasks() function call. These test that tasks remain in the Blocked state for the expected number of time. The tests will allow a little margin to account for the fact that interrupts will execute, and other tasks may share their priority. If you have changed the tick frequency it is likely that the measurable time granularity will take the measured block time outside of the allowed margin.

Maybe the vStartDynamicPriorityTasks() tasks could suffer a similar problem, but I can't remember without looking at their implementation again.

Regards.


[ 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