Web service system of lightweight embedded Bootloader

Abstract

The invention relates to a Web service system of a lightweight embedded Bootloader. The system comprises a Web front end server and a Web back end server, the Web front end comprises a UI module and a data processing module, and the UI module comprises a home page and sub-pages and is used for viewing and operating Bootloader data of different classifications on different sub-pages. The data processing module is only a main.js file, and the main.js file is used for receiving, transmitting, packaging and analyzing state data and control data of the Bootloader; the Web back-end server comprises a communication module and a Bootloader control module, the newly-added module only needs to expand a corresponding page and main.js interaction logic, back-end expandability is achieved, function expansion is achieved through a macro definition command, and the newly-added command does not need to modify communication task main logic.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a lightweight embedded Bootloader Web service system. Background Art

[0002] In today's interconnected world, embedded systems play an increasingly important role in various devices. These systems often require regular firmware updates to fix vulnerabilities or add new features. A bootloader is a special program responsible for loading the operating system or application when the device boots up. In embedded devices, managing the bootloader and updating the firmware are particularly critical.

[0003] With the rise of the Internet of Things (IoT), many devices require network management. Traditional bootloader management methods typically rely on command-line interfaces (CLIs) or specialized software and hardware, which limits user experience and operational convenience. Existing technical solutions often rely on complex command-line operations, are less intuitive, and lack flexibility in user interface design. Furthermore, some solutions consume a lot of resources in embedded environments, making them unsuitable for resource-constrained devices. Most existing solutions have fixed functionality and are difficult to quickly scale to meet user needs. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a lightweight embedded bootloader Web service system that overcomes the above problems or at least partially solves the above problems.

[0005] To achieve the above object, the present invention proposes a lightweight embedded bootloader Web service system, the system comprising: a Web front-end and a Web back-end server;

[0006] The web front-end consists of a UI module and a data processing module. The UI module consists of a homepage and various sub-pages, which are used to view and manipulate different types of Bootloader data on different sub-pages. The data processing module is only the main.js file, which is used to send, receive, package, and parse Bootloader status and control data.

[0007] The Web backend server includes a communication module and a Bootloader control module. The communication module calls the Lwip interface to apply for a socket, and is responsible for initializing the Web server, sending and receiving Web data, and parsing http requests. According to the parsing results, it sends control commands to the Bootloader control module, obtains the corresponding data, packages it, and sends return data to the Web; the Bootloader control module controls the Bootloader by calling the Bootloader base library interface, and puts the status data of the Bootloader control into the sending queue, which is sent to the Web front end by the communication module.

[0008] Preferably, the Web front end adopts the Layui framework to develop a modular front end interface, and realizes functional partitioning through the structure of nested sub-pages of Index.html, and each sub-page corresponds to an independent HTML file.

[0009] Preferably, the main.js file includes variables for front-end and back-end interaction defined in the form of global variables;

[0010] Global variables can be called by the HTML of each sub-page. The global variables include Bootloader control commands, received data parsing codes and local global variables.

[0011] Preferably, the control commands and data sent by the Web front end to the back end server are all issued by the post_requst() function defined in main.js.

[0012] Preferably, a timer is defined in the index homepage in the Web front end, and the timer periodically calls the poll_form_server() function in main.js to poll the Bootloader status data in the backend server.

[0013] Preferably, the Web command is defined in a macro definition manner, the value of the Web command corresponds to the received data parsing code in the Web front end, and the Web command is placed in the sending queue by the Bootloader control module; the communication module takes out the queue data in the execution function of the poll command and sends it to the Web front end via TCP, and the browser then parses the specific data according to the received data parsing code.

[0014] Preferably, the control data sent by the Web front end to the Web server via a post request is packaged in json format, and the Web server needs to parse the corresponding key value according to the key name of json.

[0015] Preferably, the http_post request in the Web server communication task is mainly used to interact with the Bootloader control task.

[0016] Preferably, the control command of the Web service system includes a poll command, which is periodically issued by the Web through a post request to periodically obtain the status data and log information of the Bootloader; the status data is divided into fixed data and non-fixed data;

[0017] Fixed data, including CPU temperature and DDR voltage, needs to be sent to the Web front-end in real time for display on the Web front-end graph. This data is sent to the Web front-end during each polling cycle.

[0018] Non-fixed data includes data generated by the Bootloader control task and stored in the data queue; this data is taken from the data queue and packaged into JSON format when the poll command is executed, and then sent to the Web front end via TCP. The Web front end parses and performs corresponding operations.

[0019] Preferably, the control command includes a file upload command, which is used in file stream requests in Web server communication tasks; when the Web front end issues an upload request, it will first establish a post request, which contains the file stream delimiter and file stream size that describe the subsequent file stream of the uploaded file, and the data stream of the file after the post request. The file information of the uploaded file is parsed in the post request, and the socket number of the request is recorded and saved in the corresponding data structure. In the subsequent requests, the socket number is used to determine whether each request is the data stream of this file. If so, the data stream extraction and saving operations are performed until the file stream end delimiter is found to indicate that the upload of the file is complete.

[0020] In an embodiment of the present invention, the Web service system of the lightweight embedded Bootloader includes: a Web front-end and a Web back-end server; the Web front-end includes a UI module and a data processing module, and the UI module includes a home page and various sub-pages, which are used to view and operate Bootloader data of different categories on different sub-pages. The data processing module is only the main.js file, which is used for sending and receiving, packaging and parsing the status data and control data of the Bootloader; the Web backend server includes a communication module and a Bootloader control module. The communication module calls the Lwip interface to apply for a socket, is responsible for initializing the Web server, sending and receiving Web data, and parsing http requests. It sends control commands to the Bootloader control module based on the parsing results, obtains the corresponding data and packages it and sends return data to the Web; the Bootloader control module controls the Bootloader by calling the Bootloaderbase library interface, and puts the status data of the Bootloader control into the sending queue, which is sent to the Web front end by the communication module through the Web interface. Users can operate intuitively, which lowers the usage threshold. It adopts a lightweight protocol stack and real-time operating system, which is suitable for resource-constrained embedded environments. The system architecture design makes it easier to add and modify subsequent functions, realizes front-end modularization, and independently manages functions through sub-pages. New modules only need to expand the corresponding pages and main.js interaction logic, realizing back-end scalability. Function expansion is achieved through macro definition commands. New commands do not need to modify the main logic of the communication task, but only need to add parsing and execution code in the control task. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 This is an architectural diagram of a lightweight embedded bootloader Web service system according to an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram of a Web front-end module division according to an embodiment of the present invention;

[0024] Figure 3 1 is a schematic diagram of a Bootloader control command according to an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram of an example of a received data parsing code according to an embodiment of the present invention;

[0026] Figure 5 This is an example schematic diagram of a local global variable according to an embodiment of the present invention;

[0027] Figure 6 is a schematic diagram of a post_requst function according to an embodiment of the present invention;

[0028] Figure 7 Schematic diagram of a Bootloaderweb backend server according to an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of an example of a Bootloader control command macro definition according to an embodiment of the present invention;

[0030] Figure 9 This is a schematic diagram of an example of a Bootloader web serverWEB command macro definition according to an embodiment of the present invention;

[0031] Figure 10 This is a schematic diagram of an example of a WebJSON data parsing key name macro definition according to an embodiment of the present invention;

[0032] Figure 11 Schematic diagram of a Bootloader web server initialization process according to an embodiment of the present invention;

[0033] Figure 12 Schematic diagram of a bootloader web server communication task flow in an embodiment of the present invention;

[0034] Figure 13 This is an example schematic diagram of a Web control command according to an embodiment of the present invention;

[0035] Figure 14 Schematic diagram of a Web control command parsing function according to an embodiment of the present invention;

[0036] Figure 15 This is a schematic diagram of an example of a file upload data structure according to an embodiment of the present invention;

[0037] Figure 16 1 is a schematic diagram of a Bootloader control task functional block diagram according to an embodiment of the present invention;

[0038] Figure 17 This is a Bootloaderweb management flow chart according to an embodiment of the present invention;

[0039] Figure 18The diagram is an internal structural diagram of a computer device according to an embodiment. DETAILED DESCRIPTION

[0040] In order to make the technical problems, technical solutions and beneficial effects solved by the embodiments of the present invention more clearly understood, the embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0041] Reference Figure 1 , shows an architecture diagram of a lightweight embedded bootloader Web service system according to an embodiment of the present invention, the system includes: a Web front-end and a Web back-end server;

[0042] This invention is a human-computer interaction system for managing bootloaders through browser-based operations. It aims to provide an efficient and convenient human-computer interaction interface for bootloader management, unlike traditional bootloader management methods that typically rely on command-line interfaces or dedicated software and hardware. This invention provides bootloader functions similar to those operated by traditional serial port commands, such as system status display, system parameter settings, encryption management, program uploads, and program updates. By establishing a web server within the machine, this invention enables users to configure and manage various bootloader parameters simply by accessing the corresponding IP address through a PC browser.

[0043] The front-end of this invention is developed using languages ​​such as HTML, JAVA Script, and CSS, and a UI interface is developed based on an open source framework. It features a simple structure, good portability, and a customized back-end bootloader control protocol, which provides high flexibility and good scalability. The back-end is developed in C language based on Lwip socket network programming. All functions are developed according to actual needs without excessive redundant code, greatly saving valuable embedded software and hardware resources while ensuring real-time control.

[0044] The front end of the present invention uses Layui as a template to develop the Web front end, and develops the Web back end server based on uC / OS-III and Lwip under the ZYNQ PS end. The back end server is developed from two sub-modules: the Web back end service module and the Bootloader control module. The principle block diagram is as follows Figure 1 shown.

[0045] The web service module provides an operating environment for the web front-end and exchanges control and status data between the web front-end and the bootloader control module. The bootloader control module primarily controls the bootloader system based on control data from the web service module. The bootloader control module is independent of the original bootloader control system, and web operations do not affect the original bootloader functions operated via the serial port, touch screen, or keystrokes.

[0046] The web front-end consists of two modules: the UI module and the data processing module. The UI module consists of a homepage and various sub-pages, which are used to view and manipulate different categories of Bootloader data on different sub-pages. The data processing module is only the main.js file, which is used to send, receive, package, and parse Bootloader status and control data.

[0047] The Web backend server includes a communication module and a Bootloader control module. The communication module calls the Lwip interface to apply for a socket, and is responsible for initializing the Web server, sending and receiving Web data, and parsing http requests. According to the parsing results, it sends control commands to the Bootloader control module, obtains the corresponding data, packages it, and sends return data to the Web; the Bootloader control module controls the Bootloader by calling the Bootloader base library interface, and puts the status data of the Bootloader control into the sending queue, which is sent to the Web front end by the communication module.

[0048] The Web front-end UI framework adopts the structure of nesting multiple xxx.html sub-pages in the Index.html homepage. Switch to different sub-pages through the homepage menu items. Each sub-page corresponds to an html source file. The Web front-end is generally divided into two modules: UI module and data processing module. The UI module consists of the homepage and various sub-pages. Users can view and operate different categories of Bootloader data on different sub-pages. The data processing module is only a main.js file, which is used for sending and receiving Bootloader status data and control data, as well as packaging and parsing, and finally transmits the data stream in TCP mode, such as Figure 2 shown.

[0049] In the embodiment of the present invention, the Web front end adopts the Layui framework to develop a modular front end interface, and realizes functional partitioning through the structure of nested sub-pages of Index.html, and each sub-page corresponds to an independent HTML file.

[0050] Preferably, the main.js file includes variables for front-end and back-end interaction defined in the form of global variables; global variables can be called by the HTML of each sub-page. The global variables include Bootloader control commands, received data parsing codes and local global variables.

[0051] Specifically in the embodiment of the present invention, the control commands and data sent by the Web front end to the back end server are all sent by the post_requst() function defined in main.js.

[0052] The control commands and data sent by the front-end Web to the back-end server are all issued by the post_requst() function defined in main.js, such as Figure 6 As shown. The parameter cmdR in post_requst() is the target URL. The Web server parses the command through the URL. When using it, cmdR is directly referenced as follows Figure 3 The Bootloader control command variable shown in the example above can be used (this variable must be the same as the macro defined by the web server for parsing Bootloader control commands; otherwise, parsing will fail successfully). The parameter dataR is the target data to be sent, and the data must be encapsulated in JSON format. Sync determines whether the post request is a synchronous or asynchronous request. When Sync is true, the request is sent asynchronously. When Sync is false, the request is sent synchronously.

[0053] Preferably, a timer is defined in the index homepage in the Web front end, and the timer periodically calls the poll_form_server() function in main.js to poll the Bootloader status data in the backend server.

[0054] If you need to quickly obtain certain data from the server and need to process it immediately, you can use Figure 6 The data returned by this function is the target data to be obtained, and the returned data is encapsulated in json format.

[0055] In the web, a timer is defined in the index homepage. The timer periodically calls the poll_form_server() function in main.js to poll the Bootloader status data in the backend server. For data that needs to be used multiple times or needs to be updated periodically, this method is used to periodically obtain it. For example, device CPU temperature data, voltage data, system time data, and system log data are all periodically obtained using this method. The returned data is obtained through Figure 4 The received data parsing code shown is parsed and saved in Figure 5The local global variables are used by each sub-page.

[0056] In an embodiment of the present invention, a macro definition is used in the Web backend server to define a Web command. The value of the Web command corresponds to the received data parsing code in the Web front end. The Web command is placed in the sending queue by the Bootloader control module; the communication module takes out the queue data in the execution function of the poll command and sends it to the Web front end via TCP, and the browser then parses the specific data according to the received data parsing code.

[0057] like Figure 8 As shown in the figure, the control commands of Bootloader are defined in the form of macro definitions. The values ​​of these macro definitions are consistent with those in the Web front end. Figure 3 The Bootloader control command value shown in the figure corresponds to the value of the Bootloader control command. After receiving the post request, the Web server parses the Bootloader control command through the data and the macro definition command.

[0058] Figure 9 The web command is defined in the macro definition mode. The value of the web command is the same as that in the front-end web. Figure 4 The received data parsing code corresponds to this command, which is usually placed in the send queue by the bootloader control module. The communication module extracts the queue data in the poll command execution function and sends it to the web front end via TCP. The browser then parses the specific data based on the received data parsing code.

[0059] The control data sent by the Web front end to the Web server through a post request is packaged in JSON format, so the Web server needs to parse the corresponding key value according to the JSON key name. Figure 10 Macro definitions for each JSON data key name. The key values ​​defined by the macros are consistent with the key values ​​sent by the front-end Web.

[0060] Web server initialization flow chart is as follows Figure 11 As shown in the figure, after initialization is completed, the Web server communication task and the Bootloader control task and their data transmission queues will be created.

[0061] The Bootloader web server communication task flow is as follows Figure 12As shown. The http_get request in the Web server communication task is mainly used by the browser to obtain the web page file and send it to the browser, which is then rendered into a web page by the browser. The http_post request in the Web server communication task is mainly used to interact with the Bootloader control task to implement the basic functions of the Bootloader. When the http post request is processed, the following will be called Figure 14 The web control command parsing function shown is based on Figure 13 The defined Web control command is used to parse the control command in the post request. If the command is simple, it can be executed in this task and the corresponding data will be returned. If the command takes a long time to execute, it will be passed to the Bootloader control task for execution.

[0062] The control commands of the web service system include the poll command, a special one among them. This command is periodically issued by the web server via a POST request to periodically obtain bootloader status data and log information. This data is divided into fixed and non-fixed data. Fixed data, such as CPU temperature and DDR voltage, needs to be sent to the web front-end in real time for display on the web front-end's graphs. This data is sent to the web front-end with each poll. Non-fixed data is typically generated by the bootloader control task and stored in a data queue. When the poll command is executed, this data is retrieved from the data queue, packaged into a JSON format, and sent to the web front-end via TCP. The web front-end parses the data and performs the corresponding operations. Examples of non-fixed data include the bootloader's operation log, progress bar data, and pop-up prompts.

[0063] Furthermore, the control command includes a file upload command. The file stream request in the Web server communication task uses the file upload command. The file upload command is another special command in the control command. When the Web front end issues an upload request, there will first be a post request. The request contains information such as the file stream delimiter and file stream size that describe the subsequent file stream of the uploaded file. The network request immediately after this post request is the data stream of the file, and other requests are also interspersed in it. Therefore, the file information of the uploaded file must be parsed in the post request, and the socket number of the request must be recorded and saved to the corresponding Figure 15In the data structure shown, the socket number is used in all subsequent requests to determine whether each request is the data stream of this file. If so, the data stream is extracted and saved until the file stream end delimiter is found and the file upload is completed. In this way, the file upload is realized.

[0064] The Bootloader control task is used to execute time-consuming task commands. It first parses the time-consuming task commands passed by the Web server communication task, and then starts to execute the corresponding functions. During the execution process, if there is any information that needs to be responded to by the Web, it will be placed in the data queue. Then, when the Web server communication task executes the poll command, it will be taken out from the data queue, packaged, and sent to the Web front end.

[0065] Bootloader control task functions such as Figure 16 shown.

[0066] Bootloaderweb management flow chart as follows Figure 17 As shown. The user opens a browser and enters the device IP in the address bar to enter the Bootloaderweb login interface. After entering the correct password, the user enters the device status display interface, which can monitor device voltage, temperature, log information, software version number, etc. Then, select the corresponding management function according to the needs. You can select any of the following functions for operation, as described below:

[0067] Network Management: Set network IP addresses and other information. Disk Management: Format disks and partitions. Program Update: Verify and update device firmware. Encryption Management: Encrypt and authorize device operations. System Self-Test: Test the device's DDR, ferroelectric chip, and display. System Settings: Set the device's startup options and language. Each operation generates an operation log to facilitate subsequent debugging and problem tracking. After each operation is completed, the user can continue with other operations or exit management.

[0068] In the embodiment of the present invention, a lightweight Web service architecture and implementation method based on the Zynq platform are constructed on the ARM processor (PS side) of the Zynq platform by integrating the uC / OS-III real-time operating system and the Lwip lightweight TCP / IP protocol stack to build a dual-task model: based on the Lwip HTTP protocol processing module, GET request (web page file transfer) and POST request (control command parsing) are implemented, and the JSON key value macro definition ( Figure 10 ) Quickly match front-end instructions. Independently execute time-consuming operations (such as program updates and disk formatting), and asynchronously interact with communication tasks through shared data queues to avoid front-end operation blocking. Use macro definition ( Figure 8-9) Unified management of commands and status codes, reducing code redundancy, achieving low memory usage, and meeting the needs of most embedded chip platforms.

[0069] Develop a modular interface based on the Layui front-end framework, using the Index.html nested sub-page structure ( Figure 2 ), supports dynamic loading of functional modules (such as network configuration, firmware update page), replacing traditional command line operations. Hybrid communication mode: Synchronous request: used for immediate response to key instructions (such as parameter setting, encryption authorization); Asynchronous polling (Poll command): obtains device status data (CPU temperature, voltage) through a timer cycle, and updates the front-end curve graph in real time ( Figure 4 ).

[0070] In the embodiment of the present invention, a custom protocol and efficient data transmission are realized, including the JSON data encapsulation specification: defining global variables ( Figure 3-5 ) Unified management of control commands, parsing codes and status data to achieve decoupling of front-end and back-end data. Phased file upload technology ( Figure 15 ): The front-end uploads the file stream in fragments based on XMLHttpRequest, and uses custom delimiters to mark the file boundaries; the back-end tracks the upload session through the Socket number, verifies and stores it in the fragment order, and avoids system resource exhaustion caused by large file transfers.

[0071] In the embodiment of the present invention, through the Web interface, users can operate intuitively, which lowers the usage threshold. It adopts a lightweight protocol and real-time operating system, which is suitable for resource-constrained embedded environments. The system architecture design makes the addition and modification of subsequent functions simpler, realizes front-end modularization, and independently manages functions through sub-pages. New modules only need to expand the corresponding pages and main.js interaction logic, realizing back-end scalability. Function expansion is achieved through macro definition commands. New commands do not need to modify the main logic of the communication task, and only need to add parsing and execution code in the control task.

[0072] In one embodiment, a computer device is provided. The computer device can be a PC or a ZYNQ platform device, or an overall system device composed of the two. The internal structure diagram can be as follows: Figure 18As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a web service system of a lightweight embedded bootloader is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the computer device housing, or an external keyboard, touchpad or mouse.

[0073] Those skilled in the art will understand that Figure 18 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0074] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps corresponding to the above system when executing the computer program.

[0075] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps corresponding to the above-described system are implemented. The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences between the other embodiments. The same or similar parts between the various embodiments can be referred to in detail.

[0076] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatus, or computer program products. Thus, embodiments of the present invention may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the process in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0078] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

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

[0080] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0081] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0082] The above is a detailed introduction to a lightweight embedded Bootloader Web service system provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A lightweight embedded Bootloader Web service system, characterized in that: The system includes: a Web front-end and a Web back-end server; The web front-end includes a UI module and a data processing module. The UI module consists of a homepage and various sub-pages, which are used to view and operate different categories of Bootloader data on different sub-pages. The data processing module is only the main.js file, which is used for sending, receiving, packaging, and parsing Bootloader status data and control data. The Web backend server includes a communication module and a Bootloader control module. The communication module calls the Lwip interface to apply for a socket, and is responsible for initializing the Web server, sending and receiving Web data, and parsing http requests. According to the parsing results, it sends control commands to the Bootloader control module, obtains the corresponding data, packages it, and sends return data to the Web; the Bootloader control module controls the Bootloader by calling the Bootloader base library interface, and puts the status data of the Bootloader control into the sending queue, which is sent to the Web front end by the communication module.

2. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The web front end uses the Layui framework to develop a modular front end interface, and realizes functional partitioning through the structure of nested sub-pages in Index.html, and each sub-page corresponds to an independent HTML file.

3. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The main.js file includes variables for front-end and back-end interaction defined in the form of global variables; global variables can be called by the HTML of each sub-page. The global variables include Bootloader control commands, received data parsing code and local global variables.

4. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The control commands and data sent by the Web front end to the back end server are all issued by the post_requst() function defined in main.js.

5. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: In the web front end, a timer is defined in the index homepage, and the timer periodically calls the poll_form_server() function in main.js to poll the Bootloader status data in the backend server.

6. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The web command is defined in a macro definition manner. The value of the web command corresponds to the parsing code of the received data in the web front end. The web command is placed in the sending queue by the bootloader control module. The communication module takes out the queue data in the execution function of the poll command and sends it to the Web front end via TCP. The browser then parses the specific data according to the received data parsing code.

7. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The control data sent by the Web front end to the Web server via a post request is packaged in json format, and the Web server needs to parse the corresponding key value according to the key name of json.

8. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The http_post request in the Web server communication task is mainly used to interact with the Bootloader control task.

9. The lightweight embedded Bootloader Web service system according to claim 1, characterized in that: The control commands of the Web service system include poll commands, which are periodically issued by the Web through post requests to periodically obtain the status data and log information of the Bootloader; the status data is divided into fixed data and non-fixed data; Fixed data, including CPU temperature and DDR voltage, needs to be sent to the Web front-end in real time for display on the Web front-end graph. This data is sent to the Web front-end during each polling cycle. Non-fixed data includes data generated by the Bootloader control task and stored in the data queue; this data is taken from the data queue and packaged into JSON format when the poll command is executed, and then sent to the Web front end via TCP. The Web front end parses and performs corresponding operations.

10. The lightweight embedded Bootloader Web service system according to claim 9, characterized in that: The control command includes a file upload command, which is used in file stream requests in Web server communication tasks. When the Web front end issues an upload request, a post request is first established. The post request contains a file stream delimiter and a file stream size that describe the subsequent file stream of the uploaded file. The data stream of the file after the post request is parsed in the post request to obtain the file information of the uploaded file, and the socket number of the request is recorded and saved in the corresponding data structure. In subsequent requests, the socket number is used to determine whether each request is the data stream of this file. If so, the data stream extraction and saving operations are performed until the file stream end delimiter is found to indicate that the upload of the file is complete.

Images