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


different idea for xTaskCreate()

Posted by Jeff Smith on April 14, 2006
I've been thinking about a different way that xTaskCreate() could work easier and be more portable. I wonder if others have given it much thought.

We can see that each task typically has it's own initialization code first, and then begins it's infinite loop for the real task code. So that code before the loop is always executed once, the first time.

What makes sense to me is if a function for the same purpose as xTaskCreate() were defined which is meant to be called from *within* the task function itself. That means it would not have to pass the parameter that tells where that task needs to run when called again later, because it can be taken from context.

It would help in HCS12 and GCC because it would be easier to start tasks which begin in a different memory banks, without the wierd trampoline stuff that GCC does.

Basically in GCC-m68hc1x if a start address of the func is 31:80A0, there is no way to pass the whole address in a pointer (only have 16-bit ptr). Instead, it gives a 16-bit addr to a trampoline func which manually tweaks the stack, sets the mem ory bank, then jumps to the real func. It seems more straight forward if xTaskCreate() could just look at the current stack to see the full addr it was called from. I realize however that would be one more function that would have to be in port.c instead of task.c, so maybe not so convenient for everyone.

RE: different idea for xTaskCreate()

Posted by Richard on April 16, 2006
Anything that would reduce the number of parameters passed to xTaskCreate() would be good as this takes more stack than would otherwise be desirable.

I have in the past attempted something similar where a function was introduced to turn main() into a task. This was done to try and recover the stack used by main() itself. main() would start all the other tasks in the system, then call the new function, before entering a for(ever) infinite loop and be called under the control of the scheduler.

I would still like to do this, but it requires some fairly major work in each port which is not easy and somewhat time consuming. I can't remember exactly what the issues where but I remember there were some difficulties.


RE: different idea for xTaskCreate()

Posted by Jim P on April 16, 2006
The best way to turn a bunch of parameters into just one is to create a structure and pass a pointer to the structure into the routine.

RE: different idea for xTaskCreate()

Posted by Jeff Smith on April 18, 2006
Interresting that recovering the stack from main() with my HCS12 is automatic. Because the stack is at the end of the memory heap, all I have to do is setup the heap to overlap the initial stack at the high end of RAM. I don't allocate that much memory from heap until vTaskStartScheduler(). Since that never returns (which is mostly because it's a small system--less RAM), the main() stack can simply be overwritten when the space is needed.

In otherwords, turning main() into a task won't be of value to me. Making each task require less stack... now that's important.

[ 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