3. Accessing and using the interfaces
This section covers basic usage and access of the device hardware. Most of the hardware is accessed using the default Linux interfaces but some device specific interfaces may require additional software and/or interfaces to be accessed. See the CC Linux – Programmer’s Guide documentation for general information regarding software development using the device interfaces.
There may also be additional methods to access the device interfaces than the ones described herein, depending on additional installed software or connected hardware.
3.1 Storage and file system
Depending on your device model, the device uses an eMMC or CFast based storage. The storage is partitioned into protected operating system parts and writable user parts. The filesystem abstracting the storage is overlayFS on top of ext4. OverlayFS provides a great way to merge filesystems such that one of the filesystems (called the “lower” one) never gets written to, but all changes are made to the “upper” one.
The eMMC and CFast storage options are industrial grade classified and have both static and dynamic wear levelling to prevent a premature aging and to ensure the longest lifetime. Still, eMMC and CFast have a limited number of write cycles. It is recommended that the amount of data written to storage is limited within the application. Rather keep information in RAM memory and write larger blocks at one time instead of frequently writing smaller pieces.
There is however a trade-off that an application needs to make here if the data to be saved is mission critical or not. An application should not cache files in the eMMC/CFast file system, since in case of a sudden power loss, the eMMC’s/CFast’s writable partition is made write-protected to protect the files from being corrupted. An application needs to be careful when writing large files, as it can cause pro-longed write-protect sequences, which is a potential hazard to the file system and eMMC/CFast.
The eMMC/CFast is partitioned into two root file systems, which are write protected, two application file systems, which are write protected and one user file system area, which is write enabled by default. Table 2 and Table 3 show the file system layouts for the root filesystems A and B respectively.
In both root filesystems A and B, any attached USB memory is automatically mounted once inserted. Supported formats for USB-memory include FAT types which is the default format for USB-memories. USB-memory devices are never automatically formatted so if the file system is unsupported, the device will remain unmounted.
Mount point |
Filesystem |
Mount status |
Description |
|---|---|---|---|
/ |
Ext4 |
ro |
Read only Rootfs A partition |
/appfs |
Ext4 |
ro |
Read only Appfs A partition |
/data |
Ext4 |
rw |
Read write Data partition |
/etc |
Overlay |
ro |
Lower dir for overlay |
/data/cc-workdir |
Overlay |
ro |
Work directory for overlay |
/data/cc-etc |
Overlay |
rw |
Upper dir for overlay |
/data/media/usbsda1 |
Vfat |
rw |
First USB memory, if available |
/data/media/usbsdb1 |
Vfat |
rw |
Second USB memory, if available |
/tmp |
tmpfs |
rw |
RAM memory, for storing temporary files |
/var/volatile |
tmpfs |
rw |
RAM memory for storing logs etc. during runtime |
Mount point |
Filesystem |
Mount status |
|
|---|---|---|---|
Mount point |
Filesystem |
Mount status |
Description |
/ |
Ext4 |
ro |
Read only Rootfs B partition |
/appfs |
Ext4 |
ro |
Read only Appfs B partition |
/data |
Ext4 |
rw |
Read write Data partition |
/etc |
Overlay |
ro |
Lower dir for overlay |
/data/cc-workdir |
Overlay |
ro |
Work directory for overlay |
/data/cc-etc |
Overlay |
rw |
Upper dir for overlay |
/data/media/usbsda1 |
Vfat |
rw |
First USB memory, if available |
/data/media/usbsdb1 |
Vfat |
rw |
Second USB memory, if available |
/tmp |
tmpfs |
rw |
RAM memory, for storing temporary files |
/var/volatile |
tmpfs |
rw |
RAM memory for storing logs etc. during runtime |
3.1.1 User file storage
On CC Linux 4.0, the /data partition is used for user file storage as only the data partition has the read-write access.
3.2 CAN
The device has up to four CAN interfaces with user configurable baud rate and frame type accessible from the CCSettingsConsole application. The CAN interfaces can also be accessed with the Linux operating system standard API SocketCAN. More information can be found in the CC Linux – Programmer’s Guide.
3.3 CAN-FD
In order to speed up the transfer of larger data, CAN with flexible data rate (CAN-FD) can be used. For integration with existing CAN networks, each CAN-FD port can also be used as a regular CAN port. The CAN-FD interfaces are accessed via SocketCAN similarly as regular CAN.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
Yes |
Yes |
Yes |
3.4 Ethernet
The device is set up to use DHCP for IP address retrieval. The network connection settings can be changed within the operating system settings, i.e. by using the network interfaces file as described in chapter 6.5.1.
Be aware that connecting the device to a network environment can impose a security threat if the required security measures are not taken.
3.5 Wireless LAN
The network connection settings can be changed within the operating system settings, i.e. by using the network interfaces file as described in chapter 6.5.1.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
Yes |
Yes |
No |
Be aware that connecting the device to a network environment can impose a security threat if the required security measures are not taken.
3.6 Bluetooth
The connection settings can be changed within the operating system settings, as described in chapter 6.5.1.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
Yes |
Yes |
No |
3.7 USB
A multitude of peripherals can be connected to the device via USB. For some peripherals, drivers compatible with the operating system must be installed in order to enable correct function. For such installations, please contact CrossControl for support in adding a suitable driver or follow the instruction from the device manufacturers.
3.8 Configurable inputs
The configurable input channels are available for software developers using the CCAux API. Parts of the functionality available can be viewed or set within CCsettingsConsole for test purposes.
For additional technical details, please see the Technical Manual of your device model and the CCAux API Reference Documentation.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
No |
No |
No |
Yes |
Yes |
3.9 PWM Outputs
The user-settable PWM output signals are available for software developers using the CCAux API. The output settings can be viewed or set within CCSettingsConsole for test purposes.
Please note that the PWM outputs are turned off upon suspend and need to be reconfigured when resuming. The CCAux API function PowerMgr_hasResumed can be called from within the user application in order to detect a resume from suspend event.
For additional technical details, please see the Technical Manual of your device model and the CCAux API Reference Documentation.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
No |
No |
No |
Yes |
Yes |
3.10 Backlight
Users can adjust the screen backlight intensity level. The backlight functionality can be controlled from CCSettingsConsole, via software using the CCAux API, and via backlight buttons.
Setting |
Default |
|---|---|
Backlight intensity |
255 |
Persistent backlight |
ON |
Automatic backlight (ABL) |
OFF |
ABL min level |
1 |
ABL soft transitions |
ON |
Led dimming |
ON |
The most recent setting is always used, it is saved between restarts.
3.11 Ambient light sensor
The ambient light sensor measures light levels in front of the device. The ambient light sensor is accessed through the CCAux API. It can also be accessed for diagnostic through CCSettingsConsole.
It is possible to use the ambient light sensor to make a custom, fully automatic, backlight control. Such an automatic backlight control function is included in the device, but it is not enabled by default. It can be set up in CCSettingsConsole or through the CCAux API.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
Yes |
Yes |
Yes |
Yes |
3.12 Buzzer
The device is equipped with a buzzer which can play tones in various frequency and intensity levels. The buzzer is accessed through the CCAux API. It can also be accessed for diagnostic through CCSettingsConsole.
Please note that the buzzer is turned off upon suspend and needs to be reconfigured when resuming. The CCAux API function PowerMgr_hasResumed can be called from within the user application in order to detect a resume from suspend event.
On some device models, the volume can be considered very loud when standing close to the device. Increment the volume gradually and use appropriate ear protection.
3.13 Temperature sensors
Several temperature sensors are placed internally in the device. It is possible for an application to retrieve temperature information from the temperature sensors through the CCAux API.
3.15 RS232 external serial port
There is one external RS232 port which can be accessed via /dev/ttyExt0.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
No |
No |
Yes |
3.16 Speaker
The speaker is controlled using the normal operating system functionality from the ALSA libraries, including sample applications. The audio device is identified as Cirrus Logic HD Audio.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
No |
No |
No |
3.17 Audio Out
The audio out is controlled using the normal operating system functionality from the ALSA libraries, including sample applications. The audio device is identified as Cirrus Logic HD Audio.
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|
Yes |
No |
No |
No |
No |