Skip to main content
Version: Torizon OS 7.x.y

Torizon Application Development Overview

Introduction​

This article provides an overview of the application development process on Torizon OS using containers.

If you want to leverage Torizon Cloud features without using containers or want to integrate Torizon in your already configured Yocto environment, check our Torizon OS Reference Minimal Image Overview.

The preferred development workflow is centered in the Torizon IDE Extension for VS Code, whenever a use case is supported by the VS Code Torizon Templates. This is the fastest path to set up an application development environment that covers evaluation, development, and production in a modern DevOps-oriented fashion.

As a fallback development workflow for use cases not covered by the VS Code Torizon Templates, this article also covers application development using Dockerfiles and Docker Compose without the Torizon IDE Extension for VS Code and the VS Code Torizon Templates.

This article is not about how to customize the OS. This topic is covered in the OS Customization section, and it explains how to enable peripherals, configure services, prepare an image for production programming that includes your final application, and more.

Prerequisites​

There are no prerequisites.

Container Images and Torizon​

Torizon OS is a minimal Linux-based OS with a Docker container engine supported.

Containers, like any approach, come with both advantages and disadvantages, as well as associated misconceptions. This section aims to elucidate the pros and cons of using containers and discuss how the Torizon ecosystem mitigates their effects. Additionally, it will address common misconceptions and provide explanations for them.

Container Images Pros​

Using container images offers several benefits:

  • Detach the development workflow: Application developers can work independently without needing to be concerned about modifying the base operating system. This separation streamlines development.
  • Decoupling application from base OS: Updates to the base OS can be done without the need to change and test compatibility for the application against new library versions, simplifying maintenance.
  • Support for diverse simultaneous workflows: Multiple development teams can use different application stacks in separate containers. For example, one team can use Qt and Python for GUI development while another uses C/C++ for control systems.
  • Vendor responsibility for OS Maintenance: The hardware vendor takes on the responsibility of maintaining the base OS, freeing up valuable time and engineering resources to focus on the unique aspects of your product.
  • Security by default: Containers have limited access to hardware resources unless you grant them permission, allowing for a more controlled and secure system design. Therefore you can design your system in a way that parts of your application only have access to a limited set of the base OS functions and devices.
  • Platform portability: Containers can run on various hardware platforms as long as a container engine is available, ensuring portability. Exceptions apply when specific hardware features are necessary, which would be an issue even without containers.
  • Efficient dependency management: You can swiftly install dependencies within your container using popular package managers and feeds like Apt and Debian packages, eliminating the need to use Yocto Project to integrate them into the base OS.

Container Images Cons and Misconceptions​

This section presents and clears some common misconceptions about containers by providing facts and how Torizon OS helps you mitigate any possible downsides:

  • You must learn about a new technology. If you are new to containers, you must learn the basics of how they work so that you can make the best of it.
    • The Torizon IDE Extension, together with templates, samples, and documentation, enables you to start developing your application even with zero knowledge of Docker.
  • The performance of the application is severely impacted by containers.
    • Containers aren't lightweight VMs. They are a means to sandbox a process from accessing resources on the outside while still using the same kernel as the base OS.
  • The storage space is inefficient as it increases with each container.
    • Due to containers using a layering system, as long as you share the same base among containers - which is the most common scenario - one can actually use less storage. A good analogy is statically and dynamic linking: container filesystem-level caching is like using dynamic libraries but for the whole application runtime.
    • Even if you decide to use one container with a different base on some occasions - for instance, a ready-to-use DB or web server container - the overhead size will range from dozens of MB to maybe a couple hundred.
    • Optimized (like debian-slim and Distroless Containers) are very optimized and can include precisely what is needed for the user application to run and nothing else.
  • The RAM overhead is big as libraries have to be loaded once for every container.
    • Shared libraries are only loaded more than once if they have different versions - which is not a common scenario as you will often use the same base for multiple containers.
    • Even when you decide to use different base containers, it is likely that the overhead ranges within the hundreds of kB to dozens of MB, and is still neglectable in contrast to a RAM-intensive application.
    • You can always statically link applications and run from a "Scratch" container, a container that has nothing but what you decide gets in.
  • Hardware access is either not possible or complicated.
    • Hardware access is possible, and our templates, samples, and documentation already solve them so you can focus on application development. GPU acceleration, and access to embedded buses, among others, are quite common.
    • Having granular permissions for hardware access is very positive for cybersecurity, and container runtimes provide a flexible and ergonomic way of adjusting these.
    • In the worst-case scenario, you can decide to run a container in a very permissible way so you are not bothered with figuring out granular permissions. You will lose a layer of security that would otherwise come with a very low cost, on the other hand, your system will be as insecure as one without containers.
  • Remote debugging on the target is not possible or complicated.
    • It is entirely possible and made easier with the Torizon IDE Extension for several languages (C/C++, Python, .NET, and many more).

Debian Containers for Torizon and Other Containers​

Embedded systems have specific hardware units that are not often supported by Linux distributions focused on server and desktop environments. Due to that, and also to guarantee quality through extensive testing, Toradex provides Debian Containers for Torizon that extend Debian containers from the community with hardware support and extensive testing.

That said, there are times when you may opt to use a 3rd party container from the community. For instance, there are several database and web server containers ready to use.

Also, if you either want or need a very small container, you can use Alpine instead of Debian, or even create your container from scratch. The tradeoffs are that you will lose the easy hardware access and extensive testing provided with the Debian Containers for Torizon.

Development Workflow Basics​

This section explains the foundation of the development workflows.

Preferred Workflow - Torizon IDE Extension​

By choosing this workflow, you must follow the articles from the IDE Extension sub-section.

You will learn, among other things, how to:

Fallback Workflow - Dockerfiles and Docker Compose​

This workflow does not depend on the availability of VS Code Torizon Templates and therefore embraces more possibilities. The tradeoff is that you won't get an environment ready to deploy, debug, and update devices either during development or production.

You will be working directly with containers to configure, build and deploy your application. Most of the container configuration and build are automated with Torizon IDE Extension.

You must learn about and figure out by yourself, among other things, how to:

Development Workflow Next Steps​

Once you have a working development environment, other questions will come up:

  • How can I use a given peripheral or hardware interface, such as GPIO, UART, SPI, I2C, CAN, and others?
  • What container offerings are provided by Toradex?
  • How can I use the Torizon Cloud to keep my devices up-to-date?

There is no single, linear workflow to answer those questions covering all possible use cases. You may want to check out:

  • The Developer Website left sidebar. Sections and sub-sections contain groups of related articles and your use case may be covered there.
  • The Developer Website search. Inspecting every single article in the Developer Website sidebar may be overwhelming, and the search is a good place to get started.
  • The Toradex Community. The Toradex team can help you move on.

Wish you a good development!

Blogs​

This section brings interesting blogs and valuable insights to your attention.



Send Feedback!