Method and medium for interface conversion from a vxworks system to an embedded linux system

Abstract

The application provides a method and medium for interface conversion from a VxWorks system to an embedded Linux system, which comprises: constructing a compatible layer in a user state, rewriting key system function APIs of the VxWorks, such as task management, message queue, semaphore and watchdog, and calling Linux native system functions or implementing corresponding logic by itself in the internal, and finally compiling the implementation code into a static library or a dynamic library. An application program only needs to link the library and include the corresponding header file, so as to be compiled and run in the embedded Linux system without modifying the core source code. The application realizes seamless transplantation in the user state without modifying the operating system kernel and configuration, significantly reduces the transplantation cost and system stability risk, and is suitable for various deployed Linux environments.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically, to an interface conversion method and medium for converting VxWorks systems to embedded Linux systems. Background Technology

[0002] VxWorks is an embedded real-time operating system (RTOS) widely used in aerospace, industrial, automotive, and military fields due to its excellent real-time performance, high reliability, and high customizability. With the improvement of embedded platform CPU performance, the real-time design of the operating system is no longer a bottleneck in most application scenarios. Linux, with its open-source nature, strong customizability, extensive hardware support, rich software ecosystem, and excellent memory isolation mechanisms, is increasingly being used in more and more fields.

[0003] Because the system function APIs provided by the two operating systems are different, even applications developed using the same standard C / C++ cannot be seamlessly ported from VxWorks to Linux. Therefore, designing an interface conversion method for VxWorks systems to embedded Linux systems to reduce the difficulty of porting is of great significance.

[0004] Existing technologies related to this application include Xenomai, which provides a VxWorks skin or alchemy skin to enable the porting of VxWorks to Linux. However, this requires patching the kernel with Xenomai and enabling necessary configurations, thus preventing its use on already deployed Linux systems. Furthermore, the API naming and header files of the alchemy skin differ from VxWorks system functions, hindering seamless user-mode porting. Additionally, some technologies are based on kernel-mode emulation, but modifications to the kernel may introduce stability issues.

[0005] In summary, existing technical solutions have significant shortcomings in reducing portability costs, maintaining non-intrusive user-mode deployment, and ensuring system stability. Therefore, an innovative solution is urgently needed. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide an interface conversion method and medium for converting VxWorks systems to embedded Linux systems.

[0007] An interface conversion method for VxWorks system to embedded Linux system provided by the present invention includes the following steps: A user-space compatibility layer is created to convert the system function APIs called by VxWorks applications into calls supported by the embedded Linux system. The compatibility layer is implemented by rewriting the VxWorks system function APIs and internally calling Linux system functions or implementing the corresponding functions itself. The rewritten source code is compiled into a library file, and a header file corresponding to VxWorks is provided; this allows VxWorks applications to be compiled and run on embedded Linux systems without modifying the core code by including the header file and linking the library file.

[0008] Preferably, the rewriting of VxWorks system function APIs includes rewriting the APIs of the task maintenance module, including: The taskSpawn function is overridden, which internally creates a new thread by calling the pthread_create function and manages the task description information; Override the taskDelete function, which internally cancels the specified thread by calling the pthread_cancel function; Rewrite the taskDelay function, which internally uses the usleep function to delay the task.

[0009] Preferably, the rewriting of the taskSpawn function includes: Establish a global task mapping table to store task IDs, names, and priority information; Before creating a new task, duplicates are checked in the global task mapping table based on the ID and name. If no duplicate is found, pthread_create is called to create a thread, and the thread information is inserted into the global task mapping table. After configuring the signal mask and separation attribute of the thread, the passed-in task routine is executed.

[0010] Preferably, the rewriting of VxWorks system function APIs includes rewriting the message queue module API, including: Override the msgQCreate function to create a message queue structure containing a message container, condition variables, and a mutex lock. Rewrite the msgQSend function, which internally constructs the data to be sent into a message, inserts it into a message container of the corresponding priority, and notifies the receiving thread by releasing a semaphore. Override the msgQReceive function, which internally retrieves a message from the highest priority message container based on the waiting strategy and copies the data to the specified memory. Override the msgQDelete function to release the resources occupied by the message queue; Rewrite the msgQNumMsgs function to calculate and return the total number of messages currently in the message queue.

[0011] Preferably, the rewriting of VxWorks system function APIs includes rewriting the semaphore module APIs, including: Rewrite the semBCreate and semCCreate functions, which internally call the sem_init function to create POSIX semaphores; Rewrite the semMCreate function, which internally calls the pthread_mutex_init function to create a mutex lock; Rewrite the semGive function, and internally call either the sem_post function or the pthread_mutex_unlock function, depending on the semaphore type. Rewrite the semTake function and, depending on the semaphore type and the waiting parameters, internally choose to call pthread_mutex_lock, sem_wait, sem_trywait, or a timed polling function; Override the semDelete function to destroy semaphores or mutexes.

[0012] Preferably, the rewriting of VxWorks system function APIs includes rewriting the watchdog module API, including: Override the wdCreate function to create a watchdog descriptor and register it to the global watchdog mapping table; Create a separate timer thread that periodically traverses the global watchdog mapping table and executes the registered callback function for watchdogs that have reached their timeout period. Override the wdStart function to start or reset the timeout and callback function of the specified watchdog timer; Override the wdCancel function to stop the specified watchdog timer; Override the wdDelete function to delete the specified watchdog from the global watchdog mapping table and release the resources.

[0013] Preferably, the library file is a static library or a dynamic library.

[0014] According to the present invention, a computer-readable storage medium is provided thereon storing a computer program, which, when executed by a processor, implements the interface conversion method for VxWorks system to embedded Linux system.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention provides a user-space compatibility layer that is fully compatible with the VxWorks system API, enabling applications developed for VxWorks to be ported to embedded Linux systems without modifying their core business logic code. Developers only need to link the library files provided by this invention during the compilation stage to complete cross-platform compilation, which greatly saves manpower and time costs and simplifies the porting process.

[0016] 2. All interface conversion functions of this invention are implemented in user space, without modifying the operating system kernel, thus avoiding the risk of system crashes caused by kernel code defects and ensuring high stability and reliability of the ported software.

[0017] 3. This invention does not depend on a specific Linux kernel configuration or version, and requires no pre-configuration or customization of the target Linux system. Therefore, it can be widely applied to various pre-deployed commercial or open-source embedded Linux distributions. Attached Figure Description

[0018] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a general framework diagram of an embodiment of the present invention; Figure 2 This is a schematic diagram of the taskSpawn process according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the taskDelete process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the msgQCreate process according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the msgQDelete process according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the msgQSend process according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the msgQReceive process according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the semaphore creation process according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the semGive process according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the semTake process according to an embodiment of the present invention; Figure 11 This is a view of the wdCreate process in an embodiment of the present invention; Figure 12This is a schematic diagram of the watchdog timer thread flow according to an embodiment of the present invention. Detailed Implementation

[0019] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0020] Application implementation typically requires calling a series of system functions provided by the operating system kernel. These system functions are implemented in the kernel and made available to users through API interfaces. The system functions in VxWorks and Linux are implemented in different ecosystems, and their usage and functionality differ. For example... Figure 1 As shown, this method creates a compatibility layer that implements commonly used VxWorks system function APIs that differ from Linux. Internally, it calls Linux system functions to implement task maintenance, message queues, semaphores, and watchdog timer functionalities. Figure 1 As shown.

[0021] This method includes the following steps: Step 1: Rewrite the task maintenance module; In VxWorks, multithreaded programming is accomplished through tasks, which are the basic unit of system scheduling. Each task is defined by a set of data structures, including the task name, priority, status, stack information, task routine, and execution context, all of which are stored in the Task Control Block (TCB). Commonly used task-related system functions are shown in the table below.

[0022] Table 1 VxWorks Task-Related Interface Functions

[0023] In Linux, a thread is the smallest unit of system scheduling and can be used to perform VxWorks tasks. Commonly used task-related system functions are shown in the table below.

[0024] Table 2 Linux Task-Related Interface Functions

[0025] This method rewrites APIs such as taskSpawn, taskDelete, and taskDelay, and internally calls related pthread functions.

[0026] In one specific implementation, step 1 includes the following steps: Step 1.1: Rewrite the taskSpawn interface; Create a task and specify its name, priority, stack size, and task routine. This method designs a `taskSpawn` function for processing tasks of the same priority, such as... Figure 2 As shown.

[0027] First, a task description table is created to store information such as the ID, name, and priority of each task. Then, a duplicate check is performed based on the ID and name to determine if the task already exists. If no duplicates are found, `pthread_create` is called to create a new thread, which is then inserted and stored in the global thread mapping table. Before the thread runs, its signal mask needs to be configured and its detached attribute needs to be set. Finally, the task pointer passed in when the task was created is called.

[0028] Step 1.2: Override the taskDelete interface First, the thread is located in the global thread table by its ID. Then, `pthread_cancel` is called to cancel the thread. Finally, the thread is removed from the global thread table. Figure 3 As shown.

[0029] Step 1.3: Rewrite the taskDelay interface Call the usleep function to schedule tasks.

[0030] Step 2: Rewrite the message queue module; VxWorks provides message queue functionality. A message queue is a buffer-like object that improves the reliability of data communication between tasks. Tasks can send and receive data through message queues, thereby achieving data synchronization and communication between tasks. Commonly used message queue-related system functions are shown in the table below.

[0031] Table 3 VxWorks Message Queue Related Interface Functions

[0032] In Linux, there is no message queue mechanism provided between threads. This method rewrites the APIs such as msgQCreate, msgQDelete, msgQSend, msgQReceive, and msgQNumMsgs, and internally designs a message queue mechanism based on containers and condition variables.

[0033] In one specific implementation, step 2 includes the following steps: Step 2.1: Rewrite the msgQCreate interface; Create a message queue descriptor, condition variable, mutex lock, and a list to store messages. For example... Figure 4 As shown Step 2.2: Rewrite the msgQDelete interface; Release the requested message queue resources. For example... Figure 5 As shown.

[0034] Step 2.3: Rewrite the msgQSend interface; The message queue address is located based on the message queue descriptor. The data to be sent is constructed into a new message, inserted into the list of the corresponding priority, and the semaphore is released to notify the thread calling msgQReceive to receive the message. For example... Figure 6 As shown.

[0035] Step 2.4: Rewrite the msgQReceive interface First, check if there are any messages in each priority message queue. If so, immediately retrieve the highest priority data. If not, determine if waiting is necessary. If no waiting is needed, exit immediately. If waiting indefinitely, block until data is received. If waiting periodically, check the message queue semaphore every 5 milliseconds to see if it has been released. When a semaphore is released and messages can be received, pop a message from the highest priority list and copy the data stored in the message to the memory pointed to by the passed pointer. For example... Figure 7 As shown.

[0036] Step 2.5: Rewrite the msgQNumMsgs interface Calculates and returns the total number of current elements across all lists.

[0037] Step 3: Rewrite the semaphore module; The semaphores commonly used in VxWorks systems can be mainly divided into three types: atoms, mutexes, and counters, used for signal transmission between tasks and resource synchronization protection under race conditions. The commonly used semaphore-related system functions are shown in the table below.

[0038] Table 4 VxWorks Semaphore Related Interface Functions

[0039] Linux systems also provide semaphores and mutexes to achieve the same functionality. Commonly used related system functions are shown in the table below.

[0040] Table 5 Linux Semaphore Related Interface Functions

[0041] This method overrides APIs such as semBCreate, semCCreate, semMCreate, semGive, semTake, and semDelete, and internally calls functions related to semaphores and mutexes.

[0042] In one specific implementation, step 3 includes the following steps: Step 3.1: Override the semBCreate, semCCreate, and semMCreate interfaces; `mBCreate` and `semCCreate` are implemented using POSIX semaphores. First, a semaphore descriptor is created to store the semaphore type, mode, and initial parameters. Internally, `sem_init` is called to complete semaphore creation and return the semaphore descriptor. `semMCreate` is implemented using a mutex lock. Internally, `pthread_mutex_init` is called to complete semaphore creation and return the semaphore descriptor. Figure 8 As shown.

[0043] Step 3.2: Rewrite the semGive interface; First, query the type parameter of the semaphore descriptor. Atomic and counting semaphores are implemented using `sem_post`, and mutex semaphores are implemented using `pthread_mutex_unlock`. For example... Figure 9 As shown.

[0044] Step 3.3: Rewrite the semTake interface; First, the type parameter of the semaphore descriptor is queried. For mutex semaphores, `pthread_mutex_lock` is used directly. For atomic or counting semaphores, the semaphore parameter is first obtained. If it's an atomic semaphore, the count is checked. If the count is greater than 1, `sem_trywait` is called to reset the count to 1. Then, it's determined whether waiting is necessary. If no waiting is needed, `sem_trywait` is called and returns a result. If waiting indefinitely, `sem_wait` is called to wait. For timed waiting, `sem_trywait` is called every 5 milliseconds until success is returned or a timeout occurs. Figure 10 As shown.

[0045] Step 4: Rewrite the watchdog module; VxWorks systems commonly use watchdog timers to implement scheduled tasks. The commonly used watchdog-related system functions are shown in the table below.

[0046] Table 6 VxWorks Watchdog Related Interface Functions

[0047] This method implements watchdog management through a timed thread mechanism.

[0048] In one specific implementation, step 4 includes the following steps: Step 4.1: Override the wdCreate interface; Create a watchdog descriptor, assign it an ID number, and insert it into the global watchdog mapping table. For example... Figure 11 As shown.

[0049] Step 4.2: Create a timed thread; The first call to wdCreate creates a timer thread. This timer thread iterates through the watchdog list every 5 milliseconds, stopping when a watchdog reaches its designated time and calling its registered callback function. For example... Figure 12 As shown.

[0050] Step 4.3: Override the wdCreate and wdCancel interfaces; The `wdStart` interface is used to enable or update the watchdog timer. Simply set the start flag to 1 and update the configured timeout and callback function to the global watchdog mapping table. The `wdCancel` interface stops the watchdog timer from starting; simply set the start flag to 0.

[0051] Step 4.4: Rewrite the wdDelete interface; Destroy the watchdog; the middleware removes the watchdog element from the global mapping table and releases its resources.

[0052] Step 5: Compile into a library and provide an API.

[0053] This method compiles the source code into a static or static library, providing header files. Applications can then call the API and link the library files for use. In a preferred embodiment, when porting a VxWorks application to a Linux system, the library compiled using this method is used. The compilation environment includes the path to the header file compiled using this method, and the library is linked during compilation to complete the porting. The compiled executable file can then run on the Linux platform.

[0054] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0055] In the description of this application, it should be understood that the terms "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0056] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for interface conversion from a VxWorks system to an embedded Linux system, characterized in that, Includes the following steps: Create a user-space compatibility layer to translate system function API calls from VxWorks applications into calls supported by the embedded Linux system; The compatibility layer is implemented by rewriting the VxWorks system function API, and internally calls Linux system functions or implements corresponding functions by itself. The rewritten source code is compiled into a library file, and a header file corresponding to VxWorks is provided; this allows VxWorks applications to be compiled and run on an embedded Linux system by including the header file and linking the library file, without modifying the core code.

2. The interface conversion method for VxWorks system to embedded Linux system according to claim 1, characterized in that, The rewriting of VxWorks system function APIs includes rewriting the APIs of the task maintenance module, including: The taskSpawn function is overridden, which internally creates a new thread by calling the pthread_create function and manages the task description information; Override the taskDelete function, which internally cancels the specified thread by calling the pthread_cancel function; Rewrite the taskDelay function, which internally uses the usleep function to delay the task.

3. The interface conversion method for VxWorks system to embedded Linux system according to claim 2, characterized in that, The rewritten taskSpawn function includes: Establish a global task mapping table to store task IDs, names, and priority information; Before creating a new task, duplicates are checked in the global task mapping table based on the ID and name. If no duplicate is found, pthread_create is called to create a thread, and the thread information is inserted into the global task mapping table. After configuring the signal mask and separation attribute of the thread, the passed-in task routine is executed.

4. The interface conversion method for VxWorks system to embedded Linux system according to claim 1, characterized in that, The rewriting of VxWorks system function APIs includes rewriting the message queue module APIs, including: Override the msgQCreate function to create a message queue structure containing a message container, condition variables, and a mutex lock. Rewrite the msgQSend function, which internally constructs the data to be sent into a message, inserts it into a message container of the corresponding priority, and notifies the receiving thread by releasing a semaphore. Override the msgQReceive function, which internally retrieves a message from the highest priority message container based on the waiting strategy and copies the data to the specified memory. Override the msgQDelete function to release the resources occupied by the message queue; Rewrite the msgQNumMsgs function to calculate and return the total number of messages currently in the message queue.

5. The interface conversion method for VxWorks system to embedded Linux system according to claim 1, characterized in that, The rewriting of VxWorks system function APIs includes rewriting the semaphore module APIs, including: Rewrite the semBCreate and semCCreate functions, which internally call the sem_init function to create POSIX semaphores; Rewrite the semMCreate function, which internally calls the pthread_mutex_init function to create a mutex lock; Rewrite the semGive function, and internally call either the sem_post function or the pthread_mutex_unlock function, depending on the semaphore type. Rewrite the semTake function and, depending on the semaphore type and the waiting parameters, internally choose to call pthread_mutex_lock, sem_wait, sem_trywait, or a timed polling function; Override the semDelete function to destroy semaphores or mutexes.

6. The interface conversion method for VxWorks system to embedded Linux system according to claim 1, characterized in that, The rewriting of VxWorks system function APIs includes rewriting the watchdog module APIs, including: Override the wdCreate function to create a watchdog descriptor and register it to the global watchdog mapping table; Create a separate timer thread that periodically traverses the global watchdog mapping table and executes the registered callback function for watchdogs that have reached their timeout period. Override the wdStart function to start or reset the timeout and callback function of the specified watchdog timer; Rewrite the wdCancel function to stop the specified watchdog timer; Override the wdDelete function to delete the specified watchdog from the global watchdog mapping table and release the resources.

7. The interface conversion method for VxWorks system to embedded Linux system according to any one of claims 1 to 6, characterized in that, The library file can be a static library or a dynamic library.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the interface conversion method for VxWorks system to embedded Linux system as described in any one of claims 1 to 7.

Images