Qt application on Xenomai

C Smith csmithquestions at gmail.com
Mon Mar 4 09:38:50 CET 2019


QT will allocate/destruct memory and its overhead and timing are
unpredictable because of its signal/slot architecture - don't try to run QT
in RT space.
Instead, run your QT (C++,etc) application in userspace. Have your QT
application attach to a static shared memory segment which a xenomai RT
thread creates, and put any time-critical code into the RT thread. Send
messages on XDDP sockets (or similar fifos) between the two processes if
necessary. Your UI and multimedia graphics don't really need determinism,
they have only 'soft real time' timing requirements (they can drop frames
or finish late and the human viewer doesn't care). We've done this
architecture for years, on uniprocessor systems, it works well.
- C Smith

On Sun, Mar 3, 2019 at 11:56 PM Stéphane Ancelot via Xenomai <
xenomai at xenomai.org> wrote:

> Hi,
>
> I will share some points from my viewpoint :
>
> The Xenomai impact will depend on the processor architecture selected
> (uniprocessor or multiprocessor).
>
> In uniprocessor context, while your rt application will consume cpu
> time, meanwhile the other scheduled application will be waiting for
> their time slice.
>
> And thus GUI application is interrupted and may be slow in some cases
> (that really depends on the impact of the RT process). In multiprocessor
> context, this becomes no more a problem.
>
> Performance is then dependant on the cpu architecture (x86/x64/arm...)
> and their graphics chip device.
>
> Depending on the graphics chip, the performance needed to drive a 19inch
> size display is not the same as driving a 7inch size display.
>
> There are two kinds of Qt applications these days : Native Qt and QML
> applications.
>
> * Qt is native and can use 2D OpenGL or display framebuffer,
>
> * QML is no more than a javascript application layer running in a
> javascript web engine , in this case you will be performance mainly
> impacted by the QML architecture.
>
> If your GUI application fits only few buttons in a display, then, that's
> not a problem.
>
> Regards.
>
> Stéphane ANCELOT
>
>
> Le 02/03/2019 à 06:57, Sumitabh Ghosh via Xenomai a écrit :
> > Hi Henning,
> >
> > Thanks for your confirmation. Just to understand your set up further,
> does
> > the POSIX layer used by QT is of the Xenomai skin ? Is This the way Qt is
> > leveraging the rt features ?
> >
> > I guess the rendering of graphics is handled through non rt Linux
> > framebuffer /opengl apis.
> >
> > Let me know if my above understanding is correct.
> >
> > Thanks,
> > Sumit
> >
> >
> >
> >
> > On Fri, Mar 1, 2019, 18:02 Henning Schild <henning.schild at siemens.com>
> > wrote:
> >
> >> Hi,
> >>
> >> i am not sure i fully understand the question. In case you are worried
> >> about combining Xenomai and Qt, i can assure you that it is possible.
> >> We do have big c++/Qt applications running both rt and non-rt on
> >> xenomai.
> >>
> >> regards,
> >> Henning
> >>
> >> Am Fri, 1 Mar 2019 14:10:42 +0530
> >> schrieb Sumitabh Ghosh via Xenomai <xenomai at xenomai.org>:
> >>
> >>> Hi,
> >>>
> >>> I have a generic question not specific to any platform. If I want to
> >>> run a small graphics application on Xenomai 3.x what would be the
> >>> correct approach. e.g. Qt application framework which needs POSIX
> >>> apis and a linux frame buffer to be able to render 2D applications.
> >>>
> >>> Kindly provide me some pointers.
> >>>
> >>> Thanks in advance.
> >>>
> >>> Cheers!
> >>> Sumit
> >>
>


More information about the Xenomai mailing list