From: mea@sparta.com (Mike Anderson)
Newsgroups: comp.os.vxworks
Subject: re: comp.os.vxworks newsdigest
Date: Thu, 12 Nov 92 14:55:45 EST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Greetings!

Dave Wybo writes:

> I am interested in the variety of VMEbus based processor boards which are
> supported by vxworks.  Having followed this newsgroup for a while, I have a
> pretty good feel that some of the more common flavors are supported, such as
> M68xxx based VME boards from a wide variety of vendors.
> 
To my knowledge, VxWorks runs on:

Motorola   680X0 and 683XX
MIPS       R3000 and (soon) R4000
Intel      80960CA and (soon) 80960CF (I think the SA and SB are also supported)
Sun        SPARC (both 25 & 40 MHz)
Hitachi(?) TRON G200

> Does anyone have any info about other processor boards, such as the HP-RT,
> MC88110, R4400, etc?  Anyone have a feel for how long it takes Wind River to
> bring a port of vxworks for a new hardware architecture to market?

Check with Mike Trest at Visicom (trest@visicom.com).  He does a lot of
BSPs for VxWorks and may be able to clue you in on this one.

> 
> Does one necessarily need a full Wind River "blessing" of a new processor board
> in order to get the kernel up and running? i.e. if I have brand xyz 68xxx
> based processor, how much work can I expect to have to do in order to get a
> basic port done?  (basic meaning just something running, with maybe a console
> port supported for debugging)

No.
There is a VxWorks porting kit availbale from WRS to help.
Ask Mike Trest.

> 
> What is the recommended debugging environment for vxworks?

The gdb debugger works reasonably well for source code.  If you're 
talking about debugging a new VxWorks port to a commercial board,
you can probably get by without an ICE but it sure would make things 
easier.  If you're trying to port to a board of your own design, I'd
have an ICE, logic analyzer and bus analyzer with bus anomaly tester
handy.  Again, you might be able to get by without these pieces of gear,
but life is greatly simplified if you have access to them.

> 
> Just how easy is it to take a program that runs on a un*x box, and convert it
> to run under vxworks?

I do it frequently.  I all depends on how deep into UN*X you get with your
code.  Most I/O and/or network stuff works without a hitch.  However, 
some of the BSD signals like SIGIO are not supported (although you can 
write your own as we have).

> 
> My impression is that there are many happy, or at least satisfied customers
> out there.  Any gotcha's?  Any environments where vxworks is just plain
> inappropriate?

If you're trying to run Microsoft Windows, I feel that VxWorks is probably
inappropriate ;-).  Seriously though, VxWorks is really a fairly
"general purpose" operating system.  I remember at the VxWorks user's
group meeting in '90 when most folks there were surprised that I was 
running large-scale simulations that incorporated 40+ CPUs running
VxWorks.  Since most users think of VxWorks in applications such as
controlling silicon wafer steppers and the like, we sometimes forget that
VxWorks is really a good general O/S with just a few caveats.

> 
> If I have a single task solution, can I turn off context switching so that I
> keep the o.s. out of the way of my real-time task? (other than clock interrupts
> of course)

Yes.

> 
> I am somewhat familiar with pSOS+ and the ability to run a task in supervisor
> (privileged) mode if I so desire.  Is the same true for vxworks?
> 

To the best of my understanding, all tasks in VxWorks currently run in
supervisor state.



==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================