MaxTasks

MaxTasks RTOS Example

Overview

This example demonstrates how to increase the maximum number of system tasks beyond the default limits in the NBRTOS (NetBurner Real-Time Operating System). The application creates multiple tasks that execute in a sequential chain pattern, showcasing the system's ability to handle an increased task count.

Application Description

The MaxTasks example creates 64 additional tasks beyond the standard system tasks. These tasks operate in a coordinated sequence where each task:

1. Waits for its turn using a semaphore
2. Introduces a short delay for readable output
3. Prints its task information (name, priority, system tick)
4. Signals the next task in the sequence
5. Returns to sleep

The tasks execute in reverse priority order, creating a continuous cycle that demonstrates the system's task scheduling capabilities.

Key Features

• Task Creation: Creates 64 extra tasks with unique names and priorities
• Sequential Execution: Tasks execute in a coordinated chain pattern
• Status Reporting: Each task reports its name, priority, and current system tick
• Error Handling: Provides feedback on task creation success/failure
• Network Integration: Includes network stack initialization and DHCP support

Configuration

System Limits

The application requires modification of default RTOS limits through the constants-overload.h file:

#define OS_MAX_TASKS (64)    // Max number of system tasks
#define OS_MAX_PRIOS (128)   // Maximum number of system priorities

Note

The application project must have the constants file located in the project's overload folder with the same path as the where the constants file is normally found, \nbrtos\include\constants-overload.h. The entire project path for constants is then: \MaxTasks\overload\nbrtos\include\constants-overload.h

Task Configuration

• Extra Task Count: 64 tasks (configurable via EXTRA_TASK_COUNT)
• Base Priority: Starts at MAIN_PRIO + 1 (configurable via EXTRA_TASK_BASE_PRIO)
• Stack Size: Each task uses USER_TASK_STK_SIZE stack space
• Task Names: Auto-generated as "ExtraTask_X" where X is the task index

Performance Considerations

Hard Limits

• Maximum of 256 task priorities in NBRTOS
• Priority values stored in uint8_t format
• Limited by OSTaskID() return type

Performance Impact

Increasing maximum task priorities affects system performance in several ways:

1. Memory Usage: All OS control objects (OS_CRIT, OS_SEM, OS_FIFO, OS_MBOX) must grow to accommodate additional priority levels
2. Processing Overhead:
   • Additional scanning required for priority bit checking
   • Increased memory bandwidth requirements
   • Greater cache space utilization
3. Memory Alignment: Default 16-byte OS control objects lose power-of-two alignment, potentially spanning multiple cache lines

Recommendation

A caution regarding system limits and performance. There is a hard limit of 256 task priorities in the NBRTOS. This is a function of storing the task priority in a uint8_t in the OS_TCB and the return type of OSTaskID().

As for the impact on system performance, when you increase the maximum task priorities, the OS must be able to handle the additional priority values. To do so, all task priority lists used in various OS related objects (i.e. OS_CRIT) have to grow in size. This not only means more memory usage, but, more fundamentally, more processing overhead. The processing overhead is twofold:

1. Scanning additional storage for bits being set.
2. The memory bandwidth and cache space associated with having to read more memory.

By default, most OS control objects (OS_CRIT, OS_SEM, OS_FIFO, OS_MBOX) are 16 bytes. This fits nicely from a memory alignment perspective as it's a power of two. By increasing the max priority value, it increases the size and breaks that symmetry, increasing the odds of the structure spanning multiple cache lines. Given this, the number of priorities shold not be increased unless absolutely necessary.

File Structure

main.cpp                 # Main application code
constants-overload.h     # System limit overrides

Code Structure

Main Components

1. Task Arrays: Pre-allocated storage for stacks, names, and semaphores
2. ExtraTask(): The common task function executed by all extra tasks
3. UserMain(): Application entry point that creates and manages tasks
4. Validation: Compile-time checks to ensure configuration consistency

Task Synchronization

The application uses an array of semaphores (ExtraTaskSem[]) to coordinate task execution. Each task:

• Waits on its own semaphore
• Posts to the previous task's semaphore (creating reverse-order execution)
• The cycle is primed by posting to the first task's semaphore

Build Requirements

• NetBurner NNDK (NetBurner Network Development Kit)
• NBRTOS support
• Network stack libraries

Usage

1. Configure the desired number of extra tasks by modifying EXTRA_TASK_COUNT
2. Ensure constants-overload.h has appropriate OS_MAX_TASKS and OS_MAX_PRIOS values
3. Compile and deploy to NetBurner hardware
4. Monitor serial output to observe task execution sequence

Output Format

Each task prints information in the format:

[TaskName][Priority]: [SystemTick]

Example output:

ExtraTask_0[ 21]: 1234
ExtraTask_63[ 84]: 1235
ExtraTask_62[ 83]: 1236
...

Error Handling

The application includes comprehensive error checking:

• Compile-time validation of configuration limits
• Runtime reporting of task creation success/failure
• Network initialization timeout handling

Customization

To modify the application:

• Change EXTRA_TASK_COUNT to create more/fewer tasks
• Adjust EXTRA_TASK_BASE_PRIO to change starting priority
• Modify timing delays in ExtraTask() and UserMain()
• Update task naming convention in the creation loop

Warning

This example is primarily for demonstration and testing purposes. In production systems, carefully consider the performance implications of increasing task limits and only do so when the additional tasks are essential for your application's functionality.