Quality RTOS & Embedded Software

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




Loading

Changing configCPU_CLOCK_HZ changes delay lengths

Posted by richdinoso on April 7, 2017

I am working with the EFM32 GG starter kit. I'm testing the blink LED demo that comes with Simplicity Studio. In FreeRTOSConfig.h there is this line: ~~~

define configCPUCLOCKHZ (( unsigned long ) 14000000)

~~~

When I change the value to 24000000 the length of vTaskDelay increases as well. Is there another #define that needs to be changed in conjunction?

configTICKRATEHZ is 1000, and the number of ticks being passed to vTaskDelay is correctly calculated.

The task definition and creation: ~~~ static void LedBlink(void pParameters) { TaskParamst * pData = (TaskParamst) pParameters; const portTickType delay = pData->delay;

for (;;) { BSP_LedToggle(pData->ledNo); vTaskDelay(delay); } } ~~~

~~~ /* Parameters value for taks*/ static TaskParamst parametersToTask1 = { pdMSTOTICKS(1000), 0 }; static TaskParamst parametersToTask2 = { pdMSTOTICKS(1000), 1 };

/Create two task for blinking leds/ xTaskCreate( LedBlink, (const char *) "LedBlink1", STACKSIZEFORTASK, &parametersToTask1, TASKPRIORITY, NULL); xTaskCreate( LedBlink, (const char *) "LedBlink2", STACKSIZEFORTASK, &parametersToTask2, TASKPRIORITY, NULL); ~~~


Changing configCPU_CLOCK_HZ changes delay lengths

Posted by rtel on April 7, 2017

Is this using Systick to generate the tick interrupt? Or is it using a low power clock along with some low power modes?


Changing configCPU_CLOCK_HZ changes delay lengths

Posted by richdinoso on April 7, 2017

This is the function that sets up the tick interrupt. ~~~ attribute(( weak )) void vPortSetupTimerInterrupt( void ) { /* Calculate the constants required to configure the tick interrupt. / #if configUSETICKLESSIDLE == 1 { ulTimerCountsForOneTick = ( configSYSTICKCLOCKHZ / configTICKRATEHZ ); xMaximumPossibleSuppressedTicks = portMAX24BITNUMBER / ulTimerCountsForOneTick; ulStoppedTimerCompensation = portMISSEDCOUNTSFACTOR / ( configCPUCLOCKHZ / configSYSTICKCLOCK_HZ ); } #endif / configUSETICKLESSIDLE */

/* Configure SysTick to interrupt at the requested rate. */
portNVIC_SYSTICK_LOAD_REG = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
portNVIC_SYSTICK_CTRL_REG = ( portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT );

} ~~~ configSYSTICKCLOCKHZ = 14000000, configTICKRATEHZ = 1000 ulTimerCountsForOneTick = 14000


Changing configCPU_CLOCK_HZ changes delay lengths

Posted by rtel on April 7, 2017

As you say:

ulTimerCountsForOneTick = 14000

is it right that configUSETICKLESSIDLE is set to 1? If so, could you try setting it to 0 and see if you observe the same behaviour, or if that fixes the issue. That will narrow down where we need to look.


Changing configCPU_CLOCK_HZ changes delay lengths

Posted by richdinoso on April 7, 2017

The debugger runs into that code, so configUSETICKLESSIDLE is sure set to 1. I already tried setting it to 0, but I did it again just now to double check. The behavior is the same.


Changing configCPU_CLOCK_HZ changes delay lengths

Posted by richdinoso on April 10, 2017

Someone pointed out that changing this value does not actually change my clock. Sorry for the misunderstanding. Thread closed.


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




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS