rtel wrote on Friday, June 17, 2016:
I hope you understand what i am trying to say.
Note really to be honest :o)
A task is implemented by a function. When the task starts, the task is
given its own stack, and it starts executing the function at the very
top of the function - just as if the function had been called by another
The way the C function is converted into assembly code is determined by
the compiler, hopefully (?) following the C standard. To the compiler,
the task is just a function like any other function, and is compiled as
such. Anything you expect to happen (with respect to the point at which
variables are allocated and the scope of the variables) were you to call
the function will be exactly how it will work if the function is the
entry point of a task - because exactly the same assembly instructions
will be executing.
Therefore usTest1 and usTest2 will be allocated (on the stack or in
registers, depending on the compiler and optimisation level, etc.) when
the program counter executes the function entry prologue code, exactly
as if the function had just been called by another function. There the
variables will exist until such time that you delete the task (at which
point the task’s stack is also freed). That is equivalent to the
variables existing until the function returned to its calling function
had it just been called.
The variables inside the for() loop have block scope - the block being
the brackets in the for() loop. They will therefore be allocated (on
the stack or in a register) each time you enter that block, and
unallocated each time you exit that block - exactly as they would do for
any block scope variable in any C program.