KR20100100685A - Interface apparatus for communication between processors and communication system - Google Patents

Abstract

PURPOSE: An interface device for communication between processors and a communication system are provided to supply a flexible, symmetrical, and standardized interface for communication between a host processor and a sub processor. CONSTITUTION: The second layer(L2) manages a logical channel state and a physical channel state of a hardware channel for communication with a counterpart processor. The second layer transceives data with the counterpart processor based on the logical channel state and physical channel state. The third layer(L3) comprises one or more hardware interface APIs. The hardware interface API connects the interface device with hardware of the processor based on control by the second layer.

Description

Interface Apparatus for Communication Between Processors and Communication System

The present invention relates to an interface device and a communication system for communication between processors, and more particularly, to an interface configuration technology that can symmetrically standardize the structure of an interface module for performing communication between processors.

Recently, as the wired / wireless communication infrastructure is established and various services are provided based thereon, the computational throughput of the computational processing system provided in the device has also increased significantly. Accordingly, arithmetic processing systems tend to include a plurality of processors in order to improve their processing speed and processing power. For example, an arithmetic processing system may include a host processor and a plurality of subprocessors for performing main functions.

The host processor and the subprocessor communicate with each other to perform a specific function. For this communication, each processor must have a hardware implemented interface and a software implemented interface.

In general, in the case of the software-implemented interface, since the host processor and the subprocessor have different hardware structures, they are designed depending on hardware. Therefore, the interface configuration of the host processor and the subprocessor is asymmetric and not standardized.

For example, the host processor is provided with a host interface as a software driver for communication between the host processor and the subprocessor. The host interface is implemented in the form of code describing an interface processor with a subprocessor. Application threads generated by the host processor load and use the code for communication with the subprocessor. That is, application threads of the host processor may use the host interface in the form of code as a shared resource. The subprocessor may operate according to a request of the host interface and transmit response information.

However, in this case, since a plurality of applications generated by the processor share threads with the host interface in code form, code management is difficult and system congestion increases.

In addition, as mentioned above, since the software interfaces of the host processor and the subprocessor are asymmetrical and not standardized in the related art, programming is difficult and development is difficult and maintenance is difficult. It also depends on hardware, making it less portable to other processors.

Therefore, in the software interface structure for communication between processors, for example, between a host processor and a subprocessor, there is an urgent need for the development of a new technology capable of constructing a flexible, symmetrical and standardized interface.

SUMMARY OF THE INVENTION The present invention, devised in this context, provides an interface device and communication system for communication between processors that can provide a flexible, symmetrical, and standardized interface configuration for communication between processors, such as between a host processor and a subprocessor. There is a technical problem.

In order to achieve this object, the present invention provides an interface device for communication between processors in one aspect. The interface device for communication between the processors is an interface device provided in a processor for communication with a counterpart processor, and includes a first layer including at least one application program interface (API) for interworking an upper thread with the interface device; ; As a lower layer of the first layer, a logical channel state and a physical channel state of a hardware channel for communication with a counterpart processor are managed, and based on the logical channel state and the physical channel state, A second layer for processing data transmission and reception; And a third layer as a lower layer of the second layer, the third layer having at least one hardware interface API for interworking the hardware of the interface device and the processor based on the control by the second layer.

The at least one API of the first layer receives a transmission request message requesting data transmission from the upper thread to the counterpart processor and is based on the logical channel state managed by the second layer. A transmission API that determines whether the requested data transmission is possible and requests to perform the requested data transmission to the second layer when the requested data transmission is currently possible; And a reception API for transmitting the information of the received data to the upper thread when the information indicating that the data of the counterpart processor is received from the second layer is received.

The transmission API may request to temporarily store information related to the data transmission to the second layer when the requested data transmission is currently impossible. The first layer transmits the temporarily stored data to the second layer after the request for the temporary storage, when the requested data transmission becomes a possible channel state or a preset time elapses, based on the logical channel state. The apparatus may further include a retransmission API requesting to perform the data transmission according to the information associated with the.

The second layer logically manages the hardware channel, and requests, cancels, opens, writes, reads, and closes the hardware channel. A channel manager having a plurality of APIs for requesting; A channel transfer manager for transmitting a message to the third layer to control an operation of the hardware channel in response to a request from the channel manager; And a channel state manager for managing a logical channel state and a physical channel state of the hardware channel in association with the channel manager and the channel transfer manager.

The plurality of APIs included in the channel manager may include: a requesting API for requesting a reservation for the hardware channel to a channel transmission manager in order to transmit or receive data according to a request from the first layer or the counterpart processor; A cancellation API for sending a request to the channel transfer manager to request to cancel the reservation for the reserved hardware channel; An open API for sending a request to the channel transfer manager to open the hardware channel; A write API for transmitting a request to the channel transfer manager to transmit data to the counterpart processor through the open hardware channel; A read API for transmitting a request to the channel transfer manager to request to receive data from the counterpart processor through the open hardware channel; And a closed API for transmitting a request for closing the open hardware channel to the channel transfer manager.

The logical channel state may include a standby state indicating that the hardware channel is reserved; An active state indicating that data is being transmitted or received via the hardware channel; And a sleep state indicating that the hardware channel can be used. The channel manager may report to the channel state manager while monitoring the logical channel state of the hardware channel.

The second layer may further include a buffer manager for storing information related to the data transmission in an internal queue when receiving a request for temporarily storing information related to data transmission from the first layer.

The second layer may include a header generator configured to generate a header of a predetermined standard including information and add a command for setting the hardware channel to data; And a header parser that parses a header of data received from the hardware channel and transmits the header to the channel manager. The header may include any one of control information, transmission completion information, and reception completion information.

On the other hand, in order to solve the above technical problem, the present invention provides a communication system in another aspect. The communication system includes a first processor and a second processor, the first processor having a first interface module for communicating with the second processor through a hardware channel, the second processor providing the hardware channel. A second interface module for communicating with the first processor may be provided.

The first interface module includes: a first layer including at least one application program interface (API) for interworking an application thread of the first processor and the first interface module; As a lower layer of the first layer, the logical channel state and the physical channel state of the hardware channel is managed, and the data transmission and reception with the second processor based on the logical channel state and the physical channel state Second layer; And a third layer as a lower layer of the second layer, the third layer including at least one hardware interface API for interworking hardware of the first interface module and the first processor based on control by the second layer. Can be. The second interface module may have a configuration corresponding to the first interface module.

The at least one API of the first layer receives a transmission request message requesting data transmission from the application thread to the second processor and based on the logical channel state managed by the second layer. A transmission API that determines whether the requested data transmission is currently possible, and requests to perform the requested data transmission to the second layer if the requested data transmission is currently possible; And a reception API for transmitting the information of the received data to the application thread when the information indicating that the data of the second processor has been received from the second layer is received.

The transmission API may request to temporarily store information related to the data transmission to the second layer when the requested data transmission is currently impossible. The first layer transmits the temporarily stored data to the second layer after the request for the temporary storage, when the requested data transmission becomes a possible channel state or a preset time elapses, based on the logical channel state. The apparatus may further include a retransmission API requesting to perform the data transmission according to the information associated with the.

The second layer logically manages the hardware channel, and requests, cancels, opens, writes, reads, and closes the hardware channel. A channel manager having a plurality of APIs for requesting; A channel transfer manager for transmitting a message to the third layer to control an operation of the hardware channel in response to a request from the channel manager; And a channel state manager managing the logical channel state and the physical channel state of the hardware channel in association with the channel manager and the channel transfer manager.

The logical channel state may include a standby state indicating that the hardware channel is reserved; An active state indicating that data is being transmitted or received via the hardware channel; And a sleep state indicating that the hardware channel can be used.

The second layer may include: a buffer manager configured to store information related to the data transmission in an internal queue when receiving a request for temporarily storing information related to data transmission from the first layer; A header generator for generating a header of a predetermined standard including information and adding a command for setting the hardware channel to data; And a header parser that parses a header of data received from the hardware channel and transmits the header to the channel manager.

As described above, according to the present invention, an interface module for inter-processor communication can be classified hierarchically and a symmetrical and standardized configuration can be provided.

1 is a block diagram showing a configuration of a communication system including an interface device for communication between processors according to a preferred embodiment of the present invention.
2 is a block diagram illustrating a configuration of an interface device for communication between processors according to a preferred embodiment of the present invention.
3 is an exemplary diagram for describing an operating principle of the interface device shown in FIG. 2.
4 is a block diagram illustrating a hardware structure related to an interface between a host processor and a multimedia processor.
5 is an exemplary diagram illustrating tables for explaining information inserted into a header generated by a header generator.
6 is an exemplary diagram showing the structure of a header whose command type is 'Control'.
7 is an exemplary diagram showing the structure of a header whose command type is 'Ack'.
8 is an exemplary diagram showing the structure of a header whose command type is 'Data'.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily understand the technical matters of the present invention. In the preferred embodiment of the present invention described below, specific technical terms are used for clarity of content. The invention, however, is not limited to the particular term selected, and it is to be understood that each specific term includes all technical synonyms that operate in a similar manner to achieve a similar purpose.

1 is a block diagram showing a configuration of a communication system including an interface device for communication between processors according to a preferred embodiment of the present invention.

As shown in FIG. 1, a first processor such as a host processor HP and a second processor such as a multimedia processor MP may communicate with each other. The multimedia processor MP is a sub-processor interworking with the host processor HP, which is only an example of the embodiment and is not limited thereto.

The host processor HP may include an application thread 1 for performing a function of a host and a first interface module 2 for communicating with a multimedia processor MP. The multimedia processor MP may include an application thread 4 for performing multimedia functions and a second interface module 3 for communicating with the host processor HP based on a command of a host processor HP which is a main processor. Can be.

The first interface module 2 may be located between the application thread 1 of the host processor HP and the hardware from a layer perspective, for example, the number of threads executed by the host processor HP. have. The first interface module 2 may process data transmission and reception with the multimedia processor MP while interworking with the application thread 1 of the upper layer host processor HP and the hardware of the lower layer host processor HP. have.

The second interface module 3 may be located between the application thread 4 and the hardware of the multimedia processor MP in a hierarchical sense, and may be a thread executed by the multimedia processor MP, for example. have. The second interface module 3 may process data transmission / reception with the host processor HP while interworking with the application thread 4 of the upper layer multimedia processor MP and the hardware of the lower layer multimedia processor MP. have.

The first interface module 2 and the second interface module 3 may have the same configuration. That is, the software interface configuration for communication between the host processor HP and its subprocessor, the multimedia processor MP, is identical, symmetrical, and standardized.

Hereinafter, a detailed configuration and operation of an interface device for communication between processors according to a preferred embodiment of the present invention will be described. The interface device described below may be equally applied to the first interface module 2 and the second interface module 3.

2 is a block diagram illustrating a configuration of an interface device for communication between processors according to a preferred embodiment of the present invention. 3 is an exemplary diagram for describing an operating principle of the interface device shown in FIG. 2.

2 to 3, an interface device (hereinafter, abbreviated as interface device) 10 for communication between processors according to a preferred embodiment of the present invention is a higher thread 5, for example, an application thread and lower layer hardware. It can be implemented in the form of a thread executed in between. The interface device 10 may include a first layer L1, a second layer L2, and a third layer L3.

The first layer L1 may mean an upper access layer for performing access to an upper layer. The first layer L1 may include a plurality of application program interfaces (APIs) for interworking the upper thread 5 and the second layer L2. The API may perform a predetermined function as a dedicated API used in the interface apparatus 10. For example, the first layer L1 may include a Send API 22, a Resend API 24, a Receive API 26, and the like.

The transmission API 22 receives a transmission request message requesting data transmission from the upper thread 5 to the counterpart processor, determines whether or not the requested data transmission is possible according to the logical channel state of the hardware channel. According to the result of the determination, the second layer L2 may request to perform the requested data transmission or request to temporarily store the data transmission related information.

For example, the transmission API 22 requests the channel state manager 60 of the second layer L2 after receiving a transmission request message for requesting data transmission from the upper thread 5 to the counterpart processor. After receiving a response by querying a logical channel state of a hardware channel to which the data is to be transmitted, it may be determined whether the requested data transmission is possible based on the response.

The logical channel state of the hardware channel may be any one of a standby state, an active state, and a sleep state. The standby state is a state indicating that a hardware channel is already reserved, and the active state is a state indicating that data is being transmitted or received through the hardware channel. In addition, the sleep state is a state indicating that a hardware channel is not reserved or used.

The transmission API 22 may determine that the requested data transmission is possible when the logical channel state of the current hardware channel is in the sleep state in the response received from the channel state manager 60, while the logical channel of the current hardware channel is available. If the state is a standby state or an active state, it may be determined that the requested data transmission is currently impossible.

As a result of this determination, if the requested data transmission is currently available, the transmission API 22 may send a request indicating to perform the requested data transmission to the channel manager 40 of the second layer L2. On the other hand, if the requested data transmission is currently impossible, the transmission API 22 may request the buffer manager 30 of the second layer L2 to temporarily store the information related to the requested data transmission.

When the retransmission API 24 requests the transmission API 22 to temporarily store information related to the requested data transmission, the logical channel state is changed to a state in which data transmission is possible or a predetermined time has elapsed. It may perform a function of requesting again to the channel manager 40 of the second layer (L2) that has not been performed.

For example, the retransmission API 24 requests the buffer manager 30 to temporarily store the information related to the requested data transmission after the transmission API 22 requests the logical state of the hardware channel from the channel state manager 60. When the channel state receives information indicating that the channel state has changed to a state in which data can be transmitted, for example, a sleep state, or when a predetermined time elapses, the channel manager 40 transmits the information related to the data transmission related information temporarily stored in the buffer manager 30. Accordingly, a request may be sent to perform data transmission.

The reception API 26 may perform a function of notifying the upper thread 5 when the information indicating that the data of the counterpart processor is received from the second layer L2 is received. For example, the reception API 26 may receive information indicating that the data of the counterpart processor has been received from the channel manager 40 of the second layer, and transmit the related information of the received data to the upper thread 5. Can be.

Meanwhile, the second layer L2 may be a logical layer that is a lower layer of the first layer L1. The second layer (L2) manages the logical channel state and the physical channel state of the hardware channel for communication with the counterpart processor, and the data with the counterpart processor based on the logical channel state and the physical channel state. Function to handle transmission and reception.

The second layer L2 includes a buffer manager 30, a channel manager 40, a channel transfer manager 50, and a channel status manager 60. ), A header maker 70, a header parser 80, and the like.

The buffer manager 30 may perform a function of storing data transmission related information according to a request of the transport API 22 of the first layer L1. The buffer manager 30 may include a queue 32 for storing data. When the buffer manager 30 receives a request for temporarily storing information related to data transmission from the transmission API 22, the buffer manager 30 may store the information related to the data transmission in an internal queue 32. Stored data transmission related information may be used in retransmission.

The channel manager 40 logically manages hardware channels, and requests, cancels, opens, writes, reads, and closes the hardware channels. It can perform a function of requesting a transmission manager. Such a channel manager 40 is, for example, a request API (Request API) 41, a Cancel API (Cancel API) 42, an Open API 43, a Write API 44, a lead. Read API (API) 45, Close API (Close API) and the like. The APIs are used in the interface module 10 and may each perform unique functions.

The request API 41 channel-transmits a request to reserve a hardware channel in order to transmit or receive data according to a request from the transport API 22, the retransmission API 24, or the counterpart processor of the first layer L1. A function of transmitting to the manager 50 may be performed. The cancellation API 42 may transmit a request for canceling a reservation for a reserved hardware channel to the channel transmission manager 50. The open API 43 may perform a function of transmitting a request for opening a hardware channel to the channel transfer manager 50. The write API 44 may perform a function of transmitting a request to the channel transmission manager 50 to transmit data to the counterpart processor through an open hardware channel. The read API 45 may transmit a request to the channel transfer manager 50 to request to receive data from the counterpart processor through the opened hardware channel. The close API 46 may perform a function of transmitting a request to the channel transfer manager 50 to close the open hardware channel.

Meanwhile, the channel manager 40 may logically manage the hardware channel, monitor the logical channel state of the hardware channel, and report it to the channel state manager 60. The logical channel state of the hardware channel may be any one of a standby state, an active state, and a sleep state. As mentioned earlier, the standby state indicates that the hardware channel is already reserved, the active state indicates that data is being sent or received through the hardware channel, and the sleep state indicates that the hardware channel is not reserved or in use. It may mean a state indicating no.

The operation of the channel manager 40 will be described in connection with the operation of APIs of the channel manager 40. When the hardware channel is in the sleep state, when a request for requesting data transmission is received from the first layer L1, the request API 41 of the channel manager 40 reserves a hardware channel with the channel transmission manager 50. You can ask. In response, if the hardware channel is reserved, the hardware channel transitions to the standby state. At this time, the channel manager 40 reports to the channel state manager 60 that the hardware channel has transitioned to the standby state.

The open API 43 of the channel manager 40 may then send a request to the channel transfer manager 50 to open the reserved hardware channel. When the hardware channel is open, the hardware channel transitions to the active state. At this time, the channel manager 40 reports to the channel state manager 60 that the hardware channel has transitioned to the active state. Next, the write API 44 of the channel manager 40 may request to transmit data to the channel transfer manager 50.

When the transmission of data is complete, the close API 46 of the channel manager 40 may request the channel transfer manager 50 to close the hardware channel. Accordingly, when the hardware channel is closed, the hardware channel transitions to the sleep state. At this time, the channel manager 40 reports to the channel state manager 60 that the hardware channel has transitioned to the sleep state.

On the other hand, if the hardware channel is reserved, if information is received from the outside that the requested data transmission is not normally performed due to a failure, etc., the cancellation API 42 of the channel manager 40 is reserved for the hardware channel. A message requesting the cancellation of the message may be transmitted to the channel transmission manager 50. If the reservation of the hardware channel is canceled, the channel manager 40 may report to the channel state manager 60 that the hardware channel has transitioned to the sleep state.

The channel transmission manager 50 may perform a function of transmitting a message for controlling the operation of the hardware channel to the third layer L3 according to a request from the channel manager 50. That is, the channel transfer manager 50 may substantially perform a function of controlling the operation of the hardware channel. For example, the channel transfer manager 50 may control access, release, data transmission, and reception of the hardware channel.

The channel transmission manager 50 may support a transmission scheme through hardware channels of the first mode and the second mode. The first mode may mean, for example, a master mode that transmits and receives data through a hardware channel through which a register can be directly accessed to write or read data by directly accessing a memory of a counterpart processor. The second mode may refer to, for example, a FIFO mode for transmitting and receiving data through a hardware channel using a first in first out (FIFO) provided in an interface port of a transmitting processor.

FIG. 4 is a block diagram illustrating a hardware structure related to an interface between a host processor and a multimedia processor, and illustrates an example of a first mode and a second mode supported by the channel transmission manager 50.

Referring to FIG. 4, the multimedia processor MP may include, as hardware, an interface port 6 for connecting with a host processor HP. The interface port 6 may include a transmission / reception port 7, a register 8, a FIFO 9, and the like.

In the first mode, the host processor HP may access the memory inside the multimedia processor MP, for example the SDRAM 10, to read or write data by setting the registers of the register section 8 of the multimedia processor MP. Can be. On the other hand, the second mode utilizes the FIFO. For example, the multimedia processor MP loads data to be transmitted in the FIFO 9 for data transmission and transmits an event to the host processor HP indicating that data is to be transmitted. Then, the host processor HP approaches the FIFO 9 and takes the data loaded in the FIFO 9.

The channel transfer manager 50 may monitor the physical state of the hardware channel and report it to the channel state manager 60. The physical state of the hardware channel may include, for example, an open state, a closed state, a master transfer state, a master receive state, a FIFO transfer state, and a FIFO reception state. Receive) may be included.

The open state may indicate that a hardware channel for communication is physically open. The closed state may indicate that the hardware channel is physically closed. The master transmission state may indicate that data is transmitted in a hardware channel of a first mode. The master reception state may indicate that data is received in the hardware channel of the first mode. The FIFO transmission state may indicate that data is transmitted in a hardware channel of a second mode. The FIFO reception state may indicate that data is received in a hardware channel of a second mode.

Meanwhile, the channel state manager 60 may manage the logical channel state and the physical channel state of the hardware channel in cooperation with the channel manager 40 and the channel transfer manager 50. For example, the channel state manager 60 receives a logical channel state of a hardware channel from the channel manager 40 and manages the information. In addition, the channel state manager 60 may manage the information after receiving the physical state of the hardware channel from the channel transfer manager 50. The channel state manager 60 may provide logical channel information according to a request from the outside, for example, a request from the transport API 22 or the retransmission API 24 of the first layer L1.

The header generator may perform a function of generating a header of a predetermined standard including information and a command for setting a hardware channel to transmit data to the data. The header parser may parse a header or the like from the received data and analyze the information.

5 is an exemplary diagram illustrating tables for explaining information inserted into a header generated by a header generator.

As shown in FIG. 5, information such as a command type, a channel number, an ARQ request, an option, and the like may be inserted into a header generated by the header generator.

The command type is information for identifying the type of the command, and may be set to 'Control', 'Data', 'Ack', and the like as shown in Table 1 (T1) of FIG. 5. 'Control' indicates a control command, 'Data' means a command indicating the completion of the transmission, 'Ack' may mean a command indicating that the command has been normally received from the sender.

The channel number is information for designating the type of the FIFO channel, and may be set to "FIFO 0, FIFO 1, FIFO 2 ', etc., for example, as shown in Table 2 (T2) of FIG. Is information for specifying whether to request an ARQ indicating that data has been normally received from the other party of the ARQ. For example, as shown in Table 3 (T3) of FIG. None ARQ 'or' ARQ Request 'to request the receiver to send ARQ, etc. The option is information about additional contents, for example, an error code or the like as Table 4 (T4) of FIG. It may be set to information for conveying channel status and the like.

6, 7 and 8 are exemplary views showing the structure of a header having a command type of 'Control', a header having a command type of 'Ack' and a header having a command type of 'Data', respectively.

As shown in FIG. 6, a header having a command type of 'Control' may be, for example, a 1-bit field into which 1-bit ARQ request can be inserted and a 5-bit field into which a serial number S / N can be inserted. , A 2-bit field into which a channel number can be inserted, and a 6-bit field into which a control command can be inserted. The serial number is for assigning a sequential unique number each time a command is transmitted. For example, the serial number may be information that increases by a specific number (eg, '1') each time the command is transmitted.

Referring to FIG. 7, a header having a command type of 'Ack' may include, for example, a 1-bit field into which a 1-bit ARQ request can be inserted, a 5-bit field into which a serial number can be inserted, and an option into which a header can be inserted. Field and the like. Meanwhile, referring to FIG. 8, a header having a command type of 'Data' may be, for example, a 1-bit field into which a 1-bit ARQ request may be inserted and a 5-bit field into which a serial number S / N may be inserted. , A 2-bit field into which a channel number can be inserted.

Meanwhile, the third layer L3 is a lower layer of the second layer L2 and may perform a function of interworking the hardware resources of the interface module 10 and the processor based on the control by the second layer L2. have. The third layer L3 may include a hardware interface unit 90. The hardware interface unit 90 may include a plurality of hardware interface APIs for accessing hardware resources.

While the present invention has been described above by way of example thereof, those skilled in the art will variously modify and change the present invention without departing from the technical matters and scope of the present invention as set forth in the claims below. It will be understood that it can be done. Accordingly, modifications to future embodiments of the present invention will not depart from the technology of the present invention.

L1: first layer
L2: second layer
L3: third tier
10: interface module
22: transfer API (Application Program Interface)
24: Retransmission API
26: Receive API
30: buffer manager
40: channel manager
50: channel transfer manager
60: channel status manager
70: header constructor
80: header parser
90: hardware interface unit

Claims (16)

An interface device provided in a processor for communication with a partner processor,
A first layer having at least one API (Application Program Interface) for interworking an upper thread with the interface device;
As a lower layer of the first layer, a logical channel state and a physical channel state of a hardware channel for communication with a counterpart processor are managed, and based on the logical channel state and the physical channel state, A second layer for processing data transmission and reception; And
A lower layer of the second layer, the processor comprising a third layer having at least one hardware interface API for interworking the hardware of the interface device and the processor based on control by the second layer; Interface device for communication between.
The at least one API of the first layer is
Receiving a transmission request message requesting data transmission from the upper thread to the counterpart processor, and determining whether the requested data transmission is currently possible based on the logical channel state managed by the second layer; A transmission API for requesting to perform the requested data transmission to the second layer if the requested data transmission is currently possible; And
And a reception API that transmits the information of the received data to the upper thread when the information indicating that the data of the counterpart processor has been received from the second layer is included.
The method of claim 2, wherein the transmission API requests to temporarily store information related to the data transmission to the second layer when the requested data transmission is currently impossible,
The first layer is,
After requesting the temporary storage, when the requested data transmission becomes a possible channel state based on the logical channel state or when a preset time elapses, the temporary storage data is transmitted according to the information related to the temporary stored data transmission to the second layer. And a retransmission API for requesting to perform data transmission.
The method of claim 1, wherein the second layer,
A plurality of APIs for logically managing the hardware channel and for requesting, canceling, opening, writing, reading, and closing the hardware channel. A channel manager having a;
A channel transfer manager for transmitting a message to the third layer to control an operation of the hardware channel in response to a request from the channel manager; And
And a channel state manager for managing a logical channel state and a physical channel state of the hardware channel in association with the channel manager and the channel transfer manager.
The method of claim 4, wherein the plurality of APIs provided in the channel manager
A requesting API for requesting a channel transmission manager to make a reservation for the hardware channel in order to transmit or receive data in response to a request from the first layer or the counterpart processor;
A cancellation API for sending a request to the channel transfer manager to request to cancel the reservation for the reserved hardware channel;
An open API for sending a request to the channel transfer manager to request to open the hardware channel;
A write API for transmitting a request to the channel transfer manager requesting to transmit data to the counterpart processor through the opened hardware channel;
A read API for transmitting a request to the channel transfer manager to request to receive data from the counterpart processor through the open hardware channel; And
And a closed API for transmitting a request to the channel transfer manager to close the open hardware channel.
The method of claim 4, wherein the logical channel state,
A standby state indicating that the hardware channel is reserved;
An active state indicating that data is being transmitted or received via the hardware channel; And
And a sleep state indicating that the hardware channel is available for use.
7. The interface device of claim 6, wherein the channel manager reports the logical channel state of the hardware channel to the channel state manager.
The method of claim 4, wherein the second layer,
And a buffer manager for storing information related to the data transmission in an internal queue when receiving a request for temporarily storing information related to the data transmission from the first layer. Device.
The method of claim 4, wherein the second layer,
A header generator for generating a header of a predetermined standard including information and adding a command for setting the hardware channel to data; And
A header parser for parsing a header of data received from the hardware channel and transmitting the header to the channel manager;
And the header includes any one of control information, transmission completion information, and reception completion information.
A first processor and a second processor,
The first processor has a first interface module for communicating with the second processor via a hardware channel, and the second processor has a second interface module for communicating with the first processor via the hardware channel; ,
The first interface module,
A first layer having at least one application program interface (API) for interworking the application thread of the first processor and the first interface module;
As a lower layer of the first layer, the logical channel state and the physical channel state of the hardware channel is managed, and the data transmission and reception with the second processor based on the logical channel state and the physical channel state Second layer; And
A lower layer of the second layer, the third layer having at least one hardware interface API for interworking hardware of the first interface module and the first processor based on control by the second layer; Characterized by a communication system.
The communication system of claim 10, wherein the second interface module has a configuration corresponding to the first interface module.
The method of claim 10, wherein the at least one API of the first layer is
Receives a transmission request message requesting data transmission from the application thread to the second processor, and determines whether the requested data transmission is currently possible based on the logical channel state managed by the second layer. A transmission API for requesting to perform the requested data transmission to the second layer if the requested data transmission is currently possible; And
And a receiving API that transmits the information of the received data to the application thread when the information indicating that the data of the second processor is received from the second layer is received.
The method of claim 12, wherein the transmission API requests to temporarily store information related to the data transmission to the second layer when the requested data transmission is currently impossible,
The first layer is,
After requesting the temporary storage, when the requested data transmission becomes a possible channel state based on the logical channel state or when a preset time elapses, the temporary storage data is transmitted according to the information related to the temporary stored data transmission to the second layer. And a retransmission API requesting to perform data transmission.
The method of claim 10, wherein the second layer,
A plurality of APIs for logically managing the hardware channel and for requesting, canceling, opening, writing, reading, and closing the hardware channel. A channel manager having a;
A channel transfer manager for transmitting a message to the third layer to control an operation of the hardware channel in response to a request from the channel manager; And
And a channel state manager managing the logical channel state and the physical channel state of the hardware channel in association with the channel manager and the channel transfer manager.
15. The system of claim 14, wherein the logical channel state is:
A standby state indicating that the hardware channel is reserved;
An active state indicating that data is being transmitted or received via the hardware channel; And
And a sleep state indicating that the hardware channel is available for use.
The method of claim 14, wherein the second layer,
A buffer manager for storing information related to the data transmission in an internal queue when receiving a request for temporarily storing information related to data transmission from the first layer;
A header generator for generating a header of a predetermined standard including information and adding a command for setting the hardware channel to data; And
And a header parser for parsing a header of data received from the hardware channel and transmitting the header to the channel manager.

Images