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 syste

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, and one user file system area, which is write enabled by default. Table 2 and Table 3 show the file system layouts for the main and rescue systems respectively.

In both main and rescue mode, 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.

Table 2: File system layout for main system

Mount point	Filesystem	Mount status
/	Overlay	rw	Virtual merge of lower and upper dirs
/mnt/.rootfs/ro	Ext4	ro	Lower dir for overlay (original root filesystem)
/mnt/.rootfs/rw	Ext4	rw	Upper dir for overlay (work directory for overlay)
/media/usbsda1	Vfat	rw	First USB memory, if available
/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

Table 3: File system layout for rescue system

Mount point	Filesystem	Mount status
/	Overlay	rw	Virtual merge of lower and upper dirs
/rescue/rooffs/ro	Ext4	ro	Lower dir for overlay (original root filesystem)
/rescue/rooffs/rw	Ext4	rw	Upper dir for overlay (work directory for overlay)
/media/usbsda1	Vfat/ext4	rw	First USB memory, if available
/media/usbsdb1	Vfat/ext4	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

In previous versions of CC Linux the system has forced users to save files under /opt. This is no longer necessary but can still be used if it is logical to the user.

On the other hand, CC Linux provides the OPKG packaging system which should be used to install and remove user applications and thus will provide proper locations to the files. Refer to the Programmer’s Guide for more information.

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.

Table 4: CAN-FD availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	No	Yes	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.

Table 5: Wireless LAN availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	No	No	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.

Table 6: Bluetooth availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	No	No	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 Video in

The video-in signal can be accessed and controlled using the CCAux API, in Qt using the QMultimedia framework, or directly using gstreamer. The application CCvideo has been developed to provide an example of how to use the video-in signal with QMultimedia in QML, see chapter Eror: Reference source not found.

Video input can be displayed without any significant CPU performance penalty, in one video window instance.

Table 7: Video input availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	No	No	No	No	No	No	No

3.9 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.

Table 8: Configurable input availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	Yes	No	No	No	No	Yes	Yes

3.10 Analog inputs

The analog input channels are available for software developers using the CCAux API. The voltage reading can be viewed within CCsettingsConsole for test purposes.

For additional technical details, please see the Technical Manual of your device model and the CCAux API Reference Documentation.

Table 9: Analog input availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	Yes	No	No	No	No	No	No

3.11 Digital Outputs

The user-settable digital output signals are available for software developers using the CCAux API. The output status can be viewed or set within CCSettingsConsole for test purposes.

Please note that the digital 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.

Note that the PWM outputs available on VI,Vx10 and Yukon can be used in digital out mode.

Table 10: Digital output availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	No	No	No	No	No	No	No

3.12 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.

Table 11: PWM output availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	Yes	No	No	No	No	Yes	Yes

3.13 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.

The most recent setting is always used, it is saved between restarts.

3.14 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.

Table 12: Lightsensor availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	No	Yes	Yes	Yes	Yes	Yes	Yes

3.15 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.16 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.17 Buttons

Depending on your device model there are up to 10 buttons with configurable functionality. The configuration of each button can be set using either CCAux API or CCSettingsConsole.

Table 4 lists all available configurations for each device model. For additional details, see your device model’s Technical Manual. Note that the Vx10 and Yukon uses a new button API where the term “action trigger” is not used.

Table 13: Available button configurations. Configuration can be set individually for each button.

Configuration	Description	VS	VI	X900	V700	V1x00	Vx10	Yukon
Only MP action	Button is not handled in SS. The button can be used in user software via the input event API. Button events can be read from the device node /dev/input/event2	No	Yes	No	No	No	No	No
Start-up trigger	Button is used by SS to trigger a start-up action; powers up the system or wakes up from suspend state (if supported).	Yes	Yes	Yes	No	No	Yes	Yes
Action trigger	Button is used as an action trigger (available actions listed in Table 5.) It is possible to choose one action for short presses and a different action for long presses.	Yes	Yes	Yes	No	No	Yes	Yes
Start-up & Action trigger	Button is used as both Start-up and Action trigger.	Yes	Yes	Yes	No	No	Yes	Yes
BL decrease	Button decreases display backlight intensity.	No	Yes	No	No	No	No	No
BL increase	Button increases display backlight intensity.	No	Yes	No	No	No	No	No
BL decrease & start up	Button decreases display backlight intensity and acts as a start-up trigger.	No	Yes	No	No	No	No	No
BL increase & start up	Button increases display backlight intensity and acts as a start-up trigger.	No	Yes	No	No	No	No	No

Table 14: Available actions for short/long presses on a button configured as an ‘action trigger’. Actions are set globally for all buttons.

Action	VS	VI	X900	X700	V1x00	Vx10	Yukon
No action	Yes	Yes	Yes	No	No	Yes	Yes
Shutdown	Yes	Yes	Yes	No	No	Yes	Yes
Suspend	No	Yes	Yes	No	No	Yes	Yes

X900 has dedicated buttons for BL increase and decrease.

Yukon has a dedicated power button.

Table 15: Button availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	Yes	Yes	Yes	No	No	Yes	Yes

3.18 RS232 external serial port

There is one external RS232 port which can be accessed via /dev/ttyExt0.

Table 16: External RS232 port availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	No	Yes	Yes	No	No	No	Yes

3.19 RS485 external serial port

There is one external RS485 port which can be accessed via /dev/ttyExt1.

Table 17: External RS485 port availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
Yes	No	No	No	No	No	No	No

3.20 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.

Table 18: Speaker availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	No	Yes	Yes	No	No	No	No

3.21 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.

Table 19: Audio out availability per platform.

VS	VI	X900	X1200	V700	V1x00	Vx10	Yukon
No	No	Yes	Yes	No	No	No	No