WO2021125393A1

WO2021125393A1 - Microcontroller unit-based driver recognition device and method

Info

Publication number: WO2021125393A1
Application number: PCT/KR2019/018087
Authority: WO
Inventors: 김병수; 하인용; 기경완; 조한철
Original assignee: (주)로보티즈
Priority date: 2019-12-19
Filing date: 2019-12-19
Publication date: 2021-06-24

Abstract

The present invention relates to a microcontroller unit-based driver recognition device and method. According to one embodiment of the present invention, a microcontroller unit-based driver recognition device and method manage and distribute, outside a firmware, a driver code for a slave device through a script language, thereby being capable of supporting plug and play of the slave device during runtime.

Description

Microcontroller unit-based driver recognition device and method

The present invention relates to an apparatus and method for recognizing a driver, and more particularly, to a microcontroller unit-based driver recognition that supports plug and play of a slave device by recognizing a driver of a slave device during runtime on a non-OS microcontroller unit-based basis Apparatus and method.

The 4th Industrial Revolution uses communication to connect things to a network by combining intelligent information technology, including the Internet of Things, with existing industries and services or combining with new technologies in various fields such as robotics. There are a variety of things from In addition, modularization plays an important role in order for things to be connected to each other in a network, and if it can support Plug and Play, which can be used immediately after being connected, user convenience can be further increased. In this sense, drivers supported by each vendor of the OS (Operation System) enhance user convenience. Plug-and-play support is possible if only the corresponding version of the driver is installed on both sides of the operating system driver.

However, since the OS and the non-OS have very different environments and conditions, the plug-and-play support method in the OS environment cannot be applied to the non-OS in the same way, and there are constraints. In particular, runtime modification is not possible due to the characteristics of the microcontroller unit's firmware. As an alternative means, data addresses of various devices are mapped and used. However, in the case of address mapping, firmware needs to be modified to change the API (Application Programming Interface) to be executed, and additional memory consumption is required. In addition, it is difficult to define various device functions because it can be controlled only with defined data.

On the other hand, the technology using the DYNAMIXEL protocol among the plug-and-play methods based on UART (Universal Asynchronous Receiver/Transmitter) in the existing microcontroller unit is limited by the design of the protocol, and the end user It was possible to use it only if the registered data address and data size were accurately recognized. Therefore, it was necessary to unify the addresses of the data of the devices naturally, and there was a disadvantage that the degree of freedom was decreased and the end user still had to know this information. The fact that both parties need to know the same information is the same as the OS driver, but Dynamixel protocol must know the raw (RAW) information, and the API parameters must be modified accordingly.

Background art of the present invention is disclosed in Korean Patent Registration No. 10-1343176.

The present invention provides an apparatus and method for recognizing a microcontroller unit-based driver that supports plug-and-play of various devices on a non-OS.

The present invention provides a microcontroller unit-based driver recognition device and method for defining a driver function using a script language and executing the driver function through a script executor.

The present invention provides a microcontroller unit-based driver recognition apparatus and method capable of receiving and defining driver information of various devices at runtime without modification of the microcontroller unit's firmware.

According to one aspect of the present invention, there is provided an apparatus for recognizing a driver based on a microcontroller unit.

In the microcontroller unit-based driver recognition apparatus according to an embodiment of the present invention, a setting unit for sharing a driver function generated through a script language, a collection unit for collecting driver codes of a slave device during runtime, and the slave device It may include a control unit to communicate with and control.

According to another aspect of the present invention, a method for recognizing a driver based on a microcontroller unit and a computer-readable recording medium in which a computer program executing the same is recorded.

A method for recognizing a microcontroller unit-based driver according to an embodiment of the present invention and a recording medium storing a computer program executing the same according to an embodiment of the present invention comprises the steps of: searching for a slave device; The method may include confirming whether it is the case, requesting the driver code of the new slave device using a script language, and registering the slave device during runtime using the driver code.

According to an embodiment of the present invention, an apparatus and method for recognizing a driver based on a microcontroller unit may receive driver information of various devices at runtime using a driver function predefined through a script language.

According to an embodiment of the present invention, the microcontroller unit-based driver recognition apparatus and method uses a method similar to the OS driver on a non-OS, so that it is more familiar to OS users and thus it is possible to minimize the acquisition of additional knowledge required for development. .

According to an embodiment of the present invention, an apparatus and method for recognizing a microcontroller unit-based driver is based on a plug-and-play technology using a low-cost microcontroller unit-based UART interface, and has price competitiveness compared to expensive equipment.

According to an embodiment of the present invention, the apparatus and method for recognizing a driver based on a microcontroller unit can manage/distribute a driver code for a device outside the firmware, thereby increasing the efficiency of maintenance/maintenance/management.

1 to 3 are diagrams for explaining a microcontroller unit (MCU)-based driver recognition device according to an embodiment of the present invention.

4 and 5 are diagrams illustrating a microcontroller unit-based driver recognition method according to an embodiment of the present invention.

Since the present invention can have various changes and can have various embodiments, specific embodiments are illustrated in the drawings and will be described in detail through detailed description. However, this is not intended to limit the present invention to specific embodiments, and it should be understood to include all modifications, equivalents and substitutes included in the spirit and scope of the present invention. In describing the present invention, if it is determined that a detailed description of a related known technology may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. Also, as used herein and in the claims, the terms "a" and "a" are to be construed to mean "one or more" in general, unless stated otherwise.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings, and in the description with reference to the accompanying drawings, the same or corresponding components are given the same reference numerals, and the overlapping description thereof will be omitted. do it with

Referring to FIG. 1 , when a slave device is plugged and played in a non-OS-based microcontroller unit (MCU) environment, the microcontroller unit allocates information to a driver area. Non-OS-based microcontroller units are different from OS-based plug-and-play support methods. Since runtime modification is impossible due to the nature of the firmware of the microcontroller unit, it is sometimes used as an address mapping method. However, the microcontroller unit (MCU)-based driver recognition apparatus 10 does not map data addresses of various devices. Instead, the microcontroller unit (MCU)-based driver recognition device 10 adds a driver of the same API so that the end user can define the driver. Since the microcontroller unit (MCU)-based driver recognition device 10 does not map data addresses, firmware does not need to be modified, and memory waste required for mapping is reduced.

Since the microcontroller unit cannot be modified during runtime, the microcontroller unit-based driver recognition apparatus 10 supports plug-and-play of the slave device using a script language. The script language does not depend on the hardware or device being executed, and defines driver functions as strings. Since the microcontroller unit-based driver recognition device 10 uses a script language, it can execute driver functions through a script executor.

The microcontroller unit-based driver recognition device 10 declares a function in the microcontroller unit (MCU) in advance, and defines and uses the function in the host as well. In other words, the functions defined in the host can be used in the microcontroller unit.

When a slave device is added, the microcontroller unit transmits the driver code of the added slave device to the host. The host analyzes the transmitted driver code through the script executor and drives the added slave device.

The microcontroller unit-based driver recognition apparatus 10 may manage/distribute the driver code for the slave device outside the firmware, thereby increasing the efficiency of maintenance/maintenance/management.

Since the microcontroller unit-based driver recognition device 10 uses a script language and communication, it can be implemented in various ways if another script language or a communication system capable of performing the same role is established. In addition, the communication protocol can be used by adopting various protocols such as MODBUS and custom protocols other than the Dynamixel protocol used in the present invention.

Referring to FIG. 2 , the microcontroller unit-based driver recognition apparatus 10 includes a setting unit 100 , a collection unit 200 , and a control unit 300 .

The setting unit 100 shares a driver function (API) through a script language. The setting unit 100 allows the microcontroller unit and the host to use the driver function together.

The collection unit 200 collects the driver code and information of the slave device by calling the driver function to the microcontroller unit.

The controller 300 communicates with the slave device and controls the slave device using the collected driver code and information of the slave device. The control unit 300 supports to call a driver function from user code created by the user. For example, when a device driver function is called from the user code, the controller 300 executes a corresponding driver script using the driver code of the registered device. For example, the controller 300 may control each slave device by executing a driver script.

Referring to FIG. 3 , the microcontroller unit-based driver recognition device 10 declares a slave driver function to the microcontroller unit, and defines the host to use the declared slave driver function. The microcontroller unit-based driver recognition apparatus 10 calls a driver function when the slave device is plugged in. The microcontroller unit-based driver recognition apparatus 10 calls a driver function and receives a slave device code as a parameter. The microcontroller unit-based driver recognition apparatus 10 analyzes the slave device code through a script interpreter and drives (plays) the slave device.

The microcontroller unit-based driver recognition apparatus 10 updates slave device information during runtime to support plug and play of the slave device.

3, for example, when the host_slave_read, host_slave_write, and imu_read_data functions are defined in the host, and the microcontroller unit calls the imu_read_data function, driver information of the slave device can be received. That is, the microcontroller unit and the host have a driver for reading IMU data, and the driver function is defined as imu_read_data. At this time, the microcontroller unit transmits the data address according to the slave device as a parameter while calling the host_slave_read function, and the host receives the definition of the imu_read_data function as a string through communication with the microcontroller unit. The host can receive the slave device code by using the host_slave_read defined by the host and the parameter information transmitted from the microcontroller unit. That is, the host acquires the slave device code (IMU data) by calling the imu_read_data function even if there is no RAW information. The microcontroller unit-based driver recognition apparatus 10 supports plug-and-play of a slave device even during runtime by receiving only desired IMU data by processing a driver function using a script language.

4 and 5 are diagrams illustrating a microcontroller unit-based driver recognition method according to an embodiment of the present invention. Each process described below is a process performed by each functional unit constituting a microcontroller unit-based driver recognition device, but for the sake of concise and clear description of the present invention, the subject of each step is collectively referred to as a microcontroller unit-based driver recognition device.

Referring to FIG. 4 , in step S410 , the microcontroller unit-based driver recognition apparatus 10 searches for a slave device by performing a plug and play operation. In step S420, the microcontroller unit-based driver recognition apparatus 10 proceeds to step S430 when a new slave device is detected, and proceeds to step S460 if there is no new slave device.

In step S430, the microcontroller unit-based driver recognition apparatus 10 receives the driver code of the slave device. At this time, the microcontroller unit-based driver recognition apparatus 10 receives the driver code of the slave device by calling the driver function generated in the script language. The microcontroller unit-based driver recognition apparatus 10 calls a driver function to receive a driver code of a slave device will be described in detail later with reference to FIG. 5 .

In step S440, when the received response packet is a driver code, the microcontroller unit-based driver recognition apparatus 10 uses the driver code to register the slave device during runtime.

In step S450, the microcontroller unit-based driver recognition apparatus 10 registers the slave device and performs step S410 again. For example, the microcontroller unit-based driver recognition device 10 may support the plug-and-play function by repeatedly executing or scheduling the PnP executor. The microcontroller unit-based driver recognition apparatus 10 may communicate with the slave device for which device registration has been completed, and may control the slave device.

If there is no newly added slave device in step S420 and there is a removed slave device, proceed to step S470 to delete the deleted slave device code from the host and release the slave device. For example, the microcontroller unit-based driver recognition apparatus 10 may identify the removed slave through a ping command to the slave device.

In step S400, the microcontroller unit-based driver recognition apparatus 10 calls a driver function of the slave device and receives the driver code of the slave device as a parameter.

In step S400, the host executes the user code. The user code may be an application written by a user. For example, when a device driver function is called from the user code, the microcontroller unit-based driver recognition device 10 executes the corresponding driver script using the driver code of the registered device.

In step S4001, the microcontroller unit-based driver recognition device 10 calls a driver function according to the request of the user code.

In step S4003, the microcontroller unit-based driver recognition apparatus 10 checks whether the slave device is registered using the called driver function, and if not registered, moves to step S4008 to process an error. For example, in the error processing, the driver recognition device 10 notifies the user of the error to the user who wrote the user code.

In step S4005, the microcontroller unit-based driver recognition device 10 executes the driver script of the registered driver.

In step S4007, the microcontroller unit-based driver recognition device 10 ends the execution of the driver script.

Referring to FIG. 5 , in step S4301 , the slave device waits to receive a command from the microcontroller unit-based driver recognition apparatus 10 .

In step S4302, the microcontroller unit-based driver recognition device 10 calls the driver function generated in the script language to proceed to step S4303. If the microcontroller unit-based driver recognition device 10 does not call the driver function, step S4305 is performed.

In step S4303, the microcontroller unit-based driver recognition apparatus 10 generates and transmits the driver code of the slave device through the driver function as a response packet, and returns to step S4301 to wait for command reception.

In step S4305, the microcontroller unit-based driver recognition device 10 processes the command received from the host, generates and transmits a response packet. For example, the slave device may be an actuator. When the actuator receives a write command such as a specific speed output request from the host, it executes the command and responds with the result as a packet. In addition, when the actuator receives a read command such as a request to confirm the current position, the actuator responds with a value for the current position as a packet.

In step S4304, the microcontroller unit-based driver recognition apparatus 10 transmits the response packet received from the slave device to the host.

The above-described microcontroller unit-based driver recognition method may be implemented as a computer-readable code on a computer-readable medium. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disk, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer-equipped hard disk). can The computer program recorded in the computer-readable recording medium may be transmitted to another computing device through a network, such as the Internet, and installed in the other computing device, thereby being used in the other computing device.

In the above, even though all the components constituting the embodiment of the present invention are described as being combined or operated in combination, the present invention is not necessarily limited to this embodiment. That is, within the scope of the object of the present invention, all the components may operate by selectively combining one or more.

Although acts are shown in a specific order in the drawings, it should not be understood that the acts must be performed in the specific order or sequential order shown, or that all shown acts must be performed to obtain a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of the various components in the embodiments described above should not be construed as necessarily requiring such separation, and the program components and systems described may generally be integrated together into a single software product or packaged into multiple software products. It should be understood that there is

So far, the present invention has been looked at focusing on the embodiments thereof. Those of ordinary skill in the art to which the present invention pertains will understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Modes for carrying out the invention have been described together in the above best mode for carrying out the invention.

The present invention relates to an apparatus and method for recognizing a driver based on a microcontroller unit, and supports a plug-and-flag function of a device using a low-cost microcontroller unit, and maintains/repairs/management of the device by being able to manage/distribute the device outside the firmware It has industrial applicability because it increases the efficiency of

Claims

In the microcontroller unit-based driver recognition device,

a setting unit that shares the driver function created through the script language;

a collection unit that collects the driver code of the slave device during runtime; and

and a control unit for communicating and controlling the slave device.
The method of claim 1,

A microcontroller unit-based driver recognition device supporting plug and play of the slave device.
The method of claim 1,

The control unit calls the driver code of the slave device using a driver function,

A microcontroller unit-based driver recognition device capable of controlling each slave device using the driver code.
In the microcontroller unit-based driver recognition method,

searching for a slave device;

checking whether the slave device is new;

requesting a driver code of the new slave device using a script language; and

and registering a slave device during runtime using the driver code.
5. The method of claim 4,

A microcontroller unit-based driver recognition method supporting plug and play of the slave device.
5. The method of claim 4,

A microcontroller unit-based driver recognition device capable of controlling each slave device using the driver code.
A computer program recorded in a computer-readable recording medium executing any one of the microcontroller unit-based driver recognition methods according to claim 4 to claim 6 .