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

Few FreeRTOS related questions (basics)

Posted by re-play on July 30, 2014

Morning all,

first of all, I'm a FreeRTOS newbie so please do take that into account when looking at my questions that might appear too basic to some of you. I got those questions while studying different kinds of FreeRTOS examples code that I've used for learning on my STM32 Cortex ARM board kit. My questions are as follows:

1.) Is it absolutely necessary to declare my tasks (at the top of main.c) and what's the reason for doing it?

2.) What's the difference between using (void * p) and (void * pvParameters) when writing my tasks and how do I know when to use it? I've seen both cases in many examples I've checked.

3.) How do I know when to use "prv" (private) or "v" (void) as a part of my tasks' names? For example, one of my task is flashing LEDs - should my name it "taskLED" or "vtaskLED" or "prvtaskLED"? Is it necessary to use this kind of names at all?

Thank you for any help and guidance.


Few FreeRTOS related questions (basics)

Posted by davedoors on July 30, 2014

1) Tasks can be created at any time before or after the scheduler is running, so not just from main().

2) That is just a function parameter, you can call it whatever you want just like any other function parameter. Other than the name of the parameter the two examples you post are identical. This is just C code.

3) Again this is just C code, and this time that is just the name of the function, you can call it whatever you like just like any other function. By convention FreeRTOS code will prefix file scope functions prv just to denote that the function is private to that file.


Few FreeRTOS related questions (basics)

Posted by re-play on July 30, 2014

I see. So, just to make it sure: is it necessary to always declare my tasks and local functions (prototypes) or not? I've seen this practice in most of FreeRTOS examples code I checked (usually it's right after #include and #define part) and I'm not sure about the reason for doing this. Again, I'm talking about prototypes.

Thanks for your answers, it really helps.


Few FreeRTOS related questions (basics)

Posted by rtel on July 30, 2014

FreeRTOS is just C code, so normal C rules apply (it is after all being compiled with a compiler that just sees text input and knowns nothing about FreeRTOS).

If you declare a function, be it implementing a task or not, then the file in which the function is declared should have a prototype for that function, or must have a function prototype if the function is used before it is declared. Any other file that uses the function must also be able to see the function prototype (normally in a header file) otherwise you will get a compiler error about an undeclared identifier.

Where you put that prototype is entirely up to you within the rules mandated by the C compiler.

Regards.


Few FreeRTOS related questions (basics)

Posted by re-play on July 30, 2014

Oh, I see! Makes more sense now. Thanks for your help.


[ 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