pat@grebyn.com (Pat Bahn) (06/09/90)
What real time operating systems are available for the big motorola processors? we are lookig at building a voice processor. and need to look at OS's. I think MACH may have Real/time capabilities but the manager is pushing OS/9 and I think that's a bad idea. So my colleagues, what do you all think? Everything I've done in real-time we wrote on the machine and did ourselves. -- ============================================================================= Pat @ grebyn.com | If the human mind was simple enough to understand, 301-948-8142 | We'd be too simple to understand it. -Emerson Pugh =============================================================================
teape@hslrswi.UUCP (Andrew Kiggins) (06/27/90)
>In article <20124@grebyn.com>, pat@grebyn.com (Pat Bahn) writes: > You might want to check out: > VxWorks Wind River Systems 415-428-2623 > VRTX Ready Systems 408-736-2600 > We've chosen the VRTX OS, mainly for political/historical reasons, however we still need to get a development environment. Ready Systems do a package called RTC/Hyperlink, there's VxWorks, and Teltronix have an environment. This all has to run on SunOS BTW. Cost wise there's not much to choose and on paper they look pretty similar, although VxWorks has all sorts on neat dobberies for device driving and they've offered to port is for VRTX. What I'd like to know is is there any problem the salesperson isn't going to tell us about. I'd be glad of any information from someone who has used the stuff. Once we've chosen I'll be glad to pass on any info or amusing anecdotes :-). Reply be email, or post, as it seems there's a number of interested parties out there. Thanks in advance Andy. A Andy.
cb1p+@andrew.cmu.edu (Chris Beasley) (07/13/90)
Here at RedZone robotics we have been using VxWorks with the Wind kernel from WRS for about a year. We have several complaints although we havn't found anything better yet (we are looking into os9). 1) Select: This is the single largest problem we have hd to date with VxWorks. Select polls instead of blocking like on Unix. When asked to fix this WRS said it was in the works. The fix they came up with was more efficient polling. This of course is not a fix. Also, select only works with sockets and not with any old FD as on Unix. In the first version we had pipes, stdio and other FD's worked even though the manuals said they wouldn't. The more efficient polling version now lives up to the documentation and only works on sockets. 2) IO system: The IO system is single threaded and somewhat buggy. The shell interface is sonewhat inconsistent. The whole system is supposed to be multitasking and has some limited support for multiprocessing but the IO system is single threaded and this has caused us no end of headaches, aside from the fact that it renders the system effectively single user. This is a pain during the development cycle. The shell also uses a non reentrant parser so it's not really going to be easy to make a multi threaded shell. STDIN and OUT are global so the IO system can only point one place at one time. This discussion seems to be losing clarity so I'll stop now... If you have more specific questions lemme know. Beez Employed by but not officially representing RedZone Robotics Inc. louie!beez@sunpitt.east.sun.com
rdh@sli.com (Robert D. Houk) (07/16/90)
In article <8abRihm00WB9EVo18y@andrew.cmu.edu> cb1p+@andrew.cmu.edu (Chris Beasley) writes:
2) IO system: The IO system is single threaded and somewhat buggy.
The shell interface is sonewhat inconsistent. The whole system is supposed
to be multitasking and has some limited support for multiprocessing
It is multi-tasking. It is very-limited ("roll-your-own") multiprocessing,
offering a few low-level primitives to allow you to mix'n'match your par-
ticular multi-processing (symmetric? master/slave? vector/etc/processors?)
environment.
but the IO system is single threaded and this has caused us no end of
?huh? While there is a limit on the number of "open fd"s, there is abso-
lutely nothing in VxWorks that prevents one task from doing I/O to a
(e.g.,) socket while another task is simultaneously (and non-interferingly,
so to speak) doing I/O to another (e.g.,) socket, local SCSI disk, pipe,
or whatever.
headaches, aside from the fact that it renders the system effectively
single user. This is a pain during the development cycle. The shell
It *IS* a single user system. Multi-tasking, but single user. And yes, it
is non-protective multi-tasking, any task can freely hang the entire sys-
tem by doing something stupid or wrong (e.g., taking a system semaphore
and not releasing it (such as splSemId - would hang the TCP sub-system),
writing all over [another task's] memory, executing a HALT instruction,
etc.).
also uses a non reentrant parser so it's not really going to be easy
to make a multi threaded shell. STDIN and OUT are global so the IO
system can only point one place at one time.
Since it is a single user system, with only one "console" terminal, this
makes some sense (after all, would you want every process (e.g., "ls") you
spawn on your Sun to go to the controlling terminal, or to somewhere else?).
However, if for some reason you want a particular task's STDIN, STDOUT,
and/or STDERR to go somewhere else (e.g., local SCSI disk file, host disk
file, pipe (other task), etc.) then the facility exists to redirect locally
(per-task/process) each separately [see ioGlobalStdGet() and ioGlobalStdSet(),
compare to ioTaskStdGet() and ioTaskStdSet()]. By default, all tasks simply
use the globally-available "console" terminal as STDxxx.
Granted, if you want a multi-user general-purpose Unix timesharing system
with "real-time" capability, then VxWorks is not what you want. Bear in
mind that the VxWorks Shell/etc developement environment wasn't meant to
be a "production" environment [at least I don't think it was, I don't work
for Wind River so I obviously cannot speak for them, nor read their minds
(much as I would like to), these are my opinions/observations solely], it
was a developement/debugging environment to allow you to develope appli-
cation(s) code to be "embedded" in a box somewhere, probably without a
terminal of any type available, and certainly no humans "logging into" the
system (VxWorks) shell...this is *not* to say that a lot of people haven't
discovered nifty applications that depend on many of the supposedly-develop-
ment-environment's features (e.g., ethernet TCP, NFS) and incorporated them
into applications...
My $.17 anyways.
-RDH