Real-Time Performance Benchmarking of RISC-V Architecture: Implementation and Verification on an EtherCAT-Based Robotic Control System

1. Introduction

The surge in advanced intelligent and collaborative robots, along with automated control systems, has accelerated research in real-time control [1,2]. Embedded systems for real-time control must possess the capability to execute tasks within desired timeframes using limited resources [3]. Based on their response to missed deadlines, these systems are classified into hard, soft, and firm real-time systems. Failure to meet deadlines in hard real-time tasks can have severe consequences, such as system failure or even industrial disasters [4]. In contrast, missing deadlines in soft and firm real-time tasks typically does not lead to system destruction or severe consequences. If a soft real-time task exceeds its deadline, it may result in a lower quality of service to users or the continuation of the task, whereas a firm real-time task may render the results useless or cause them to be ignored by the system [5,6]. Therefore, real-time applications for real-time control must be implemented considering these time-critical constraints. As the demands for these real-time applications grow, there is a corresponding increase in the complexity and expense of implementing and validating their functionalities. However, costs can be mitigated with adequate technical support and detailed information about the instruction set architecture (ISA) for these systems.

RISC-V is an ISA designed to be simple and modular. Developed as open-source and royalty-free, it allows anyone to use and extend its capabilities freely [7]. This makes it a popular option for creating embedded systems in real- time environments, especially when budget constraints are a major consideration, due to its advantage of low-cost deployment [8,9]. Additionally, RISC-V can be modified to meet various constraints and requirements easily, allowing for the implementation of desired functionalities [10,11,12]. However, unlike ARM and x86-64, which benefit from advanced commercialization and a wealth of information, RISC-V, as a relatively new player in the market, encounters challenges due to limited technical support and information pertaining to the development of real-time applications [13].

the escalating complexity and functional demands of real-time applications, meeting required response times has become increasingly challenging. Consequently, there is an increased need for development information to implement RISC-V based real-time systems that achieve these response times. By offering diverse real-time performance information through comparisons of RISC-V with various ISAs, we aim to simplify the development of RISC-V-based real-time systems that meet necessary performance standards, thereby improving the development efficiency. In this paper, we compare and analyze the real-time performance capabilities of the Inter-task Communication (ITC) mechanism on embedded boards based on RISC-V and other ISAs. For complex, multi-functional tasks in real-time applications, it is common to divide them into smaller tasks based on their specific roles. These smaller tasks rely on ITC to maintain data integrity and to ensure timely communication [14]. Specifically, ITC is used for facilitating communication among various tasks in applications that collect signals from sensors or other hardware, analyze and process these signals within a defined time frame, and subsequently operate actuators [15,16]. The kernel architecture for running these real-time applications differs based on the processor architecture and can be categorized into real-time operating systems (RTOS) and real-time Linux, depending on the approach.

For RTOS applications, we utilized FreeRTOS [17] and applied it to HiFive1 Rev B (RISC-V) and STM3240G- EVAL (ARM M). For real-time Linux, we chose Linux with the Preempt-RT patch [18], conducting our experiments on VisionFive 2 (RISC-V), MIO5272 (x86-64), and Raspberry Pi 4 B (ARM A). Table 1 and Table 2 show the specifications of the boards using FreeRTOS and Preempt-RT. We carried out experiments using both FreeRTOS and Linux with the Preempt-RT patch for each ISA to assess and compare their real-time performance capabilities across various processor architectures. In FreeRTOS, we focused on measuring the response times of the queue, stream buffer, message buffer, semaphore, and mutex. The results revealed that ITC mechanisms in FreeRTOS on RISC-V performed better than those on ARM M. For Preempt-RT, our measurements included the response times of the pipe, FIFO, message queue, semaphore, and mutex. Moreover, we evaluated the scheduling latency of each ISA using cyclictest [19] on Linux with the Preempt-RT patch. Across all tested metrics in Preempt-RT, x86-64 showcased the best real-time performance. Notably, RISC-V surpassed ARM A in all ITC mechanisms except FIFO. However, its Cyclictest results indicated the lowest performance. Despite this, the results demonstrated that RISC-V meets the performance requirements necessary for real-time applications. To validate RISC-V’s capability in real-world scenarios further, we tested its real-time performance by controlling a collaborative robot. For a comparative analysis, we selected x86-64, recognized for its superior real-time performance, and implemented an EtherCAT master and a real-time motion control application on each ISA. Our results indicated that real-time application based on RISC-V adequately fulfills the performance demands for motion control of a collaborative robot.

This paper has five sections. In Section 2, we provide an overview of FreeRTOS and Preempt-RT. Section 3 deals with the real-time mechanisms in FreeRTOS and presents the benchmarking results. Section 4 describes the experiments conducted to assess the real-time performance capabilities on Preempt-RT and shows each benchmarking result. Finally, we summarize the results of benchmarking the real-time performance.

2. Related Work

Recent research has focused extensively on analyzing the performance capabilities of real-time operating systems (RTOS) and real-time Linux across various architectures. In one such study [20], performance of RTOS on ARM M4 and M0 microcontrollers, with a particular emphasis on context switching in systems that support preemptive scheduling. This included FreeRTOS, RT-thread, Keil RTX, and uC/OS-II, and the evaluation was based on events, semaphores, and mailboxes. The study provided insights for choosing an RTOS that is well suited for small microcontrollers by comparing various RTOS types on similar architectures. However, these experiments were limited to the ARM M architecture and focused exclusively on RTOS synchronization mechanisms. In contrast, our experiment broadens the scope by comparing the real-time performance capabilities of task communication mechanisms across various ISAs, including RISC-V, taking into account the size of the data transmitted.

In a previous study [21], experiments were carried out to measure execution times and latencies. These included comparing the performance capabilities of two forms of RTOS, specifically FreeRTOS and uC/OS-III. The measurements focused on real-time latencies, semaphore and mutex operation durations, and the frequency of sustained interrupts. Furthermore, additional tests examined thread creation and mutex locking behaviors to detect any functional issues in the operating systems. Another study [22] focused on the performance of RTOS in IoT devices, measuring the time required for task-switching due to semaphores and message queues, time durations when acquiring and releasing a fixed-size memory region, and the response time of a task to an interrupt service routine. However, as the computational demands and development costs of embedded systems rise, real-time Linux is increasingly being adopted in various fields [18]. Therefore, in our study, we aim to aid in the design and development of real-time applications for embedded systems by providing insights into the real-time performance of not just RTOS, but also the Preempt-RT kernel, across different ISAs.

One study [23] conducted a comparison of the timing accuracy and interrupt latency between a compounded real-time operating system (cRTOS), Preempt-RT, and Xenomai. In other research [24], the timing latencies of Linux patched with Preempt-RT were assessed on different ARM architectures, specifically Raspberry Pi 3 and BeagleBone AI. Researchers [24] also delved into the scheduling latency of real-time Linux on multi-core general-purpose processors, offering development guidelines for real-time applications suited to Xenomai and Preempt-RT kernels. Additionally, experiments were undertaken on scheduling latency using Cyclictest on the RISC-V architecture with the Preempt-RT patch [25]. Despite these studies, there is a noticeable lack of information about the development of real-time applications for RISC-V when compared to other ISAs. To address this gap, we implemented real-time applications on both RISC-V and x86-64, providing insight into real-time performance capabilities for robot motion control.

In this paper, we compare various real-time performances across multiple ISAs to demonstrate the performance of the RISC-V architecture for real-time applications with a multi-tasking structure. To validate the practicality of our experimental findings, we implemented an EtherCAT master on both RISC-V and x86-64 to control a six-axis robot. This paper contributes by offering valuable information about real-time performance outcomes, aiding in the selection of an appropriate ISA for real-time systems. It also highlights the potential for significant time and cost savings in the development of real-time applications utilizing the RISC-V.

3. Background

3.1. FreeRTOS

FreeRTOS, an open-source real-time operating system (RTOS), is suitable for small embedded systems that are required to undertake multi-tasking [26]. It features a microkernel architecture and is primarily used in microcontrollers and small microprocessors [27]. Its popularity in real-time application development projects stems from its simplicity, compact size, portability, user-friendliness, and compatibility with various hardware architectures. Additionally, the robust FreeRTOS community offers substantial technical support, with system bugs and errors swiftly addressed, providing significant benefits for development [28].

3.2. Preempt-RT

The Preempt-RT patch consists of a series of kernel modifications aimed at minimizing latency and enhancing determinism for tasks on Linux [29]. By applying the Preempt-RT patch to a Linux kernel, real-time tasks can be executed alongside non-real-time tasks in the same user space. This integration offers features such as symmetrical multiprocessing (SMP) and priority inheritance to avoid priority inversion outcomes [30,31]. Furthermore, the development of real-time applications is facilitated by its compatibility with existing libraries and tools that comply with the POSIX standard [18].

3.3. Inter-task communication

Inter-task communication (ITC) mechanisms facilitate data transfers between tasks, and each kernel can implement these mechanisms with slight variations in functionality and naming. The commonly used ITC mechanisms in real- time kernels include the following:

• Queue: This mechanism is for message transfers between tasks, operating on a first-in, first-out (FIFO) basis. Users can define the message size and the queue’s capacity. In many types of RTOS, if a task attempts to retrieve a message from an empty queue, it will wait until another task places a message in the queue.
• Semaphore: Semaphores are used to manage access to task resources. Operating systems typically categorize them into binary semaphores, with a count limit of one, and counting semaphores, with a higher count limit. Unlike mutexes, semaphores do not prioritize tasks, making them suitable for synchronizing operations between tasks.
• Mutex: A mutex, short for mutual exclusion, limits access to a resource to one task at a time, ensuring that the task holding the mutex can operate without interference from others. While similar to a binary semaphore in restricting access to a single resource, a mutex is unique in that it is assigned to the task with the highest priority.

4. Real-time Performance measurement on FreeRTOS

In this section, we outline the uniform RTOS environments and experimental methodologies applied across various ISAs and present the corresponding results. The hardware used in the experiments and the experimental environment are detailed in Table 1. To evaluate the real-time performance of RISC-V and other ISAs in RTOS, we measured inter-task communication response times in FreeRTOS. For the RISC-V assessments, we used the HiFive1 Rev B board, which is equipped with a FE310-G002 32-bit microcontroller unit. This board is capable of speeds up to 320MHz and includes 2kB of SRAM and 4MB of flash memory. In the ARM M case, our experiments were conducted on the STM3240G-EVAL board, hosting an STM32F407IGH6 32-bit microcontroller unit with a maximum speed of 168MHz and 2MB of SRAM. Our development environment consisted of Visual Studio Code IDE and PlatformIO, employed as a cross-platform development extension. Due to the limited availability of the FreeRTOS kernel version for the HiFive1 Rev B board in our setup, we aligned the kernel version on the STM3240G-EVAL board to V10.2.0 for consistency. The experimental results indicated that RISC-V’s real-time performance in all ITC mechanisms of FreeRTOS was superior to that of ARM M.

4.1. Inter Task Communication of FreeRTOS

In our test application, we measured the communication time between two tasks to assess the real-time performance of the ITC mechanism. Figure 1 illustrates the setup used to evaluate the real-time performance of the ITC mechanism on FreeRTOS. We assigned the priorities of the two tasks differently, with the highest being 8 and a slightly lower priority ranking at 7, conducting the tests over a period of 10ms. During the experiments, we connected the GPIO pins of each board to an oscilloscope and recorded measurements from over 1000 adequate samples. The real-time performance of the ITC mechanism for each ISA was then determined by calculating the average of these measured response times.

4.1.1. Queue

In our experiment, we measured the time required for a task to send data to a queue and for another task to receive and return the data. We utilized two separate queues for sending and receiving data, enabling efficient communication between the tasks. Unlike previous studies [32] that measured RTOS performance using a single task to send a fixed-size message to itself, our experiment aimed to evaluate message communication performance capabilities in a multi-tasking real-time application. We conducted tests with messages of varying sizes, handled by two tasks. To assess how the response time varied with different data sizes, we incrementally increased the size of the data sent through the queue, starting with 60 bytes and increasing to 600 bytes in 60-byte steps.

Figure 2 displays the experimental results. We observed that with an increase in the data size, the average response time ranged from 9.84us to 12.85us for HiFive1 Rev B and from 64.72us to 334.70us for STM3240G-EVAL. Notably, the queue’s response time was consistently shorter in RISC-V, and the escalation in the response time as the data size was increased was also relatively minimal.

4.1.2. Stream Buffer

Stream buffer, a mechanism used to transfer data of varying lengths as a byte stream between two tasks, was employed in our experiment. We utilized two stream buffers, one for sending and the other for receiving data between the tasks, to measure the time required for data exchange. To determine how the response time varied with different data sizes, we increased the size of the data by 60 bytes in each step of the experiment.

Figure 3 presents the results of these tests. We observed that the average response time ranged from 13.05us to 32.75us for HiFive1 Rev B and from 71.40us to 342.04us for STM3240G-EVAL.

4.1.3. Message Buffer

In our experiments, we focused on the message buffer, a mechanism specifically designed to transmit variable- length discrete messages between two tasks. We used two message buffers, one for sending and the other for receiving data, to measure the time required to exchange data. To analyze how the response time varied with different data sizes, we systematically increased the size of the data in increments of 60 bytes.

The outcomes of these experiments are depicted in Figure 4. We noted that the average response time increased from 3.10us to 9.64us for HiFive1 Rev B and from 18.31us to 108.51us for STM3240G-EVAL.

4.1.4. Semaphore and Mutex

In FreeRTOS, semaphores are categorized into counting and binary semaphores based on the number of preemptible semaphores. Counting semaphores control access to a resource by restricting the number of semaphores available for resource preemption, restricting access once the count reaches zero. On the other hand, binary semaphores and mutexes are used to prevent simultaneous access to a resource by two tasks. In this experiment, we measured the time taken for a semaphore or mutex to be released and then acquired between two tasks [33].

The results are displayed in Figure 5. The average response times for HiFive1 Rev B were 4.74us for counting semaphores, 4.68us for binary semaphores, and 4.90us for mutex. For STM3240G-EVAL, these times were 12.64us, 27.97us, and 13.68us, respectively. Notably, the binary semaphore experiment on STM3240G-EVAL showed highly unstable signals, with a significant standard deviation of 68.8us. To investigate potential errors in the ARM’s binary semaphore related to the FreeRTOS version, we repeated the experiment using version 10.4.4 without any code changes. This led to stable binary semaphore signals, showing a response time of 12.50us and a remarkably low standard deviation of 0.002us. Additionally, version 10.4.4 displayed a modest improvement in the real-time performance for both counting semaphores and mutex compared to version 10.2.0. Table 3 presents the experimental results for semaphores and mutexes, including FreeRTOS version 10.4.4.

5. Real-time Performance measurement on Preempt-RT

In this section, we describe the real-time Linux environment and experimental methods for various ISAs, and their corresponding experimental results. To evaluate the real-time performance of RISC-V and other ISAs in a real-time Linux environment, we patched Linux with Preempt-RT and measured the response time of ITC mechanism. Figure 6 depicts the setup for assessing the real-time performance of ITC mechanism on Preempt-RT. We also conducted a cyclictest to evaluate the scheduling latency of each ISA. For consistency across experiments, we applied the Preempt-RT patch to a Debian-based Linux version 5.15, suitable for each board, within a desktop environment. This setup was then cross-compiled and installed on all boards.

The hardware used and the versions of the real-time kernel are detailed in Table 2. For these experiments, the RISC-V VisionFive 2 board with a JH-7110 64-bit microprocessor unit at 1.5GHz and 8GB SDRAM was utilized. The ARM A ISA was represented by Raspberry Pi 4 B, equipped with a BCM2711 64-bit microprocessor unit at 1.5GHz and 8GB SDRAM. The x86-64 setup involved the MIO-5272 board, featuring a 2.6GHz i7 6600U 64-bit microprocessor unit and 16GB of SDRAM. The experimental findings indicate that in Preempt-RT, x86-64 offered the best real-time performance for the ITC mechanism, and except for FIFO, RISC-V outperformed ARM A. In the cyclictest results, x86-64 showed superior performance, while RISC-V recorded the lowest outcome.

5.1. Inter Task Communication of Preempt-RT

In the test application to measure the real-time performance of the ITC mechanism in Preempt-RT, we measured the communication time between two tasks, similar to the experiment conducted previously in FreeRTOS. We set the corresponding task priorities to 95 and 90 and established a 10ms period for the experiment, which ran for a total duration of 30 minutes. The response time of the ITC mechanism was captured using the high-resolution time function clock_gettimer(), and the data was saved to a file for analysis. The real-time performance capabilities of the ITC mechanism for each ISA were then determined by calculating the average of these recorded response times.

5.1.1. Pipe

A ’pipe’ is a mechanism that facilitates the transmission of messages without set boundaries by means of a byte stream between two tasks [34]. In our experiment, we used two pipes, one for sending and the other for receiving data, to measure the time required to exchange data. To observe the variations in the response time with different data sizes, we conducted the experiments while gradually increasing the data size from 4 to 3072 bytes. The outcomes of these experiments are depicted in Figure 7. The average response time for VisionFive 2 was shorter than that of Raspberry Pi 4 B but longer than that of MIO-5272.

5.1.2. FIFO

FIFO, functioning similarly to a pipe, is a mechanism used for message transmission between two tasks. It can be handled like a file in a file system, akin to a regular file [35].In our experiment, we utilized two FIFOs, one for sending and the other for receiving data, to measure the time needed to complete the data exchange. To assess how the response time varied with different data sizes, we progressively increased the data size from 4 to 3072 bytes in each test. The results of these experiments are presented in Figure 8. We observed that the average response time for VisionFive 2 was less than that of Raspberry Pi 4 B but greater than that of MIO-5272.

5.1.3. Message Queue

A message queue is a mechanism for transmitting fixed-length messages between two tasks, ensuring that the receiver receives complete messages as sent by the sender. In our experiment, we used two message queues for sending and receiving data to measure the time required to exchange data. To determine how the response time varied with different data sizes, we incrementally increased the data size from 4 to 3072 bytes during these tests. The outcomes of these experiments are illustrated in Figure 9. We found that the average response time for the VisionFive 2 was less than that of the Raspberry Pi 4 B, but greater than that of the MIO-5272.

5.1.4. Semaphore and Mutex

We measured the time it took for two tasks to release and subsequently acquire a semaphore or mutex. The results of this experiment are displayed in Figure 10. For both the semaphore and mutex, the average response times were 10.84us and 10.01us for VisionFive 2, 18.29us and 18.11us for Raspberry Pi 4 B. The corresponding times were 4.92us and 4.90us for MIO-5272.

5.2. Scheduling Latency

In a real-time Linux environment, we employed the cyclictest benchmarking tool to evaluate the scheduling latency of each ISA. cyclictest enables measurements of the difference between a thread’s intended wake-up time and the time it wakes up for each ISA [36]. A previous study [25] used cyclictest in Preempt-RT-patched Linux to assess the real-time performance of RISC-V. However, our experiment expanded this analysis to include not only RISC-V but also ARM A and x86-64, enabling a comprehensive comparison of their real-time performance capabilities. The measurements for each ISA were carried out over a two-hour period with 1ms intervals.

For cyclictest, we used the -m option to prevent page faults and the -S option for efficient testing in SMP (symmetric multiprocessing) systems ($cyclictest -m -S -p97 -i1000 -N -d0 -D2h). Our results showed that MIO- 5272 exhibited the shortest average scheduling latency of 3.92us, whereas VisionFive 2 had the longest at 32.69us. In terms of the standard deviation, MIO-5272 also had the smallest value at 0.20us, while VisionFive 2 had the largest outcome at 7.02us. A summary of the cyclictest results is provided in Figure 11 and Table 3.

Table 5. measured scheduling latency on cyclictest

Hardware	Mean (us)	Min (us)	Max (us)	Sdev (us)
VisionFive 2	32.690	7.662	202.984	7.023
Raspberry Pi 4 B	21.472	14.311	158.704	1.440
MIO-5272	3.919	3.489	38.051	0.202

Table 5. measured scheduling latency on cyclictest

Hardware	Mean (us)	Min (us)	Max (us)	Sdev (us)
VisionFive 2	32.690	7.662	202.984	7.023
Raspberry Pi 4 B	21.472	14.311	158.704	1.440
MIO-5272	3.919	3.489	38.051	0.202

6. Real-time Performance Experiment on Collaborative Robot

In this section, we describe the experimental environment used to assess real-time Linux motion control of a collaborative robot based on RISC-V. We detail the implementation procedure and results of the executed real-time application. By assessing the real-time performance of each ISA via the ITC mechanism and with cyclictest experiments within the Preempt-RT framework, we were able to ascertain that RISC-V meets the requisite performance benchmarks for real-time application deployment. Accordingly, we developed a real-time application for collaborative robot motion control and examined its response times to ensure the ISA’s compatibility with real-time operational demands.

To construct the real-time motion control system, our platform of choice was Preempt-RT, consistent with our previous experimental environment. For the EtherCAT master implementation, we adopted IgH EtherCAT, an open-source fieldbus protocol [37,38]. In the ensuing experiments, we selected VisionFive 2 on RISC-V and MIO-5272 of x86-64, which is recognized for its superior real-time performance. These boards were patched with Preempt-RT and subsequently integrated with the IgH EtherCAT master.

In prior research, referenced as [39], the focus was on EtherCAT master’s implementation and a real-time performance evaluation for a Python-based servo motor control application. This paper directly evaluates RISC-V’s applicability in real-time systems by evaluating response times during a collaborative robot motion control test. Figure 13 shows the architecture of the EtherCAT network with Preempt-RT for motion control. Commands dispatched from the EtherCAT master for motion control traverse the Ethernet driver, subsequently reaching the robot’s six actuators via the network interface. The EtherCAT application interface provides the requisite libraries and tools pivotal for EtherCAT motion control applications, while the EtherCAT master core contains crucial data pertaining to both master and slave entities.

The EtherCAT master core was designed to abstract system-level routines related to EtherCAT, utilizing the IgH EtherCAT application interface and library. The Master Base is responsible for configuring the EtherCAT master according to the connected slaves. Furthermore, data acquisition and control for each slave should be executed in line with its specific Slave Base. The real-time functionalities intrinsic to the Preempt-RT kernel manifest through RT- POSIX. Hence, every task integral to the motion control application functions as a real-time task, operated via POSIX threads within the RT-POSIX environment.

6.1. Motion Control of a Collaborative Robot

To ensure the efficient operation of the motion control application, its functionalities were modularly partitioned and decomposed across multiple tasks, culminating in a multi-task implementation. Figure 14 shows the architecture of the motion control application. The Dynamic Task is responsible for computing inverse dynamics and leverages the open-source Kinematics and Dynamics Library (KDL) provided by Orocos. The Trajectory Task specifies the designated trajectory and velocity for each joint. The Main Task controls Indy7’s operations, utilizing the IgH EtherCAT protocol. It receives control data from message queues managed by individual tasks. Finally, the Log Task logs the response times of each task, encompassing its own, and integrates the encoder data, subsequently storing this information in a designated file.

In the experiment conducted here, motion control involved rotating each motor angle of Indy7 [40] within a range from 0 to 90 degrees. Concurrently, the real-time performance was evaluated by examining the response times associated with each task.

Table 6 shows the experiment task configurations and the corresponding response time results. The data reveals that, concerning the application response times across both architectures, the Dynamic Task had the shortest durations, whereas the Log Task registered the longest. Specifically, for VisionFive 2, the response times for the Dynamic Task and Log Task were 112.71us and 329.50us, respectively. In contrast, for MIO-5272, these times were 95.89us for the Dynamic Task and 164.08us for the Log Task.

Figure 15 and Figure 16 depict the discrepancies between the reference and actual trajectories for each joint angle of Indy7. In these figures, the red line signifies the positional variance, while the blue line represents the velocity differential. The positional and velocity values for each joint were derived from encoder sensor feedback data. The experimental results indicate that both hardwares maintained positional variance of less than two degrees across all joints. Nonetheless, notable velocity discrepancies were evident at the initiation and culmination of the motion sequences. These fluctuations likely arose from real-time adjustments and optimizations of the velocity controller to ensure accurate and smooth motion. Notably, both VisionFive 2 and MIO-5272, built on x86-64 ISA, recognized for its superior real-time performance, effectively performed motion control for Indy7. This underscores the potential feasibility of employing RISC-V in real-time applications, particularly for collaborative robot management.

7. Conclusion

In this paper, we analyzed the real-time performance of RISC-V and other ISAs to provide development metrics for real-time system applications. We employed two real-time approaches, FreeRTOS and Linux with Preempt-RT. For FreeRTOS, we evaluated the ITC mechanism’s response time on both HiFive1 Rev B (RISC-V) and STM3240G-EVAL (ARM M). Meanwhile, with Preempt-RT, we assessed the ITC mechanism’s response time and determined the scheduling latency using Cyclictest across three Hardwares: VisionFive 2 (RISC-V), Raspberry Pi 4 B (ARM A) and MIO-5272 (x86-64). Following our analysis, we successfully implemented the IgH EtherCAT master on both RISC-V and the outperforming x86-64 ISA. Utilizing a multi-task real-time application, we controlled the motion of a six-axis collaborative robot, known as Indy7, to assess the real-time capabilities of both ISAs. Our findings indicate that while RISC-V excels in real-time performance, particularly with the ITC mechanism in RTOS, its performance and scheduling latency in real-time Linux were comparatively low. However, with regard to real-time robot control applications, RISC-V’s performance stood competitively alongside those of other ISAs.

In future research, leveraging the insights obtained from our real-time performance analysis in this study, we aim to expand the scope of RISC-V applications within real-time environments, particularly for overseeing diverse robotic systems such as mobile robots. Furthermore, we intend to explore the feasibility of integrating advanced intelligent control systems, harnessing deep learning and machine learning techniques, in RISC-V-based real-time applications.