CN116521418B - Method for acquiring operation information of embedded system and computer readable storage medium - Google Patents
Method for acquiring operation information of embedded system and computer readable storage medium Download PDFInfo
- Publication number
- CN116521418B CN116521418B CN202310560683.5A CN202310560683A CN116521418B CN 116521418 B CN116521418 B CN 116521418B CN 202310560683 A CN202310560683 A CN 202310560683A CN 116521418 B CN116521418 B CN 116521418B
- Authority
- CN
- China
- Prior art keywords
- embedded system
- operation information
- scheme
- storage area
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 46
- 230000002093 peripheral effect Effects 0.000 claims abstract description 49
- 238000012546 transfer Methods 0.000 claims abstract description 6
- 230000006870 function Effects 0.000 claims description 16
- 230000001960 triggered effect Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 12
- 238000011161 development Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 241000282472 Canis lupus familiaris Species 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000012840 feeding operation Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Retry When Errors Occur (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides a method for acquiring operation information of an embedded system and a computer readable storage medium, wherein the operation information comprises real-time operation state data of at least one peripheral of the embedded system, and the acquisition method comprises the following steps: executing a preset first scheme to acquire the running information and storing the running information in a first storage area of the embedded system; and before the embedded system enters HardFault and is interrupted, executing a second preset scheme to transfer the running information from the first storage area to a second storage area. The method for acquiring the embedded running information can ensure that the real-time state data of each peripheral can be timely, completely and accurately acquired before restarting due to various faults when the embedded system is in different states.
Description
Technical Field
The application belongs to the technical field of embedded systems, and particularly relates to an acquisition method of embedded system operation information and a computer readable storage medium.
Background
The embedded system is a product of combining a computer technology, a semiconductor technology, a microelectronic technology and the like, is rapidly applied to the fields of aviation, aerospace, military, communication, household appliances and the like since the embedded system appears, and is increasingly widely applied to the fields of intelligent control, intelligent/automatic driving and the like of various robots along with the rapid development of artificial intelligence and the Internet of things technology in recent years.
The embedded system generally comprises hardware, an operating system, a software running environment and the like, wherein the hardware comprises a processor, peripheral equipment, necessary peripheral circuits and the like, and the control of the hardware is realized through a program running in the operating system and specific functions are completed. The development of the embedded system is surrounded, the core work is based on the processor architecture and the operating system characteristics of the used embedded system, and the main control program and the application programs of various peripheral devices are developed and debugged, so that the main control program and the application programs of various peripheral devices can be accurately and stably controlled to complete the setting function, and obviously, various software and hardware problems in the running process of the system can be analyzed and solved only by accurately acquiring various running information of the embedded system, so that the running of the embedded system after the development is completed can be ensured to be safe and stable.
At present, various mature embedded systems are provided with self-contained operation data acquisition mechanisms or information storage systems, however, in the actual use process, the requirements of timely and stable acquisition of various data in various complex and precisely controlled application scenes can not be met far away by utilizing the self-contained mechanisms or systems of the system, so that the existing embedded system data acquisition mechanisms are required to be improved to ensure that the operation information of the embedded system can be effectively acquired under various faults and accidents in the operation process of the embedded system.
Disclosure of Invention
In order to solve the above-mentioned problems occurring in the prior art, an object of the present application is to provide a method for acquiring operation information of an embedded system and a computer-readable storage medium storing an executable program for operating the method.
The embodiment of the application provides a method for acquiring operation information of an embedded system, wherein the operation information comprises real-time operation state data of at least one peripheral of the embedded system.
The acquisition method comprises the following steps: executing a preset first scheme to acquire the running information and storing the running information in a first storage area of the embedded system; and before the embedded system enters HardFault and is interrupted, executing a second preset scheme to transfer the running information from the first storage area to a second storage area.
Further, the first scheme includes the steps of: the embedded system continues to run the main thread until at least one of the peripheral triggers receives an interrupt; executing a data updating function to acquire the real-time running state data of the peripheral equipment triggering the receiving interruption; storing the real-time running state data to the first storage area; and exiting the receiving interrupt.
Further, the second scheme includes the steps of: interrupting a currently executing program; periodically resetting the countdown data of the watchdog until the latest updated real-time running state data of each peripheral device stored in the first storage area is transited to the second storage area in a traversing way.
Preferably, the second scheme is executed when at least one of the following situations occur in the embedded system: memory overflow, wild pointer appearance and pop.
Preferably, the embedded system is an RT-Thread system, and the second scheme is executed at an application layer of the RT-Thread system.
Preferably, the operation information further includes systink data of the embedded system, and the method for acquiring the operation information of the embedded system further includes the following steps: and executing a preset third scheme when the embedded system generates an operation error of the operating system.
Further, the third scheme includes the steps of: acquiring the systink data and storing the systink data in the second storage area; restarting the embedded system.
Specifically, the operating system running error is represented by that the embedded system has abnormal systink update frequency but does not trigger HardFault interrupt.
Preferably, the acquisition method further comprises the steps of: and transferring the operation information from the first storage area to the second storage area.
The present application also provides, by way of example, a computer-readable storage medium storing an executable program that can be used to perform the above-described method of acquiring embedded system operation information.
The technical scheme provided by the embodiment of the application has at least the following beneficial effects:
According to the method for acquiring the running information of the embedded system, the real-time state data of each peripheral is acquired in a mode of executing the receiving interruption when the system is in the normal running state, and the failure information loss caused by restarting caused by a watchdog is avoided by executing the second scheme before the system is in the serious failure state capable of causing restarting is interrupted by HardFault, so that the real-time state data of each peripheral is timely, completely and accurately acquired, and the problem that the HardFault interruption mechanism of the existing embedded system cannot timely and effectively save failure field information is effectively solved.
Drawings
FIG. 1 is a block diagram of a conventional embedded system;
FIG. 2 is a flow chart of a method of acquiring embedded system operational information according to some embodiments of the present application;
FIG. 3 is a schematic diagram illustrating the execution of the first and second aspects in the main thread of the embedded operating system according to an embodiment of the present application;
FIG. 4 is a schematic diagram of an embedded system performing a second embodiment in some embodiments;
FIG. 5 is a flow chart of a method of acquiring embedded system operational information according to some embodiments of the present application;
FIG. 6 is a schematic diagram of a specific flow of executing a third aspect during a main thread run of an embedded operating system, in some embodiments.
Detailed Description
The present application will be further described below based on preferred embodiments with reference to the accompanying drawings. The embodiments described below are only some, but not all, embodiments of the present application and should not be construed as limiting the scope of the claimed application.
Furthermore, the terms "comprises," "comprising," "includes," and their derivatives, as used in this specification, are intended to be interpreted as excluding the existence of at least one additional feature, variable, numerical value, step, element, or combination of the aforementioned features, variables, numerical values, steps, elements, or combinations thereof; also, words such as "first," "second," and the like, used in this specification are merely for distinguishing descriptions and should not be construed as indicating or implying relative importance.
Unless defined otherwise, technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art.
In order to more clearly illustrate the improvement of the technical scheme claimed by the application relative to the prior art, the mechanism for acquiring various information in the development process of the prior embedded system and the difference between the mechanism and the actual information acquisition requirement are firstly elaborated.
Fig. 1 shows a diagram of an existing RT-Thread architecture of an embedded operating system, on the basis of which an embedded robot system, an embedded unmanned vehicle, etc. can be developed, and it should be noted that, in the description of the present application, the embedded robot system, the embedded unmanned vehicle system, and other similar systems based on software/hardware combinations developed by the embedded operating system are referred to as embedded systems.
As shown in fig. 1, the embedded operating system generally integrates a real-time operating system (RTOS) kernel at the bottom layer, components and services at the middle layer (including a file system, a network frame, a device frame, etc.), and various software packages at the application layer (including peripheral drivers, an internet of things, multimedia, etc.), and can support chips of various architectures such as ARM, RISC-V, tricore, etc., and control various peripheral devices such as a motor, a mechanical ARM, a sensor, etc., through the peripheral drivers, and acquire operation information of the various peripheral devices. Wherein generally the operation information comprises real-time operation status data of the respective peripheral devices, such as: real-time rotating speed, torque, power and other data of the motor, real-time acceleration data acquired by the acceleration sensor, real-time gesture data acquired by the gesture sensor and the like. The real-time running state data can be acquired by different control programs running in a main thread of the embedded operating system, and then through data analysis and feedback, each peripheral is controlled to realize the preset function and perform real-time monitoring.
Obviously, in the development and debugging processes of the embedded systems such as various robots, unmanned vehicles and the like, only in various states of the whole embedded system, the operation information of each part can be accurately obtained, each control program running in the embedded operating system can be effectively debugged, and especially when the embedded system is crashed or is in an abnormal state due to various known and/or unknown reasons, real-time state data of the operating system and various peripheral devices are required to be completely and accurately stored in time, so that problems existing in software and hardware of the system can be effectively analyzed through the information, thereby being beneficial to timely positioning faults and solving the problems in a targeted manner.
In some existing embedded operating systems (such as the RT-Thread operating system shown in fig. 1), the acquisition of real-time running state data of various peripheral devices is generally achieved through an interrupt management mechanism of a kernel layer, specifically, when the running state of a certain peripheral device changes, a receiving interrupt in a main Thread is triggered, the main Thread executes an update function in the receiving interrupt, so as to achieve the acquisition of real-time running state data of the peripheral device or update the real-time running state data of the peripheral device through feedback, and the receiving interrupt is exited after the update function is executed. Because the main thread continuously runs, the main thread continuously enters into the receiving interrupt triggered by each peripheral in the running process of the main thread so as to continuously acquire the real-time state data of each peripheral.
The data acquisition mechanism can effectively acquire the running state information of each peripheral when the embedded system is in a normal running state, however, when various abnormal states are encountered in the running process of the system, the data acquisition mechanism of the embedded system can be invalid and the reasons for the invalid are also various, and the following is analysis of partial abnormal states encountered by the embedded system and the reasons for the invalid of the data acquisition mechanism of the embedded system by the inventor:
Firstly, when the embedded system is in a development stage, as various hardware of the peripheral is in a model selection stage and a corresponding control program is also in a debugging stage, mismatching and instability of the hardware and errors, defects and the like of the control program can cause the system to crash, at the moment, interrupt management of a kernel layer triggers HardFault interrupt with extremely high priority, the interrupt further triggers restarting operation of a watchdog, and the system can not acquire real-time running state data of each peripheral, namely the real-time running state data of each peripheral is restarted by the watchdog, however, the real-time running state data of each peripheral just carries key information which can cause system faults before HardFault is interrupted.
Secondly, after the existing embedded operating system is interrupted by HardFault, the existing embedded operating system can send an error log to an external display device through a serial port by using an own log management mechanism, however, the method cannot meet the requirement of timely, completely and accurately acquiring real-time state data of each device, because,
1) Because of the transmission bandwidth limitation of the embedded system, the self-contained log management system strictly limits the data structure of the log information which is sent outwards after the access HardFault is interrupted, the complete log state data cannot be directly sent, and if the data acquisition and transmission functions are automatically modified or added at the HardFault interruption position, various unexpected risks caused by the change of a kernel layer are likely to exist;
2) The embedded operating system needs to be restarted through a watchdog under various crash conditions, and the specific mechanism is that the system cannot perform a watchdog feeding operation (the watchdog feeding refers to resetting of the restarting timing of the watchdog) after the watchdog is interrupted at HardFault, so that the hard restarting of the system is performed when the restarting timing of the watchdog reaches a set value, and the system cannot complete the acquisition and storage work of real-time state data of each peripheral before the restarting of the watchdog after the watchdog is interrupted at HardFault due to the high priority of HardFault interruption;
3) In the aspect of data storage, the existing embedded system is dependent on online debugging in the whole scheme, for example, information is directly read at a console through a serial port, and for data storage of offline debugging (testing), a scheme for comprehensively considering various conditions does not exist, even if the data can be stored offline by modifying information flow to a flash, the forwarding efficiency through a read+serial port is still low, and the transmission of the read flash+serial port still depends on online debugging.
Therefore, the data acquisition modes of various existing embedded systems need to be improved, so that the real-time state data of each peripheral can be timely, completely and accurately acquired under various states of system operation, particularly before restarting due to various faults.
To this end, the application provides a method for obtaining operation information of an embedded system, as described above, the operation information comprising real-time operation status data of at least one peripheral device of the embedded system. Fig. 2 shows a flow chart of the acquisition method, in some embodiments, as shown in fig. 2, comprising the steps of:
Step S100: executing a preset first scheme to acquire the running information and storing the running information in a first storage area of the embedded system;
Step S200: before the embedded system enters HardFault and is interrupted, executing a preset second scheme to transfer the running information from the first storage area to a second storage area.
In the embodiment of the application, the operation information is obtained when the embedded system is in the normal operation state through a preset first scheme and is stored in a first storage area of the embedded system; through a preset second scheme, when various faults which cause system breakdown occur in the embedded system, the running information is transferred from the first storage area to the second storage area before the system is restarted.
Fig. 3 further illustrates the execution of the first scheme and the second scheme included in the acquiring method in the main thread of the embedded operating system in some specific embodiments, as shown in fig. 3, after the embedded operating system starts the main thread, that is, after the embedded operating system executes various sub-threads, control programs, and the like in the main thread. In the embodiment of the application, in the normal operation process of the main thread, the real-time operation state data of each peripheral is continuously obtained through a preset first scheme and stored in a first storage area; before the main thread is interrupted by HardFault due to various faults, acquiring real-time running state data of each peripheral from the first storage area through a preset second scheme, transferring the real-time running state data to the second storage area, and then entering HardFault to interrupt and restarting the operating system by using a watchdog after the second scheme is executed.
Specific embodiments of the first and second aspects are further described below with reference to the drawings.
In an embodiment of the application, the first scheme comprises the following execution steps:
S101: the embedded system continues to run the main thread until at least one of the peripheral triggers receives an interrupt;
s102: executing a data updating function to acquire the real-time running state data of the peripheral equipment triggering the receiving interruption;
S103: storing the real-time running state data to the first storage area;
S104: and exiting the receiving interrupt.
In some specific embodiments (such as an embedded operating system for controlling a robot or an unmanned vehicle) described above, the main thread triggers the receiving interrupt when a state or a detection value (such as a rotation speed or torque of a motor, a temperature value monitored by a temperature sensor, or an angle of a steering engine, etc.) of a certain peripheral changes during operation, so that the system jumps to the inside of the receiving interrupt.
After the system jumps to the receiving interrupt, the real-time running state data of the peripheral device triggering the receiving interrupt can be obtained through a data updating function, and the data updating function can be written in a manner familiar to a person skilled in the art or an appropriate function is selected from the existing related function library so as to realize the functions.
After the real-time running state data is obtained, the real-time running state data can be stored in the first storage area, and then the corresponding receiving interrupt is exited after the steps are executed, so that the execution of the first scheme is ended, and the program which is being executed before the receiving interrupt is continuously executed.
In the embodiment of the present application, the first storage area may be an internal Memory, such as a Random-Access Memory (RAM), that directly exchanges data with the processor, and the storage area may be quickly read and written at any time, so that when the embedded system is in a normal running state, real-time state data of each peripheral device may be saved for reading by each control program running in the system, and the technology of saving data by using the internal Memory is known to those skilled in the art and will not be described herein.
Obviously, in a continuously running main thread, the first scheme may be executed multiple times, corresponding to the reception interruption caused by different peripherals, respectively. In some embodiments, the first scheme may be executed at least once in the same program running in the main thread, in other embodiments, the first scheme may be executed in different programs running in the main thread, respectively, and in other embodiments, the first scheme may be executed in different programs running in different sub-threads, respectively.
In an embodiment of the application, the second scheme comprises the following execution steps:
S201: interrupting a currently executing program;
S202: periodically resetting the countdown data of the watchdog until the latest updated real-time running state data of each peripheral device stored in the first storage area is transited to the second storage area in a traversing way.
In the embodiment of the application, the second scheme is executed when the embedded system has the conditions of memory overflow, wild pointer, pop stack and the like. In the running process of the embedded system, various reasons such as hardware faults/conflicts, program code errors, pointer jump errors or memory management errors and the like all cause the situation to occur, and further trigger HardFault to interrupt, because of the high priority of HardFault interrupt, once the program enters HardFault interrupt, each program running on an application layer cannot be executed until a watchdog initiates a restarting operation, in which case, running information stored in a first area is lost completely, so that valuable data for analyzing the fault cause is lost.
For this reason, in the embodiment of the present application, the second scheme is used to preempt HardFault to interrupt the protection of the system operation site when the embedded system encounters a system crash caused by different reasons, so as to avoid the loss of the latest updated operation information caused by the restart operation caused by the watchdog after the entering HardFault of the system is interrupted, and it is obvious that in the embodiment of the present application, the second storage area is a type of memory with a power-down data saving function, such as a charged erasable programmable read-only memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY, EEPROM), a Flash memory (Flash memory), and the like.
Fig. 4 illustrates a specific implementation of the second scheme by the embedded system in some specific embodiments, as shown in fig. 4, when a memory overflow occurs during the running process of the main thread, a wild pointer or a pop stack occurs, a currently executing program is first interrupted, then a first storage area is traversed, the real-time running state data updated by each peripheral device last time is transferred to the second storage area, during the transferring process, in order to avoid a system restarting operation caused by the watchdog, the countdown data of the watchdog needs to be periodically reset (i.e. a "feeding dog" operation is performed), until the transferring operation is completed in a traversing manner, after that, the feeding dog operation can be stopped and the restarting of the system is further implemented by the watchdog (according to the countdown state of the watchdog after the traversing is completed, the restarting may be implemented in the program interrupted by the second scheme, and may also be implemented after entering HardFault).
In the embodiment of the application, the second scheme is implemented at the application layer of the embedded system in a mode of executable programs or callable functions in the programs, and the second scheme is implemented at the application layer, so that various serious problems possibly caused by modification of a kernel layer when similar data transfer operation is implemented in HardFault interrupt can be avoided, meanwhile, the data quantity to be saved can be flexibly selected according to specific needs, and the problem that data cannot be completely saved because the data cannot be fed to dogs when data transfer processing is performed in HardFault interrupt is avoided by periodically resetting the countdown data of the watchdog in the process.
In some specific embodiments, the embedded system is an RT-Thread system, and the second scheme is executed at an application layer of the RT-Thread system. The applicant finds that in the running process of the embedded system based on RT-Thread development, besides the system breakdown state of HardFault interruption caused by the normal running state, memory overflow and the like, another operating system running error state exists, when the RT-Thread real-time operating system enters the operating system running error state, the CPU occupancy rate is not high, and the problems of memory overflow, pointer position error and the like caused by various obvious problems of software and hardware do not occur, so that the situation of triggering HardFault and triggering watchdog restarting operation does not exist, the only visible obvious phenomenon is that the systink updating frequency is rapidly reduced, the running frequency of each peripheral control program is seriously influenced, even the uncontrollable state that each peripheral is in non-reaction for a long time occurs, the problem cannot be solved by replacing a chip running the RT-Thread operating system, but the fault can be eliminated by restarting the operating system.
To this end, in some preferred embodiments of the present application, the operation information further includes systink data of the embedded system, and as shown in fig. 5, the obtaining method further includes step S300: and when the embedded system enters the operation error state of the operating system, executing a preset third scheme.
FIG. 6 illustrates a schematic diagram of a particular flow of executing a third scheme during the execution of a main thread of an embedded operating system, as shown in FIG. 6, in some particular embodiments, the third scheme comprising the steps of:
S301: acquiring the systink data and storing the systink data in the second storage area;
S302: restarting the embedded system.
In some specific embodiments, the systink data may be obtained by constructing an additional hardware timer interrupt, making a difference between the systink captured in the previous interrupt and the current systink and converting the difference into a time in the same unit when the hardware timer interrupt is triggered each time, and executing a third scheme when the two obtained systink intervals are abnormal, so as to restart the operating system.
In some preferred embodiments, the method further includes a step of transferring the operation information from the first storage area to the second storage area in a regular, non-regular or according to a preset trigger condition in a normal operation state of the system, so as to achieve timely and complete storage of the data.
The present application also provides, by way of example, a computer-readable storage medium storing, in some embodiments of the present application, an executable program that can be used to perform the aforementioned method of acquiring embedded system operation information. In particular, the computer readable storage medium may be a non-transitory computer readable storage medium, such as a high speed random access memory, having stored thereon a computer executable program that is executable by a processor or controller to implement all or part of the steps of the method of acquiring embedded system operational information described above.
While the foregoing is directed to embodiments of the present application, other and further embodiments of the application may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Claims (7)
1. A method for acquiring operation information of an embedded system, wherein the operation information comprises real-time operation state data of at least one peripheral of the embedded system, the method is characterized by comprising the following steps:
Executing a preset first scheme to acquire the running information and storing the running information in a first storage area of the embedded system;
executing a second preset scheme to transfer the operation information from the first storage area to a second storage area before the embedded system enters HardFault for interruption;
the first scheme includes the steps of:
the embedded system continues to run the main thread until at least one of the peripheral triggers receives an interrupt;
executing a data updating function to acquire the real-time running state data of the peripheral equipment triggering the receiving interruption;
Storing the real-time running state data to the first storage area;
exiting the reception interrupt;
The second scheme comprises the following steps:
interrupting a currently executing program;
Periodically resetting the countdown data of the watchdog until the latest updated real-time running state data of each peripheral device stored in the first storage area is transited to the second storage area in a traversing way.
2. The method for acquiring operation information of an embedded system according to claim 1, wherein the second scheme is executed when at least one of the following situations occur in the embedded system:
Memory overflow, wild pointer appearance and pop.
3. The method for acquiring the operation information of the embedded system according to claim 1, wherein:
The embedded system is an RT-Thread system, and
The second scheme is executed at an application layer of the RT-Thread system.
4. The method for acquiring operation information of an embedded system according to claim 1, wherein,
The operation information also comprises systink data of the embedded system, and the method for acquiring the operation information of the embedded system further comprises the following steps:
and executing a preset third scheme when the embedded system generates an operation error of the operating system.
5. The method for obtaining operation information of an embedded system according to claim 4, wherein the third scheme comprises the steps of:
Acquiring the systink data and storing the systink data in the second storage area;
Restarting the embedded system.
6. The method for acquiring the operation information of the embedded system according to claim 4, wherein:
The operating system running error is represented by the exception of the systink update frequency of the embedded system, but the HardFault interrupt is not triggered.
7. A computer-readable storage medium storing an executable program, wherein the executable program is capable of being used to perform the method of acquiring embedded system operation information according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310560683.5A CN116521418B (en) | 2023-05-16 | 2023-05-16 | Method for acquiring operation information of embedded system and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310560683.5A CN116521418B (en) | 2023-05-16 | 2023-05-16 | Method for acquiring operation information of embedded system and computer readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116521418A CN116521418A (en) | 2023-08-01 |
| CN116521418B true CN116521418B (en) | 2024-04-26 |
Family
ID=87404599
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310560683.5A Active CN116521418B (en) | 2023-05-16 | 2023-05-16 | Method for acquiring operation information of embedded system and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116521418B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170255728A1 (en) * | 2016-03-04 | 2017-09-07 | Synopsys, Inc. | Capturing Time-Slice of Emulation Data for Offline Embedded Software Debug |
| CN109614258A (en) * | 2018-11-26 | 2019-04-12 | 广东工业大学 | The control method of the electronic operating system of built-in Linux and its external monitoring module |
| CN113742113A (en) * | 2020-05-29 | 2021-12-03 | 上海微电子装备（集团）股份有限公司 | Embedded system health management method, equipment and storage medium |
| US20220113850A1 (en) * | 2020-10-09 | 2022-04-14 | Arris Enterprises Llc | Embedded product, method for displaying embedded product information and computer readable medium |
-
2023
- 2023-05-16 CN CN202310560683.5A patent/CN116521418B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170255728A1 (en) * | 2016-03-04 | 2017-09-07 | Synopsys, Inc. | Capturing Time-Slice of Emulation Data for Offline Embedded Software Debug |
| CN109614258A (en) * | 2018-11-26 | 2019-04-12 | 广东工业大学 | The control method of the electronic operating system of built-in Linux and its external monitoring module |
| CN113742113A (en) * | 2020-05-29 | 2021-12-03 | 上海微电子装备（集团）股份有限公司 | Embedded system health management method, equipment and storage medium |
| US20220113850A1 (en) * | 2020-10-09 | 2022-04-14 | Arris Enterprises Llc | Embedded product, method for displaying embedded product information and computer readable medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116521418A (en) | 2023-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111994094B (en) | Remote control take-over method, device, system, medium and unmanned vehicle | |
| US20230011677A1 (en) | Autonomous driving control system and control method and device | |
| US8321065B2 (en) | Method for controlling/regulating at least one task | |
| CN101713970B (en) | Method and systems for restarting a flight control system | |
| US9442793B2 (en) | Robust hardware/software error recovery system | |
| EP3301526B1 (en) | Controller, control method, and program | |
| US7428660B2 (en) | Starting control method, duplex platform system, and information processor | |
| CN111745650A (en) | Operation method of robot operation system and control method of robot | |
| CN116521418B (en) | Method for acquiring operation information of embedded system and computer readable storage medium | |
| US20090049336A1 (en) | Processor controller, processor control method, storage medium, and external controller | |
| JP2009129463A (en) | Processing method of temporary error in real time system of vehicle controller | |
| US20220055637A1 (en) | Electronic control unit and computer readable medium | |
| US8726099B2 (en) | Data processing system | |
| WO2018173910A1 (en) | Vehicle control device | |
| US11434846B2 (en) | Engine control device | |
| EP2555115A1 (en) | Device and method for restoring information in a main storage device | |
| CN112636881B (en) | Signal switching method and device and vehicle | |
| CN114637619A (en) | Vehicle controller and error management method thereof | |
| CN116521419B (en) | Control method of embedded operating system | |
| KR102471314B1 (en) | A System and Method of Health Management for On-the-fly Repairing of Order Violation in Airborne Software | |
| CN116991637B (en) | Operation control method and device of embedded system, electronic equipment and storage medium | |
| CN116893916A (en) | Log recording method and log recording device | |
| CN115755665A (en) | Monitoring management module and method, microcontroller, computer program and storage medium | |
| JP2003106211A (en) | Controllable for automobile internal combustion engine | |
| CN117008941A (en) | Interrupt processing program noninductive upgrading method and computer system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |