Quality RTOS & Embedded Software

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




Loading

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.

Regards.

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) 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