I think POSIX will make it very l vastly easier. But a graphical raster framebuffer should be doable. Look at QPA, the platform plugin architecture and see what you can adapt.
Warning: I've never tried to do it. > Sent: Thursday, September 27, 2018 at 2:09 AM > From: "Kim Hartman" <kim.hart...@tenasys.com> > To: "interest@qt-project.org" <interest@qt-project.org> > Subject: [Interest] Porting Qt to our RTOS > > I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed > RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX > compliant). Currently the RTOS has only a text console output based on INT10 > services. The RTOS is fully preemptive, with strict priority based > scheduling, managed process services with rich IPC services. The development > environment is tightly coupled with MS VC (2008 and on) with ANSI C and C++11 > language support. The RTOS is very stable and been commercially deployed for > decades. It lacks a means for graphical programming, mostly for industrial > controls application. What is the means to port Qt to this RTOS? We're not > intending on building out OpenGL ES 2.0 unless absolutely necessary. I've > read some marketing materials about Qt on MCU, however the details seem very > thin. It's not Windows, Linux, OSX, Android, QNX, Integrity, or VxWorks... > how to go about getting this done? > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
