Blog:
Torizon Ecosystem: A Great Alternative to Windows CE

Windows Compact Embedded's (Windows CE) latest version, Windows CE 2013, has already reached the end of the extended support. It has been on extended support since 2018. Although Microsoft still allows license sales to continue until 2028, it is not recommended for new projects. In other words, you could consider that Windows CE is dead.

In light of that, it's time to migrate, if you haven't already, to a new platform!
But, you might be asking yourself: which one? And how?
In this blog, I’ll go over some of the possible solutions to this dilemma.

Migration or Modernization?

The term “migration” can imply that moving away from Windows CE is much simpler than it really is. There’s no guarantee that, in the process, you’ll successfully and seamlessly migrate to a new platform because the technology stack used in Windows CE is very different from modern platforms.

Unfortunately, I’d be lying if I said that you would be able to use the same code base, with no modifications, on a new platform.

The best approach would be to modernize your application using the latest technologies and tools available in the market. The migration process could serve as a good opportunity to improve your application by adding new features and modernizing the user interface.

What are the options?

That may depend on your business, product, and your company's goals. But here, let's discuss some of the available options:

Windows 10 IoT Enterprise

Microsoft offers Windows IoT Enterprise as a migration option for Windows CE customers, which is essentially an "IoT" version of the full Windows Enterprise. In other words, it is fully compatible with the Windows ecosystem for PCs.

Microsoft lists on its Minimum Hardware Requirements for Windows IoT Enterprise page that the OS supports a list of processors from Intel, AMD, Qualcomm, and NXP.

So what are the cons? Developers and manufacturers might face the following challenges:

• There is no list of development boards or computer-on-modules (CoMs) that support Windows IoT Enterprise. That means that support for a custom board is solely the product's manufacturer or developer's responsibility.
• Support for drivers is limited to those supported by Microsoft.
• Another con is the licensing cost. Windows IoT Enterprise is not free, and the licensing cost can be high, depending on the number of units to be produced. The costs of maintaining a customized board can be quite high, as seen here: “Cost and the degree of customization are the key factors in this decision, with both generally increasing as you customize further.”

Although this is the path that Microsoft recommends to “migrate” from Windows CE, it does not mean that the migration will not require you to modernize your solution in one way or another.

That's where another option comes in: Embedded Linux-based platforms.

Embedded Linux

It is a fact that Linux is one of the best options for embedded systems. The support offered by hardware manufacturers for Linux is well-known and documented, making it the platform of choice for BSP (Board Support Package) implementation for most SoC manufacturers.

Does it have any cons?
The learning curve can be a bit steep for those used to the Windows ecosystem. Furthermore, this curve can be exponentially higher if your company has to maintain a customized Linux distribution for your product.

Using Popular Desktop Linux Distributions

Ubuntu, Debian, Fedora, and Arch Linux, among others, are very popular Linux distributions for desktop use. You may have already heard of some of them.

How about using one of these distributions for your embedded Linux product? After all, they are very popular, have a large developer community, and are under active maintenance.

Despite being a tempting option, there are several problems with using a desktop distribution for your embedded system:

• Hardware Support: Desktop distributions are designed for desktop use for the most common hardware in the market. That means they may not have the necessary Kernel architecture, drivers, and support for your embedded hardware. You may need to add more drivers and support for your embedded hardware, which can be a challenging task.
• Large Storage Memory Footprint: Desktop distributions are designed to be generic and support a wide range of hardware and peripherals common in the desktop world. That means they come with a lot of software packages that you may not need for your embedded system. That can lead to a large storage memory footprint, which is not ideal for embedded systems with limited storage.
• Customization Effort: You will need to spend a significant amount of time and effort to customize the desktop distribution to meet the requirements of your embedded system. That includes removing unnecessary software packages, configuring the system to have the right boot services, starting the applications, and optimizing the system.
• Update System: Desktop distributions are designed to have a system for updating software packages that may not be suitable for embedded systems. Embedded systems are often required to meet standards and specifications to ensure secure and reliable updates. You will need to implement a system for updating software packages suitable for embedded systems that meets these requirements.
• Maintenance and Reproducibility: Additionally, you will need to maintain this "custom distribution" after customization, which can be resource-consuming. You will also need to ensure the custom distribution is reproducible, meaning you can recreate the same distribution and generate production images consistently. It will require a significant effort to maintain a build system to generate the images of the custom distribution.

A good read on the topic is the following blog post: Why bare-metal Debian (and Raspberry Pi OS) is not a good choice for most Embedded Systems.

Android

Android, which is Linux-based, is essentially an embedded Linux with a well-defined distribution and development ecosystem. That means you'll have the pros of Embedded Linux with good hardware support. Furthermore, Android is a very popular platform, with a large community of developers and a vast number of libraries and frameworks available.

Cons? Maintaining an Android distribution just for your product is not a trivial task. Although the platform is very popular, for application developers, finding experts in the OS internals is not as easy as finding embedded Linux experts. Google doesn't support custom Android distributions, which means you'll have to maintain your own distribution or rely on a third party to provide support.

Torizon OS

You may have noticed a recurring problem with the options listed above: You will have to maintain your own Linux distribution or Android distribution or support your custom board software in some way to use Windows IoT Enterprise.

But what if I told you that you can have the best of both worlds? The solution that encompasses the advantages we shared before is Torizon OS.

Torizon is a Linux distribution and an entire ecosystem of development tools maintained by Toradex. It is Open Source, provides free support for Toradex Computer on Modules customers, and includes Common Torizon, which provides support for third-party, non-Toradex boards and modules.

Torizon OS Comparison with Windows CE

But talk is cheap.

In the following lines, I want to show you a comparison between Windows CE and Torizon OS. Linux and Windows CE are like apples and oranges, but the Torizon team has worked to make the migration and learning curve as smooth as possible.

BSP (Board Support Package)

Toradex provides BSPs for Windows CE for Toradex System on Modules. If you need to customize the Windows CE BSP, Toradex provides the Microsoft Platform Builder solution files. Note that in the case of Windows CE, some BSP drivers are provided by Microsoft, and there is no access to the source code.

In Torizon's case, the BSP is also provided and maintained by Toradex, based on the SoC manufacturer's BSP. If you need to customize the BSP, the entire project is Open Source and available on GitHub.

Development Tools for BSP

With Windows CE, development tools are provided by Microsoft, which includes the Microsoft Platform Builder. The development environment is based on Visual Studio, which requires a specific license to access and use the Platform Builder feature.

With Torizon, the BSP is developed using the Open Embedded and Yocto Project. The development environment is based on Linux tools, which are Open Source and free.

OS Customization

If you come from the Windows CE world, you might argue that it was very rare to have to modify the Windows CE BSP. That is if your hardware vendor kept the BSP up to date and provided debug and release images. But if you needed to modify the BSP, you would use Microsoft Platform Builder.

For Torizon OS, the goal is to provide a comprehensive Operating System complete with all necessary drivers and features. If, for any reason, you need to modify these drivers or add customizations to OS services and features, you can utilize the TorizonCore Builder. This tool allows for in-depth customization and modification, providing users with the flexibility to tailor the Operating System to their specific needs.

Microsoft Platform Builder x TorizonCore Builder

The Microsoft Platform Builder project was not only used to modify the BSP but also to customize features of the base Windows CE OS, such as to enable or disable drivers, features, services, libraries, and applications. It also generated binaries for debugging and release.

Similarly, the Torizon OS ecosystem offers the TorizonCore Builder. TorizonCore Builder is a command line tool that uses a configuration file in YAML format. The YAML describes the version of the base OS to be used and which configurations, drivers, customizations, and applications will be included in the final OS for production.

GPIO Pin Muxing Configuration

On Windows CE, the GPIO configuration was done through the Toradex GPIO Config Tool. This tool allowed the developer to configure the GPIO pins of the SoC, setting the pin alternate functions, GPIO, PWM, I2C, SPI, UART, etc.

These configurations were stored in the registry and were read by the driver at boot time. The driver was responsible for configuring the pins according to the registry settings.

In Torizon, the pin muxing and configuration are done through the Device Tree.

The Device Tree is a data structure used by Linux that describes the hardware components of the system. It's compiled into a binary file, which is read by the Linux Kernel at boot time. Here is an example of what it looks like to configure a pin for its alternate function (UART) in a Device Tree overlay:

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,colibri-imx6dl", "fsl,imx6dl";
    fragment@0 {
        target = <&uart1>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&pinctrl_uart1>;
            status = "okay";
        };
    };

    pinctrl_uart1: uart1grp {
        fsl,pins = <
            MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x80000000
            MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x80000000
        >;
    };
};

These overlays can be compiled and added to a custom image using the TorizonCore Builder.

Device Tree is a powerful hardware description tool. Although the learning curve can be a little steep, you don't have to worry! We have comprehensible documentation available on the Toradex developer website for you to learn:

• Pin Multiplexing - Changing Pin Functionalities in the Linux Device Tree
• Device Tree Overlays on Torizon

Also, our team of FAEs is always available to help you in our community.

Application Development

Visual Studio Smart Device Projects

No one can deny that developing applications for Windows CE was very easy. The development environment was well-integrated into Visual Studio, with support for C native, Visual Basic, or C# with .NET Compact Framework.

The development of graphical applications with WinForms support, with Visual Studio's famous drag-and-drop designer tool, made for simpler times. There wasn't as much demand for responsiveness across different screen resolutions.

The integration of Visual Studio Smart Device projects also made it possible to remote deploy and debug directly on the target. Where after build and deployment, Visual Studio automatically connected to the debugger, allowing debugging of the application running on the target:

Torizon IDE Extension Visual Studio Code Templates

One of the focuses of the Torizon ecosystem is maintaining this ease of development experience that developers had with Windows CE. To this end, we have the Torizon IDE Extension for VS Code.

The Torizon IDE Extension for VS Code simplifies the development process by providing ready-to-use templates and integrated tools for remote deployment and debugging. That means you can focus more on developing your application and less on setting up your development environment.

There are more than 24 templates that can be used. Among them, you'll find templates for applications in C, Python, Node.js, .NET, Java, Rust, and others. Torizon is not limited to a single development framework. In all these templates, we seek to maintain the same development experience well-integrated with Torizon OS, supporting build automation, remote deployment, and remote debugging.

There Are so Many Options

With so many templates, frameworks, and languages, you might be thinking now: “Where do I start?”

If you're transitioning from the Windows CE world, where you used the Visual Studio integrated environment with Smart Device projects and C#, we highly recommend starting with a Torizon C# GUI template.

Since the release of .NET 3.1, you can now use .NET and C# to develop applications for Linux on arm. The Torizon IDE Extension for VS Code provides .NET templates and supports Graphical User Interface development with two frameworks: Uno Platform or Avalonia UI. These two frameworks use C# and XAML to create graphical applications.

Following this recommendation allows you to leverage your existing C# and .NET skills, while also taking advantage of the powerful features and flexibility Linux provides.

Mono and WinForms for Linux

Perhaps you have a legacy application developed in Windows CE with C# and WinForms. If you want to migrate this application to Torizon, you can try the Mono Project to run your application on Linux.

Mono is an Open Source implementation of the .NET Framework, which allows you to run .NET Framework applications (versions before .NET Core) on Linux.

However, it's important to note that the Mono Project is not a fully-compatible implementation of the .NET Framework. Some features of WinForms are not implemented in Mono.

Additionally, the WinForms implementation in Mono is currently in maintenance mode, meaning no new features or ports are expected to be added to the project. Therefore, you will need to test your application on Mono to see if it works correctly and adjust the project as necessary.

Torizon IDE Extension for VS Code provides a template for Mono WinForms applications for evaluation, which allows you to create a project, build, deploy, and debug your application directly on the target running Torizon OS.

Hardware / Peripheral Access

In embedded systems, it is very common for the project to require access to specific hardware or peripherals. When talking about Windows CE, hardware access was generally done through native drivers, which were developed in C or C++, with direct access to the hardware's memory addresses mapped. Ultimately, the developer had to do 'bit bashing' and write their own 'user driver' to control the hardware.

Of course, Toradex provided basic hardware access libraries, so the developer could use something higher level to access the hardware instead of "bit bashing" the pins registers. Below is an example of how to access GPIO in Windows CE using Toradex libraries:

#include <windows.h>
#include "gpio.h"

int main()
{
    HANDLE hGpio = NULL;                ///< handle to the GPIO library
    DWORD sodimm = 101;                 ///< Hardcoded Sodimm Pin Number
    uIo io = COLIBRI_PIN(sodimm);       ///< Helper macro to create a static ioColibriPin structure
    BOOL success;

    hGpio = Gpio_Init(NULL);                ///< Init GPIO library
    success = Gpio_Open(hGpio);

    Gpio_ConfigureAsGpio(hGpio, io);        ///< Set SODIMM Pin  as GPIO
    Gpio_SetDir(hGpio, io, ioOutput);       ///< Set SODIMM Pin direction as Output

    while(TRUE)
    {
        Gpio_SetLevel(hGpio, io, ioLow);        ///< Set the logic level of SODIMM pin  to low
        Sleep(500);
        Gpio_SetLevel(hGpio, io, ioHigh);       ///< Set the logic level of SODIMM pin  to high
        Sleep(500);
    }

    success = Gpio_Close(hGpio);
    success = Gpio_Deinit(hGpio);

    return(TRUE);
}
</windows.h>

In Torizon, which uses the Linux Kernel, hardware access is done through Kernel drivers. It is the Linux Kernel's responsibility to manage hardware access, and the developer generally communicates with the Kernel through system files.

For example, to access a GPIO, the developer opens the file representing the GPIO bank, /dev/gpiochipX, where X is the GPIO bank expected to open, and performs IOCTL operations to configure a specific pin. We also have libraries that help us open these files and easily execute IOCTL. Here's the same example of accessing GPIO, but now using the Linux libgpiod library:

#include <stdio.h>
#include <unistd.h>
#include <gpiod.h>

int main()
{
    struct gpiod_chip *chip;
    struct gpiod_line *line;
    const char* sodimm = "101"; // Hardcoded SODIMM pin number (for libgpiod it's a pin name)
    int ret;

    chip = gpiod_chip_open("/dev/gpiochip0"); // Open the system file that handle GPIO bank 0
    line = gpiod_chip_find_line(chip, sodimm); // Find the line that represent the SODIMM pin 101
    ret = gpiod_line_request_output(line, "demo", 0);

    while(1) {
        gpiod_line_set_value(line, 0); // Set the logic level of SODIMM pin  to low
        usleep(500000);
        gpiod_line_set_value(line, 1); // Set the logic level of SODIMM pin  to high
        usleep(500000);
    }

    gpiod_line_release(line);
    gpiod_chip_close(chip);

    return 0;
}
</gpiod.h></unistd.h></stdio.h>

An interesting detail is that libgpiod is not a specific library for Toradex hardware. Access to hardware interfaces in Linux follows well-defined standards. If the hardware manufacturer implements this standard in their Linux BSP, access to the hardware is standardized independently of the hardware manufacturer. That makes it easy to find libraries and examples of using these libraries for Linux.

There is a very good page about the topic on the Toradex Developer website:

• Peripheral Access Overview

Graphical User Interface / Desktop Environment

On Windows CE, the graphical interface was based on the Windows GDI (Graphics Device Interface) and the Windows CE API. From .NET, the development of graphical applications was done using the WinForms framework. In the last versions of Windows CE, Microsoft also added support for WPF (Windows Presentation Foundation) and Silverlight.

The desktop environment was very simple, with a taskbar, start menu, and the ability to run multiple applications at the same time in different windows, even though, generally, product applications were single windows in full screen. The desktop environment was very similar to the desktop version of Windows 98 but with a simpler interface.

On Torizon OS, the desktop environment that is recommended and supported by Toradex is Weston.

Weston is a reference implementation of a Wayland compositor, which is a protocol that defines the communication between the graphical application and the display server. Weston is a simple compositor, but it is very powerful and can be customized to meet the needs of your product.

During the development of your application, you can use the Weston compositor as a normal desktop environment, with a taskbar, start menu, and the ability to run multiple applications at the same time in different windows:

For production, you can configure Weston to run your application in full screen, without the taskbar and start menu:

These modes are supported out-of-the-box by the Torizon team, and you can toggle between them using a simple --developer argument.

Conclusion

The migration from Windows CE to a new platform is a complex process, but it is also an opportunity to modernize your application. The Torizon OS ecosystem was designed to make this migration as smooth as possible, maintaining the ease of development that Windows CE was known for.

Torizon OS is a Linux distribution, maintained by Toradex, which provides a complete development environment, with tools, libraries, and support for hardware access. The Torizon OS ecosystem is Open Source and free with no lock-in to Toradex hardware, supporting third-party boards and modules.

If you are considering migrating from Windows CE to a new platform, I recommend that you take a look at the Torizon OS ecosystem and all the good work we have done to provide a great and easy development experience.