Hello,
We have been supported by a 3rd company in trying to make a porting decision, with the idea of moving from T20 WinCE7 to iMX8.
We are still deciding which UI framework to choose, trying to see of the Qt commercial license costs can be avoided. We have been given some options, like Qt(commercial/free), Silnt, and some other non-C++ UIs (like SkiaSharp or Avalonia).
We have also been given an alternative OS we could choose that could also lower the migration cost, Windows 10 IoT
Now, I understand from a variety of posts in both your website and this forum (e.g. this or this) that mine might be a rethorical question, but I’m going to ask it anyway: How is the current Toradex support situation for W10IoT, especially on iMX8? Would it be viable?
What follows is the list of all the usages we made of T20 (OS-wise and Toradex libs-wise) so far for our application:
Toradex libraries to use hardware capabilities in both our main application and our installer/updater application:
I2C towards an external RTC and 3 other components.
GPIO
Interrupt
PWM
MapMem (to access and set the display driver strength for the Tegra T20, but I guess we won’t need it for the iMX has for sure a better way to do that);
COM ports:
the well-known wceusbsh001 ( “\$device\com0” on the device side) that allows us to use the same USB port connection the WinCE is using for connection and debug
around which a driver has been built for WIndows ages ago that would allow our PC application to recognize and connect to our devices through the WinUSB DLL, as suggested by Toradex
a COM port toward an internal microprocessor mounted on our custom mainboard;
a COM port toward an internal Bluetooth SMT module mounted on our custom mainboard;
WinCE7 OS features we use:
We obviously use the OS in many ways (registry editor, libraries, APIs, etc). Is Torizon emulating it, and to which degree? Will we be able to use e.g. the Registry?
The Waveform Audio API for: reproducing recorded audio wav files, through the system API “PlaySound()”, and recording input audio from a USB-connected microphone;
The DirectShow library (compiled as a project inside our application) for acquiring video live feed from a USB-connected camera, and taking screenshots of it;
The WLANAPI to establish a wifi connection via a USB wifi adapter LM816, and the winsock2 (ws2.dll) to perform tcp connections;
The SHLoadImageFile from the CEaygshell.dll library to load jpeg images and convert them in bitmapt to show onscreen;
The winreg.h to set some registers from inside our applications
The winuser.h ChangeDisplaySettingsEx to query the display orientation (the device has an accelerometer inside via i2c telling us what to do)
The wingdi.h AddFontResource to load our own font files;
and more
From the PC:
Debug connection between Visual Studio 2008 and the device itself.
Waited for a reply… but nobody else has commented.
We have experience with WinCE 5 and WEC 2013. We tried Win10 IoT and found it was not a “real” product from Microsoft. After an initial splash, the CPU and SoM support has been practically non-existent. For example, after the first RPi release, or two, there was no follow-up support for new RPi hardware revisions. Major features stopped working and there was zero response/support from Microsoft.
Win10 IoT apparently is/was a “toy” project at Microsoft and is not a reliable platform for professionals IMO.
Toradex seems very set on Torizon as the path forward from WinCE. Unfortunately we have not found any shortcuts other than a full port effort to move from WinCE to Torizon. I personally do not care for the complexity of the additional layers of Torizon utilizing Docker, which seems more oriented to web/database oriented projects than instrument firmware that requires tight integration with hardware. We preferred just starting with a Debian distribution (there is still some support for now in the Toradex ecosystem) and building on that. With the modern SoMs with fast multi-core CPUs and plenty of RAM/Flash, trying to cut down the deploy footprint with Yocto seems rather unnecessary complication. The general Debian distribution has better support for numerous development libraries.
I have engaged in arguments with more experienced developers herein that believe compartmentalizing functionality as Torizon attempts to do is the modern way forward. I just don’t understand the need for more complexity if you are building a standalone instrument that doesn’t need continual extensibility. Plus, it seems like all the exceptions you have to make with Torizon to bypass its compartmentalization to access hardware/networking/etc. just leads you back to the same place as using a standard Linux distribution anyway.
Unfortunately we don’t plan to support Windows 10 Iot (or the Windows 10/11 on ARM) anytime soon.
This could change in future, but at the moment this is what i can say.
This is unfortunate as Windows 10 would allow a seamless migration of the UI app to an emulated CE environment running on top of Windows 10.
Of course we will still support Windows CE as long as it’s possible and we sell HW that supports it.
Is there any reason why you cannot migrate from T20 to iMX6? We would still have WinCE support there.
Porting to iMX6 was an option in the earlier decision making, where we went for iMX8 for mainly two reasons:
The entire WinCE ecosystem will cease to be licensed by 2028, so porting to iMX6 WinCE won’t be a final solution, and the porting will need to be repeated in about 5 years. Can you confirm this btw? I would not like to discover later on I was under a false or exaggerated impression;
I was under the impression, mostly by Toradex’s own comparison judgements, that iMX6 compared to T20 would result in a loss of performances. Of course this would need to be confirmed based on the actual project benchmark.
Perhaps you might help me understand how true this is, considering: we use T20 to, amongs other things: show camera live feed through DirectShow lib, show videos on screen (actually they are jpeg files in sequence), reproduce groups of wav files from the SD Card, and more or less our entire UI is made of button-based bitmaps images.
If you still consider iMX6 viable for this type of usage, we might eventually consider it (also depending on how much in a pinch we are).
Also, apart from the iMX6 escape route, we are currently about to reach agreements with a 3rd company that would take care of part of the migration for us. They recently shared a new cost-effective alternative migration path:
“Migrate to Linux with the selected Toradex board. Emulate Windows inside the Linux environment”.
I was curious: do any of you at Toradex (or any reader or other customer that have/had to migrate) think this would be possible?
Thanks for the interesting discussion. To add a bit of flavor from the Toradex side, we find that the flexibility of containers makes it very easy to create a large fleet of identical devices while giving a very convenient delivery and packaging mechanism to deploy updates to the applications. The immutable nature of the underlying OSTree root filesystem guarantees that the bag of bits being deployed to your devices in the field is identical to what you have tested internally. Using a package-based update mechanism can result in significant package version creep unless you are extremely careful about what and when you update. But adding the container level on top means you can run Debian or other distro inside the container giving you a nice familiar environment to develop your app.
We also support custom Yocto builds using the Torizon layers for those who don’t like or want containers. Admittedly that is a steeper learning curve than using a native debian and does not provide (easily) things like network-hosted package feeds and such but is obviously a common solution in the connected Embedded device space.
