Principle Analysis and Transplantation of Single-Chip Microcomputer Operating System RTX51

1. Subject requirements:

Carefully analyze the principles of the MCU operating system RTX51, transplant it to the MCU experimental platform, and require writing a short program to verify the correctness of its operation (for example, writing two tasks with different display contents).

2. RTX51 Principle

Note: Since the original English text is better, I did not translate it (but I also wrote a partial translation). I directly extracted some English and summarized them together.

1. Task Management

1) Classes of Tasks

RTX-51 recognizes two classes of tasks:

1. Fast tasks

n Contain especially short responses and interrupt disable times.

n Contain a separate register bank and a separate stack area (register banks 1, 2 and 3).(Figure 1)

n Contain the highest task priority (priority 3) and can therefore interrupt standard tasks.

n All contain the same priority and can therefore not be mutually interrupted.

n Can be interrupted by c51 interrupt functions.

n A maximum of three fast tasks can be active in the system.

2. Standard tasks

n Require somewhat more time for the task switching compared to fast tasks.

n Share a common register bank and a common stack area (register bank 0).

n The current contents of registers and stack are stored in the external (XDATA) memory during a task change.

n Can be interrupted by fast tasks.

n Can interrupt themselves mutually.

n Can be interrupted by c51 interrupt functions.

n A maximum of 16 standard tasks can be active in the system.

Figure 3: Task Classes and Memory Allocation

Each standard process contains a device context in extended memory (XDATA). When a standard process performs a process switch, it stores its own registers and stacks in the corresponding device context (an area in extended memory). Afterwards, registers and stacks are reloaded from the device context and execution continues. (Switching technology)

In comparison, fast processes do not require such trouble, because they have their own independent Register and Stack, so you only need to activate the corresponding Register (modify PSW) and the pointer to the Stack (Mov SP, #XX).

2) Task states

RTX-51 recognizes four task states:

1. READY All tasks which can run are READY. One of these tasks is the RUNNING (ACTIVE)task.

2. RUNNING (ACTIVE) Task which is currently being executed by the processor. Only one task (maximum) can be in this state at a time.

3. BLOCKED (WAITING) Task waits for an event.

4. SLEEPING All tasks which were not started or which have terminated themselves are in this state.

3) Process Scheduling (Task Switch)

The RTX-51 system section which the processors assigns to the individual tasks is referred to as the scheduler (also dispatcher).

The RTX_51 scheduler works according to the following rules:

1. The task with the highest priority of all tasks in the READY state is executed.

2. If several tasks of the same priority are in the READY state, the task that has been ready the longest will be the next to execute.

3. Task switchings are only executed if the first rule would have been otherwise violated (exception: round-robin scheduling).

Time-slice task change (round-robin scheduling) are executed if the following conditions are satisfied:

1. Round-robin scheduling must be enabled (see configuration).

2. The RUNNING task has the priority of 0 and is currently not executing a floating-point operation (see section "Floating-Point Operations", page 28).

3. At least one task with the priority zero must be in the READY state.

4. The last task change must have occurred after the selected system time interval (see system function "os_set_slice"). The system time interval can be changed dynamically during program execution.

4) Task Communication and Synchronisation

There are three two mechanisms:

1. Signal

Signals represent the simplest and fastest form of task communication. These can always be used when a pure task synchronization is required without data exchange.

Each active task contains its own signal flag with which the following operations can be executed:

l Wait for a signal

l Send signal

Clear signal

The task number (see section section "Task Declaration") of the receiver task is used for identifying the signals for the individual operations.

2. Message(via MailBoxes(FIFO))

n By means of the mailbox concept, messages can be exchanged free of conflicts between the individual tasks.

n RTX-51 provides a fixed number of eight mailboxes. Messages can be exchanged in words (2 bytes) via these mailboxes. In this case, a message can represent the actual data to be transferred or the identification of a data buffer(defined by the user). In comparison to the signals, mailboxes are not assigned a fixed task, but can be freely used by all tasks and interrupt functions. These are identified with a mailbox number.

Mailboxes allow the following operations:

l Send a message

l Read a message[page]

Each mailbox is internally consists of three wait lists.(Figure 2)

Figure 2

1. Message list

List of the messages written in the mailbox. These comprise a maximum of eight messages.

2. Write wait list

Wait list for tasks which want to write a message in the message list of the mailbox (maximum 16 tasks).

3. Read wait list

Wait list for tasks which want to read a message from the message list of the mailbox (maximum 16 tasks).

3. Semaphore

n By means of the semaphore concept, resources can be shared free of conflicts between the individual tasks.

n A semaphore contains a token that your code acquires to continue execution. If the resource is already in use, the requesting task is blocked until the token is returned to the semaphore by its current owner.

n There are two types of semaphores: binary semaphores and counting semaphores. As its name implies, a binary semaphore can only take two values: zero or one (token is in or out). A counting semaphore, however, allows values ​​between zero and 65535.

RTX-51 provides a fixed number of eight semaphores of the binary type.

Semaphores allow the following operations:

l Wait for token

l Return (send) token

2. Interrupt Management

RTX-51 performs task synchronization for external events by means of the interrupt system.

Two types of interrupt processing are basically supported in this case:

1. MCU C language Interrupt Functions (Interrupt are processed by c51 interrupt functions)

l Very sudden, periodically occurring interrupts without large coupling with the rest of the system (only infrequent communication with RTX-51 tasks, etc.).

l Very important interrupts which must be served immediately independent of the current system state.

2. Task Interrupts(Interrupts are processed by fast or standard tasks of RTX-51

l Fast Task Interrupts

Important or periodic interrupts which must heavily communicate with the rest of the system when they occur.

lStandard Task Interrupts

Only rarely occurring interruptions which must not be served immediately.

RTX-51 shows considerable different response times for fast and standard tasks.

u The INTERRUPT ENABLE registers of the 8051 are managed by RTX-51 and must not be directly manipulated by the user!

u The Interrupt Priority registers of the 8051 (not to be confused with the softwaretask priorities) are not influenced by RTX-51.

3. Dynamic Memory Management

RTX-51 uses a simple and effective algorithm, which functions with memory blocks of a fixed size. All memory blocks of the same size are managed in a socalled memory pool. A maximum of 16 memory pools each a different block size can be defined. A maximum of 255 memory blocks can be managed in each pool.

n Generate Memory Pool

The application can generate a maximum of 16 memory pools with various block sizes. The application must provide an XDATA area for this purpose. The pool is stored and managed by RTX -51 in this area (see system function "os_create_pool").

n Request Memory Block from Pool

As soon as a pool has been generated, the application can request memory

blocks. The individual pools are identified by their block size in this case.

If an additional block is still free in the pool, RTX-51 supplies the start address

of this block to the application. If no block is free, a null pointer is returned (see

system function "os_get_block").

n Return Memory Block to Pool

If the application no longer needs a requested memory block, it can be returned

to the pool for additional use (see system function "os_free_block").

4. Time Management

RTX-51 maintains an internal time counter, which measures the relative time passed since system start. The physical source of this time base is a hardware timer that generates an interrupt periodically. The time passed between these interrupts is called a system time slice or a system tick.

This time base is used to support time dependent services, such as pause or timeout on a task wait.

Three time-related functions are supported:

n Set system time slice

The period between the interrupts of the system timer sets the "granularity" of the time base. The length of this period, also called a time slice, can be set by the application in a wide range (see system function "os_set_slice").

n Delay a task

A task may be delayed for a selectable number of time slices. Upon calling this system function the task will be blocked (sleep) until the specified number of system ticks has passed (see system function "os_wait").

nCyclic task activation

For many real-time applications it is a requirement to do something on a regular basis. A periodic task activation can be achieved by the RTX interval wait function (see system function "os_wait"). The amount of time spent between two execution periods of the same task is controlled, using os_wait, and is measured in number of system ticks and may be set by the application.

5. RTX (FULL) Functions Overview

Initialize and Start the System:

os_start_system (task_number)

Task Management:

os_create_task (task_number)

os_delete_task (task_number)

os_ running_task_id()

Interrupt Management:

os_attach_interrupt (interrupt)

os_detach_interrupt (interrupt)

os_enable_isr (interrupt)

os_disable_isr (interrupt)

os_wait (event_selector, timeout, 0)

oi_set_int_masks (ien0, ien1, ien2)

oi_reset_int_masks (ien0, ien1, ien2)

Signal Functions:

os_send_signal (task_number)

os_wait (event_selector, timeout, 0)

os_clear_signal (task_number)

isr_send_signal (task_number)

Message Functions:

os_send_message (mailbox, message, timeout)

os_wait (event_selector, timeout, *message)

isr_send_message (mailbox, message)

isr_recv_message (mailbox, *message)

Semaphore Functions:

os_send_token (semaphore)

os_wait (event_selector, timeout, 0)

Dynamic Memory Management:

os_create_pool (block_size, *memory, mem_size)

os_get_block (block_size)

os_free_block (block_size, *block)

Functions with the System Clock:

os_set_slice (timeslice)

os_wait (event_selector, timeout, 0)

Debug Functions:

os_check_tasks (*table)

os_check_task (task_number, *table)

os_check_mailboxes (*table)

os_check_mailbox (mailbox, *table)

os_check_semaphores (*table)

os_check_semaphore (semaphore, *table)

os_check_pool (block_size, *table)

3. RTX51 porting

This experiment uses the Tiny version of RTX. That is to say, there is no priority distinction, no mailbox mechanism, and no dynamic memory management. It is very simple to transplant it. Just configure the configuration file it comes with, and then compile and link it with the written program. When connecting, add an rtxtny parameter, which means that when I connect, I connect the RTXtiny library file, which is equivalent to compiling the program and the operating system together. The configuration file can be found under the installation destination rtxtiny2. The file name is Conf_tny.A51. For example, in my computer, the path is: D:\\Keil\\MCUc语言\\RtxTiny2\\SourceCode\\Conf_tny.A51. As shown in the figure below:

[page]

Since the chip in the test box is AT 89C 51, so configure RAMTOP EQU of Conf_tny.A51 07F , the purpose is to configure the internal RAM to 128 bytes.

4. Source code:

The source code is as follows. Please see the comments in the code for explanation.

/*

** RTX-51 porting

** Ported to AT89S52

** This program is a cyclic pattern display LED light

** There are three display styles, corresponding to the following three processes

** The following algorithm uses the "time to space" conversion, which simplifies the algorithm a lot

** I have tested this program on a minimal system board.

*/

#include

#include

const unsigned char table[]={0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80

,0x40,0x20,0x10,0x08,0x04,0x02,0x01,0xFF,0x00};

/*Conversion from time to space, if table is:

const unsigned char table[]={0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80};

The number of algorithms and codes will be doubled. Although the number of table arrays has doubled, the number of algorithms has been reduced by half.

The benefits are of course not only reflected here, the following process 2 is also reduced by half*/

//Process 0 left->right->left

void LED0 (void) _task_ 0

{

int i;

os_create_task(1); //Create process 1

os_create_task(2); //Create process 2

while(1)

{

for (i = 0; i < 15; i++)

{

P1 = table[i];

os_wait(K_TMO,30,0); //Wait for 30*10000 microseconds = 0.3 seconds

}

os_send_signal(1); //Send Signal to activate process 1

os_wait(K_SIG,0,0); //Wait for signal

}

}

//Process 1 all on -> all off -> all on

void LED1 (void) _task_ 1

{

int i;

while(1)

{

os_wait(K_SIG,0,0);

for (i = 0; i < 3; i++)

{

P1 = table[15]; //All bright

os_wait(K_TMO,30,0);

P1 = table[16]; //All destroyed

os_wait(K_TMO,30,0);

}

os_send_signal(2);

}

}

//Process 2 both sides -> middle middle -> both sides

void LED2 (void) _task_ 2

{

int i;

while(1)

{

os_wait(K_SIG,0,0);

for (i = 0; i < 8; i++)

{

P1 = table[i] | table[i+7]; //Since the table length is twice as long, a loop is omitted and the algorithm is also simplified.

os_wait(K_TMO,30,0);

}

os_send_signal(0);

}

}

5. Conclusion:

This experiment uses the Tiny version of RTX. Many advanced functions are not implemented. The main purpose is to understand the principle of RTX, then transplant it to a single-chip microcomputer, and write a small program to test it. By reading the English documents attached to RTX, I have a deep understanding of this operating system. I feel that this operating system has many advantages and many shortcomings. For example, it supports fewer tasks, but because it is a single-chip microcomputer, its "endurance" capacity is also limited, which is understandable. In general, it is a good operating system for single-chip microcomputers.

6. Reference documents:

[1] RTX-51 Official English Documentation (including FULL version and Tiny version)

[2] Keil Software – Cx51 Compiler User Manual, Chinese version