Accessing MT100EOCG Hardware Interfaces
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
N is the command port number from 0 to the number of available ports – 1 (varies by cellular modem).
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:
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/modem_at0) accepts all supported AT commands, while the second (
/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
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
/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)
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
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
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.
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
/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
/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.
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.
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
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
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.
For more information on the electrical characteristics of the SPI bus, please request a copy of the MultiConnect OCG-E Developer’s Guide
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.
For more information on the electrical characteristics of the I2C bus, please request a copy of the MultiConnect OCG-E Developer’s Guide