Dear Herman and Akhil,

thank you for your interest and response!

I think, that until somebody actually start to use Orocos@QNX the main (but
really good!) goal
is just testing platform independence... As I have mentioned - I have
already caught some minor
issues related to STL conformance with QNX's compiler, which is definitely
more restrictive
about this. (I have separated those fixes into individual commits, so they
can be easily picked
with Git).

QNX is the most POSIX-compatible system I know and does it since a long time
ago...
In fact - the only fixes required to port gnulinux files to QNX were about
Linux non-conformance to POSIX!

The reason that my lab is using QNX is in fact a bit about legacy. We have
started to play
with QNX4 several years ago. At that time there was no RT competition at
all. QNX allows
for RT between processes running in protected memory model - this has
strongly influenced
our software and now it is structured into processes instead of "components"
(i.e. shared libraries,
which execute inside one address space). QNX also allows for handing
interrupts in userspace
without any tricks, which is much more than most of the opensource like
RTAI/RTEMS can do...

The community support nor development tools for QNX are not as great as for
userspace gnulinux
port, but please do not forget, that CDT (C/C++ Development Tools) for
Eclipse is from QNX! There
also exist many other QNX tools specialized for RT development.

The bad side (and the reason why we are looking at the open-source
alternative) is device drivers
and third party software support, which is much behind Linux. There are
application, where RT is
not really required, but we want to use our software - i.e. a mobile
robotics. In such a application
please forget about QNX. You will have to spent most of your time looking
for supported WiFi and
framegrabber just to realize, that you still have to make OpenCV and QT
running at QNX...

I think the real pros of Orocos@QNX would be to run distributed components
in RT. This is possible
with QNX proprietary network protocol, QNET. OK, I doubt to what extend
there can be RT over Ethernet,
but QNX claims it is RT and certainly it is with more "RT" networks, i.e.
Profibus. The question however
is about Orocos and it's bindings to Corba. It is not easy to build working
ACE+TAO or OmniORB package,
and even then - I think they will not use QNET transport. If it would be
possible to distribute Orocos
just with Send/Receive/Reply concept - then we are home.

Piotr

On Mon, May 17, 2010 at 17:28, Madhani, Akhil J
<Akhil [dot] J [dot] Madhani [..] ...>wrote:

> We are now using Orocos/RTT as part of a development project here at
> Disney. While we are developing in Linux, platform independence is
> certainly a selling point to have Orocos be accepted by the larger Disney
> community.
>
> Without discussing the pros/cons of QNX, I will say it does tend to be one
> of the leading contenders in any discussion of commercial RTOS. It seems to
> me that a maintained port to QNX would certainly lend credibility (and
> testing) to the stated goal of platform independence.
>
> -Akhil
>
>
>
>
>
>
> Akhil J. Madhani, PhD
> Technical Staff - Director
> Walt Disney Imagineering R&D
> 1401 Flower St.
> Glendale, CA 91201
> Office: (818) 553-6839
> Cell: (818) 641-4481
> akhil [dot] j [dot] madhani [..] ...
>
>
> This electronic message transmission contains information which may be
> confidential or privileged. The information is intended to be for the use of
> the individual or entity named above. If you are not the intended recipient,
> please immediately notify the sender at (818) 553-6839 and delete this
> e-mail message from your computer. Be aware that any disclosure, copying,
> distribution or use of the contents of this information is prohibited.
> Thank you.
> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:
> orocos-dev-bounces [..] ...] On Behalf Of Herman Bruyninckx
> Sent: Sunday, May 16, 2010 11:34 PM
> To: Piotr Trojanek
> Cc: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] Orocos port to QNX
>
> On Sat, 15 May 2010, Piotr Trojanek wrote:
>
> > I am happy to announce an initial (but quite reasonable) port of the
> Orocos
> > to the QNX real-time OS, http://www.qnx.com/ has been comleted.
>
> Great! Probably it deserves a mention on the Orocos.org home page...
>
> > i have just pushed it to my GitHub repository,
> http://github.com/ptroja/orocos-rtt-qnx
> > - see branches rtt-1.0-svn-patches-qnx and rtt-2.0-mainline-qnx.
> >
> > While QNX is propertiary system, so you can find it a bit against the
> open-source
> > philosophy,
>
> It's not more "strange" than the efforts to make RTT run on Windows or MAC
> OS X :-)
>
> > I think that this port can be at least *interesting*.
> > Actually most of the QNX source code is now
> > open - legal fans can take a look at this site:
> http://www.qnx.com/news/pr_2471_1.html
> >
> > The exact build procedure is a bit tricky - you need to install a
> cross-development
> > headers
> > and libraries from my http://github.com/ptroja/qnx-cross/downloads.
> >
> > The current status is as follows:
> > * all RTT compiles cleanly, both for 1.x and 2.x branches,
> > * most of the tests programs fail (but not most of the test cases!) -
> which I guess is
> > not so bad,
> > * OCL needs some hand-help to compile, but the basic set of components
> (helloworld,
> > deployer,
> > timer, taskbrowser and reporter) seems to work properly.
> >
> > During the port I have discovered some minor STL issues, like missing
> headers or std::
> > namespace prefixes (QNX C++ compiler is more restrictive about this). I
> think those can
> > be safely applied to trunk (I could only check, that gnulinux target is
> happy with those
> > fixes).
> > Other changes are QNX specific, but they do not pollute Orocos source
> tree at all.
> >
> > The the final question is... Are there any interest in the community in
> sharing and
> > improving this port?
> > I think there is no point to have just another dead-port to maintain in
> the source tree
> > (I think there
> > was such a story of RTEMS port some time ago...). I think, that QNX is
> very interesting
> > platform
> > for Orocos, but there must be also interest of users to make it live and
> work :-)
>
> There is of course the other "final" question: what are the pros and cons
> of supporting QNX? Or other "less popular" OSs?
>
> I mean this as a serious question, to which I would welcome motivated
> arguments, since making Orocos platform-independent was an _objective_
> since day one...
>
> Phrasing the question a bit differently: what is realtime Linux missing wrt
> QNX, RTEMS, VxWorks...? There is at least one thing I can come up with:
> certification! But there are probably other arguments, or am I wrong...?
>
> For example, Piotr, what is your lab's motivation to go for QNX instead of
> Linux?
> Legacy? Support? Features?
>
> > Best regards,
> >
> > --
> > Piotr Trojanek
>
> Herman
>
> > Robot Control and Recognition Systems Team,
> > Institute of Control & Computation Engineering,
> > Warsaw University of Technology
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

QNET has nothing to do with real-time communication.

 and certainly it is with more "RT" networks, i.e. Profibus.

PROFIBUS allows a bus cycle of 100us e.g. with a jitter of 5us ... can you do this with QNET ?? No, no ... PROFIBUS provides much more predictable real-time than QNET!

Regards

Armin Steinhoff

http://www.steinhoff-automation.com

Dear Armin,

I think I am missing something... QNET is layer for a distributed
inter-process messaging.
It does his job at a kernel level (in opposition to any TCP/IP based
protocol, i.e. real-time CORBA).
As a QNX rule - a server task priority is changed to the client's priority
when the request arrives.
No matter if the request arrive from local or remote client. So this allows
for managing priorities
of distributed tasks.

>From the other hand we know, that Ethernet introduces somehow unacceptable
jitter - so we
do not want to use Ethernet as a QNET's transport. But it is still possible
to use Profibus
or even a bare RS232 as a transport layer for QNET with help of devn-fd.so
driver:
http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/d/devn-fd.so...

My conclusion is, that combining QNET messaging with real-time data link
layer you can
get transparent, distributed messaging without loosing any of the real-time
capabilities you
have on local QNX machine.

Regards,

On Wed, Jun 9, 2010 at 16:05, wrote: