Data communication method and system between software based on real-time system and shared memory

Abstract

The invention provides an inter-software data communication method and system based on a real-time system and a shared memory, and relates to the technical field of computer data communication. The method comprises the steps that under the condition that queue creation is successful, data are written into a queue through a second operating system, and mutual exclusion is in an occupied state when the queue is in the data writing period so that a first operating system cannot operate the queue; and sending the semaphore to the first operating system through the second operating system so as to enable the first operating system to read the data written in the queue, wherein the mutual exclusion quantity is in a non-occupied state when the semaphore is sent so as to enable the first operating system to read the data written in the queue. The high efficiency of data transmission can be effectively improved, so that the requirement of an RTX real-time operating system for high-efficiency data transmission is met, meanwhile, data can be cached to avoid data loss, and the situation of data transmission errors can be avoided by setting the semaphore and the mutual exclusion quantity.

Description

Technical Field

[0001] The present invention relates to the field of computer data communication technology, and in particular, to a method and system for data communication between software based on a real-time system and shared memory. Background Art

[0002] At present, the software developed in the RTX real-time operating system has the advantages of high response performance and high processing performance. However, the software developed by the RTX real-time operating system often lacks a human-computer interaction interface. Therefore, the RTX real-time operating system, as a lower computer, processes and calculates, and usually uses other software under the Windows system to develop the upper computer for human-computer interaction and other functions. The data transmission between the upper computer and the lower computer often uses shared memory, which is convenient for the RTX real-time operating system to obtain data in real time and also convenient for the RTX real-time operating system to transmit data to the Windows system. Since the simple use of shared memory may cause the old data to be overwritten by the new data before it can be retrieved, the stability of ordinary stacks and queues in multi-threaded and real-time systems is not high, and the transmission thread and the reading thread in multi-threaded programming occupy a large amount of system resources, which may affect the stability of the RTX real-time system. At the same time, there are many development platforms for the Windows system, and the languages ​​used by different platforms are also different, which makes adaptation difficult. Summary of the invention

[0003] The purpose of this specification is to provide a method for data communication between software based on real-time system and shared memory, which can overcome the above-mentioned defects of the existing communication method between RTX real-time operating system and windows system software.

[0004] The embodiments of this specification are implemented as follows:

[0005] On the one hand, this specification provides a method for data communication between software based on a real-time system and shared memory, mainly including:

[0006] Creating a queue, a semaphore and a mutex in the memory of the first operating system respectively, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas;

[0007] Under the condition that the queue is successfully created, data is written into the queue through the second operating system, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue;

[0008] After the queue data is written, the semaphore is sent to the first operating system through the second operating system so that the first operating system can read the data written in the queue. The mutex is in a non-occupied state when the semaphore is sent so that the first operating system can read the data written in the queue.

[0009] On the other hand, this specification provides a data communication system between software based on a real-time system and shared memory, mainly including:

[0010] A creation module, used to create a queue, a semaphore and a mutex respectively in the memory of the first operating system, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas;

[0011] A writing module, used for writing data into the queue through the second operating system under the condition that the queue is successfully created, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue;

[0012] A reading module is used to send the semaphore to the first operating system through the second operating system after the queue data is written so that the first operating system can read the data written in the queue, and the mutex is in a non-occupied state when sending the semaphore so that the first operating system can read the data written in the queue.

[0013] The embodiments of this specification have at least the following advantages or beneficial effects:

[0014] This method for inter-software data communication based on real-time system and shared memory opens up a shared memory space, i.e., a queue, through a first operating system, and stores real-time or required data in the queue through a second operating system. The queue enables the first operating system to read the data in the queue in an orderly manner, which can effectively improve the efficiency of data transmission, thereby meeting the requirements of the RTX real-time operating system for efficient data transmission. Moreover, the use of the queue can ensure data transmission efficiency while caching data to avoid data loss. In addition, data transmission errors can be avoided by setting semaphores and mutexes. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present specification and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0016] Figure 1 A flowchart of a method for data communication between software based on a real-time system and shared memory provided in this specification;

[0017] Figure 2 Another flowchart of the method for data communication between software based on real-time system and shared memory provided in this specification;

[0018] Figure 3 A schematic diagram of a process of the second operating system provided in this specification writing data into the queue;

[0019] Figure 4 A schematic diagram of a process of the first operating system reading data in the queue provided in this specification;

[0020] Figure 5 A schematic diagram of a data communication system between software based on a real-time system and shared memory provided in this manual. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solutions and advantages of the embodiments of this specification more clear, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are part of the embodiments of this specification, not all of the embodiments. Generally, the components of the embodiments of this specification described and shown in the drawings here can be arranged and designed in various different configurations.

[0022] Please refer to Figures 1 to 4 An embodiment of the present specification provides a method for data communication between software based on a real-time system and a shared memory, mainly comprising:

[0023] Step 102: Create a queue, a semaphore and a mutex in the memory of the first operating system respectively, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas;

[0024] Step 104: under the condition that the queue is successfully created, data is written into the queue through the second operating system, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue;

[0025] Step 106: After the queue data is written, the semaphore is sent to the first operating system through the second operating system so that the first operating system can read the data written in the queue. The mutex is in a non-occupied state when the semaphore is sent so that the first operating system can read the data written in the queue.

[0026] In this embodiment, the first operating system may preferably be a Windows operating system, and the second operating system may preferably be an RTX real-time operating system.

[0027] In this embodiment, the code of the above method is developed based on C language, so that the above method is applicable to RTX real-time operating system and Windows operating system, and can also be adapted to other various platforms. It can be seen that the above method can effectively improve the applicability of the above method.

[0028] Specifically, the above method opens up a shared memory space, namely, a queue, through the first operating system, and uses the second operating system to store real-time or required data in the queue. The queue method enables the first operating system to read the data in the queue in an orderly manner, which can effectively improve the efficiency of data transmission, thereby meeting the requirements of the RTX real-time operating system for efficient data transmission. Moreover, the use of the above queue method can ensure data transmission efficiency while caching data to avoid data loss. In addition, data transmission errors can be avoided by setting semaphores and mutexes.

[0029] In this embodiment, the first operating system and the second operating system may be deployed in the same system, or in two independent systems, and both may achieve the above-mentioned data communication effect.

[0030] In this embodiment, according to multi-threaded programming, by setting the above-mentioned semaphore, if the first operating system does not receive the semaphore sent by the second operating system, the first operating system cannot read the data in the above-mentioned queue, thereby achieving the effect of preventing system resources from being occupied.

[0031] In this embodiment, the same queue can be accessed and used by multiple software, systems and programs, and has good versatility.

[0032] In this embodiment, the queue, the semaphore and the mutex correspond to independent fixed-size memory areas determined according to the data volume requirement. Specifically, the size of the memory area corresponding to the queue can be determined according to the data volume.

[0033] In this embodiment, one implementation of step 102 is specifically as follows:

[0034] Step 112: Create a memory area of ​​a specific size in the memory of the first operating system as a queue;

[0035] Step 114, assigning a unique and independent name and identifier to the queue;

[0036] Step 116: creating another independent memory area in the first operating system memory as a semaphore;

[0037] Step 118, assigning a unique and independent name and identifier to the semaphore;

[0038] Step 120: creating another independent memory area in the first operating system memory as a mutex;

[0039] Step 122: assign a unique and independent name and identifier to the mutex, wherein the mutex is used in multiple threads and enables only one thread to read the data in the queue at a time, and the first operating system is one thread in the multiple threads.

[0040] In this embodiment, the above-mentioned queues, semaphores and mutexes are the same group. The above-mentioned queues have unique names and identifiers to facilitate indexing and searching for memory addresses corresponding to the above-mentioned queues. The above-mentioned semaphores and the above-mentioned mutexes have unique names and identifiers respectively, which can avoid confusion between semaphores and mutexes of each group of queues, thereby avoiding data transmission errors.

[0041] In this embodiment, before step 104, the following steps are also included:

[0042] Step 132: Determine whether the queue is successfully created through the first operating system;

[0043] Step 134: If successful, assign the identifier corresponding to the queue to a first specific value;

[0044] Step 136: If not, assign the identifier corresponding to the queue to a second specific value.

[0045] In this embodiment, when the queue is created successfully, the queue corresponding identifier is assigned a value of 1, and when the queue is created unsuccessfully, the queue corresponding identifier is assigned a value of 0, so as to determine whether to write data into the queue.

[0046] In this embodiment, the above queue is a communication message queue.

[0047] In this embodiment, the queue can be created by the first operating system.

[0048] In this embodiment, after step 132, the following steps are also included:

[0049] Step 142: Use the second operating system to index the memory address corresponding to the queue using the name of the queue;

[0050] Step 144: Determine, by the second operating system, whether the identifier corresponding to the queue is the first specific value;

[0051] Step 146: If yes, allow the writing of data into the queue through the second operating system to be executed.

[0052] In this embodiment, if the second operating system determines that the identifier corresponding to the queue is the first specific value, the queue is created successfully, and the second operating system can open the memory address of the queue and write data into the queue, that is, write the data into a specific memory area.

[0053] In this embodiment, one implementation of step 104 is specifically as follows:

[0054] Step 152: determining, by the second operating system, whether the mutex is in an occupied state;

[0055] Step 154: If not, write the data into the queue through the second operating system;

[0056] Step 156: Adjust the mutex to an occupied state until the queue completes writing data.

[0057] In this implementation, adjusting the mutex to an occupied state when writing data can prevent the first operating system from performing any operations on the current queue during the writing process, thereby preventing the current queue from being interfered with by other threads and avoiding data transmission errors, thereby improving data transmission efficiency.

[0058] In this embodiment, one implementation of step 106 is specifically as follows:

[0059] Step 162: Determine whether the first operating system receives the semaphore;

[0060] Step 164: If received, determine whether the mutex is in an occupied state through the first operating system;

[0061] Step 166: If the mutex is in a non-occupied state, the data written in the queue is read through the first operating system;

[0062] Step 168: When the first operating system reads the data written in the queue, the mutex is adjusted to an occupied state.

[0063] In this embodiment, if the first operating system does not currently receive the semaphore, the first operating system is in a waiting state.

[0064] In this embodiment, the second operating system sends the semaphore to the first operating system, indicating that there is data in the queue and can be read.

[0065] In this embodiment, if the first operating system determines that the mutex is in an occupied state, it indicates that an error or anomaly occurs in the current queue and data reading operations cannot be performed. It can be seen that the above can effectively avoid the occurrence of data reading errors.

[0066] In this embodiment, after the first operating system reads the data in the queue, the mutex may be adjusted to a non-occupied state so that other threads can continue to operate the queue.

[0067] In this embodiment, another implementation of step 102 is specifically as follows:

[0068] Step 172: Create multiple groups of queues in the memory of the first operating system, and set semaphores and mutexes for each group of queues respectively. The identifiers corresponding to each group of queues are different, the identifiers corresponding to each group of semaphores are different, and the identifiers corresponding to various mutexes are different.

[0069] In this embodiment, each group of queues can exist at the same time and can be used together, independently of each other and without interfering with each other.

[0070] In this embodiment, the number of times the data in the queue is read is determined according to the number of times the data is written into the queue.

[0071] In this embodiment, data written into the queue can be written continuously, and old data will be cached in the queue.

[0072] Please refer to Figure 5 Another embodiment of the present specification provides a data communication system between software based on a real-time system and a shared memory, mainly comprising:

[0073] A creation module 202, configured to respectively create a queue, a semaphore and a mutex in the memory of the first operating system, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas;

[0074] A writing module 204, configured to write data into the queue through the second operating system under the condition that the queue is successfully created, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue;

[0075] The reading module 206 is used to send the semaphore to the first operating system through the second operating system after the queue data is written so that the first operating system can read the data written in the queue. The mutex is in a non-occupied state when sending the semaphore so that the first operating system can read the data written in the queue.

[0076] Specifically, the above method opens up a shared memory space, namely, a queue, through the first operating system, and uses the second operating system to store real-time or required data in the queue. The queue method enables the first operating system to read the data in the queue in an orderly manner, which can effectively improve the efficiency of data transmission, thereby meeting the requirements of the RTX real-time operating system for efficient data transmission. Moreover, the use of the above queue method can ensure data transmission efficiency while caching data to avoid data loss. In addition, data transmission errors can be avoided by setting semaphores and mutexes.

[0077] In this embodiment, the creation module 202 is used to create a memory area of ​​a specific size on the memory of the first operating system as a queue; assign a unique and independent name and identifier to the queue; create another independent memory area on the memory of the first operating system as a semaphore; assign a unique and independent name and identifier to the semaphore; create another independent memory area on the memory of the first operating system as a mutex; assign a unique and independent name and identifier to the mutex, the mutex is used in multi-threading, the mutex enables only one thread to read the data in the queue at the same time, and the first operating system is a thread in the multi-threading. The above-mentioned queue, semaphore and mutex are the same group, the above-mentioned queue has a unique name and identifier, so as to facilitate indexing and searching the memory address corresponding to the above-mentioned queue, the above-mentioned semaphore and the above-mentioned mutex have unique names and identifiers respectively, which can avoid confusion between semaphores and mutexes of each group of queues, thereby avoiding data transmission errors.

[0078] In this embodiment, the write module 204 is used to determine whether the queue is successfully created through the first operating system; if successful, the identifier corresponding to the queue is assigned to a first specific value; if not, the identifier corresponding to the queue is assigned to a second specific value. The second operating system uses the name of the queue to index the memory area corresponding to the queue; the second operating system determines whether the identifier corresponding to the queue is the first specific value; if so, the writing of data to the queue through the second operating system is allowed to be executed. The second operating system determines whether the mutex is in an occupied state; if not, the data is written to the queue through the second operating system; the mutex is adjusted to an occupied state until the data writing to the queue is completed. Adjusting the mutex to an occupied state when writing data can prevent the first operating system from performing any operations on the current queue during the writing process, thereby preventing the current queue from being interfered with by other threads and avoiding data transmission errors, thereby improving data transmission efficiency.

[0079] In this embodiment, the reading module 206 is used to determine whether the first operating system has received the semaphore; if received, the first operating system determines whether the mutex is in an occupied state; if the mutex is in a non-occupied state, the first operating system reads the data written in the queue; when the first operating system reads the data written in the queue, the mutex is adjusted to an occupied state. Multiple groups of queues are created in the memory of the first operating system, and each group of queues corresponds to a semaphore and a mutex, and the identifiers corresponding to each group of queues are different, the identifiers corresponding to each group of semaphores are different, and the identifiers corresponding to various mutexes are different. If the above-mentioned first operating system determines that the mutex is in an occupied state, it indicates that an error or anomaly occurs in the current queue, and data reading operations cannot be performed. It can be seen that the above-mentioned data reading errors can be effectively avoided.

[0080] Based on the same invention, another embodiment of the present specification further provides a computer-readable storage medium, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including multiple application programs, the electronic device executes Figure 1 The corresponding embodiment provides a method for data communication between software based on a real-time system and shared memory.

[0081] In this specification, each embodiment is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0082] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0083] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, this specification may be in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, this specification may be in the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0084] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that has the function specified in a box.

[0085] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0086] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0087] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0088] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0089] The above is only an embodiment of the present application and is not intended to limit this specification. For those skilled in the art, this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification should be included in the scope of the claims of this specification.

Claims

1. A method for inter-software data communication based on a real-time system and shared memory, used for a first operating system and a second operating system, characterized in that: include: Creating a queue, a semaphore and a mutex in the memory of the first operating system respectively, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas; Under the condition that the queue is successfully created, data is written into the queue through the second operating system, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue; After the queue data is written, the semaphore is sent to the first operating system through the second operating system so that the first operating system can read the data written in the queue. The mutex is in a non-occupied state when the semaphore is sent so that the first operating system can read the data written in the queue.

2. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: The queue, the semaphore and the mutex correspond to independent fixed-size memory areas determined according to data volume requirements.

3. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: The creating a queue, a semaphore and a mutex respectively in the memory of the first operating system comprises: Creating a memory area of ​​a specific size in the memory of the first operating system as a queue; assigning a unique and independent name and identity to said queue; Another independent memory area in the first operating system memory is created as a semaphore; assigning a unique and independent name and identifier to said semaphore; Another independent memory area in the first operating system memory is created as a mutex; A unique and independent name and identifier are assigned to the mutex, the mutex is used in multiple threads, the mutex enables only one thread to read the data in the queue at the same time, and the first operating system is one thread in the multiple threads.

4. The method for data communication between software based on real-time system and shared memory according to claim 3, characterized in that: Under the condition that the queue is successfully created, before the second operating system writes data into the queue, the method further includes: Determining whether the queue is successfully created by the first operating system; If successful, assigning the identifier corresponding to the queue to a first specific value; If not, the identifier corresponding to the queue is assigned a second specific value.

5. The method for data communication between software based on real-time system and shared memory according to claim 4, characterized in that: After determining whether the queue is successfully created by the first operating system, the method further includes: Using the second operating system to index the memory address corresponding to the queue by the name of the queue; Determining, by the second operating system, whether the identifier corresponding to the queue is the first specific value; If so, the step of writing data into the queue through the second operating system is allowed to be executed.

6. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: The step of writing data into the queue by the second operating system under the condition that the queue is successfully created includes: Determining, by the second operating system, whether the mutex is in an occupied state; If not, writing the data into the queue through the second operating system; The mutex is adjusted to an occupied state until the data writing to the queue is completed.

7. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: After the writing of the queue data is completed, sending the semaphore to the first operating system through the second operating system so that the first operating system can read the data written in the queue includes: Determining whether the first operating system receives the semaphore; If received, determining whether the mutex is in an occupied state through the first operating system; If the mutex is in a non-occupied state, reading the data written in the queue through the first operating system; When the first operating system reads the data written in the queue, the mutex is adjusted to an occupied state.

8. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: The creating a queue, a semaphore and a mutex respectively in the memory of the first operating system comprises: Multiple groups of queues are created in the memory of the first operating system, and semaphores and mutexes are set corresponding to each group of queues. The identifiers corresponding to each group of queues are different, the identifiers corresponding to each group of semaphores are different, and the identifiers corresponding to various mutexes are different.

9. The method for data communication between software based on real-time system and shared memory according to claim 1, characterized in that: The number of times data in the queue is read is determined according to the number of times data is written into the queue.

10. A data communication system between software based on real-time system and shared memory, characterized in that: include: A creation module, used to create a queue, a semaphore and a mutex respectively in the memory of the first operating system, wherein the queue, the semaphore and the mutex correspond to independent fixed-size memory areas; A writing module, used for writing data into the queue through the second operating system under the condition that the queue is successfully created, and the mutex is in an occupied state during the period when the queue is writing data so that the first operating system cannot operate the queue; A reading module is used to send the semaphore to the first operating system through the second operating system after the queue data is written so that the first operating system can read the data written in the queue, and the mutex is in a non-occupied state when sending the semaphore so that the first operating system can read the data written in the queue.

Images