KR20110108143A - Embeded system based on script programming language and operation method thereof - Google Patents

Abstract

An embedded system is disclosed. The embedded system uses a system programming language to define a plurality of low level device resources and provides a hardware related application module and a script programming language to provide a handling service to the plurality of low level device resources. And an embedded application module for a user interworking with and controlling the plurality of low level device resources.

Description

Embedded system based on script programming language and its driving method {EMBEDED SYSTEM BASED ON SCRIPT PROGRAMMING LANGUAGE AND OPERATION METHOD THEREOF}

The present invention relates to an embedded system related technology, and more particularly, includes both a script programming language based application and a system programming language based application. The present invention relates to an embedded system and a driving method thereof capable of smoothing communication between processes by providing an interworking interface therebetween.

Today's embedded systems are becoming increasingly complex in hardware and software. This is because the form of the embedded system is changing to the form of a complex terminal covering a variety of services. As a result, the use of various libraries and components and the interaction between components are increasing.

In terms of embedded system development, most embedded applications are based on system programming languages (eg, C / C ++ languages). Although such a system programming language is suitable for developing hardware-related applications, it is not suitable for developing a user application having a simple software characteristic that accommodates current complex terminal requirements.

For example, developing a user application using a system programming language requires a lot of development manpower, time and cost, and also has a high possibility of a bug due to the complexity of the result.

In addition, in case of C / C ++, after compiling the source and compiling the result, the generated executable files and library files are loaded back into the embedded system and the result is checked to check the result. It takes time for the preparation process to load in, which requires time outside of development.

In the development process of most embedded systems, source code is compiled by using BSP provided by CPU vendor, which is a major component, or owned OS package for embedded system, and the corresponding platform cross compiler. It is loaded into an embedded system to test its operation and results.

In other words, all processes necessary for embedded system development belong to the corresponding BSP or OS package, so that developments have to have separate equipments for general and development tasks or purchase virtual OS emulators (eg, vmware) separately.

As a result, developers who are not working in the embedded field or newly-developed society have difficulty in setting up or preparing a system development environment before starting to develop embedded systems, and have separate training on the relevant BSP and development environment. It must be received.

Accordingly, the technical problem to be achieved by the present invention is to provide an embedded system and a method of driving the same, which enable powerful portability, rapid application, verification, and debugging in the process of developing an embedded system. It provides an embedded system that utilizes the system programming language, requires a script programming language in the user's embedded application, and provides an interworking interface between these applications and its driving method.

The embedded system for solving the technical problem may include a hardware related application and a user embedded application. The hardware related application module may use a system programming language to define a plurality of low level device resources and provide a handling service for the plurality of low level device resources. The embedded application module for the user may use the script programming language to interwork with the hardware related application module and control the plurality of low level device resources.

The embedded application module for a user may include a script interpreter and a binding interface. The script interpreter may execute source code corresponding to a plurality of script language based modules. The binding interface may bind the hardware related application module and the user embedded application module. The plurality of script language based modules may include a script language based core module and a plurality of script language based extension modules.

The binding interface may enable the hardware related application module to use data and functions of the user embedded application module and enable the user embedded application module to use an application module based on a programming language of the hardware related application module. have. The programming language based application module may include libraries linked to the embedded application module for the user based on a remote procedure call (RPC).

The script programming language may be LUA and the system programming language may be C or C ++.

The embedded system may register new firmware by storing source code received based on a predetermined communication protocol in a memory of the embedded system and executing the stored source code, and update received based on a predetermined communication protocol. Firmware may be updated by storing a source code portion in a memory of the embedded system and executing the stored source code.

The method for driving an embedded system for solving the technical problem may include using a system programming language to define a plurality of low level device resources and providing a handling service to the plurality of low level device resources, and using a script programming language. And controlling the plurality of low level device resources in association with providing the handling service to the plurality of low level device resources.

Controlling the plurality of low level device resources using the script programming language comprises executing source code corresponding to a plurality of script language based modules and using the system programming language. Binding a step of providing resources with a handling service and controlling the plurality of low level device resources using the script programming language.

The step of binding enables the system programming language-based module to use the data and functions of the script programming language-based module, and to enable the script programming language-based module to use the system programming language-based module. It may include. The system programming language based application module may include libraries linked to the script programming language based module on a remote procedure call (RPC) basis.

The embedded system driving method may further include registering new firmware by storing the received source code in a memory of the embedded system based on a predetermined communication protocol and executing the stored source code. The embedded system driving method may further include updating firmware by storing a portion of a source code to be received based on a predetermined communication protocol in a memory of the embedded system and executing the stored source code.

The embedded system driving method according to an embodiment of the present invention may be implemented by executing a computer program for executing the booting method of the computer system stored in a computer-readable recording medium.

As described above, since the embedded system and its driving method utilize a script programming language, in terms of the development of the embedded system, development costs are reduced, development period is shortened, bugs are reduced during development, and debugging efficiency is increased. In terms of the management of the embedded system, there is an effect that can reduce the firmware registration and update time and reduce the error.

1 is a block diagram of an embedded system according to an embodiment of the present invention.
2 is a view for comparing the C interworking interface and the LUA PRC interworking interface.
3 is a flowchart illustrating a conventional embedded system development process.
4 is a flowchart illustrating a process of developing an embedded system according to an exemplary embodiment of the present invention.
5 is a flowchart illustrating a firmware update process of a conventional embedded system.
6 is a flowchart illustrating a firmware update process of an embedded system according to an exemplary embodiment of the present invention.
7 illustrates the speed of multiple system programming languages and multiple script programming languages.

Specific structural and functional descriptions of embodiments according to the concepts of the present invention disclosed in this specification or application are merely illustrative for the purpose of illustrating embodiments in accordance with the concepts of the present invention, The examples may be embodied in various forms and should not be construed as limited to the embodiments set forth herein or in the application.

Embodiments in accordance with the concepts of the present invention can make various changes and have various forms, so that specific embodiments are illustrated in the drawings and described in detail in this specification or application. However, this is not intended to limit the embodiments in accordance with the concept of the present invention to a particular disclosed form, it should be understood to include all changes, equivalents, and substitutes included in the spirit and scope of the present invention.

When a component is said to be "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that another component may exist in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between. Other expressions describing the relationship between components, such as "between" and "immediately between," or "neighboring to," and "directly neighboring to" should be interpreted as well.

Terms such as first and / or second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another, for example, without departing from the scope of rights in accordance with the inventive concept, and the first component may be called a second component and similarly The second component may also be referred to as the first component.

When a component is said to be "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that another component may exist in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. Like reference numerals in the drawings denote like elements.

1 is a block diagram of an embedded system 100 in accordance with an embodiment of the present invention. The embedded system 100 utilizes a system programming language in hardware-related applications while using a script programming language that is relatively simple to develop in an embedded application for non-hardware related users. That is, the embedded system 100 is configured in such a way that an application based on a script programming language and an application based on a system programming language coexist, and the inter-process communication can be easily performed by providing an interworking interface between the applications.

Here, the embedded system may be one of an Internet phone, a video phone, a home gateway, an IPTV set-top box, a mobile phone, a navigation, a PMP, and an MP3 player. However, the scope of the present invention is not limited thereto. In the present specification, the embedded system 100 using LUA in the script programming language and the C language in the system programming language will be described as an embodiment of the present invention. However, the scope of the present invention is not limited thereto.

Referring to FIG. 1, the embedded system 100 may include a user embedded application module 110 and a hardware related application module 120.

The hardware related application module 120 defines a plurality of low level device resources included in the embedded system 100 and handles the plurality of low level device resources using a system programming language (eg, C language). Can be provided. Although not shown in FIG. 1, the plurality of low level device resources may include a central processing unit, a memory, a graphics card, a sound card, a speaker, a microphone, and the like. However, the scope of the present invention is not limited thereto.

The embedded application module 110 for the user may use a script programming language (eg, LUA) to interwork with the hardware related application module 120 and control the plurality of low level device resources.

The embedded system 100 may register new firmware by storing the received source code in a memory (not shown) of the embedded system based on a predetermined communication protocol and executing the stored source code. Here, the predetermined communication protocol may include a communication protocol such as FTP, HTTP, SAMBA. However, the scope of the present invention is not limited thereto.

The embedded system 100 may update the firmware by storing a portion of source code to be received based on the predetermined communication protocol in a memory of the embedded system and executing the stored source code.

The user embedded application module 110 includes a Lua core module 112, a Lua extension module 114, a Lua interpreter 116, and a binding interface 118.

The lua interpreter 116 may execute source code for driving a plurality of lua based modules including the lua core module 112 and the lua extension module 114. The Lua extension module 114 may include a Lua socket module, a Lua SSL module, a Lua HTTP module, a Lua SNMP module, a Lua XML module, and the like. However, the scope of the present invention is not limited thereto.

The binding interface 118 may bind the hardware related application module 120 and the user embedded application module 110. Here, the binding means that the data and functions of the embedded application module 110 for the user can be used in the hardware-related application module 120 and the hardware-related application module (in the embedded application module 110 for the user) 120 means that the application module based on the programming language can be used.

However, as illustrated in FIG. 1, the user embedded application module 110 and the hardware related application module 120 may directly access each other without going through the binding interface 118.

The hardware related application module 120 may include a C application module 122, a C language-based Linux kernel 124, a system call module 126, a network protocol module 128, and a device driver module 130. It may include.

2 is a view for comparing the C interworking interface and the LUA PRC interworking interface in the embedded system 100 according to an embodiment of the present invention.

Referring to FIG. 2, in the general C interworking interface method, each of the C-based core, the SNMP agent, and the web server may directly access the C application module. As illustrated in FIG. 2, the C application module may include a library corresponding to a VoIP application, a voice application, and a DSP interface.

However, in the Lua Remote Procedure Call (RPC) interface scheme in the embedded system 100 according to an embodiment of the present invention, a Lua-based core, an SNMP agent, and a web server are based on RPC, that is, a C application module. It can be seen that the library corresponding to the VoIP application, the voice application, and the DSP interface can be accessed through the internal RPC interface included in 122.

Here, RPC refers to a protocol used to request details of a network and to request a service, function, or subroutine call from another process on the network in a specific process.

Meanwhile, each of the components of the embedded system 100 according to the embodiment of the present invention may be implemented by software, hardware, or a combination of software and hardware for carrying out the technical spirit of the present invention.

In addition, each component of the embedded system 100 or a combination thereof according to an embodiment of the present invention may be mounted using various types of packages. For example, each component of the embedded system 100 or a combination thereof according to an embodiment of the present invention may be a package on package (PoP), ball grid arrays (BGAs), chip scale packages (CSPs), plastic leaded chip carriers. (PLCC), Plastic Dual In-Line Package (PDIP), Die in Waffle Pack, Die in Wafer Form, Chip On Board (COB), Ceramic Dual In-Line Package (CERDIP), Plastic Metric Quad Flat Pack (MQFP), Thin Quad Flatpack (TQFP), Small Outline (SOIC), Shrink Small Outline Package (SSOP), Thin Small Outline (TSOP), Thin Quad Flatpack (TQFP), System In Package (SIP), Multi Chip Package (MCP), Wafer It can be implemented using packages such as -level Fabricated Package (WFP), Wafer-Level Processed Stack Package (WSP), and the like.

3 and 4, the difference between the conventional embedded system development process and the embedded system 100 development process according to an embodiment of the present invention will be described.

3 is a flowchart illustrating a conventional embedded system development process. Referring to FIG. 3, in the embedded system development process based on a conventional system programming language, a step of creating source code (S30), a step of compiling all or a part of source code (S31), and generating a firmware loadable to an embedded system ( S32), loading the generated firmware into the embedded system (S33), and booting the embedded system loaded with the firmware to check and debug the operation of the loaded firmware (S34), wherein the steps S30 to S34 It can be seen that is performed repeatedly.

Among the processes described above, the overall source code creation step S30 is similar to the embedded system 100 source code creation step according to the embodiment of the present invention. However, subsequent steps S31 to S34 are different from the steps for developing the embedded system 100 according to the embodiment of the present invention.

For example, an internet router and an internet phone terminal, the source code compilation step (S31) is different depending on the function of the terminal, but takes about 6 to 8 minutes, and the firmware generation step (S32) is about 2 minutes It takes time, and the firmware loading step (S33) takes about 1 minute. That is, it takes about 10 minutes to modify the source code and to operate the output of the source code. This is true even if a line is changed or several files are changed in writing source code.

However, the development process of the embedded system 100 according to the embodiment of the present invention based on the script programming language is simpler than the conventional embedded system development process, and the time required is shorter. 4 is a flowchart illustrating a development process of an embedded system 100 according to an exemplary embodiment of the present invention.

Referring to FIG. 4, in the process of developing an embedded system 100 according to an embodiment of the present invention, a process of creating source code (S40), loading source code into the embedded system 100 (S41), and loaded Immediately executing the source code, and checking and debugging the result (S42).

The development process of the embedded system 100 according to an embodiment of the present invention is different from the conventional embedded system development process described with reference to FIG. 3 without requiring the step of compiling the source code to generate the firmware. It can be seen that there is no need to reboot the embedded system 100 to reflect the firmware. This is because the source code written based on the script programming language and loaded into the embedded system 100 may be directly executed by the LUA interpreter 116 without any special process.

4 and 5, the difference between the firmware management method of the conventional embedded system and the firmware management method of the embedded system 100 according to the embodiment of the present invention will be described.

5 is a flowchart illustrating a firmware update process of a conventional embedded system. Even if some firmware needs to be changed on an existing embedded system, there is a problem that requires updating the entire firmware. Hereinafter, the process will be described in detail with reference to FIG. 5.

 If a firmware update is required, the service provider or embedded system petitioner registers the new firmware on the terminal version management server and registers the firmware on the file distribution server (S50). When an upgrade event occurs (S51), the embedded system checks whether new firmware exists in the terminal version management server or file distribution server (S52).

Here, the upgrade event may be a method in which the embedded system approaches the terminal version server at regular intervals to check for new firmware, or the terminal version management server may order the embedded system to check for new firmware. Multiple embedded systems are connected to one terminal version server or the like. Therefore, the new upgrade event method generally uses the former, and the latter is mainly used for the action on the problem-producing terminal.

If the new firmware does not exist in the terminal version management server or the like, the embedded system performs a normal operation (S53). However, when it is confirmed that the new firmware exists in the terminal version management server, the embedded system downloads the corresponding firmware from the terminal version management server, etc. (S54), and performs integrity check of the downloaded firmware (S55).

Recently, since the user interface of the embedded system is complicated and various convenience functions are mounted on the embedded system, the number of embedded systems that are in charge of the capacity of the firmware loaded on the embedded system and the terminal version server is increasing dramatically. As a result, the time it takes for service providers to upgrade the firmware of the entire embedded system is also increasing dramatically.

For example, if it is necessary to upgrade the firmware of about 5 million Internet phones currently distributed in Korea, the time taken to complete the upgrade of the network bands and the Internet phone terminals of all subscribers is difficult to measure.

In addition, if the firmware downloaded from the terminal version management server or the like is not the same as the firmware registered in the terminal version management server, etc., the downloaded firmware must be discarded.

If there is no problem with the downloaded firmware, the embedded system stores the firmware in memory (S56) and reboots to operate as new firmware (S57). Usually, the time required to download and install new firmware through these steps is about 4-6 minutes per embedded system. In the meantime, if an abnormal event such as a power failure or network service failure occurs, the embedded system returns to the previous firmware. In case of failing to return to the previous firmware, the user should repair the embedded system through the after service.

6 is a flowchart illustrating a firmware update process of an embedded system according to an exemplary embodiment of the present invention. Hereinafter, the process will be described in detail with reference to FIG. 6.

When the firmware update of the embedded system 100 according to the embodiment of the present invention is required, the new firmware registration step S60 and the upgrade event generation step S61 are not different from those of the existing embedded system.

However, unlike the conventional method, the embedded system 100 according to an embodiment of the present invention, if the new source code is present in the terminal version control server (S62), and only download the corresponding code that needs to be upgraded (S64, S65) In this case, the source code can be directly executed without the firmware loading and the embedded system rebooting in the conventional method.

That is, when upgrading some firmware of the embedded system 100 according to an embodiment of the present invention, the entire firmware does not need to be replaced, and thus the size of the new source code is very small compared to the firmware replacement method of the existing embedded terminal. short. Therefore, the firmware upgrade method of the embedded system 100 according to the exemplary embodiment of the present invention has an advantage of performing upgrade of a very efficient and fast executable code for a plurality of embedded systems as compared with the conventional method.

The embedded system 100 driving method including the embedded system 100 firmware upgrade method according to an embodiment of the present invention described above may be implemented by executing computer readable codes stored in a computer readable recording medium. have. The method for driving the embedded system 100 according to the embodiment of the present invention may be implemented by executing a computer program for executing the method for driving the embedded system 100 stored in a computer-readable recording medium.

The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. For example, computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like.

The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. In addition, functional programs, codes, and code segments for implementing the embedded system 100 driving method may be easily inferred by programmers in the art to which the present invention pertains.

Hereinafter, the characteristics of system programming languages and script programming languages that may be utilized in the embedded system 100 according to an exemplary embodiment of the present invention will be described.

7 illustrates the data processing speed of multiple system programming languages and multiple script programming languages. Table 1 shows the characteristics of C and Java, the representative system programming languages, and Lua and Python, the major script programming languages.

Referring to FIG. 7 and Table 1, Lua, which is a script programming language used in the embedded system 100 according to an embodiment of the present invention, has a low complexity, high source code ease of implementation, and a data processing speed in the C language. It's about 30 times slower than Java or PHP, slow in extension modules compared to other languages, and moderate resource usage.

In the embedded system 100 according to an exemplary embodiment of the present invention, the Lua-based embedded application module 110 for the user is linked to the C language-based hardware-related application module 120, thereby shortening the extension module, which is a disadvantage of the Lua-based embedded system. Supplemented.

Although the invention has been described with reference to one embodiment shown in the drawings, this is merely exemplary, and it will be understood by those skilled in the art that various modifications and equivalent other embodiments are possible. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

100: embedded system 110: embedded application module for the user
120: hardware related application module 112: Lua core module
114: Lua extension module 116: Lua interpreter
118: binding interface 122: C application module
124: Linux kernel 126: System poll module
128: network protocol module 130: device driver module

Claims (17)

A hardware related application module for defining a plurality of low level device resources and providing a handling service for the plurality of low level device resources using a system programming language; And
A user-programmed embedded application module for interoperating with the hardware related application module and controlling the plurality of low level device resources using a script programming language,
The user embedded application module
A script interpreter for executing source code corresponding to a plurality of script language based modules; And
Embedded system comprising a binding interface for binding the hardware-related application module and the user embedded application module. The method of claim 1, wherein the plurality of scripting language based modules
Script language based core modules; And
Embedded system comprising a plurality of scripting language based extension modules. The method of claim 1, wherein the binding interface
An embedded system that allows the hardware-related application module to use data and functions of the user-specific embedded application module and to use the programming language-based application module of the hardware-related application module in the user-embedded application module. The method of claim 3, wherein the programming language-based application module
Embedded system including libraries that are linked with the embedded application module for the user based on Remote Procedure Call (RPC). The method of claim 1, wherein the script programming language is
Embedded system characterized in that the LUA. The system of claim 1, wherein the system programming language is
Embedded system characterized in that it is C or C ++. The system of claim 1, wherein the embedded system is
And storing the received source code in a memory of the embedded system based on a predetermined communication protocol and registering the new firmware by executing the stored source code. The system of claim 1, wherein the embedded system is
And storing the source code portion to be received based on a predetermined communication protocol in a memory of the embedded system and updating the firmware by executing the stored source code. Defining a plurality of low level device resources and providing a handling service to the plurality of low level device resources using a system programming language; And
Using a script programming language to control the plurality of low level device resources in conjunction with providing the handling service of the plurality of low level device resources,
Controlling the plurality of low level device resources using the script programming language
Executing source code corresponding to a plurality of script language based modules; And
Binding a step of providing a handling service for the plurality of low level device resources using the system programming language and controlling the plurality of low level device resources using the script programming language. Way. 10. The method of claim 9, wherein the plurality of scripting language based modules
Script language based core modules; And
An embedded system driving method comprising a plurality of scripting language based extension modules. The method of claim 9, wherein the binding step
Enabling the system programming language-based module to use data and functions of the script programming language-based module, and enabling the script programming language-based module to use the system programming language-based module. Way. 12. The system of claim 11, wherein the system programming language based application module
And a library interoperating with the script programming language based module based on a remote procedure call (RPC). 10. The system of claim 9, wherein the script programming language is
Embedded system drive method characterized in that the LUA. 10. The system of claim 9, wherein the system programming language is
Method of driving an embedded system, characterized in that the C or C ++. The method of claim 9, wherein the embedded system driving method is
And registering new firmware by storing the received source code in a memory of the embedded system based on a predetermined communication protocol and executing the stored source code. The method of claim 9, wherein the embedded system driving method is
Storing the source code portion to be received based on a predetermined communication protocol in a memory of the embedded system and updating the firmware by executing the stored source code. A computer-readable recording medium storing code for executing the embedded system driving method according to any one of claims 9 to 17.

Images