Unsolved Fresh start on an RTOS
-
I have an RTOS which only runs on x86 and currently has a console text output driven by INT10. The development tools are VS(ALL) with C++11 fully supported. It provides object, thread, memory management with FAT32 files system and TCP/IP stack and Ethernet drivers. It is not POSIX compliant, and doesn't support multi-threading in applications (not SMP) and no OpenGL ES 2.0 (or otherwise).
The desire is to run Qt to provide for HMI application needs. What is needed to get Qt enabled for this RTOS? Anyone have experience in coming up from scratch?
-
@zingbats said in Fresh start on an RTOS:
I have an RTOS
Could it be possible you name it, and provide more details? (unless it's a very protected secret...)
On the other hand, have you already checked the platforms supported by Qt?
-
Not a protected secret. It's the INtime real-time operating system, from TenAsys. Most deployments have been when the RTOS is running simultaneous with Windows so the desktop and all graphics are managed by Windows. INtime Distributed RTOS is a stand alone model (no Windows), therefor a means for having display, controls, graphics is desired. Qt has been demonstrated on Windows with INtime for Windows. It seems a good fit for the stand alone version as well.
Yes, I've reviewed the platforms list as 'supported'. INtime is nothing like any of those. Development tools are tightly integrated with MSVS, so we're only interested in a run-time engine of Qt.
-
Hi @zingbats,
Looks like a tough, but interesting project.
It is not POSIX compliant, and doesn't support multi-threading in applications (not SMP) and no OpenGL ES 2.0 (or otherwise).
That doesn't sound as if it makes things easier...
I strongly suggest you to ask this question on the Interest mailing list. Core developers are monitoring this list and can give more in-detail answers about the requirements and culprits.
There has also been an interesting blog post about the ongoing effort to let Qt run on smaller CPUs with reduced capabilities OS: http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu
Good luck! Regards
-
Thanks aha, I'll look into the 'Interest mailing list' per your suggestion.
I read the blog post of Qt on MCUs, which was encouraging, however a bit light on details of how one might proceed. The mention of OpenGL ES comes up there, when it's in contrast with the premise of the subject of using MCUs. I would like to understand more of the implementation details.
Despite not being POSIX compliant, the INtime RTOS is very full featured operating environment, just no SMP. There fully managed process and object resources with a rich set of IPC methods. What makes it 'a tough' project in your opinion?
-
If you'd like to proceed, the sensible place to start is to try to compile Qt Core using an INtime cross-compiler.
@zingbats said in Fresh start on an RTOS:
Despite not being POSIX compliant, the INtime RTOS is very full featured operating environment, just no SMP. There fully managed process and object resources with a rich set of IPC methods. What makes it 'a tough' project in your opinion?
That's answered in the blog post about MCUs (http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu ):
...in general, there are two main requirements you need to meet:
- POSIX-compatible operating system;
- C++11-compatible compiler.
Now regarding POSIX – Portable Operating System Interface. That actually answers the question why Qt does not work on “bare metal” out of the box. Inside Qt we are using a lot of POSIX functions (pthreads, mmap, fopen, open and others), so if we want to run Qt on bare metal, we need to create your own implementation of POSIX – basically implement your own operating system.
You could start stripping away the Qt features that depend on POSIX functions to make life easier, but at some point you'll probably need to write your own "POSIX wrapper" to call native INtime functions.
May I ask which Qt feature(s) you want to use?
-
Here is the link to the corresponding thread on the mailing list.