Method, device and equipment for CANopen protocol stack transplantation and medium

Abstract

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

Description

Technical Field

[0001] This application relates to the field of protocol stack porting technology, and in particular to a CANopen protocol stack porting method, apparatus, device and medium. Background Technology

[0002] Due to its high degree of standardization and reliability, the CANopen protocol has become the mainstream communication protocol in the field of motor drivers. However, traditional CANopen protocol stacks (such as the complete CiA 301 standard version) include a full range of functional modules such as object dictionary, PDO / SDO, emergency messages, and NMT, resulting in a large amount of code and memory consumption. Furthermore, the main control chips of motor drivers (especially small and medium-sized servo drivers and stepper drivers) are mostly low-cost MCUs (such as the STM32 series and Renesas RL78 series), with limited Flash and RAM capacity. Moreover, the core task of the driver is motion control, which requires high real-time communication response.

[0003] Therefore, the redundancy of the CANopen protocol stack may consume resources of the motor driver's main control chip, affecting the execution efficiency of the motion control algorithm and increasing communication latency. Furthermore, it suffers from high portability, requiring extensive parameter modifications when adapting to different main control chip compilation environments and peripheral interfaces. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, device, and medium for porting the CANopen protocol stack, aiming to improve the porting efficiency of the CANopen protocol stack.

[0005] This application provides a method for porting the CANopen protocol stack, including:

[0006] 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;

[0007] Based on the hardware configuration information of the main control chip, a target driver template is determined; the target driver template is adapted to the main control chip and used to develop a device driver that supports the CANopen protocol.

[0008] 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;

[0009] The configured driver template is then migrated to the main control chip of the motor driver to be migrated.

[0010] In some embodiments, determining the target driver template based on the hardware configuration information of the main control chip includes:

[0011] 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.

[0012] In some embodiments, 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:

[0013] Based on the target configuration information, the protocol adaptation layer file is configured with parameters to obtain the configured protocol adaptation layer file;

[0014] Based on the target task information, the object dictionary configuration file is configured with entries to obtain the configured object dictionary configuration file;

[0015] 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.

[0016] In some embodiments, configuring parameters of the protocol adaptation layer file based on the target configuration information includes:

[0017] 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.

[0018] In some embodiments, configuring entries in the object dictionary configuration file based on the target task information includes:

[0019] Remove entries from the object dictionary configuration file that are irrelevant 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.

[0020] 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 does not exceed 32.

[0021] In some embodiments, after migrating the configured driver template to the main control chip of the motor driver to be migrated, the method further includes:

[0022] After the configured driver template is added to the project of the motor driver to be migrated, it is determined whether the memory resources occupied by the configured driver template meet the preset memory conditions.

[0023] If the conditions are met, send an RPDO control command to the motor driver to be migrated;

[0024] Determine whether the controlled motor responds to the RPDO control command;

[0025] 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.

[0026] This application also provides a CANopen protocol stack porting device, including:

[0027] 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;

[0028] 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 a device driver that supports the CANopen protocol.

[0029] 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.

[0030] The fourth module is used to migrate the configured driver template to the main control chip of the motor driver to be migrated.

[0031] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described CANopen protocol stack porting method.

[0032] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described CANopen protocol stack porting method.

[0033] The beneficial effects of this application are as follows: A target driver template is selected based on the target configuration and target task information of the motor driver to be migrated, and after configuration, it is ported to the main control chip of the motor driver to be migrated, thereby simplifying the porting process of the CANopen protocol stack to different hardware platforms. Therefore, the method of selecting and configuring a target driver template based on the target configuration and target task information of the motor driver to be migrated can efficiently generate a highly customized, lightweight configured driver template, avoiding tedious manual trimming and modification, and significantly reducing the complexity and error rate of porting. At the same time, by accurately matching hardware resources and application requirements, the Flash and RAM resources occupied by the generated configured driver template are minimized, thus reserving more resources for the motion control algorithm of the main control chip, ensuring the real-time performance and response speed of the motor driver's motion control. Attached Figure Description

[0034] Figure 1 This is a diagram illustrating the application environment of the CANopen protocol stack porting method provided in the embodiments of this application.

[0035] Figure 2 This is a flowchart of the CANopen protocol stack porting method provided in the embodiments of this application.

[0036] Figure 3 This is a flowchart of a method for configuring a target driver template provided in an embodiment of this application.

[0037] Figure 4 This is a flowchart of a method provided in this application embodiment for migrating the configured driver template to the main control chip of the motor driver to be migrated.

[0038] Figure 5 This is a schematic diagram of the CANopen protocol stack porting device provided in the embodiments of this application.

[0039] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

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

[0042] 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 this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] Figure 1 This diagram illustrates the application environment of the CANopen protocol stack porting method provided in this embodiment. (See also...) Figure 1 This method is applied to a CANopen protocol stack porting system. The system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of several servers. The terminal 110 sends the target configuration information and target task information of the motor driver to be migrated to the server 120. The server 120 obtains the target configuration information and target task information of the motor driver to be migrated, determines the target driver template based on the hardware configuration information of the main control chip, configures the target driver template based on the target configuration information and target task information, obtains a configured driver template adapted to the target configuration information, and portes the configured driver template to the main control chip 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; the target driver template is a device driver program adapted to the main control chip and used to develop support for the CANopen protocol.

[0048] It should be understood that Figure 1 The application scenarios shown are merely examples. In practical applications, the CANopen protocol stack porting method provided in this application embodiment can also be applied to other scenarios. For example, the above-described CANopen protocol stack porting method can be directly applied to terminal 110. Terminal 110 is used to obtain the target configuration information and target task information of the motor driver to be migrated, determine the target driver template based on the hardware configuration information of the main control chip, configure the target driver template based on the target configuration information and target task information, obtain the configured driver template adapted to the target configuration information, and port the configured driver template to the main control chip of the motor driver to be migrated.

[0049] See Figure 2 In one embodiment, a CANopen protocol stack porting method is provided. The execution subject of the method can be a terminal or a server, including but not limited to steps S201 to S204.

[0050] Step S201: Obtain the target configuration information and target task information of the motor driver to be migrated.

[0051] The motor driver to be migrated refers to a motor drive device that needs to integrate the CANopen protocol stack to implement CANopen communication functionality. This driver typically contains a main control chip responsible for executing motion control algorithms and handling communication tasks.

[0052] 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.

[0053] 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.

[0054] 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.

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

[0056] 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.

[0057] When determining the target driver template, the following methods can be used: The execution entity maintains a list containing multiple main control chip driver templates. Engineers manually select a driver template compatible with the main control chip from this list as the target driver template, based on the obtained main control chip hardware configuration information. Alternatively, the execution entity can automatically filter one or more driver templates that best meet the criteria from a general template library based on the main control chip's model, architecture, and other hardware configuration information, using preset matching rules. Another option is for engineers to input detailed parameters of the main control chip and then use a code generation tool to dynamically generate a basic driver template based on these parameters.

[0058] Step S203: Based on the target configuration information and target task information, configure the target driver template to obtain the configured driver template adapted to the target configuration information.

[0059] A configured driver template refers to a customized driver program obtained by adjusting parameters and tailoring functions based on the target driver template and the target configuration and task information of the motor driver to be migrated. This template can accurately adapt to the target hardware environment and application requirements, thereby achieving efficient and resource-optimized CANopen communication functions.

[0060] This configuration process can be implemented in several ways. For example, engineers can manually modify macro definitions, variable values, and function calls in the target driver template based on target configuration and task information to adapt to specific hardware resources and functional requirements. As a more automated approach, a configuration script can be written that reads the target configuration and task information and then automatically modifies specific code segments or configuration files in the target driver template. Alternatively, a graphical configuration tool can be provided, allowing engineers to set various parameters and function options on the interface through drag-and-drop and check-and-click operations, while the tool automatically generates or modifies the code in the target driver template in the background.

[0061] Step S204: The configured driver template is migrated to the main control chip of the motor driver to be migrated.

[0062] The porting process typically involves integrating the configured driver template code into the motor driver project, then manually compiling and linking it, and finally burning the generated firmware to the main control chip via debugging interfaces such as JTAG / SWD. To improve efficiency, an automated deployment tool can be used. This tool can automatically complete a series of operations, including code integration, compilation, and burning, thereby deploying the configured driver template to the target main control chip. As a remote deployment method, an OTA (Over-The-Air) update function can be reserved on the main control chip. The configured driver template can be sent to the main control chip as a firmware package via network or serial interface, where it will be updated by the chip's internal bootloader.

[0063] The following example will provide a more detailed explanation of the above technical solution:

[0064] Suppose there is a motor driver to be migrated, whose main control chip is a low-cost microcontroller (e.g., MCU-A) with limited Flash and RAM resources. This motor driver needs to implement a simple CANopen speed control task, i.e., receiving speed commands and controlling the motor speed via the CANopen network. Traditional CANopen protocol stacks, due to their large codebase and comprehensive functional modules, are difficult to directly adapt to such resource-constrained microcontrollers. Furthermore, manual customization and porting are complex, prone to introducing errors, and prolong the development cycle.

[0065] To address the aforementioned issues, the first step is to obtain the target configuration and target task information for the motor driver to be migrated. Specifically, engineers consult the MCU-A hardware manual to obtain hardware configuration information such as the model of its main control chip, details of the internal CAN controller's register configuration, and the model of the CAN transceiver used. Simultaneously, based on the application requirements of the motor driver, its target task is defined as "CANopen speed control," which includes the required CANopen object dictionary entries (e.g., control words, status words, target speeds, etc. in speed mode) and PDO mapping relationships. Accurate acquisition of this information is fundamental to subsequent steps.

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

[0067] Next, based on the previously acquired target configuration and target task information, the target driver template is configured. For example, for the CAN controller hardware configuration of the MCU-A, parameters such as the baud rate and filter mask of the CAN controller in the template are adjusted. Simultaneously, according to the target task of "CANopen speed control," object dictionary entries related to speed control are defined or enabled in the template, and the corresponding PDO mappings are configured to ensure that the motor driver can correctly receive and send speed control data. Through this configuration process, the target driver template is customized, forming a configured driver template adapted to the MCU-A hardware environment and speed control task. This configured driver template only contains the CANopen protocol stack functions required to implement the speed control task, thus avoiding unnecessary code and memory consumption.

[0068] Finally, the configured driver template is ported to the main control chip MCU-A of the motor driver to be migrated. This typically involves compiling the configured code into executable firmware and burning it into the MCU-A's Flash memory using a programmer or debugger. Once the porting is complete, the MCU-A can communicate with the host computer via the CANopen network, receive speed commands, and drive the motor to run according to a preset speed curve. This structured process significantly reduces the difficulty of porting the CANopen protocol stack to resource-constrained motor drivers, optimizes system resource utilization, and ensures the real-time performance and efficiency of motion control.

[0069] Based on the above examples, the CANopen protocol stack porting method proposed in this embodiment demonstrates significant technical contributions. In traditional porting schemes, engineers typically need to manually trim redundant functions from the complete CANopen protocol stack and modify the underlying driver code and configuration parameters one by one for specific hardware platforms. For example, in the above scenario of MCU-A motor driver speed control, if the traditional method is used, engineers need to spend a lot of time analyzing each module of the complete CiA 301 standard protocol stack, manually deleting functions unrelated to speed control such as SDO and emergency messages, and manually writing or modifying the MCU-A's CAN controller initialization code, interrupt service routines, etc. This manual trimming and modification process is not only extremely labor-intensive but also prone to introducing errors, resulting in a long debugging cycle. Especially for resource-constrained low-cost microcontrollers, even a slight mistake can lead to memory overflow or performance degradation.

[0070] In contrast, this embodiment provides a systematic, efficient, and resource-optimized porting approach by acquiring target configuration and task information, determining the target driver template based on the main control chip's hardware information, configuring the target driver template based on the target configuration and task information, and porting the configured driver template to the main control chip. For example, after acquiring the hardware configuration and speed control task information of the MCU-A, the execution entity can automatically or semi-automatically determine a basic driver template adapted to the MCU-A. Subsequently, by selectively configuring this template, retaining only the CANopen protocol stack functions required to implement the speed control task, a highly customized, lightweight configured driver template is generated. This method avoids the tedious manual trimming and modification in traditional solutions, significantly reducing the complexity and error rate of porting.

[0071] Therefore, the technical solution of this embodiment can effectively solve the problems of large code size, high memory consumption, and high portability of traditional CANopen protocol stacks. By accurately matching hardware resources and application requirements, the Flash and RAM resources occupied by the generated configured driver template are minimized, thereby reserving more resources for the motion control algorithm of the main control chip and ensuring the real-time performance and response speed of the motor driver motion control. At the same time, by providing a structured configuration process and a template-based development model, this method significantly improves the portability efficiency of CANopen protocol stacks under different main control chips and application scenarios, shortens the product development cycle, and has significant practical value and technological advancement.

[0072] In some embodiments, determining the target driver template based on the hardware configuration information of the main control chip includes: searching for a driver template corresponding to the main control chip from a predefined template library based on the hardware configuration information of the main control chip, editing the CAN pin definition information and timer channel definition information of the driver template, and obtaining the target driver template.

[0073] When determining the target driver template, the first step is to search for the corresponding driver template from a predefined template library based on the hardware configuration information of the main control chip. This driver template is the starting point for developing device drivers that support the CANopen protocol. For example, a mapping table between the main control chip model and the driver template can be established in the predefined template library. When the hardware configuration information of the main control chip is input, the execution entity automatically queries this mapping table and returns the corresponding driver template. Alternatively, features can be extracted from the hardware configuration information of the main control chip, and then fuzzy matching or keyword search algorithms can be used to find the driver template in the template library that best matches these features.

[0074] Next, the CAN pin definition information of the driver template needs to be edited. 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 main control chip. Since the hardware design of different motor drivers or main control chips may connect the CAN module to different GPIO pins, the preset pin definitions in the driver template need to be modified to match the actual hardware connection and ensure normal CAN communication. For example, a graphical user interface (GUI) tool can be used to allow users to intuitively select or input the GPIO ports and pin numbers corresponding to the CAN_TX and CAN_RX pins on the main control chip, and then the tool automatically modifies the relevant macro definitions or structure members in the driver template; alternatively, users can directly modify specific fields in a configuration file (such as XML, JSON, or C header files), such as `#define CAN_TX_PIN GPIOA_PIN9`, to update the CAN pin definitions. Simultaneously, the timer channel definition information of the driver template also needs to be edited. Timer channel definition information refers to the configuration of the timer modules inside the main control chip. These timers are typically used to implement time-sensitive functions in the CANopen protocol, such as the heartbeat message transmission cycle, timeout detection for node protection mechanisms, and synchronous transmission of PDOs (Process Data Objects). Different main control chips or application scenarios may require different timer resources or different timer channels. Therefore, the preset timer configurations in the driver template need to be adjusted to meet the protocol stack's time accuracy requirements and the actual allocation of hardware resources. For example, the configuration tools provided by the integrated development environment (IDE) can be used to select the available timer modules (such as TIM1, TIM2, etc.) for the main control chip and configure their operating modes (such as up counting, down counting), prescalers, auto-reload values, and interrupt priorities. Then, the tool generates corresponding code snippets to update the driver template. Alternatively, the timer initialization function or macro definition in the driver template can be modified to manually specify the timer instance, channel number, and related clock source and counting period to ensure that the timer function is consistent with the requirements of the CANopen protocol stack. Through the above editing, the target driver template is finally obtained.

[0075] This application's solution utilizes the hardware configuration information of the main control chip to intelligently search for and obtain a basic driver template that perfectly matches the model or architecture of the main control chip from a predefined template library, providing a hardware abstraction layer for the operation of the CANopen protocol stack. Based on this, the found driver template is further refined by modifying the preset CAN pin definition information in the template to ensure that the transmit and receive pins of the CAN communication module are accurately mapped to the actual physical pins of the main control chip of the motor driver to be migrated, thereby establishing a reliable CAN bus connection. Simultaneously, by editing the timer channel definition information, the timer configuration in the driver template is matched with the actual timer resources of the main control chip and the CANopen protocol stack's requirements for time synchronization, timeout detection, and other functions. This combination of searching and editing ensures that the generated target driver template is not only macroscopically compatible with the main control chip but also microscopically precisely aligned with the specific hardware layout and timing requirements, thus laying a solid foundation for the stable operation of the subsequent CANopen protocol stack.

[0076] The following is a concrete example. After obtaining the hardware configuration information of the main control chip of the motor driver to be migrated, for example, if the main control chip is an STM32F407 series microcontroller, the execution entity can first search for the keyword "STM32F407" in the predefined template library to find a driver template designed for the STM32F407 series microcontroller. Subsequently, to adapt this general template to the specific motor driver hardware, it needs to be customized. 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 main control chip, the macro definitions of the CAN pins in the driver template need to be modified and updated to `#define CAN_RX_GPIO_PORT GPIOA`, `#define CAN_RX_GPIO_PIN GPIO_PIN_11`, `#define CAN_TX_GPIO_PORT GPIOA`, and `#define CAN_TX_GPIO_PIN GPIO_PIN_12`. Meanwhile, if the CANopen protocol stack needs to use the TIM3 timer to implement the periodic transmission of heartbeat messages, and this timer channel is assigned as channel 1 in the current hardware design, then the timer initialization related code in the driver template needs to be edited to configure TIM3 channel 1 with an appropriate counting mode and period, such as setting the prescaler and auto-reload register, to achieve precise timing functionality. Through these specific editing operations, a target driver template that is fully adapted to the STM32F407 main control chip and the specific motor driver hardware layout is finally obtained.

[0077] Through the above technical solution, when determining the target driver template, not only can the basic template be quickly located based on the hardware configuration information of the main control chip, but also the CAN pin definition information and timer channel definition information can be edited specifically. This effectively solves the problem of mismatch between the basic template and the specific hardware pin allocation and timer resource usage, avoiding communication failures or timing errors caused by hardware differences. This fine-grained configuration ensures that after the CANopen protocol stack is ported to the main control chip of the motor driver to be migrated, it can accurately and efficiently interact with the underlying hardware, significantly improving the success rate of protocol stack porting and operational stability, and reducing the workload of manually debugging and modifying the underlying driver code.

[0078] In one embodiment, the target-driven template includes a protocol adaptation layer file, an object dictionary configuration file, and an application layer interface file. See also... Figure 3 The method for configuring the target driver template includes, but is not limited to, steps S301 to S303.

[0079] Step S301: Based on the target configuration information, configure the parameters of the protocol adaptation layer file to obtain the configured protocol adaptation layer file.

[0080] Step S302: Based on the target task information, configure the entries in the object dictionary configuration file to obtain the configured object dictionary configuration file.

[0081] Step S303: Encapsulate the configured protocol adapter layer file, the configured object dictionary configuration file, and the application layer interface file to obtain the configured driver template.

[0082] The protocol adaptation layer file acts as a bridge between the CANopen protocol stack and the underlying hardware (such as the CAN controller and CAN transceiver). Its role is to translate the general communication commands 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, and handling CAN interrupts. This file can exist as a C language source file, defining hardware-related function interfaces and data structures; alternatively, it can be a pre-compiled library file, providing standardized APIs for upper layers to call.

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

[0084] The application layer interface file provides a standardized interface for upper-layer applications (such as motor control algorithms and 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 and send PDO (Process Data Object) or SDO (Service Data Object) requests through simple function calls. This file typically provides function declarations and data structure definitions in the form of a C language header file (.h), while its corresponding implementation file is responsible for calling the protocol adaptation layer and manipulating the object dictionary.

[0085] Based on the target configuration information, the protocol adapter layer file is configured with parameters such as CAN baud rate, CAN interrupt priority, and CAN receive / transmit buffer size, according to the system clock frequency of the main control chip, the register address and interrupt vector of the CAN controller, and the drive characteristics of the CAN transceiver. This configuration can be achieved by modifying macro definitions, global variables, or structure members in the protocol adapter layer file; alternatively, these parameters can be dynamically set at runtime by calling specific configuration functions.

[0086] Based on the target task information, the object dictionary configuration file is configured with entries, primarily involving customized adjustments to the entries within the configuration file. This includes adding new task-related entries (such as target speed, actual location, current limits, etc.), deleting redundant entries unrelated to the current task, modifying the data type or access permissions of existing entries, and setting default values ​​or ranges for entries. This configuration can be achieved by editing the data item definitions in the object dictionary configuration file; alternatively, it can be done through a dedicated configuration tool with a graphical interface, generating the corresponding configuration file.

[0087] The encapsulation of the protocol adapter layer file, object dictionary configuration file, and application layer interface file involves integrating these files—after parameter and entry configuration—into a complete and deployable driver template. The purpose of this encapsulation is to facilitate subsequent porting and compilation. This can be achieved by organizing these files within a specific project directory structure and providing corresponding build scripts (such as Makefile or CMakeLists.txt); or by compiling and linking these files into a static or dynamic library for use by applications on the main control chip.

[0088] This application's solution decouples the target driver template into three core components: a protocol adaptation layer file, an object dictionary configuration file, and an application layer interface file, achieving refined and modular configuration of the CANopen protocol stack. First, the protocol adaptation layer file, acting as a hardware abstraction layer, precisely adjusts its parameters based on the target configuration information, ensuring seamless integration between the CANopen protocol stack and the main control chip, CAN controller, and CAN transceiver of the motor driver to be migrated. This provides stable and reliable underlying communication services for the upper-layer protocol stack. Second, the object dictionary configuration file, as the core of device parameter and data storage, customizes its entries based on the target task information, removing unnecessary entries and adding key data required for the task, ensuring the protocol stack accurately reflects the functional requirements of the motor driver. Simultaneously, the application layer interface file provides a standardized API, enabling upper-layer applications to easily access and manipulate the configured protocol stack and object dictionary. Finally, by encapsulating these independently configured and optimized files, a complete and highly customized configured driver template is formed. This structured configuration approach makes the porting process of the CANopen protocol stack no longer a simple code copying process, but a precise tailoring and optimization for specific hardware and task requirements. This effectively solves the problem that general driver templates are difficult to accurately adapt to specific hardware and task requirements, and significantly improves the efficiency and success rate of porting.

[0089] As a specific implementation, assume the main control chip of the motor driver to be migrated is an STM32F407 series microcontroller from STMicroelectronics, which integrates a CAN controller and is paired with an NXP TJA1051 CAN transceiver. The target task is to implement closed-loop speed control of the motor. In this case, the target driver template can be a software project containing the following files: a protocol adapter layer file, for example named `can_hal_adapter.c`, which contains initialization code for the STM32F407's built-in CAN controller, interrupt service routines, and CAN frame send and receive functions. Based on the target configuration information, the parameters in this file will be configured as follows: CAN baud rate of 500kbps, CAN interrupt priority set to NVIC_PRIORITY_5, and CAN receive FIFO0 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 are configured to include: a control word (index 0x6040), modes of operation (index 0x6060), target velocity (index 0x6081h), and actual velocity (index 0x6064), with their data types (e.g., UINT16, INT32) and access permissions (e.g., read / write, read-only). Redundant entries unrelated to speed control, such as position control or current control, can be removed. The application layer interface file, for example named `motor_app_interface.h`, defines the functions called by the motor control application. Finally, these configured files, such as `can_hal_adapter.c`, `obj_dict_config.h`, and `motor_app_interface.h`, are compiled and linked to generate firmware that can be burned into the STM32F407 microcontroller; this is the configured driver template.

[0090] By refining the target driver template into protocol adaptation layer files, object dictionary configuration files, and application layer interface files, and configuring parameters and entries based on target configuration information and target task information respectively, this application's solution achieves a high degree of modularity and customization of the CANopen protocol stack. This structured configuration approach enables the protocol stack to accurately adapt to different hardware platforms and diverse motor control tasks, avoiding redundant code and unnecessary resource consumption caused by general templates. Therefore, the ported CANopen protocol stack not only runs efficiently and stably, but also significantly improves development efficiency and system flexibility, ensuring optimal performance of the motor driver in specific application scenarios.

[0091] In some embodiments, the protocol adaptation layer file is configured with parameters based on the target configuration information, including: configuring the capacity parameter of the ring 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 to the corresponding parameter values ​​based on the hardware configuration information of the main control chip, so as to obtain the configured protocol adaptation layer file.

[0092] The capacity parameter of the circular buffer is used to store a circular queue of CAN messages. Data is written when it arrives and read when it is processed. This parameter is set to balance differences in data transmission and reception rates, prevent data loss, and improve communication efficiency. Its setting can be based on factors such as the RAM size of the main control chip, the CAN bus load, and the message processing speed; for example, it can be set to store 16, 32, or 64 CAN frames.

[0093] The mapping parameters for PDO (Process Data Object) mapping entries refer to the mapping relationship between application layer variables and PDO message data fields. PDO is a mechanism in the CANopen protocol used for real-time data transmission. The configuration of these parameters aims to ensure that application layer data can be transmitted correctly and efficiently through PDO. The configuration includes the PDO's COB-ID (Communication Object Identifier), transmission type (synchronous / asynchronous), event timer, and the index and sub-index of the object dictionary entries contained in each PDO.

[0094] The communication timeout protection mechanism's duration parameter is used to detect whether nodes in the CANopen network are functioning correctly. By setting a timeout period, if the expected message is not received within this time, communication is considered abnormal. This parameter is configured to improve system robustness, promptly detect and handle communication failures, and prevent the system from entering an uncertain state. For example, it can be configured as the sending cycle and timeout period for node guarding or heartbeat messages.

[0095] This application's solution, based on the hardware configuration information of the main control chip, finely configures key communication parameters in the protocol adaptation layer file, thereby ensuring the efficient and stable operation of the CANopen protocol stack on a specific hardware platform. Specifically, firstly, based on the RAM size of the main control chip, the characteristics of the CAN controller, and the expected CAN bus load, the capacity parameters of the ring buffer are precisely set to optimize data transmission and reception efficiency and effectively avoid buffer overflow. Secondly, considering the application layer's requirements for real-time data transmission, the mapping parameters of PDO mapping entries are defined in detail, accurately associating application layer variables with the CANopen PDO message structure to ensure timely and reliable transmission of process data. Furthermore, to enhance system robustness, the duration parameters of the communication timeout protection mechanism are configured according to the timer resources of the main control chip and the system response time requirements, enabling the system to promptly detect and respond to communication anomalies and prevent system instability caused by communication failures. These parameter settings are based on the hardware characteristics of the main control 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 main control 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.

[0096] As a specific implementation method, it is assumed that the main control 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, parameters can be set according to the STM32F407 datasheet and the actual application scenario. For example, the capacity parameter of the ring buffer can be configured to 32 CAN frames to balance memory usage and data throughput. The mapping parameters of the PDO mapping entries can be specifically set as follows: the COB-ID of TPDO1 (transmitting 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 fields of TPDO1. The COB-ID of RPDO1 (receiving 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 fields of RPDO1. The duration parameters of the communication timeout protection mechanism can be configured as follows: the heartbeat message sending period is 200ms, and the heartbeat message timeout is 500ms, to ensure that node failures can be detected in a timely manner when communication is interrupted. These parameter values ​​will be directly written into the corresponding macro definitions or structure members of the protocol adapter layer file to form the configured protocol adapter layer file.

[0097] By employing the aforementioned technical solution, and based on the hardware configuration information of the main control chip, precisely configuring the capacity parameters of the circular buffer, the mapping parameters of the PDO mapping entries, and the duration parameters of the communication timeout protection mechanism in the protocol adaptation layer file, the efficient and stable operation of the CANopen protocol stack on a specific motor driver hardware platform can be ensured. Specifically, the precisely set circular buffer capacity effectively avoids data overflow and loss, improving communication reliability; the optimized PDO mapping entry parameters enable application layer data to be transmitted through the CANopen network in real time and accurately, improving system response speed; and the configuration of the communication timeout protection mechanism's duration parameters enhances system robustness, enabling timely detection and handling of communication faults and preventing the system from entering an uncertain state. This refined parameter configuration allows the protocol adaptation layer file to fully utilize the hardware resources of the main control chip, significantly improving the porting efficiency and operational performance of the CANopen protocol stack, thereby providing stable and reliable CANopen communication capabilities for the motor driver to be migrated.

[0098] In some embodiments, the object dictionary configuration file is configured with entries based on the target task information, including: removing entries in the object dictionary configuration file that are not related to the task represented by the target task information; and when an entry expansion request is received, expanding the entries indicated by the entry expansion request in the object dictionary configuration file to obtain the configured object dictionary configuration file.

[0099] Removing entries from the object dictionary configuration file that are irrelevant to the task represented by the target task information can be done by retaining only entries that match the current target task information during configuration, based on a predefined mapping relationship between tasks and required object dictionary entries; or by performing semantic analysis on the target task information to identify 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.

[0100] The entries indicated by the extension request in the object dictionary configuration file can be dynamically created or added to the object dictionary configuration file based on the entry information (such as index, sub-index, data type, access permissions, etc.) indicated in the request, when the executing entity receives an entry extension request from an external source (such as a development tool or host computer) during runtime or configuration phase; or, the executing entity can reserve a portion of the object dictionary space or adopt a dynamic memory allocation mechanism, and when it detects the need to support new functions or data points, add the new entry definition to the object dictionary configuration file through a programming interface or configuration tool, and update its internal structure.

[0101] This application's solution achieves close adaptation to target task information through fine-grained management of the object dictionary configuration file. Specifically, when configuring the object dictionary configuration file based on target task information, a "removal" operation is first performed. This involves intelligently identifying and removing all redundant entries in the object dictionary configuration file that are irrelevant to the current task, based on the actual task requirements represented by the target task information. This process ensures that the final 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. Furthermore, to address potential future functional expansions or special requirements, this solution introduces an "expansion" mechanism. When the execution entity receives an external request to expand entries, it can dynamically add new entries to the object dictionary configuration file according to the entry information explicitly indicated in the request. This bidirectional, dynamic configuration strategy allows the object dictionary configuration file to remain minimal to save resources while maintaining high flexibility to adapt to constantly changing application scenarios. In this way, this solution, combined with the aforementioned overall method of configuring the protocol adaptation layer file and encapsulating the driver template, jointly constructs an efficient, customizable, and easy-to-maintain CANopen protocol stack porting solution.

[0102] The following is a concrete example. Assume the target task information for the motor driver to be migrated indicates that its main function is to implement closed-loop speed control and simple status monitoring. The initial object dictionary configuration file may contain various entries such as current control parameters, advanced diagnostic information, and complex motion mode instructions. During configuration, the execution entity will automatically identify and remove entries unrelated to speed closed-loop control and status monitoring, such as current control parameters, advanced diagnostic information, and complex motion mode instructions, based on the target task information, thus obtaining a streamlined 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 corresponding entry is not included in the initial configuration, an entry expansion request can be sent via a host computer tool. This request can instruct the addition of an "overload protection threshold" entry with index 0x607F, sub-index 0x01, and data type UINT16. Upon receiving this request, the execution entity will dynamically create and add this entry to the currently configured object dictionary configuration file, thereby achieving flexible functional expansion.

[0103] Through the above technical solution, when configuring entries in the object dictionary configuration file based on target task information, irrelevant entries can be accurately eliminated according to actual task requirements, effectively reducing unnecessary memory usage and processing overhead, and improving system operating efficiency. Simultaneously, upon receiving an entry expansion request, the system can flexibly expand the required entries, greatly enhancing the adaptability and scalability of the CANopen protocol stack. This allows the motor driver to respond more efficiently and flexibly to different task requirements and functional upgrades, avoiding resource waste or functional limitations caused by a fixed object dictionary, thereby improving the practicality and robustness of the entire CANopen protocol stack porting method.

[0104] 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 does not exceed 32.

[0105] This application's solution imposes strict resource limitations on the protocol adapter layer file and object dictionary configuration file, ensuring that the entire CANopen protocol stack can run efficiently in resource-constrained embedded environments when the configured driver template is ported to the main control chip of the motor driver to be migrated. Specifically, when configuring parameters in the protocol adapter layer file based on target configuration information, the upper limits of Flash and RAM usage are considered simultaneously, guiding the parameter selection and code generation process to strictly control memory consumption while meeting functional requirements. For example, the configuration parameters of the ring buffer capacity, PDO mapping entries, and communication timeout protection mechanism duration are all optimized within the limit of no more than 3KB of Flash and 512 bytes of RAM. Similarly, when configuring entries in the object dictionary configuration file based on target task information, the number of entries is strictly limited to no more than 32. This makes the configuration process more streamlined 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 final generated configured driver template is not only fully functional but also optimal in terms of resource utilization, thus solving the challenge of efficiently running the CANopen protocol stack on resource-constrained motor drivers.

[0106] The following is a concrete example. Assume the main control chip of the motor driver to be migrated is a microcontroller with 64KB Flash and 8KB RAM. When configuring the protocol adapter layer file, to ensure its Flash usage does not exceed 3KB, 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 should be enabled, while disabling all debug log output and infrequently used error handling mechanisms. During compilation, use the GCC compiler's "-Os" (optimize code size) option and conduct rigorous code reviews of the protocol adapter layer-related source files to avoid unnecessary variables and functions. To limit RAM usage to no more than 512 bytes, the CAN message buffer in the protocol adapter layer can be designed as a statically allocated fixed-size array; for example, allocate a 128-byte buffer each for receiving and transmitting, and ensure that all status variables and flags use the smallest possible data type (such as uint8_t), avoiding the use of large structures or dynamic memory allocation. When configuring the object dictionary configuration file, depending on the target task of the motor driver (e.g., only controlling motor speed, reading motor current, and fault status), it can contain only the following entries: one RPDO mapping entry for setting the speed, one TPDO mapping entry for reading the current, one TPDO mapping entry for reading fault status, and several SDO entries for configuring motor parameters (such as maximum speed and acceleration). This ensures that the number of entries in the object dictionary is precisely controlled to within 32; for example, the actual configuration may only contain around 20 entries, thus meeting resource constraints.

[0107] Through the above technical solution, this application can significantly optimize the resource consumption 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 failure to start due to excessive resource consumption can be effectively avoided. This allows 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 widespread application of motor drivers.

[0108] In one embodiment, see Figure 4 The method after migrating the configured driver template to the main control chip of the motor driver to be migrated includes, but is not limited to, steps S401 to S404.

[0109] Step S401: After adding the configured driver template to the project of the motor driver to be migrated, determine whether the memory resources occupied by the configured driver template meet the preset memory conditions.

[0110] If the conditions are met, proceed to step S402; otherwise, return to step S203.

[0111] Step S402: Send RPDO control commands to the motor driver to be migrated.

[0112] Step S403: Determine whether the controlled motor responds to the RPDO control command.

[0113] If there is a response, proceed to step S404; if there is no response, return to step S203.

[0114] Step S404: Generate feedback information to characterize successful transplantation.

[0115] After porting the configured driver template to the main control chip of the motor driver to be migrated, this solution introduces a subsequent verification and feedback mechanism after completing the core porting operation of the CANopen protocol stack, i.e., after deploying the driver template adapted to the target hardware and tasks onto the main control chip of the motor driver. This sequence ensures that the porting effect is checked before the configured driver template is put into actual operation.

[0116] After configuring the driver template and adding it to the project of the motor driver to be migrated, it is determined whether the memory resources occupied by the configured driver template meet the preset memory conditions. This aims to verify the resource usage of the ported CANopen protocol stack on the target main control chip. The preset memory conditions may include limitations on Flash storage space, RAM running memory space, stack size, etc. This determination can be made by analyzing the memory mapping file generated during the compilation and linking stage, or by real-time monitoring at runtime through the main control chip's memory management unit (MMU) or debugging tools.

[0117] If the conditions are met, send RPDO control commands to the motor driver to be migrated. RPDO (Receive Process Data Object) is a mechanism in the CANopen protocol used for real-time data transmission, typically used to send control commands or set parameters from the CANopen master to the slave (i.e., the motor driver). If the memory conditions are met, it indicates that the protocol stack's resource usage is acceptable, and its functionality can be further verified. Sending RPDO control commands can be done, for example, through the CANopen master software or debugging tools, sending start, stop, speed setting, and other commands to the motor driver.

[0118] Determining whether the controlled motor responds to RPDO control commands aims to verify whether the ported CANopen protocol stack can correctly parse and execute received RPDO commands and drive the motor to perform corresponding actions. Response determination can be accomplished by monitoring the motor's actual operating status (e.g., whether it has started, reached the set speed, or received error feedback), or by reading the status information sent by the motor driver via TPDO (Transmit Process Data Object). If memory usage does not meet preset conditions, or the motor fails to respond correctly to RPDO commands, it indicates a problem with the current porting or configuration. In this case, the execution entity will automatically backtrack to the steps of configuring the target driver template to adjust and optimize based on the detected problems; otherwise, feedback information indicating successful porting will be generated. This can be resolved, for example, by modifying parameters in the protocol adaptation layer file, adjusting entries in the object dictionary configuration file, or selecting a more suitable driver template.

[0119] This application's solution, after the initial porting of the CANopen protocol stack, introduces an automated verification and feedback mechanism to ensure the quality and functionality of the porting. First, after integrating the configured driver template into the motor driver project, the execution entity immediately evaluates the memory resources occupied by the driver template to determine if it meets the preset memory limits. This step aims to ensure from a resource consumption perspective that the ported protocol stack does not place an excessive burden on the target main control chip, thereby avoiding system crashes or performance degradation due to memory overflow or insufficient resources. If the memory usage meets the requirements, the functionality of the protocol stack is further verified by sending RPDO control commands, i.e., checking whether the motor driver can correctly receive, parse, and execute CANopen protocol commands and drive the controlled motor to make the expected response. This functional verification is crucial to ensuring that the ported protocol stack can actually function. If a problem occurs in any verification stage (memory usage or functional response), the execution entity does not simply stop but intelligently backtracks to the protocol stack configuration stage, allowing developers or automated tools to reconfigure and optimize the target driver template based on feedback information. This closed-loop verification and feedback process effectively moves the post-porting testing and debugging process forward and automates it, significantly improving the success rate and efficiency of the porting, reducing the cost of manual intervention and repeated debugging, and ensuring that the ported CANopen protocol stack can meet the actual needs of the motor driver in terms of resources and functions.

[0120] As a specific implementation, after adding the configured driver template to the project of the motor driver to be migrated, the memory-mapped file (e.g., .map file) output by the compiler's linker can be used to analyze the Flash and RAM space occupied by the configured driver template. The preset memory conditions can be set to Flash space not exceeding 3KB and RAM space not exceeding 512 bytes. If the analysis results show that the memory usage exceeds these limits, it is determined that the preset memory conditions are not met. If the memory usage meets the conditions, an RPDO control command is sent to the motor driver to be migrated via a CANopen master simulator. For example, a "start motor" command is sent (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). At this time, it can be determined whether the motor has entered the "running" state by monitoring the TPDO status word output by the motor driver (e.g., object dictionary entry 6041h), or by detecting the motor's rotation through external sensors. If the motor does not start or the status word is not updated correctly, it is determined that the RPDO control command is not responding. Whether the memory is not up to standard or the motor is not responding, the executing entity will trigger a backtracking mechanism. For example, a prompt box will pop up in the development environment, instructing the user to return to the interface for configuring the target driver template and providing specific error information so that the user can adjust the ring buffer capacity parameter or the mapping parameter of the PDO mapping entry in the protocol adapter layer file, or modify the entry in the object dictionary configuration file.

[0121] Through the above technical solution, this application introduces an automated memory resource check and functional verification mechanism after the CANopen protocol stack is ported. This effectively avoids instability or crashes caused by excessive memory consumption of the ported protocol stack, and ensures that the ported protocol stack can correctly respond to CANopen control commands and drive the motor to work normally. When memory is found to be insufficient or the motor is unresponsive, the execution entity can promptly provide feedback and automatically backtrack to the configuration stage, thereby allowing for rapid iterative optimization of the protocol stack. This significantly reduces the time and cost of manual debugging and troubleshooting, improves the success rate and efficiency of the porting, and ensures that the ported CANopen protocol stack meets the actual needs of the motor driver in terms of both resources and functionality, thus improving the reliability and stability of the motor driver.

[0122] See Figure 5 This application also provides a CANopen protocol stack porting apparatus, which can implement the above-described CANopen protocol stack porting method. The apparatus includes:

[0123] The first module 501 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.

[0124] The second module 502 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 a device driver that supports the CANopen protocol.

[0125] The third module 503 is used to configure the target driver template based on the target configuration information and the target task information, and obtain the configured driver template adapted to the target configuration information.

[0126] The fourth module 504 is used to migrate the configured driver template to the main control chip of the motor driver to be migrated.

[0127] The specific implementation of this CANopen protocol stack porting device is basically the same as the specific implementation of the CANopen protocol stack porting method described above, and will not be repeated here.

[0128] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0129] The following reference Figure 6 To describe an electronic device 600 according to such an embodiment of the present disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0130] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may 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 storage unit 620 and processing unit 610), a display unit 640, etc.

[0131] The storage unit stores program code, which can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the above-described CANopen protocol stack porting method section of this specification according to various exemplary embodiments of this disclosure.

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

[0133] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0134] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0135] Electronic device 600 can also communicate with one or more external devices 600' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0136] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0137] The CANopen protocol stack porting method, apparatus, device, and medium provided in this application simplify the porting process of the CANopen protocol stack to different hardware platforms by selecting a target driver template based on the target configuration information and target task information of the motor driver to be migrated, configuring it, and then porting it to the main control chip of the motor driver to be migrated. Therefore, the method of selecting and configuring a target driver template based on the target configuration information and target task information of the motor driver to be migrated can efficiently generate a highly customized, lightweight configured driver template, avoiding tedious manual trimming and modification, and significantly reducing the complexity and error rate of porting. Simultaneously, by accurately matching hardware resources and application requirements, the Flash and RAM resources occupied by the generated configured driver template are minimized, thus reserving more resources for the motion control algorithm of the main control chip and ensuring the real-time performance and response speed of the motor driver's motion control.

[0138] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0139] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0140] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0141] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0142] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained 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 configured driver template is then 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 irrelevant 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 configured driver template to the main control chip of the motor driver to be migrated, the method further includes: After the configured driver template is added to the project of the motor driver to be migrated, it is determined whether the memory resources occupied by the configured 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 configured 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