Torizon Best Practices Guide
Introduction
This article aims to give an overview on the best practices when developing applications and using Torizon OS.
Development Environment
Developing applications for Torizon can be done using command-line tools or, as we recommend, the Torizon IDE Extension. This article contains best practices that may apply in all situations using Torizon.
Working with Containers
Torizon, as explained on the Torizon OS Technical Overview, provides the container runtime and Debian Containers for Torizon, among others listed on the List of Container Images for Torizon, to simplify the developer's life and keep the development model close to one of desktop or server applications. Even though we follow the desktop and server application standards as much as possible, some requirements are inherent to embedded systems development that are divergent. One typical example is hardware access.
The article Best Practices with Containers outlines the intricacies of using a container runtime on Torizon OS, emphasizing the aspects or requirements related to using containers on embedded systems, such as hardware access, permanent data storage, connectivity management, etc.
Hardware Access
Container technology is very popular in domains where direct access to the hardware is usually restricted, like servers and cloud-based solutions. On the other side, software running on an embedded device will probably need to access peripheral devices, for example, to collect data from sensors or to drive external machinery. Docker provides ways to access specific peripheral devices from inside a container, and often one needs to grant access from both a permission and a namespace perspective. Refer to Best Practices with Peripheral Access article.
Setup Network Between Containers
By default, containers connect to Docker's "bridge" network. This configuration allows containers to communicate with the outside with no restrictions. However, it prevents them from being accessible from the outside. In the article How to Setup Network Between Containers we cover the Inter-container Communication, Inter-process Communication and Using the Host Network Inside a Container cases and the recommended practices to stablish connections between processes running inside a container.
Graphical User Interface (GUI)
The default choice for Graphic User Interface (GUI) in Torizon is to use the Wayland protocol. This requires a compositor that manages the screen and input devices and allows clients to access "surfaces" on the screen.
Torizon provides a container with the Weston compositor and clear instructions about how to run it on Debian Containers for Torizon. There is also a dedicated article for Working with Weston on Torizon OS that covers common customization options used by our customers.
GUI Frameworks/Toolkits and Wayland
Many commonly used GUI-toolkits support Wayland as a rendering back end. Usually, you need to set an environment variable that configures rendering mode.
In the following table, you can find configuration settings for some popular toolkits:
| Toolkit | Env setting |
|---|---|
| GTK3 | GDK_BACKEND="wayland" |
| Qt5 | QT_QPA_PLATFORM="wayland" |
| SDL2 | SDL_VIDEODRIVER="wayland" |
Remote Access Using VNC or RDP
By using the Weston-based Debian Containers for Torizon, you can enable VNC or RDP remote access by simply adding an environment variable. Learn more on Remote Access the Torizon OS GUI Using VNC or RDP.
Managing CPU Resources
Docker containers are a great way to isolate processes from each other on a host. This is especially useful when running multiple processes that require a lot of CPU, memory or GPU, because it prevents the process from consuming other resources. You can also limit the amount of CPU that a container can use, useful to prevent a process from overusing core resources or to ensure that containers always have a limited amount of them.
By default, a container can access unlimited resources from the host machine's CPU, i.e. has no resource constraints. Docker provides a way to control the amount of CPU in a container by setting run configuration flags with the docker run command. You can set various constraints to limit CPU cycles that a particular container can access. Configuring the CPU resources in a Docker container is particularly helpful when it comes to SoCs that have multiple cores with different computing powers, which is the case for Apalis iMX8QM and iMX8QP, for example.
To learn how to do this, refer to How to Configure CPU Usage with Torizon.