GE910 Family Ports Arrangements - Adaptive Modules · 2016. 12. 13. · semiconductor memories or other media. Laws in the Italy and other countries preserve for Telit and its licensors

G

APPLICABILITY TABLE

SW Versions

GE Family ( Embedded )

GE910-QUAD 13.00.xx4

GE910-GNSS 13.00.xx4

GE910-QUAD AUTO 13.00.xx6

Note: the features described by the present document are provided by the products equipped

with the software versions equal or higher than the versions shown in the table.

G

SPECIFICATIONS SUBJECT TO CHANGE WITHOUT NOTICE

Notice

While reasonable efforts have been made to assure the accuracy of this document, Telit

assumes no liability resulting from any inaccuracies or omissions in this document, or from

use of the information obtained herein. The information in this document has been carefully

checked and is believed to be entirely reliable. However, no responsibility is assumed for

inaccuracies or omissions. Telit reserves the right to make changes to any products described

herein and reserves the right to revise this document and to make changes from time to time

in content hereof with no obligation to notify any person of revisions or changes. Telit does

not assume any liability arising out of the application or use of any product, software, or

circuit described herein; neither does it convey license under its patent rights or the rights of

others.

It is possible that this publication may contain references to, or information about Telit

products (machines and programs), programming, or services that are not announced in your

country. Such references or information must not be construed to mean that Telit intends to

announce such Telit products, programming, or services in your country.

Copyrights

This instruction manual and the Telit products described in this instruction manual may be,

include or describe copyrighted Telit material, such as computer programs stored in

semiconductor memories or other media. Laws in the Italy and other countries preserve for

Telit and its licensors certain exclusive rights for copyrighted material, including the

exclusive right to copy, reproduce in any form, distribute and make derivative works of the

copyrighted material. Accordingly, any copyrighted material of Telit and its licensors

contained herein or in the Telit products described in this instruction manual may not be

copied, reproduced, distributed, merged or modified in any manner without the express

written permission of Telit. Furthermore, the purchase of Telit products shall not be deemed

to grant either directly or by implication, estoppel, or otherwise, any license under the

copyrights, patents or patent applications of Telit, as arises by operation of law in the sale of a

product.

Computer Software Copyrights

The Telit and 3rd Party supplied Software (SW) products described in this instruction manual

may include copyrighted Telit and other 3rd Party supplied computer programs stored in

semiconductor memories or other media. Laws in the Italy and other countries preserve for

Telit and other 3rd Party supplied SW certain exclusive rights for copyrighted computer

programs, including the exclusive right to copy or reproduce in any form the copyrighted

computer program. Accordingly, any copyrighted Telit or other 3rd Party supplied SW

computer programs contained in the Telit products described in this instruction manual may

not be copied (reverse engineered) or reproduced in any manner without the express written

permission of Telit or the 3rd Party SW supplier. Furthermore, the purchase of Telit products

shall not be deemed to grant either directly or by implication, estoppel, or otherwise, any

license under the copyrights, patents or patent applications of Telit or other 3rd Party supplied

SW, except for the normal non-exclusive, royalty free license to use that arises by operation

of law in the sale of a product.

G

USAGE AND DISCLOSURE RESTRICTIONS

License Agreements

The software described in this document is the property of Telit and its licensors. It is

furnished by express license agreement only and may be used only in accordance with the

terms of such an agreement.

Copyrighted Materials

Software and documentation are copyrighted materials. Making unauthorized copies is

prohibited by law. No part of the software or documentation may be reproduced, transmitted,

transcribed, stored in a retrieval system, or translated into any language or computer language,

in any form or by any means, without prior written permission of Telit

High Risk Materials

Components, units, or third-party products used in the product described herein are NOT

fault-tolerant and are NOT designed, manufactured, or intended for use as on-line control

equipment in the following hazardous environments requiring fail-safe controls: the operation

of Nuclear Facilities, Aircraft Navigation or Aircraft Communication Systems, Air Traffic

Control, Life Support, or Weapons Systems (High Risk Activities"). Telit and its supplier(s)

specifically disclaim any expressed or implied warranty of fitness for such High Risk

Activities.

Trademarks

TELIT and the Stylized T Logo are registered in Trademark Office. All other product or

service names are the property of their respective owners.

Copyright © Telit Communications S.p.A.

G

1. Introduction ................................................................................................................... 7

2. GE910 Family Ports Arrangements and VSD ............................................................. 9

3. AT#PORTCFG Command ........................................................................................... 11

4. CMUX Protocol ........................................................................................................... 17

5. Services ....................................................................................................................... 22

6. The Winning Ports Configuration.............................................................................. 31

G

G

The purpose of the present document is to provide a guideline to logically connect the

physical interfaces of the module to the services provided by the module itself. The GE910

Family modules need to be configured in suitable way to avoid hardware/software resources

conflicts.

Scope of this guide is to describe the ports/services arrangements provided by the GE910

Family modules. With ports/services arrangements is intended the logical connection of an

available serial port to an available Access point (e.g. AT0, AT1, AT2, TT, PYSER, GPS,

etc.).

This document is intended for User Application designers who want to exploit at best the

communication resources offered by the GE910 Family modules without run up against

resources contention among services.

For general contact, technical support, to report documentation errors and to order manuals,

contact Telit Technical Support Center (TTSC) at:

[email protected]

[email protected]

[email protected]

[email protected]

Alternatively, use:

http://www.telit.com/en/products/technical-support-center/contact.php

For detailed information about where you can buy the Telit modules or for recommendations

on accessories and components visit:

http://www.telit.com

To register for product news and announcements or for product questions contact Telit

Technical Support Center (TTSC).

Our aim is to make this guide as helpful as possible. Keep us informed of your comments and

suggestions for improvements.

Telit appreciates feedback from the users of our information.

mailto:[email protected]




http://www.telit.com/en/products/technical-support-center/contact.php

http://www.telit.com/

G

[1] Telit’s CMUX Implementation User Guide, 1vv0300994

[2] AT Commands Reference Guide, 80000ST10025a

[3] Easy Script in Python 2.7, 80378ST10106A

[4] GE910 Hardware User Guide, 1vv0300962

Revision Date Product/SW Version Changes 0 2013-05-16 First issue

1 2014-02-18

/

The title of the document has been

changed from “GE910 Family Ports

Arrangements (Virtual Service Device)”

in “GE910 Family Ports Arrangements”.

New chapters have been added.

Products added:

GE910-QUAD AUTO / 13.00.xx6 /

DTE Data Terminal Equipment

GPS Global Positioning System

RTD Real Time Debugger

USIFx Universal Serial Interface

VSD Virtual Service Device

G

Before describing the several logical connection configurations between physical ports and Services provided

by the modules belonging to the GE910 Family, it is useful to introduce the Virtual Serial Device. To have

information on physical ports of the modules refer to document [4].

Virtual Serial Device, hereafter called VSD, is a piece of software designed to run on GE910 Family modules.

It basically manages logical connections between the physical serial ports, accessible to the user, and the

services provided by the module. To accomplish this activity, VSD supports several Software Access Points

used as anchorage points for the logical connections. The following table shows the items involved in the

logical connections management: Physical Serial Ports, Software Access Points, AT Parsers and TT Utilities,

Services and Protocols.

Services

Physical Serial Ports Software Access Points AT Parsers and TT Utilities Protocols

USIF01 AT0 Instance #1 Python CMUX (VC1÷VC4)

2

USIF1 AT1 Instance #2 GPS USB (USB0÷USBx)

3 AT2 Instance #3

TT RTD VHWDTE0 VHWDTE1 PYSER

·············· ··············

GPS/NMEA

Tab. 1: Items managed by VSD

It is advisable to remind the concept of instances and their relationships with the Access Points. GE910

Family provides three AT Commands Parser Instances which are logically independent. Each one is managed

by the same control software block and is connected to an Access Point as sketched in the figure below.

fig. 1: AT Parser Instance concept

1 In document [4] USIF0 and USIF1 are called respectively Modem Serial Port 1 (Main) and Modem Serial Port 2 (Auxiliary). 2 Four CMUX channels: VC1÷VC4. 3 USB channels: the number of channels depends on the software version installed on the module.

AT0

Access point

AT2

Instance # 3

AT1

Instance # 2

AT1

Access point

AT2

Access point

Virtual Service Device

AT0

Instance # 1

Unique AT Parser Control Software

Block

G

The physical connection between the module and the generic device can be accomplished via the interfaces

provided by the module itself (USIFx, USBx). A sketch is shown in fig. 2.

The generic device can be developed by the user in accordance with its needs. In general, the device can be a

micro-controller (Application Processor) entirely developed by the user and equipped with an operating

system accomplishing the requirements of the user application.

fig. 2: Module and Application Processor

Interfaces

Module

Application

Processor

G

The logical connection examples described in this document assume that the module is connected to a

Windows-PC.

Tab. 2 shows the #PORTCFG variants supported by the modules in relation with the software version

installed on them. To have detailed information on AT command syntax refer to [2].

#PORTCFG variants supported

Module Software Versions

13.00.xx4 13.00.xx5 13.00.xx6 GE910-QUAD 0 0 0, 1, 3

GE910-QUAD AUTO 0 0 0, 1, 3

GE910-GNSS 0 0, 9 0, 1, 3, 8, 9

Tab. 2: #PORTCFG variants supported by Modules/Software Versions

NOTICE: the user shall use only the #PORTCFG variants showed in the table. All other parameter values

provided by the AT#PORTCFG command are reserved for Telit internal use only.

Before dealing with #PORTCFG variants, it is advisable to see how the USBx channels are mapped into

virtual COMx ports on the DTE side. The figure below shows an example of mapping. In general, it depends

on the Windows PC configuration and the number of the USB channels. The GE910 USB drivers are provided

by Telit and must be installed on the Windows-PC.

fig. 3: USBx mapped into Virtual COMx ports

As previously described, the GE910 Family

provides two USB channels, see the figure on the

left side. In this example the mapping is:

• USB0 channel COM21 (or VCOM21)

• USB1 channel COM22 (or VCOM22)

Now, it is possible to assign a VCOMx port to

each USBx channel.

NOTICE: SW 13.00.xx6 provides three USB

channels: USB0, USB1, USB2.

G

G

Assume that the factory setting of the module is

not changed and the USB cable is not plugged in.

Now, power on the module: the factory

arrangement of the logical internal connections

among physical ports and “Access points” is

depicted in the table below.

AT#PORTCFG=0 (Factory setting)

AT0 AT1 AT2 TT

No USB cable

USIF0 X

USIF1 RTD

Tab. 3: #PORTCFG=0, no USB cable

Assume that the module is powered on and its

configuration is the factoring setting configuration

shown on the left side. Now, connect the USB

cable to the module. The module recognizes the

“plug in” event and assumes the factory

arrangement depicted in the table below.


AT0 AT1 AT2 TT

USB0 X

USB1 X

USIF0 X

USIF1 RTD

Only for SW version: 13.00.xx6


AT0 AT1 AT2 TT

USB0 X

USB1 X

USB2 N/A N/A N/A N/A

USIF0 X

USIF1 RTD

Tab. 4: #PORTCFG=0, with USB cable

The fig. 4 and fig. 5 show details concerning the logical connections among external physical ports and

internal “Access points”.

fig. 4: #PORTCFG=0, no USB cable connected

AT0

Access point AT1

Access point

AT2

Access point

TT

Access point

USIF0

Physical port

HyperTerminal Session

connected to AT0 parser

(instance # 1)

USB

Physical port

USB

USIF1

Physical port

DTE RTD

Application

COM1 COM2

USB

Channels

USB1 USB0

Virtual Serial Device

G

fig. 5: #PORTCFG=0 with USB cable connected

NOTICE: RTD tool is available to the end user.

AT0

Access point

AT1

Access point AT2

Access point

TT

Access point



(instance # 1) DTE

RTD

Application


USB0 AT1

USB1 AT2

USB

Channels

USB1 USB0

USIF0

Physical port

USB

Physical port

USIF1

Physical port

USB COM1 COM2

G


AT#PORTCFG=1

AT0 AT1 AT2 TT

No USB cable

USIF0 X

USIF1 ???



AT#PORTCFG=1

AT0 AT1 AT2 TT

USB0 X

USB1 X

USB2 RTD

USIF0 X

USIF1 N/A N/A N/A N/A


fig. 6: #PORTCFG=1 + USB cable connected

TT

Access point

USIF1

Physical port

USB

Physical port

USIF0

Physical port

AT0

Access point AT1

Access point

AT2

Access point



(instance # 1) USB1 AT2

USB

USB0 AT1

DTE

RTD

Application

USB1 USB0


COM2 COM1

USB

Channels

USB2

USB2 RTD

G


AT#PORTCFG=3

AT0 AT1 AT2 TT

No USB cable

USIF0 X

USIF1 X



AT#PORTCFG=3

AT0 AT1 AT2 TT

USB0 X

USB1 N/A N/A N/A N/A

USB2 RTD

USIF0 X

USIF1 X


fig. 7: #PORTCFG=3 + USB cable connected

TT

Access point AT2

Access point

AT1

Access point

AT0

Access point

DTE

HyperTerminal Session connected to AT0 parser

(instance # 1)

USB0 AT2

USB

USB

Physical port

COM1

USIF0

Physical port

USB

Channels

USB0 USB1


Application

(instance # 2)

USB2

USIF1

Physical port

COM2

USB2 RTD

G

This section shows examples of ports arrangement supporting CMUX protocol. If you need to develop a

Multiplexing Protocol running on a desired application processor (e.g. a user micro-controller) refer to [1] to

get detailed information.

The module is configured as indicated in fig. 4: #PORTCFG=0 no USB cable plugged in. In addition, suppose

that the used DTE is a Windows PC and its device configuration is shown in fig. 8. Now, run on the DTE the

TELIT Serial Port MUX application, configure the virtual serial ports of MUX as shown on fig. 9, and

logically connect the virtual serial ports to the physical port COM1, refer to fig. 10. When the user starts an

application (e.g. Hyper Terminal) connected to one of the four virtual ports, TELIT Serial Port MUX

application sends automatically the AT+CMUX=0 command to the module and the CMUX protocol is

activated.

fig. 8: Physical COMx Ports

fig. 9: Virtual Serial Ports of MUX

NOTICE: the virtual serial ports of the TELIT Serial Port MUX application must be configured in such a

way to avoid conflict with the physical or virtual serial ports already present on the Windows PC (DTE).

G

Tab. 9 summarizes the VCOMxCOM1/USIF0VCx configuration and the RTD application

connection via USIF1/COM2 physical ports. The fig. 10 shows the connections details.

Module DTE connection VCOMx VCx AT0 AT1 AT2 TT

USB not used

USIF0 COM1

VCOM16VC1 X

VCOM17VC2 X

VCOM18VC3 X

VCOM19VC4

USIF1 COM2 RTD

Tab. 9: Ports Arrangement with CMUX + RTD

fig. 10: Ports Arrangement with CMUX + RTD

CMUX

Standard Protocol

AT0

Access point

AT1

Access point

AT2

Access point

USB

Physical port

DTE

HyperTerminal

Session connected

through VC1 to AT0

Access Point

HyperTerminal

Session connected

through VC3 to AT2

Access Point

TELIT Serial Port MUX

VCOM16 VCOM17 VCOM18 VCOM19

COM1

HyperTerminal Session connected

through VC2 to AT1

Access Point

VC4 spare

USB

VC1

VC2 VC3

VC4 spare

RTD Application


USIF0

Physical port

USIF1

Physical port

COM2

TT

Access point

G

The module is configured as indicated in fig. 5: #PORTCFG=0 (factory setting) plus USB cable plugged in. In

addition, suppose that the used DTE is a Windows PC and its device configuration is shown in fig. 3 (two

USB channel are available). Now, run on the DTE the TELIT Serial Port MUX application, configure the

virtual serial ports of MUX as shown in fig. 11, and logically connect the virtual serial ports to the USB1

channel mapped into VCOM22 virtual port as shown on Tab. 10, and fig. 12. When the user starts an

application (e.g. Hyper Terminal) connected to one of the four Virtual Ports, TELIT Serial Port MUX

application sends automatically the AT+CMUX=0 command to the module and the CMUX protocol is

activated.

fig. 11: Virtual Serial ports of TELIT MUX

As previously described, the GE910 Family

provides two USB channels, see the figure on the

left side. In this example the mapping is:

USB0 channel COM21 (or VCOM21)

USB1 channel COM22 (or VCOM22)

In addition, the figure shows the virtual serial ports

generated by the TELIT Serial Port MUX

application.

NOTICE: the virtual serial ports of the TELIT Serial Port MUX application must be configured in such a way

to avoid conflict with the physical or virtual serial ports already present on the Windows PC (DTE). An

example is shown in fig. 11.

G

The table below summarizes the new ports arrangement.

Module DTE connection Channels USBx VCOM VCOMx VCx AT0 AT1 AT2 TT

USB USB

USB0

USB1 VCOM22

VCOM16 VC1 X

VCOM17 VC2 X

VCOM18 VC3 X

VCOM19 VC4

USIF0 not used

USIF1 COM2 RTD

Tab. 10: Ports Arrangement when CMUX is connected to USB1 channel

Referring to fig. 12: it is worth noting that the AT0 (instance # 1) is disconnected from USIF0 and connected

to VC1USB1 channelUSB physical portVCOM22VCOM16Hyper Terminal. Instead,

the RTD stays on USIF1.

G

fig. 12: Ports Arrangement when CMUX is connected to USB1 channel


CMUX

Standard Protocol

AT0

Access point

USIF0

Physical port

AT1

Access point

AT2

Access point

TT

Access point

USIF1

Physical port

COM1 COM2

USB

Physical port

USB

Channels

USB0 USB1

VC1

VC2

VC3

VC4 spare

USB

DTE

HyperTerminal

Session connected

through VC1 to AT0

Access Point

HyperTerminal

Session connected

through VC3 to AT2

Access Point

TELIT Serial Port MUX

VCOM16 VCOM17 VCOM18 VCOM19

HyperTerminal

Session connected

through VC2 to AT1

Access Point

VC4 spare

USB1VCOM22

RTD

Application

G

This section describes the interaction between the ports arrangements and the services provided by the

modules.

The module equipped with GPS receiver can send NMEA sentences on a physical port in accordance with the

current ports configuration.

The AT#PORTCFG=8 connects directly the GPS Access point to the external physical port USB2, no AT

commands (AT$GPSP, AT$GPSNMUN ) are needed to route the NMEA sentences towards USB2 port.

Only for GE910-GNSS, SW version 13.00.xx6

AT#PORTCFG=8

AT0 AT1 AT2 TT GPS/NMEA

USB0 X

USB1 X

USB2 X

USIF0 X

USIF1 RTD

Tab. 11: #PORTCFG=9

fig. 13: USB1 channel supports only NMEA sentences

AT0

Access point

AT1

Access point AT2

Access point

TT

Access point



(instance # 1) DTE

RTD

Application


USB0 AT1

USB1 AT2

USB

Channels

USB2 USB0

USIF0

Physical port

USB

Physical port

USIF1

Physical port

USB COM1 COM2

NMEA sentences

GPS

Access point

USB1

USB2 only NMEA

G

Assume that the AT#PORTCFG=0 command is entered and an USB cable is connected to the module, the

internal logical connections of the module are shown in Tab. 4 and fig. 14. Now, to allow the NMEA

sentences run on the physical port USIF0 the operator must enter the AT$GPSP and AT$GPSNMUN

commands. After executing the two AT commands, NMEA sentences and AT commands can share the USIF0

port at the same time See figure below.

fig. 14: USIF0 port supports AT commands + NMEA sentences

GPS

Access point

NMEA sentences

AT0

Access point

AT1

Access point AT2

Access point

TT

Access point



(instance # 1) DTE

RTD

Application


USB0 AT1

USB1 AT2

USB

Channels

USB1 USB0

USIF0

Physical port

USB

Physical port

USIF1

Physical port

USB COM1 COM2

NMEA sentences

and AT commands

G

The AT#PORTCFG=9 connects directly the GPS Access point to the external physical port USB1, no AT

commands (AT$GPSP, AT$GPSNMUN ) are needed to route the NMEA sentences towards USB1 port.


AT#PORTCFG=9 GNSS


USB0 X

USB1 X

USIF0 X

USIF1 RTD


AT#PORTCFG=9


USB0 X

USB1 X

USB2 N/A N/A N/A N/A N/A

USIF0 X

USIF1 RTD

Tab. 12: #PORTCFG=9

fig. 15: USB1 channel supports only NMEA sentences

AT0

Access point

AT1

Access point AT2

Access point

TT

Access point



(instance # 1) DTE

RTD

Application


USB0 AT1

USB1 only NMEA

USB

Channels

USB1 USB0

USIF0

Physical port

USB

Physical port

USIF1

Physical port

USB COM1 COM2

NMEA sentences

GPS

Access point

G

The GE910 Family modules provide the Python programming language to offer to the user a tool to develop

control scripts in accordance with his communication and hardware needs, see [3]. As shown on fig. 16 the

VSD provides two access points called VHWDTE0 and VHWDTE1. MDM and MDM2 Python modules are

logically connected respectively to the two access points.

It is assumed that the module is using the factory setting4 configuration and USB cable is not plugged in.

Now, power on the module: the factory arrangement of the internal logical connections among physical ports

and “access points” is depicted in fig. 4, and Tab. 3 summarizes the factory ports arrangement. When the

Python script runs the Python instruction import MDM5, the VSD disconnects the USIF0/AT0 logical

connection and establishes the logical connection VHWDTE0/AT0 enabling Python script to access AT0

parser. In the same way, import MDM2 instruction requests to the VSD to establish the logical connection

VHWDTE1/AT1. The fig. 16 shows that USIF0 is disconnected from AT0 parser and cannot be used by an

external device.

Python script can run another Python software module to use the USIF0 port using the instruction import SER

and the access point PYSER. The fig. 17 shows the new connection: the physical port USIF0 is connected to

Python script via PYSER/SER.

The Python software modules MDM, MDM2, and SER use three independent resources: USIF0 physical port,

AT0, and AT1 Access Points. No resources contention can arise among them. As a rule, we can say that the

MDM, MDM2, and SER instructions steal the resources regardless their current owner.

As shown in the next pages there are other Python modules to create logical connection between a physical

port and an Access point. To have detailed information on the software versions supporting different Python

modules refer to document [3]. Here are some figures showing different logical connection configurations.

4 AT#PORTCFG=0, refer to Chapter 3. 5 It is assumed that the reader is familiar with Python language.

G

AT2

Instance # 3

fig. 16: Python & MDM, MDM2 modules

DTE HyperTerminal Session


(instance # 1)

COM1

RTD

Application

COM2

AT0

Access point

AT1

Instance # 2

AT0

Instance # 1

AT1

Access point

AT2

Access point

TT

Access point


Python

MDM2 MDM

VHWDTE1 VHWDTE0

User Script

USB

Physical port

USIF0

Physical port

USIF1

Physical port

Trace Utility

G

AT2

Instance # 3

fig. 17: Python & MDM, MDM2, SER modules



(instance # 1)

COM1

RTD

Application

COM2

AT0

Access point

AT1

Instance # 2

AT0

Instance # 1

AT1

Access point AT2

Access point

TT

Access point


Python

MDM SER

VHWDTE1 VHWDTE0

User Script

USB

Physical port

USIF0

Physical port

USIF1

Physical port

MDM2

PYSER

Trace Utility

G

AT2

Instance # 3

In accordance with the installed software version, Python script can run the Python software module to use the

USIF1 port using the instruction import SER2 and the access point PYSER2. The figure below shows the new

connection: the physical port USIF1 is connected to Python script via PYSER2/SER2.

fig. 18: Python & MDM, MDM2, SER, SER2 modules

The Python software modules MDM, MDM2, SER, and SER2 use four independent resources: USIF0, USIF1

physical ports, and AT0, AT1 Access Points. No resources contention can arise among them. As a rule, we

can say that the MDM, MDM2, SER, and SER2 instructions steal the resources regardless their current owner.



(instance # 1)

COM1

Connected to Python

script

COM2

AT0

Access point

AT1

Instance # 2

AT0

Instance # 1

AT1

Access point AT2

Access point

TT

Access point


Python

MDM SER

VHWDTE1 VHWDTE0

User Script

USB

Physical port

USIF0

Physical port

USIF1

Physical port

MDM2

PYSER

Trace Utility

PYSER2

SER2

G

AT2

Instance # 3

In accordance with the installed software version, Python script can run the Python software module to use the

USB0 channel using the instruction import USB0 and the access point PYUSB0. The figure below shows the

new connection: the USB0 channel is connected to Python script via PYUSB0/USB0.

fig. 19: Python & MDM, MDM2, SER, USB0 modules

The Python software modules MDM, MDM2, SER, and USB0 use four independent resources: USIF0

physical port, USB0 channel, and AT0, AT1 Access Points. No resources contention can arise among them.

As a rule, we can say that the MDM, MDM2, SER, and USB0 instructions steal the resources regardless their

current owner.

USB0 connected to Python script

DTE

HyperTerminal Session connected to AT0 parser

(instance # 1)

COM1

RTD

Application

COM2

AT0

Access point

AT1

Instance # 2

AT0

Instance # 1

AT1

Access point

AT2

Access point

TT

Access point


Python

MDM SER

VHWDTE1 VHWDTE0

User Script

USB

Physical port

USIF0

Physical port

USIF1

Physical port

MDM2

PYSER

Trace Utility

PYUSB0

USB0

USB1 USB0 USB2

Channels

USB

G

AT2

Instance # 3

It is assumed that the user needs to debug a new Python script. The module is using the factory setting

#PORTCFG=0 configuration, refer to Tab. 3. Now, suppose that the Python script runs: import MDM, import

MDM2, import SER and print instructions. The figure below sketches the actions results of the first tree

instructions. Moreover, it shows that the print instruction uses the TT Access point to send the print messages

to the USIF1 port. The RTD application displays on the DTE, in readable format, the trace data received in

binary format from the Trace Utility, and the print Python messages, received from the User Script, in text

format. The Hyper Terminal session can only display the print Python messages received in text format.

fig. 20: Python & MDM, MDM2, SER and print modules

DTE HyperTerminal Session connected to Python

script.

COM1 COM2

RTD Application or

HyperTerminal Session in accordance with the

debugging session needs.

AT0

Access point

AT1

Instance # 2

AT0

Instance # 1

AT1

Access point

AT2

Access point

TT

Access point


Python

MDM SER

VHWDTE1 VHWDTE0

User Script

pri

nt

: P

yth

on

scr

ipt

inst

ruct

ion

.

Trace Utility

USB

Physical port USIF0

Physical port

USIF1

Physical port

MDM2

PYSER

G

There are two methods to change module ports arrangement in addition to use #PORTCFG:

Plug in/out the USB cable;

Enter the AT+CMUX=06 command.

Here are two examples showing how the user can change ports configuration.

Example 1

Module: its ports configuration is shown on fig. 4 (factory setting).

User action: the user runs on the Windows PC the TELIT Serial Port MUX application so configured:

Virtual Ports COM16÷COM19 logically connected to COM1.

PC: it provides the required Virtual Ports. When the user starts an application (e.g. Hyper

Terminal) connected to one of the three Virtual Ports (the fourth one is spare), TELIT Serial

Port MUX application sends the AT+CMUX=0 command to the module.

Module: in accordance with the received command, the involved AT Parser starts the CMUX protocol.

The module enters the configuration shown on fig. 10.

User action: now, the user connects USB cable.

Module: it enters the configuration shown on fig. 5.

PC: it provides two new virtual “COM” logically connected to the two USB channels. The CMUX

protocol is disabled and the TELIT Serial Port MUX application running on Windows PC is

no more connected to the module, it should be closed. COM1 is ready for new applications.

User action: now, the user disconnects USB cable.

Module: it enters again the configuration shown on fig. 4.

6 TELIT Serial Port MUX application automatically sends the AT+CMUX=0 command to the module, see chapters 4.1, 4.2.

G

Example 2

Module: its port configuration is shown on fig. 4 (factory setting).

User action: the user connects USB cable.

Module: in accordance with the user action, the module enters the configuration shown on fig. 5.

PC: it provides two virtual “COM” required by USB drivers to logically connect the two USBx

channels.

User action: the user runs on the Windows PC the TELIT Serial Port MUX application so configured:

Virtual Ports COM16÷COM19 logically connected to USB1VCOM22.

PC: it provides the required Virtual Ports. When the user starts an application (e.g. Hyper

Terminal) on a Virtual Ports, TELIT Serial Port MUX sends the AT+CMUX=0 command to

the module.

Module: in accordance with the received command, the involved AT Parser starts the CMUX protocol.

The module enters the configuration shown on fig. 12.

User action: now, the user disconnects USB cable.

Module: it enters the configuration shown on fig. 4.

PC: discards the two virtual “COM” logically connected to the two USBx channels. The CMUX

protocol is disabled, TELIT Serial Port MUX application running on Windows PC is no more

connected to the module, and it should be closed.

The two examples show that the last required port configuration overrides the previous one.

Documents

GE910 Family Ports Arrangements - Adaptive Modules · 2016. 12. 13. · semiconductor memories or other media. Laws in the Italy and other countries preserve for Telit and its licensors