Accessing MT100EOCG Hardware Interfaces

Cellular Modem

CoreCDP (2.2.2 and later) provides port naming using udev rules. This allows for consistent port naming across OCG models with different cellular modems. It also makes it easier to use the correct cellular modem port when other USB serial devices are attached to the OCG. Command ports are named /dev/modem_atN where N is the command port number from 0 to the number of available ports – 1 (varies by cellular modem).

Example:
First port: /dev/modem_at0
Second port: /dev/modem_at1

For CoreCDP versions prior to 2.2.2 (or if not using the udev symlink), the default port names are as follows.

Ports per model:
MT100EOCG-G2: /dev/ttyS1
MT100EOCG-EV2: /dev/ttyUSB0
MT100EOCG-EV3: /dev/ttyUSB2, /dev/ttyUSB3
MT100EOCG-H4: /dev/ttyUSB3, /dev/ttyUSB4
MT100EOCG-H5: /dev/ttyACM0, /dev/ttyACM3

For models that have numerous ports available, the developer can initiate a data connection on one port while using the other port for sending/receiving SMS or querying signal strength (AT+CSQ).

Note: The MT100EOCG-H4 modem has two command ports, but they are not the same. The first port (/dev/ttyUSB3 or /dev/modem_at0) accepts all supported AT commands, while the second (/dev/ttyUSB4 or /dev/modem_at1) is intended for initiating data connections and only supports a limited set of AT commands. If you need access to the full AT command set while a PPP link is active, set your /etc/ppp/options file to use /dev/modem_at1. This will leave /dev/modem_at0 available for other purposes requiring full AT command support.

To test AT commands, CoreCDP sample images provide both microcom and minicom for serial communication.

To establish a PPP link for internet access, make sure the correct device port is set in /etc/ppp/options. Once pppd is configured for your device, it is recommended to create a pppd chat script in /etc/ppp/peers that is specific to your wireless carrier. Then run pppd call <script name> to initiate the connection. See Establishing a Cellular Data (PPP) Connection for more information.

The reset line on the modem can be controlled using the mts-io module. See MT100EOCG I/O Control using mts-io

The H5 radio must be reset by running /usr/sbin/radio-reset-h5 (rather than using the standard mts-io method). This script disables all USB host ports while the radio is reset. If the script is not used, the radio will fail to reset and will not function until properly reset.
Serial UART (logic level)

Port: /dev/ttyS2
The external serial port (pins TXD_1, RXD_1, etc) is accessible using /dev/ttyS2. To control the DCD pin or read DTR, see MT100EOCG I/O Control using mts-io

GPS Reciever

Port: /dev/ttyS3
Baudrate: 9600
The GPS receiver is accessible at 9600 baud on /dev/ttyS3. See GPS Receiver Overview for more receiver and protocol information. Also see Command-line Utility for GPS for configuring the receiver if needed. Note that no configuration is needed to simply read location data — the receiver writes location updates at 1 second intervals by default.

USB 2.0 Full Speed (12 Mbps) Host

The USB Host is supported driectly by the Linux kernel. Drivers for many devices are available. Only certain devices are active in the baseline corecdp firmware.

USB Device Port

Port: /dev/ttyGS0
Driver: g_serial
The USB device port is configured by default to operate as a serial device using the USB Gadget serial driver. The CoreCDP sample images have the port configured as a login port. In some cases the USB cable must be attached to your PC when the device boots up to be accessible.
The gadget serial device provides a CDC-ACM serial device which is autodetected by most Linux systems and no driver install should be necessary. For Windows systems, first read the instructions in the gadget serial documentation and then download linux-cdc-acm.inf, which is located in the kernel usb documentation directory.

Ethernet

The 10/100 Ethernet interface can be configured by editing /etc/network/interfaces (a Debian-style network configuration file). The CoreCDP sample images set a default static IP address of 192.168.2.1. To use DHCP, change the iface eth0 inet static line to iface eth0 inet dhcp and remove or comment out the address, netmask, and gateway lines for eth0.

The Ethernet port can also be disabled using the mts-io module, if needed. See MT100EOCG I/O Control using mts-io

SD Card Slot

Device: /dev/mmcblk0p1 (first partition)
SD card access is available via a block device at /dev/mmcblk0pX, where X is the partition number on the card. The CoreCDP sample images are configured to auto-mount /dev/mmcblk0p1 at /media/card both on boot and on card insert. By default, the card is mounted with the “sync” option on — this causes writes to be flushed to the card immediately.

Temperature Sensor

The temperature sensor located on the MT100EOCG can be used for monitoring the board temperature. The temperature sensor can be read using the mts-io module. See MT100EOCG I/O Control using mts-io for details and examples.

Digital I/O

The MT100EOCG has four digital output, six digital input, and two dual-mode input/output pins. These pins can be read/written using the mts-io module. See MT100EOCG I/O Control using mts-io for more information. For more information on the electrical characteristics of the pins, please request a copy of the MultiConnect OCG-E Developer’s Guide

Analog Input Channels 0-3

The four analog input channels can be read using the mts-io module. See MT100EOCG I/O Control using mts-io for more information. For more information on the electrical characteristics of the inputs, please request a copy of the MultiConnect OCG-E Developer’s Guide

LEDs

There are six I/O lines for LEDs on the MT100EOCG hardware. By default, LEDs 1 and 4-6 are accessible through sysfs using the mts-io driver. LED 2 (status LED) is accessible through sysfs using the built-in leds-gpio kernel driver. LED 2 defaults to being a status light and is blinked by the “heartbeat” trigger on kernel boot. LED 3 is read-only and is connected to the LS pin of the cellular radio. See MT100EOCG I/O Control using mts-io for more information.

Example of controlling status LED (LED 2) via leds-gpio:

$ cd /sys/class/leds/status/
$ ls
brightness  device      power       subsystem   trigger     uevent
# current trigger is in square brackets
$ cat trigger
none nand-disk mmc0 timer [heartbeat] default-on 

# disable heartbeat trigger
$ echo "none" > trigger

# turn LED on
$ echo 1 > brightness

# make the LED blink on SD card activity
$ echo "mmc0" > trigger

# blink on NAND Flash activity
$ echo "nand-disk" > trigger

# Use the "timer" trigger to blink the LED
$ echo "timer" > trigger
# Keep it on for 1000 ms and off for 500 ms
$ echo 1000 > delay_on
$ echo 500 > delay_off
SPI Bus

The SPI bus can be used to access up to 3 SPI devices (SPI_CS5, SPI_CS6, SPI_CS7). CoreCDP 2.3.3 and later provide the “spidev” driver for accessing SPI devices from userspace C code. See Linux SPI documentation for more information and sample code, specifically the following files: spi-summary, spidev, spidev_fdx.c, spidev_test.c.

Device files:

  • CS5: /dev/spidev1.5
  • CS6: /dev/spidev1.6
  • CS7: /dev/spidev1.0

For more information on the electrical characteristics of the SPI bus, please request a copy of the MultiConnect OCG-E Developer’s Guide

I2C Bus

The External I2C bus can be used to access I2C devices. Userspace access to I2C devices is provided via the i2c-dev driver. I2c-dev documentation can be found here.

Device file: /dev/i2c-0

For more information on the electrical characteristics of the I2C bus, please request a copy of the MultiConnect OCG-E Developer’s Guide