Multi-task scheduling method and device based on wearable device and electronic device

Abstract

The application provides a multi-task scheduling method and device based on a wearable device and an electronic device. The method comprises: determining a state mode of the wearable device, and monitoring an event signal triggered for the wearable device, the event signal containing an event identifier; determining a triggering event according to the event identifier, switching the state mode of the wearable device based on the triggering event, and executing a main task corresponding to the triggering event; monitoring a preset judgment condition for triggering execution of a sub-task in the execution process of the main task, and executing a sub-task corresponding to the judgment condition when the judgment condition is met when the triggering judgment condition is monitored; and scheduling the execution flow of the sub-task based on the running logic between the sub-tasks in the execution process of the sub-task, wherein the sub-task comprises a plurality of parallel processing sub-tasks caused by the main task triggered by the triggering event. The application can reduce the complexity of multi-task scheduling, and improve the flexibility and efficiency of multi-task scheduling.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of scheduling systems, and in particular to a multi-task scheduling method and device based on a wearable device and an electronic device. BACKGROUND

[0002] In the power-on running process of the wearable device, the system can provide a series of tasks for the wearable device to execute. Since the system resources are often limited, and some tasks consume a long time in the multi-task execution process, the system resources need to be continuously occupied, which directly affects the running efficiency of the system. Therefore, in order to avoid blocking caused by continuous occupation of resources by tasks, a scheduling system needs to be configured in the wearable device to schedule tasks. The following takes an intelligent safety helmet as an example to describe the multi-task scheduling process in the current scheduling system.

[0003] The intelligent safety helmet usually uses a single-chip microcomputer with a cortex-M0 core as the master control, uses C language for embedded programming, and improves the orderliness of multi-task scheduling by transplanting an existing embedded OS kernel. However, the scheduling mode of the OS kernel has the risk of space shortage and conflict with the BLE protocol stack. If the OS kernel is not used, and multi-task scheduling is performed through program bare running, the complexity of multi-task scheduling will be greatly improved, which brings difficulties to multi-task scheduling and also makes it difficult to upgrade the function. Therefore, the existing multi-task scheduling scheme improves the complexity of multi-task scheduling, reduces the execution efficiency of the scheduling system, and cannot flexibly schedule multi-tasks with complex logic, thereby affecting the stability of the system. SUMMARY

[0004] Therefore, the embodiments of the present application provide a multi-task scheduling method and device based on a wearable device and an electronic device to solve the problems of high complexity of multi-task scheduling, low execution efficiency of the scheduling system, and inability to flexibly schedule multi-tasks with complex logic in the prior art.

[0005] In a first aspect, the embodiments of the present application provide a multi-task scheduling method based on a wearable device, which includes determining the state mode of the wearable device and monitoring the event signal triggered for the wearable device, the event signal containing an event identifier; determining the triggering event according to the event identifier, switching the state mode of the wearable device based on the triggering event, and executing the main task corresponding to the triggering event; monitoring the preset judgment condition for triggering the execution of the sub-task during the execution of the main task, and executing the sub-task corresponding to the judgment condition when the triggering judgment condition is monitored; and scheduling the execution flow of the sub-task based on the running logic between the sub-tasks during the execution of the sub-task, wherein the sub-task includes multiple parallel processing sub-tasks under the main task caused by the triggering event.

[0006] In a second aspect, the embodiment of the present application provides a multi-task scheduling device based on a wearable device, which comprises a monitoring module configured to determine a state mode of the wearable device and monitor an event signal triggered for the wearable device, the event signal containing an event identifier; a switching module configured to determine a triggering event according to the event identifier, switch the state mode of the wearable device based on the triggering event, and execute a main task corresponding to the triggering event; an execution module configured to monitor a preset judgment condition for triggering execution of a sub-task during execution of the main task, and execute a sub-task corresponding to the judgment condition when the judgment condition is monitored; and a scheduling module configured to schedule an execution flow of the sub-task based on a running logic between the sub-tasks during execution of the sub-task, wherein the sub-task comprises a plurality of parallel processing sub-tasks under the main task caused by the triggering event.

[0007] In a third aspect, the embodiment of the present application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the program to implement the steps of the above method.

[0008] In a fourth aspect, the embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the above method.

[0009] The above at least one technical scheme adopted by the embodiment of the present application can achieve the following beneficial effects:

[0010] By determining the state mode of the wearable device and monitoring the event signal triggered for the wearable device, the event signal containing the event identifier, the triggering event is determined according to the event identifier, the state mode of the wearable device is switched based on the triggering event, and the main task corresponding to the triggering event is executed; during execution of the main task, the preset judgment condition for triggering execution of the sub-task is monitored, and the sub-task corresponding to the judgment condition is executed when the judgment condition is monitored; during execution of the sub-task, the execution flow of the sub-task is scheduled based on the running logic between the sub-tasks, wherein the sub-task comprises a plurality of parallel processing sub-tasks under the main task caused by the triggering event. The present application can reduce the complexity of multi-task scheduling, reduce the difficulty of multi-task scheduling, improve the execution efficiency of the scheduling system, can flexibly schedule the multi-task of complex logic, and thus improve the stability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0012] Figure 1 is the overall architecture of the multi-task scheduling system involved in the actual application scenario of the embodiment of the present application;

[0013] Figure 2 is the flowchart of the multi-task scheduling method based on wearable device provided by the embodiment of the present application;

[0014] Figure 3 is the switching flowchart of the state mode of the intelligent safety helmet provided by the embodiment of the present application;

[0015] Figure 4 is the implementation flowchart of the sleep mode of the intelligent safety helmet provided by the embodiment of the present application;

[0016] Figure 5 is the implementation flowchart of the working mode of the intelligent safety helmet provided by the embodiment of the present application;

[0017] Figure 6 is the scheduling and event switching diagram of the intelligent safety helmet provided by the embodiment of the present application;

[0018] Figure 7 is the structure diagram of the multi-task scheduling device based on wearable device provided by the embodiment of the present application;

[0019] Figure 8 is the structure diagram of the electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0020] In the following description, specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, persons skilled in the art will understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed description of well-known systems, devices, circuits and methods is omitted so as not to obscure the description of the present application with unnecessary details.

[0021] As described above, in order to avoid the occurrence of task waiting and blocking and reduce the continuous occupation of system resources during the multitasking of the wearable device, a scheduling system needs to be configured in the master control of the wearable device to coordinate the occupation of system resources by multiple tasks and realize task scheduling between multiple tasks. In addition, with the development of embedded systems, the scenarios in which embedded systems support multitasking are becoming more and more widespread. The following takes an intelligent safety helmet as an example to illustrate the current multitasking scheduling scheme and problems in the scheduling system, which can specifically include the following contents:

[0022] The intelligent safety helmet usually uses a single-chip microcomputer with a cortex-M0 core as the master control and uses C language for embedded programming. Since the master control chip of the intelligent safety helmet usually has a BLE protocol stack embedded therein, the operation capacity and flash space of the master control chip are limited, but it needs to handle all the interaction processes of the intelligent safety helmet, which is very inconvenient to use.

[0023] Currently, transplanting an existing embedded OS kernel (such as eCOS or freeRTOS) will make the scheduling more organized, but the scheduling mode of the embedded OS kernel has the risk of space shortage and conflict with the BLE protocol stack; however, if an OS kernel is not used and multitasking is directly scheduled by a program running nakedly (NONE-OS), complex multitasking will bring difficulties to scheduling, and subsequent function upgrades cannot be performed, nor can the scheduling of subtasks caused by events be realized.

[0024] As can be seen, since most BLE protocol single-chip microcomputers on the market currently have a cortex-M0 core, different open source OSs are transplanted for work, so only simple interaction with other peripherals (such as serial ports and SPIs) can be performed outside the BLE protocol, and a separate MCU (single-chip microcomputer) is used to process complex task processes. Although this can separate protocol processing and process scheduling and divide complex overall functions, this scheduling scheme has the following problems: using a separate MCU not only increases hardware costs but also greatly increases maintenance costs, affecting the overall stability of the system.

[0025] In view of the problems in the prior art, on the premise of guaranteeing the overall stability of the system, it is particularly important to provide a scheme that can realize all task scheduling using a single-chip microcomputer with a BLE protocol based on comprehensive consideration of space cost and performance. Therefore, an embedded scheduling system between an OS and a NONE-OS is designed in the embodiment of the present application, and a multi-task scheduling method realized based on the embedded scheduling system can reduce the complexity and difficulty of multi-task scheduling, improve the execution efficiency of the scheduling system, flexibly schedule multi-tasks with complex logic, and improve the stability of the system.

[0026] The overall architecture of the system involved in the practical application scenario of the embodiment of the present application will be described below with reference to the accompanying drawings, Figure 1 is a schematic diagram of the overall architecture of the multi-task scheduling system involved in the practical application scenario of the embodiment of the present application. As Figure 1 indicated, the overall architecture of the multi-task scheduling system can specifically include:

[0027] The execution subject of the embodiment of the present application can be considered as an embedded scheduling system configured in the main control chip of the intelligent safety helmet. In the embedded scheduling system of the intelligent safety helmet, the embedded scheduling system can be divided into the following four layers from bottom to top: a physical layer, a protocol layer, an event and task layer, and an application layer. The physical layer is configured to configure all peripherals, including IO, SPI, IIC, UART, etc., so as to initialize the external Flash memory, pressure sensor, and G-SENSOR (acceleration sensor). The protocol layer mainly includes a serial port working task (_task_uart), which performs protocol processing on the input and output data of the serial port, and realizes the isolation of the physical layer and the upper layer architecture. The event and task layer is the embodiment of the five state modes of the intelligent safety helmet. Since the specific tasks of each state mode are different, and only one state mode can exist at the same time, the event and task layer becomes the core part of the entire scheduling system. The application layer schedules all events and tasks according to the actual functions of the intelligent safety helmet and relies on the Real-Time Clock (RTC).

[0028] It should be noted that the following embodiments of the present application take the intelligent safety helmet in the field of building construction as a wearable device, and describe the multi-task scheduling of the embedded scheduling system in the intelligent safety helmet as an application scenario. However, the wearable device in the embodiment of the present application includes but is not limited to the intelligent safety helmet, and the application scenario of the embodiment of the present application is not limited to multi-task scheduling in the field of building construction. Any other scenario of multi-task scheduling based on a wearable device is applicable to the present scheme, and the above application scenario does not constitute a limitation on the technical scheme.

[0029] Figure 2 is a flowchart of a multi-task scheduling method based on a wearable device provided by an embodiment of the present application. Figure 2 The multi-task scheduling method based on a wearable device can be executed by an embedded scheduling system in the smart safety helmet. As shown in Figure 2 The multi-task scheduling method based on a wearable device can specifically include:

[0030] S201, determining a state mode of the wearable device, and monitoring an event signal triggered for the wearable device, the event signal containing an event identifier;

[0031] S202, determining a triggering event according to the event identifier, switching the state mode of the wearable device based on the triggering event, and executing a main task corresponding to the triggering event;

[0032] S203, monitoring a preset judgment condition for triggering execution of a sub-task in the execution process of the main task, and executing a sub-task corresponding to the judgment condition when the judgment condition is monitored;

[0033] S204, scheduling an execution flow of the sub-tasks based on a running logic between the sub-tasks in the execution process of the sub-tasks, wherein the sub-tasks include a plurality of parallel processing sub-tasks caused by the main task triggered by the triggering event.

[0034] Specifically, the state mode of the wearable device in the embodiment of the present application includes but is not limited to the following five modes: factory mode, factory test mode, activation mode, hibernation mode and working mode. Each state mode corresponds to a main task, i.e. factory task, factory test task, activation task, hibernation task and working task. In actual application, the above five tasks can be scheduled according to specific triggering events, i.e. switching between tasks, and the smart safety helmet (hereinafter also referred to as the device) can only have one main task running at the same time. The system determines whether to schedule a certain main task according to whether it is registered, whether it is in working hours and other conditions. All main tasks need to be registered at initialization, set when needed to run, and unregistered when other main tasks need to be executed.

[0035] Further, the triggering event of the wearable device can be a key event or a clock event. For example, in the factory mode, the user can trigger an SOS key event by clicking the SOS key on the smart safety helmet, and generate a corresponding event signal. At this time, the smart safety helmet is switched from the factory mode to the factory test mode. In another embodiment, in the activation mode, the smart safety helmet switches from the activation mode to the hibernation mode or the working mode by judging the current time. For example, when the time is 06:00-21:00, the smart safety helmet is switched from the activation mode to the working mode according to the clock.

[0036] Further, the most basic in the multi-task scheduling system is the definition and operation of events and tasks, the event refers to the message type that the scheduling system needs to wait for, a certain event will cause the running or cancellation of the related task; and the task is the program that needs to be run when a certain event occurs. All events and tasks can be registered, set and cancelled by the scheduling system, thereby ensuring the flexibility and reliability of the overall function of the system. In the initialization process of the multi-task scheduling system, the corresponding events and tasks need to be registered first, and the events and tasks are bound, the task is set when it needs to run, the task is cancelled when other tasks need to be executed, and then the corresponding tasks are switched by setting and cancelling the events, thereby completing the switching between different state modes.

[0037] Further, in addition to the main task in the multi-task scheduling system, that is, in addition to the corresponding multiple state modes under different conditions, there are different sub-tasks under different state modes, and the sub-tasks under different main tasks may overlap, for example, the sleep mode and the working mode may have multiple same sub-tasks. In actual application, in addition to scheduling the main task, since there are different sub-tasks under a single state mode, different sub-tasks occupy different resources, some sub-tasks only occupy a few resources and are released, and some sub-tasks continuously occupy CPU resources at the same time, so the sub-tasks also need to be scheduled.

[0038] According to the technical scheme provided by the embodiment of the application, the state mode of the wearable device is determined, and the event signal triggered for the wearable device is monitored, the event signal containing an event identifier; the triggering event is determined according to the event identifier, the state mode of the wearable device is switched based on the triggering event, and the main task corresponding to the triggering event is executed; in the execution process of the main task, the preset judgment condition for triggering the execution of the sub-task is monitored, when the triggering judgment condition is monitored, the sub-task corresponding to the judgment condition is executed; in the execution process of the sub-task, the execution flow of the sub-task is scheduled based on the running logic between the sub-tasks, and the sub-task includes multiple parallel processing sub-tasks of the main task caused by the triggering event. The application can reduce the complexity of multi-task scheduling, reduce the difficulty of multi-task scheduling, improve the execution efficiency of the scheduling system, can realize flexible scheduling of complex multi-task, and thereby improve the stability of the system.

[0039] In some embodiments, before determining the state mode of the wearable device, the method further comprises: registering a predetermined trigger event, establishing a binding relationship between the trigger event and the main task, and configuring a corresponding setting interface and a cancellation interface for the trigger event; wherein each trigger event corresponds to a state mode, and the setting interface and the cancellation interface are respectively used for performing setting and cancellation operations on the state mode during the switching process of the main task.

[0040] Specifically, during the initialization process of the multi-task scheduling system, the trigger event and the corresponding task are registered respectively, and the main task caused by the trigger event is bound. In addition to using the interface to register the event and the task, a corresponding setting interface and a cancellation interface are also configured for the event. The registration using interface is completed during system initialization, the setting interface is used to set the next event task when the previous task is running, and the cancellation interface is used to cancel the previous event task when the next event task starts.

[0041] Further, since the trigger event and the main task are pre-configured during initialization, the corresponding main task can be directly run after the trigger event occurs. In actual application, the event and the task are registered respectively, and the event and the task are bound, the task is set when it needs to be run, the task is cancelled when it needs to be executed, and then the corresponding task is switched by setting the event and cancelling the event, so as to complete the switching between different state modes.

[0042] In some embodiments, determining the state mode of the wearable device comprises: determining the state mode of the wearable device according to the current running state of the wearable device, wherein the state mode comprises a factory mode, a factory test mode, an activation mode, a hibernation mode and a working mode.

[0043] Specifically, different state modes are triggered under different conditions. Here, determining the state mode of the wearable device means determining the state mode in which the wearable device is currently located. The five state modes of the intelligent safety helmet, the trigger conditions and the trigger events are described in detail below in combination with the drawings and specific embodiments, Figure 3 is a switching process schematic diagram of the state mode of the intelligent safety helmet provided by the embodiments of the present application. As Figure 3 shown, the switching process of the state mode of the intelligent safety helmet can include:

[0044] The intelligent safety helmet can include five state modes, i.e. factory mode, factory test mode, activation mode, hibernation mode and working mode. After the production of the intelligent safety helmet is completed, the factory mode is entered, at this time, the factory test mode can be switched to through the SOS key, the intelligent safety helmet is detected for yield and function screening, and after completion, it is jumped back to the factory mode; the activation mode can also be switched to through the BOOT key, the server of the intelligent safety helmet is registered; if the registration is successful, the intelligent safety helmet switches between the hibernation mode and the working mode by judging the current time, for example, when the current time is from 21:00 to 06:00 the next day, the intelligent safety helmet switches to the hibernation state, the device does not work, otherwise, it enters the working mode, all peripherals of the device are in the working state.

[0045] In some embodiments, monitoring an event signal triggered for the wearable device includes: when a key operation for the wearable device is monitored, generating an event signal corresponding to a key event triggered according to the key operation; and / or when it is monitored that the time is within a preset clock requirement range, generating an event signal corresponding to a clock event triggered according to the time.

[0046] Specifically, the events for triggering the state mode switching (i.e. main task switching) mainly include two types, i.e. key event and clock event, the key event refers to the event triggered by the user by clicking the key, such as by pressing the SOS key or the BOOT key, the state mode of the intelligent safety helmet can be jumped to the factory test mode or the activation mode. The clock event refers to judging whether the state mode should be in the hibernation mode or the working mode according to the current time, and switching it. The implementation and functions of the five state modes of the intelligent safety helmet will be described in detail below in combination with specific embodiments, which can specifically include the following contents:

[0047] After the production of the intelligent safety helmet is completed, the factory mode is entered by default. In the factory mode, the device will close all peripherals such as SPIFlash, two sensors (i.e. pressure sensor and six-axis sensor), core chip RV1109 and 4G module, and be in the low-power state of RTC and IO port that can be awakened. At this time, the user can press the two external keys SOS and BOOT to jump the state mode of the intelligent safety helmet to the factory test mode or the activation mode.

[0048] In the factory mode, the device turns on all peripherals and powers on the core chip and the 4G module. At this time, the main control chip performs IO detection, Flash detection, SENSOR detection and BLE detection, and the core chip simultaneously performs EMMC mounting detection, CAMERA detection and 4G detection. If all the detections are successful, the main control chip and the core chip perform data interaction to synchronize the detection results, at this time, the interaction data includes the self-test results of each module in the main control board and the core board, that is, the test result data, so as to simultaneously detect the main control board and the core board, and then jump to the factory mode; if there is an abnormality in the detection, the device will continue to detect for five minutes in this state, and after the five-minute timing is over, whether the detection is successful or not, the detection results will be synchronized and then jump to the factory mode.

[0049] In the active mode, the device turns on the power of the core chip and the 4G module, and informs the 4G module to register and activate through a protocol instruction. The core chip connects to the server through the 4G module and performs registration, if the registration is successful, the device updates the RTC time and jumps to the sleep mode or the working mode according to the current time; if the registration is unsuccessful, the device turns off other power supplies to enter a low-power state, and waits for four hours to perform the activation operation again, and does not jump to the factory mode.

[0050] Further, the implementation process of the sleep mode will be described in detail below in combination with the drawings and specific embodiments, Figure 4 is the implementation flowchart of the sleep mode of the intelligent safety helmet provided by the embodiments of the present application. As Figure 4 shown, the implementation process of the sleep mode of the intelligent safety helmet can include:

[0051] The default working time of the device is from 06:00 to 21:00, and the device is in the sleep mode state at other times. In this mode, it is first judged whether the current time is in the working time, if not, the device will turn off the IO interface and the Flash memory which are not needed to work, but the G-SENSOR (six-axis sensor or acceleration sensor) is retained and set to the interrupt mode. It should be noted that the G-SENSOR has two working modes: interrupt mode and FIFO mode, in the interrupt mode, the interrupt IO of the G-SENSOR only has a rising edge output when it shakes, which is used for waking up the main control chip in the sleep mode; in the FIFO mode, the G-SENSOR continuously collects acceleration data and outputs according to a certain pre-set period, which is used for motion trajectory judgment in the working mode.

[0052] In the hibernation mode, the device is always in the RTC low-power state. When the G-SENSOR has more than 2 vibration outputs within 10 seconds, the device will jump from the hibernation mode to the working mode, and work for 10 minutes, and then determine the mode in which the device should be at this time according to the current RTC time. If the G-SENSOR does not generate an interrupt during the whole hibernation time, the device will also jump according to the RTC time.

[0053] Here, the real-time clock (RTC) can be understood as a clock circuit composed of a crystal oscillator on the motherboard and related circuits. The RTC generates a lower frequency clock through circuit frequency conversion, and the clock is incremented by one after each cycle and can be initialized through the RTC. Based on the time period set by the RTC timer, when a certain time period is reached, the corresponding function module or CPU can be automatically triggered to start and stop.

[0054] Further, the implementation process of the working mode will be described in detail below in combination with the drawings and specific embodiments, Figure 5 is a schematic diagram of the implementation process of the working mode of the intelligent safety helmet provided by the embodiments of the present application. As Figure 5 shown, the implementation process of the working mode of the intelligent safety helmet can include:

[0055] In the working mode, all peripherals are turned on and off, the core chip RV1109 and the 4G module power supply are turned off, iBeacon and sensor data are collected, and the RV1109 is turned on and an instruction is sent to take a picture at a set time interval (such as 3600 seconds), and the collected data is transmitted to the RV1109 through the serial port. Whenever the fourth picture is taken, the main control chip will also turn on the 4G module power supply and send an instruction to make the RV1109 upload the video taken and all the data obtained to the cloud server. After the shooting or data uploading is completed, the task jumps to the beginning and determines the starting state of the current RTC time.

[0056] In some embodiments, the triggering event is determined according to the event identifier, and the state mode of the wearable device is switched based on the triggering event, including: searching for a predetermined triggering event according to the event identifier, obtaining a triggering event corresponding to the event identifier, and determining a state mode corresponding to the triggering event, so as to switch the state mode of the wearable device to the state mode of the triggering event corresponding to the event identifier.

[0057] Specifically, according to the event identifier of the trigger event, it is determined which one of the pre-registered events the trigger event corresponds to, since each pre-registered event corresponds to its own event identifier, the type of the trigger event can be determined by looking up the event identifier. In actual applications, the event identifier can be a handle defined in advance for each trigger event, that is, an identifier defined for each event and task. All events and tasks in the multi-task scheduling system have unique handles. For example, the handle of the factory event can be MODE_FACTORY, and the handle of the work event can be MODE_WORK.

[0058] Further, since the intelligent safety helmet has five state modes, the multi-task scheduling system defines five corresponding events and tasks. The correspondence between the events and tasks will be described below in combination with the chart.

[0059] Table 1: Correspondence between state modes and events / tasks

[0060] State mode Corresponding event Corresponding task Factory mode MODE_FACTORY _task_mode_factory Test mode in factory MODE_TEST_IN_FACTORY _task_mode_test_in_factory Activation mode MODE_ACTIVATION _task_mode_activation Sleep mode MODE_SLEEP _task_mode_sleep Work mode MODE_WORK _task_mode_work

[0061] It should be noted that the scheduling system first registers the corresponding events and tasks in the initialization stage, and switches the corresponding tasks by setting and unregistering the events in actual operation, thereby completing the switching between different state modes.

[0062] For example, register the factory event and task using the interface:

[0063] event_register_event(&gs_event_handle,_task_mode_factory,NULL,MODE_FACTORY);

[0064] Set the factory mode event using the interface:

[0065] event_set_event(&gs_event_handle, NULL, MODE_FACTORY);

[0066] Unregister the factory mode event using the interface:

[0067] event_clear_event(&gs_event_handle, MODE_FACTORY)。

[0068] In some embodiments, switching the state mode of the wearable device to the state mode of the trigger event corresponding to the event identification comprises: setting a second event at the end of a first event corresponding to the state mode of the wearable device by using a setting interface corresponding to the state mode of the trigger event, and unregistering the first event at the beginning of the second event by using an unregistering interface of the state mode of the wearable device, so as to switch the state mode of the wearable device from the state mode of the first event to the state mode of the second event.

[0069] Specifically, in the actual operation of the scheduling system, the switching of the state mode of the intelligent safety helmet can be performed by setting an event and unregistering the event, that is, the switching between different state modes is realized by event switching. The switching process of the state mode of the intelligent safety helmet is described in detail below with reference to the accompanying drawings and specific embodiments. Figure 6 FIG. 1 is a schematic diagram of scheduling and event switching of an intelligent safety helmet provided by an embodiment of the present application. As shown in FIG. 1, the process of scheduling and event switching of the intelligent safety helmet can include: Figure 6

[0070] After the handle definition of all events and tasks and the establishment of the event and task stack are completed in the initialization phase, each event corresponds to a main task, and the events are dynamically switched by connecting all events and tasks in series. The advantage of this dynamic switching is that when the device working scene or requirement is changed, only a small adjustment is needed to meet the change requirement, which greatly saves the labor cost and time cost.

[0071] In the scheduling process shown in FIG. 2, the intelligent safety helmet scheduling system first initializes itself, defines the handle of the scheduling itself, and establishes the event and task stack. Then, all events are registered, that is, the five state modes of the intelligent safety helmet are defined respectively and bound to the corresponding tasks. Then, other tasks independent of the five state modes, such as the serial port task and the BLE clock task, are registered separately, and the current state mode is judged and set to ensure the independence of its function and serve other five state modes of events. Finally, the scheduling is performed according to the specific scene, and the switching of different events is completed according to the specific use scene. Figure 6

[0072] For example, when the current state mode of the intelligent safety helmet is the active mode, taking the switching between the active mode and the sleep mode and the working mode as an example, 9:00-21:00 is defined as the working time, the clock triggers the running of the working event, and the other time is the sleep time, and the clock triggers the running of the sleep event.

[0073] ​​Since only one event (i.e. only one state mode) is allowed to be set at a time point, the exclusivity of event switching is also guaranteed. In order to achieve this requirement, the scheduling system adopts a method similar to mutual exclusion, such as when event 1 needs to be unregistered and event 2 needs to be set, event 2 is first set at the end of event 1, and then event 1 is unregistered at the beginning of the running of event 2, so that only one event representing five state modes is set at a time point, avoiding the confusion of the scheduling system.

[0074] The above embodiments mainly introduce the scheduling between state modes, i.e. the scheduling of the main task triggered by the trigger event, but each main task triggered by the event also contains a plurality of sub-tasks, and the sub-tasks may also cause simultaneous occupation of CPU resources in the running process. Therefore, the embodiments of the present application also include the scheduling of the sub-tasks, and the scheduling process between the sub-tasks under the main task triggered by the event will be described below in combination with specific embodiments.

[0075] In some embodiments, during the execution of the main task, the preset judgment condition for triggering the execution of the sub-task is monitored, and when the trigger judgment condition is monitored, the sub-task corresponding to the judgment condition when the judgment condition is satisfied is executed, including: during the running of the main task, the time and the task execution times for triggering the sub-task are monitored, and when the time or the task execution times satisfy the judgment condition, the sub-task corresponding to the judgment condition is executed, wherein the judgment condition includes a time judgment condition and a number of times judgment condition.

[0076] Specifically, during the execution of the main task triggered by the trigger event, some judgment conditions can further trigger the sub-tasks, and the conditions for triggering the sub-tasks are generally divided into two categories, i.e. RTC clock and task execution times, in other words, after the event triggers the main task, the main task continuously monitors the time and the task execution times in the running process, and triggers the corresponding sub-tasks according to the judgment conditions; for example, the following sub-tasks can also be executed under the main task corresponding to the working mode: collecting sensor data, iBeacon scanning, writing Flash, etc. Since some sub-tasks may need to run simultaneously, and there is also some internal running logic between the sub-tasks, the participation of the scheduling system is still required in the running process of these sub-tasks.

[0077] In some embodiments, during the execution of the sub-tasks, the execution process of the sub-tasks is scheduled based on the running logic between the sub-tasks, including: during the running of the sub-tasks, the sub-task execution switching operation is performed according to the running logic between different sub-tasks under the main task, so as to schedule the execution process of the sub-tasks, wherein the running logic between the sub-tasks includes judging different conditions in preset different clocks.

[0078] Specifically, the running logic between the sub-tasks can be considered as the logic of judging different conditions in different RTC clocks, for example, taking the sub-task of iBeacon scanning in the working mode as an example, the RTC clock triggers the iBeacon scanning sub-task to start execution, if the iBeacon is scanned, the scanned iBeacon data is written into the Flash memory, and if the iBeacon is not scanned, the Flash memory is not written. Therefore, the running logic between the sub-tasks is actually the scheduling operation between the sub-tasks on the time slice through the RTC.

[0079] It should be noted that the state mode of the intelligent safety helmet is a main task triggered by an event under certain conditions, and during the running of the main task, when a certain judgment condition is met, a corresponding sub-task is triggered. Therefore, the sub-task in the embodiment of the application is not necessarily triggered by an event, but a sub-task triggered in the running process of the main task under certain judgment conditions after the event triggers the main task.

[0080] In some embodiments, after the wearable device is powered on, the initialization operation is performed on the preset serial port working task, and the serial port working task is continuously run, the serial port working task is used for analyzing the serial port data of the main control chip and the core chip in the wearable device, and the analyzed serial port data is uploaded or the upper layer data is framed according to the protocol.

[0081] Specifically, in the embodiment of the application, the scheduling system will establish a serial port working task (_task_uart) during initialization, and the serial port working task is independent of the other five state modes. The serial port working task is specially used for processing the serial port data interaction of the main control chip and the core chip, and uploading the analyzed serial port data or framing the upper layer data according to the protocol.

[0082] As can be seen, in the embodiment of the application, the tasks triggered by the system are divided into two kinds, one is the continuously running task, and the other is the task triggered by the event or condition. The continuously running task after the device is powered on is triggered by the system clock, and the task triggered by the event or condition is judged by the RTC real-time clock, therefore, the serial port working task and the main task and the sub-task are two tasks with different running logics, when the clocks of the two tasks conflict, the RTC clock is given priority, that is, the priority of the task running by the condition is higher than that of the always running task.

[0083] Further, in the embodiment of the present application, the wearable device includes but is not limited to a smart safety helmet, a smart watch, smart glasses and the like. The wearable device is a device integrating functions of a hardware device, software, data interaction, mobile communication and the like. The wearable device can be provided with a key or a touch screen. A user triggers a corresponding function by clicking the key or the touch screen. The wearable device can automatically execute a predetermined function according to a period, such as automatically executing iBeacon scanning and automatically performing wearing detection. In actual application, different wearable devices can be selected according to different application scenarios. For example, in the construction scene of the embodiment of the present application, a smart safety helmet and a smart glasses and the like can be used.

[0084] In addition, the chip, Bluetooth module, pressure sensor and the like used in the wearable device can be selected according to actual needs and application scenarios. For example, the main control chip can be a Bluetooth chip BLUENRG355 with a cortex-M0 core of ST, and the core chip can be a visual chip RV1109 of ROCKCHIP. Therefore, the specific type of module or device used does not constitute a limitation on the technical scheme of the present application.

[0085] According to the technical scheme provided by the embodiment of the present application, the multi-task scheduling method based on the wearable device can not only schedule the main task caused by the event, but also schedule the sub-task under the main task caused by the event. Therefore, the scheduling of tasks of different types and conditions can be realized, and the flexibility of multi-task scheduling is increased. When scheduling the sub-task, the execution of the sub-task triggered by the event is not relied on, but the running logic of the sub-task itself is relied on. The corresponding sub-task is triggered by judging the condition, so that the stability of the system is guaranteed. The present application can reduce the complexity and difficulty of multi-task scheduling, improve the execution efficiency of the scheduling system, and is conducive to the subsequent upgrading of the functions of the smart safety helmet.

[0086] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the method embodiment of the present application.

[0087] Figure 7 is a structural schematic diagram of the multi-task scheduling device based on the wearable device provided by the embodiment of the present application. As shown in Figure 7 The multi-task scheduling device based on the wearable device includes:

[0088] The monitoring module 701 is configured to determine the state mode of the wearable device and monitor the event signal triggered for the wearable device. The event signal contains an event identifier.

[0089] The switching module 702 is configured to determine a trigger event according to the event identifier, switch the state mode of the wearable device based on the trigger event, and execute a main task corresponding to the trigger event;

[0090] The execution module 703 is configured to monitor a preset judgment condition for triggering an execution subtask during execution of the main task, and execute a subtask corresponding to the judgment condition when the trigger judgment condition is monitored;

[0091] The scheduling module 704 is configured to schedule an execution flow of the subtasks based on a running logic between the subtasks during execution of the subtasks, wherein the subtasks include a plurality of parallel processing subtasks of the main task caused by the trigger event.

[0092] In some embodiments, Figure 7 The registration module 705 registers a predetermined trigger event before determining the state mode of the wearable device, establishes a binding relationship between the trigger event and the main task, and configures a corresponding setting interface and a cancellation interface for the trigger event; wherein each trigger event corresponds to a state mode, and the setting interface and the cancellation interface are respectively used for setting and canceling operations of the state mode during switching of the main task.

[0093] In some embodiments, Figure 7 The monitoring module 701 determines the state mode of the wearable device according to a current running state of the wearable device, wherein the state mode includes a factory mode, a factory test mode, an activation mode, a hibernation mode, and a working mode.

[0094] In some embodiments, Figure 7 The monitoring module 701 generates an event signal corresponding to a key event triggered by a key operation according to the key operation when the key operation of the wearable device is monitored; and / or generates an event signal corresponding to a clock event triggered by a time according to the time when the time is within a preset clock requirement range.

[0095] In some embodiments, Figure 7 The switching module 702 searches for a predetermined trigger event according to the event identifier, acquires a trigger event corresponding to the event identifier, and determines a state mode corresponding to the trigger event, so as to switch the state mode of the wearable device to the state mode of the trigger event corresponding to the event identifier.

[0096] In some embodiments, Figure 7The switching module 702 uses the setting interface corresponding to the state mode of the triggering event to set the second event at the end of the first event corresponding to the state mode of the wearable device, and uses the unregistration interface of the state mode of the wearable device to unregister the first event at the beginning of the second event, so as to switch the state mode of the wearable device from the state mode of the first event to the state mode of the second event.

[0097] In some embodiments, Figure 7 During the execution of the main task, the execution module 703 monitors the time of triggering subtasks and the number of times the task is executed. When the time or the number of times the task is executed meets the judgment conditions, the subtask corresponding to the judgment conditions is executed. The judgment conditions include time judgment conditions and number of times judgment conditions.

[0098] In some embodiments, Figure 7 During the execution of a subtask, the scheduling module 704 performs a switching operation on the subtask according to the execution logic between different subtasks under the main task, so as to schedule the execution flow of the subtask. The execution logic between subtasks includes judging different conditions within preset different clocks.

[0099] In some embodiments, Figure 8 After the wearable device is powered on, the initialization module 706 performs an initialization operation on the preset serial port task and continues to run the serial port task. The serial port task is used to parse the serial port data of the main control chip and core chip in the wearable device, and transmit the parsed serial port data upward or frame the upper layer data according to the protocol.

[0100] In some embodiments, the wearable device includes a smart helmet.

[0101] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0102] Figure 8 This is a schematic diagram of the structure of the electronic device 8 provided in an embodiment of the present invention. Figure 8 As shown, the electronic device 8 of this embodiment includes a processor 801, a memory 802, and a computer program 803 stored in the memory 802 and executable on the processor 801. When the processor 801 executes the computer program 803, it implements the steps in the various method embodiments described above. Alternatively, when the processor 801 executes the computer program 803, it implements the functions of each module / unit in the various device embodiments described above.

[0103] By way of example, the computer program 803 can be segmented into one or more modules / units, which are stored in the memory 802 and executed by the processor 801 to accomplish the present application. The one or more modules / units can be a series of computer program instruction segments capable of accomplishing a specific function, which are used to describe the execution process of the computer program 803 in the electronic device 8.

[0104] The electronic device 8 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The electronic device 8 can include but is not limited to the processor 801 and the memory 802. Those skilled in the art can understand that the electronic device 8 can include more or less components, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, and the like. ​ The electronic device 8 is only an example and does not constitute a limitation on the electronic device 8, and can include more or less components than the illustration, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, and the like.

[0105] The processor 801 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0106] The memory 802 can be an internal storage unit of the electronic device 8, for example, a hard disk or a memory of the electronic device 8. The memory 802 can also be an external storage device of the electronic device 8, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, and the like equipped on the electronic device 8. Further, the memory 802 can include both the internal storage unit and the external storage device of the electronic device 8. The memory 802 is used to store the computer program and other programs and data required by the electronic device. The memory 802 can also be used to temporarily store data that has been output or will be output.

[0107] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be realized in the form of hardware or software function unit. In addition, the specific name of each functional unit and module is only for the convenience of mutual distinction, and does not limit the protection scope of the present application. The specific working process of the unit and module in the above system can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

[0108] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the related description of other embodiments.

[0109] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0110] In the embodiments provided by the present application, it should be understood that the disclosed device / computer equipment and method can be implemented by other ways. For example, the device / computer equipment embodiments described above are only schematic, and the division of the modules or units is only a logical function division, and there can be another division way in actual implementation, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection between each displayed or discussed coupling can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0111] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0112] In addition, each function unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software function unit.

[0113] If the integrated module / unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can be executed by a processor to implement the steps of each method embodiment. The computer program can include computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0114] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit it; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of the present application, and should be included in the protection scope of the present application.

Claims

1. A multi-task scheduling method based on wearable devices, characterized in that, Design an embedded scheduling system and implement a multi-task scheduling method based on this system. The embedded scheduling system is divided into four layers from bottom to top: physical layer, protocol layer, event and task layer, and application layer. Among them, the physical layer configures all peripherals; the protocol layer includes serial port tasks, performs protocol processing on serial port input and output data, and realizes the isolation between the physical layer and the upper-layer architecture; the event and task layer is a concretization of five state modes: factory mode, factory test mode, activation mode, sleep mode, and working mode; the application layer schedules all events and tasks according to the actual functions of the wearable device and relies on a real-time clock. The methods include: Determine the state mode of the wearable device and monitor event signals triggered for the wearable device, the event signals containing an event identifier; The triggering event is determined based on the event identifier, the state mode of the wearable device is switched based on the triggering event, and the main task corresponding to the triggering event is executed. During the execution of the main task, preset judgment conditions for triggering the execution of sub-tasks are monitored. When the judgment condition is detected to be triggered, the sub-task corresponding to the judgment condition is executed. During the execution of the subtasks, the execution flow of the subtasks is scheduled based on the operational logic between them. The subtasks include multiple parallel subtasks under the main task triggered by the triggering event. Before determining the state mode of the wearable device, the method further includes: Register the predetermined triggering event, establish the binding relationship between the triggering event and the main task, and configure the corresponding setting interface and unregistration interface for the triggering event; Each of the triggering events corresponds to a state mode. The setting interface and the deregistration interface are used to perform setting and deregistration operations on the state mode during the switching of the main task, respectively. Determining the state mode of the wearable device includes: Based on the current operating state of the wearable device, the state mode of the wearable device is determined, wherein the state mode includes factory mode, factory test mode, activation mode, sleep mode and working mode; The step of determining a triggering event based on the event identifier and switching the state mode of the wearable device based on the triggering event includes: The predetermined triggering event is searched according to the event identifier to obtain the triggering event corresponding to the event identifier, and the state mode corresponding to the triggering event is determined so as to switch the state mode of the wearable device to the state mode of the triggering event corresponding to the event identifier. Switching the state mode of the wearable device to the state mode of the triggering event corresponding to the event identifier includes: Using the setting interface corresponding to the state mode of the triggering event, a second event is set at the end of the first event corresponding to the state mode of the wearable device, and using the unregistration interface of the state mode of the wearable device, the first event is unregistered at the beginning of the second event, so as to switch the state mode of the wearable device from the state mode of the first event to the state mode of the second event. The method further includes: performing an initialization operation on a preset serial port task after the wearable device is powered on, and continuously running the serial port task. The serial port task is used to parse the serial port data of the main control chip and the core chip in the wearable device, and transmit the parsed serial port data upward or frame the upper layer data according to the protocol.

2. The method according to claim 1, characterized in that, The monitoring of event signals triggered by the wearable device includes: When a key press operation on the wearable device is detected, an event signal corresponding to the key press event is generated based on the key press event triggered by the key press operation; and / or, When the time is detected to be within the preset clock requirement range, an event signal corresponding to the clock event is generated based on the clock event triggered by the time.

3. The method according to claim 1, characterized in that, During the execution of the main task, preset judgment conditions for triggering the execution of subtasks are monitored. When a judgment condition is detected, the subtask corresponding to the condition is executed, including: During the operation of the main task, the time of triggering the sub-task and the number of times the task is executed are monitored. When the time or the number of times the task is executed meets the judgment condition, the sub-task corresponding to the judgment condition is executed. The judgment condition includes a time judgment condition and a number of times judgment condition.

4. The method according to claim 1, characterized in that, During the execution of the sub-tasks, the execution flow of the sub-tasks is scheduled based on the operational logic between the sub-tasks, including: During the execution of the subtask, a switching operation is performed on the subtask according to the execution logic between different subtasks under the main task, so as to schedule the execution flow of the subtask. The execution logic between the subtasks includes judging different conditions within preset different clocks.

5. The method according to any one of claims 1 to 4, characterized in that, The wearable device includes a smart safety helmet.

6. A multi-task scheduling device based on a wearable device, wherein the device employs the method described in any one of claims 1-5, characterized in that, The device includes: The monitoring module is configured to determine the state mode of the wearable device and monitor event signals triggered for the wearable device, the event signals including an event identifier; The switching module is configured to determine a trigger event based on the event identifier, switch the state mode of the wearable device based on the trigger event, and execute the main task corresponding to the trigger event; The execution module is configured to monitor preset judgment conditions for triggering the execution of subtasks during the execution of the main task, and execute the subtask corresponding to the judgment condition when the judgment condition is triggered. The scheduling module is configured to schedule the execution flow of the subtasks based on the running logic between the subtasks during the execution of the subtasks, wherein the subtasks include multiple parallel subtasks under the main task caused by the triggering event.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images