Not Applicable
Not Applicable
The present invention relates generally to wireless technology, and more particularly to the addition of wireless functionality to host devices.
In the course of bringing electronic products to market, original equipment manufacturers (OEMs) may wish to provide wireless functionality to devices that would otherwise require wired operation. For example, a manufacturer of probes, sensors, or other industrial data collection or control devices may desire to offer wireless versions of its products for portable, handheld use. Unfortunately, the implementation of wireless functionality can pose a significant challenge to such OEMs.
Typically, an OEM's expertise will be limited to technological fields directly relevant to its products. In the example above, the OEM may have significant experience in designing and implementing test equipment, but may not have the skills necessary to develop test equipment that utilizes wireless communication. Moreover, for such an OEM, it may be cost-prohibitive to hire the necessary talent and fund the development of a device-specific wireless solution.
Indeed, even if an OEM develops a device-specific wireless implementation, it is still important for such a device to comply with industry-standard wireless protocols in order to ensure compatibility with other wireless devices and wireless communication networks. Ad hoc designs are unlikely to offer such compatibility,
Given the complexity of modem wireless networks, it is also desirable to configure wireless devices to ensure compatibility with other equipment. Depending on the particular environment in which a wireless device is deployed, different configurations may be necessary. For an OEM, configuring such a wireless device may require reviewing and changing the wireless device software. The writing and re-writing of large amounts of software code each time the configuration changes can be a time consuming and inefficient way for OEMs, or users of their products, to update the configuration of a wireless device.
Accordingly, there exists a need for an efficient, cost-effective way to implement wireless functionality in OEM devices that are compatible with industry-standard wireless protocols. There further exists a need to configure such devices in an efficient manner. Various embodiments of the present invention are directed toward meeting these, as well as other needs.
The present invention, roughly described, is directed to a module for providing wireless functionality to a host device, and related methods for configuring the module and exchanging data with the host device.
In one embodiment, the module includes a wireless radio supporting a wireless protocol, and an antenna in communication with the radio capable of transmitting and receiving wireless signals over a wireless link. Software running on an application processor of the module facilitates data exchange between a host device and the radio by converting data between a host-oriented protocol (or other appropriate protocol) and a wireless protocol, thereby providing the host device with network connectivity. Flash memory can also be provided for storing a configuration of the module.
In various embodiments, the configuration of the module is comprised of a plurality of configuration parameters. In such embodiments, the module can be remotely configured by software running on a remote device, or by commands issued by the remote device. Alternatively, the module configuration can be changed by commands issued by a host device.
In other embodiments, the module can allow for data exchange between a remote device and a host device over a wireless link. After receiving an HTML page request from the remote device over the wireless link, the module can return an HTML page having code that is executable by the remote device. By executing the code, the remote device can issue a data request command to the module. In response, the module can pass at least a portion of the command to the host device, which can return requested data that is received by the module. The module can return the requested data to the remote device where it can be formatted and displayed on a browser.
Other data exchange methods are also provided which utilize commands issued by a host device to physical ports of the module, or by a remote device over a wireless link. Authentication can also be implemented on the module to secure against the execution of unauthorized commands issued by the host device or remote device. These and other embodiments of the present invention are discussed in further detail below.
In various embodiments of the present invention, module 120 can provide data from host 110 to remote device 170, thereby permitting host 110 to communicate wirelessly over link 135. In other embodiments, module 120 can be configured by host 110 or remotely over link 135 by remote device 170.
Host 110 can be any hardware device to which it may be desirable to add wireless functionality. For example, host 110 can be a data acquisition or control device for use with industrial, scientific, medical, and automotive (“ISMA”) applications. Other possible applications include, but are not limited to: instrumentation, factory automation, health care, building control, remote sensors, point of sale systems, and security systems. Typically, host 110 will include a processor which is capable of communicating with module 120.
Module 120 allows host 110 to communicate wirelessly with other components of the system of
Module 120 can communicate with host 110 by way of physical ports on the module 120, as further described herein. Various embodiments of module 120 can communicate with access point 150 using different wireless protocols, including IEEE 802.11 wireless standards (such as 802.11a, b, g), Bluetooth® wireless technology, a WiFi compatible protocol, a protocol complying with a ZigBee™ wireless technology, a protocol complying with an UWB (ultra wide band) wireless technology, or others known in the art. For example, when deployed for use with 802.11b networks, module 120 can provide a complete 802.11b network interface, thereby allowing host 110 to communicate wirelessly with a WiFi compatible 802.11b network. It is further contemplated that module 120 can have an IP address that is assigned a default value and/or dynamically allocated by using the dynamic host control protocol (DHCP).
There are several alternative ways in which module 120 can communicate with the various components of
Antennas 130 and 140 are capable of sending and receiving wireless communications between module 120 and access point 150 over wireless link 135 in accordance with the present invention. Access point 150 is a wireless device that serves as a bridge or router between module 120 and network 160. In order to communicate with module 120, access point 150 may also utilize any of the various wireless protocols known in the art. In one embodiment, access point 150 is a DHCP server, permitting dynamic assignment of IP addresses to module 120. It will be appreciated that wireless link 135 can be implemented as any suitable wireless network, such as a WLAN, conforming to a wireless protocol known in the art.
Network 160 can be a Local Area Network (LAN), Intranet, the Internet, and/or any other suitable network capable of exchanging electronic information between access point 150 and one or more remote devices 170 in accordance with the present invention.
As illustrated in
In one embodiment, remote device 170 is capable of running a browser application 180 which can be any software application used for communicating over the Internet. By communicating with module 120 over network 160 and wireless link 135, browser 160 can be used to access data provided by host 110 through module 120, as further described herein. In certain embodiments, browser 180 is also capable of configuring module 120, as also described herein. In another embodiment, device 170 is capable of running a user-operable configuration utility 190 for remotely configuring module 120.
When a plurality of remote devices 170 are provided as described above, module 120 can be implemented such that module 120 is capable of selectively communicating with each remote device 170, one at a time. By performing relatively brief communications between module 120 and the various remote devices 170, the appearance of simultaneous, concurrent access to module 120 and/or host 110 by such remote devices 170 can be achieved. It is further contemplated that different combinations of browser 180, utility 190, and/or other applications can be run on individual remote devices 170 of the plurality of remote devices 170. For example, it will be appreciated that browser 180, utility 190, and/or other applications need not be implemented on a single remote device 170. Rather, each can be implemented separately, or in any desired combination, on one or more remote devices 170 of the plurality of remote devices 170. It will also be appreciated that, in various embodiments, a remote device 170 can operate as a remote client or server, as appropriate.
Module 120 incorporates a wireless radio 210 supporting a wireless networking protocol. Radio 210 includes a media access control (MAC) 210a that provides for and manages all time-critical wireless media control for the module. In one embodiment, MAC 210a can be implemented on a chip, for example, the Intersil Corporation ISL 3871. It will be appreciated that other embodiments of MAC 210a are also contemplated in accordance with the present invention.
Radio 210 also includes a baseband RF block 210b for providing all appropriate baseband signal processing as well as appropriate RF modulation for wireless communication between module 120 and access point 150. In one embodiment, baseband RF 210b can be implemented on a chip, for example, the Intersil Corporation ISL 3684. It will be appreciated that other embodiments of baseband RF 210b are also contemplated in accordance with the present invention.
Radio 210 further includes preamplifier 210c and power amplifier 210d for amplifying signals received by and transmitted from module 120, respectively. Transmit/receive switch 210e selects a signal path for either transmit or receive functions, and can be automatically controlled by MAC 210a.
Antenna selection switch 210f controls whether internal antenna 130a or optional external antenna 130b is used for wireless communication. Switch 210f can also be automatically controlled by MAC 210a. Internal antenna 130a and optional external antenna 130b illustrate various embodiments of antenna 130 set forth in
Application processor 220 supports the operation of module 120. In one embodiment, processor 220 can be implemented by, for example, a Ubicom, Inc. IP2022™ Wireless Network Processor. It will be appreciated that other embodiments of processor 220 are also contemplated in accordance with the present invention. Firmware of processor 220 supports a 802.11b network driver, as well as a TCP/IP protocol stack and features required for Internetworking. Of the 120 MIPS provided by this embodiment of processor 220, 30 MIPS are typically available for customer-specific applications. In this embodiment, processor 220 has 64 KB program flash memory, 16K program RAM, and 4 KB data RAM integrated on-chip. Optional expansion application memory, such as SRAM 240 and FLASH 250 can also be provided for operation in conjunction with processor 220 as illustrated in
Module 120 also provides a plurality of physical ports 230 for communicating with host 110. It will be appreciated that a variety of physical input and output ports 230 can be implemented to facilitate the integration of module 120 into a wide range of hosts 110 for analog and/or digital applications. In one embodiment, the physical ports 230 are under software control and are implemented as twelve (12) 5V tolerant General Purpose I/O lines (GPIO) and eight (8) 3.3V max Analog input/Digital I/O lines (AnGP or AIN). The GPIO lines can also be configured through a high-speed SERDES to support high speed synchronous or asynchronous serial, Ethernet, USB, or SPI communication. Additionally, free GPIO lines can be configured to support low-speed asynchronous serial, SPI, 12C, and SMB interfaces or switches and indicators.
The main I/O function of each of physical ports 230, as well as the dedicated function for the various SERDES configurations for an embodiment of the present invention are illustrated in the following Table 1.
With regard to the embodiment set forth in Table 1 above: ports that are not dedicated to a selected SERDES function are GPIO or AnGP; the USB interface can operate in either Host or Device mode; the SPI interface can operate in either Master or Slave Mode; the GPIO can operate in either Master or Slave Mode; and the Ethernet(2) configuration can be used concurrently with any of the other SERDES or I/O functions.
In another embodiment, GPIO and AnGP physical ports 230 can be used to implement other interfaces under firmware control. Table 2 below lists several interfaces which can be implemented, and the number of ports used for such implementation. It will be appreciated that firmware support for other interfaces may also be provided.
In another embodiment, the I/O configuration of physical ports 230 is implemented in five I/O groups as set forth in Table 3 below. Each row of Table 3 represents one of physical ports 230. Within each group, only one of the columns may be selected at a time:
In addition, some GPIO lines of physical ports 230 can be configured to implement special functions, rendering them unavailable as GPIO bits. Examples of such special functions are set forth in the following Table 4:
Module 120 can also be provided with an additional Test SPI interface (not shown) used for development and manufacturing purposes and for downloading firmware of module 120. In one embodiment, the Test SPI interface is implemented using the following signals set forth in Table 5:
Referring again to
In various embodiments, the mechanical packaging of module 120 can be implemented as: (1) a single board that forms the completely integrated module; or (2) a two-board stacked version with one board including the radio and baseband processor, and a second board containing the application processor and I/O interface.
Module 120 can also be implemented in accordance with the following specifications of Table 6:
Additional software 340 and 345 of module 120 can be implemented by the combination of MAC 210a and baseband RF 210b of radio 210. Software 340 implements an 802.11 MAC layer and provides many of the standard functions necessary for wireless networking, including: segmentation and reassembly of packets, encryption/decryption, MAC Control (including synchronization, beacon, and controlling the power of the module wireless output signal), and baseband functions (including the functionality illustrated in the packet procedures and co-ordination functions blocks). Software 345 supporting the radio physical layer 345 can also be provided, as illustrated in
In the block diagram, data from host 110 is received by module 120 through a serial interface connection between host 110 and module 120. The data is passed through any appropriate combination of the layers and software components (collectively illustrated as element 430) implemented on module 120, and sent over wireless link 135. It will be appreciated that the HTTP and Telnet layers of module 120 provide for the implementation of a web server and Telnet server, respectively, on module 120. In one embodiment, all web page requests to module 120 are handled by the web server of module 120. It will also be appreciated that the data layer of module 120 provides a conduit for other data connections through module 120.
Data is received by access point 150 (implemented as a bridge in
In another aspect of the present invention, module 120 permits a browser 180 of remote device 170 to request and receive data from host 110, and display the data to a user of remote device 170 as an HTML-formatted web page. For example, if host 110 is implemented as a remote sensor, the sensor data can be requested and displayed to a user of browser 180.
In step 620, remote device 170 executes the embedded code which causes remote device 170 to issue a data request command to module 120, wherein the command includes an encoded string (step 625). The string can be encoded in accordance with a host-oriented protocol or other appropriate protocol such that, when the string is processed by host 110, it will be recognized by host 110 as a data request. For example, in one embodiment, the encoded string can be an ASCII string encoded in accordance with a coding scheme determined by an OEM provider of host 110.
Module 120 interprets the command (step 630) and passes the encoded string to host 110 (step 635). Host 110 processes the string (step 640) and returns a response string to module 120 (step 645). The response string can be in the form of HTML blocked data to be processed by the embedded code executing on remote device 170. Upon receipt of the response string, module 110 passes the response string to remote device 170 (step 650). Embedded code executing on the remote device 170 then causes browser 180 to format and display the data encoded in the response string (step 655).
In various embodiments, the embedded code is expected to include code that issues HTTP “put” or “get” commands that may include CLI putget or putexpect commands (further described herein) to obtain content for web pages from the host 110. If it is desired that module 120 and host 110 be readily available to provide data from host 110 to browser 180, or be readily available to interact with other connections, any connection initiated by the embedded code should be kept open for as a short a time as possible, in order to permit other traffic to easily interleave between requests issued by the embedded code.
In another aspect of the present invention, module 120 facilitates data communication between remote device 170 and host 110 using a pass-through mode initiated by commands issued by remote device 170 or host 110.
While module 120 is in pass-through mode, module 120 passes raw data received from wireless link 135 directly to host 110, and passes raw data received from host to the wireless link, without interpreting the data passed in either direction. However, while in pass-through mode, module 120 can still interpret a command to escape the pass-through mode (step 725).
After module 120 has escaped pass-through mode, additional commands can be issued to module 120 (step 730). If one or more additional commands are issued (step 735), the process returns to step 715 after such issuance. If no additional commands are to be issued, then the connection between module 120 and remote device 170 is closed (step 740).
In another aspect of the present invention, module 120 facilitates the communication of host 110 with remote device 170 by way of commands issued by host 110 to module 120 in accordance with an alternate process.
After the connection is prepared, host 110 issues a command to module 120 having encoded data to be transmitted to remote device 170 (step 815). It will be appreciated that the encoded data in the command of step 815 can be a string encoded in accordance with a host-oriented protocol or other appropriate protocol such that, when the string is processed by remote device 170, it will be recognized as a data request.
Upon receipt of the command, module 120 opens a port to remote device 170 (step 820) and transmits the encoded data to remote device 170 (step 825). Remote device 170 then responds to the encoded data by returning response data to module 120 (step 830). It will be appreciated that the response data can also be a string encoded in accordance with a host-oriented protocol or other appropriate protocol as previously described herein such that, when the string is processed by host 110, it will be recognized by host 110 as a response to the encoded data contained in the command of step 815. Upon receipt of the response data, module 120 transmits the response data to host 110 (step 835) and closes the port (step 840).
It will be appreciated that the steps of
In another aspect of the present invention, module 120 facilitates the communication of remote device 170 with host 110 by way of commands issued by remote device 170 to module 120 in accordance with an alternate process.
Upon receipt of the command, module 120 opens a port to host 110 (step 920) and transmits the encoded data to host 110 (step 925). Host 110 then responds to the encoded data by returning response data to module 120 (step 930). It will be appreciated that the response data can be formatted as a string that is encoded in accordance with a host-oriented protocol or other appropriate protocol such that, when the string is processed by remote device 170, it will be recognized by remote device 170 as a response to the encoded data contained in the command of step 915. Upon receipt of the response data, module 120 transmits the response data to remote device 170 (step 935) and closes the port (step 940).
It will be appreciated that the steps of
In another aspect of the present invention, module 120 can support a comprehensive set of configuration parameters for customizing the operation and implementation of the module 120. Parameters can be implemented to support read, write, or read/write status. In various embodiments, the configuration parameters can be adjusted in a variety of ways, such as through the issuance of commands (for example, CLI commands) by host 110 or remote device 170, by browser 180 through an HTML page served by module 120, and/or by configuration utility 190. Authentication can be required for the adjustment of various parameters, and certain parameters can be implemented such that adjustment is only permitted at the factory. Various combinations of these adjustment methods may also be used.
The following Table 8 lists a set of configuration parameters that can be implemented in a particular embodiment of module 120. It will be appreciated that the support of a “Hardware I/O Configuration” parameter, as well as those parameters listed thereafter in Table 8, constitute additional unique features of module 120 in relation to prior art designs.
In one embodiment, the configuration parameters are divided into three capability sets stored in flash memory of processor 220: (1) device configuration parameters; (2) OEM configuration parameters; and (3) factory configuration parameters.
Referring to
OEM configuration parameters 520 can be modified and configured by an OEM in order to customize module 120 for use with a particular host 110 provided by the manufacturer. For example, such OEM configuration parameters can specify: HTML pages and fields permissions, command permissions, product ID, OEM ID, OEM defaults, and OEM access key (permanent, random, host assigned). In particular, the OEM configuration parameters can configure the HTML pages and GIF files served by module 120 when a browser 180 accesses a host 110 provided by the OEM.
Factory configuration parameters 530 specify the base configuration of module 120 that is loaded into flash memory from the program image 560 (firmware) of the module, and cannot be subsequently changed by an OEM receiving the module. The factory configuration 530 can be dynamically reloaded as desired. Such factory configuration parameters can adjust: functional permissions, MAC address, version and date codes, manufacturer ID, factory defaults for all fields and parameters, factory access key, hardware configuration definition, and which tools can be used to adjust other parameters (i.e. browser, commands, configuration utility).
HTML pages 540 and GIF files 550 are also stored in flash memory. Various HTML pages 540 and GIF files 550 can be provided, having different purposes. For example, when host 110 is accessed by browser 180 through module 120 as in
In optional step 1010, configuration utility 190 downloads a pre-existing OEM configuration 520, HTML pages 540, and GIF files 550 from module 120 over wireless link 135. A user of remote device 170 can then modify the downloaded OEM configuration 520, HTML pages 540, and GIF files 550, or create a new OEM configuration, HTML pages, and/or GIF files using configuration utility 190 (step 1015).
During step 1015, the user can modify any of the configuration parameters in the OEM configuration 520 as well as parameters for, and content of, HTML pages 540 and GIF files 550 served by module 120 for browser-based data communication with host 110, as previously described above. In one embodiment, the modified data is in the format of a binary configuration file. At step 1020, the configuration utility 190 uploads the modified or new OEM configuration, HTML pages, and GIF files to module 120 over wireless link 135.
To secure against the execution of unauthorized commands, module 120 can provide authentication security. Authentication can be implemented in the form of a user ID and password sent to module 120. For example, in one embodiment, access to module 120 from remote device 170 using Telnet, HTTP, or TCP over wireless link 135 can be authenticated. In other embodiments, authentication can be applied to access to module 120 from host 110. It will be appreciated that various authentication implementations are contemplated, wherein authentication is applied to some, all, or none of the access to module 120 from host 110 and/or remote device 170. It is further contemplated that authentication need not be applied at all times. For example, it may be desirable that authentication not be performed when module 120 is in a pass-through mode. Depending on the password used for authentication, a security/access level is determined. The terms “access level” and “security level” are used interchangeably herein.
In one embodiment, each CLI command recognized by module 120 corresponds to one of five (5) security levels: Level 0 (L0) UDP security; Level 1 (L1) default security; Level 2 (L2) device configuration security; Level 3 (L3) OEM security; and Level 4 (L4) manufacturer security. Level 0 is a connectionless access level pertaining to access to module 120 over UDP and access to name query services. Level 0 commands can be executed without requiring authentication. Level 1 is the default security level for module 120 when power is applied.
Authentication for a particular security level permits the execution of CLI commands requiring the same security level, as well as CLI commands having lower security levels. For example, an authentication using a valid Level 2 user ID and password would permit the execution of CLI commands having security Levels 0, 1, and 2, but would not permit the execution of CLI commands having security Levels 3 or 4.
To facilitate the operation of module 120 as described herein, module 120 can be implemented to recognize and execute commands received from remote device 170 over wireless link 135 and/or from host 110. Various commands can be used to configure, control, and obtain status of module 120, and set up communications via module 120. The commands issued to module 120 can be of any suitable format that can be interpreted and processed by the module. For example, such commands can be implemented using a command line interface (CLI).
Module 120 can implement a variety of responses to CLI commands it receives, depending on the nature of the command and success or failure of the command. For example, module 120 can return a response formatted as “OK” which indicates the successful execution of a CLI command. Similarly, module 120 can return an error response, having the general format: “Error 0xhhhh: error text” where the aschex value is the error code. In one embodiment, all responses are followed by <CRLF>.
In one embodiment, the CLI commands of the following Tables 9A-H can be employed. It will be appreciated that the “Ln” column indicates the security level corresponding to each command, as further described herein.
ds
ds”
ds”
In the commands of Tables 9A-H above, the following conventions can be applied:
As illustrated in
The serial interface connection between host 110 and module 120 can be realized by serial ports of physical ports 230. Data passed over the serial interface can be implemented in accordance with a host-oriented protocol or other appropriate protocol, as previously described herein.
In various embodiments, the serial interface connection of module 120 can operate in a plurality of modes. In one embodiment, three such modes are supported: (1) CLI mode; (2) listen mode; and (3) pass-through mode. In CLI mode, the serial interface will respond to CLI commands from host 110, while commands received from any other CLI communication interfaces (i.e. interfaces (b) and (c) described above) are ignored. In listen mode, the serial interface will respond to CLI commands received from any of the CLI communication interfaces (a), (b), or (c) described above. In pass-through mode, raw data can be tunneled back and forth over the serial interface, permitting the raw data to be passed between host 110 and remote device 170. To ensure that host 110 and module 120 are synchronized regarding the characterization of data on the serial interface, the operation of these various modes is subject to the various arbitration rules further set forth herein.
In one embodiment, only one communication session at a time can send and receive data over the serial interface connection between module 120 and host 110. These sessions include: (1) host-initiated communication using the serial interface in CLI or pass-through mode; (2) putget or putexpect commands received through the web server of module 120; (3) a Telnet session through the Telnet server of module 120 using putget, putexpect, and pass-through mode; and (4) a TCP connection initiated by host 110 or remote device 170.
Module 120 can be implemented such that host 110 has priority over the serial interface. If the host 110 decides it wants the serial interface and issues an escape sequence CLI command to module 120, the serial interface is placed into CLI mode, and host 110 is given ownership of the serial interface. Any other session activity on the serial interface is immediately terminated. The escape string is nevertheless transmitted through the connection before the connection is terminated.
The following Table 10 sets forth an example, illustrating a sample sequence of commands and interaction between host 110 and module 120 using the serial interface. ds<CRLF>
module 120 forwards
ds<CRLF>
When in listen mode, module 120 does not provide delineation of requests or indication of a request's source. The request data must be designed to provide adequate identification so that the host 110 can respond with the correct information. For example, the data in a putget or putexpect command issued by Java Script embedded in resident HTML should include enough information so that after the data is forwarded, host 110 can discern the source of the data and respond accordingly. Similarly, the data in a putget or putexpect command issued by host 110 to remote device 170, as well as the response data from the remote device 170, should include sufficient information for each to discern the communication source in order to send corresponding response data.
Regarding the escape sequence command: there is no escape sequence command transparency (i.e. there is no need to prefix escape characters with an escape prefix); the escape sequence is a fixed length 5 byte sequence; the CLI commands have no way of clearing the escape value; only one escape is defined for all CLI communication interfaces.
Module 120 does not allow remote device 170 to permanently own control of the serial interface. However, when the host 110 releases ownership of the serial interface with a listen CLI command, remote device 170 can issue a pass through command, causing the serial interface to enter pass through mode, allowing module 120 to tunnel data from remote device 170 to host 110. At any time though, the host 110 may regain ownership of the serial interface, and block the remote device 170 client from tunneling data. It will be appreciated that such functionality is useful for configurations where the host 110 needs to urgently communicate information. Remote device 170 clients, such as a remote device 170 acting as a Telnet or HTTP client, may issue a pass command to tunnel data to the host 110. However, if the host 110 has ownership of the serial interface (either by: (1) the serial interface being in CLI mode; or (2) the serial interface being in a pass-through mode initiated by host 110), module 120 will reject such a request.
When module 120 powers up, various parameters can affect whether module 120 attempts to make a connection with a remote device 170. In one embodiment, the wl-auto state can determine such operation. If it is disabled, the serial interface will be set to CLI mode upon power up. When it is enabled, module 120 will attempt to connect to the wl-tcp-ip address of remote device 170. If the connection is successful, the serial interface is set to pass-through mode, as if host 110 issued a pass CLI command. If the connection fails, module 120 will send an escape sequence CLI command to host 110, and continue to retry the connection.
In one embodiment, the serial interface can be implemented to default to a host-initiated pass-through mode (acting as if the pass-through mode were initiated by host 110; i.e. module 120 attempts to make a TCP connection to the last defined wl-tcp-ip address and sets the serial interface in pass-through mode), on start up.
When the serial interface is set to pass-through mode by the host 110, the following are true:
When module 120 detects and executes an escape sequence CLI command received from the host 110, the following are true:
When module 120 detects and executes the “listen” command received from the host 110, the following are true:
In various embodiments, when pass-through mode has been initiated by host 110, the TCP connection is kept open until host 110 closes the connection or module 120 receives a close CLI command over any CLI communication interface. No other CLI communication interface can initiate pass-through mode or have module 120 execute putget or putexpect CLI commands while the host 110 initiated pass-through TCP connection is open or the serial interface is in CLI mode.
In various embodiments, putget or putexpect commands issued by host 110 cause module 120 to open a TCP connection to a remote device 170, send data, get data, transfer the data to the host 110, and close the TCP connection. The whole transaction is intended to be short and quick so that the serial interface can rapidly switch between CLI mode and listen mode. This latter capability is important if the host 110 wishes to be able to receive ad hoc putget data over the web server of module 120.
As previously described herein, module 120 provides a Telnet server. Once a Telnet session is established from remote device 170, the Telnet server expects that any further data it receives from remote device 170 will be in the form of a CLI command. Remote device 170 can then send CLI commands to the CLI server of module 120.
After a Telnet connection is established, the following applies:
The following Table 11 sets forth an example of a Telnet session where commands are sent and data is exchanged. ds<CRLF>
ds<CRLF>
ds<CRLF>
Regarding the browser-based data communication previously described above, the process of
It will be appreciated that the scope of the present invention is not limited by the particular embodiments set forth herein. It is contemplated that the ordering of steps explained herein can be changed where appropriate, and that various steps can be combined into composite steps and/or dissected into substeps where appropriate. In addition, it is contemplated that, in addition to and/or as an alternative to the data formats previously described herein, data transmitted and/or received pursuant to various embodiments of the present invention can be formatted in accordance with an appropriate string format, binary data format, an ASCII Hex format, and/or other appropriate formats. Other appropriate variations of the present invention, whether explicitly provided for or implied, are also contemplated by the present disclosure.