IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

Prior to making the RTX_TASK_CREATE API call, the caller must set the following members of the TaskDefBlock
structure.
proc
name
Here you must set the far vector to your task's entry point. The task's main procedure should be declared
(depending on compiler used) as:
Borland C: void huge taskfunc(void)
Microsoft C: void far _saveregs _loadds taskfunc(void)
These assure that the data segment register (DS) is loaded on entry into your task.
Make up a four letter name for your task by which it can be uniquely identified. Avoid names already occupied
by the systemtasks.
stackptr
This far pointer should point to the top of you task's stack space (highest address). Your tasks stack pointer will
be initialized to this value, which points to the first byte of memory following your actual stack space. (Note that
x86 CPU decrements the stack pointer prior to pushing data onto the stack.) The stack memory space resides
within your application program.
stacksize
Here you specify the size of your task's stack space in bytes. The amount of stack space required for your task
depends on the nature of your task. If large automatic objects are declared in your task's procedures, a large
amount of stack space will be needed. Caution:
Some of the system's interrupts use your task's stack. Consequently we recommend a minimum stack
space of 1024 bytes per task.
Since the problems resulting from stack overflow are often difficult to diagnose and analyze, the following
design steps are recommended:
1. Initially allocate way more stack space then you believe you will need.
2. When you have your task performing what it was designed to do, measure the amount of stack space
being used by your task. The RTX_GET_TASK_STATE API can be used to obtain this measurement.
3. Refine your stack allocation based on this measurement, arriving at a compromise between the
conflicting requirements: efficiency on the one hand (small stack desired) and program maintainability
and reliability on the other hand (big stack desired).
Software maintainability becomes an issue here if you have the stack space wired so tight that the slightest
code change will lead to stack overflow. Reliability is an issue when paths in your task (or interrupts) are
executed that did not execute during your stack space measurement trials.
priority
Application program tasks can range in priority from 3 to 127 (inclusive), where 3 is higher priority. Generally,
task priorities between 20 and 30 are recommended. This recommendation is based on the priority
assignments of the built-in systemtasks. Too high a priority for an application task may block important system
tasks: e.g. the Ethernet receiver task. However, in some cases higher priority application tasks are appropriate
design, but in these cases you must keep the execution dwell of these high priority task very short. User DOS
applications are started at priority 25.
Note:
Internally all tasks have a unique priority. When a task is createdor its priority is changed, that task is
given a lower internal task priority than any other task in the system with the same user task priority.
time_slice
Set this value to zero if you do not want round-robin time slicing between this task and others at the same
priority level. If you do want round-robin switching, then specify here the number of milliseconds of CPU time
that this task should receive before the system switches to the next task at this same priority. System timing
granularity is one millisecond. Time slicing is disabled on all DOS application main tasks.
mailboxlevelN
These provisional four values are not used in the current implementation.
Related Topics
API function RTX_TASK_CREATE - Create and start a task
Page 239 / 400