EtherCAT slave station program and EEPROM (Electrically Erasable Programmable Read-Only Memory) data synchronous updating method and system, medium, program product and terminal
By implementing the synchronous update method of EtherCAT slave program and EEPROM data in the MCU controller of the EtherCAT slave device, the cumbersome and inefficient problems caused by the update of MCU and EEPROM data in the prior art are solved, and a more efficient update process and lower cost are achieved.
Patent Information
- Application Number
- CN202411635332.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-15
- Publication Date
- 2025-03-07
AI Technical Summary
In the prior art, the MCU and EEPROM data of the EtherCAT slave equipment are updated separately, resulting in a cumbersome and inefficient burning process, which limits the improvement of production efficiency and cost savings.
By implementing the synchronous update method of the EtherCAT slave program and EEPROM data in the MCU controller, it includes starting the MCU program firmware after power-up, determining whether EEPROM burned data is stored, and if there is an EEPROM initialization, and setting the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed.
This method simplifies the EEPROM data update process, integrates EEPROM updates into MCU updates, reduces operational complexity, significantly improves update efficiency, saves more than 50% of time, and reduces labor and material costs.
Smart Images

Figure CN119576380A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to a field, and in particular to a method, system, medium, program product and terminal for synchronously updating data between an EtherCAT slave program and an EEPROM. Background Art
[0002] The MCU (Microcontroller Unit) chip is responsible for interacting with the ESC (Electronic Speed Controller) chip in the EtherCAT (Ethernet for Control Automation Technology) slave device, running the set control program, and performing the corresponding control tasks. The ESC chip is responsible for processing the EtherCAT data frame and realizing the data exchange function between the master and slave MCUs. The main function of the EEPROM (Electrically ErasableProgrammable Read-Only Memory) device is to store key information in the EtherCAT slave device description file (EtherCAT Slave Information), including the ESC configuration parameters, device identification and version information, and the definition of the communication data object dictionary.
[0003] After the EtherCAT slave device is powered on, the ESC first loads the necessary configuration parameters from the EEPROM to complete its startup process. Subsequently, when the master scans the slave, it reads the description information in the EEPROM to complete the initial configuration of the slave.
[0004] During the development, mass production and upgrade phases of slave devices, developers need to burn firmware and data to the MCU and EEPROM in the EtherCAT slave. The commonly used method on the market is to use special tools to burn the program to the MCU and the data to the EEPROM. Compared with the relatively mature and convenient MCU program burning method, the burning of EEPROM data often relies on related tools such as TwinCAT or EEPROM Programmer, which is not only more cumbersome, but also time-consuming and labor-intensive. However, this solution of updating the MCU program and EEPROM data separately limits the improvement of production efficiency and cost savings. Summary of the invention
[0005] In view of the shortcomings of the prior art described above, the purpose of the present application is to provide a method, system, medium, program product and terminal for synchronously updating the EtherCAT slave program and EEPROM data, which is used to solve the problem that the solution of updating the MCU and EEPROM data separately leads to the cumbersome and inefficient burning process, thereby limiting the production efficiency.
[0006] To achieve the above-mentioned purpose and other related purposes, the first aspect of the present application provides a method for synchronously updating data between an EtherCAT slave program and an EEPROM, the method being applied to an MCU controller, the MCU controller being communicatively connected with the EEPROM and an ESC peripheral, the method comprising: starting the MCU program firmware after power-on, and determining whether the EEPROM burning data is stored in the MCU program firmware; if the EEPROM burning data is stored in the MCU program firmware, extracting an EEPROM initialization completion flag, and determining whether the EEPROM initialization is completed; if the EEPROM initialization is not completed, performing an EEPROM data initialization operation on the EEPROM through the EEPROM burning data, and setting the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed; starting the ESC peripheral, and loading data from the EEPROM to initialize the EtherCAT slave.
[0007] In some embodiments of the first aspect of the present application, the program firmware of the MCU controller includes: a boot partition and one or more firmware partitions; each firmware partition contains the EEPROM initialization completion flag and the EEPROM burning data.
[0008] In some embodiments of the first aspect of the present application, the method also includes performing a firmware update operation on the MCU, and the firmware update operation includes the following steps: starting the boot partition and erasing the firmware area to be updated; burning the updated EEPROM burning data and the MCU program into the firmware area to be updated, and setting the EEPROM initialization completion flag of the firmware area to be updated to an unfinished state; performing an EEPROM data initialization operation on the EEPROM through the updated EEPROM burning data, and setting the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed.
[0009] In some embodiments of the first aspect of the present application, the firmware partition includes a Ping partition and a Pang partition.
[0010] In some embodiments of the first aspect of the present application, performing an EEPROM data initialization operation on the EEPROM through the EEPROM burning data also includes the following steps: determining whether the ESC peripheral supports the EEPROM simulation function; if the ESC peripheral supports the EEPROM simulation function, upon receiving an EEPROM data read instruction sent by the ESC peripheral, reading the EEPROM data from the flash memory controlled by the MCU controller, and sending the EEPROM data to the ESC peripheral; and / or, upon receiving an EEPROM data write instruction sent by the ESC peripheral, writing the data sent by the ESC peripheral into the flash memory controlled by the MCU controller.
[0011] In some embodiments of the first aspect of the present application, if the EEPROM burning data is not stored in the MCU program firmware, the ESC peripheral is directly started and data is loaded from the EEPROM to initialize the EtherCAT slave.
[0012] To achieve the above-mentioned purpose and other related purposes, the second aspect of the present application provides a system for synchronously updating the data of an EtherCAT slave station program and an EEPROM, the system comprising an MCU controller, an EEPROM memory and an ESC peripheral, the interaction process of the system comprising: the MCU controller starts the MCU program firmware after power-on, and determines whether the EEPROM burning data is stored in the MCU program firmware; if the EEPROM burning data is stored in the MCU program firmware, the MCU controller extracts the EEPROM initialization completion flag and determines whether the EEPROM initialization is completed; if the EEPROM initialization has not been completed, the MCU controller performs an EEPROM data initialization operation on the EEPROM through the EEPROM burning data, and sets the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed; the MCU controller starts the ESC peripheral and loads data from the EEPROM to initialize the EtherCAT slave station.
[0013] To achieve the above-mentioned purpose and other related purposes, the third aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for synchronously updating data between the EtherCAT slave program and the EEPROM.
[0014] To achieve the above-mentioned purpose and other related purposes, the fourth aspect of the present application provides a computer program product, which includes a computer program code. When the computer program code is run on a computer, the computer implements the data synchronization update method between the EtherCAT slave program and the EEPROM.
[0015] To achieve the above-mentioned purpose and other related purposes, the fifth aspect of the present application provides an electronic terminal, including a memory, a processor and a computer program stored in the memory; the processor executes the computer program to implement the data synchronization update method between the EtherCAT slave program and the EEPROM.
[0016] As described above, the EtherCAT slave program and EEPROM data synchronization update method, system, medium, program product and terminal of the present application have the following beneficial effects: the present application adopts the technical means of synchronously updating EEPROM data by updating MCU firmware during the development, mass production and upgrade stages of EtherCAT slave devices. This process does not require the use of special tools, significantly simplifies the process of EEPROM data update, and integrates the update of EEPROM into the MCU update, thereby reducing the complexity of operation. Through this method, the update efficiency of EtherCAT slave devices has been significantly improved, and compatibility has also been enhanced. At the same time, human and material costs have been reduced. The original EEPROM update process was cumbersome and time-consuming, but by incorporating the EEPROM update into the MCU update, the number of updates that originally required two times was successfully reduced to one, saving more than 50% of time. This series of improvements effectively improves the overall update efficiency and optimizes resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 A flow chart of an embodiment of a method for synchronously updating data between an EtherCAT slave program and an EEPROM of the present application is shown.
[0018] Figure 2 The EtherCAT slave station hardware architecture in an embodiment of the method for synchronously updating the EtherCAT slave station program and EEPROM data of the present application is shown.
[0019] Figure 3 The MCU firmware partition structure in an embodiment of the method for synchronously updating the data of the EtherCAT slave program and the EEPROM of the present application is shown.
[0020] Figure 4 A flow chart showing another embodiment of the method for synchronously updating data between an EtherCAT slave program and an EEPROM of the present application is shown.
[0021] Figure 5 A structural diagram of an embodiment of a system for synchronously updating data between an EtherCAT slave program and an EEPROM of the present application is shown.
[0022] Figure 6A structural schematic diagram of an embodiment of a terminal for synchronously updating data of an EtherCAT slave program and an EEPROM of the present application is shown. DETAILED DESCRIPTION
[0023] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.
[0024] Before further explaining the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations:
[0025] <1> EtherCAT slave program: The EtherCAT slave program is an application program used for the control and communication of EtherCAT slave devices. It is responsible for processing EtherCAT protocol data frames, executing device functions, and exchanging data with the upper-level master station.
[0026] <2> MCU: An MCU (microcontroller unit) is an integrated circuit that typically includes a processor, memory, and input / output peripherals and is used for embedded control and data processing, executing control logic in EtherCAT slave devices.
[0027] <3> EEPROM: EEPROM (Electrically Erasable Programmable Read-Only Memory) is a non-volatile memory that is able to retain data after power is removed and is typically used to store device configurations and parameters.
[0028] <4> ESC peripheral: ESC peripheral (EtherCAT Slave Controller) is the hardware component responsible for processing the EtherCAT communication protocol. It is responsible for receiving and sending data frames from the master station to ensure real-time data transmission.
[0029] <5> EEPROM burning data: EEPROM burning data refers to a specific data set used to initialize the EEPROM memory. This data usually includes device configuration, parameters, and other necessary information.
[0030] <6> Boot partition: The boot partition is a specific area stored in the Flash memory, which is used to store the basic programs and data required for device startup to ensure that the device can successfully start and load the main program.
[0031] <7> MII interface: MII interface (Media Independent Interface) is an interface used to connect Ethernet physical layer devices and MAC layer devices, supporting data transmission up to 100Mbps.
[0032] <8> IIC interface: IIC interface (Inter-Integrated Circuit) is a serial communication protocol used to transmit data between a microcontroller and external devices, and is usually used to connect sensors and memory.
[0033] <9> RJ45 interface: RJ45 interface is a common Ethernet connector consisting of 8 pins, used to connect LAN devices to achieve data transmission.
[0034] <10> Physical layer chip: The physical layer chip is an integrated circuit that implements the network physical layer function and is responsible for converting digital signals into electrical signals suitable for transmission to support network communications.
[0035] <11> Network isolation transformer: A network isolation transformer is a transformer used to isolate circuits and reduce electromagnetic interference. It is often used to ensure safe isolation between devices and improve the stability of signal transmission.
[0036] <12> Slave device description file: A slave device description file is a file that describes the functions and characteristics of an EtherCAT slave device. It contains device type, communication parameters, and functional information and is usually used for device identification and configuration.
[0037] <13> bin file: bin file is a binary file format used to store program code and data, usually used in embedded systems for firmware updates or device configuration.
[0038] <14> Flash memory: Flash memory is a non-volatile memory that can retain data after power failure. It is widely used to store programs and data and is often used to store programs and configurations in embedded devices.
[0039] To facilitate understanding of the embodiments of the present application, first Figure 1 Detailed description. Figure 1 The flowchart of a method for synchronously updating data between an EtherCAT slave program and an EEPROM in an embodiment of the present application is shown. The method is applied to an MCU controller, and the MCU controller is connected to the EEPROM and the ESC peripheral communication. The method for synchronously updating data between an EtherCAT slave program and an EEPROM in this embodiment mainly includes the following steps:
[0040] Step S11: after power-on, start the MCU program firmware and determine whether the MCU program firmware stores EEPROM burning data.
[0041] In one embodiment of the present application, the program firmware of the MCU controller includes: a boot partition and one or more firmware partitions; each firmware partition contains the EEPROM initialization completion flag and the EEPROM burning data.
[0042] In one embodiment of the present application, the method proposed in the present application is applied to an MCU controller, and the MCU controller is connected to the EEPROM and the ESC peripheral communication. Among them, the chip of the MCU controller is used to communicate and interact with the chip of the ESC peripheral, run the setting program and execute the corresponding peripheral control task. The ESC chip is used to process EtherCAT data frames to realize data exchange between the master station and the slave station MCU. The EEPROM device is used to store information in the EtherCAT slave station device description (EtherCAT Slave Information) file, and the slave station device description file includes ESC configuration parameters, device identification and version information, communication data object dictionary definition, etc.
[0043] It should be noted that EtherCAT (Ethernet Industrial Control Automation Technology) is a high-performance, real-time industrial Ethernet communication protocol. The EtherCAT network adopts a master-slave architecture, in which the master station is responsible for managing the network, while the slave station performs the actual control tasks.
[0044] The hardware architecture of the EtherCAT slave is as follows: Figure 2 As shown in the figure. In the hardware architecture of the EtherCAT slave, the MCU and ESC are connected to each other through the PDI (Process Data Interfaces) interface. The role of PDI is to achieve data communication and efficient transmission of control signals between the MCU and ESC, thereby ensuring that the ESC can receive and execute control commands issued by the MCU. The ESC is connected to the EEPROM (Electrically Erasable Programmable Read-Only Memory) through the IIC (Inter-Integrated Circuit) interface. The EEPROM is responsible for storing the configuration information and parameters of the ESC to ensure that the ESC can run with the correct configuration at startup.
[0045] Furthermore, the external device connected to the ESC chip is connected to the physical layer chip (PHY) through the MII (Media Independent Interface) interface, and is further connected to the RJ45 interface through a network isolation transformer to achieve communication connection with the master station. The PHY chip is responsible for converting digital signals into analog signals suitable for transmission in the network, while providing the necessary electrical isolation and signal enhancement to ensure the integrity and reliability of the data. The RJ45 interface provides a way to physically connect to other network devices (including the master station), thereby achieving two-way transmission of data. In addition, the function of the MCU chip is not limited to controlling ESC peripherals, but is also used to manage the functions of other devices in the entire system, including but not limited to monitoring status, processing data, and coordinating tasks, to ensure the harmonious work and efficient operation of each component.
[0046] In one embodiment of the present application, when the ESC peripheral used does not support the EEPROM emulation function, the ESC peripheral needs to be connected to the EEPROM device through the IIC pin, so that the ESC can directly access the EEPROM device through the corresponding pin to store and rewrite data, and the MCU also needs to be connected to the EEPROM device through the IIC pin so that the MCU can initialize the EEPROM data. When the ESC peripheral used supports the EEPROM emulation function, the storage function of the EEPROM device can be realized directly by the flash memory controlled by the MCU; when the ESC peripheral reads and writes data in the EEPROM, the ESC peripheral sends a read and write request to the MCU through the pin connected to the MCU, so that the MCU can feed back specific data stored in the MCU's Flash memory to the MCU, so that the ESC completes the access and rewriting of the EEPROM data.
[0047] In an embodiment of the present application, the firmware partition includes a Ping partition and a Pang partition.
[0048] In this embodiment, the boot partition (BootLoader) of the firmware is a special area for storing the boot program. After the MCU is powered on, the boot program will be run first to initialize the system resources. If a firmware upgrade is required, the firmware is received and downloaded to the designated Ping area or Pang area, and then the firmware program is verified. If a firmware upgrade is not required, jump to the designated Ping area or Pang area to run the firmware program.
[0049] In one embodiment of the present application, the MCU firmware upgrade adopts a "dual-zone" configuration to form a dual-zone flash partition, specifically a "Ping-Pang" partition mode. The dual-zone flash partition supports data backup and recovery, ensuring efficient security and reliability during the firmware upgrade process. When each partition is used alternately, the firmware data can be backed up, thereby improving the stability and data integrity of the upgrade process. On the other hand, the present application also covers the case of single-zone flash partitions. In single-zone mode, there is no backup of the old firmware during the firmware upgrade process. This single-drive mode is suitable for scenarios that do not require high backup requirements, ensuring the flexibility and practicality of firmware upgrades in specific applications. By separating the dual-zone and single-zone designs, the present application can effectively adapt to different usage requirements and provide users with a variety of storage solutions.
[0050] Step S12: If the EEPROM burning data is stored in the MCU program firmware, the EEPROM initialization completion flag is extracted, and it is determined whether the EEPROM initialization is completed; if the EEPROM initialization has not been completed, the EEPROM data initialization operation is performed on the EEPROM through the EEPROM burning data, and the EEPROM initialization completion flag in the MCU program firmware is set after the initialization is completed.
[0051] In one embodiment of the present application, the setting process of the EEPROM initialization completion flag also includes: fixed position reservation. Specifically, during the development stage of the firmware, a specific memory address is reserved through a link file for storing the EEPROM initialization completion flag. During the MCU development process, a fixed memory location is predefined in the program for directly reading or updating the status of the flag. When the EEPROM initialization is completed, the MCU updates the value of this location to a predefined constant to indicate that the initialization is successful.
[0052] In one embodiment of the present application, the process of setting the EEPROM initialization completion flag includes: adding a field when adding the firmware information header to indicate the EEPROM initialization completion status. Specifically, by integrating this flag in the firmware header structure. In addition, the header structure also includes other metadata such as version information and a checksum. This ensures that the integrity and accuracy of data transmission can be verified during the firmware download process.
[0053] In one embodiment of the present application, performing an EEPROM data initialization operation on the EEPROM through the EEPROM burning data also includes the following steps: determining whether the ESC peripheral supports the EEPROM simulation function; if the ESC peripheral supports the EEPROM simulation function, upon receiving an EEPROM data read instruction sent by the ESC peripheral, reading the EEPROM data from the flash memory controlled by the MCU controller, and sending the EEPROM data to the ESC peripheral; and / or, upon receiving an EEPROM data write instruction sent by the ESC peripheral, writing the data sent by the ESC peripheral into the flash memory controlled by the MCU controller.
[0054] In one embodiment of the present application, the method also includes performing a firmware update operation on the MCU, and the firmware update operation includes the following steps: starting the boot partition and erasing the firmware area to be updated; burning the updated EEPROM burning data and the MCU program into the firmware area to be updated, and setting the EEPROM initialization completion flag of the firmware area to be updated to an unfinished state; performing an EEPROM data initialization operation on the EEPROM through the updated EEPROM burning data, and setting the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed.
[0055] In this embodiment, when the MCU firmware adopts the dual-zone (Ping-Pang) partition mode, when executing the firmware update, the boot program will erase the Ping partition or the Pang partition, and then burn the firmware to the specified partition, thereby ensuring that the EEPROM initialization completion flag after burning is in an unfinished state. Only when the MCU successfully completes the initialization of the EEPROM data will the EEPROM initialization completion flag be set to the completed state.
[0056] Furthermore, in one embodiment of the present application, the traditional upgrade method is also supported. It is understandable that when the EtherCAT device is powered on again, the MCU will determine the EEPROM initialization completion flag, thereby avoiding problems such as multiple initializations and erasing of configuration data updated by the user later. If the firmware does not contain EEPROM data, the MCU will not perform EEPROM initialization, and the EEPROM data will be updated in a traditional way.
[0057] Specifically, in the development, mass production and upgrade stages of EtherCAT slave devices in the prior art, developers need to burn programs and data to the MCU and EEPROM in the slave respectively. The common method in the market is to use tools such as TwinCAT or EEPROM Programmer to burn data to the EEPROM. However, this process is still relatively time-consuming and labor-intensive, with low efficiency, and the practice of updating the MCU program and EEPROM data separately leads to reduced production efficiency and increased costs.
[0058] In one embodiment of the present application, the burning process includes burning of a .bin file, which is a common program storage format. The MCU program can generate a .bin program file after compiling, linking, and assembling, and the .bin file contains the initial data stored in the EEPROM. The EEPROM initial data is usually preset in the slave program development stage, and can be directly generated by the EtherCAT Slave Stack Code (SSC) tool provided by the EtherCAT Technology Alliance (ETG), or added to the MCU program of the slave after converting the slave device description file (ESI XML) into an array format through other related tools. The program is compiled, linked, and assembled to generate an MCU program firmware containing the EEPROM initial data, which is burned to the flash memory controlled by the MCU. When the MCU is powered on to run the program firmware in the flash memory, the EEPROM initial data in the firmware will be written to the EEPROM one by one and verified. After the EEPROM data initialization operation is completed, the MCU will set the EEPROM initialization completion flag in the program firmware. This method not only ensures the effectiveness of the EEPROM in the firmware upgrade and data storage process, but also enhances the reliability and stability of the entire system.
[0059] Step S13: Start the ESC peripheral and load data from the EEPROM to initialize the EtherCAT slave.
[0060] In one embodiment of the present application, if the EEPROM burning data is not stored in the MCU program firmware, the ESC peripheral is directly started and data is loaded from the EEPROM to initialize the EtherCAT slave.
[0061] In the present embodiment, when the MCU initializes the EEPROM data, different initialization methods can be adopted according to whether the ESC peripheral supports the EEPROM simulation function. If the ESC peripheral does not support the EEPROM simulation function, the MCU is connected to the actual EEPROM device through the IIC peripheral pin and initialized by the IIC peripheral. On the contrary, if the ESC peripheral supports the EEPROM simulation function, the MCU can effectively respond to the ESC peripheral's read and write requests to the EEPROM through the Flash controlled by the MCU. In this case, the MCU obtains the data required by the ESC peripheral by accessing the flash memory storage space controlled by itself, and feeds these data back to the ESC peripheral. At the same time, the MCU can also update specific data in the flash memory, thereby realizing the dynamic update of the EEPROM data. This flexible initialization method ensures that the system manages the EEPROM data optimally according to the functional support.
[0062] It should be explained that the EEPROM emulation function is that the MCU simulates the behavior of the EEPROM through the Flash memory, so that the MCU can realize the data storage function similar to the EEPROM inside the MCU without the physical EEPROM device. The conditions for realizing the EEPROM emulation function include one or more of the following: the MCU chip contains a programmable Flash memory; the Flash memory supports the erase operation; the MCU is configured with a Flash control algorithm.
[0063] The implementation process of the EEPROM emulation function includes: using at least two pages in the MCU's Flash memory to manage data; exchanging and updating data between these pages; simulating the operation of the EEPROM through specific write and erase algorithms, thereby realizing various functions such as power-off protection and multiple rewrites of data. The advantage of the EEPROM emulation function is that it supports the MCU to flexibly and efficiently store and manage data without the need for a physical EEPROM device, thereby reducing costs and design complexity.
[0064] In one embodiment of the present application, the MCU used is the HPM6E00 series MCU chip of Shanghai Xianji Semiconductor, which integrates the ESC peripheral chip and has the EEPROM simulation function, so that users do not need to use actual EEPROM devices. This function has been effectively implemented in the SDK v1.7.0 development code provided by Shanghai Xianji Semiconductor. Users only need to follow the steps to generate EEPROM data and add it to the MCU program. After the program is burned, the MCU will automatically initialize the EEPROM data when it runs for the first time, without the need for additional tools to burn the EEPROM data.
[0065] Figure 4The flowchart of another embodiment of the present application is shown. The synchronous update of the EtherCAT slave program and the EEPROM data of the present application includes the following process: power on to start the MCU firmware, check whether the firmware contains EEPROM burning information, if it contains EEPROM burning information, further check the state of the EEPROM initialization completion flag in the flash memory controlled by the MCU firmware, if the initialization completion flag is in an uncompleted state, use the EEPROM burning information in the MCU firmware to initialize the content in the EEPROM, and then set the EEPROM initialization completion flag in the flash memory to a completed state. After the burning operation is completed, and if the MCU firmware does not contain EEPROM burning information, start the ESC peripheral and load the data in the EEPROM to execute the EtherCAT slave protocol stack.
[0066] Furthermore, the process of executing the EtherCAT slave station includes: initializing the protocol stack through the slave station MCU to ensure that a connection can be established with the EtherCAT network, which includes setting parameters such as the network interface and configuring related parameters. When the connection is established, the MCU receives data frames from the master station through the protocol stack, and these data frames contain commands and synchronization signals. The MCU parses these data to identify the information contained. After the parsing is completed, the slave station MCU performs corresponding operations according to the instructions, and the operations include controlling the drive, monitoring sensor data, or executing predefined tasks.
[0067] Subsequently, when the MCU has executed the command, it will feed back the execution result or status information to the master. Specifically, the protocol stack packages the relevant data into data frames and sends them to the master. In addition, in the EtherCAT system, multiple slaves usually need to be synchronized. The protocol stack is responsible for processing the reception and response of synchronization signals to ensure that the slave MCU performs operations at the correct time to maintain coordination with other devices. The protocol stack also includes error detection and status monitoring functions. If an abnormality occurs during the execution process, the MCU needs to report the fault through the protocol stack and perform necessary error recovery or retry mechanisms. The above steps form a continuous loop, and the MCU continuously receives instructions from the master, executes operations and feeds back status to ensure the real-time and reliability of communication. This series of processes ensures that the slave MCU can efficiently execute the EtherCAT communication protocol and support real-time requirements and multi-device collaboration in industrial automation.
[0068] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" represent examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.
[0069] In the embodiments of the present application, "at least one" refers to one or more, and "plurality" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can represent: a, b, c, ab, ac, bc or abc, where a, b, c can be single or multiple.
[0070] Figure 5 Schematic block diagram of the EtherCAT slave program and EEPROM data synchronization update system 500 provided in the embodiment of the present application. Figure 5 As shown, the system includes an MCU controller 501, an ESC peripheral 502 and an EEPROM memory 503, and the interaction process of the system includes:
[0071] The MCU controller 501 starts the MCU program firmware after power-on, and determines whether the MCU program firmware stores EEPROM burning data;
[0072] If the EEPROM burning data is stored in the MCU program firmware, the MCU controller 501 extracts the EEPROM initialization completion flag and determines whether the EEPROM initialization is completed; if the EEPROM initialization is not completed, the MCU controller 501 performs an EEPROM data initialization operation on the EEPROM 503 through the EEPROM burning data, and sets the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed;
[0073] The MCU controller 501 starts the ESC peripheral 502 and loads data from the EEPROM 503 to initialize the EtherCAT slave.
[0074] It should be understood that the specific process of each module executing the above corresponding steps has been described in detail in the above method embodiment, and for the sake of brevity, it will not be repeated here.
[0075] It should also be understood that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional module in each embodiment of the present application may be integrated into a processor, or may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.
[0076] Figure 6 is a schematic block diagram of an electronic terminal provided in an embodiment of the present application. Figure 6 As shown, the electronic terminal includes: at least one processor 601, a memory 602, at least one network interface 603 and a user interface 605. The various components in the device are coupled together through a bus system 604. It can be understood that the bus system 604 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 604 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 6 In the specification, various buses are labeled as bus systems.
[0077] The user interface 605 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.
[0078] It is understood that the memory 602 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), which is used as an external cache. By way of exemplary but not limiting explanation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM). The memory described in the embodiments of the present application is intended to include but is not limited to these and any other suitable categories of memory.
[0079] The memory 602 in the embodiment of the present application is used to store various categories of data to support the operation of the electronic terminal 600. Examples of these data include: any executable program for operating on the electronic terminal 600, such as an operating system 6021 and an application 6022; the operating system 6021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 6022 can include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The data synchronization update method of the EtherCAT slave program and the EEPROM provided in the embodiment of the present application can be included in the application 6022.
[0080] The method disclosed in the above embodiment of the present application can be applied to the processor 601, or implemented by the processor 601. The processor 601 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 601 or an instruction in the form of software. The above processor 601 may be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 601 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor 601 may be a microprocessor or any conventional processor, etc. In combination with the steps of the accessory optimization method provided in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
[0081] In an exemplary embodiment, the electronic terminal 600 may be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD) to execute the aforementioned method.
[0082] According to the method provided in the embodiments of the present application, the present application also provides a computer program product, which includes: computer program code, when the computer program code is run on a computer, the computer executes the method for synchronously updating the data of the EtherCAT slave program and the EEPROM in any of the embodiments shown above.
[0083] According to the method provided in the embodiments of the present application, the present application also provides a computer-readable storage medium, which stores a program code. When the program code is run on a computer, the computer executes the method for synchronizing and updating the data of the EtherCAT slave program and the EEPROM in any of the embodiments shown above.
[0084] The terms "component", "module", "system", etc. used in this specification are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program and / or a computer. By way of illustration, both applications running on a computing device and a computing device can be components. One or more components may reside in a process and / or an execution thread, and a component may be located on a computer and / or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may, for example, communicate through local and / or remote processes according to signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system and / or a network, such as the Internet interacting with other systems through signals).
[0085] Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0086] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0087] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0088] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0089] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0090] In the above embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When loading and executing computer program instructions (programs) on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. that contains one or more available media integrated. Available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., high-density digital video discs (DVDs), or semiconductor media (e.g., solid state disks (SSDs)).
[0091] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.
[0092] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
[0093] In summary, the present application provides a method, system, medium, program product and terminal for synchronously updating the data of the EtherCAT slave program and the EEPROM. By starting the MCU program firmware, it is determined whether there is EEPROM burning data; if so, the EEPROM is initialized and the completion flag is set; finally, data is loaded from the EEPROM to initialize the EtherCAT slave. The present application effectively improves the update efficiency, simplifies the EEPROM update process, enhances the compatibility of the equipment, and reduces the manpower and material costs. By integrating the EEPROM initialization with the MCU update, the update steps are reduced, more than 50% of the time is saved, the resource allocation is optimized, and the equipment utilization efficiency is improved. Therefore, the present application effectively overcomes the various shortcomings in the prior art and has a high industrial utilization value.
[0094] The above embodiments are merely illustrative of the principles and effects of the present application and are not intended to limit the present application. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present application shall still be covered by the claims of the present application.
Claims
1. A method for synchronously updating data between an EtherCAT slave program and an EEPROM, characterized in that: The method is applied to an MCU controller, the MCU controller is communicatively connected with an EEPROM and an ESC peripheral, and the method comprises: After power-on, start the MCU program firmware and determine whether the EEPROM burning data is stored in the MCU program firmware; If the EEPROM burning data is stored in the MCU program firmware, the EEPROM initialization completion flag is extracted, and it is determined whether the EEPROM initialization is completed; if the EEPROM initialization is not completed, the EEPROM data initialization operation is performed on the EEPROM through the EEPROM burning data, and the EEPROM initialization completion flag in the MCU program firmware is set after the initialization is completed; Start the ESC peripheral and load data from the EEPROM to initialize the EtherCAT slave.
2. The method for synchronously updating data of the EtherCAT slave program and the EEPROM according to claim 1, characterized in that: The program firmware of the MCU controller includes: a boot partition and one or more firmware partitions; each firmware partition contains the EEPROM initialization completion mark and the EEPROM burning data.
3. The method for synchronously updating the EtherCAT slave program and the EEPROM data according to claim 2, wherein the method further comprises executing a firmware update operation on the MCU, wherein the firmware update operation comprises the following steps: Starting the boot partition and erasing the firmware area to be updated; Burn the updated EEPROM burning data and MCU program into the firmware area to be updated, and set the EEPROM initialization completion flag of the firmware area to be updated to an unfinished state; An EEPROM data initialization operation is performed on the EEPROM using the updated EEPROM burning data, and an EEPROM initialization completion flag in the MCU program firmware is set after the initialization is completed.
4. The method for synchronously updating the EtherCAT slave program and EEPROM data according to claim 2, wherein the firmware partition comprises a Ping partition and a Pang partition.
5. The method for synchronously updating data of an EtherCAT slave program and an EEPROM according to claim 1, characterized in that: Performing an EEPROM data initialization operation on the EEPROM by means of the EEPROM burning data also includes the following steps: Determine whether the ESC peripheral supports the EEPROM emulation function; if the ESC peripheral supports the EEPROM emulation function, upon receiving an EEPROM data read instruction sent by the ESC peripheral, read the EEPROM data from the flash memory controlled by the MCU controller, and send the EEPROM data to the ESC peripheral; And / or, upon receiving an EEPROM data write instruction sent by the ESC peripheral, writing the data sent by the ESC peripheral into a flash memory controlled by the MCU controller.
6. The method for synchronously updating the EtherCAT slave program and the EEPROM data according to claim 1, characterized in that: If the EEPROM burning data is not stored in the MCU program firmware, the ESC peripheral is started directly and the data is loaded from the EEPROM to initialize the EtherCAT slave.
7. A system for synchronously updating EtherCAT slave program and EEPROM data, characterized in that: The system includes an MCU controller, an EEPROM memory and an ESC peripheral, and the interaction process of the system includes: The MCU controller starts the MCU program firmware after power-on, and determines whether the EEPROM burning data is stored in the MCU program firmware; If the EEPROM burning data is stored in the MCU program firmware, the MCU controller extracts the EEPROM initialization completion flag and determines whether the EEPROM initialization is completed; if the EEPROM initialization is not completed, the MCU controller performs an EEPROM data initialization operation on the EEPROM through the EEPROM burning data, and sets the EEPROM initialization completion flag in the MCU program firmware after the initialization is completed; The MCU controller starts the ESC peripherals and loads data from the EEPROM to initialize the EtherCAT slave.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for synchronously updating data between the EtherCAT slave program and the EEPROM as claimed in any one of claims 1 to 6 is implemented.
9. A computer program product, characterized in that The computer program product includes computer program codes, and when the computer program codes are executed on a computer, the computer implements the method for synchronously updating the EtherCAT slave program and the EEPROM data according to any one of claims 1 to 6.
10. An electronic terminal comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the method for synchronously updating data between the EtherCAT slave program and the EEPROM as claimed in any one of claims 1 to 6.