Method, apparatus and system for transmitting and receiving data via serial asynchronous interface
By using binary protocol mode and full duplex operation in the asynchronous serial interface, synchronization problems are solved, data transmission efficiency is improved, and higher throughput and lower latency is achieved.
Patent Information
- Application Number
- CN202410892124.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-07-05
- Filing Date
- 2024-07-04
- Publication Date
- 2025-01-07
AI Technical Summary
The low throughput caused by synchronization problems during data exchange is particularly insufficient compared with high data rate communication technologies such as WiFi or Ethernet, and is prone to become a communication bottleneck.
By using a binary receive/send protocol mode between switching between receiving and sending data, synchronous data transmission with binary header and length indication, eliminating the wait state, and achieving full duplex operation to improve throughput.
It effectively improves the data transmission throughput of the serial asynchronous interface, reduces the waiting state, optimizes the data exchange efficiency, and avoids delays caused by resynchronization.
Smart Images

Figure CN119276415A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of communication, and in particular to data exchange, that is, sending and receiving data via an interface. Specifically, the present disclosure relates to a method for sending data via a serial asynchronous interface, a method, device and system for receiving data via a serial asynchronous interface. Background Art
[0002] In the field of data exchange between different devices, communication protocols are used to enable the devices involved to communicate with each other. An interface providing access to such a protocol is usually defined, thereby freeing the devices involved from the burden of knowing all the details defined in the protocol. A well-known example of such an interface is the so-called socket interface, which provides access to the transmission control protocol TCP, the Internet protocol IP, the user datagram protocol UDP, a protocol implementation (also called TCP / IP or UDP / IP protocol stack). Interfaces are used within a device for exchanging data between different modules or entities, such as a protocol stack or a radio frequency transmitter-receiver module.
[0003] The interface may be implemented as a serial or parallel interface and may operate synchronously or asynchronously. This description focuses on interfaces that exchange data in a serial, asynchronous manner (ie, without using a clock signal shared between the participating senders and receivers).
[0004] Additionally, interfaces can be implemented as text-based interfaces, which are controlled by readable text or strings. Another type of interface is implemented as a binary interface that accepts and provides binary data. This description relates to the text-based interface type.
[0005] A well-known and widely implemented text-based asynchronous serial interface is the AT command set, sometimes referred to as the Hayes AT command set. The AT command set is hailed as a de facto standard in communications. The AT command set used today is derived from the Hayes AT command set or the Modem Attention Command Set, which was developed by Hayes for telephone modems. Prior art implementations of the AT command set interface are also used to provide access to TCP / UDP / IP sockets.
[0006] Unfortunately, during the data exchange process, known asynchronous serial interfaces often suffer from low throughput caused by wait states caused by the inevitable synchronization between the sender and the receiver (e.g., the host and the module). In detail, the host (e.g., the entity using the communication function) and the module (e.g., the entity providing the communication function) should be synchronized before sending data. To this end, the reception of commands and / or data is actively confirmed. In detail, it may be necessary to indicate to the host or module when data has been received and the module or host can transmit other data. If the host or module runs out of memory, the transmission must be interrupted. An established solution to these problems is, for example, to use a flow control mechanism. Specifically, the host can issue a command to inquire how much data the module can accept, however, this introduces more wait states. Or the host can send data without knowing the amount of data that the module can accept, which may lead to a complete pause of the entire communication channel if the module runs out of memory, or in the worst case may lead to data loss and mean retransmission. In any case, the resulting throughput through the interface is not satisfactory low, especially when compared with the data rate and corresponding throughput achieved by communication technologies such as WiFi or Ethernet that can be controlled via such an interface. The interface can even end up being a bottleneck in this type of communication.
[0007] Therefore, an object may be seen in providing a method, device and system that overcomes the disadvantages of the prior art. In particular, a solution to increase throughput on a serial asynchronous interface is to be provided.
[0008] Unless stated otherwise, the definitions provided above also apply to the following description. Summary of the invention
[0009] In one embodiment, a method for sending data via a serial asynchronous interface comprises the following steps:
[0010] To operate the device in text-based receive protocol mode,
[0011] receiving, by the device while operating in a text-based receive protocol mode, via the interface a request message including a binary header component and a length indication,
[0012] After receiving the request message, the device enters the binary receiving protocol mode.
[0013] receiving, by the device while operating in the binary receive protocol mode, an amount of binary data, the amount being specified by the length indication of the request message,
[0014] The device exits the binary receive protocol mode.
[0015] Once the device receives a request message with a binary header component and a length indication, the device enters a binary receive protocol mode. The request message (especially the header component) indicates that the next byte sequence will be in binary mode. Based on the length indication, the module determines when to exit binary mode. Since this simple binary header is used in the request message, the wait state caused by binary synchronization that is inevitable in the prior art implementation is eliminated. Therefore, the throughput on the serial asynchronous interface is improved.
[0016] In other words, according to the specified method, the module follows a simple rule, namely, whenever a binary header is received together with a length indication in a request message, the module starts operating in a binary reception protocol mode, in which the module remains until the number of byte positions indicated in the length indication have been received. Thus, the device sending the information and its counterpart are always synchronized without any waiting state dedicated to the synchronization of the communication partner.
[0017] After exiting the binary receive protocol mode, the device again operates in the text-based receive protocol mode.
[0018] In the development of devices operating in text-based receive protocol mode, include initializing operation in binary receive protocol mode.
[0019] The text-based receiving protocol mode is characterized by receiving text messages or data, i.e., character strings, from a counterpart communicating with a module such as a host. These character strings can be formatted using the American Standard Code for Information Interchange ASCII. The conversion between the operation in the text-based receiving protocol mode and the operation in the binary receiving protocol mode is directly implemented after receiving the request message.
[0020] In development, initializing operation in the binary receive protocol mode includes receiving, by the device, at least one command message including a header and a command component. The command message complies with an AT command set.
[0021] A command message is a text message received in a text-based receive protocol mode. The command component of the message announces the subsequent arrival of a request message. As described above, the subsequent receipt of a request message results in an automatic switch to a binary receive protocol mode and immediate transmission of binary data in that mode.
[0022] In development, the method also includes the following steps:
[0023] The device sends a notification message while receiving the binary data amount, the notification message including a notification component defining a maximum amount of data that the device can receive, and
[0024] Another amount of binary data is received by the device while operating in the binary receive protocol mode. The other amount of binary data is specified by the notification component of the notification message.
[0025] The device operates in full duplex because it can simultaneously receive and send data via a serial asynchronous interface. For flow control reasons, while operating in a binary receive protocol mode and receiving binary data according to a request message, the device can send a notification message to its counterpart (e.g., a host) via the interface. The notification message is a text message. The notification message enables the direct continuation of receiving more binary data in the binary receive protocol mode. The wait state required for resynchronization for receiving a new binary data block in the prior art implementation is avoided. This further increases the throughput via the serial asynchronous interface.
[0026] Binary mode is used for each direction separately. Here, the receiving direction operates in binary mode, while the sending direction remains in text-based mode unless a request message is also received on the sending side. By having each direction controlled independently, the interface can be utilized more efficiently. This also allows sending notification messages in text-based mode that inform how much more data can be sent in the next block while it is still sending the current block.
[0027] In an improvement, the notification message also includes confirmation information, which confirms the successful receipt of the command message and the request message.
[0028] The notification message does not confirm the successful reception of the binary data. Instead, the notification message contains information about how much data the device can receive, so as to let its counterpart know whether more data can be queued and sent directly after the current amount of binary data during the exchange of the current amount of binary data.
[0029] In development, immediately after receiving another amount of binary data while the device is operating in the binary receive protocol mode, the method further comprises the following steps:
[0030] The device enters a text-based receive protocol mode, and
[0031] Another command message including a header component and a command component is received by the device while operating in the text-based receive protocol mode.
[0032] The further command message also complies with the AT command set. In particular, the header component is represented by AT and the command component is represented by SEND. In the case where the maximum amount of data indicated by the notification message has not been completely exhausted after receiving the further amount of binary data, the further command message is directly transmitted to the module and received by the module. This eliminates the other waiting states required for resynchronizing the host and the device in the prior art implementation. The throughput via the serial asynchronous interface is further optimized.
[0033] In one embodiment, a method for receiving data via a serial asynchronous interface includes the following steps: operating a device in a text-based transmission protocol mode; sending a request message including a binary header component and a length indication via the interface while the device is operating in the text-based transmission protocol mode; the device enters a binary transmission protocol mode; sending an amount of binary data while the device is operating in the binary transmission protocol mode, the amount being specified by the length indication of the request message; and the device exits the binary transmission protocol mode.
[0034] By means of request messages, a synchronous switch between a text-based transmission protocol mode and a binary transmission protocol mode is achieved. In this case, the module is sending binary data and the transmission is notified with a request message. The amount of binary data is sent directly after the request message is sent, thereby reducing the wait states otherwise required for synchronizing the sender and the receiver or the module and the host, as in this embodiment. Thus, when compared to the prior art implementation of a text-based protocol for exchanging data via a serial asynchronous interface, the throughput is improved.
[0035] After exiting the binary transmit protocol mode, the device again operates in the text-based transmit protocol mode.
[0036] In an improvement, operating the device in the text-based transmit protocol mode includes initiating operation in the binary transmit protocol mode.
[0037] In text-based send protocol mode, a switch to operation in binary send protocol mode has been initiated.
[0038] In development, initializing operation in binary send protocol mode involves the following steps:
[0039] receiving, by the device, at least one command message including a header component, a command component, and a first length indication, wherein the command message complies with the AT command set and the command component triggers subsequent sending of the request message; and
[0040] An acknowledgement message is sent by the device, the acknowledgement message acknowledging receipt of the command message and including a second length indication.
[0041] In this development, the initialization of the switch from the text-based to the binary transmission protocol mode is triggered by the counterpart of the device, so that the device receives a command message. The command message indicates the willingness of the counterpart to read data from the serial asynchronous interface. The first length indication indicates the amount of data that the counterpart wishes to receive. Then, the device sends a confirmation message and notifies how much data is available by means of the second length indication. Therein, the first length indication and the second length indication can have different values. Both the command message and the confirmation message are text messages.
[0042] In an improvement, the method further comprises the following steps while the device sends the binary data volume:
[0043] receiving, by the device, another command message comprising a header component, a command component and another length indication,
[0044] The device continues to send binary data according to another length indication of the another command message in the binary sending protocol mode.
[0045] Since the serial asynchronous interface is a full-duplex interface, the device is able to simultaneously send and receive messages and data through the interface. In particular, as described, while sending binary data in the binary send protocol mode, the device receives another command message, which notifies the counterpart of the willingness to receive more binary data, the amount of which is indicated in another length indication. Therefore, the device can directly continue to send more binary data without any resynchronization, which leads to a further improvement in throughput.
[0046] In an alternative development, operations in initializing binary send protocol mode include:
[0047] A trigger message is sent by the device including an indication of the amount of available binary data.
[0048] In this alternative, the switch from text-based to binary send protocol mode is initiated by the device by sending a trigger message. The trigger message can be sent spontaneously at any time (e.g., once the device receives data, e.g., from a TCP / IP protocol stack). After sending the trigger message as a text message, a request message is directly sent and the switch to binary send protocol mode is made. Data can be sent without any wait states, thereby optimizing the throughput via the serial asynchronous interface.
[0049] In development, the binary header component of the request message includes predefined characters.
[0050] The predefined characters are unique and the same for each request message used in different embodiments of the methods described herein.The characters used for the header component of the request message are predefined so that the device and its counterpart can clearly identify the request message.
[0051] In one embodiment, the device comprises means configured to perform the method of sending data via a serial asynchronous interface and / or means configured to perform the method of receiving data via a serial asynchronous interface and a serial asynchronous interface as defined above.
[0052] By implementing one or both of the above methods, the device achieves higher throughput via the serial asynchronous interface compared to prior art implementations by eliminating wait states.
[0053] In development, the device is implemented as an integrated module that also includes hardware and software components for implementing the communication functions. The communication functions are configured to be controlled via a serial asynchronous interface.
[0054] The communication functions include wired and wireless communication functions, for example, wired and wireless communication functions according to one or more of wireless LAN WLAN, Bluetooth BT, Bluetooth low energy BLE, ultra-wideband UWB, Ethernet according to IEEE 802.11x, the third generation partnership project 3GPP, compatible mobile communications, each of which is implemented as known to those skilled in the art. The serial asynchronous interface can be implemented as a universal asynchronous receive and transmit UART interface. The interface is used to control the communication functions without having to know all the details of each and every function.
[0055] In one embodiment, a system comprises a device as described above and a host device comprising a serial asynchronous interface, the serial asynchronous interface of the host device being coupled to the serial asynchronous interface of the device. The host device is configured to communicate with the device via the serial asynchronous interface.
[0056] The system can be implemented, for example, on a microcontroller. The host device and the device communicate and exchange data using a serial asynchronous interface. In this communication, the above method is used to optimize the throughput via the interface. BRIEF DESCRIPTION OF THE DRAWINGS
[0057] The proposed solution is explained in detail below using exemplary embodiments with reference to the accompanying drawings. Components and elements having the same function or having the same effect have the same reference numerals. In the case where parts or components correspond to one another in their function, their description will not be repeated in the following figures. In them,
[0058] Figure 1 shows an implementation example of the proposed method for sending data via a serial asynchronous interface,
[0059] Figure 2 shows an implementation example of the proposed method for receiving data via a serial asynchronous interface,
[0060] Figure 3 shows an example of implementation of the proposed device and system,
[0061] Figure 4 shows an exemplary message flow of the proposed method for sending data via a serial asynchronous interface,
[0062] Figure 5 An exemplary message flow showing the proposed method of receiving data via a serial asynchronous interface, and
[0063] Figure 6 Another exemplary message flow of the proposed method for receiving data via a serial asynchronous interface is shown.
[0064] Reference numerals
[0065] 10. Equipment
[0066] 20 Host device
[0067] 30 Systems
[0068] 11, 21 Interface
[0069] 12 Communication Function
[0070] Steps S10, S11, S12, S13, S14, S15, S16
[0071] Steps S20, S21, S22, S23, S24, S25, S26
[0072] Rq, Nf, Cd1a, Cd1b, Cd2a, Cd2b messages
[0073] Cf1, Cf2, Tr1, Tr2 messages
[0074] D Data
[0075] G1, G2 Clearance DETAILED DESCRIPTION
[0076] Figure 1 An exemplary embodiment of the proposed method for sending data via a serial asynchronous interface is shown. The method comprises the following steps:
[0077] S10: Operate the device in text-based receive protocol mode,
[0078] S12: receiving, by the device while operating in a text-based reception protocol mode, via the interface a request message comprising a binary header component and a length indication,
[0079] S13: After receiving the request message, the device enters a binary receiving protocol mode.
[0080] S14: receiving, by the device while operating in the binary reception protocol mode, an amount of binary data, and
[0081] S15: The device exits the binary receiving protocol mode.
[0082] The device receives data sent or transmitted from a counterpart. The device switches between a text-based reception protocol mode and a binary reception protocol mode. Once the device receives a request message in step S12, it enters a binary mode in step S13 and directly starts receiving a binary data amount in step S14, which has been indicated by the length indication of the request message. Since the device is synchronized with the transmitting counterpart by means of the request message in step S12, the wait states necessary in the prior art implementation of a text-based serial asynchronous interface are reduced. This results in an improved throughput.
[0083] Optionally, the method further comprises step S11:
[0084] The device initiates operation in Binary Receive Protocol mode.
[0085] Optionally, the method may further include step S16:
[0086] A notification message is sent by the device while receiving the amount of binary data, the notification message including a notification component defining a maximum amount of data that the device can receive.
[0087] The notification message is sent as a text message using the full-duplex function of the serial asynchronous interface. The notification message may also include confirmation information, which confirms the successful reception of the command message of step S11 and the request message of step S12. Figure 1 As shown, step S16 is executed simultaneously with steps S13, S14 and S15.
[0088] Figure 2 An exemplary embodiment of the proposed method for receiving data via a serial asynchronous interface is shown. The method comprises the following steps:
[0089] S20: Operate the device in text-based send protocol mode,
[0090] S22: sending, by the device while operating in the text-based transmission protocol mode, via the interface a request message including a binary header component and a length indication,
[0091] S23: The device enters a binary transmission protocol mode,
[0092] S24: sending, by the device while operating in a binary send protocol mode, an amount of binary data, the amount being specified by a length indication of the request message, and
[0093] S25: The device exits the binary sending protocol mode.
[0094] In this embodiment, the device sends data to a counterpart (e.g., a host) via an interface to receive the data. To this end, the device switches between a text-based transmission protocol mode and a binary transmission protocol mode. The switching is improved by introducing a request message with a binary header component with predefined characters and a length indication. The request message enables synchronization between the device and its counterpart. Therefore, the transmission of binary data can be started immediately after sending the request message. Waiting states for synchronization between the device and its counterpart are eliminated, and the throughput on the interface is increased.
[0095] Optionally, the method further comprises step S21:
[0096] Initialize operation in binary send protocol mode. This step can be implemented in two alternative ways.
[0097] According to a first alternative, step S21 may comprise receiving, by the device, at least one command message comprising a header component, a command component and a first length indication, and sending, by the device, an acknowledgement message acknowledging receipt of the command message and comprising a second length indication.
[0098] According to a first alternative, the initialization of the operation in the binary transmission protocol mode is prompted by the communication partner of the device, so that the device receives a command message indicating that the communication partner is ready to receive data according to the amount defined in the first length indication. The device responds with a confirmation message and notifies the amount of data available for transmission with a second length indication.
[0099] According to a second alternative, the device itself initializes operation in the binary send protocol mode by sending a trigger message comprising an indication of the amount of available binary data.
[0100] Optionally, the method may further include step S26: receiving, by the device, another command message including a header component, a command component and another length indication. This step is performed while the device sends the binary data amount in step S24. The device continues to send the binary data according to another length indication of the other command message in the binary send protocol mode.
[0101] By separating the actual data transfer from the command, the device is able to receive a new command message while the last data is currently being sent in binary mode. This improves throughput compared to prior art implementations where once a command is issued, the host must wait for the command status (i.e., OK or ERROR) before issuing another command. Since in the proposed method the device sends an acknowledgement message before sending data in binary mode, the host is allowed to issue and execute two commands simultaneously to some extent and still comply with the rule requiring waiting for a status before the next command.
[0102] Figure 3 Exemplary embodiments of the proposed device and system are shown.
[0103] The device 10 includes a device configured to perform (for example, referring to Figure 1 ) An apparatus for transmitting data via a serial asynchronous interface as described above. Alternatively or additionally, the device 10 includes a device configured to execute (for example, referring to Figure 2 ) The apparatus of the method of receiving data via a serial asynchronous interface as described above. The device 10 also includes a serial asynchronous interface 11. The apparatus may be implemented by a microcontroller configured to run the method implemented in software or firmware.
[0104] Device 10 may be implemented as an integrated module (eg, on a single chip).
[0105] The device 10 may also include hardware and software components 12 implementing the above-mentioned communication functions. The communication functions may be controlled and accessed from outside the device via the interface 11 .
[0106] The system 30 specified herein comprises a device 10 and a host apparatus 20. The host apparatus 20 further comprises a serial asynchronous interface 21 coupled to the interface 11 of the device 10. The interface itself may be implemented as a UART. The host apparatus 20 is configured to communicate with the device 10 via the serial asynchronous interface 21.
[0107] The host device 20 implements the communication counterpart or partner of the device 10 when exchanging (i.e., sending and receiving) data via the interface. In the data exchange, the host device 20 and the device 10 take over the corresponding roles. In detail, in the case where the host device 20 has data to be sent from the system 30 to another system, which can be the proposed another system 30, or can be an Internet server or a mobile phone, the device 10 internally assumes the role of the receiving part and implements the method for sending data via the interface (such as Figure 1 The host device 20 plays the role of a sender that implements a method for receiving data via an interface (eg, referring to Figure 2 described).
[0108] In the opposite case, i.e. when data arrives from another system (e.g. another system 30 or an Internet server or a mobile phone) and is received via the component 12 for implementing the communication functions of the device 10, the device 10 internally assumes the role of the sender and implements the method for receiving data via the interface (e.g. Figure 2 Therefore, the host device 20 assumes the role of the receiver and implements a method for sending data via an interface (such as Figure 1 ).
[0109] Figure 4 An exemplary message flow according to an embodiment of the proposed method of sending data via a serial asynchronous interface is shown. Messages are described relative to time t as they are sent from the host device 20 to the device 10 or otherwise in this example. The message flow is based on an exemplary implementation using the AT command set.
[0110] At the beginning, the device 10 is in Figure 1 The text-based reception protocol mode of step S10 is initialized in the device by receiving a command message Cd1a. In an exemplary implementation using the AT command set, the command message Cd1a includes a header AT followed by a command component which is the name of the command (here the string SEND). This corresponds to Figure 1 Step S11.
[0111] Next, the device 10 receives a request message Rq, which includes a binary header component (here called SOF) and a length indication marked with LEN. This corresponds to step S12. By means of this request message Rq, the module or device 10 and the host device 20 are synchronized for the subsequent data transmission. Therefore, after sending the request message Rq, the host device 20 can immediately start sending the binary data D. After receiving the request message Rq, the device 10 switches to the binary reception protocol mode, as shown in FIG. Figure 1Step S13. The request message Rq is received by the device 10 after a gap G1, which corresponds to the time taken for the device 10 to detect that the last byte of the request message Rq has been received. This time may also be referred to as the device reception waiting time.
[0112] In accordance with Figure 1 While receiving the binary data volume D in step S14, the device 10 may Figure 1 Step S16 sends a notification message Nf. The notification message Nf includes a notification component (here + DATA: <avail>) to inform the host device 20 about the maximum amount of data that the device 10 can receive. The notification message Nf may also include confirmation information (here OK) that confirms the successful reception of the command message Cd1a and the request message Rq. The notification message Nf is received by the host device 20 after another gap G2, which is equivalent to the time taken for the host device 20 to detect that the last byte of the notification message Nf has been received. The time gap G2 is also called the host device reception waiting time. Then, because the host device 20 knows from the notification message Nf how much data the device 10 can receive, the host can schedule another data block and directly send the next data block before the first data block is completely sent.
[0113] After having received the first binary data block and the optional second binary data block, the device Figure 1 Step S16 switches to the text-based reception protocol mode, and receives another command message Cd1b notifying that another request message (not shown) is subsequently sent from the host device 20.
[0114] As can be seen from the message flow, no additional waiting states are required except for the inevitable gaps G1 and G2 generated by the reception waiting times of the device 10 and the host apparatus 20, respectively.
[0115] In an exemplary scenario, the request message Rq may have a length indication of length zero. This causes the device 10 to send a notification message Nf notifying the device of the maximum amount of data that can be received. The host device 20 may then directly send the amount of data D according to the indicated maximum amount.
[0116] Figure 5 An exemplary message flow of the proposed method for receiving data via a serial asynchronous interface is shown. Also in this example, the AT command set is used to exchange data on a UART interface (as an example of a serial asynchronous interface). The different messages are shown relative to time t and are described from the perspective of transmission.
[0117] First, the device 10 is in Figure 2 The text-based transmission protocol mode of step S20 is shown in FIG. 2. The host device 20 transmits a command message Cd2a, which includes a header component (here AT), a command component (here a string RECV), and a length indication (here marked as LEN). The command message Cd2a indicates the willingness of the host device 20 to receive data.
[0118] In order to Figure 2 Step S21 further initializes the operation of the device 10 in the binary transmission protocol mode, and after receiving the command message Cd2a after the first gap G1, the device sends a confirmation message Cf1. The confirmation message Cf1 confirms the reception of the command message Cd2a (here with OK) and sends a second length indication (here +DATA: <avail>), which informs the host device 20 about the amount of data available for transfer from the device 10 to the host device 20. Figure 2 In step S22, after sending the confirmation message Cf1, the device 10 directly sends a request message Rq including a binary header component and a length indication. Then, the device 10 enters Figure 2 The binary sending protocol mode of step S23.
[0119] Next, the device 10 Figure 2 In step S24, the binary data volume D is sent. While sending the data volume D, the device 10 can Figure 2 Step S26 receives another command message Cd2b from the host device 20. The command message Cd2b corresponds to the command message Cd2a, but may have another value in the length indication. In this case, the device 10 may directly continue to send the binary data D according to the length indicated in the command message Cd2b.
[0120] It can also be determined here that, apart from the inevitable gaps G1 and G2, no other waiting states are required to keep the device 10 and the host device 20 synchronized and to send binary data.
[0121] Figure 6 Another exemplary message flow of the proposed method of receiving data via a serial asynchronous interface is shown. The messages sent by the module 10 are shown with respect to time t. In this example, an alternative way of initializing the device 10 operating in a binary transmission protocol mode is shown.
[0122] To this end, the device 10 sends a trigger message Tr1. According to the AT command set, a so-called unsolicited result code URC is used for this trigger message Tr1. The URC can be sent spontaneously at any time. The URC includes an event name (here DATA), indicating that data should be sent. In addition, with the trigger message Tr1, the amount of available binary data is indicated here by AVAIL. After sending the trigger message Tr1, the device 10 immediately sends a request message Rq and then enters the binary send protocol mode. The device 10 immediately starts sending the amount of binary data D.
[0123] After completing sending the binary data volume D, the device 10 enters a text-based sending protocol mode.
[0124] Later, the device 10 may send another trigger message Tr2 in the text-based transmission protocol mode to notify the host device 20 of the subsequent transmission of another binary data block.
[0125] For this alternative, it is assumed that the device can reuse the hardware-implemented flow control mechanism known to those skilled in the art in order to prevent potential memory overflows.
[0126] It should be understood that the present invention is not limited to the disclosed embodiments and the contents specifically shown and described above. On the contrary, the features recorded in the independent dependent claims or the specification can be advantageously combined. In addition, the scope of the present invention includes those changes and modifications that are obvious to those skilled in the art and fall within the scope of the appended claims. Exemplary names for command components, notification components, confirmation information, etc. should not be considered to limit the scope of the present invention. The term "comprising" used in the claims or the specification does not exclude other elements or steps of the corresponding features or processes. In the case where the terms "one" or "an" are used in conjunction with features, they do not exclude a plurality of such features. In addition, any figure marks in the claims should not be interpreted as limiting the scope.< / avail> < / avail>
Claims
1. A method for sending data via a serial asynchronous interface, the method comprising the following steps: operating (S10) the device in a text-based reception protocol mode, receiving (S12), by the device while operating in the text-based reception protocol mode, via the serial asynchronous interface, a request message (Rq), the request message (Rq) comprising a binary header component and a length indication, After receiving the request message, the device enters (S13) a binary receiving protocol mode, receiving (S14), by the device while operating in the binary reception protocol mode, an amount of binary data (D), the amount being specified by the length indication of the request message, The device exits (S15) the binary reception protocol mode.
2. The method according to claim 1, in, Operating (S10) the device in the text-based reception protocol mode includes initializing (S11) operation in the binary reception protocol mode.
3. The method according to claim 2, in, Initializing (S11) the operations in the binary receiving protocol mode include: receiving, by the device, at least one command message (Cd1a) comprising a header and a command component, and The command message complies with the AT command set.
4. The method according to any one of claims 1 to 3, The method further comprises: sending (S16), by the device while receiving the amount of binary data (D), a notification message (Nf), the notification message (Nf) comprising a notification component defining a maximum amount of data that the device can receive, and Another amount of binary data is received by the device while operating in the binary receive protocol mode, the another amount of binary data being specified by the notification component of the notification message.
5. The method according to claim 4, in, The notification message (Nf) also comprises confirmation information, which confirms the successful reception of the command message and the request message.
6. The method according to claim 4, Immediately after receiving, by the device while operating in the binary receive protocol mode, the further amount of binary data, the method further comprises: the device enters the text-based receive protocol mode, and Another command message (Cd1b) comprising a header component and a command component is received by the device while operating in the text-based receive protocol mode.
7. The method according to any one of claims 1 to 3, in, The binary header component of the request message (Rq) comprises predefined characters.
8. A method for receiving data via a serial asynchronous interface, the method comprising the steps of: operating (S20) the device in a text-based transmission protocol mode, sending (S22), by the device while operating in the text-based transmission protocol mode, via the serial asynchronous interface, a request message (Rq), the request message (Rq) comprising a binary header component and a length indication, The device enters (S23) a binary transmission protocol mode, sending (S24), by the device while operating in the binary send protocol mode, an amount of binary data (D), the amount being specified by the length indication of the request message, The device exits the binary send protocol mode.
9. The method according to claim 8, in, Operating the device in the text-based transmission protocol mode includes initializing (S21) operation in the binary transmission protocol mode.
10. The method according to claim 9, in, Initializing the operations in the binary sending protocol mode includes: receiving, by the device, at least one command message (Cd2a) comprising a header component, a command component and a first length indication, wherein the command message conforms to an AT command set and the command component triggers a subsequent sending of the request message, and A confirmation message (Cf1) is sent by the device, the confirmation message (Cf1) confirming receipt of the command message and comprising a second length indication.
11. The method according to any one of claims 8 to 10, The method further comprises, while the device sends the binary data volume: receiving, by the device, a further command message (Cd2b), the further command message (Cd2b) comprising a header component, a command component and a further length indication, The device continues to send binary data according to the other length indication of the other command message in the binary sending protocol mode.
12. The method according to claim 9, in, Initializing the operations in the binary sending protocol mode includes: A trigger message (Tr1) is sent by the device including an indication of the amount of available binary data.
13. The method according to any one of claims 8 to 10, in, The binary header component of the request message (Rq) comprises predefined characters.
14. A device for sending and receiving data, the device comprising: A device configured to perform the method according to any one of claims 1 to 7, and / or An apparatus configured to perform the method according to any one of claims 8 to 13, and Serial asynchronous interface.
15. The device according to claim 14, in, The device is implemented as an integrated module, which also includes hardware and software components (12) for implementing communication functions, and Wherein, the communication function is configured to be controlled via the serial asynchronous interface.
16. A system for sending and receiving data, the system comprising: The device (10) according to claim 14 or 15, and a host device (20), the host device (20) comprising a serial asynchronous interface, the serial asynchronous interface being coupled to the serial asynchronous interface of the device, Wherein, the host device is configured to communicate with the device via the serial asynchronous interface.