On Sun, 23 May 1999, Hosam Fathy wrote:
> 1-Does RT Linux support POSIX.4? If yes, does NT also support it?
Isn't this POSIX real-time support?
I don't think NT supports this; I've heard the basic POSIX subsystem of NT
is quite poor and was a minimal implementation to meet the U.S.
government's specification of a "POSIX-compliant" OS in certain
applications. (That is, it was added to sell NT to the U.S. government,
not to be useful.) I've made minimal use of it myself, so I could be
wrong. I know NT threads are not posix threads, if pthreads are part of 4.
I don't know if Linux meets this POSIX level either, actually. There were
some patches floating around to do some of the POSIX real-time stuff,
these may be in the 2.2 kernel.
Perhaps you are more concerned about standard C/C++ porting issues.
If you have a lot of Win32 calls (e.g ReadFile/WriteFile), as opposed to
standard C calls, there will be a bit of work ahead of you. You could
possibly devise some macros to make things go faster, or just bite the
bullet and re-write (it will be clearer in the long run).
The cygwin (www.cygnus.com) port of gcc may be useful, but I'm not sure.
It was really devised to help get FSF and other UNIX applications onto
the Win32 platforms.
> 2-What strategy would you recommend for porting the software?
Having been through this before, there are two ways to go: (1) try a lot
of tools to make things work (e.g. there is an MFC for UNIX kit available
from Bristol(?) or WindRiver(?) or somebody (try a google search,
www.google.com), you could investigate that (and pay big $$ for it), it
might be useful; similarly you could look into the POSIX compliance
issues, etc.) or (2) accept the fact that you need to do a re-write.
My guess is that if you opt for #1 you'll waste a lot of time and end up
at #2 in any case.
Accept it as a great lesson that you should always measure/characterize
things yourself at the start of a project, and *never* *ever* rely on the
vendor's claims. I know I have, I was also bitten by Microsoft's notion of
"on-average" real-time. Like you, I'm not a real-time engineer, but a
chemist, and my users, like yours, requested a Windows95/NT interface.
Luckily, I found NT's >60ms gaps in "real-time" priority a little ahead of
you (about this time last year, actually).
I considered keeping my NT GUI and using a network interface to the
RT-Linux box to do control and collect data. In the end, this didn't work
for my application because I wanted to stream a lot of data to the GUI
and it was more efficient on the same box. This may work well in your
case, however.
I know re-writing an application is a major bummer, but I can share with
you some tools I've found useful:
(1) Code Crusader (jcc) -- A great editor and coding environment; not
quite the VC++ IDE, but quite usable.
http://www.cco.caltech.edu/~jafl/jcc/
(2) Fast Light Toolkit -- A great, easy to use/understand GUI toolkit
(and, it's cross-platform with Win32). This is
just a simple toolkit, not an application
framework like MFC. For my application it was
better than MFC; Fluid, the GUI designer is great.
htttp://www.fltk.org/
(3) Mesa -- OpenGL for Linux, this works well with FLTK, and OpenGL is
cross-platform. It takes a bit to learn OpenGL and
may not be needed in your case unless you require
pretty 3D graphics (or like the cross-platform
aspect).
http://www.mesa3d.org/
The FLTK/Mesa combo is particularly nice because you can bounce back gui
code written in Linux to NT (and vice-versa).
If you need threads, I've heard good things about the QP library. If you
need communications, ACE is supposed to be good. Both of these have been
used with FLTK if I recall correctly.
In addition, pick-up a good book on programming in the UNIX/Linux
environment, like Stevens' _Advanced Programming in the UNIX Environment_.
This is just a great reference.
Since you may end-up rewriting a lot of code, you may want to rethink your
design as well, _Design Patterns_ by Gamma, Helm, Johnson, and Vlissides
is a good resource. I found the Singleton design pattern particularly
useful (e.g. as the communication class to the RT-tasks). I'm using a
singleton<-->singleton/mediator<-->gui type of design; the first singleton
just handles communications with the RT-task, the mediator handles all
other calculations and processing, and the GUI is Fluid-generated GUI
class.
> 3-Our software needs to communicate with 10 GPS receivers simultaneously
> through COM connections. How hard is it to develop Linux drivers for
> special-purpose serial boards?
>
Not particularly hard. You just need good documentation and some time. The
board in question may already have a standard Linux driver, and there is
the rt-com stuff for RT-Linux that may be useful.
Good luck!
-Don
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
