An optical module based on embedded operating system and working method thereof

By transplanting an embedded operating system into the optical module MCU, the problem of lack of real-time operating system support in the high-speed optical module is solved, and the optical module operation with high real-time and high stability is achieved, meeting the high-speed requirements and simplifying the development process.

CN119356832BActive Publication Date: 2025-03-14EOPTOLINK TECH INC LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411932089.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-26
Publication Date
2025-03-14
Estimated Expiration
2044-12-26

AI Technical Summary

Technical Problem

The traditional bare-metal program control mode lacks real-time operating system support in high-speed optical modules, relies on hardware interrupts, has low development efficiency, and is difficult to meet high-speed requirements.

Method used

Migrate embedded operating systems such as FREERTOS, Zephyr and RT-Thread into the MCU of the optical module, and implement task scheduling and priority management through the embedded operating system.

Benefits of technology

It realizes the high real-time response capability of optical modules at 400G, 800G and higher rates, reduces interrupt processing time, reduces dependence on hardware interrupts, improves stability and reliability, simplifies the development process, and reduces system maintenance difficulty and after-sales service costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119356832B_ABST
    Figure CN119356832B_ABST
Patent Text Reader

Abstract

The present invention belongs to the technical field of optical modules, and relates to an optical module based on an embedded operating system and a working method thereof. An embedded operating system is transplanted into the MCU of the optical module, and the CMIS protocol and / or user-defined functional tasks are executed through the embedded operating system; the architecture of the optical module includes an application layer, a kernel layer, and a hardware abstraction layer; the kernel layer schedules and processes the tasks defined in the application layer to control the hardware abstraction layer; the kernel layer adopts an embedded operating system kernel, specifically: an embedded operating system is transplanted into the MCU of the optical module. By introducing the embedded operating system kernel into the optical module MCU, real-time operating system support for high-speed optical modules is achieved; and based on the task scheduling and priority management capabilities of the embedded operating system, high real-time response capabilities of optical modules at 400G, 800G and higher rates are achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention relates to the technical field of optical modules, and specifically discloses an optical module based on an embedded operating system and a working method thereof. Background Art

[0002] With the rapid development of artificial intelligence (AI), Internet of Things (IoT), big data and cloud computing, global data traffic has grown exponentially, resulting in a sharp increase in demand for high-speed, high-capacity data transmission. In this context, optical module technology has been widely used in data centers, AI computing clusters, 5G base stations, smart grids and industrial automation. Optical modules are the core components in communication systems, responsible for photoelectric conversion, and determine the rate, energy efficiency and stability of communication systems. In recent years, the transmission rate of optical modules has gradually increased from 100G to 400G and 800G, and will even increase to 1.6T, 3.2T or higher in the future to meet the needs of new generation applications.

[0003] At present, the management of high-speed optical modules is mainly designed with reference to the CMIS (Common Management Interface Specification) protocol. The CMIS protocol is a common management interface specification that provides an open and standardized optical module management mechanism. The CMIS protocol covers key functions such as module status management, data path status management, stage control, module diagnosis, variable diagnosis monitoring, and command data blocks, requiring the module to respond in a very short time to ensure high real-time performance and high stability.

[0004] With the continuous expansion of CMIS protocol functions and the diverse customization needs of optical module terminal customers, high-speed optical modules need to process and execute more functions / tasks and realize state switching. The traditional bare-metal program control mode is gradually facing bottlenecks, mainly manifested in the lack of real-time operating system support, dependence on hardware interrupts, and low development efficiency. These problems make it difficult to meet the use of optical modules under high-speed requirements. Summary of the invention

[0005] The purpose of the present invention is to provide an optical module based on an embedded operating system and a working method thereof, so as to solve the problems that the traditional bare metal program control mode lacks real-time operating system support, is dependent on hardware interrupts, and has low development efficiency; the specific scheme is as follows:

[0006] In a first aspect, an optical module based on an embedded operating system is provided, wherein an embedded operating system is transplanted into an MCU of the optical module, and a CMIS protocol and / or user-defined functional tasks are executed through the embedded operating system; the embedded operating system includes but is not limited to a FREERTOS real-time operating system, a Zephyr real-time operating system, and a RT-Thread real-time operating system.

[0007] In a second aspect, an optical module based on an embedded operating system is provided, wherein the architecture of the optical module includes an application layer, a kernel layer and a hardware abstraction layer;

[0008] The kernel layer schedules and processes the tasks defined in the application layer to control the hardware abstraction layer; wherein the tasks defined in the application layer are the optical module function tasks defined based on the CMIS protocol; the hardware abstraction layer is composed of the hardware drivers in the optical module;

[0009] The kernel layer adopts an embedded operating system kernel, specifically: an embedded operating system is transplanted into the MCU of the optical module.

[0010] Furthermore, the optical module functional tasks defined based on the CMIS protocol in the application layer include idle tasks, code writing tasks, debugging parameter modification tasks, channel and data path control tasks, command data block tasks, DSP tunnel tasks, module state machine tasks, data path state machine tasks, error recording tasks, module performance diagnosis control tasks, multi-function diagnosis monitoring tasks and digital diagnosis monitoring tasks;

[0011] And assign priority parameters according to the preset importance of the functional tasks, and assign stack space parameters according to the complexity of the data processed by different functional tasks.

[0012] Furthermore, the kernel layer comprises a scheduler, a timer, a mutex module, an event group module, a semaphore, a message queue and an error diagnosis module;

[0013] The scheduler is used to sort the functional tasks in the task list based on different priority parameters, and to temporarily suspend the functional tasks blocked by the mutex; its scheduling methods include: priority-based preemptive scheduling, time slice round-robin scheduling, and priority-based preemptive scheduling with time slices;

[0014] The timer is used to perform preset periodic counting based on the system clock beat.

[0015] Furthermore, the hardware abstraction layer includes a transmitting unit driver, a receiving unit driver, a DSP driver, an MCU peripheral driver and a power chip driver in the optical module.

[0016] Furthermore, the embedded operating system porting process is as follows:

[0017] Configure the timer of the embedded operating system based on the system clock of the MCU, and determine the frequency configuration value of the timer by presetting the pre-scaling coefficient and reload value;

[0018] Based on the number and size of local variables required in the optical module functional task in the CMIS protocol, the maximum depth of function calls, and the nested function calls, stack space is configured for each functional task;

[0019] Configure priority parameters for each functional task based on the importance of each task in the optical module functional task in the CMIS protocol;

[0020] Configure the stack pointer initialization code in the MCU startup file to make the stack pointer point to the starting position of the embedded operating system task stack, and set the interrupt vector and interrupt service entry address of the embedded operating system timer;

[0021] Configure the timer interface of each hardware in the hardware abstraction layer; including: configuring the timer initialization function, start function, stop function and interrupt processing function;

[0022] Configure the interrupt handling interface of the embedded operating system and set priority parameters.

[0023] Furthermore, the embedded operating system migration process also includes:

[0024] Create multiple functional tasks of different types and with different priority parameters, schedule the tasks through the scheduler, and test whether the functional tasks are executed according to the preset startup order, execution time, and task switching.

[0025] In a third aspect, a working method of an optical module based on an embedded operating system is provided, which includes:

[0026] S1. Initialize the MCU of the optical module to put each component in the MCU in the initial state;

[0027] S2. Initialize the embedded operating system kernel transplanted into the MCU and enter the ready state;

[0028] S3. Initialize the embedded operating system objects and configure tasks, mutexes, timers, and event groups;

[0029] S4. Start the task scheduler to implement task scheduling.

[0030] Further, S3. Initialize the embedded operating system object, configure the task, mutex, timer and event group, specifically including:

[0031] S301. Configure the mutex for DSP access;

[0032] S302. Configure the digital diagnostic monitoring task timer and set its priority parameters and stack space parameters;

[0033] S303. Configure the event group and assign event flags to the corresponding tasks;

[0034] S304. Configure the idle task and set its priority parameters and stack space parameters;

[0035] S305. Configure the coding task and set its priority parameters and stack space parameters;

[0036] S306. Configure the debugging parameter modification task and set its priority parameters and stack space parameters;

[0037] S307. Configure the channel and data path control tasks and set their priority parameters and stack space parameters;

[0038] S308. Configure the command data block task and set its priority parameters and stack space parameters;

[0039] S309. Configure the DSP tunnel task and set its priority parameters and stack space parameters;

[0040] S310. Configure the module state machine task and set its priority parameters and stack space parameters;

[0041] S311. Configure the module path state machine task and set its priority parameters and stack space parameters;

[0042] S312. Configure the error logging task and set its priority parameters and stack space parameters;

[0043] S313. Configure the module performance diagnostic control task and set its priority parameters and stack space parameters;

[0044] S314. Configure the multi-function diagnostic monitoring task and set its priority parameters and stack space parameters;

[0045] S315. Start the digital diagnosis monitoring task timer.

[0046] Further, S4. Start the task scheduler to implement task scheduling, which specifically includes:

[0047] S401. Configure timer service tasks;

[0048] S402. Turn off interruption;

[0049] S403. Set the embedded operating system kernel scheduler to enter the running state;

[0050] S404. Configure the enabled task time statistics;

[0051] S405. Set PendSV and SysTick to preset priority parameters;

[0052] S406. Configure the system kernel timer interrupt to enable the heartbeat of the embedded operating system and set the priority parameters, with an interrupt period of 1ms;

[0053] S407. Configure the number of nested levels of critical sections;

[0054] S408. Based on the above configuration, start task scheduling.

[0055] Furthermore, in the optical module working method, the task triggering mode includes a periodic task triggering mode and an event-driven task triggering mode;

[0056] The periodic task triggering method is specifically: setting a time period based on a software timer configured for the periodic working task of the optical module, and triggering the task based on the time period;

[0057] The event-driven task triggering method is specifically as follows: when the execution of the optical module working task is based on the corresponding triggering event, the task changes from the running state to the blocked state, until the triggering event is triggered, the task changes to the ready state and the running state to continue execution.

[0058] The beneficial effects of the present invention are:

[0059] Introduce an embedded operating system kernel into the optical module MCU to achieve real-time operating system support; through task scheduling and priority management, the embedded operating system can achieve high real-time response capabilities of optical modules at 400G, 800G and future 1.6T, 3.2T or even higher rates, and support the CMIS protocol function requirements in more complex applications in the future and the diverse customization requirements of optical module terminal customers; through the task management, priority scheduling, synchronization and communication mechanisms of the embedded operating system, the interrupt processing time is reduced, the dependence on hardware interrupts is reduced, the stability and reliability of multi-task high-speed optical modules are improved, the difficulty of system maintenance is effectively reduced, and the after-sales service costs are saved; the task time statistics function and error recording task function of the embedded operating system can improve the reliability, maintainability and market competitiveness of the product; the introduction of the embedded operating system reduces the burden on developers in underlying task scheduling and resource management, shortens the development cycle, and saves development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 This is a system hierarchical schematic diagram of an optical module based on an embedded operating system of the present invention.

[0061] Figure 2The figure is a hardware principle block diagram of the optical module based on the embedded operating system of the present invention. DETAILED DESCRIPTION

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

[0063] First, the present invention analyzes and points out the specific deficiencies of the traditional bare metal program control mode, including:

[0064] 1. Real-time bottleneck: In high-speed applications, optical modules need to respond to different management instructions in real time and control a large number of communication tasks. The sequential execution and interrupt dependence of bare metal programs lead to insufficient real-time guarantees and cannot meet the requirements of future higher-speed applications (such as 1.6T, 3.2T).

[0065] 2. Burden of interrupt processing: In order to realize the high real-time functions in the CMIS protocol and the diverse customization requirements of optical module terminal customers, many functions need to be implemented in hardware interrupts. This design makes the interrupt processing time long, the system scheduling efficiency is low, and it will have a negative impact on the reliability, power consumption and system resource management of the optical module. At the same time, frequent interrupt dependence increases the difficulty of system debugging and maintenance, and reduces development efficiency.

[0066] 3. Limited system scalability and maintainability: In the bare metal control mode, developers need to manually handle complex task scheduling and resource management, which is prone to resource competition in a multi-tasking environment, affecting the scalability of the optical module. In addition, bare metal programs are usually designed for specific hardware configurations and have poor adaptability, making it difficult for the system to quickly adapt to high-speed applications that support future CMIS protocol expansion and the diverse customization needs of optical module terminal customers.

[0067] Example 1

[0068] Based on the above shortcomings, the present invention proposes to transplant an embedded operating system into the MCU of the optical module, and execute the CMIS protocol and / or user-defined functional tasks through the embedded operating system.

[0069] Among them, embedded operating systems include but are not limited to FREERTOS real-time operating system, Zephyr real-time operating system, RT-Thread real-time operating system, μ C / OS-II / III real-time operating system and ThreadX real-time operating system, etc.

[0070] By introducing the embedded operating system kernel into the optical module MCU, real-time operating system support is achieved; through task scheduling and priority management, the embedded operating system can achieve high real-time response capabilities of optical modules at 400G, 800G and future 1.6T, 3.2T or even higher rates, and support the CMIS protocol function requirements in more complex applications in the future; through the task management, priority scheduling, synchronization and communication mechanisms of the embedded operating system, the interrupt processing time is reduced, the dependence on hardware interrupts is reduced, the stability and reliability of multi-task high-speed optical modules are improved, the difficulty of system maintenance is effectively reduced, and the after-sales service costs are saved; the task time statistics function and error recording task function of the embedded operating system can improve the reliability, maintainability and market competitiveness of the product; the introduction of the embedded operating system reduces the burden on developers in underlying task scheduling and resource management, shortens the development cycle, and saves development costs.

[0071] Example 2

[0072] Based on the above solution, when introducing the embedded operating system kernel into the optical module MCU, the specific solution is as follows.

[0073] In the implementation example of the present invention, the embedded operating system takes FREERTOS as an example. FREERTOS is an open source real-time operating system kernel. Its main function is to manage the hardware resources of the microcontroller (MCU) or microprocessor (MPU), so that multiple tasks can be executed concurrently; it has the advantages of high portability and lightweight; the present invention introduces it into the functional task execution management of the high-speed optical module, and designs its specific application method in the high-speed optical module scenario.

[0074] This embodiment takes FREERTOS as an example. Figure 1 As shown in FIG. 1 , the architecture of the optical module that introduces the FREERTOS real-time operating system includes an application layer, a kernel layer, and a hardware abstraction layer;

[0075] The kernel layer controls the hardware abstraction layer by scheduling and processing the tasks defined in the application layer. The tasks defined in the application layer are the optical module functional tasks defined based on the CMIS protocol. The hardware abstraction layer consists of the hardware drivers in the optical module.

[0076] The kernel layer adopts the FREERTOS kernel, specifically: FREERTOS is transplanted in the MCU of the optical module.

[0077] In the application of high-speed optical modules, the optical module functional tasks defined in the application layer based on the CMIS protocol include idle tasks, code writing tasks, debugging parameter modification tasks, channel and data path control tasks, command data block tasks, DSP tunnel tasks, module state machine tasks, data path state machine tasks, error recording tasks, module performance diagnosis control tasks, multi-function diagnosis monitoring tasks and digital diagnosis monitoring tasks; it should be understood that the optical module functional tasks may be more than the tasks listed above. When the rate of the optical module reaches a higher level, there may be other functional tasks that are not currently proposed.

[0078] Based on the above, the control logic of the optical module is abstracted into hardware driver layer, kernel layer and application layer. The application layer tasks are managed by FREERTOS, which can improve the maintainability and reusability of the code.

[0079] Specifically, the idle task mainly implements watchdog feeding, transmitting end disabled polling, module state machine polling, data path state machine polling, module performance diagnostic polling, multi-function diagnostic monitoring polling, etc.; the code writing task is used to save user code, supplier and custom code to the module Flash. The debugging parameter modification task is used to modify the debugging parameters of the transmitting unit, receiving unit and DSP related chips. Channel and data path control tasks: 1. Used for transmitting and receiving end channel disable, channel polarity, channel balance control, 2. Used for data path control of control sets containing application examples and signal integrity. The command data block task is an enhanced interaction mechanism that extends the basic CMIS register read and write operation capabilities. Through the asymmetric message mechanism, the host can issue commands asynchronously, and the module notifies the host through status and flags after processing. It can be used to implement functions such as firmware download and performance monitoring. The DSP tunnel task is used to enable the host to read and write functions to the DSP under the condition that the module itself is prohibited from accessing the DSP. The module state machine task is used to manage the interaction between the host and the module and the overall behavioral characteristics of the module. The state of the module state machine indicates whether the module is ready to be managed and used by the host, and describes the module-wide behaviors and features. Through the module state machine tasks, the host and the module can coordinate to ensure that the module behavior in each stage from startup to normal operation complies with the protocol specification. The data path state machine task is used to describe the behaviors and properties related to the data path configuration and is managed by the host. It provides a hierarchical way to help the host and the module manage and configure specific data paths more accurately. The error logging task is used to record the error logs in the operation of the module, such as abnormal states in the operation of the DSP, stack overflows of various tasks, etc. This task runs through the research and development, production and application of optical modules, improves the reliability, maintainability and market competitiveness of the product, and is an important means to improve the efficiency of research and development and user experience. The module performance diagnostic control task is used to evaluate the error performance of the module and the module self-diagnosis based on indicators such as bit error rate and signal-to-noise ratio through control loopback, configuration pattern generator and error checker. The multi-function diagnostic monitoring task is used to expand the performance and diagnostic monitoring functions of the optical module, including new functions such as statistical data and new observable objects that may be monitored (when supported by the module). The digital diagnostic monitoring task is used to monitor the key operating parameters of the module in real time, such as laser operating temperature, laser drive current, transmitting optical power, receiving optical power, power supply voltage, etc. The main purpose is to provide optical module diagnostic information for performance evaluation and troubleshooting.

[0080] At the same time, it is also necessary to assign priority parameters according to the importance of different functional tasks, and assign stack space parameters according to the complexity of the data processed by different functional tasks. In the scheme of the present invention, the larger the value of the priority parameter, the higher the priority; the size of the stack space parameter mainly depends on the number and size of local variables required in the optical module functional tasks, the maximum depth of function calls, and the nested function calls.

[0081] The kernel layer consists of a scheduler, a timer, a mutex module, an event group module, a semaphore, a message queue and an error diagnosis module; it should be understood that the kernel layer is used to implement multi-task scheduling and real-time operation support, and the present invention mainly uses functions such as a scheduler, a timer, a mutex, an event group, and an error diagnosis.

[0082] The scheduler is used to sort the functional tasks in the task list based on different priority parameters, and to temporarily suspend the functional tasks blocked by the mutex; its scheduling methods include: priority-based preemptive scheduling, time slice round-robin scheduling, and priority-based preemptive scheduling with time slices;

[0083] The timer is used to perform preset periodic counting based on the system clock tick.

[0084] The hardware abstraction layer includes the transmitting unit driver, receiving unit driver, DSP driver, MCU peripheral driver and power chip driver in the optical module. Its main function is to realize the driving of hardware.

[0085] The process of porting FREERTOS to the optical module MCU is as follows:

[0086] The FREERTOS timer is configured based on the MCU's system clock, and the frequency configuration value of the timer is determined by presetting the pre-scaling coefficient and the reload value; wherein the frequency configuration value is used as a reference time interval for FREERTOS task scheduling and time management.

[0087] Based on the number and size of local variables required in the optical module functional task in the CMIS protocol, the maximum depth of function calls, and the nested function calls, stack space is configured for each functional task;

[0088] Configure priority parameters for each functional task based on the importance of each task in the optical module functional task in the CMIS protocol;

[0089] Configure the stack pointer initialization code in the MCU startup file to make the stack pointer point to the starting position of the FREERTOS task stack, and set the interrupt vector and interrupt service entry address of the FREERTOS timer;

[0090] Configure the timer interface of each hardware in the hardware abstraction layer; including: configuring the timer's initialization function, start function, stop function and interrupt processing function; among them, the timer's initialization function includes the timer's clock source, counting mode and other related parameters; the interrupt processing function needs to call the FREERTOS system timer processing function to update the system tick count and trigger the task scheduling check.

[0091] Then configure the interrupt processing interface of FREERTOS and set the priority parameters. The interrupt processing interface is used to build the interrupt processing interface of FREERTOS to ensure that the interrupt system of MCU can work with FREERTOS. When an interrupt occurs, the context information of the current task, including the register value, is saved, and the task execution can be accurately restored after the interrupt processing is completed. In addition, for different types of interrupts, corresponding priority settings are performed in FREERTOS to ensure the timeliness of the interrupt response and not interfere with the normal progress of task scheduling.

[0092] After the above-mentioned transplantation process is completed, the transplanted FREERTOS kernel needs to be tested. The testing method is as follows:

[0093] Create multiple functional tasks of different types and with different priority parameters, schedule the tasks through the scheduler, and test whether the functional tasks are executed according to the preset startup sequence, execution time, and task switching. If the test function is executed according to the preset startup sequence, execution time, and task switching, the test is successful.

[0094] In the above solution, the optical module hardware used is as follows: Figure 2 As shown in the figure, it is a schematic block diagram of the principle of the optical module, which mainly includes the layout of the optical fiber interface, electrical interface, transmitting unit, receiving unit, DSP, MCU and power management module. The functions of each part are as follows:

[0095] Fiber optic interface: Connected to the transmitting unit and receiving unit, used to send and receive optical signals. If it is an AEC (Active Electrical Cable) copper module, the receiving and transmitting units and fiber optic interface in the above block diagram are not included.

[0096] Electrical interface: Contains 1. A variety of low-speed signal control pins, such as INTL, LPMode, ModSel (optional), Reset and I2C to realize module status indication, power mode control, module selection, reset control, and communication between the host (switch, network card, etc.) and the module. 2. Contains high-speed signal line data pins, divided into Tx1, Tx2...Txn differential signal pairs at the transmitting end and Rx1, Rx2...Rxn differential signal pairs at the receiving end. 3. The power line and ground line are used to power the optical module.

[0097] Transmitter unit: mainly includes laser, modulator and driver, responsible for converting electrical signals into optical signals and transmitting them to the remote optical module receiving unit through optical fiber. If it is an AEC (Active Electrical Cable) copper module, the receiving and transmitting units and optical fiber interface in the above block diagram are not included.

[0098] Receiving unit: mainly includes photodetector and TIA (transimpedance amplifier), which is responsible for converting optical signals into electrical signals, amplifying the electrical signals and then outputting them to DSP.

[0099] DSP: Mainly used to handle complex signal modulation and transmission problems. It improves the performance and transmission quality of optical modules through efficient digital signal processing algorithms, mainly including: 1. Signal encoding and decoding. 2. Clock and data recovery. 3. Signal equalization and dispersion compensation. 4. Forward error correction. 5. Power optimization and signal management. Some DSPs have integrated the driver in the above-mentioned transmitting unit and the TIA in the receiving unit.

[0100] MCU: It is the management core of the module. Based on the transplanted FREERTOS kernel, it is responsible for coordinating and controlling the work of each part of the module to ensure the efficient operation of the module and communication with the host. It has the following main functions: 1. Initialization and configuration of the module. 2. Realization of I2C communication between the module and the host. 3. Implementation and management of the CMIS protocol. 4. Firmware update.

[0101] Power supply unit: provides power for MCU, DSP, transmitting unit and receiving unit.

[0102] Example 3

[0103] Based on the high-speed optical module introduced with the embedded operating system kernel, this embodiment mainly describes the working method of the optical module, which is the same as Embodiment 2 and also takes FREERTOS as an example; specifically, the following steps are included:

[0104] S1. Initialize the MCU of the optical module to put each component in the MCU in the initial state;

[0105] S2. Initialize the FREERTOS kernel transplanted into the MCU and enter the ready state;

[0106] S3. Initialize the FREERTOS object and configure the tasks, mutexes, timers, and event groups;

[0107] S4. Start the task scheduler to implement task scheduling.

[0108] Specifically, S3. Initialize the FREERTOS object and configure the tasks, mutexes, timers, and event groups, including:

[0109] S301. Configure the mutex for DSP access;

[0110] S302. Configure the digital diagnostic monitoring task timer and set its priority parameters and stack space parameters;

[0111] S303. Configure the event group and assign event flags to the corresponding tasks;

[0112] S304. Configure the idle task and set its priority parameters and stack space parameters;

[0113] S305. Configure the coding task and set its priority parameters and stack space parameters;

[0114] S306. Configure the debugging parameter modification task and set its priority parameters and stack space parameters;

[0115] S307. Configure the channel and data path control tasks and set their priority parameters and stack space parameters;

[0116] S308. Configure the command data block task and set its priority parameters and stack space parameters;

[0117] S309. Configure the DSP tunnel task and set its priority parameters and stack space parameters;

[0118] S310. Configure the module state machine task and set its priority parameters and stack space parameters;

[0119] S311. Configure the module path state machine task and set its priority parameters and stack space parameters;

[0120] S312. Configure the error logging task and set its priority parameters and stack space parameters;

[0121] S313. Configure the module performance diagnostic control task and set its priority parameters and stack space parameters;

[0122] S314. Configure the multi-function diagnostic monitoring task and set its priority parameters and stack space parameters;

[0123] S315. Start the digital diagnosis monitoring task timer.

[0124] Specifically, S4. Starting the task scheduler to implement task scheduling specifically includes:

[0125] S401. Configure timer service tasks;

[0126] S402. Turn off interruption;

[0127] S403. Set the FREERTOS kernel scheduler to enter the running state;

[0128] S404. Configure the enabled task time statistics;

[0129] S405. Set PendSV and SysTick to preset priority parameters; PendSV is a pendable service call, which is a programmable exception, usually used to implement task switching in the operating system, and its priority is usually set low; SysTick is a timer, which is a 24-bit down counter used to provide basic timing functions, which can generate periodic interrupts, which are very important for the time management of the operating system and the scheduling of various periodic tasks.

[0130] S406. Configure the enabled timer interrupt as the heartbeat of FREERTOS and set the priority parameters, with an interrupt period of 1ms;

[0131] S407. Configure the number of nested levels of critical sections;

[0132] S408. Based on the above configuration, start task scheduling.

[0133] In addition, in the optical module working method, the task triggering mode includes a periodic task triggering mode and an event-driven task triggering mode;

[0134] The specific method of triggering the periodic task is: setting the time period based on the software timer configured for the periodic working task of the optical module, and triggering the task based on the time period;

[0135] The event-driven task triggering method is as follows: when the execution of the optical module working task is based on the corresponding trigger event, the task changes from the running state to the blocked state until the trigger event is triggered and the task changes to the ready state and the running state to continue execution.

[0136] In different implementation environments, priority parameters and stack space parameters can be set according to application scenarios; in a specific implementation case, the specific settings are as follows:

[0137] S1. Initialize the MCU of the optical module to put all components in the MCU in the initial state; mainly including initializing GPIO, ADC, DAC, SPI, watchdog, I2C and other peripherals.

[0138] S2. Initialize the FREERTOS kernel transplanted into the MCU and enter the configuration state; mainly includes setting the kernel to the ready state, indicating that you can start creating tasks, software timers and other resources.

[0139] S3. Initialize the FREERTOS object and configure the tasks, mutexes, timers, and event groups; specifically:

[0140] S301. Configure the mutex for DSP access;

[0141] S302. Configure the digital diagnostic monitoring task timer with a priority of 9 and a stack size of 8K;

[0142] S303. Configure the event group and assign event flags to the corresponding tasks; it should be noted that, except for the digital diagnostic monitoring task and the idle task, the remaining tasks are assigned corresponding event flags;

[0143] S304. Configure the idle task with a priority of 8 and a stack size of 32K;

[0144] S305. Configure the coding task with a priority of 40 and a stack size of 16K;

[0145] S306. Configure the debugging parameter modification task, with a priority of 25 and a stack size of 16K;

[0146] S307. Configure channel and data path control tasks, with a priority of 9 and a stack size of 16K;

[0147] S308. Configure the command data block task, the priority is 26, and the stack size is 16K;

[0148] S309. Configure the DSP tunnel task with a priority of 25 and a stack size of 16K;

[0149] S310. Configure the module state machine task, the priority is 10, and the stack size is 16K;

[0150] S311. Configure the module path state machine task, with a priority of 9 and a stack size of 16K;

[0151] S312. Configure the error logging task, with a priority of 9 and a stack size of 16K;

[0152] S313. Configure the module performance diagnosis control task, with a priority of 9 and a stack size of 16K;

[0153] S314. Configure the multi-function diagnostic monitoring task, with a priority of 9 and a stack size of 16K;

[0154] S315. Start the digital diagnosis monitoring task timer.

[0155] S4. Start the task scheduler to implement task scheduling, including:

[0156] S401. Configure timer service tasks;

[0157] S402. Turn off interruption;

[0158] S403. Set the FREERTOS kernel scheduler to enter the running state;

[0159] S404. Configure and enable task time statistics; wherein, enable the task time statistics function. Based on this function, developers can perform 1. performance optimization on optical modules during the R&D stage (identify and optimize performance bottlenecks by analyzing the distribution of task running time). 2. Task priority adjustment (ensure that high-priority tasks have sufficient CPU time to improve real-time performance). 3. Resource allocation evaluation (understand the CPU occupancy of tasks and provide data support for the reasonable allocation of resources such as memory and processing power). The task time statistics function helps developers intuitively understand the system operation status and provides important support for performance analysis and anomaly detection from R&D to actual application. This not only improves product quality, but also significantly shortens the development cycle and improves user experience.

[0160] S405. Set PendSV and SysTick to preset priority parameters; based on the above implementation case, the preset priority here is 15;

[0161] S406. Configure and enable the system kernel timer interrupt as the heartbeat of FREERTOS and set the priority parameter, where the interrupt period is 1ms; the preset priority here is also 15;

[0162] S407. Configure the number of nested levels of critical sections;

[0163] S408. Based on the above configuration, start task scheduling.

[0164] The present invention adopts a priority-based preemptive scheduling method with time slice rotation, that is, tasks with high priority are executed first, and tasks with equal priority are executed based on time slice rotation.

[0165] FREERTOS has 5 stack memory management modes. When creating a FREERTOS object, the present invention adopts the Heap_4 mode, which uses the first fit algorithm to allocate memory. Adjacent free memory blocks can be combined (merged) into a larger block, which will minimize the risk of memory fragmentation.

[0166] The present invention adopts a mutex to perform mutual exclusion protection on DSP operations, prevents resource competition among multiple tasks, and realizes synchronous access of multiple tasks. The use of a mutex can simplify the code design of multi-task resource access and avoid complex manual synchronization mechanisms.

[0167] The optical module tasks in this invention mainly use the following two task triggering methods:

[0168] 1. Periodic tasks: This periodic task is implemented through the digital diagnostic monitoring task software timer. The software timer period can be configured to be 50ms, that is, the module voltage, temperature, transmitting power, receiving power and other digital diagnostic monitoring quantities are reported every 50ms. In the bare metal program, there are usually two implementation methods: 1. Sequential reporting in the main loop, the reporting period is uncertain, and if the main loop time is greater than 100ms specified by the CMIS protocol, the real-time reporting cannot be met. 2. Use hardware timer for periodic reporting. Since the monitoring quantity acquisition time is long, the interrupt processing time will also be longer, which will affect the real-time, reliability and efficiency of the system. Using the FREERTOS software timer can avoid occupying interrupt resources and can also report in time.

[0169] 2. Event-driven tasks: Except for digital diagnostic monitoring tasks and idle tasks, the remaining tasks will call the waiting event function at the beginning of task execution to change the task itself from running state to blocked state until the corresponding event is triggered and then changed to ready state and running state for operation. For example, when the channel and data path control tasks are executed for the first time, they will enter the blocked state. The host writes Page10h byte130 specified by the CMIS protocol to the module through I2C as 0xFF. At this time, the optical module will enter the I2C interrupt, call the event sending function in I2C to send the "transmitter send disable" event. After the I2C interrupt exits, the channel and data path control tasks will immediately change from the blocked state to the ready state. At this time, if there is no task with a higher priority than the channel and data path control tasks, the task will immediately enter the running state to execute the "transmitter send disable" function. This task looks like it is executed in an interrupt, but it does not actually occupy interrupt resources. In the bare metal, since the "transmitter send disable" function of the execution module takes a long time to operate the DSP, it is often executed in the main loop in practice. The time from receiving the host command to starting the execution of the "transmitter transmission disable" function depends on the main cycle time, such as 60ms. The time from receiving the host command to starting the execution of the optical module based on the operating system is only 16us. When using the command data block task for firmware update, the same size firmware, the same I2C communication rate, the download time in the bare metal program is 45s, while the download time based on the operating system is 38 seconds. The position of downloading firmware can save production costs in mass production.

[0170] It should be noted that the above-mentioned Embodiment 2 and Embodiment 3 both take FREERTOS as an example. Since the transplantation process and working method of each embedded operating system in the present invention are basically the same, it is not difficult to think of how to transplant such as Zephyr real-time operating system, RT-Thread real-time operating system, μC / OS-II / III real-time operating system and ThreadX real-time operating system and other operating systems, as well as their working methods of configuration.

[0171] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. An optical module based on an embedded operating system, characterized in that: An embedded operating system is transplanted into the MCU of the optical module, and the CMIS protocol and / or user-defined functional tasks are executed through the embedded operating system; the embedded operating system includes but is not limited to the FREERTOS real-time operating system, the Zephyr real-time operating system and the RT-Thread real-time operating system; The transplantation process of the embedded operating system is as follows: Configure the timer of the embedded operating system based on the system clock of the MCU, and determine the frequency configuration value of the timer by presetting the pre-scaling coefficient and reload value; Based on the number and size of local variables required in the optical module functional tasks in the CMIS protocol and the customized functional tasks of the optical module terminal customers, the maximum depth of function calls, and the nested function calls, stack space is configured for each functional task; Configure priority parameters for each functional task based on the importance of each task in the optical module functional task in the CMIS protocol and the customized functional task of the optical module terminal customer; Configure the stack pointer initialization code in the MCU startup file to make the stack pointer point to the starting position of the embedded operating system task stack, and set the interrupt vector and interrupt service entry address of the embedded operating system timer; Configure the timer interface of each hardware in the hardware abstraction layer; including: configuring the timer initialization function, start function, stop function and interrupt processing function; Configure the interrupt handling interface of the embedded operating system and set priority parameters.

2. An optical module based on an embedded operating system, characterized in that: The architecture of the optical module includes an application layer, a kernel layer and a hardware abstraction layer; The kernel layer schedules and processes the tasks defined in the application layer to control the hardware abstraction layer; wherein the tasks defined in the application layer are the optical module function tasks defined based on the CMIS protocol and the customized function tasks of the optical module terminal customers; the hardware abstraction layer is composed of the hardware drivers in the optical module; The kernel layer adopts an embedded operating system kernel, specifically: an embedded operating system is transplanted into the MCU of the optical module; The transplantation process of the embedded operating system is as follows: Configure the timer of the embedded operating system based on the system clock of the MCU, and determine the frequency configuration value of the timer by presetting the pre-scaling coefficient and reload value; Based on the number and size of local variables required in the optical module functional tasks in the CMIS protocol and the customized functional tasks of the optical module terminal customers, the maximum depth of function calls, and the nested function calls, stack space is configured for each functional task; Configure priority parameters for each functional task based on the importance of each task in the optical module functional task in the CMIS protocol and the customized functional task of the optical module terminal customer; Configure the stack pointer initialization code in the MCU startup file to make the stack pointer point to the starting position of the embedded operating system task stack, and set the interrupt vector and interrupt service entry address of the embedded operating system timer; Configure the timer interface of each hardware in the hardware abstraction layer; including: configuring the timer initialization function, start function, stop function and interrupt processing function; Configure the interrupt handling interface of the embedded operating system and set priority parameters.

3. The optical module based on embedded operating system as claimed in claim 2, characterized in that: The optical module functional tasks defined based on the CMIS protocol in the application layer include idle tasks, code writing tasks, debugging parameter modification tasks, channel and data path control tasks, command data block tasks, DSP tunnel tasks, module state machine tasks, data path state machine tasks, error recording tasks, module performance diagnosis control tasks, multi-function diagnosis monitoring tasks, digital diagnosis monitoring tasks and customized functional tasks for optical module terminal customers; And assign priority parameters according to the preset importance of the functional tasks, and assign stack space parameters according to the complexity of the data processed by different functional tasks.

4. The optical module based on embedded operating system as claimed in claim 3, characterized in that: The kernel layer comprises a scheduler, a timer, a mutex module, an event group module, a semaphore, a message queue and an error diagnosis module; The scheduler is used to sort the functional tasks in the task list based on different priority parameters, and to suspend the functional tasks blocked by the mutex; The scheduling modes include: priority-based preemptive scheduling, time slice round-robin scheduling, and priority-based preemptive scheduling with time slices; The timer is used to perform preset periodic counting based on the system clock beat.

5. The optical module based on embedded operating system as claimed in claim 2, characterized in that: The hardware abstraction layer includes a transmitting unit driver, a receiving unit driver, a DSP driver, an MCU peripheral driver and a power chip driver in the optical module.

6. The optical module based on embedded operating system as claimed in claim 2, characterized in that: The embedded operating system migration process also includes: Create multiple functional tasks of different types and with different priority parameters, schedule the tasks through the scheduler, and test whether the functional tasks are executed according to the preset startup order, execution time, and task switching.

7. An optical module working method based on an embedded operating system, characterized in that: The steps include: S1. Initialize the MCU of the optical module to put each component in the MCU in the initial state; S2. Initialize the embedded operating system kernel transplanted into the MCU and enter the ready state; the transplantation process of the embedded operating system is as follows: Configure the timer of the embedded operating system based on the system clock of the MCU, and determine the frequency configuration value of the timer by presetting the pre-scaling coefficient and reload value; Based on the number and size of local variables required in the optical module functional tasks in the CMIS protocol and the customized functional tasks of the optical module terminal customers, the maximum depth of function calls, and the nested function calls, stack space is configured for each functional task; Configure priority parameters for each functional task based on the importance of each task in the optical module functional task in the CMIS protocol and the customized functional task of the optical module terminal customer; Configure the stack pointer initialization code in the MCU startup file to make the stack pointer point to the starting position of the embedded operating system task stack, and set the interrupt vector and interrupt service entry address of the embedded operating system timer; Configure the timer interface of each hardware in the hardware abstraction layer; including: configuring the timer initialization function, start function, stop function and interrupt processing function; Configure the interrupt processing interface of the embedded operating system and set priority parameters; S3. Initialize the embedded operating system objects and configure tasks, mutexes, timers, and event groups; S4. Start the task scheduler to implement task scheduling.

8. The optical module working method based on embedded operating system as claimed in claim 7, characterized in that: S3. Initialize the embedded operating system objects and configure the tasks, mutexes, timers, and event groups, including: S301. Configure the mutex for DSP access; S302. Configure the digital diagnostic monitoring task timer and set its priority parameters and stack space parameters; S303. Configure the event group and assign event flags to the corresponding tasks; S304. Configure the idle task and set its priority parameters and stack space parameters; S305. Configure the coding task and set its priority parameters and stack space parameters; S306. Configure the debugging parameter modification task and set its priority parameters and stack space parameters; S307. Configure the channel and data path control tasks and set their priority parameters and stack space parameters; S308. Configure the command data block task and set its priority parameters and stack space parameters; S309. Configure the DSP tunnel task and set its priority parameters and stack space parameters; S310. Configure the module state machine task and set its priority parameters and stack space parameters; S311. Configure the module path state machine task and set its priority parameters and stack space parameters; S312. Configure the error logging task and set its priority parameters and stack space parameters; S313. Configure the module performance diagnostic control task and set its priority parameters and stack space parameters; S314. Configure the multi-function diagnostic monitoring task and set its priority parameters and stack space parameters; S315. Start the digital diagnosis monitoring task timer.

9. The optical module working method based on embedded operating system as claimed in claim 7, characterized in that: S4. Start the task scheduler to implement task scheduling, including: S401. Configure timer service tasks; S402. Turn off interruption; S403. Set the embedded operating system kernel scheduler to enter the running state; S404. Configure the enabled task time statistics; S405. Set PendSV and SysTick to preset priority parameters; S406. Configure the system kernel timer interrupt to enable the heartbeat of the embedded operating system and set the priority parameters, with an interrupt period of 1ms; S407. Configure the number of nested layers of critical sections; S408. Based on the above configuration, start task scheduling.

10. The optical module working method based on embedded operating system as claimed in claim 7, characterized in that: In the optical module working method, the task triggering mode includes a periodic task triggering mode and an event-driven task triggering mode; The periodic task triggering method is specifically: setting a time period based on a software timer configured for the periodic working task of the optical module, and triggering the task based on the time period; The event-driven task triggering method is specifically as follows: when the execution of the optical module working task is based on the corresponding triggering event, the task changes from the running state to the blocked state, until the triggering event is triggered, the task changes to the ready state and the running state to continue execution.

Citation Information

Patent Citations

  • Thread signal operating method and system of embedded real-time operation system

    CN111538580A

  • Optical module control method, device and equipment and computer readable storage medium

    CN112346390A