KR102185289B1 - Software development system and method - Google Patents

Abstract

A software development system is disclosed. A software development system according to an embodiment of the present invention is a software development system that provides an integrated development environment supporting the development of device software for driving a hardware device including a main board equipped with a microcontroller, the hardware device A module component providing unit that provides information on one or more module components mounted on and electrically connectable through the integrated development environment; A module selection unit that selects the module component through a user interface; And a module code providing unit configured to provide a module code written so that the module component and the main board of the hardware device interact through the integrated development environment, and includes the module component and the module code selected from the module selection unit. The device software is automatically generated on the basis.

Description

Software development system and method {SOFTWARE DEVELOPMENT SYSTEM AND METHOD}

The present invention relates to a software development system and method, and more specifically, to develop software by purchasing a module component connected to a microcontroller and a module code associated with the module component in a software development program for driving a hardware device. It relates to a software development system and method.

In progressing a development project for developing a hardware device, the developer tries to find a module component that is compatible with the main board according to the development intention, has adequate performance, and has a low production cost. To do this, developers spend a lot of time searching through numerous module parts, reviewing data sheets, and looking for suitable module parts. In addition, in order to develop a program for driving a hardware device, a data sheet for each module component is studied, and trial and error are performed.

Even if such time cost is consumed, if the main board is replaced during the development project, all program codes must be changed to be compatible with the replaced microcontroller. It's like starting a project from scratch. The resources consumed up to this point are just thrown away. In such a hardware device development stage, it is necessary to prevent inefficiently wasted resources.

KR 10-0403195 B1 (2003. 10. 14.)

An object of the present invention is to create a database of module codes for module parts in the hardware device development stage, and to automate the setting work between the module parts and the main board only by simple pin assignment through a user interface.

In addition, it is possible to select only the module components compatible with the main board and the pins of the module components, thereby reducing the debugging time in the development stage.

In addition, module parts information is provided in the integrated development environment to reduce the time required to search for module parts.

In addition, by sharing or selling the module code, the developer gains additional profit or accelerates the development time, and the module component seller diversifies the promotion method.

A software development system according to an embodiment of the present invention is a software development system that provides an integrated development environment supporting the development of device software for driving a hardware device including a main board equipped with a microcontroller, the hardware device A module component providing unit that provides information on one or more module components mounted on and electrically connectable through the integrated development environment; A module selection unit that selects the module component through a user interface; And a module code providing unit configured to provide a module code written so that the module component and the main board of the hardware device interact through the integrated development environment, and includes the module component and the module code selected from the module selection unit. The device software can be automatically generated on the basis.

In addition, the module component providing unit may provide information on the module component not registered in the integrated development environment among the module components compatible with the main board to be exposed in the integrated development environment.

In addition, even if the alignment standard of the module components exposed in the integrated development environment is changed, the module component providing unit may be fixedly exposed to the upper part of the module component.

In addition, the module component providing unit may recommend the module component based on a frequency of use according to the type of the hardware device input from the integrated development environment among the module components compatible with the main board.

In addition, the integrated development environment may further include a parts purchase unit that provides purchase information on the module parts.

In addition, the purchase information may include one or more of a purchase place of the module component, price information according to each purchase place, a discount rate according to a purchase quantity, and a reputation for each purchase place.

In addition, the module code providing unit may provide the module code information not registered in the integrated development environment among the module codes for the module component to be exposed in the integrated development environment.

In addition, the module code may include a module code registered in the module code providing unit as being subordinate to a user account.

In addition, the module code providing unit, when the integrated development environment requests the module code, requests authentication of the receiving authority for the module code, but the receiving authority type is one of free, purchase, attachment, and subscription, and the Among the types of receiving rights, the attachment is dependent on the module part, and the receiving authority authentication may be changed for free when the module part is purchased.

In addition, the module code providing unit may allow only a part of the module code to be inquired when the integrated development environment for which the reception right authentication is requested is not authenticated with the reception right for the module code.

In addition, the module code received by the module code providing unit includes a unique code of the received integrated development environment, and the integrated development environment is the integrated development environment based on the unique code included in the received module code. Compilation of the module code can be performed or rejected depending on whether or not is authenticated.

In addition, the integrated development environment lists each pin connectable of the main board or the microcontroller for each pin of the module part through the user interface using pin information on the selected module part, and the user Can be assigned by input.

In addition, the integrated development environment may change the module code according to the changed pin assignment when the pin of the main board allocated to the pin of the selected module component is changed.

A software development method according to an embodiment of the present invention is a software development method using an integrated development environment that supports the development of device software for driving a hardware device including a main board equipped with a microcontroller, wherein the hardware device A module part information providing step of providing information on one or more module parts that can be mounted and electrically connected through the integrated development environment; A module selection step of selecting the module component; And a module code providing step of providing a module code written so that the module part and the main board of the hardware device interact through the integrated development environment; including, the module part and the module code selected in the module selection step. The device software can be automatically generated on the basis.

In addition, the integrated development environment lists each pin connectable of the main board or the microcontroller for each pin of the module part through the user interface using pin information on the selected module part, and the user Can be assigned by input.

In addition, in the providing of the module part information, information on the module part not registered in the integrated development environment among the module parts compatible with the main board may be provided to be exposed in the development program.

In addition, the providing of the module code may include: a reception request step of requesting the module code by the integrated development environment; An authentication requesting step of requesting authentication of receiving permission of the requested module code for an account logged in to the integrated development environment; If the receiving authority is authenticated as one of free, purchase, attachment, and subscription, the module code is provided, and if the receiving authority is not authenticated, only a part of the module code is inquired.

The hardware development system and the development method using the same according to the present invention can automate the setting task between the module component and the main board only by converting the module code for the module component into a database in the hardware device development stage, and simply assigning pins through the user interface. .

In addition, it is possible to select only the module components compatible with the main board and the pins of the module components, thereby reducing the debugging time in the development stage.

In addition, it is possible to reduce the time required to search for module parts by providing module part information in the integrated development environment.

In addition, by sharing or selling module codes, developers can obtain additional profits or accelerate development time, and module component sellers can diversify promotion methods.

1 is a block diagram of a hardware device according to an embodiment of the present invention
2 is a block diagram showing a schematic configuration of a software development system according to an embodiment of the present invention.
3 is a diagram illustrating selection of a module component through a user interface of the integrated development environment executed in a developer terminal according to an embodiment of the present invention.
4 is a diagram illustrating setting of a hardware environment through a user interface of an integrated development environment according to an embodiment of the present invention.
5 is a diagram showing a driving code according to an embodiment of the present invention.
6 is a diagram illustrating a driving code into which a driving code generated by an integrated development environment according to an embodiment of the present invention is inserted.
7 is a diagram showing a change in a driving code according to a hardware environment setting change.
8 is a diagram illustrating a module code connected by the generated driving code of FIG. 6 according to an embodiment of the present invention.
9 is a view showing selection of a module component according to an embodiment of the present invention.
10 is a view showing that a module component is recommended according to an embodiment of the present invention.
11 is a view showing a state in which a part of a module component according to an embodiment of the present invention is fixedly exposed to an upper portion.
12 is a block diagram showing a schematic configuration of a software development system according to an embodiment of the present invention.
13 is a diagram showing a market interface of an integrated development environment according to an embodiment of the present invention.
14 is a conceptual diagram illustrating a relationship between transmission and reception of module code and compilation authentication information according to an embodiment of the present invention.
15 is a flowchart of a software development method according to an embodiment of the present invention.
16 is a detailed flowchart of a module code providing step according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those of ordinary skill in the art can easily implement the present invention. However, the present invention may be implemented in various different forms and is not limited to the embodiments described herein. In addition, in the drawings, parts not related to the description are omitted in order to clearly describe the embodiments of the present invention.

The terms used in this specification are used only to describe specific embodiments, and are not intended to limit the present invention. Singular expressions may include plural expressions unless the context clearly indicates otherwise.

In the present specification, terms such as "comprise", "have", or "include" are intended to designate the presence of features, numbers, steps, actions, components, parts, or a combination thereof described in the specification. It may be understood that the presence or addition of other features, numbers, steps, actions, components, parts, or combinations thereof, or further features, are not excluded in advance.

In addition, the components shown in the embodiments of the present invention are shown independently to represent different characteristic functions, and it does not mean that each component is formed of separate hardware or a single software component. That is, each constituent unit is described as being listed as a respective constituent unit for convenience of explanation, and at least two constituent units of each constituent unit are combined to form one constituent unit, or one constituent unit may be divided into a plurality of constituent units to perform a function. Integrated embodiments and separate embodiments of each of these components are also included in the scope of the present invention unless departing from the essence of the present invention.

In addition, the following embodiments are provided to more clearly describe to those with average knowledge in the art, and the shape and size of elements in the drawings may be exaggerated for clearer explanation.

Hereinafter, a preferred embodiment according to the present invention will be described with reference to the accompanying drawings.

1 is a block diagram of a hardware device according to an embodiment of the present invention.

Referring to FIG. 1, the hardware device 10 according to an embodiment of the present invention includes one or more module parts (M1, M2, ..., Mn) on the main board 11 on which the microcontroller 12 is mounted. ) May be a device that is electrically connected to perform a specific function. The hardware device 10 may be equipped with a driving program or a control program, and may perform a designed specific function or a special task. Hereinafter, a driving program, a control program, or an operating system for driving the hardware device 10 is referred to as device software.

The hardware device 10 may be a simple device or a high-level device. The simple device may be a device in which a low-performance microcontroller 12 and a low-capacity memory are mounted on the main board 11, and a high-level device is a device having a relatively high performance microcontroller 12 and a high capacity to perform various functions. It may be a device equipped with a memory. The type of the hardware device 10 may vary according to the function of the module components M1, M2, ..., Mn electrically connected to the main board 11. For example, the hardware device 10, which may correspond to a simple device, may be an alarm-capable electronic clock device equipped with a display module for displaying time and a speaker module, and an electronic clock device equipped with a module capable of measuring weight. It can be a scale device. The hardware device 10 that may correspond to a high-level device may be a device such as a smart phone, a smart TV, or a medical device equipped with a plurality of modules.

One or more module components M1, M2, ..., Mn may be connected to the main board 11. That the module components M1, M2, ..., Mn are connected to the main board 11 may be capable of transmitting and receiving electrical signals or power to each other. In addition, it can be said that it is connected if it can transmit and receive signals even if it is not physically connected. For example, when the main board 11 and the module parts (M1, M2, ..., Mn) are wirelessly connected to transmit and receive signals, the main board 11 and the module parts (M1, M2, ..., Mn) Can be said to be connected.

The module parts M1, M2, ..., Mn may be additionally connected to the hardware device 10 and may be parts capable of performing a specific function. The hardware device 10 may include at least one module component (M1, M2, ..., Mn). In general, module parts (M1, M2, ..., Mn) are connected to a board including a central processing unit such as a microcontroller 12 to perform one or more functions or different module parts (M1, M2, .. ., Mn) can interact to perform various functions. Module components (M1, M2, ..., Mn) can operate according to the control signal of the microcontroller 12, and the operation result can be returned to the main board 11 or the microcontroller 12. . For example, module parts (M1, M2, ..., Mn) are communication modules, sensor modules, audio output modules, data conversion modules, auxiliary memory modules, sensor modules of various functions, rectifiers, motors, display modules, antennas, etc. I can.

Device software for driving the hardware device 10 may be classified into a driving code and a module code. Here, the driving code may be a code for directly controlling the hardware device 10. The module code may be an auxiliary code subordinately included in the driving code. In general, when a developer writes a driving code, a code such as a function or variable that is repeatedly used for any one module part (M1, M2, ..., Mn) may be included. Codes such as functions or variables that are repeatedly used for one module part (M1, M2, ..., Mn) can be separately generated as other code files, and can be used subordinately by connecting them to the driving code. The module code may be a code previously written for one module part. In addition, the module code may include information on the corresponding module parts (M1, M2, ..., Mn). The information of module parts (M1, M2, ..., Mn) is the category, model, manufacturer, function, number of pins, pin type (input pin or output) of the module part (M1, M2, ..., Mn). Pin), and the like.

2 is a block diagram showing a schematic configuration of a software development system according to an embodiment of the present invention.

Referring to FIG. 2, the software development system 100 according to an embodiment of the present invention may provide an integrated development environment supporting device software development. The software development system 100 is a module part providing unit that provides information on one or more module parts (M1, M2, ..., Mn) that can be electrically connected by being mounted on the hardware device 10 through the integrated development environment. (110), a module selection unit 120 for selecting module parts (M1, M2, ..., Mn) through a user interface, and module parts (M1, M2, ..., Mn) and a hardware device (10) It may include a module code providing unit 130 that provides the module code written to interact with the main board of the integrated development environment.

Device software may be automatically generated based on the module component and the module code selected by the module selection unit 120. The driving code mentioned in FIG. 1 may be included in the device software.

The integrated development environment may be a program that runs on a developer terminal and develops the device software for the hardware device 10. The developer terminal may be a terminal capable of receiving, processing, and displaying various data, etc. through the network 150 according to the user's input/output operation. For example, a smartphone, a tablet computer, a desktop ( Desktop) Computer, Laptop Computer, Notebook, Workstation, PDA (Personal Digital Assistants), Portable Computer, Wireless phone, Mobile phone, e-book -book), PMP (Portable Multimedia Player), portable game console, navigation device, black box, digital camera, television, and wearable device. , Not limited to these.

The software development system 100 is connected to the development support server 140 through the network 150 to transmit and receive data. In addition, the module component providing unit 110, the module selection unit 120, and the module code providing unit 130 of the software development system 100 are respectively connected to the development support server 140 and the network 150 to transmit and receive data. can do.

The network 150 may be a communication network that is a high-speed backbone network of a large communication network capable of large-capacity, long-distance voice and data services, and may be a next-generation wired or wireless network for providing Internet or high-speed multimedia services. When the network 150 is a wireless communication network, cellular communication or short-range communication may be included. For example, cellular communication is LTE (Long-Term Evolution), LTE-A (LTE Advance), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), UMTS (Universal Mobile Telecommunications System), WiBro (Wireless Broadband), or It may include at least one of Global System for Mobile Communications (GSM) and the like. In addition, short-range communication may include at least one such as Wireless Fidelity (Wi-Fi), Bluetooth, or Near Field Communication (NFC). However, the present invention is not limited thereto, and it is preferable that a wireless communication technology to be developed later is included.

The module component providing unit 110 may receive data on module components (M1, M2, ..., Mn) held by the development support server 140 to be exposed or used in the integrated development environment.

The module code providing unit 130 may receive data on the module code held by the development support server 140 to be exposed or used in the integrated development environment.

3 to 8 describe the integrated development environment.

3 is a diagram illustrating selection of a module component through a user interface of the integrated development environment executed in a developer terminal according to an embodiment of the present invention.

1 and 3, a developer may select a module component to be connected to the main board 11 through the user interface I100 of the integrated development environment. Module parts M1, M2, ..., Mn appearing in the user interface I100 are module parts registered in the integrated development environment. The registered module component may mean that the module code of the corresponding module component is registered in the integrated development environment, and the module code of the module component can be used as the driving code.

In addition, the integrated development environment, when module parts (M1, M2, ..., Mn) are selected through the user interface (I100), the module parts (M1, M2, ... ,) appearing in the user interface (I100). Mn) may appear only module components compatible with the main board 11 of FIG. 1. For example, if the module parts registered in the integrated development environment are M1 to M10, only the module parts M1, M3, and M10 compatible with the main board 11 may appear in the user interface I100. When the main board 11 is replaced with another main board, only compatible M2, M4 and M6 may appear on the replaced main board. Alternatively, all module parts (M1, M2, ..., Mn) registered in the integrated development environment are displayed, but only module parts compatible with the main board 11 may be selected. For example, if the module parts registered in the integrated development environment as above are M1 to M10, all M1 to M10 are displayed on the user interface (I100), but only M1, M3, and M10 compatible with the main board 11 are selected. Can be. Here, when the main board 11 is replaced with another main board, the module parts that can be selected may be changed.

In the related art, time cost was consumed to examine the types of module components required to implement the intended function by the developer, and to check each data sheet to see if the main board 11 to be used and the module components to be connected are compatible with each other. However, in the integrated development environment of the present invention, it is possible to easily check whether the registered module parts are compatible with the main board 11, and only compatible module parts can be selected, thereby reducing the mentioned time cost.

4 is a diagram illustrating setting of a hardware environment through a user interface of an integrated development environment according to an embodiment of the present invention.

Referring to FIGS. 1 and 4, hardware environment setting for a selected module component may be performed through a user interface I100. The hardware configuration may be to allocate each pin of the selected module component to each pin of the main board 11 or the microcontroller 12. Here, the pin may mean a physical contact through which signals, data, or power can be transmitted and received.

The main board 11 and module components M1, M2, ..., Mn have pins for transmitting and receiving signals according to their respective hardware design. The developer connects the pins of the module parts (M1, M2, ..., Mn) to the pins of the main board (11) according to their own intention, and the main board (11) and the module parts (M1, M2, ..., Mn) Can create a signal path between. In the past, these pin assignments were assigned by the developer by writing their own code. In this case, the developer had to write a code while reviewing the data sheet of the main board 11 and the data sheet of the module parts (M1, M2, ..., Mn) connected to the main board 11. It was necessary to check how many module component pins to be connected to the main board 11, whether the corresponding pin is an analog input pin or an output pin, or a digital input pin or an output pin. In order to connect one module component to the main board 11 in this way, it took time to review and confirm the data sheet, and the more module parts to be connected to the main board 11, the longer the time.

However, in the integrated development environment of the present invention, pins of the main board 11 corresponding to each pin of a module component may be allocated using a user interface. The integrated development environment may automatically generate the driving code by automatically reflecting the hardware environment setting through the user interface I100 to a driving code.

In addition, the hardware configuration may include allocating pins of the module components M1, M2, ..., Mn to the pins of the microcontroller 12. In general, the microcontroller 12 is mounted on the main board 11 and the module component (M1, M2, ..., Mn) pins may be connected to the main board 11 pins. However, in rare cases, the module component (M1, M2, ..., Mn) pin and the microcontroller 12 pin are connected directly. Since the integrated development environment of the present invention includes allocating pins of the microcontroller 12 to pins of module parts (M1, M2, ..., Mn), development efficiency for various development cases can be improved.

When the hardware environment setting through the user interface (I100) is described in more detail, when a module component (M1, M2, ..., Mn) to be connected to the main board 11 is selected, specific hardware according to the selected module component is selected. A user interface I100 in which environment setting is possible may appear. The user interface I100 may include an area I110 in which pin assignment is possible and an area I120 showing detailed information of a selected module component. The pin assignment area I110 may include an interface I111 for designating a mainboard pin corresponding to each pin of a module component. The area I120 showing detailed information of the selected module component may include information to include a category, model, manufacturer, function, or place of purchase for the selected module component. On the other hand, when the area I120 showing detailed information is clicked with a mouse or the like, a more detailed data sheet for a corresponding module component may be linked and provided.

In addition, in the integrated development environment, only pins of the main board 11 or the microcontroller 12 that can be assigned to the selected module component pins can be selected. For example, when the'Row1' pin is assigned as shown in FIG. 4, since'Row1' is a digital output pin, only the digital input pin can be selected as the pin of the main board 11 or the microcontroller 12. No VCC, GND or analog pins are selected. In the conventional method of comparing data sheets and writing in text form, it is possible to make a mistake in allocating the digital output pin “Row1” to the analog input pin, but the present invention can significantly reduce such a possibility.

In general, since the total number of pins on the main board 11 is larger than the total number of pins of one module component, it can be proceeded by allocating one of the total pins of the main board 11 to one pin of the selected module component. have.

5 is a diagram illustrating a driving code according to an embodiment of the present invention, and FIG. 6 is a diagram illustrating a driving code into which a driving code generated by an integrated development environment according to an embodiment of the present invention is inserted.

The driving code 200 shown in FIG. 5 is an initial driving code 210 in which only the type of the main board 11 is selected and module parts are not connected in the integrated development environment. The driving code 200 of FIG. 6 is the driving code 200 into which the initial driving code 210 and the driving code 220 generated by the integrated development environment are inserted. The integrated development environment may generate the driving code 220 reflecting the hardware environment setting.

This will be described with reference to FIGS. 4 and 6. The integrated development environment lists each pin of the main board or the microcontroller that can be connected to each pin of the module part through a user interface using pin information on the selected module part, and assigns it by the user input. have. In the hardware configuration of FIG. 4, the pins of Row1, Row2, Row3, Row4, Col1, Col2, and Col3 of the keypad module (Keypad_4x30) are set to 5, 4, 3, 2, 8, 7 of the main board 11, respectively. If pin 6 is assigned, the integrated development environment may generate the driving code 220 reflecting the hardware environment setting. In FIG. 4, only portions of Row1, Row2, and Row3 of the keypad module (Keypad_4x30) are indicated on pins 5, 4, and 3 of the main board 11, respectively, due to the size of the user interface I100. It is assumed that Row4, Col1, Col2, and Col3 of the keypad module (Keypad_4x30) are assigned to pins 2, 8, 7, and 6 of the main board 11, respectively.

The generated driving code 220 may also include a code that enables a predefined function related to the selected module component (Keypad_4x30 in FIGS. 4 and 6) to be used. In the generated driving code 220 of FIG. 6,'#include <Keypad_4x3.h>' refers to the driving code 200 and the module so that the function defined in the module code related to the keypad module part can be used by the driving code 200. This is the code that connects the code. The integrated development environment automatically generates a code connecting the module code in the driving code 200 to connect the driving code 200 and the module code, and easily use the function defined in the module code within the driving code 200. You can do it.

The generation of the driving code 220 of the integrated development environment may be automatically performed upon completion of the hardware environment setting. When the pin assignment is completed through the user interface I100, the drive code 220 reflecting the hardware environment setting is automatically generated, so that the developer can immediately check the generated drive code 220, and a function included in the module code Can be used immediately.

The driving code 220 generated by the integrated development environment shown in FIG. 6 is not limited to the illustrated code, but can be modified to suit the characteristics of the module parts (M1, M2, ..., Mn) and further added. Can be. In addition, it may be generated by being included in the initial driving code 210.

7 is a diagram showing a change in a driving code according to a hardware environment setting change.

Referring to FIG. 7, in the integrated development environment according to an embodiment of the present invention, when the hardware environment setting is changed, the changed content may be reflected in the generated driving code 220. More specifically, the pin assignment according to the initial hardware configuration of FIG. 4 is 5 of the main board 11, respectively, for the Row1, Row2, Row3, Row4, Col1, Col2, and Col3 pins of the keypad module (Keypad_4x30). It is assigned to pins 4, 3, 2, 8, 7, and 6. Accordingly, the driving code 220 generated by reflecting the generated initial hardware configuration of FIG. 6 is also pin assigned to pins 5, 4, 3, 2, 8, 7, and 6. Later, if the pin assignment of the Row1 and Row2 pins of the keypad module (Keypad_4x30) to pins 10 and 11 of the main board 11 through the user interface I110 as shown in FIG. 7 is changed, the integrated development environment is The driving code 221 may be modified to reflect the changed pin assignment.

In the process of developing the hardware device 10, the developer repeats design and programming for numerous module components. In such a repetitive process, data sheets are compared each time, hardware configuration and code writing are also repeated, so inefficient time consumption is very large. In addition, there is a high possibility that the code is incorrectly written in the iterative process. It is usually corrected during the debugging process, but debugging time is often wasted. The present invention can prevent inefficient resource consumption in the development process of the hardware device 10.

In addition, the present invention does not simply generate a code, but according to the type of the main board 11, information on different module parts (M1, M2, ..., Mn), basic hardware settings, and module codes, which are frequently used codes, are provided. It is stored in the integrated development environment, and the developer can simply configure the hardware environment through the user interface. Since the hardware environment setting is automatically reflected in the driving code so that the developer can easily use the function for the module part, it is possible to save the modification time resource according to the module replacement.

8 is a diagram illustrating a module code connected by the generated driving code of FIG. 6 according to an embodiment of the present invention.

Referring to FIG. 8, the module code 300 may be a code prepared in advance to facilitate use of a code (variable, function, or data type type definition and declaration) for controlling a module component to be connected in the driving code. In FIG. 8, a module code connected with “#include <keypad_4x3.h>” among the driving codes 220 generated by the integrated development environment shown in FIG. 6 is shown in FIG. 6 and 8, due to the generated driving code 220, the class of Keypad_4x3 can be used, and the'getKey()' function 310 defined in the module code 300 is used as the driving code ( 200) can be used immediately. In addition, another module code 320 connected in series may also exist in the module code 300. Due to another module code 320 that is subordinately connected in the module code, all functions for controlling the corresponding module parts can be used only with the driving code 220 generated by simple hardware configuration.

The module code 300 prevents a developer from separately writing a corresponding module component to use each module component, thereby reducing development resource waste. The module code is not limited to the code shown in FIG. 8, and various other codes may be included as module codes. For example, it is possible to store the module component information in the form of JSON (JavaScript Object Notation) and display the module component information in the hardware environment setting. Accordingly, the module code has a broader meaning than the area of modular programming used in the programming area, and may include all files or codes that allow the module component to be used and used by the corresponding main board 11.

9 is a view showing selection of a module component according to an embodiment of the present invention.

Referring to FIG. 9, as mentioned in FIG. 3, a developer can select a module component to be connected to the main board 11 through the user interface I100 of the integrated development environment. At this time, in the user interface I100, not only module parts M1, M2, and M3 registered in the integrated development environment, but also module parts M4 and M5 that are not registered in the integrated development environment may be displayed and selected.

Module parts M4 and M5 that are not registered in the integrated development environment may be module parts registered in the development support server 140 of FIG. 2 and received by the module part providing unit 110. When the software development system 100 is connected to the module parts providing unit 110 and the network 150, the integrated development environment provides the module parts providing unit 110 with data on the module parts registered in the development support server 140. Is received, the received module parts M4 and M5 may be displayed on the user interface I100. All module parts registered in the development support server 140 may be exposed as module parts of the module part providing unit 110 appearing in the integrated development environment. However, it may be exposed according to a predetermined standard for the developer's user convenience. The predetermined criterion may be compatibility with the main board 11 and a frequency of use.

That is, the module component providing unit 110 receives information on the module component not registered in the integrated development environment among module components compatible with the main board 11 from the development support server 140 and exposes it to the integrated development environment. It can be provided if possible. Even if the developer is not registered in the integrated development environment, since the developer can obtain or use the commonly used module part information through the module part database of the development support server 140, time for searching for module part information can be saved. In addition, since module part information is provided in the integrated development environment, the development process may be more efficient.

Hereinafter, a module component that is not registered in the integrated development environment and is received by the module component provider 110 from the development support server 140 and exposed to the user interface I100 is referred to as a cloud module component.

10 is a view showing that a module component is recommended according to an embodiment of the present invention.

Referring to FIG. 10, the module component providing unit may recommend a module component having a high frequency of use according to a type of a hardware device input from the integrated development environment among module components compatible with the main board. In more detail, the module component providing unit may recommend module components that are frequently used when manufacturing the hardware device according to the type of hardware device the developer intends to manufacture. The recommended module components M6, M7, and M8 may be exposed through the user interface I100 of the integrated development environment. The recommended module parts M6, M7, M8 may be cloud module parts M7, M8, or may be module parts M7 registered in the integrated development environment. The module component provider recommends module parts with a high frequency of use according to the type of hardware device, so that the developer can preemptively use the recommended module parts even if the developer does not have development experience of the hardware device to be developed, trial and error during the development period are avoided. Can be reduced.

11 is a view showing a state in which a part of a module component according to an embodiment of the present invention is fixedly exposed to an upper portion.

Referring to FIG. 11, even if the alignment standard of module components exposed in the integrated development environment is changed, the module component providing unit may allow some of the module components to be fixedly exposed to the upper part. In more detail, module components exposed to the user interface I100 may be aligned according to a predetermined standard as mentioned above. For example, the predetermined criterion may be a frequency of use of module parts, a unit price of module parts, and scores registered by other developers. When the predetermined alignment criteria are changed, the alignment criteria of the cloud module components may be changed according to the changed criteria. At this time, some of the cloud module parts may be fixed in order of alignment so that they are exposed to the highest level. In FIG. 11, (A) and (B) show that the module parts are arranged according to different alignment criteria. In (A) of FIG. 11, the module parts arranged according to the alignment criteria are M12, M13, and M14, and the module parts fixed to be exposed at the top are M9, M10, and M11. In (B) of FIG. 11, the module parts arranged according to different alignment criteria are M15, M12, and M14, and the module parts fixed to be exposed at the top are M9, M10, and M11.

Qualifications may be required to be exposed to a fixed level. The qualification can be obtained by a developer who registers the module part by paying a predetermined product, and the qualification can be maintained for a certain period. When the deadline has elapsed, the above qualification can be reacquired by paying the goods again.

A seller who sells the module parts may use the qualification to place the module parts at the top of the exposed list to induce more people to inquire and purchase the module parts.

12 is a block diagram showing a schematic configuration of a software development system according to an embodiment of the present invention, and FIG. 13 is a view showing a market interface of an integrated development environment according to an embodiment of the present invention.

12 and 13, the software development system 100 according to an embodiment of the present invention may further include a parts purchase server 160 that provides purchase information on module parts in an integrated development environment. The parts purchase server 160 is connected to the network 150 to transmit and receive data related to the purchase information with the software development system 100. The purchase information may be one or more of one or more purchase places of the module parts, price information according to each purchase place, a discount rate according to a purchase quantity, and a reputation for each purchase place, and appear on the market interface I200 of the integrated development environment. I can.

In an embodiment, the market interface I200 may appear when a cloud module component of FIGS. 9 to 11 is selected. The market interface I200 may be an interface for purchasing a cloud module component selected by a developer or a module code of the selected cloud module component. The module code information not registered in the integrated development environment among the module codes for module parts may be exposed on the market interface I200. The module code information may be provided by the module code providing unit 130 receiving the module code information from the development support server 140.

Module codes developed by different developers may be uploaded to the development support server 140. The uploaded module code may be dependent on each developer's account. The fact that the module code is subordinate to the developer account may mean that the distribution authority of the module code is granted to the developer account. The module code providing unit 130 may sell or distribute the uploaded module code according to the signal of the authenticated developer account. For example, the distributed module code may be exposed to the market interface I200 of the module component and sold as shown in FIG. 13, or may be shared as an attachment on a bulletin board.

In order to receive the distributed module code, the integrated development environment may make a reception request to the module code providing unit 130. When the integrated development environment requests the module code, the module code providing unit 130 may request authentication of receiving authority for the module code. The type of receiving permission may be one of free, purchase, attachment, and subscription. The reception right may be authenticated by checking account information logged in to the integrated development environment for which the module code is requested to be received by the development support server 140. In addition, the type of reception authority may be designated using the developer account authority to be distributed.

The free of charge type may be a type that anyone can receive without a qualification limit for receiving the module code. Since the module code designated for free is not subject to qualification restrictions, it can be transmitted to a developer terminal that has requested reception without receiving authorization authentication.

Among the types of the right to receive, the purchase may be to acquire the right to receive the module code of the version at the time of purchase of the module code distributed by paying a predetermined product. When the right to receive the purchase type is acquired, in order to receive the latest version of the module code distributed after the point of purchase, it may be necessary to pay the goods again to reacquire the right to receive.

The attachment among the types of the right to receive is subordinate to the module component, and thus the authentication of the right to receive is changed for free when the module component is purchased. For example, when the module part M20 of FIG. 13 is purchased, the module code designated as sale for the module part M20 is provided with the receiving authority type free for the account that purchased the module part M20. Can be changed to. The module code, which is changed for free, may be a module code written by a manufacturer who manufactured the module part M20, or may be a module code individually written by another developer. The module code that is changed for free may be designated according to an agreement between the service provider and the developer who wrote the code or the manufacturer.

Among the types of receiving rights, a subscription may be a subscription to an account that distributes the module code. In more detail, the subscription to the account may be to change the right to receive the module code distributed by the account for free during a predetermined period by paying for goods. For example, if you subscribe to an account called'A', you can receive module codes distributed from the account'A' without restrictions during the subscription period. In addition, it may be a subscription that is not limited to the account. Subscriptions that are not limited to the account may be global subscriptions. When the global subscription is made, the module code registered in the development support server 140 can be received indefinitely regardless of the account during the subscription period.

The module code providing unit 130 may allow only a part of the module code to be inquired when the integrated development environment for which the reception right authentication is requested is not authenticated for the reception right for the module code.

A developer who has developed the module code may further develop the module code by sharing the developed module code with a plurality of other developers, or may obtain a profit by selling the module code. In addition, since the developer who purchases or subscribes to the module code can select a purchase option, it can be determined according to the development situation, and can greatly accelerate the development time by purchasing the entire module code of the module component used in the hardware device. . A seller who sells module parts may sell the module code essentially linked to the module part in bundles with the module parts, so that a sales strategy may be diversified.

14 is a conceptual diagram illustrating a relationship between transmission and reception of module code and compilation authentication information according to an embodiment of the present invention.

Referring to FIG. 14, in an embodiment, the module code C1 received from the module code providing unit 130 may include a unique code of the received integrated development environment. Here, the unique code may be, for example, a control device identification code of a developer terminal, a serial number of an integrated development environment, and a serial number of a main board of the developer terminal. However, the present invention is not limited thereto, and may be another unique value capable of identifying a developer terminal on which the integrated development environment is executed.

The integrated development environment executed in the developer terminal may perform or reject compilation of the module code according to whether the integrated development environment is authenticated based on the unique code included in the received module code. If the compilation authentication information matches, the integrated development environment may compile the received module code C1. However, when the compilation authentication information is inconsistent, the integrated development environment may refuse to compile the received module code C1. Whether or not the integrated development environment is authenticated is determined by the module code providing unit 130, the unique code C2 of the integrated development environment for which the module code C1 has been requested, and the integration of the received module code to be compiled. It may be a match or inconsistency of the unique code of the development environment.

For example, when requesting to provide a module code to the module code providing unit 130 in the integrated development environment executed in the first developer terminal, the first developer terminal provides the module code providing unit with the unique code C2 of the integrated development environment. It can be provided as (130). When the module code providing unit 130 checks the reception authority authentication, and provides the module code C1 to the first developer terminal, the module code C1 contains a unique code C2 of the integrated development environment of the first developer terminal. You can provide it with information. When compiling the received module code C1, the integrated development environment of the first developer terminal may compare the unique code C2 included in the module code C1 with its own code to check match or inconsistency. .

On the other hand, when the module code (C1) provided through the supply request from the first developer terminal to the module code providing unit 130 is compiled in the second developer terminal, the unique code (C2) included in the module code (C1) and the second Since the unique code of the integrated development environment executed in the developer terminal is different, the compilation authentication information becomes inconsistent, and the integrated development environment may reject the compilation of the module code C1.

In addition, the integrated development environment may request the module code providing unit for authentication again when the number of times the received module code is compiled exceeds a predetermined number of times. Even if the initial compilation authentication is performed, if a predetermined number of compilations is exceeded, the integrated development environment may reject compilation and request reauthentication of the module code providing unit 130. Since the initial compilation authentication may be hacking or fake authentication using a tool, re-authentication may be requested.

Compilation authentication of the integrated development environment can prevent illegal distribution of module codes.

Hereinafter, a software development method according to an embodiment of the present invention will be described. Since the software development method is similar to the variable steering wheel system, it will be briefly mentioned.

15 is a flowchart of a software development method according to an embodiment of the present invention.

Referring to FIG. 15, a software development method using an integrated development environment supporting the development of device software for driving a hardware device including a main board equipped with a microcontroller according to an embodiment of the present invention is provided in the hardware device. Module part information providing step (S110) of providing information on one or more module parts that can be mounted and electrically connected through the integrated development environment, a module selection step of selecting the module part (S120), and the module part and the hardware It may include a module code providing step (S130) of providing a module code written so that the main board of the device interacts through the integrated development environment.

The device software may be automatically generated based on the module component and the module code selected in the module selection step S120.

The integrated development environment lists each pin connectable of the main board or the microcontroller with respect to each pin of the module component through the user interface using pin information on the selected module component, and by the user input Can be assigned.

The module component information providing step (S110) may be to provide information on the module component not registered in the integrated development environment among the module components compatible with the main board to be exposed in the development program.

16 is a detailed flowchart of a module code providing step according to an embodiment of the present invention.

Referring to Figure 16, the module code providing step (S120) is a reception request step (S121) in which the integrated development environment requests the module code, the right to receive the requested module code for an account logged into the integrated development environment It may include an authentication request step (S122) of requesting authentication. And after the step of authenticating or confirming the reception right (S123), if one of free, purchase, attachment, and subscription is authenticated, the module code is provided (S123). It may include an inquiry step (S125).

Various embodiments described herein may be implemented by hardware, middleware, microcode, software, and/or a combination thereof. For example, various embodiments include one or more application specific semiconductors (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays. (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions presented herein, or a combination thereof.

Further, for example, various embodiments may be embodied or encoded on a computer-readable medium containing instructions. Instructions embodied or encoded on a computer-readable medium may cause a programmable processor or other processor to perform a method, eg, when the instructions are executed. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. The storage medium may be any available medium that can be accessed by a computer. For example, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage medium, magnetic disk storage medium or other magnetic storage device, or instructions or data accessible by the computer to the desired program code. It may include any other medium that can be used to transport or store in the form of structures.

Such hardware, software, firmware, and the like may be implemented within the same device or within separate devices to support the various operations and functions described herein. Additionally, components, units, modules, components, and the like described as "units" in the present invention may be implemented together or separately as interoperable logic devices. The description of different features for modules, units, etc. is intended to highlight different functional embodiments, and does not necessarily imply that they must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components or may be integrated within common or separate hardware or software components.

Although the operations are shown in the figures in a specific order, it should not be understood that these operations are performed in the specific order shown, or in a sequential order, or that all illustrated operations need to be performed to achieve the desired result. . In any environment, multitasking and parallel processing can be advantageous. Moreover, the division of various components in the above-described embodiments should not be understood as requiring such division in all embodiments, and the described components are generally integrated together into a single software product or packaged into multiple software products. It should be understood that you can.

The present invention has been described with reference to the embodiments shown in the drawings, but these are only exemplary, and those of ordinary skill in the art will appreciate that various modifications and equivalent other embodiments are possible therefrom. Therefore, the true technical protection scope of the present invention should be determined by the technical spirit of the appended claims.

10: hardware device 11: mainboard
12: microcontroller 100: software development system
110: module component providing unit 120: module selection unit
130: module code provider 140: development support server
150: network 160: parts purchasing server

Claims (5)

In a software development system that provides an integrated development environment that supports the development of device software for driving a hardware device including a main board equipped with a microcontroller,
A module component providing unit mounted on the hardware device and providing information on one or more module components electrically connectable through the integrated development environment;
A module selection unit that selects the module component through a user interface; And
Including; a module code providing unit that provides a module code written so that the module component and the main board of the hardware device interact through the integrated development environment,
Automatically generate the device software based on the module component and the module code selected by the module selection unit,
The module code providing unit provides the module code information not registered in the integrated development environment among the module codes for the module part to be exposed in the integrated development environment.
The method of claim 1,
The software development system further comprising a parts purchase unit for providing purchase information on the module parts in the integrated development environment.
The method of claim 1,
The module code,
A software development system comprising a module code that is subordinate to a user account and registered in the module code providing unit.
The method of claim 1,
The module code providing unit,
When the integrated development environment requests the module code, it requests authentication of the receiving authority for the module code, and the receiving authority type is one of free, purchase, attachment, and subscription,
The attachment of the type of receiving authority is subordinate to the module part, and the receiving authority authentication is changed for free when the module part is purchased.
In the software development method using an integrated development environment that supports the development of device software for driving a hardware device including a main board equipped with a microcontroller,
A module part information providing step of providing information on one or more module parts mounted on the hardware device and electrically connectable through the integrated development environment;
A module selection step of selecting the module component; And
A module code providing step of providing a module code written so that the module component and the main board of the hardware device interact through the integrated development environment; and
Automatically generating the device software based on the module part and the module code selected in the module selection step,
In the providing of the module code, the module code information not registered in the integrated development environment among the module codes for the module part is provided to be exposed in the integrated development environment.

Images