Real-time response of the Embedded Linux system on BeagleBone Black Wireless

Abstract

The project aims to extract the timing parameters that shows the real-time responsiveness of the Embedded Linux system ported on BeagleBone Black Wireless.

Introduction

Today’s product developing cycle is getting complex so it is getting difficult to get the product in time with Bare Metal System. The Real-time operating system (RTOS) increases the efficiency in task management and resource sharing, due to this developer need not worry much about hardware-level coding in details which reduces time to develop the system.

The main difference between an RTOS and Desktop Operating Systems such as Linux is the response time to external events. For certain applications, Linux can be used because of its rich networking support which is the most important block of IoT applications, scalability, open-source and large community support. With the real-time RTOS patch, we can improve the responsiveness of the Linux system. In this project, we will find out how much the Linux system is responsive to external events. we will build the kernel with the PREEMPT_RT patch.

System Implementation

To quantize the responsiveness of the Linux system the following parameters needs to find out:
1. Interrupt Latency: It shows how fast the external event starts to get serviced in the Linux system.
2. End-to-end Response Time: It is the total time to finish the interrupt service part and user application service part and giving response back to the external event.
3. Complete Syscall Time: It contains the user to kernel context switch time, executing one small instruction in kernel mode and return context switch time from kernel space to userspace. small instruction will be to change signal on GPIO.
4. Context Switch Time: It is the time required to context switch from userspace to kernel space.
5.Userspace Time with MMAP: It is the time required to turn change signal on GPIO by bypassing kernel space with MMAP.
6. Kernel Space Time with Kernel Function: It is the time required to change the signal on GPIO with kernel function in kernel space.

Resources

Hardware

• BeagleBone Black Wireless
• Tiva Family Board TM4c123G6PM
• USB to serial adapter
• Linux Machine

Software

• U-boot
• Linux kernel_version=5.4.70-bone-rt-r38
• Atomthread RTOS
• Code Composer Studio
• gnuplot
• gtkterm

Load Simulation

The Linux system responsiveness depends on the state of the system, the state which can cause larger latency to service to the external needs to be simulated in order to benchmark this system. There are many sources that can cause this response latency major of them are Networking tasks, Page Fault, Larger ISRs of interrupts etc. For this project, we will stimulate both Networking Tasks and Page Fault.

Networking Task

In this task, a large file will be transferred from Linux Machine to BeagleBone, this will cause large traffic on board such that it will affect the response time of the system. The BeagleBone should be connected to a network where Linux Machine is connected.Follow Link:[[1]]
sudo scp file_name debian@board_ip:/home/
Also, the folder on BeagleBone board is mounted on Linux machine over the network.
sudo sshfs -o allow_other debian@board_ip:/home/ ~/project_folder

Page Fault

Page Fault occurs when there is the entry of the physical address of the data in MMU, which implies data is not present in the RAM. The putting entry into MMU, swapping of the data in and out takes time, this can cause the late response to interrupt. The logic used for simulating the page fault is that we take dynamic memory of size near to RAM size. Then randomly get the location from this memory and write any data into this location, this will cause the page fault most of the time.

int main()
{
   while(1)
   {
      //get pointer to the 500MB data using malloc() function
     // get a random number as index for data 
     //Write the data into that location pointed by index
   }
}

Tasks

These tasks are used to get the values for timing parameters mentioned above.

1. Interrupt Latency

Interrupt Latency task uses setup-1 of the project. The logic used to determine this timing parameter as in the following pseudo-code:

//BeagleBone Interrupt module for GPIO_48
irq_handler
{
 
   GPIO_49=high;
   //Perform necessary task
   GPIO_49=low;
}
 
//Tiva Board Code
isr_handler //for PD0 which receives signal from BeagleBone GPIO_49 pin.
{
   //Turn off timer
   //Store the number of ticks
   //Post the Semaphore for Task1 and Task2
}
 
Task1() //Priority=16
{
    while(1)
   {
      //wait for Semaphore
      //disable systick int
      //PD1 = 1
      //Start timer with known value
      //Enable Systick
      //PD1 = 0
   }
}
 
Task2() //Priority=17
{
    while(1)
   {
      //wait for Semaphore
      //Print on UART
   }
}

The response observed is as below in the graph:

2. End-to-end Response Time

This task uses the setup-1 of project.The logic used to determine this timing parameter as in the following pseudo-code:

//BeagleBone Interrupt module for GPIO_48
irq_handdler
{
   //Send a signal to the user task
}
 
usertask()
{
   while(!check)
   {
      GPIO_49=high;
      wait=0;
      //perforn necessary task
      GPIO_49=low;
}
 
signal_handler()
{
   check=1;
}

The response observed is as below in the graph:

3. Complete Syscall Time

This task uses the setup-2 of project.The logic used to determine this timing parameter as in the following pseudo-code:

 

 

 

 

 

 

 

 

 

 

setup-2 of project

int main()
{
   while(1)
   {
        GPIO_49=high;
        syscall();
        GPIO_49=low;
   }
}
 
//Tiva Board Code
isr_handler //for PD0 which receives signal from BeagleBone GPIO_49 pin.
{
   if(PD0 is high)
   {
      //turn on timer
   }
   else
   {
      //Turn off timer
      //Store the number of ticks
      //Post the Semaphore for Task1
   }
}
 
Task1() //Priority=16
{
    while(1)
   {
      //wait for Semaphore
      //Print on UART
   }
}

The response observed is as below in the graph:

4. Context Switch Time

This task uses the setup-2 of project. The logic used to determine this timing parameter as in the following pseudo-code:

int main()
{
   while(1)
   {
        GPIO_49=high;
        syscall();
   }
}
 
sycall()
{
   GPIO_49=low;
}

5. Userspace Time with MMAP

This task uses the setup-2 of project. The logic used to determine this timing parameter as in the following pseudo-code:

int main()
{
   while(1)
   {
        GPIO_49=high;
        //Access the LED multiple time
        GPIO_49=low;
   }
}
Here the LED toggled multiple times to get average value of this parameter.

6. Kernel Space Time with Kernel Function

This task uses the setup-2 of project. The logic used to determine this timing parameter as in the following pseudo-code:

int main()
{
   while(1)
   {
        syscall();
   }
}
 
sycall()
{
   GPIO_49=high;
   //Access the LED multiple times
   GPIO_49=low;
}

Here, we are toggling the LED 10 times to get average time required to change the signal at LED GPIO.

Results

Minimum, Maximum and Average values timing parameters are shown below in the table, the table represents the overall response of this Linux system.

Some inferences from the tables are:

• The worst-case response time observed in this project is 37.36 ms, It was with loading mentioned above in this project. This delay implies the system which requires response time less than this time is difficult to implement.