Summary: Getting Started with uC/OS-2

admin

how to write a dummy uC/OS-2 program?
how the control flows among procedures?

Creating a dummy program in uC/OS-II involves writing a small task that does nothing. This allows you to understand the task creation process and the structure of a task. Here's an example of what this might look like:

1. #include "includes.h"
   
2. 
   
3. #define STACKSIZE 128
   
4. OS_STK TaskStk[STACKSIZE];
   
5. 
   
6. void Task(void *pdata)
   
7. {
   
8.     for (;;)
   
9.     {
   
10.         OSTimeDlyHMSM(0, 0, 1, 0); // Delay for 1 second
    
11.     }
    
12. }
    
13. 
    
14. int main(void)
    
15. {
    
16.     OSInit(); // Initialize the OS
    
17. 
    
18.     OSTaskCreate(Task, (void *)0, &TaskStk[STACKSIZE - 1], 0); // Create the task
    
19. 
    
20.     OSStart(); // Start multitasking
    
21. 
    
22.     return 0;
    
23. }

複製代碼

In this dummy program, the control flow starts in the main() function. OSInit() initializes uC/OS-II, setting up internal data structures and creating system tasks. OSTaskCreate() creates our dummy task, Task, which will run indefinitely, delaying for one second on each iteration. OSStart() begins multitasking, at which point control is handed over to the uC/OS-II scheduler, which will execute the highest priority task that is ready to run.

The control flow of the program is managed by the uC/OS-II kernel, which handles task scheduling and the transition between tasks. When a task is created, the kernel adds it to the list of ready tasks. When the scheduler runs, it selects the highest-priority task that is ready and switches the CPU context to that task. If a task yields the CPU or if its time slice expires, the scheduler selects a new task to run.

This is a simplified explanation and actual control flow in a uC/OS-II application can be complex, involving many tasks and synchronization primitives. Understanding this requires a deeper understanding of real-time operating system concepts.

how the space of stacks are allocated?


In uC/OS-II, the space for task stacks is typically statically allocated at compile time. Each task in uC/OS-II has its own stack space, which is provided when the task is created. The size of the stack space must be sufficient for the task's needs, otherwise a stack overflow might occur. The programmer is responsible for determining appropriate stack sizes.

Here's a simple example of how a stack is declared and used in task creation:

1. #define STACKSIZE 128
   
2. OS_STK TaskStk[STACKSIZE];
   
3. 
   
4. void Task(void *pdata)
   
5. {
   
6.     // Task code goes here...
   
7. }
   
8. 
   
9. int main(void)
   
10. {
    
11.     // Initialization code...
    
12. 
    
13.     OSTaskCreate(Task, (void *)0, &TaskStk[STACKSIZE - 1], 0);
    
14. 
    
15.     // More code...
    
16. }

複製代碼

In the example above, TaskStk is an array of OS_STK type with size STACKSIZE. This array represents the stack for the task. When OSTaskCreate is called, the address of the last element of the array is passed as the top of stack pointer. uC/OS-II uses a descending stack, meaning the stack grows from higher memory addresses to lower.

  how to hook on system events?
A "hook" function in uC/OS-II is a user-defined callback function that is invoked by the operating system in response to certain system events. Hooks allow you to insert custom code that will be run at specific points in the system's operation. This is a powerful feature that allows your application to react to system events, perform debugging or testing operations, monitor system behavior, and so on.

Here are a few examples of uC/OS-II hook functions:

OSTaskSwHook(): This function is called by the operating system every time a context switch occurs (i.e., when the operating system switches from running one task to another). You might use this hook to collect statistics about task switches or to perform task-specific setup or cleanup operations.

OSTaskCreateHook(): This function is called whenever a new task is created. You might use this hook to initialize task-specific resources or to keep track of the total number of tasks.

OSTaskDelHook(): This function is called when a task is about to be deleted. You might use this hook to clean up resources that were associated with the task.

OSIdleTaskHook(): This function is called repeatedly whenever the system has no other tasks to run. You might use this hook to put the CPU into a low-power mode to save energy, or to perform background processing tasks.

Remember that the code you put in a hook function should be quick to execute and should not make blocking calls or perform complex operations. The hooks are part of the operating system's operation, and if they take too long to execute, they can impact system performance or responsiveness. Similarly, because hooks can be called from any context, they need to be reentrant and safe to run in an interrupt context.

Lastly, hooks are defined at compile-time in uC/OS-II. That means you can't dynamically register or unregister hook functions at runtime (as you might be able to do in other systems). To use a hook, you provide your own definition of the hook function in your code; the operating system will call this function at the appropriate time.

For hooking on system events, uC/OS-II provides a set of "hook" functions that can be defined by the application to handle various system events. These include task switch hooks (OSTaskSwHook), task create/delete hooks (OSTaskCreateHook, OSTaskDelHook), idle task hook (OSIdleTaskHook), etc. These hook functions are called by the uC/OS-II kernel at appropriate times. For example, OSTaskSwHook is called each time a task switch occurs.

Here's an example of how to define a task switch hook:

1. void OSTaskSwHook(void)
   
2. {
   
3.     // This code will be executed on each task switch.
   
4. }

複製代碼

In this example, OSTaskSwHook is defined to do nothing. You can replace the body of the function with your own code to handle task switches. Note that hook functions should be as quick as possible to avoid affecting system performance. Also, certain operations may not be safe within a hook function, because they might cause a reschedule or a context switch.