From: carl@umd5.umd.edu
Newsgroups: comp.os.vxworks
Subject: re: general info needed
Date: Mon, 07 Sep 92 23:35:21 -0400
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


> Submitted-by mea@sparta.com  Tue Sep  1 05:19:43 1992
> Submitted-by: mea@sparta.com (Mike Anderson)
> 
| > Submitted-by ramos@mtunm.att.com  Mon Aug 31 16:21:44 1992
| > Submitted-by: ramos@mtunm.att.com
| >  
| > We're looking into using either VxWorks or pSOS+ on a intel i960-based 
| > embedded system dedicated to communications processing.... 
| > .....I don't know anyone with VxWorks experience.  My questions are these:
>
> The folks to ask about this are Hughes Network Systems in Gaithersburg...

<relevant comments deleted>

> ...subquent revs to VxWorks and the GNU compiler.  As far as robustness
> and bugs are concerned, I frankly feel that the i960 version of VxWorks is
> more bug-free (largely owing to HNS and Intel hammering the kernel to
> death) than the 68K flavors of VxWorks.......

Well that was quite a build up!  Since I resemble these remarks I'll post
an HNS opinion on the questions:

|> 1) How hard is it to get VxWorks running on a custom platform using the 
|>    porting kit and how does it compare to pSOS+?
 
VxWorks is hosted on custom hardware via what is know as a board support 
package (BSP).  We had several to develop in a short amount of time.  Sadly 
back then there was _no_ documentation from either WR or Intel.  So we had to
develop our own base of BSP "how to" experience.  Fortunately, the Intel 
factory in Oregon are terrific and we were able to get example device drivers
and other critical questions answered.  We didn't and still do not have source
access to VxWorks.  Without sources, and with the SERIOUS lack of WR 
documentation we had to invest quite a lot of NRE on the BSP task.  

I can't specifically comment on the porting kit.  This only recently became
available and all our BSP work is completed.   I did volunteer to review
the documentation from a customer perspective given our experience 
(READ: that we *had* to go through) with BSPs but WR was not interested.

BTW, the WR porting kit is something you have to buy _extra_!!  Something
to the tune of $10K for all the trimmings but I don't have the price sheet 
handy.  To me this seems very vulgar of WR, IMO.  Not including such porting 
documentation AND example BSPs with the standard product is much the same 
as selling a "build a boat in a bottle" kit without instructions.

Anyway, given a good set of instructions I'd estimate about 4 weeks to
do a new BSP.  Development of a TCP/IP network driver for some interface other
than the standard ethernet and serial port will be extra.  Overall, the job is 
not hard if your hardware comes up first time right ;-)  It is essential that 
you look at an existing BSP, such as those available for commercial i960 
single board computers.  (However you do have to buy a licence for a specific 
commercial board to get a peek at its BSP.)

Maby someone else can comment on how this compairs with pSOS?

| > 2) How robust is the kernel? (performance, bugs, etc.)

I agree with what Mike said on this.  The Intel folks have done a great job
on their GNU compiler.  Each release has been better at performance largely
due to the compiler technology.  Hands down, the GNU compiler from Intel
is the best tool available for the i960.  We have found some bugs during our
BSP work.  Intel's bug fix turn around has been good for the i960 specific
problems.  The WR folks take care of the generic kernel problems.  Most of
the "kernel" problems we have seen has been our own code trashing memory ;-)

| > 3) What are the limitations and quality of the communications software?

The standard ethernet and serial drivers work well.  Intel has updated 
their driver with most of the 596 errata workarounds.  SLIP worked out of 
the box.  TCP/IP works as one would expect, mostly.  There is no routed and 
a few other things, but you can hardwire your routing tables and do gateway 
stuff.  Compaired to the kernel we had more bugs/problems with the TCP/IP
communications software.  Again, the folks at Intel often had a quick answer.
They also fixed all the bugs we raised, or worked with WR together to get
them fixed.

BTW, if you are planning on developing your own custom network interface,
(e.g. TCP/IP over T1, Frame Relay, or whatever), I'd recommend getting full 
WR sources for the networking code.  We didn't have these and simply would
not have made it without Intel's help, the grit of our own developers, and
looking at the standard BSD sources.  Again, this costs extra bucks.  
Unfortunately with the dearth of WR documentation there is not much choice.
It is almost like they expect folks to buy this and it somehow makes up for
WR's own documentation inadequacy.

| > 4) What are your experiences with the VxWorks source debugging environment?

We have never been able to get xVxGDB to work on our hosts since they are not
supported by WR.  VxGDB however is basically OK.  We have reported some bugs.
Overall though I have to disagree with Mike.  I think XRAY+ is a much more
friendly _debugger_.  The VxWorks shell does help bridge the gap though.

Oh and by the way, it is my understanding that the Intel factory support
folks are phasing out and a transition is happening to WR.  :-(  

Thats all for now!

---------------------
Carl Symborski
Olney Multimedia Inc.