Tasks and Data

Each task has its own private context, which includes the register values, a program counter, and a stack. However, all other data - g1obal, static, initialized, uninitialized, and everything else - is shared among all of the tasks in the system. The RTOS typically has its own private data structures, which are not available to any of the tasks. Since you can share data variables among tasks, it is easy to move data from one task to another: the two tasks need only have access to the same variables.

You can easily accomplish this by having the two tasks in the same module in which the variables are declared, or you can make the variables public in one of the tasks and declare them extern in the other.

Shared – Data Problems

If we have two tasks sharing the same data, it could happen that one of this tasks will read the half-changed data.

 Reentrancy

 Reentrant functions are functions that can be called by more than one task and that will always work correctly even if the RTOS switches from one task to another in the middle of executing the function.

 You apply three rules to decide if a function is reentrant:

 1. A reentrant function may not use variables in a nonatomic way unless they are stored on the stack of the task that called. the function or are otherwise the private variables of that task.

2. A reentrant function may not call any other functions that are not themselves reentrant.

3. A reentrant function may not use the hardware in a nonatomic way.

To better understand reentrancy, and in particular rule l above, you must first understand where the C compiler will store variables. If you are a C language guru, you can skip the following discussion of where variables are stored in memory. If not, review your knowledge of C by examining the example and answering these questions: Which of the variables are stored on the stack and which in a fixed location in memory? What about the string literal “Where does this string go?” What about the data pointed to by vPointer? By parm_ptr?

 static int static_int;

 int public_int;

int initialized = 4;

 char *string = “Where does this string go?”;

void *vPointer;

 void function (int parm, int *parm_ptr)

 {

static int static_local;

 int local;

 . . .

}

Here are the answers:

static_int - is in a fixed location in memory and is therefore shared by any task that happens to call function.

public_int - Ditto. The only differenice be-tween static_int and public_int is that functions in other C files can access public_int, but they cannot access static_int.(This means, of course, that it is even harder to be sure that this variable is not used by multiple tasks, since it might be used by any function in any module anywhere in the-system.)

initialized - The same. The initial value makes no difference to where the variable is stored.

string - The same.

“Where does this string go?" - Also the same.

vPointer - The pointer itself is in a fixed location in memory and is therefore a shared variable. If function uses or changes the data values pointed to by vPointer, then those data values are also shared among any tasks that happen to call function.

parm - is on the stack. If more than one task calls function, parm will be in a different location for each, because each task has its own stack. No matter how many tasks call function, the variable parm will not be a problem.

parm_ptr - is on the stack. Therefore, function can do anything to the value of parm_ptr without causing trouble. However, if function uses or changes the values of whatever is pointed to by parm_ptr, then we have to ask where that data is stored before we know whether we have a problem. We can’t answer that question just by looking at the code in lf we look at the code that calls function and can be sure that every task will pass a diderent value for parm_ptr, then all is well. If two tasks might pass in the same value for parm_ptr, then there might be trouble.

static_local - is in a fixed location in memory. The only difference between this and static_int is that static_int can be used by other functions in the same C file, whereas static_local can onlylbe used by function.

local - is on the stack.

Research and Development

With a focus on R&D, Micromagine embedded software engineers go far and wide exploring the breadth of capabilities and fields of application for the next generation of industry hallmarks, identifying the potential pockets of growth for our customers.
Some of the latest examples of our R&D include studying and testing Android OS porting to custom hardware platforms and trying new dimension technologies such as motion controller in game development.

Embedded System Expertise

  • Deep experience across multiple embedded platforms (ARM Cortex M series, ARM64/aarch64, Intel x86-64)

  • Custom device driver design and implementation (Linux or microcontroller or otherwise)

  • Video- and audio-rate (or higher), low-latency DSP algorithms

  • Multi-threaded applications and data processing

  • Rapid prototyping

Quality Assurance

Quality Assurance of embedded systems is also available as a separate service for our clients. We provide testing and debugging for a range of embedded solutions.
To craft efficient, resilient, and infallible software, we’ve established two focused QA Labs: Firmware & Embedded QA Lab, and Mobile QA Lab, which are applicable during unit, integration, system, and acceptance testing.

 

Powered By by Micromagine Web Solutions