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

What was the intention with xTimerPendFunctionCall calls before the scheduler started in comparison with xTimerCreate?

Posted by nurichard on July 3, 2014

Hello,

In FreeRTOS v8.0.1 standard CM0 port, xTimerCreate(..) allows the software timer API calls to be made before the scheduler starts because xTimerCreate(..) calls prvCheckForValidListAndQueue() that actually creates the timer.c static xTimerQueue. Things like xTimerStart(...) can then be used as per the API documentation. Once the scheduler starts then the timer queue command is processed and the the commands are executed.

In comparison xTimerPendFunctionCall(...) can only be called once the xTimerQueue has been created. I can force xTimerQueue to have been created by creating and then deleting a timer before using xTimerPendFunctionCall(...) prior to starting the scheduler. As far as my limited abilities go this appears to be safe for v8.0.1 and would have worked for v7.5.2 that I was previously using (if it had such an API).

My workaround is a bit of a bodge; am I fundamentally misusing the xTimerPendFunctionCall(...) functionality by wanting to call it prior to starting the scheduler??? (Naturally I could create a task to call my function if this approach is fundamentally unsafe.)

Given the advertised ability to configure timers before the scheduler starts, it appears to me that xTimerPendFunctionCall(...) falls into a similar class of functionality. What was the original intention for the FreeRTOS API usage prior to the scheduler starting???

I found that many API calls could me made in v7.5.2 which worked as expected despite there not being an explicit comment in the documentation that it was safe to do this and I am concerned about using such API calls in a blase manner that could blow up in the future. Is there a list on the website API pages (that I have failed to find) which records which are expected to always be safe???

Thank you for your help, Richard


What was the intention with xTimerPendFunctionCall calls before the scheduler started in comparison with xTimerCreate?

Posted by rtel on July 3, 2014

While it was not envisioned that xTimerPendFunctionCall() needed to be called before the scheduler was started I don't see any reason why the code could not be updated to make it safe to do so. I would need to look at it in more detail to ensure it didn't add any unnecessary bloat though. I would suggest adding a feature request through sourceforge for this. There will be a new release relatively soon (I'm waiting on other people before I can make it so don't know when exactly) but it might be that it can get done for that.

With regards to calling functions before the scheduler has started. The most important thing is not to call anything that is going to block or cause a context switch. A context switch might be attempted unexpectedly if, for example, a tasks priority was changed and that task happened to be the task that would run first when the scheduler was started. As a blanked rule of thumb, API functions other than those that create objects or explicitly say can be used before the scheduler is started should be used. In reality there are more functions that can be, but there are too many permutations and scenarios to be able to document it in a comprehensible way.

Its a bit like the rule that says "don't call any API functions when the scheduler is suspended". It is simple to have this as a global rule, whereas in reality for an expert user at least, you would find that there were several API functions that were safe to call when the scheduler is suspended - but it is much simpler from a usability point of view to have the global rule.

Regards.


What was the intention with xTimerPendFunctionCall calls before the scheduler started in comparison with xTimerCreate?

Posted by nurichard on July 4, 2014

Thanks for the Reply.

Feature request submitted: https://sourceforge.net/p/freertos/feature-requests/83/


[ 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