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
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.
References
- Davis, R.I.; Burns, A. A survey of hard real-time scheduling for multiprocessor systems. ACM computing surveys (CSUR) 2011, 43, 1–44. [Google Scholar] [CrossRef]
- Stankovic, J.A. Strategic directions in real-time and embedded systems. ACM Computing Surveys (CSUR) 1996, 28, 751–763. [Google Scholar] [CrossRef]
- Akesson, B.; Nasri, M.; Nelissen, G.; Altmeyer, S.; Davis, R.I. An empirical survey-based study into industry practice in real-time systems. In Proceedings of the 2020 IEEE Real-Time Systems Symposium (RTSS). IEEE; 2020; pp. 3–11. [Google Scholar]
- de Matos Pedro, A.; Pereira, D.; Pinho, L.M.; Pinto, J.S. Logic-based schedulability analysis for compositional hard real-time embedded systems. ACM SIGBED Review 2015, 12, 56–64. [Google Scholar] [CrossRef]
- Liu, D.; Hu, X.S.; Lemmon, M.D.; Ling, Q. Firm real-time system scheduling based on a novel QoS constraint. IEEE Transactions on Computers 2006, 55, 320–333. [Google Scholar] [CrossRef]
- Song, I.; Kim, S.; Karray, F. A real-time scheduler design for a class of embedded systems. IEEE/ASME Transactions on Mechatronics 2008, 13, 36–45. [Google Scholar] [CrossRef]
- Asanović, K.; Patterson, D.A. Instruction sets should be free: The case for risc-v. EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2014-146 2014. [Google Scholar]
- Patterson, D. Reduced instruction set computers then and now. Computer 2017, 50, 10–12. [Google Scholar] [CrossRef]
- Torres-Sánchez, E.; Alastruey-Benedé, J.; Torres-Moreno, E. Developing an AI IoT application with open software on a RISC-V SoC. In Proceedings of the 2020 XXXV Conference on Design of Circuits and Integrated Systems (DCIS). IEEE; 2020; pp. 1–6. [Google Scholar]
- Patterson, D.; Waterman, A. The RISC-V Reader: an open architecture Atlas. Strawberry Canyon, 2017. [Google Scholar]
- Ince, M.N.; Ledet, J.; Gunay, M. Building an open source Linux computing system on RISC-V. In Proceedings of the 2019 1st International Informatics and Software Engineering Conference (UBMYK). IEEE; 2019; pp. 1–4. [Google Scholar]
- Cannizzaro, M.J.; Gretok, E.W.; George, A.D. Risc-v benchmarking for onboard sensor processing. In Proceedings of the 2021 IEEE Space Computing Conference (SCC). IEEE; 2021; pp. 46–59. [Google Scholar]
- Abraham, V.; Ranpariya, D.; Parikh, P.; Gajjar, S.; Shah, D. Exploration of FreeRTOS on a RISC-V Architecture. In ICT Systems and Sustainability: Proceedings of ICT4SD 2022; Springer, 2022; pp. 1–11. [Google Scholar]
- Hambarde, P.; Varma, R.; Jha, S. The survey of real time operating system: RTOS. In Proceedings of the 2014 International Conference on Electronic Systems, Signal Processing and Computing Technologies. IEEE; 2014; pp. 34–39. [Google Scholar]
- Qian, K.; Wang, J.; Gopaul, N.S.; Hu, B. Low cost multisensor kinematic positioning and navigation system with Linux/RTAI. Journal of Sensor and Actuator Networks 2012, 1, 166–182. [Google Scholar] [CrossRef]
- Cifuentes-Cuadros, A.A.; Romero, E.; Caballa, S.; Vega-Centeno, D.; Elias, D.A. The LIBRA NeuroLimb: Hybrid Real-Time Control and Mechatronic Design for Affordable Prosthetics in Developing Regions. Sensors 2023, 24, 70. [Google Scholar] [CrossRef]
- Melot, N. Study of an operating system: FreeRTOS, 2009.
- Reghenzani, F.; Massari, G.; Fornaciari, W. The real-time linux kernel: A survey on preempt_rt. ACM Computing Surveys (CSUR) 2019, 52, 1–36. [Google Scholar] [CrossRef]
- de Oliveira, D.B.; Casini, D.; de Oliveira, R.S.; Cucinotta, T. Demystifying the real-time linux scheduling latency. In Proceedings of the 32nd Euromicro Conference on Real-Time Systems (ECRTS 2020). Schloss Dagstuhl-Leibniz-Zentrum für Informatik; 2020. [Google Scholar]
- Anh, T.N.B.; Tan, S.L. Real-time operating systems for small microcontrollers. IEEE micro 2009, 29, 30–45. [Google Scholar] [CrossRef]
- Peng, L.; Guan, F.; Perneel, L.; Timmerman, M. Behaviour and performance comparison between FreeRTOS and μC/OS-III. International Journal of Embedded Systems 2016, 8, 300–312. [Google Scholar] [CrossRef]
- Raymundo Belleza, R.; de Freitas Pignaton, E. Performance study of real-time operating systems for internet of things devices. IET Software 2018, 12, 176–182. [Google Scholar] [CrossRef]
- Yang, C.F.; Shinjo, Y. Obtaining hard real-time performance and rich Linux features in a compounded real-time operating system by a partitioning hypervisor. In Proceedings of the Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, 2020; pp. 59–72.
- Adam, G.K.; Petrellis, N.; Doulos, L.T. Performance assessment of linux kernels with PREEMPT_RT on ARM-based embedded devices. Electronics 2021, 10, 1331. [Google Scholar] [CrossRef]
- Jämbäck, M. Evaluation of Real-Time Linux on RISC-V processor architecture. Master’s thesis, 2022.
- Neuhard, Y. A Comparison of Real-time Operating Systems for Embedded Computing.
- Qutqut, M.H.; Al-Sakran, A.; Almasalha, F.; Hassanein, H.S. Comprehensive survey of the IoT open-source OSs. IET Wireless Sensor Systems 2018, 8, 323–339. [Google Scholar] [CrossRef]
- Shammar, E.A.; Zahary, A.T. The Internet of Things (IoT): a survey of techniques, operating systems, and trends. Library Hi Tech 2020, 38, 5–66. [Google Scholar] [CrossRef]
- Abbott, D. Linux for embedded and real-time applications. Elsevier, 2011. [Google Scholar]
- Litayem, N.; Saoud, S.B. Impact of the Linux real-time enhancements on the system performances for multi-core intel architectures. International Journal of Computer Applications 2011, 17, 17–23. [Google Scholar] [CrossRef]
- Delgado, R.; Choi, B.W. New insights into the real-time performance of a multicore processor. IEEE Access 2020, 8, 186199–186211. [Google Scholar] [CrossRef]
- Venkataraman, A.; Jagadeesha, K.K. Evaluation of inter-process communication mechanisms. Architecture 2015, 86, 64. [Google Scholar]
- Alagalla, A.; Rajapaksha, U.S. Techniques of Enhancing Synchronization Efficiency of Distributed Real Time Operating Systems. In Proceedings of the 2022 2nd International Conference on Advanced Research in Computing (ICARC). IEEE; 2022; pp. 308–313. [Google Scholar]
- Silva, M.; Cerdeira, D.; Pinto, S.; Gomes, T. Operating systems for Internet of Things low-end devices: Analysis and benchmarking. IEEE Internet of Things Journal 2019, 6, 10375–10383. [Google Scholar] [CrossRef]
- Kerrisk, M. The Linux programming interface: a Linux and UNIX system programming handbook; No Starch Press, 2010.
- Alonso, S.; Lázaro, J.; Jiménez, J.; Bidarte, U.; Muguira, L. Evaluating latency in multiprocessing embedded systems for the smart grid. Energies 2021, 14, 3322. [Google Scholar] [CrossRef]
- Delgado, R.; Choi, B.W.; Song, H. Application of etherCAT in microgrid communication network: a case study. In Proceedings of the 2018 International Conference on Platform Technology and Service (PlatCon). IEEE; 2018; pp. 1–6. [Google Scholar]
- Delgado, R.; Hong, C.H.; Shin, W.C.; Choi, B.W. Implementation and performance analysis of an EtherCAT Master on the latest real-time embedded Linux. International Journal of Applied Engineering Research 2015, 10, 44603–44609. [Google Scholar]
- Cho, S.Y.; Delgado, R.; Choi, B.W. Feasibility Study for a Python-Based Embedded Real-Time Control System. Electronics 2023, 12, 1426. [Google Scholar] [CrossRef]
- Tadese, M.; Pico, N.; Seo, S.; Moon, H. A Two-Step Method for Dynamic Parameter Identification of Indy7 Collaborative Robot Manipulator. Sensors 2022, 22, 9708. [Google Scholar] [CrossRef] [PubMed]
Figure 1.
Diagram for measuring the real-time performance of the ITC mechanism on FreeRTOS
Figure 1.
Diagram for measuring the real-time performance of the ITC mechanism on FreeRTOS
Figure 2.
The result of response time of queue on FreeRTOS
Figure 2.
The result of response time of queue on FreeRTOS
Figure 3.
The result of response time of stream buffer on FreeRTOS
Figure 3.
The result of response time of stream buffer on FreeRTOS
Figure 4.
The result of response time of message buffer on FreeRTOS
Figure 4.
The result of response time of message buffer on FreeRTOS
Figure 5.
The result of response time of semaphores and mutex on FreeRTOS
Figure 5.
The result of response time of semaphores and mutex on FreeRTOS
Figure 6.
Diagram for measuring the real-time performance of the ITC mechanism on Preempt-RT
Figure 6.
Diagram for measuring the real-time performance of the ITC mechanism on Preempt-RT
Figure 7.
The result of response time of pipe on Preempt-RT
Figure 7.
The result of response time of pipe on Preempt-RT
Figure 8.
The result of response time of FIFO on Preempt-RT
Figure 8.
The result of response time of FIFO on Preempt-RT
Figure 9.
The result of response time of message queue on Preempt-RT
Figure 9.
The result of response time of message queue on Preempt-RT
Figure 10.
The result of response time of semaphore and mutex on Preempt-RT
Figure 10.
The result of response time of semaphore and mutex on Preempt-RT
Figure 11.
boxplot of cyclictest results on Preempt-RT
Figure 11.
boxplot of cyclictest results on Preempt-RT
Figure 12.
Motion Control with Indy7 Collaborative Robot.
Figure 12.
Motion Control with Indy7 Collaborative Robot.
Figure 13.
Architecture of the EtherCAT network with Preempt-RT for Motion Control
Figure 13.
Architecture of the EtherCAT network with Preempt-RT for Motion Control
Figure 14.
Motion Control Application Architecture
Figure 14.
Motion Control Application Architecture
Figure 15.
real-time performance results on collaborative robot with VisionFive 2
Figure 15.
real-time performance results on collaborative robot with VisionFive 2
Figure 16.
real-time performance results on collaborative robot with MIO-5272
Figure 16.
real-time performance results on collaborative robot with MIO-5272
Table 1.
specifications of the boards using FreeRTOS
Table 1.
specifications of the boards using FreeRTOS
Hardware |
Microcontroller Unit |
Architecture |
RTOS |
kernel version |
HiFive1 Rev B |
SiFive FE310-G002 32-bit |
RISC-V RV32IMAC |
FreeRTOS |
10.2.0 |
STM3240G-EVAL |
STM32F407IGH6 with ARM Cortex-M4F 32-bit |
ARMv7-M |
FreeRTOS |
10.2.0 |
Table 2.
specifications of the boards using PremptRT
Table 2.
specifications of the boards using PremptRT
Hardware |
Microporcessor Unit |
Architecture |
Real Time Kernel |
kernel version |
VisionFive 2 |
JH7110 64-bit quad-core |
RISC-V U74-MC |
Preempt-RT |
5.15.0-rt17+ |
Raspberry Pi 4 B |
Broadcom BCM2711 ARM Cortex-A72 64-bit quad-core |
ARMv8-A |
Preempt-RT |
5.15.92-rt57-v8+ |
MIO-5272 |
Intel Core I7 6600U |
x86-64 |
Preempt-RT |
5.15.79-rt54 |
Table 3.
results of response time of semaphores and mutex including FreeRTOS V10.4.4
Table 3.
results of response time of semaphores and mutex including FreeRTOS V10.4.4
|
HiFive1 Rev B (10.2.0) |
STM3240G-EVAL (10.2.0) |
STM3240G-EVAL (10.4.4) |
ITC |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Counting Semaphore |
4.74 |
4.73 |
4.74 |
0.004 |
12.64 |
12.63 |
12.64 |
0.003 |
12.39 |
12.39 |
12.40 |
0.002 |
Mutex |
4.90 |
4.73 |
4.95 |
0.037 |
13.68 |
13.12 |
13.73 |
0.1 |
13.51 |
13.50 |
13.52 |
0.004 |
Binary Semaphore |
4.68 |
4.65 |
4.73 |
0.019 |
27.97 |
0.07 |
334.71 |
68.8 |
12.50 |
12.50 |
12.51 |
0.002 |
Table 4.
Results of real -time performance metric of semaphore and mutex on Preempt-RT
Table 4.
Results of real -time performance metric of semaphore and mutex on Preempt-RT
|
VisionFive 2 |
Raspberry Pi 4 B |
MIO-5272 |
ITC |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Mean (us) |
Min (us) |
Max (us) |
Sdev (us) |
Semaphore |
10.84 |
10.5 |
63.3 |
0.47 |
18.29 |
17.19 |
82.85 |
1.94 |
4.92 |
3.82 |
83.52 |
0.24 |
Mutex |
10.01 |
9.75 |
47.00 |
0.43 |
18.11 |
16.76 |
259.74 |
1.98 |
4.90 |
3.75 |
712.10 |
1.69 |
Table 6.
Configuration and Response Time Result of Motion Control Tasks
Table 6.
Configuration and Response Time Result of Motion Control Tasks
Task |
Response time (us) |
Period (ms) |
Priority |
|
VisionFive 2 |
MIO-5272 |
|
|
Dynamic Task |
112.71 |
95.89 |
1 |
95 |
Main Task |
292.14 |
152.99 |
1 |
90 |
Trajectory Task |
319.04 |
159.97 |
2 |
85 |
Log Task |
329.50 |
164.08 |
100 |
70 |
|
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2024 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).