CANopen protocol stack transplantation method and device, equipment and medium

Abstract

The invention relates to the technical field of protocol stack transplantation, and discloses a CANopen protocol stack transplantation method and device, equipment and a medium. The method comprises the following steps: acquiring target configuration information and target task information of a to-be-migrated motor driver; determining a target driving template based on the hardware configuration information of the main control chip; based on the target configuration information and the target task information, configuring a target driving template to obtain a configured driving template adaptive to the target configuration information; and transplanting the configuration driving template to a main control chip of the motor driver to be migrated. According to the embodiment of the invention, the transplantation efficiency of the CANopen protocol stack can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of protocol stack transplantation, and particularly to a CANopen protocol stack transplantation method, device, equipment and medium. BACKGROUND

[0002] The CANopen protocol has become a mainstream communication protocol in the field of motor drivers due to its high standardization and strong reliability. However, the traditional CANopen protocol stack (such as the complete version of CiA 301 standard) contains full-function modules such as object dictionary, PDO / SDO, emergency message, NMT, etc., which has a large amount of code and occupies a large amount of memory. The master control chip of a motor driver (especially a small and medium-sized servo driver and a stepper driver) is usually a low-cost MCU (such as STM32 series and RISa RL78 series), which has limited Flash capacity and RAM capacity, and the core task of the driver is motion control, which requires high real-time response for communication.

[0003] Therefore, the redundant functions of the CANopen protocol stack may occupy the resources of the master control chip of the motor driver, affecting the execution efficiency of the motion control algorithm and increasing the communication delay. At the same time, there is a defect of difficult transplantation, which requires a large number of parameter modifications when adapting to the compilation environment and peripheral interface of different master control chips. SUMMARY

[0004] The present application aims to provide a CANopen protocol stack transplantation method, device, equipment and medium, which aims to improve the transplantation efficiency of the CANopen protocol stack.

[0005] The present application provides a CANopen protocol stack transplantation method, which comprises: obtaining target configuration information and target task information of a motor driver to be migrated; the target configuration information comprises hardware configuration information of a master control chip, a CAN controller and a CAN transceiver, and the target task information is task information of a task to be executed by the motor driver to be migrated; determining a target drive template based on the hardware configuration information of the master control chip; the target drive template is a device driver supporting the CANopen protocol which is adapted to the master control chip; configuring the target drive template based on the target configuration information and the target task information to obtain a configured drive template adapted to the target configuration information; transplanting the configured drive template to the master control chip of the motor driver to be migrated.

[0006] In some embodiments, the determining of the target drive template based on the hardware configuration information of the master control chip comprises: The target driving template is obtained based on CAN pin definition information and timer channel definition information of the driving template corresponding to the master control chip by searching a predefined template library according to hardware configuration information of the master control chip.

[0007] In some embodiments, the target driving template includes a protocol adaptation layer file, an object dictionary configuration file and an application layer interface file, and the target driving template is configured based on the target configuration information and the target task information, including: The protocol adaptation layer file is parameter-configured based on the target configuration information to obtain a configured protocol adaptation layer file. The object dictionary configuration file is entry-configured based on the target task information to obtain a configured object dictionary configuration file. The configured protocol adaptation layer file, the configured object dictionary configuration file and the application layer interface file are packaged to obtain a configured driving template.

[0008] In some embodiments, the protocol adaptation layer file is parameter-configured based on the target configuration information, including: The capacity parameter of a ring buffer, the mapping parameter of a PDO mapping entry and the time length parameter of a communication timeout protection mechanism in the protocol adaptation layer file are configured to corresponding parameter values based on the hardware configuration information of the master control chip to obtain the configured protocol adaptation layer file.

[0009] In some embodiments, the object dictionary configuration file is entry-configured based on the target task information, including: Entries irrelevant to a task represented by the target task information in the object dictionary configuration file are removed, and when an entry expansion request is received, entries indicated by the entry expansion request are expanded in the object dictionary configuration file to obtain the configured object dictionary configuration file.

[0010] In some embodiments, the protocol adaptation layer file occupies no more than 3 KB of Flash space and no more than 512 bytes of RAM space, and the number of entries in the object dictionary configuration file is no more than 32.

[0011] In some embodiments, after the configured driving template is transplanted to the master control chip of the motor driver to be migrated, the method further includes: After the configured driving template is added to a project of the motor driver to be migrated, it is determined whether memory resources occupied by the configured driving template meet a preset memory condition. If yes, an RPDO control instruction is sent to the motor driver to be migrated. determining whether the controlled motor responds to the RPDO control instruction; If not, returning to the step of configuring the target drive template based on the target configuration information and the target task information.

[0012] The embodiment of the present application further provides a CANopen protocol stack transplantation device, comprising: The first module is configured to obtain target configuration information and target task information of a motor driver to be migrated; the target configuration information comprises hardware configuration information of a master control chip, a CAN controller and a CAN transceiver, and the target task information is task information of a task to be executed by the motor driver to be migrated; The second module is configured to determine a target drive template based on the hardware configuration information of the master control chip; the target drive template is a device driver supporting the CANopen protocol and adapted to the master control chip; The third module is configured to configure the target drive template based on the target configuration information and the target task information, to obtain a configured drive template adapted to the target configuration information; The fourth module is configured to transplant the configured drive template to the master control chip of the motor driver to be migrated.

[0013] The embodiment of the present application further provides an electronic device, which comprises a memory and a processor; the memory stores a computer program; and the processor implements the CANopen protocol stack transplantation method described above when executing the computer program.

[0014] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program; and the computer program is executed by a processor to implement the CANopen protocol stack transplantation method described above.

[0015] The present application has the following beneficial effects: a target drive template is selected based on target configuration information and target task information of a motor driver to be migrated, and is transplanted to a master control chip of the motor driver to be migrated after being configured, thereby simplifying the transplantation process of the CANopen protocol stack to different hardware platforms. Thus, the target drive template is selected and configured based on the target configuration information and the target task information of the motor driver to be migrated, so that a highly customized and lightweight configured drive template can be efficiently generated, manual trimming and modification are avoided, and the complexity and error rate of transplantation are significantly reduced. Meanwhile, the Flash and RAM resources occupied by the generated configured drive template are minimized by precisely matching hardware resources and application requirements, so that more resources are left for the motion control algorithm of the master control chip, and the real-time performance and response speed of the motor driver motion control are ensured. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 An application environment diagram of the CANopen protocol stack transplantation method provided by the embodiment of the present application.

[0017] Figure 2 A flowchart of the CANopen protocol stack transplantation method provided by the embodiment of the present application.

[0018] Figure 3 A flowchart of the method for configuring the target driver template provided by the embodiment of the present application.

[0019] Figure 4 A flowchart of the method provided by the embodiment of the present application after the configuration driver template is transplanted to the master control chip of the motor driver to be migrated.

[0020] Figure 5 A structural schematic diagram of the CANopen protocol stack transplantation device provided by the embodiment of the present application.

[0021] Figure 6 A hardware structural schematic diagram of the electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not intended to limit the present application.

[0023] It should be noted that although the functional modules are divided in the device schematic diagram, and the logical order is shown in the flowchart, in some cases, the steps shown can be executed in a manner different from the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification and claims and the accompanying drawings are used to distinguish similar objects, and are not intended to describe a specific order or sequence.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0025] The CANopen protocol stack porting method provided in this application can be executed by a computer device, which can be a terminal device or a server. Terminal devices include, but are not limited to, mobile phones, computers, smart home appliances, vehicle terminals, and aircraft. The server can be a standalone physical server, a server cluster consisting of multiple physical servers, a distributed system, or a cloud server. Furthermore, all information, data, and signals involved in this application's embodiments are authorized by the relevant parties or have been fully authorized by all parties involved, and the collection, use, and processing of related data comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0026] In the application of the traditional CANopen protocol stack, the large amount of code and high memory consumption are due to the fact that the protocol stack includes a full set of functional modules such as object dictionary, PDO / SDO, emergency messages, and NMT. ​​When deployed on a low-cost microcontroller for motor drivers, these redundant functional modules compete with the core motion control tasks for limited Flash and RAM resources, leading to reduced execution efficiency of motion control algorithms and decreased real-time communication response, thus affecting the overall system performance. For example, in a stepper driver based on the Renesas RL78 series microcontroller, the main control chip has limited storage resources. When integrating the full version of the CANopen protocol stack, the redundant functions of the protocol stack occupy too much Flash space, preventing the motion control algorithm from being fully optimized; at the same time, the shortage of RAM resources causes delays in communication interrupt handling, resulting in lag in the response of motor position control commands, specifically manifested as stepper motors losing steps at high speeds. Furthermore, this problem is exacerbated by the need to modify numerous parameters during the adaptation of different main control chip compilation environments and peripheral interfaces, leading to increased fluctuations in communication response cycles.

[0027] If the above problems are not resolved, the stability of the motion control system will be severely affected, communication timeout events may occur frequently, leading to unreliable equipment operation or even control failure, threatening equipment safety and service life.

[0028] Based on this, embodiments of this application provide a CANopen protocol stack porting method, apparatus, device, and medium. By selecting a target driver template through the target configuration information and target task information of the motor driver to be migrated, and then configuring it, the template is ported to the main control chip of the motor driver to be migrated. This simplifies the porting process of the CANopen protocol stack to different hardware platforms and improves the porting efficiency of the CANopen protocol stack.

[0029] Figure 1 This diagram illustrates the application environment of the CANopen protocol stack porting method provided in this embodiment. (See also...) Figure 1The method is applied to a CANopen protocol stack transplantation system. The system includes a terminal 110 and a server 120. The terminal 110 and the server 120 are connected through a network. The terminal 110 can be a desktop terminal or a mobile terminal, and the mobile terminal can be at least one of a mobile phone, a tablet computer, a notebook computer, and the like. The server 120 can be implemented by using an independent server or a server cluster composed of a plurality of servers. The terminal 110 is configured to send target configuration information and target task information of a motor driver to be migrated to the server 120. The server 120 is configured to obtain the target configuration information and the target task information of the motor driver to be migrated, determine a target drive template based on hardware configuration information of a master control chip, configure the target drive template based on the target configuration information and the target task information, obtain a configured drive template adapted to the target configuration information, and transplant the configured drive template to the master control chip of the motor driver to be migrated. The target configuration information includes hardware configuration information of the master control chip, a CAN controller, and a CAN transceiver. The target drive template is adapted to the master control chip and is used to develop a device driver supporting the CANopen protocol.

[0030] It should be understood that Figure 1 The application scenarios shown are only examples. In actual applications, the CANopen protocol stack transplantation method provided in the embodiments of the present application can also be applied to other scenarios. For example, the CANopen protocol stack transplantation method described above can be directly applied to the terminal 110. The terminal 110 is configured to obtain target configuration information and target task information of a motor driver to be migrated, determine a target drive template based on hardware configuration information of a master control chip, configure the target drive template based on the target configuration information and the target task information, obtain a configured drive template adapted to the target configuration information, and transplant the configured drive template to the master control chip of the motor driver to be migrated.

[0031] Referring to Figure 2 In an embodiment, a CANopen protocol stack transplantation method is provided. The execution subject of the method can be a terminal or a server, and includes but is not limited to steps S201 to S204.

[0032] In step S201, target configuration information and target task information of a motor driver to be migrated are obtained.

[0033] The motor driver to be migrated refers to a motor drive device that needs to integrate a CANopen protocol stack to realize a CANopen communication function. The driver usually includes a master control chip responsible for executing a motion control algorithm and processing a communication task.

[0034] The target configuration information includes the hardware configuration information of the main control chip, CAN controller, and CAN transceiver. In essence, the target configuration information refers to the specific parameters and settings required by the motor driver to be migrated at both the hardware and functional levels. This hardware configuration information may include the model of the main control chip, the type of the CAN controller (e.g., an internal CAN module or an external CAN chip) and its register settings, as well as the model and connection method of the CAN transceiver. This information forms the basis for low-level driver development and protocol stack adaptation.

[0035] The target task information refers to the task information of the motor driver to be migrated. In other words, the target task information refers to the specific functions or operations that the motor driver to be migrated needs to perform in actual applications. For example, a motor driver may need to implement tasks such as speed control, position control, or torque control. These tasks determine which object dictionary entries and PDO (Process Data Object) mappings need to be enabled in the CANopen protocol stack.

[0036] In practice, obtaining target configuration information can be achieved in several ways. For example, engineers can manually consult hardware manuals and requirements documents, inputting item by item the model of the main control chip, the type of CAN controller, the model of the CAN transceiver, and the specific task list to be performed by the motor driver. Alternatively, a semi-automated approach can be used, where the execution entity provides a configuration interface, the engineer selects preset hardware components and task types, the execution entity automatically fills in some parameters, and the engineer then confirms and supplements them. Another implementation method is file import, where engineers import text or spreadsheet files containing hardware configuration and task requirements information into the execution entity, which then parses and extracts the necessary information.

[0037] Step S202: Determine the target driver template based on the hardware configuration information of the main control chip.

[0038] A target driver template is a pre-designed software framework or code skeleton compatible with a specific host control chip, used to develop device drivers that support the CANopen protocol. This template is designed for developing device drivers that support the CANopen protocol and typically contains interface definitions and basic functional implementations for interacting with the underlying hardware of the host control chip, providing a starting point for subsequent protocol stack configuration.

[0039] In determining the target drive template, the following approaches can be adopted: the subject performs a list containing a plurality of master chip drive templates, and the engineer manually selects a drive template compatible with the master chip from the list according to the obtained master chip hardware configuration information as the target drive template. Alternatively, the subject can automatically filter one or several drive templates that best meet the conditions from a general template library according to the model, architecture and other hardware configuration information of the master chip for the engineer to choose. Alternatively, the engineer inputs the detailed parameters of the master chip, and then uses a code generation tool to dynamically generate a basic drive template according to these parameters.

[0040] In step S203, the target drive template is configured based on the target configuration information and the target task information to obtain a configured drive template adapted to the target configuration information.

[0041] The configured drive template refers to a customized drive program obtained by adjusting parameters and cutting functions based on the target configuration information and the target task information of the motor drive to be migrated on the basis of the target drive template. The template can accurately adapt to the target hardware environment and application requirements, thereby realizing efficient and resource-optimized CANopen communication functions.

[0042] The configuration process can adopt various implementation means. For example, the engineer can manually modify the macro definition, variable value and function call in the target drive template according to the target configuration information and the target task information to adapt to specific hardware resources and functional requirements. As a higher degree of automation implementation, a configuration script can be written, which reads the target configuration information and the target task information and then automatically modifies specific code segments or configuration files in the target drive template. In addition, a graphical configuration tool can also be provided, and the engineer sets various parameters and function options on the interface through drag-and-drop, check-box and other operations, and the tool automatically generates or modifies the code of the target drive template in the background.

[0043] In step S204, the configured drive template is transplanted to the master chip of the motor drive to be migrated.

[0044] The transplantation process usually involves integrating the configured drive template code into the project engineering of the motor driver, and then manually compiling, linking, and burning the generated firmware into the master chip through the JTAG / SWD debugging interface. In order to improve efficiency, an automatic deployment tool can also be used, which can automatically complete a series of operations such as code integration, compilation, and burning, so as to deploy the configured drive template to the target master chip. As a kind of remote deployment method, the OTA (Over-The-Air) update function can be reserved in the master chip, and the configured drive template is sent to the master chip in the form of a firmware package through the network or serial interface, and the boot loader inside the chip updates it.

[0045] The above technical solutions will be further described through a more specific example: Suppose there is a motor driver to be migrated, whose master chip is a low-cost microcontroller (for example, model MCU-A), which has limited Flash and RAM resources. The motor driver needs to implement a simple CANopen speed control task, that is, to receive speed instructions through the CANopen network and control the motor speed. The traditional CANopen protocol stack is difficult to directly adapt to such resource-constrained microcontrollers due to its large code size and comprehensive function modules, and the manual pruning and transplantation process is complex, which is easy to introduce errors and prolong the development cycle.

[0046] To solve the above problems, first, the target configuration information and target task information of the motor driver to be migrated need to be obtained. Specifically, the engineer obtains the hardware configuration information of the master chip of MCU-A by consulting the hardware manual, such as the model of the master chip, the register configuration details of the internal CAN controller, and the model of the CAN transceiver used. At the same time, according to the application requirements of the motor driver, it is clear that the target task is "CANopen speed control", which includes the CANopen object dictionary entries that need to be supported (such as control word, status word, target speed in speed mode, etc.) and PDO mapping relationship. Accurate acquisition of these information is the basis for the subsequent steps.

[0047] Secondly, based on the hardware configuration information of the MCU-A master chip, a target drive template is determined. For example, the execution subject provides a basic drive template compatible with MCU-A series microcontrollers. The template is a pre-written software framework that includes CAN controller initialization code, timer configuration interface, and basic GPIO (General Purpose Input Output) operation functions for MCU-A. The template is designed to be extensible for developing device drivers that support CANopen protocol, but does not yet contain any specific logic of CANopen protocol stack.

[0048] Next, the target drive template is configured based on the previously acquired target configuration information and target task information. For example, for the CAN controller hardware configuration of MCU-A, the baud rate, filter mask, and other parameters of the CAN controller in the template are adjusted. At the same time, according to the target task of "CANopen speed control", the object dictionary entries related to speed control are defined or enabled in the template, and the corresponding PDO mapping is configured to ensure that the motor driver can correctly receive and send speed control data. Through this configuration process, the target drive template is customized to form a configured drive template that adapts to the hardware environment of MCU-A and the speed control task. The configured drive template only contains the CANopen protocol stack functions required to implement the speed control task, thereby avoiding unnecessary code and memory occupation.

[0049] Finally, the configured drive template is ported to the main control chip MCU-A of the motor driver to be migrated. This usually involves compiling the configured code into executable firmware and burning it into the Flash memory of MCU-A through a programmer or debugger. Once the porting is completed, MCU-A can communicate with the host computer through the CANopen network, receive speed instructions, and drive the motor to run according to the preset speed curve. The entire process significantly reduces the difficulty of CANopen protocol stack porting on resource-limited motor drivers through a structured approach, optimizes system resource utilization, and ensures real-time and efficiency of motion control.

[0050] In combination with the above example, the CANopen protocol stack porting method proposed in this embodiment exhibits significant technical contributions. In traditional porting schemes, engineers usually need to manually trim redundant functions from the complete CANopen protocol stack and modify the underlying drive code and configuration parameters one by one for specific hardware platforms. For example, in the scenario of speed control of the MCU-A motor driver described above, if the traditional method is used, the engineer needs to spend a lot of time analyzing each module of the complete CANopen protocol stack according to CiA 301 standard, manually deleting SDO, emergency message, and other functions unrelated to speed control, and manually writing or modifying the CAN controller initialization code, interrupt service program, and other codes of MCU-A. This manual trimming and modification process not only has a huge workload, but also is prone to errors, resulting in a long debugging period. Especially for low-cost microcontrollers with limited resources, a slight mistake can cause memory overflow or performance degradation.

[0051] In contrast, the embodiment provides a systematic, efficient and resource-optimized transplantation approach by obtaining target configuration information and target task information, determining a target drive template based on the hardware information of the master chip, configuring the target drive template based on the target configuration and task information, and transplanting the configured drive template to the master chip. For example, after obtaining the hardware configuration and speed control task information of MCU-A, the execution subject can automatically or semi-automatically determine a basic drive template adapted to MCU-A. Subsequently, by performing targeted configuration on the template, only the CANopen protocol stack functions required to implement the speed control task are retained, thereby generating a highly customized, lightweight configured drive template. This method avoids the tedious manual trimming and modification in traditional schemes, significantly reducing the complexity and error rate of transplantation.

[0052] Therefore, the technical scheme of the embodiment can effectively solve the problems of large code amount, large memory occupation and high transplantation difficulty of the traditional CANopen protocol stack. By accurately matching hardware resources and application requirements, the Flash and RAM resources occupied by the generated configured drive template are minimized, thereby leaving more resources for the motion control algorithm of the master chip, ensuring the real-time performance and response speed of the motor driver motion control. At the same time, this method provides a structured configuration process and a templated development mode, significantly improving the CANopen protocol stack transplantation efficiency under different master chips and application scenarios, shortening the product development cycle, and having significant practical value and technical progress.

[0053] In some embodiments, based on the hardware configuration information of the master chip, the target drive template is determined, including: based on the hardware configuration information of the master chip, searching a drive template corresponding to the master chip from a pre-defined template library, editing CAN pin definition information and timer channel definition information of the drive template, and obtaining the target drive template.

[0054] In determining the target drive template, first, based on the hardware configuration information of the master chip, a drive template corresponding to the master chip is searched from a pre-defined template library. The drive template is the starting point of developing a device driver supporting the CANopen protocol. For example, a mapping relationship table of master chip models and drive templates can be established in the pre-defined template library, when the hardware configuration information of the master chip is input, the execution subject automatically queries the mapping table and returns the corresponding drive template; or, the hardware configuration information of the master chip can be feature extracted, and then a drive template most matching the features is searched in the template library using a fuzzy matching or keyword search algorithm.

[0055] Subsequently, the CAN pin definition information of the drive template needs to be edited. The CAN pin definition information refers to the configuration information of the specific physical pins (such as CAN_TX and CAN_RX pins) used by the CAN communication module on the master chip. Since different motor drivers or master chips may connect the CAN module to different GPIO pins in their hardware design, the pre-set pin definitions in the drive template need to be modified to match the actual hardware connection, ensuring the normal operation of CAN communication. For example, a graphical user interface (GUI) tool can be used to allow users to intuitively select or input the GPIO port and pin number corresponding to the CAN_TX and CAN_RX pins on the master chip, and then the tool automatically modifies the related macro definitions or structure members in the drive template. Alternatively, a configuration file (such as XML, JSON, or C header file) can be used, where users directly modify specific fields in the file, such as `#define CAN_TX_PIN GPIOA_PIN9`, to update the CAN pin definition. At the same time, the timer channel definition information of the drive template needs to be edited. The timer channel definition information refers to the configuration of the internal timer module of the master chip, which is usually used to implement time-sensitive functions in the CANopen protocol, such as the sending period of heartbeat messages, timeout detection of node protection mechanisms, synchronization transmission of PDO (Process Data Object), etc. Different master chips or application scenarios may require the use of different timer resources or the configuration of different timer channels, so the pre-set timer configuration in the drive template needs to be adjusted to meet the requirements of the protocol stack for time accuracy and the actual allocation of hardware resources. For example, an integrated development environment (IDE) configuration tool can be used to select the available timer modules (such as TIM1, TIM2, etc.) of the master chip and configure their working modes (such as up-counting, down-counting), pre-dividers, automatic reload values, and interrupt priority parameters, and then the tool generates the corresponding code snippets to update the drive template. Alternatively, the timer initialization function or macro definition in the drive template can be modified to manually specify the used timer instance, channel number, and related clock source and count period, to ensure that the timer function is consistent with the requirements of the CANopen protocol stack. Through the above editing, the target drive template is finally obtained.

[0056] The scheme of the present application provides a hardware abstraction layer for the running of the CANopen protocol stack by using the hardware configuration information of the master chip to intelligently search and obtain a basic driving template that completely matches the master chip model or architecture from a predefined template library. On this basis, the found driving template is further edited in detail, and the CAN pin definition information preset in the template is modified to ensure that the sending and receiving pins of the CAN communication module can be accurately mapped to the actual physical pins of the master chip of the motor driver to be migrated, thereby establishing a reliable CAN bus connection. At the same time, by editing the timer channel definition information, the timer configuration in the driving template can be matched with the actual timer resources of the master chip and the requirements of the CANopen protocol stack for time synchronization, timeout detection and other functions. This combination of searching and editing makes the generated target driving template not only compatible with the master chip in a macroscopic sense, but also accurately aligned with the specific hardware layout and timing requirements in a microscopic sense, thereby laying a solid foundation for the stable running of the CANopen protocol stack.

[0057] The following is described through a specific example. After obtaining the hardware configuration information of the master chip of the motor driver to be migrated, for example, the master chip is an STM32F407 series microcontroller, the execution subject can first search for the "STM32F407" keyword in the predefined template library, thereby finding a driving template designed for the STM32F407 series microcontroller. Subsequently, in order to adapt the general template to the specific motor driver hardware, customized editing is required. For example, if the CAN bus transceiver of the motor driver is connected to GPIOA_PIN11 (CAN_RX) and GPIOA_PIN12 (CAN_TX) of the master chip, the macro definition of the CAN pin in the driving template needs to be modified and updated to `#define CAN_RX_GPIO_PORT GPIOA`, `#define CAN_RX_GPIO_PIN GPIO_PIN_11`, and `#define CAN_TX_GPIO_PORT GPIOA`, `#define CAN_TX_GPIO_PIN GPIO_PIN_12`. At the same time, if the CANopen protocol stack needs to use the TIM3 timer to implement the periodic sending of heartbeat messages, and the timer channel is allocated as channel 1 in the current hardware design, the timer initialization related code in the driving template needs to be edited to configure channel 1 of TIM3 to an appropriate counting mode and period, for example, to set the prescaler and auto-reload registers to implement accurate timing functions. Through these specific editing operations, a target driving template that completely adapts to the STM32F407 master chip and the hardware layout of the specific motor driver is finally obtained.

[0058] By the above technical solution, when determining the target drive template, not only the basic template can be quickly located based on the hardware configuration information of the master chip, but also the CAN pin definition information and the timer channel definition information can be edited in a targeted manner. This effectively solves the problem of mismatch between the basic template and the specific hardware pin allocation and timer resource usage, avoiding communication failure or timing error caused by hardware differences. This fine-grained configuration ensures that the CANopen protocol stack can accurately and efficiently interact with the underlying hardware after being transplanted to the master chip of the motor driver to be migrated, significantly improving the success rate of protocol stack transplantation and the stability of operation, and reducing the workload of manual debugging and modifying the underlying drive code.

[0059] In an embodiment, the target drive template includes a protocol adaptation layer file, an object dictionary configuration file, and an application layer interface file. Referring to Figure 3 , the method of configuring the target drive template includes but is not limited to steps S301 to S303.

[0060] Step S301, based on the target configuration information, parameter configuration is performed on the protocol adaptation layer file to obtain a configured protocol adaptation layer file.

[0061] Step S302, based on the target task information, entry configuration is performed on the object dictionary configuration file to obtain a configured object dictionary configuration file.

[0062] Step S303, encapsulating the configured protocol adaptation layer file, the configured object dictionary configuration file, and the application layer interface file to obtain a configured drive template.

[0063] The protocol adaptation layer file is a bridge between the CANopen protocol stack and the underlying hardware (such as CAN controller, CAN transceiver), and its role is to convert the general communication instructions and data formats of the CANopen protocol into operations that can be recognized and executed by the specific hardware platform. For example, it can contain code for initializing the CAN controller, sending / receiving CAN frames, handling CAN interrupts, etc. This file can exist in the form of a C language source file, which defines hardware-related function interfaces and data structures; or it can also be a pre-compiled library file that provides standardized APIs for upper-layer calls.

[0064] The object dictionary configuration file is a core component of a CANopen device, used to store all accessible parameters, process data, and network variables of the device. It defines the index, sub-index, data type, access rights, and default values of these data items. Through the object dictionary, external nodes can read or modify the running parameters of the device, achieving monitoring and control of the device. This configuration file can be a structured text file, such as XML or CSV format, for easy parsing and editing by tools; or it can be directly embedded in the source code as a C language structure array, generated during compilation.

[0065] The application layer interface file provides a standardized interface for upper-layer applications (such as motor control algorithms, user interface logic) to interact with the CANopen protocol stack. It encapsulates the complexity of the underlying protocol stack, allowing application developers to access object dictionary data, send PDO (Process Data Object) or SDO (Service Data Object) requests, etc. through simple function calls. This file usually provides function declarations and data structure definitions in the form of C language header files (.h), and its corresponding implementation file is responsible for calling the protocol adaptation layer and operating the object dictionary.

[0066] Based on the target configuration information, the protocol adaptation layer file is configured with parameters, which can be based on the system clock frequency of the master chip, the register address and interrupt vector of the CAN controller, the driving characteristics of the CAN transceiver, etc. Configure CAN baud rate, CAN interrupt priority, CAN receive / send buffer size, etc. This configuration can be achieved by modifying macro definitions, global variables, or structure members in the protocol adaptation layer file; or it can also be achieved by calling specific configuration functions to dynamically set these parameters at runtime.

[0067] Based on the target task information, the object dictionary configuration file is configured with entries, mainly customized adjustment of entries in the object dictionary configuration file. This includes adding new entries related to the task (such as target speed, actual position, current limit, etc.), deleting redundant entries unrelated to the current task, modifying the data type or access rights of existing entries, and setting the default value or range of entries. This configuration can be achieved by editing the data item definitions in the object dictionary configuration file; or it can also be achieved through a special configuration tool in a graphical interface, and generate the corresponding configuration file.

[0068] The encapsulation of the protocol adaptation layer file, the post-configuration object dictionary configuration file and the application layer interface file is to integrate the protocol adaptation layer file, the object dictionary configuration file and the application layer interface file after parameter configuration and entry configuration, to form a complete and deployable drive template. The purpose of encapsulation is to facilitate subsequent transplantation and compilation. This can be to organize these files in a specific project directory structure and provide the corresponding build scripts (such as Makefile or CMakeLists.txt); or it can also be to compile and link these files into a static library or dynamic library for the application program on the host chip to call.

[0069] The scheme of the present application decouples the target drive template into three core components: the protocol adaptation layer file, the object dictionary configuration file and the application layer interface file, and realizes the fine and modular configuration of the CANopen protocol stack. First, the protocol adaptation layer file, as the hardware abstraction layer, its parameters will be accurately adjusted according to the target configuration information, to ensure that the CANopen protocol stack can be seamlessly connected with the hardware resources such as the host chip, CAN controller and CAN transceiver of the motor driver to be migrated, thereby providing stable and reliable underlying communication services for the upper protocol stack. Second, the object dictionary configuration file, as the core of device parameter and data storage, its entries will be customized according to the target task information, to eliminate unnecessary entries and add the key data required by the task, so that the protocol stack can accurately reflect the functional requirements of the motor driver. At the same time, the application layer interface file provides a standardized API, so that the upper application can conveniently access and operate the configured protocol stack and object dictionary. Finally, by encapsulating these independently configured and optimized files, a complete and highly customized post-configuration drive template is formed. This structured configuration method makes the transplantation process of the CANopen protocol stack no longer a simple code copying, but a precise cutting and optimization for specific hardware and task requirements, thereby effectively solving the problem that the general drive template is difficult to accurately adapt to specific hardware and task requirements, and significantly improving the efficiency and success rate of transplantation.

[0070] As a specific embodiment, assume that the master chip of the motor driver to be migrated is an STM32F407 microcontroller from STMicroelectronics, which integrates a CAN controller and is equipped with a TJA1051 CAN transceiver from NXP. The target task information is to implement speed closed-loop control of the motor. In this case, the target drive template can be a software project containing the following files: a protocol adaptation layer file, for example named `can_hal_adapter.c`, which contains the initialization code for the STM32F407 built-in CAN controller, the interrupt service program, and the sending and receiving functions of the CAN frame. Based on the target configuration information, the parameters in this file will be configured as follows: the CAN baud rate is 500kbps, the CAN interrupt priority is set to NVIC_PRIORITY_5, and the CAN receive FIFO0 is enabled. An object dictionary configuration file, for example named `obj_dict_config.h`, which defines the structure of the CANopen object dictionary. Based on the target task information, the entries in this file will be configured as follows: include the Controlword with index 0x6040, the Modes of Operation with index 0x6060, the Target Velocity with index 0x6081h, the Velocity Actual Value with index 0x6064, etc., and set their data types (such as UINT16, INT32) and access permissions (such as read-write, read-only). At the same time, redundant entries unrelated to speed control, such as position control or current control, can be removed. An application layer interface file, for example named `motor_app_interface.h`, which defines functions called by the motor control application. Finally, compile and link these configured `can_hal_adapter.c`, `obj_dict_config.h`, and `motor_app_interface.h` files to generate a firmware that can be burned into an STM32F407 microcontroller, which is the configured drive template.

[0071] By refining the target driver template into a protocol adaptation layer file, an object dictionary configuration file, and an application layer interface file, and respectively configuring parameters and entries based on target configuration information and target task information, the scheme of the present application realizes high modularity and customization of the CANopen protocol stack. This structured configuration method enables the protocol stack to accurately adapt to different hardware platforms and diversified motor control tasks, avoiding redundant code and unnecessary resource occupation caused by general templates. Therefore, the transplanted CANopen protocol stack not only runs efficiently and stably, but also significantly improves development efficiency and system flexibility, ensuring the best performance of the motor driver in specific application scenarios.

[0072] In some embodiments, based on the target configuration information, the protocol adaptation layer file is configured with parameters, including: based on the hardware configuration information of the master chip, configuring the capacity parameter of the ring buffer, the mapping parameter of the PDO mapping entry, and the time length parameter of the communication timeout protection mechanism in the protocol adaptation layer file to corresponding parameter values, to obtain a configured protocol adaptation layer file.

[0073] The capacity parameter of the ring buffer is used to store the circular queue of CAN messages, which is written when data arrives and read out when data is processed. The purpose of setting this parameter is to balance the difference in data transmission rate, prevent data loss, and improve communication efficiency. Its setting can be based on factors such as the RAM size of the master chip, CAN bus load, message processing speed, etc. For example, it can be set to store 16, 32, or 64 CAN frames of storage space.

[0074] The mapping parameter of the PDO mapping entry refers to PDO (Process Data Object), which is a mechanism for real-time data transmission in the CANopen protocol. The mapping parameter defines the correspondence between application layer variables and PDO message data fields. The purpose of configuring this parameter is to ensure that application layer data can be correctly and efficiently transmitted through PDO. Its configuration content includes the COB-ID (Communication Object Identifier) of the PDO, the transmission type (synchronous / asynchronous), the event timer, and the object dictionary entry index and sub-index included in each PDO.

[0075] The time length parameter of the communication timeout protection mechanism is used to detect whether the nodes in the CANopen network are working normally. By setting a timeout time, if the expected message is not received within this time, it is considered that the communication is abnormal. The purpose of configuring this parameter is to improve the robustness of the system, timely discover and handle communication faults, and prevent the system from entering an uncertain state. For example, it can be configured as the sending period and timeout time of the node guarding (Node Guarding) or heartbeat message (Heartbeat).

[0076] The scheme of the present application ensures the efficient and stable operation of the CANopen protocol stack on a specific hardware platform by fine-tuning the key communication parameters in the protocol adaptation layer file based on the hardware configuration information of the master chip. Specifically, first, according to the RAM size of the master chip, the CAN controller characteristics, and the expected CAN bus load, the capacity parameters of the ring buffer are accurately set to optimize data transmission efficiency and effectively avoid buffer overflow. Second, in combination with the real-time data transmission requirements of the application layer, the mapping parameters of the PDO mapping entries are defined in detail to accurately associate the application layer variables with the PDO message structure of CANopen, ensuring timely and reliable transmission of process data. Third, to enhance the robustness of the system, the time length parameters of the communication timeout protection mechanism are configured according to the timer resources of the master chip and the system response time requirements, so that the system can timely detect and respond to communication abnormalities and prevent system instability caused by communication failures. The setting of these parameters is based on the hardware characteristics of the master chip, allowing the protocol adaptation layer file to fully utilize hardware resources and meet the real-time requirements of the CANopen protocol. In this way, the configured protocol adaptation layer file can be highly matched with the hardware environment of the master chip, providing stable and reliable underlying communication support for subsequent object dictionary configuration and application layer interface, thereby solving the problems of low efficiency and reliability caused by improper communication parameter configuration.

[0077] As a specific implementation, assume that the master chip of the motor driver to be migrated is an STM32F407 series microcontroller, which has specific CAN controller peripherals and RAM resources. When configuring the protocol adaptation layer file, the parameters can be set according to the data sheet of STM32F407 and the actual application scenario. For example, the capacity parameters of the ring buffer can be configured as 32 CAN frames to balance memory occupancy and data throughput. The mapping parameters of the PDO mapping entries can be specifically set as follows: the COB-ID of TPDO1 (Transmit Process Data Object 1) is 0x181, the transmission type is synchronous transmission, and the motor speed (object dictionary index 606Ch) and motor current (object dictionary index 6078h) are mapped to the data field of TPDO1. The COB-ID of RPDO1 (Receive Process Data Object 1) is 0x201, the transmission type is asynchronous transmission, and the target speed (object dictionary index 6081h) is mapped to the data field of RPDO1. The time length parameters of the communication timeout protection mechanism can be configured as follows: the sending period of the heartbeat message is 200ms, and the timeout time of the heartbeat message is 500ms to ensure that node failures can be detected in time when communication is interrupted. These parameter values will be directly written into the corresponding macro definitions or structure members of the protocol adaptation layer file to form the configured protocol adaptation layer file.

[0078] By the technical solution, based on the hardware configuration information of the master control chip, the capacity parameter of the ring buffer in the protocol adaptation layer file, the mapping parameter of the PDO mapping entry and the time length parameter of the communication timeout protection mechanism are accurately configured, which can ensure the efficient and stable operation of the CANopen protocol stack on the specific motor driver hardware platform. Specifically, the accurately set ring buffer capacity effectively avoids data overflow and loss, improving the reliability of communication; the optimized PDO mapping entry parameter enables the application layer data to be transmitted in real time and accurately through the CANopen network, improving the system response speed; and the time length parameter configuration of the communication timeout protection mechanism enhances the robustness of the system, enabling timely discovery and processing of communication faults and preventing the system from entering an uncertain state. This fine-grained parameter configuration enables the protocol adaptation layer file to fully utilize the hardware resources of the master control chip, significantly improving the porting efficiency and running performance of the CANopen protocol stack, thereby providing stable and reliable CANopen communication capabilities for the motor driver to be migrated.

[0079] In some embodiments, based on the target task information, the object dictionary configuration file is configured by entries, including: eliminating entries in the object dictionary configuration file irrelevant to the task represented by the target task information, and expanding the entry indicated by the entry expansion request in the object dictionary configuration file when receiving the entry expansion request, to obtain a configured object dictionary configuration file.

[0080] Eliminating entries in the object dictionary configuration file irrelevant to the task represented by the target task information can be retaining only entries matching the current target task information according to a pre-defined mapping relationship between tasks and required object dictionary entries during configuration; or, through semantic analysis of the target task information, identifying the functional modules or data types involved in the task, and then filtering out entries related to these functional modules or data types from the object dictionary configuration file and deleting the remaining irrelevant entries.

[0081] Expanding the entry indicated by the entry expansion request in the object dictionary configuration file can be dynamically creating or adding new entries in the object dictionary configuration file according to the entry information (such as index, sub-index, data type, access permission, etc.) indicated in the request when the execution subject receives an entry expansion request sent by an external (such as a development tool or host computer) during runtime or configuration phase; or, the execution subject can reserve a part of the object dictionary space or use a dynamic memory allocation mechanism, and when detecting the need to support new functions or data points, add new entry definitions to the object dictionary configuration file through a programming interface or configuration tool and update its internal structure.

[0082] The scheme of the present application realizes the close adaptation of the object dictionary configuration file to the target task information through fine management of the object dictionary configuration file. Specifically, when configuring the object dictionary configuration file based on the target task information, first, the "elimination" operation is performed, that is, according to the actual task demand represented by the target task information, intelligently identifying and removing all redundant items in the object dictionary configuration file that are irrelevant to the current task. This process ensures that the finally generated configured object dictionary configuration file is concise and efficient, containing only the data points and function definitions necessary for the motor driver to perform a specific task. On this basis, in order to cope with possible future functional expansion or special needs, the scheme also introduces an "expansion" mechanism. When the execution subject receives an item expansion request issued externally, it can dynamically add new items to the object dictionary configuration file according to the item information explicitly indicated in the request. This two-way, dynamic configuration strategy enables the object dictionary configuration file to be both minimized to save resources and highly flexible to adapt to changing application scenarios. In this way, the present scheme, combined with the overall method of configuring the protocol adaptation layer file and encapsulating the drive template, together builds an efficient, customizable and easy-to-maintain CANopen protocol stack transplantation solution.

[0083] The following is illustrated by a specific example. Suppose the target task information of the motor driver to be migrated indicates that its main function is to implement speed closed-loop control and simple state monitoring of the motor. In the initial object dictionary configuration file, it may contain various items such as current control parameters, advanced diagnostic information, complex motion mode instructions, etc. During the configuration process, the execution subject will automatically identify and eliminate items such as current control parameters, advanced diagnostic information, and complex motion mode instructions that are irrelevant to speed closed-loop control and state monitoring based on the target task information, thereby obtaining a concise configured object dictionary configuration file. For example, if a custom "overload protection threshold" function needs to be added to the motor driver later, and the item corresponding to this function is not included in the initial configuration. At this time, an item expansion request can be sent through the upper computer tool, which can indicate the addition of an "overload protection threshold" item with index 0x607F, sub-index 0x01, and data type UINT16. After receiving this request, the execution subject will dynamically create and add the item in the current configured object dictionary configuration file, thereby realizing flexible expansion of functions.

[0084] By the technical solution, when entries of the object dictionary configuration file are configured based on target task information, irrelevant entries can be accurately removed according to actual task requirements, unnecessary memory occupation and processing overhead are effectively reduced, and system running efficiency is improved. Meanwhile, when an entry expansion request is received, the required entries can be flexibly expanded, the adaptability and scalability of the CANopen protocol stack are greatly enhanced, the motor driver can more efficiently and flexibly respond to different task requirements and function upgrades, and the problem of resource waste or function limitation caused by fixed object dictionary is avoided, thereby improving the practicality and robustness of the CANopen protocol stack transplantation method.

[0085] In some embodiments, the protocol adaptation layer file occupies no more than 3KB of Flash space and no more than 512 bytes of RAM space, and the number of entries in the object dictionary configuration file is no more than 32.

[0086] The scheme of the present application strictly limits the resources of the protocol adaptation layer file and the object dictionary configuration file, ensuring that the entire CANopen protocol stack can efficiently run in a resource-limited embedded environment when the configuration driver template is transplanted to the main control chip of the motor driver to be migrated. Specifically, when the parameters of the protocol adaptation layer file are configured based on target configuration information, the upper limits of Flash and RAM occupation are considered synchronously, guiding the parameter selection and code generation process to strictly control memory consumption while meeting functional requirements. For example, the configuration of the capacity parameter of the ring buffer, the mapping parameter of the PDO mapping entry, and the time length parameter of the communication timeout protection mechanism will be optimized under the limitation of no more than 3KB of Flash and 512 bytes of RAM. Similarly, when entries of the object dictionary configuration file are configured based on target task information, the number of entries will be strictly limited to no more than 32. This makes the configuration process more concise and focused, retaining only entries closely related to the core tasks of the motor driver and eliminating any redundant or unnecessary objects. This synergy ensures that the finally generated configuration driver template is not only functionally complete but also optimally utilizes resources, thereby solving the challenge of efficiently running the CANopen protocol stack on a resource-limited motor driver.

[0087] The following is illustrated by a specific example. Assume that the master chip of the motor driver to be migrated is a microcontroller with 64 KB Flash and 8 KB RAM. When configuring the protocol adaptation layer file, in order to ensure that its Flash occupancy does not exceed 3 KB, a lightweight CANopen protocol stack library can be selected, and only NMT (network management), SDO (service data object) client and TPDO / RPDO (process data object) functions are enabled, while all debugging log outputs and infrequently used error handling mechanisms are disabled. When compiling, the "-Os" (optimize code size) option of the GCC compiler is used, and strict code review is performed on the source files related to the protocol adaptation layer to avoid unnecessary variables and functions. For the limitation of RAM occupancy of no more than 512 bytes, the CAN message buffer in the protocol adaptation layer can be designed as a static allocation fixed size array, for example, a 128 byte buffer is allocated for receiving and sending respectively, and all state variables and flag bits are ensured to use the smallest data type (such as uint8_t), avoiding the use of large structures or dynamic memory allocation. When configuring the object dictionary configuration file, according to the target task of the motor driver (for example, only the motor speed needs to be controlled, the motor current and fault status need to be read), only the following entries can be included: one RPDO mapping entry for setting the speed, one TPDO mapping entry for reading the current, one TPDO mapping entry for reading the fault status, and several SDO entries for configuring motor parameters (such as maximum speed, acceleration). In this way, the number of entries in the object dictionary can be precisely controlled to be within 32, for example, the actual configuration may only include about 20 entries, thereby meeting the resource limitation.

[0088] Through the above technical solutions, the application can significantly optimize the resource occupancy of the CANopen protocol stack on the motor driver. By strictly limiting the Flash and RAM usage of the protocol adaptation layer file and the number of entries in the object dictionary configuration file, problems such as system instability, response delay or inability to start caused by excessive resource consumption can be effectively avoided. This enables the CANopen protocol stack to run more efficiently and stably on embedded motor drivers with extremely limited resources, thereby reducing hardware costs and improving system real-time performance and reliability. In addition, this resource optimization strategy also simplifies the maintenance and upgrade of the protocol stack, providing a solid technical foundation for the wide application of motor drivers.

[0089] In an embodiment, referring to Figure 4 The method after the configuration driver template is transplanted to the master chip of the motor driver to be migrated includes but is not limited to steps S401 to S404.

[0090] Step S401, after the project of the motor driver to be migrated is added to the project of the configuration drive template, it is judged whether the memory resource occupied by the configuration drive template meets the preset memory condition.

[0091] If yes, step S402 is executed; if no, step S203 is returned.

[0092] Step S402, an RPDO control instruction is sent to the motor driver to be migrated.

[0093] Step S403, it is judged whether the controlled motor responds to the RPDO control instruction.

[0094] If yes, step S404 is executed; if no, step S203 is returned.

[0095] Step S404, feedback information for characterizing the successful transplantation is generated.

[0096] After the configuration drive template is transplanted to the master control chip of the motor driver to be migrated, it is indicated that after the core transplantation operation of the CANopen protocol stack is completed, that is, after the drive template adapted to the target hardware and task is deployed to the master control chip of the motor driver, the subsequent verification and feedback mechanism is introduced. This timing ensures that the transplantation effect is checked before the configuration drive template is put into actual operation.

[0097] After the project of the motor driver to be migrated is added to the project of the configuration drive template, it is judged whether the memory resource occupied by the configuration drive template meets the preset memory condition, which aims to verify the resource occupation of the CANopen protocol stack on the target master control chip after transplantation. The preset memory condition can include the limitation of Flash storage space, RAM running memory space, stack size, etc. The judgment can be completed by generating a memory mapping file for analysis in the compilation and linking stage, or by real-time monitoring through the memory management unit (MMU) of the master control chip or the debugging tool in the running time.

[0098] If yes, an RPDO control instruction is sent to the motor driver to be migrated. RPDO (Receive Process DataObject) is a mechanism for real-time data transmission in the CANopen protocol, which is usually used to send control instructions or setting parameters from the CANopen master station to the slave station (i.e. the motor driver). If the memory condition is met, it indicates that the protocol stack is acceptable in terms of resource occupation, and its functionality can be further verified. The RPDO control instruction can be sent to the motor driver, for example, by CANopen master station software or debugging tool, to send start, stop, speed setting, etc. instructions.

[0099] determine whether the controlled motor responds to the RPDO control instruction, aiming to verify whether the transplanted CANopen protocol stack can normally parse and execute the received RPDO instruction and drive the motor to make corresponding actions. The response determination can be completed by monitoring the actual running state of the motor (for example, whether it is started, whether it reaches the set speed, whether there is error feedback), or by reading the state information sent by the motor driver through TPDO (Transmit Process Data Object). If the memory occupation does not meet the preset conditions, or the motor fails to correctly respond to the RPDO instruction, it indicates that there is a problem in the current transplantation or configuration. At this time, the execution subject automatically traces back to the step of configuring the target drive template, so as to adjust and optimize according to the detected problem, otherwise, feedback information is generated to represent the success of transplantation. This can be solved, for example, by modifying the parameters in the protocol adaptation layer file, adjusting the entries in the object dictionary configuration file, or reselecting a more suitable drive template.

[0100] The scheme of the present application introduces an automatic verification and feedback mechanism after the preliminary transplantation of the CANopen protocol stack, to ensure the quality and functionality of the transplantation. First, after integrating the configured drive template into the project engineering of the motor driver, the execution subject will immediately evaluate the memory resources occupied by the drive template, to determine whether it meets the preset memory limit. This step aims to ensure from the resource consumption level that the transplanted protocol stack will not cause excessive burden to the target master chip, thereby avoiding system crash or performance degradation caused by memory overflow or resource shortage. If the memory occupation meets the requirements, the functionality of the protocol stack is further verified by sending RPDO control instruction, that is, checking whether the motor driver can correctly receive, parse and execute the CANopen protocol instruction, and drive the controlled motor to make the expected response. This functional verification is the key to ensure that the transplanted protocol stack can actually play a role. If there is a problem in any verification link (memory occupation or functional response), the execution subject will not simply stop, but intelligently trace back to the configuration stage of the protocol stack, thereby allowing the developer or automatic tool to reconfigure and optimize the target drive template according to the feedback information. This closed-loop verification and feedback process effectively front-loads the testing and debugging link after transplantation and automates it, significantly improves the success rate and efficiency of transplantation, reduces the cost of manual intervention and repeated debugging, and ensures that the transplanted CANopen protocol stack can meet the actual needs of the motor driver in terms of resources and functionality.

[0101] As a specific implementation, after adding the configuration drive template into the project of the motor driver to be migrated, the memory mapping file (for example,.map file) output by the linker of the compiler can be used to analyze the Flash and RAM space occupied by the configuration drive template. The preset memory condition can be set as that the Flash space does not exceed 3 KB and the RAM space does not exceed 512 bytes. If the analysis result shows that the memory occupation exceeds these limits, it is judged that the preset memory condition is not met. If the memory occupation meets the condition, an RPDO control instruction is sent to the motor driver to be migrated through a CANopen master simulator, for example, a "start motor" instruction (object dictionary entry 6040h (control word), value 0Fh, or object dictionary entry 6060h (mode), value 03h, or object dictionary entry 6081h (target speed), value 0Ah) is sent. At this time, whether the motor has entered the "running" state can be judged by monitoring the TPDO status word (for example, object dictionary entry 6041h) output by the motor driver, or the rotation of the motor can be detected by an external sensor. If the motor is not started or the status word is not updated correctly, it is judged that the RPDO control instruction is not responded. Whether the memory does not meet the condition or the motor does not respond, the execution subject triggers a backtracking mechanism, for example, a prompt box is popped up in the development environment, indicating the user to return to the interface of configuring the target drive template, and providing specific error information, so that the user adjusts the ring buffer capacity parameter in the protocol adaptation layer file or the mapping parameter of the PDO mapping entry, or modifies the entries in the object dictionary configuration file.

[0102] Through the above technical solution, after the CANopen protocol stack is transplanted, an automatic memory resource checking and functional verification mechanism is introduced. This effectively avoids the problem of instability or crash caused by the transplanted protocol stack occupying too much memory resource, and ensures that the transplanted protocol stack can correctly respond to the CANopen control instruction and drive the motor to work normally. When it is detected that the memory does not meet the requirements or the motor does not respond, the execution subject can timely feedback and automatically backtrack to the configuration stage, thereby allowing the protocol stack to be quickly iterated and optimized, significantly reducing the time and cost of manual debugging and troubleshooting, improving the success rate and efficiency of transplantation, and ensuring that the transplanted CANopen protocol stack can meet the actual needs of the motor driver in terms of resources and functions, thereby improving the reliability and stability of the motor driver.

[0103] Referring to Figure 5 , the embodiment of the application also provides a CANopen protocol stack transplantation device, which can implement the CANopen protocol stack transplantation method. The device comprises: The first module 501 is configured to acquire target configuration information and target task information of the motor driver to be migrated; the target configuration information comprises hardware configuration information of a master chip, a CAN controller and a CAN transceiver, and the target task information is task information of a task to be executed by the motor driver to be migrated. The second module 502 is configured to determine a target drive template based on the hardware configuration information of the master chip; the target drive template is a drive template adapted to the master chip and used for developing a device driver supporting the CANopen protocol. The third module 503 is configured to configure the target drive template based on the target configuration information and the target task information, to obtain a configured drive template adapted to the target configuration information. The fourth module 504 is configured to transplant the configured drive template to the master chip of the motor driver to be migrated.

[0104] The specific implementation of the CANopen protocol stack transplantation apparatus is basically the same as that of the above-described CANopen protocol stack transplantation method, and thus will not be described herein again.

[0105] Figure 6 FIG. 1 is a schematic diagram of a hardware structure of an electronic device provided by an embodiment of the present application.

[0106] The electronic device 600 according to this embodiment of the present disclosure will be described below with reference to Figure 6 FIG. 1. Figure 6 The electronic device 600 shown is merely an example, and should not impose any limitation on the functions and use range of the embodiments of the present disclosure.

[0107] As shown in Figure 6 FIG. 1, the electronic device 600 is in the form of a general computing device. The components of the electronic device 600 can include, but are not limited to, at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including the storage unit 620 and the processing unit 610), a display unit 640, and the like.

[0108] The storage unit stores program codes which can be executed by the processing unit 610, so that the processing unit 610 performs the steps according to various exemplary embodiments of the present disclosure described in the above CANopen protocol stack transplantation method part of the present specification.

[0109] The storage unit 620 can include a readable medium in the form of a volatile storage unit, such as a random access memory (RAM) 6201 and / or a cache memory unit 6202, and can further include a read-only memory (ROM) 6203.

[0110] The storage unit 620 can also include a program / utility 6204 having a set of programs / modules 6205, each of which performs one or more of the operations / acts described herein. These include, for example, operating system, one or more applications, other program modules, and program data, each of which or a combination thereof, can include implementation of a networking environment.

[0111] The bus 630 can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration bus, a processor or local bus using any of a variety of bus architectures, and the like.

[0112] The electronic device 600 can also communicate with one or more external devices 600' such as a keyboard or pointing device, a Bluetooth device, etc.; and / or one or more devices that enable a user to interact with the electronic device 600; and / or one or more devices (e.g., a router, a modem, a network card, etc.) that enable the electronic device 600 to communicate with one or more other computing devices. Such communication can occur via an input / output (I / O) interface 650. Still yet, the electronic device 600 can communicate with one or more networks (such as one or more external networks) via a network adapter 660. The network adapter 660 can be any of a variety of different types of adapters, such as a modem, a network card, etc. The network adapter 660 can be communicatively coupled to the other components of the electronic device 600 via the bus 630. It should be appreciated that the electronic device 600 can be a part of one or more networks, such as a local area network (LAN), a wide area network (WAN), and / or the Internet, among others. It should be appreciated that the electronic device 600 can be any of a variety of electronic devices such as, for example, a smart phone, a tablet computer, a personal computer, a laptop computer, a desktop computer, a gaming console, a television, a set-top box, a streaming device, a digital media player, a digital video recorder, a navigation device, a vehicle, a wearable device, and / or the like.

[0113] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method described above.

[0114] The CANopen protocol stack transplantation method, device, equipment and medium provided by the embodiments of the application select a target drive template based on target configuration information and target task information of a motor driver to be migrated, and transplant the target drive template to a master control chip of the motor driver to be migrated after configuration, thereby simplifying the transplantation process of the CANopen protocol stack to different hardware platforms. Thus, the method of selecting a target drive template based on target configuration information and target task information of a motor driver to be migrated and configuring the target drive template can efficiently generate a highly customized and lightweight configured drive template, avoid tedious manual trimming and modification, and significantly reduce the complexity and error rate of transplantation. Meanwhile, by accurately matching hardware resources and application requirements, the Flash and RAM resources occupied by the generated configured drive template are minimized, thereby leaving more resources for the motion control algorithm of the master control chip and ensuring the real-time performance and response speed of the motion control of the motor driver.

[0115] Through the description of the above embodiments, those skilled in the art can easily understand that the example embodiments described herein can be implemented by software or by software in combination with necessary hardware. Therefore, the technical solutions according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a U disk, a mobile hard disk, etc.) or a network, and includes a plurality of instructions to make a computing device (which can be a personal computer, a server, or a network device, etc.) execute the above-mentioned method according to the embodiments of the present disclosure.

[0116] The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0117] The computer readable storage medium can include a computer-readable storage medium comprising a data signal embodied in or carried by a carrier wave or other transport mechanism and constitutes media which carries or stores the program code in a modulated data signal. Such a propagated signal can take a wide variety of forms including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable medium can be any medium that can be read by a computer including magnetic tape; magnetic disk; optical disk; optical fiber; and / or electrical signals.

[0118] Those skilled in the art can understand that the above-mentioned modules can be distributed in the device according to the description of the embodiment, and can also be changed in one or more devices different from the embodiment. The modules of the above-mentioned embodiment can be combined into one module, or can be further split into a plurality of sub-modules.

[0119] The exemplary embodiments of this disclosure are specifically shown and described above. It should be understood that the present disclosure is not limited to the detailed structure, arrangement or implementation method described herein; on the contrary, the present disclosure is intended to cover various modifications and equivalent arrangements within the spirit and scope of the appended claims.

Claims

1. A method for porting the CANopen protocol stack, characterized in that, include: Obtain the target configuration information and target task information of the motor driver to be migrated; The target configuration information includes the hardware configuration information of the main control chip, CAN controller and CAN transceiver, and the target task information is the task information of the task to be performed by the motor driver to be migrated; Based on the hardware configuration information of the main control chip, the target driver template is determined; The target driver template is adapted to the main control chip and used to develop device drivers that support the CANopen protocol. Based on the target configuration information and the target task information, configure the target driver template to obtain a configured driver template adapted to the target configuration information; The configuration driver template is migrated to the main control chip of the motor driver to be migrated.

2. The CANopen protocol stack porting method according to claim 1, characterized in that, The determination of the target driver template based on the hardware configuration information of the main control chip includes: Based on the hardware configuration information of the main control chip, the driver template corresponding to the main control chip is found in the predefined template library, and the CAN pin definition information and timer channel definition information of the driver template are edited to obtain the target driver template.

3. The CANopen protocol stack porting method according to claim 1, characterized in that, The target driver template includes a protocol adaptation layer file, an object dictionary configuration file, and an application layer interface file. Configuring the target driver template based on the target configuration information and the target task information includes: Based on the target configuration information, the protocol adaptation layer file is configured with parameters to obtain the configured protocol adaptation layer file; Based on the target task information, the object dictionary configuration file is configured with entries to obtain the configured object dictionary configuration file; The configured protocol adaptation layer file, the configured object dictionary configuration file, and the application layer interface file are encapsulated to obtain the configured driver template.

4. The CANopen protocol stack porting method according to claim 3, characterized in that, The step of configuring parameters for the protocol adaptation layer file based on the target configuration information includes: Based on the hardware configuration information of the main control chip, the capacity parameter of the circular buffer, the mapping parameter of the PDO mapping entry, and the duration parameter of the communication timeout protection mechanism in the protocol adaptation layer file are configured to the corresponding parameter values ​​to obtain the configured protocol adaptation layer file.

5. The CANopen protocol stack porting method according to claim 3, characterized in that, The step of configuring entries in the object dictionary configuration file based on the target task information includes: Remove entries from the object dictionary configuration file that are unrelated to the task represented by the target task information. When an entry expansion request is received, expand the entry indicated by the entry expansion request in the object dictionary configuration file to obtain the configured object dictionary configuration file.

6. The CANopen protocol stack porting method according to any one of claims 3 to 5, characterized in that, The protocol adaptation layer file occupies no more than 3KB of Flash space and no more than 512 bytes of RAM space, and the number of entries in the object dictionary configuration file does not exceed 32.

7. The CANopen protocol stack porting method according to claim 1, characterized in that, After migrating the configuration driver template to the main control chip of the motor driver to be migrated, the method further includes: After the project of the motor driver to be migrated is added to the configuration driver template, it is determined whether the memory resources occupied by the configuration driver template meet the preset memory conditions. If the conditions are met, send an RPDO control command to the motor driver to be migrated; Determine whether the controlled motor responds to the RPDO control command; If it does not meet the requirements or does not respond, return to the step of configuring the target driver template based on the target configuration information and the target task information.

8. A CANopen protocol stack porting device, characterized in that, include: The first module is used to obtain the target configuration information and target task information of the motor driver to be migrated. The target configuration information includes the hardware configuration information of the main control chip, CAN controller and CAN transceiver, and the target task information is the task information of the task to be performed by the motor driver to be migrated; The second module is used to determine the target driver template based on the hardware configuration information of the main control chip; The target driver template is adapted to the main control chip and used to develop device drivers that support the CANopen protocol. The third module is used to configure the target driver template based on the target configuration information and the target task information, so as to obtain a configured driver template adapted to the target configuration information. The fourth module is used to migrate the configuration driver template to the main control chip of the motor driver to be migrated.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the CANopen protocol stack porting method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the CANopen protocol stack porting method as described in any one of claims 1 to 7.

Images