NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/vxworks/793

Internet Message Format | 1992-09-08 | 5.5 KB

Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!lbl.gov!vxwexplo
From: [e-mail]
Newsgroups: comp.os.vxworks
Subject: re: general info needed
Date: Mon, 07 Sep 92 23:35:21 -0400
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 101
Sender: [e-mail]
Message-ID: <[e-mail]>
NNTP-Posting-Host: 128.3.112.16
Originator: [e-mail]


> Submitted-by [e-mail]  Tue Sep  1 05:19:43 1992
> Submitted-by: [e-mail] (Mike Anderson)
>
| > Submitted-by [e-mail]  Mon Aug 31 16:21:44 1992
| > Submitted-by: [e-mail]
| >
| > 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.