From mmuri@qualcomm.com  Tue Jan  3 12:09:56 1995
From: mmuri@qualcomm.com (Mark Muri)
Date: Tue Jan  3 12:10:03 PST 1995
Subject: Generating VMEBUS cycles from 167 Sys Con
Anyone,

  I've been experimenting with using a VME167 to generate VMEBUS cycles to
another 3rd party card.  I have a 167 as the System controller and other
167 boards (which do a successful sm boot).

  By twiddling with the bits in the VMECHIP2, I have been very successful
at generating VMEBUS addresses from the non-system-controller cards.  I
cannot, for the life of me, generate one from the System Controller!  All I
get are bus errors.  The VMECHIP2 indicates MLOB, but I never see the cycle
show up on the backplane (using a VMETRO).

  (As you know, a System Controller who exports his local memory as the
VxWorks shared memory pool cannot even access that pool with the VMEBUS
address that the non-system-contoller cards do - it must use it's local bus
address.)

  I believe that it's some simple interaction between the dual role of the
Master VMECHIP2 as one who's trying to generate the address PLUS the one in
charge of arbitrating the bus.

  I've done the proper sysPhysMemDesc changes and, since vxMP is installed,
the changes show up properly when I do a vmContextShow.  The address space
is writable and non-cached.

  Anyone run into this type of problem?  I suppose there's a simple
explanation and maybe I have been staring at it for tooooooooo long...

Mark

<=================o=====================================================>
| Mark Muri       | E-Mail: mmuri@qualcomm.com    (619)  Work: 658-3303 |
| Senior Engineer | Office: Q-244A                        Fax: 658-2108 |
| QUALCOMM, Inc  <+>                                      Car: 895-8315 |
| 6455 Lusk Blvd., San Diego, CA 92121                  Pager: 636-0446 |
<=======================================================================>

From stevem@syd.csa.com.au  Thu Jan  5 00:50:17 1995
From: stevem@syd.csa.com.au (Steven McCoy)
Date: Thu Jan  5 00:50:30 PST 1995
Subject: Bus Error with 32MByte MVME167
Our Ada application executes without a problem on a MVME167-B 
(25 MHz, 16 MBytes) and a MVME167-33A (33 MHz, 16 MBytes). A recent
upgrade to the MVME167-34A (33 MHz, 32 MBytes) has suddenly
caused the same code to generate a Bus error or at times an Illegal 
Instruction. This always occurs when executing i() or checkStack()
commands from the shell. Note that we do not have a problem with
the pi() command.

e.g.

Bus Error
Program Counter: 0x00000008
Status Register: 0x3000
Access Address : 0x08eb7376 <-- Way out of range.
Special Status : 0x0125

shell restarted.

or

Illegal Instruction
Program Counter: 0x00000012
Status Register: 0x3008

shell restarted.

The problem will still occur if the 34A 32 MByte memory module is
used on the 33A. The 16Mbyte module works fine on the 34A.  Hence,
there appears to be a problem with memory initialisation or something
with memory modules greater than 16 MBytes.

Are there any VxWorks changes required when using a 167 with more 
than 16 MBytes of memory?

We are using the following,

VADSworks version 2.0.3(b).
VxWorks (for Motorola MVME167) version 5.0.2b.
Kernel: WIND version 2.0.

Any ideas would be appreciated,

Steven McCoy
CSC Australia
A Unit of Computer Sciences Corporation
stevem@assip.csasyd.oz.au

From daemon@vxw.ee.lbl.gov  Thu Jan  5 04:00:24 1995
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan  5 04:00:32 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan  5 04:00:13 PST 1995

        Subject: Motorola MC68681 driver
        Subject: FAQ and ftp site info
        Subject: FAQ and ftp site info
        Subject: ld MEMORY command, multiple regions per section possible?
        Subject: Re: FAQ and ftp site info

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Motorola MC68681 driver
Date: Wed, 4 Jan 1995 13:37:38 GMT
From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1995Jan4.133738.17760@hgl.signaal.nl>
Sender: usenet@hgl.signaal.nl (USENET News System)

Hello,

We are currently developing a Vxworks application with a 68020 processor
and a MC68681 duart.

question :
	We are looking now for a MC68681 driver that supports the serial IO
	and that uses the MC68681 timer for the system clock.

Please email me if you have some information.

	Thanks,
		--Ben--

- -- 
==============================================================================
= B.J.M. Vloedbeld    Dept:SDA-DID-DIM   Org:Hollandse Signaalapparaten B.V. =
= Adress : P.O.box 42 7550 GD Hengelo, The Netherlands                       =
= Phone :+31-74-483994 FAX:+31-74-484009  email:bjm_vloedbeld@hgl.signaal.nl =
=============================================================[Unclassified]===

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQ and ftp site info
Date: 04 Jan 1995 21:37:02 GMT
From: wilson@ssdd475a.erim.org (Paul Wilson)
Organization: Environmental Research Institute of Michigan, Ann Arbor, Michigan
Message-ID: <WILSON.95Jan4163703@ssdd475a.erim.org>
Sender: news@newsspool.erim.org

Is there an FAQ available for this group?  Where might I obtain it?
Also, I have a requirement to produce a Sun readable TAR tape from 
a vxworks application.  Is there a netware package to do that?

	Thanks in advance for assistance.

	regards,
		Paul Wilson
		wilson@erim.org

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQ and ftp site info
Date: 04 Jan 1995 22:09:32 GMT
From: wilson@ssdd475a.erim.org (Paul Wilson)
Organization: Environmental Research Institute of Michigan, Ann Arbor, Michigan
Message-ID: <WILSON.95Jan4170932@ssdd475a.erim.org>
Sender: news@newsspool.erim.org

Is there an FAQ available for this group?  Where might I obtain it?
Also, I have a requirement to produce a Sun readable TAR tape from 
a vxworks application.  Is there a netware package to do that?

	Thanks in advance for assistance.

	regards,
		Paul Wilson
		wilson@erim.org

---------------------------

Newsgroups: comp.os.vxworks,gnu.gcc.help
Subject: ld MEMORY command, multiple regions per section possible?
Date: 4 Jan 95 22:26:52 GMT
From: kab@dtl.labs.tek.com (Kent Black)
Organization: DTL, Tektronix, Inc.
Keywords: a.out, MEMORY
Message-ID: <6986@crl.labs.tek.com>
Followup-To: comp.os.vxworks
Sender: news@crl.labs.tek.com

I would like to be able to put a globally accessible object (an OS
specific symbol table for debugging) into some slow (or even optional)
memory.  I'm thinking a chunk of ROM for text, a smallish chunk of RAM
for data and bss, and "somewhere else" for this other big chunk of
initialized data (otherwise I'm short of usable RAM).

Using a.out format (68k arch), is it possible to have a section, in
particular .data, divided among memory regions?

Consider the following ld script:
    
    OUTPUT_FORMAT("a.out-sunos-big")        /* output .o file format */
    TARGET("a.out-sunos-big")               /* input .o file format */
    ENTRY("_romSP")                         /* entry point */
    
    MEMORY  {
            rom : ORIGIN = 0xfB000000, LENGTH = 2M
            ram : ORIGIN = 0x06020000, LENGTH = 512K
            }
    
    SECTIONS {
            .text : {
                    CREATE_OBJECT_SYMBOLS
                    *(.text)
                    _etext  =  .;
                    } > rom
    
            .data : {
                    *(.data)
                    _builtForRom = .;
                    SHORT(0);
                    _edata  =  .;
                    } > ram
    
            .bss SIZEOF(.data) + ADDR(.data) :
                    {
                    *(.bss)
                    [ COMMON ]
                    _end = .;
                    __end = .;
                    } > ram
            }
    
Now, my first thought is that I could simply add an optional read of
"symtable.o" into some arbitrary address from the .data segment, but that
fails when .data > ram doesn't "fit".

Clever alternatives welcome.

- -- kab

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: FAQ and ftp site info
Date: Thu, 5 Jan 1995 08:15:17 GMT
From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1995Jan5.081517.13934@hgl.signaal.nl>
References: <WILSON.95Jan4170932@ssdd475a.erim.org>
Sender: usenet@hgl.signaal.nl (USENET News System)

Paul Wilson (wilson@ssdd475a.erim.org) wrote:
: Is there an FAQ available for this group?  Where might I obtain it?
: Also, I have a requirement to produce a Sun readable TAR tape from 
: a vxworks application.  Is there a netware package to do that?

: 	Thanks in advance for assistance.

: 	regards,
: 		Paul Wilson
: 		wilson@erim.org

here some lines from the original vxworks FAQ :

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  

This FAQ was compiled by hjb@netcom.com using comments by readers of
comp.os.vxworks as well as his own limited knowledge of VxWorks.  Credits
appear at the end.  Comments and indications of doubt are enclosed in []s in
the text.  Each section begins with dashes ("-") on a line of their own,
then the section number.  This should make searching for a specific section
easy.

This FAQ is also available via anonymous ftp in:
        rtfm.mit.edu:/pub/usenet/news.answers/vxworks-faq.Z
        ftp.uu.net:/usenet/news.answers/vxworks-faq.Z 
        cs.toronto.edu:/pub/usenet/comp.answers/vxworks-faq.Z
        ftp.netcom.com:/pub/hjb/vxfaq.gz

- -- 
==============================================================================
= B.J.M. Vloedbeld    Dept:SDA-DID-DIM   Org:Hollandse Signaalapparaten B.V. =
= Adress : P.O.box 42 7550 GD Hengelo, The Netherlands                       =
= Phone :+31-74-483994 FAX:+31-74-484009  email:bjm_vloedbeld@hgl.signaal.nl =
=============================================================[Unclassified]===

---------------------------

End of New-News digest
**********************

From crispen@eight-ball.hv.boeing.com  Thu Jan  5 06:26:29 1995
From: crispen@eight-ball.hv.boeing.com (Bob Crispen)
Date: Thu Jan  5 06:26:35 PST 1995
Subject: Re: comp.os.vxworks newsdigest
kab@dtl.labs.tek.com (Kent Black) sez:

>I would like to be able to put a globally accessible object (an OS
>specific symbol table for debugging) into some slow (or even optional)
>memory.  I'm thinking a chunk of ROM for text, a smallish chunk of RAM
>for data and bss, and "somewhere else" for this other big chunk of
>initialized data (otherwise I'm short of usable RAM).
>
>Using a.out format (68k arch), is it possible to have a section, in
>particular .data, divided among memory regions?

[snip]

>Clever alternatives welcome.

This isn't particularly clever, and I'm not completely sure it addresses
your problem, but you may find some use for it in your eventual solution.
Change the line in vxworks/config/yourboard/sysLib.c (in sysMemTop())
that reads:

    static char *memTop = (char *)(LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE);

to:

    static char *memTop = (char *)(LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE -
        0x10000);

and gen up another bootable version of VxWorks.  If you want to keep
this memory from being clobbered when you hit reset, do it for your
VxWorks boot ROM, too.  That gives you the top 64K (or whatever) of
memory that's Real Manly Memory By God -- none of this girly-man
dynamically allocated memory business. ;-)
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

From mea@mclean.sparta.com  Thu Jan  5 06:50:24 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan  5 06:50:30 PST 1995
Subject: Re: FAQ
Greetings!

  The FAQ is no longer being kept by Hwajin.  It is now located at:
teacher.mclean.sparta.com (157.185.32.10).  With the holidays, bringing
new machines on-line, running new LANs to support them and end of the
year deliverables, etc., I'm afraid I've let the FAQ fall behind.  I'm 
making every effort to catch it up to date and have the new FTP machine
for the FAQ with Mosaic home page, etc. on-line by the end of the month.

Sorry for the delay,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From daemon@vxw.ee.lbl.gov  Fri Jan  6 04:00:22 1995
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan  6 04:00:29 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan  6 04:00:13 PST 1995

        Subject: SCSI floppy disk drive
        Subject: Stability

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI floppy disk drive
Date: Thu, 5 Jan 1995 19:44:28 GMT
From: jch@netcom.com (Jack Hwang)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <jchD1y6u4.Gt9@netcom.com>

This is an old news.  Teac discontinue SCSI floppy disk drive FD235SJ.
But due to some bureautic clumsiness, the company I am working with
did not act on time to secure the supplies.  Now it all comes to me
to find alternatives.  Does anyone know there is a replacement available
which is compatiable with MVME147?  (Even 147 itself is discontinued!
DXXN!!!)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Stability
Date: 4 Jan 1995 19:50:52 GMT
From: prabhala@penafiel.irvine.dg.com (Venkata Prabhala)
Organization: Data General Corporation, Research Triangle Park, NC
Keywords: VxWorks
Message-ID: <3eeu6s$hcs@dg-irv.irvine.dg.com>

I am a new to RTOS's.  But I am certainly UNIX type!  I  have been wondering
if someone on this group could comment on the stability of VxWorks as a
development environment in a Unix host-based environment. How well does
VxWorks hold up to its promise of remote host-based development/debugging?
I  would like to hear both positive and negative comments to help my decision.
It would also help if someone could point out where I can obtain comparative
studies about different RTOSs like VxWorks, VRTX, QNX, pSOS, Solaris etc.

You may e-mail me if you think  it would increase the S/N ratio on the news
group.

Thanks.
- -- Venkat

- -- 

Venkata Prabhala, Data General Corporation	|  (prabhala@irvine.dg.com)   
2603 Main St., Ste. 360			 	|  FAX:   +1 714 724 3956
Irvine, CA 92714			 	|  VOICE: +1 714 724 3569

---------------------------

End of New-News digest
**********************

From djb@rtp.co.uk  Fri Jan  6 05:24:49 1995
From: djb@rtp.co.uk (David Bullimore)
Date: Fri Jan  6 05:24:56 PST 1995
Subject: X11- BDF bit map fonts

Dear All,

Does anyone know of a utility that converts Berkeley 'BDF' bit map fonts to 
'PCF' format for use with the Visicom X server?

David

***********************************************
* David Bullimore                             *
* Real Time Products Ltd. (RTP Ltd.)          *        
* Unit 8                                      *
* Holt Court                                  *
* Aston Science Park                          *
* Birmingham                                  *
* B7 4EJ                                      *
* England                                     *
*                                             *
* Phone:      +44.21.333 6955                 *
* Fax:        +44.21.333 5433                 *
*                                             *
* Email       djb@rtp.co.uk                   *
***********************************************

From cook@positron.med.ge.com  Fri Jan  6 06:59:41 1995
From: cook@positron.med.ge.com (Mike Cook)
Date: Fri Jan  6 06:59:48 PST 1995
Subject: DOS & large drive

Anybody out there using large drives (> 4 gigabyte) with VxWorks DOS?

I've recently configured VxWorks 5.1.1 DOS with the Seagate Elite 9 scsi 
9.8 gigabyte drive. With the exception that 

ioctl( fd, FIONFREE, &freeBytes )

doesn't work (you can't fit 9.8 gig in a 'long'!), it is functional.

Performance is the issue. If I merely read/write multiples of clusters,
being careful to align the writes on cluster boundaries, performance is
about what I expect for our controller (2.5-3 meg per sec with xfers
> 1 meg). Note that we strictly use contiguous files on the order of 
3-100 megabytes.

But when I read/write to file offsets not on cluster boundaries...
performance goes right out the window (less than half). I believe this is
due to the large cluster size of 0x25000 (74 sectors of 2K bytes), and
DOS appears to read/write at a cluster granularity.

For example, if I want to read 10K bytes from an arbritrary offset within
my contiguous file, DOS reads an entire cluster of 150K bytes (or two clusters
if the requested 10K crosses a cluster boundary).

Even writes greater than a cluster can result in two additional cluster reads
if you don't write even multiples of clusters at cluster boundaries.

The DOS implementation forces me to a minimum cluster size of 0x25000 bytes.
(9.8 gig / 64K clusters). So going to a smaller cluster size is not an
option with this drive if I want to access the entire drive as one DOS volume.

I contend, that if DOS would not do the 'buffered I/O' or only do it on a 
sector (or a few sectors) basis rather than on a cluster basis, my performance 
problems would go away.

Question 1: 
Is there anyway I can turn off the buffered I/O or reduce the buffer size?

Ideally, I would like to be able to be able to open a dos file, seek to an 
offset that is not cluster aligned and start reading/writing without having the 
system read/write more than two additional disk sectors.

Question 2:
If the answer to Question 1 is NO (unless you have source code)....I don't.

I'm tempted to try to read/write to the DOS contiguous files using Raw I/O.
Would this be advisable? 

Question 3:
Is there a simple means to obtain the clustor number (or ideally the disk
sector) for the start of a DOS contiguous file? (to aid my raw i/o if I choose
to go that route)

Question 4:
Do you have any other suggestions as to how to improve the performance?

Mike Cook
GE Medical Systems
cookm@med.ge.com
(414) 548-4791

 
 

From leonid@rst.co.il  Sat Jan  7 23:54:04 1995
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sat Jan  7 23:54:10 PST 1995
Subject: Re: SCSI floppy disk drive
> Date: Thu, 5 Jan 1995 19:44:28 GMT
> From: jch@netcom.com (Jack Hwang)
> This is an old news.  Teac discontinue SCSI floppy disk drive FD235SJ.
> But due to some bureautic clumsiness, the company I am working with
> did not act on time to secure the supplies.  Now it all comes to me
> to find alternatives.  Does anyone know there is a replacement available
> which is compatiable with MVME147?  (Even 147 itself is discontinued!
> DXXN!!!)

Jack, this has been expected to happen for some time. The SCSI floppies
are too expensive anyway, and turns out Teac didn't find them profitable
either. Here are a couple of ideas you could consider:

1. If replacing the 147, find a board with both SCSI and a CP-stype floppy
controller on board. Take a look at Wind River's 3rd party catalog.

2. Floptical drives have been suggested more then once on this list
as a viable alternative for floppies. I haven't seen them in use yet.

3. This is my presonal favorite: QIC tape drives are quite popular
in SCSI-world, and not very expensive either. (mini-QICs are cheaper yet).
It is just so happens that we sell a software solution for SCSI tapes on 
VxWorks. It lets you do backup / restore, software updates, and even
boot from a tape when starting from scratch. You must have a hard disk
on the system, or take a chunk of RAM and build a RAM-disk, cause the
tape is not direct access. 

Please contact me directly for more details regarding the SCSI tape solution.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
R S T  Software Industries Ltd.                +972-50-307-142
3 Hashikma st. Industrial Zone,         Fax:   +972-3-559-8244
P.O.Box 11502, AZUR 58017, Israel       E-Mail: leonid@rst.co.il

From ntmtv.com!isaac@ntmtv.portal.com  Mon Jan  9 14:23:38 1995
From: isaac@ntmtv.com
Date: Mon Jan  9 14:23:45 PST 1995
Subject: Re: SCSI floppy disk drive

>  Submitted-by leonid@rst.co.il  Sat Jan  7 23:54:04 1995
>  Submitted-by: leonid@rst.co.il (Leonid Rosenboim)
>   
>  > Date: Thu, 5 Jan 1995 19:44:28 GMT
>  > From: jch@netcom.com (Jack Hwang)
>  > This is an old news.  Teac discontinue SCSI floppy disk drive FD235SJ.
>  > But due to some bureautic clumsiness, the company I am working with
>  > did not act on time to secure the supplies.  Now it all comes to me
....
>  
>  Jack, this has been expected to happen for some time. The SCSI floppies
>  are too expensive anyway, and turns out Teac didn't find them profitable
>  either. Here are a couple of ideas you could consider:
>  
>  1. If replacing the 147, find a board with both SCSI and a CP-stype floppy
>  controller on board. Take a look at Wind River's 3rd party catalog.
>  
>  2. Floptical drives have been suggested more then once on this list
>  as a viable alternative for floppies. I haven't seen them in use yet.
>  
>  3. This is my presonal favorite: QIC tape drives are quite popular
>  in SCSI-world, and not very expensive either. (mini-QICs are cheaper yet).
>  It is just so happens that we sell a software solution for SCSI tapes on 

We are faced with a similiar problem as Jack with the finding a replacement
to the 4MB Teac SCSI floppy drive. Are there many others with the same problem?

I was wondering what others experience with the Floptical has been. I like
the Floptical solution because it has a SCSI interface, has increased capacity 
and also will read 2MB floppies. But will it also get discontinued like the 
4MB drives? Are there any major users of the Floptical, with sufficient demand 
to keep the company in business?

Are there any companies that make equipment for Software Duplication on the
Floptical or QIC tape drives?

Any info would be appreciated.
Thanks
------------------------------
Roy Isaac               UUCP:{ames,mcdcup}!ntmtv!isaac
Northern Telecom	INTERNET: isaac@ntmtv.com
Mountain View, CA	PHONE: 415-940-2539

From del@rst.com  Mon Jan  9 14:28:52 1995
From: del@rst.com (Mark Del Giorno)
Date: Mon Jan  9 14:29:00 PST 1995
Subject: Programming FLASH on the MV162
I'm looking for some source code that can burn FLASH on a MVME162
(it uses the Intel 28F020).  My ultimate goal is to be able to burn
my application into FLASH and run on power up (embedded - with no
ethernet attached).  Wind River has a way that I can download a hex
file via a serial link - this is o.k., but I can't believe I can't
accomplish the same thing via the ethernet connection.  When I asked
them for code to burn the FLASH, I got the following response:

        TITLE:  Programming Flash on the MV162 from within vxWorks

        KEYWORDS: MV162, Flash

        SYSTEM: All

        DESCRIPTION:  Unsupported.

        SYMPTOM(S): Customer wishes to programmatically modify the flash
eprom on
        a MV162.

        RESOLUTION: Programmatically writing flash from vxWorks is strongly
        discouraged.  This is reportedly very messy and very slow.  You have
        to erase all of flash prior to reprogramming.

        This is definitely unsupported.

Just because it's "messy and slow" doesn't seem like a real good reason to
me that Wind River should not support it!!!!!

Thanks in advance for any help.

    _/_/_/_/  _/_/_/_/ _/_/_/_/_/      Mark Del Giorno   (del@rst.com)
   _/    _/  _/           _/           (410) 876-9200  Fax: 876-9470
  _/_/_/_/  _/_/_/_/     _/            Robotic Systems Technology
 _/   _/         _/     _/             1110 Business Parkway South
_/    _/  _/_/_/_/     _/              Westminster, MD 21157

From pf1122@tcville.es.hac.com  Mon Jan  9 15:47:14 1995
From: pf1122@tcville.es.hac.com (Kim Chacon)
Date: Mon Jan  9 15:47:22 PST 1995
Subject: Re:  Programming FLASH on the MV162

Mark Del Giorno wrote:
---------------------------------------------------------------------
> Submitted-by del@rst.com  Mon Jan  9 14:28:52 1995
> Submitted-by: del@rst.com (Mark Del Giorno)
>  
> I'm looking for some source code that can burn FLASH on a MVME162
> (it uses the Intel 28F020).  My ultimate goal is to be able to burn
> my application into FLASH and run on power up (embedded - with no
> ethernet attached).  Wind River has a way that I can download a hex
> file via a serial link - this is o.k., but I can't believe I can't
> accomplish the same thing via the ethernet connection.

We have done this.  We have installed a Flash EEPROM industry pack on
our MVME162 card.  We purchased software from a company named CompWare
Corp.  The contact person at Compware that we have dealt with is
Paul Anderson (602-998-8650).  Call him to get price information.
I did not personally order the software, so I don't have that information.

The software contains a flashLib, which provides C functions such as:
flashShow(), flashWrite(), eraseFlash(), etc.

We have successfully run our code from a Dos Filesystem relocated from
a RAM disk device to the Flash EEPROM.  The files were relocated via 
writeFlash().  

I hope this helps,
Kim M. Chacon
Hughes Aircraft Company
email:  chacon@tcville.es.hac.com

From daemon@vxw.ee.lbl.gov  Tue Jan 10 04:00:49 1995
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 10 04:01:14 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 10 04:00:24 PST 1995

        Subject: Re: Getting printf() to work in "real-time"
        Subject: Re: NTDS boards
        Subject: CPU Idle time on Vxworks
        Subject: Re: RAMDISK/ROMDISK
        Subject: Re: VADSWorks (Ada on VxWorks)
        Subject: Re: Getting printf() to work in "real-time"
        Subject: CPU idle time on VxWorks -- Again
        Subject: Changing file times.
        Subject: re: RAMDISK/ROMDISK
        Subject: Re: CPU idle time on VxWorks -- Again
        Subject: Re: Changing file times.
        Subject: Re: CPU Idle time on Vxworks
        Subject: Has anyone ported scandir() ?
        Subject: Re: VADSWorks (Ada on VxWorks)
        Subject: Re: GreenHills Ada on VxW
        Subject: Re: NTDS boards
        Subject: Re: CPU Idle time on Vxworks
        Subject: ld error
        Subject: Re: CPU Idle time on Vxworks
        Subject: Re: Driver/Source for a Motorola MVME376 Ethernet pcb
        Subject: Re: TCP/IP & Mbuf configuration
        Subject: Re: Can VxWorks coexist with other OS on VMEbus?
        Subject: Embedded Systems Design Symposium
        Subject: Green Hills
        Subject: Timer interrupts in VxWorks
        Subject: Re: Timer interrupts in VxWorks
        Subject: Re: Timer interrupts in VxWorks
        Subject: FTP site for MVE166/167
        Subject: Help!  ISR causes NFS to die!
        Subject: dosFs VOLUME_NOT_AVAILABLE
        Subject: Motorola MC68681 driver
        Subject: FAQ and ftp site info
        Subject: FAQ and ftp site info
        Subject: ld MEMORY command, multiple regions per section possible?
        Subject: Re: FAQ and ftp site info
        Subject: SCSI floppy disk drive
        Subject: Stability
        Subject: Re: SCSI floppy disk drive
        Subject: Fortran compiler & tools/ Vxworks on Alpha
        Subject: Re: DOS & large drive
        Subject: Database on VxWorks
        Subject: Re: Changing file times.
        Subject: Looking For A File Transfer Protocol
        Subject: Looking for new VxWorks File System
        Subject: Can't ftp thor.atd.ucar.edu
        Subject: Re: Can't ftp thor.atd.ucar.edu
        Subject: Fortran Compiler for Alpha/VXworks
        Subject: Cartridge Tape Driver
        Subject: smObjLocalToGlobal() Question 
        Subject: Email address Wind River Systems, Visicom

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Getting printf() to work in "real-time"
Date: Mon, 19 Dec 1994 11:44:07 GMT
From: jh@ns.ph.liv.ac.uk (Jomar Honsi)
Organization: University of Liverpool Nuclear Structure Group
Message-ID: <D1239K.4zI@liverpool.ac.uk>
References: <9412162057.AA03904@lassen>
Reply-To: jh@ns.ph.liv.ac.uk
Sender: news@liverpool.ac.uk (News System)

In article AA03904@lassen, stan@lassen.rti.com (Stan Schneider) writes:
>>> Submitted-by del@rst.com  Thu Dec 15 10:48:59 1994
>
>>>          for (i = 0 ; i < n ; i++)
>>>            {
>>>              if (some_signal() > TOO_HIGH)
>>>                printf("Error - cycle %d\n", i);
>>>            }
>
>>> I don't get anything printed to the screen until the go() routine exits
>>> completely, then I get a complete dump of all the cycle numbers that the
>>> errors occurred. 
>
>Could this be simply that you're starving the netTask with an infinite loop at
>tShell priority?  Try setting the shell to a lower priority via
>taskPrioritySet.
>
>        -- Stan
>
Why not use logMsg ? (and watch the priorities)
- ---
** Jomar Honsi                     Phone:  + (44)(51)7943398
** Department of Physics           E-mail: jh@ns.ph.liv.ac.uk
** University of Liverpool, UK

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: NTDS boards
Date: 19 Dec 1994 20:58:19 GMT
From: Fran Horan <franfh@aplexus.jhuapl.edu>
Organization: JHU/APL
Message-ID: <3d4s5b$4km@aplcomm.jhuapl.edu>
References: <199412161938.OAA21574@piranha.ssd.ray.com>

NTDS boards

We use the Antares VMENIO board sold by Visicom in San Diego Ca. for
several of our mission-critical embedded systems on Navy ships.  Their
phone number is 619-457-2111.  We have several drivers developed in house
but Visicom was planning to release a driver last time I talked to them. 
I would investigate theirs first and see if it is made to work with
vxWorks.  We are happy with their product and support.
Fran Horan
franfh@aplexus.jhuapl.edu
FranHoran@aol.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: CPU Idle time on Vxworks
Date: 19 Dec 1994 17:00:08 -0600
From: sureshr@bnr.ca (Suresh Rao)
Organization: Bell-Northern Research, Richardson, TX
Message-ID: <3d539o$58d@crchha82.bnr.ca>
Sender: sureshr@bnr.ca (Marco Marchetti)

I need to find out the CPU Idle time (CPU load statistics) on Vxworks.
Does anybody have any ideas about how to get it ? 

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: RAMDISK/ROMDISK
Date: Tue, 20 Dec 1994 01:15:03 GMT
From: miked@wrs.com (Mike Deliman)
Organization: Wind River Systems, Inc.
Message-ID: <D134t5.3uM@wrs.com>
References: <D0spFx.7Cw@oasis.icl.co.uk>
Sender: news@wrs.com (News Manager)

In article <D0spFx.7Cw@oasis.icl.co.uk> rsgawera@wg.icl.co.uk writes:
>Dear VxWorkers,
>	Is there any easy way of building a file system in Flash memory ie
>some sort of RAMdisk. We have a board running vxworks with a Flash card and we
>want to store software on the Flash card. If a simple file system were created,
>we could easily pull software off the card and also update the software.
>
>		Thanks in advance,
>			Raj Gawera
>
>Raj Gawera
>ICL CSD
>email : rsgawera@wg.icl.co.uk

Raj,

check out the sources in  <vw>/src/usr - look at the memDrv.c and ramDrv.c files.
Build something like this for your flash.... "flashDrv.c", and use it with
dosFs.

Sincerely

  -miked

- -- 
- ------------------------------------------------------------------------------
  Mike Deliman <> miked@wrs.com <> phone: 510-748-4100 <> facs: 510-814-2164
  Snail Mail:  Wind River Systems,  1010 Atlantic Ave,  Alameda CA 94501 USA
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VADSWorks (Ada on VxWorks)
Date: 20 Dec 1994 08:58:42 GMT
From: corey@rational.com (Corey Ashford)
Organization: Rational Software Corporation
Message-ID: <3d66c2$snb@rational.rational.com>
References: <00988FB6.3321E960.19@cub.kscorp.com>

Bob Dowling (dowling@cub.kscorp.com) wrote:

: Recently, I replied to a question from Matt Whiting (whiting_ms@corning.com) 
: about Ada compilers available for use with VxWorks.  I wrote:
:  
: > I've used the Rational/Verdix VADSworks cross-compiler on SUNs for the
: > Motorola 68020/030 on the ubiquitous MVME-147.  They can be reached at
: > (800) 289-8237 or (703) 318-5800.

: John R. Cobarruvias (cobarruvias@asd1.jsc.nasa.gov) saw this on 
: comp.os.vxworks, and sent me the following, which may interest you:

: This is the only one I have heard of. VADSworks is pretty good. I have used
: it before with an R3000 board. I would be VERY cautious with the Rational
: APEX product coupled with VADSWorks. Try it before you buy it.

: VADSWorks has been successfully used by a number of people. It's a great set
: of tools.

: A couple of things you should be aware of:

: 1) VADSWorks is VxWorks coupled with Verdix Ada. It is sold by Verdix (now
: Rational) as a single product. 

: 2) Because of 1, you get your tech support from Rational/Verdix NOT from
: [Wind River]. 

: 3) It has caused us much grief if Verdix doesn't or can't answer our
: questions. Then they had to go to WRS then get back to us. We couldn't ask
: WRS directly. I think this MAY have changed recently.

This hasn't changed much.

: 4) Verdix gets VxWorks from WRS, then integrates it with VADS. Because of
: this, we were usually behind on VxWorks newest releases and fixes since it
: has to go through Verdix first. The problem was worse since we were using a
: little-used board. 680x0 should have less of a problem.

Starting Q1 1995, the VADSworks product will be layered on top of VxWorks
in such a way that allows us to not need to alter any VxWorks source.  This
will enable us to keep up with VxWorks releases in a timely manner.  In
fact, the layer is so clean that the VADSworks product will be treated
like an add-on product to VxWorks.   This product has been in development
for a couple of years and runs on 68k, MIPS, and soon DEC Alpha targets.

: 5) If you go with APEX, then you have another layer to integrate. APEX over
: VADS over VxWorks. I would be very cautious about this product. Try before
: you buy. We did and we won't use it.

APEX II (which is a combination of APEX's front-end tools with VADS
back-end and debugger + plus some new features) will be integrated with
VADSworks.  This will be a much smoother product than the present
combination of APEX and VADS.  I don't know the projected date, but I'd
guess it's at least Q3 1995.

- - Corey

== My comments do not represent any official position of Rational Software
Corp.  Please contact a sales rep for schedules ==

Internet: corey@rational.com
Sneakernet: down_the_hall!right_at_the_mens_room!past_the_stain_on_the_wall!...
Rational Software Corporation
1600 N.W. Compton Drive, Suite #357
Aloha, OR 97006
ph# (503) 690-1116 x6710

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Getting printf() to work in "real-time"
Date: Tue, 20 Dec 1994 14:15:32 GMT
From: clegg@ssd.fsi.com
Organization: Flightsafety International, Broken Arrow, OK
Message-ID: <1994Dec20.141532.31676@dev1.ssd.fsi.com>
References: <9412162057.AA03904@lassen> <D1239K.4zI@liverpool.ac.uk>
Reply-To: clegg@ssd.fsi.com
Sender: news@dev1.ssd.fsi.com

>In article AA03904@lassen, stan@lassen.rti.com (Stan Schneider) writes:
> Submitted-by del@rst.com  Thu Dec 15 10:48:59 1994
>
>          for (i = 0 ; i < n ; i++)
>            {
>              if (some_signal() > TOO_HIGH)
>                printf("Error - cycle %d\n", i);
>            }
>
> I don't get anything printed to the screen until the go() routine exits
> completely, then I get a complete dump of all the cycle numbers that the
> errors occurred. 
>
I didn't see the orignal posting, however, if you are logging into the VxWorks 
system over ethernet, you may need to flush(stdout) the buffer once in a while to
get real time output.
R. Clegg
clegg@ssd.fsi.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: CPU idle time on VxWorks -- Again
Date: 20 Dec 1994 08:53:23 -0600
From: sureshr@bnr.ca
Organization: Bell-Northern Research, Richardson, TX
Message-ID: <3d6r53$76q@crchha82.bnr.ca>
Sender: sureshr@bnr.ca (Marco Marchetti)

Spy command gives timing for individual tasks. I was looking for some command
which gives the overall picture.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Changing file times.
Date: Tue, 20 Dec 1994 15:21:27 GMT
From: heller@nm.picker.com (Mark Heller)
Organization: Picker International, Nuclear Medicine Division
Message-ID: <1994Dec20.152127.9206@picker.com>
Sender: news@picker.com

Hi All,
	I'm running VxWorks 5.1.1 and looking for a way to change
	the dates on files on a Dos filesystem. After going through 
	the documentation I can't find an equivalent call to the 
	Unix utime function.  Does anyone know how to change the 
	date on a VxWorks file.

Thanks
- -----
- -Mark
- ----------------------------------------------------------------
Mark Heller             Picker International Inc. 
heller@nm.picker.com    Ohio Imaging Nuclear Medicine Division
phone 216-473-7626      23060 Miles Road
fax 216-473-7390        Bedford Heights, Ohio 44128
- ----------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: re: RAMDISK/ROMDISK
Date: Tue, 20 Dec 1994 16:24:04 GMT
From: dat85715@indirect.com (D'Anne Thompson)
Organization: Internet Direct, indirect.com
Message-ID: <D14Aw4.4C@indirect.com>
References:  <9412200920.AA00735@rst.co.il>
Sender: dat85715@bud.indirect.com

In article <9412200920.AA00735@rst.co.il>
leonid@rst.co.il (Leonid Rosenboim) writes:

> > We recently completed a project which used a Radstone SME-1 4 MByte
> > Flash EEPROM board as a WFRM (Write Few, Read Many) solid state
> > "disk".  We used the vxWorks-supplied ramDrv as a model to create a
> > flashDrv driver.  We only had to stick some Radstone-specific Flash
> > EEPROM programming code into the ramBlkWrt() function.  Next, we had
> > vxWorks create a DOS filesystem on the board.  ...
> 
> This is not a very good idea: the DOS filesystem is updating certaing
> sectors very frequently (FATs, root dir, dirs), and the Flash parts
> all have a limitted erase-cycle life-time (means you can only erase
> a sector up to 100,000 times, after that the sector is dead).
> Depending on the type of parts you are using, and their respective
> erase cycle limit, the board will die on you.
> 
> The other drawback of this simplistic approach is that if a power
> failure occurs in the midst of the DOS file system updating the FAT,
> i.e. just after it erased the FAT sector(s) but before they have
> been reprogrammed, then you loose some or all of your files.
> 
> The only situation where such a solution is feasible, is when the files
> are updated only during software version upgrades or system reconfiguration,
> i.e. very infrequently and in a controlled manner. This is by no means
> a general solution !

For a solution using the Microsoft Flash File System, I would contact
RAMIX,
Inc.  The do pcmcia cards and software for VxWorks, and have software
for this.  There are two standards for file systems on Flash devices
and the Microsoft FFS is one of them (can't recall the other). It
implements a 'wear levelling' strategy to spread the usage among the
flash blocks equally. I would suggest contacting RAMIX at
1-818-349-6772.  Tell them D'Anne sent you
(maybe they'll give me a discount next time).

D'Anne Thompson
dat85715@indirect.com
dee@ioinc.tucson.az.us

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: CPU idle time on VxWorks -- Again
Date: Tue, 20 Dec 1994 16:39:22 GMT
From: dat85715@indirect.com (D'Anne Thompson)
Organization: Internet Direct, indirect.com
Message-ID: <D14BLn.Fs@indirect.com>
References:  <3d6r53$76q@crchha82.bnr.ca>
Sender: dat85715@bud.indirect.com

In article <3d6r53$76q@crchha82.bnr.ca>
sureshr@bnr.ca writes:

> 
> Spy command gives timing for individual tasks. I was looking for some command
> which gives the overall picture.

If you are looking for a module that will give you a simple percentage
of
cpu busy (or idle) try the VxWorks archive 'loadMeter.shar'.  The
manual page is what you will find there.  To get the source you will
have to write to 'bob@noao.edu' and ask him for a copy (identify
yourself and what you plan to do with the software - he's government
funded and they want to know who is getting their software and what
they are doing with it - 'technology transfer' you know).

Anyway here's a synopsis.

loadMeter(2)              SYSTEM CALLS               loadMeter(2)

loadMeter.c - cpu load meter module

SYNOPSIS

loadMeterSysInit - initialize the load meter system
loadMeterPercentSet - set a load meter value
loadMeterPercentGet - get current average load value (in percent)   
loadMeterOnOffSet - turn load meter on/off
loadMeterOnOffGet - return current on/off status of load meter system  
  loadMeterAsString - string representation of current load

STATUS  loadMeterSysInit (int delay, int samples)
STATUS  loadMeterPercentSet (double percent)
double  loadMeterPercentGet (void)
STATUS  loadMeterOnOffSet (BOOL flag)
BOOL    loadMeterOnOffGet (void)
char    *loadMeterAsString (void)

DESCRIPTION

This module implements a cpu load meter for a vxWorks system.
Current load is based upon the  number of cycles through the
idle task  loop in a  given period  of time.  The higher the
number, the  lower the cpu loading.   A low number of cycles
represents a high cpu loading.  (Idle time is (100% - load%)).

D'Anne Thompson
dat85715@indirect.com
dee@ioinc.tucson.az.us

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Changing file times.
Date: 20 Dec 94 17:55:14 GMT
From: froeber@bbn.com (Fred Roeber)
Organization: Bolt, Beranek and Newman Inc.
Message-ID: <froeber.787946114@labs-n.bbn.com>
References: <1994Dec20.152127.9206@picker.com>

heller@nm.picker.com (Mark Heller) writes:

>	I'm running VxWorks 5.1.1 and looking for a way to change
>	the dates on files on a Dos filesystem.

See the function dosFsTimeSet in VxWorks.   Fred
- -- 
   |  Fred J Roeber,  BBN Systems and Technologies |
   |       50 Enterprise Center, Suite 201         |
   |  Middletown, RI  02842-1087  (401) 849-2543   |
   |              froeber@bbn.com                  |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: CPU Idle time on Vxworks
Date: 20 Dec 1994 11:08:20 GMT
From: gournay@news.cea.fr (J.F. Gournay)
Organization: Resumix, Inc., Santa Clara, CA
Message-ID: <3d6dv4$939@anemone.saclay.cea.fr>
References: <3d539o$58d@crchha82.bnr.ca>
Reply-To: gournay@news.cea.fr

Use the spy comand. It will give you some outputs like the following:

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
- --------     --------      -----  ---   ---------------  ---------------
tExcTask     _excTask     3dcc54    0     0% (      23)    0% (       0)
tLogTask     _logTask     3da354    0     0% (       0)    0% (       0)
tShell       _shell       3abc70    1     0% (       1)    0% (       1)
tRlogind     _rlogind     3bab28    2     0% (       0)    0% (       0)
tTelnetd     _telnetd     3b8c84    2     0% (       0)    0% (       0)
tRlogOutTask _rlogOutTask   2cf300    2     1% (      59)    2% (      14)
tRlogInTask  _rlogInTask   2a7d0c    2     0% (       0)    0% (       0)
tSpyTask     _spyTask     2a67f4    5     2% (      82)    2% (      11)
tRdbTask     _rdbTask     3b6254   20     0% (       0)    0% (       0)
timeStamp    _gts_select   2d4ac0   32     0% (       1)    0% (       0)
callback     _callbackTask   2d6bb0   40     0% (       0)    0% (       0)
scanEvent                 2b6688   41     0% (       0)    0% (       0)
tNetTask     _netTask     3d5fc8   50     0% (      14)    0% (       0)
scanPeriod                2b8f48   53     0% (       1)    0% (       1)
scanPeriod                2bb808   54     0% (       0)    0% (       0)
tFtpdTask    _ftpdTask    3b3d9c   55     0% (       0)    0% (       0)
scanPeriod                2be0c8   55     0% (       0)    0% (       0)
scanPeriod                2c0988   56     0% (       0)    0% (       0)
callback     _callbackTask   2d9844   57     0% (       0)    0% (       0)
scanPeriod                2c3248   57     0% (       0)    0% (       0)
scanPeriod                2c5b08   58     0% (       0)    0% (       0)
scanPeriod                2c83c8   59     0% (       0)    0% (       0)
callback     _callbackTask   2dc4d8   65     0% (       0)    0% (       0)
tPortmapd    _portmapd    3b776c  100     0% (       0)    0% (       0)
CA TCP       _req_server   2d2b78  181     0% (       0)    0% (       0)
CA UDP       _cast_server   2d1600  182     0% (       0)    0% (       0)
CA online    _rsrv_online_notify_task   2d0078  183     0% (       0)    0% (       0)
taskwd                    2ddde4  200     0% (       0)    0% (       0)
KERNEL                                    0% (      32)    0% (       3)
INTERRUPT                                 0% (      11)    0% (       0)
IDLE                                     93% (    3426)   94% (     495)
TOTAL                                    96% (    3650)   98% (     525)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Has anyone ported scandir() ?
Date: 20 Dec 1994 17:44:54 -0800
From: gnn@tx.abekas.com (George Neville-Neil)
Organization: Abekas Video Systems, Inc.
Message-ID: <gnn.787974249@tx>

Hi Folks,

	I was wondering if anyone has ported Berkeley's scandir
function to vxWorks?

Thanks,
George

- -- 
George V. Neville-Neil		work: gnn@abekas.com     home:gnn@netcom.com

Home Page: ftp://ftp.netcom.com/pub/gnn/gnn.html
	
- -- 
George V. Neville-Neil		work: gnn@abekas.com     home:gnn@netcom.com

Home Page: ftp://ftp.netcom.com/pub/gnn/gnn.html
	

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VADSWorks (Ada on VxWorks)
Date: 21 Dec 1994 05:40:35 GMT
From: COBARRUVIAS@ASD1.JSC.NASA.GOV (COBARRUVIAS_JOHN)
Organization: NASA/JSC
Message-ID: <3d8f4j$att@pendragon.jsc.nasa.gov>
References: <00988FB6.3321E960.19@cub.kscorp.com> <3d66c2$snb@rational.rational.com>

In <3d66c2$snb@rational.rational.com> corey@rational.com writes:
[points 1-4 deleted]
> 
> : 5) If you go with APEX, then you have another layer to integrate. APEX over
> : VADS over VxWorks. I would be very cautious about this product. Try before
> : you buy. We did and we won't use it.
> 
> APEX II (which is a combination of APEX's front-end tools with VADS
> back-end and debugger + plus some new features) will be integrated with
> VADSworks.  This will be a much smoother product than the present
> combination of APEX and VADS.  I don't know the projected date, but I'd
> guess it's at least Q3 1995.
> 

Again, my point still stands. Try before you buy. 
I've heard about this integration of front end products (which are 
pretty good) and backend products (which are also pretty good) way back 
in '89 when it was called rcf. Now it is APEX and now APEX II and I 
still haven't SEEN the integration. Try before you buy.

> 
> - Corey
> 
> == My comments do not represent any official position of Rational Software
> Corp.  Please contact a sales rep for schedules ==
> 
> Internet: corey@rational.com
> Sneakernet: down_the_hall!right_at_the_mens_room!past_the_stain_on_the_wall!...
> Rational Software Corporation
> 1600 N.W. Compton Drive, Suite #357
> Aloha, OR 97006
> ph# (503) 690-1116 x6710

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GreenHills Ada on VxW
Date: 21 Dec 94 11:43:33 -0400
From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer)
Organization: NRL SPACE SYSTEMS DIVISION
Message-ID: <1994Dec21.114333.1515@nrlvx1>
References: <9412160956.AA01103@rtp.co.uk>

In article <9412160956.AA01103@rtp.co.uk>, djb@rtp.co.uk (David Bullimore) writes:
> Re:
>> original question from Matt Whiting (whiting_ms@corning.com) 
>> about Ada compilers available for use with VxWorks. 
> 
> GreenHills are selling their Ada compiler for use with VxWorks. Has
> anyone had experience of using this combination?
> 
> 

I got a rather lengthy dose from a greenhills sales demo recently.
Seems their one (_big_) advantage (which he didn't really understand)
was that there was apparently no modification of the vxworks kernel.
Therefore, unlike vadsworks, vxworks may be purchased and supported by
WRS directly (and upgrades such as 5.2 should come quicker - no 
waiting on rational to rebuild their version of it). One problem for us
is that they no longer support the SGI (but "for us" they'd
do it... yeah).

He shied away from providing references in a big way. Im still interested
with their low cost, and since I sometimes have to modify the kernel
in some way with the sometimes wacky hardware I deal with, an unmodified
WRS kernel is a good plus, IMHO.  Also, I feel that WRS is more supportive
for kernel mods than I sense rational is (IMO). 

There was the usual dosage of compiler specs, and their code management
stuff... Im so uninterested in that.  I was/am looking for a reliable
transparent ADA for vxworks and walked away with an unsure feeling
on their package.

Anyone care to rant and rave about MULTI? BTW, their MULTI GUI 
is for the *DOGS*.

bye,
Doug
- -- 
Doug Dyer   -  dyer@alx.sticomet.com | Real-time systems       . *  //[]//
Software Technology, Inc. (STI)	     | Space flight/ground software   ^^ .
DC office: (703) 329-9707            | vxWorks BSPs, etc.	       .

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: NTDS boards
Date: Wed, 21 Dec 1994 21:21:16 GMT
From: rrailey@relay.nswc.navy.mil (Rene H. Railey)
Organization: NSWCDD, Dahlgren, VA 22448
Message-ID: <rrailey.40.00105ADF@relay.nswc.navy.mil>
References: <199412161938.OAA21574@piranha.ssd.ray.com> <3d4s5b$4km@aplcomm.jhuapl.edu>
Sender: news@relay.nswc.navy.mil (oanews)

In article <3d4s5b$4km@aplcomm.jhuapl.edu> Fran Horan <franfh@aplexus.jhuapl.edu> writes:
>Path: oanews!relay2!relay!night.primate.wisc.edu!caen!zip.eecs.umich.edu!newshost.marcam.com!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!uunet!netnews.jhuapl.edu!fran.jhuapl.edu!franfh
>From: Fran Horan <franfh@aplexus.jhuapl.edu>
>Newsgroups: comp.os.vxworks
>Subject: Re: NTDS boards
>Date: 19 Dec 1994 20:58:19 GMT
>Organization: JHU/APL
>Lines: 11
>Distribution: world
>Message-ID: <3d4s5b$4km@aplcomm.jhuapl.edu>
>References: <199412161938.OAA21574@piranha.ssd.ray.com>
>NNTP-Posting-Host: fran.jhuapl.edu
>X-Newsreader: Nuntius Version 1.2
>X-XXMessage-ID: <AB1B5E57DB0142DA@fran.jhuapl.edu>
>X-XXDate: Mon, 19 Dec 1994 20:59:19 GMT

>NTDS boards

>We use the Antares VMENIO board sold by Visicom in San Diego Ca. for
>several of our mission-critical embedded systems on Navy ships.  Their
>phone number is 619-457-2111.  We have several drivers developed in house
>but Visicom was planning to release a driver last time I talked to them. 
>I would investigate theirs first and see if it is made to work with
>vxWorks.  We are happy with their product and support.
>Fran Horan
>franfh@aplexus.jhuapl.edu
>FranHoran@aol.com

In addition we are in looking at a NTDS board from Sabtech Industries. The 
Hawk model has been out for sometime and a new Falcon model is up for release. 
You will find that the Antares cards are simple in their design with no 
onboard CPU for decision. The Sabtech Boards have a bp driver for vxWorks and 
as of now use a 68020 processor for more flexability. We have used Antares 
Cards in the past and have been very pleased. This move to Sabtech is to 
explore other options. A Sabtech rep can be reached at NewTech Associates at 
(301) 937-6822. They are Sabtech resellers.

Rene H. Railey					! This is my opinion
Naval Surface Warfare Center			! and does not necessarily
Dahlgren Division Code  F33			! reflect the views of my
Dahlgren, VA  22448-5000			! employer.
(703) 663-6276
rrailey@relay.nswc.navy.mil     

P.S 	Elvis is a deadhead

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: CPU Idle time on Vxworks
Date: Thu, 22 Dec 1994 14:18:31 GMT
From: clegg@ssd.fsi.com
Organization: Flightsafety International, Broken Arrow, OK
Message-ID: <1994Dec22.141831.25502@dev1.ssd.fsi.com>
References: <3d539o$58d@crchha82.bnr.ca> <3d6dv4$939@anemone.saclay.cea.fr>
Reply-To: clegg@ssd.fsi.com
Sender: news@dev1.ssd.fsi.com

In <3d6dv4$939@anemone.saclay.cea.fr>, gournay@news.cea.fr (J.F. Gournay) writes:
>Use the spy comand. It will give you some outputs like the following:
>
Be careful when using the spy command.  We have found that under certain
circumstances it is unstable.  During one particularly bad instance, it was saying that
a task was using 89-100% of the CPU time when the task was actually using 10% to
a max of 30%.  The same task was also indicated by spy() to be using 0% of the CPU
time later when it was running under the same state using the same amount of time.
We eventually gave up on spy and wrote our own routines which used the VMEChip2
timers and allowed us to measure min/max and avg time inside a task.  Granted, in
a multitasking system, these times may include execution of higher priority tasks, but
I am really only concerned with how much a frame a task takes up in ANY circumstance
and not just the average, which is the only thing that spy can measure.  Even though
spy uses the PCCChip2 timers, I believe you could gather the same information easily
by counting the number of timer interrupts (ticks) between times and adding the
timer count to get the current "time" in microseconds.
FYI
Roger Clegg
clegg@ssd.fsi.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: ld error
Date: 22 Dec 1994 21:07:10 GMT
From: bqv@se19.wg2.waii.com (Bang Q. Vu)
Organization: Western Geophysical Exploration Products
Keywords: ld
Message-ID: <3dcppu$3k7a@ep130.wg2.waii.com>
Reply-To: vu@wg2.waii.com

I used the "ld" command to load an object file from a SPARC station
to a MVME147 target and got the following error:

loadAoutLib error: insufficient memory for externals table (need 209872 bytes)
ld error: error reading file.

I used the ld option that add only global symbols to the symbol table.
Am I getting a "too many symbols" error here? If so, how do I overcome
this limitation?

- -- 
Bang Vu                        Western Geophysical, a division of
                               Western Atlas International Inc.
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                               Email  :  vu@wg2.waii.com
                               Voice  :  (713) 964-6192
                               Fax    :  (713) 964-6218

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: CPU Idle time on Vxworks
Date: 22 Dec 1994 22:56:19 GMT
From: berg@fnal.fnal.gov (David Berg)
Organization: FERMILAB, Batavia, IL
Message-ID: <3dd06j$25m@fnnews.fnal.gov>
References: <1994Dec22.141831.25502@dev1.ssd.fsi.com>
Reply-To: berg@fnal.fnal.gov

In article 25502@dev1.ssd.fsi.com, clegg@ssd.fsi.com () writes:
>In <3d6dv4$939@anemone.saclay.cea.fr>, gournay@news.cea.fr (J.F. Gournay) writes:
>>Use the spy comand. It will give you some outputs like the following:
>>
>Be careful when using the spy command.  We have found that under certain
>circumstances it is unstable.  During one particularly bad instance, ...

spy() uses the auxiliary clock, which for the mv167, is implemented by a
PCCchip2 timer. The system clock for the mv167 is also implemented using
a PCCchip2 timer. Although they are separate counters, they both derive
from the same clock, and are therefore synchronous. The default tic rates
are 100 Hz for the auxiliary clock and 60 Hz for the system clock, which
are fairly commensurate (least common multiple is 300). Kernel scheduling
events triggered by the system clock have a good chance of maintaining a
constant phase with respect to the auxiliary clock; therefore, spy() is
prone to systematic errors.

The best alternative is to implement the auxiliary clock using a timer
that is truly independent of the system clock timer, eg, one of the
VMEchip2 timers. You might also vary the tic rates; try using prime
numbers, eg, 101 and 61.

If you really want to be sure that you're measuring what you want to, I
would agree that the best approach is to code your own routines using a
PCCchip2 timer.

- --------------------------+---------------------------------------------
   "A nanosecond here,    |    David M. Berg      (berg@fndaut.fnal.gov)
   a nanosecond there,    |  Computing Division
 and pretty soon you're   |    Fermilab MS120
talking about Real Time." |      PO Box 500        tel: 708-840-3021
(apologies to the late    |   Batavia IL 60510     fax: 708-840-2783
 Sen. Everett Dirksen)    |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Driver/Source for a Motorola MVME376 Ethernet pcb
Date: Fri, 23 Dec 1994 02:09:08 GMT
From: hjb@netcom20.netcom.com (squeedy)
Organization: Peaceful Star, Oakland, CA
Message-ID: <HJB.94Dec22180909@netcom20.netcom.com>
References: <199412201653.JAA15400@den.mcd.mot.com>
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com (squeedy)

>>>>> "Lenny" == Lenny Bates <lenny@den.mcd.mot.com> writes:
In article <199412201653.JAA15400@den.mcd.mot.com> Lenny Bates <lenny@den.mcd.mot.com> writes:

    Lenny> Greetings, Does anyone know if a driver and source code for
    Lenny> the Motorola MVME376 (Hawk) Ethernet interface pcb is
    Lenny> avaliable. A driver for VXworks, HP/UX or Solaris would be
    Lenny> considered.

the UNIX drivers for the MVME37X (at least MVME372 and MVME374) i have
worked on previously are based on BPP (buffered-pipe protocol) and CE
(common environment) standard over VME backplane, which were
motorola-specific standards for talking to intelligent periperal
boards.  as far as i know the firmware running on the "stock" MVEM37X
expects the BPP/CE for all packet exchanges to and from the host CPU.
this mechanism was painfully slow, and it was very hard to get any
good performance from these boards.

i have never heard of anyone doing a driver that uses BPP/CE for
vxworks.  

the drivers for MVME37X i have hacked on while at unisoft were part of
a STREAMS TCP/IP package.  the driver interface to the IP layer was
different from any other modern STREAMS network device drivers.  i
believe motorola SVR3.2 for delta boxes with NSE option includes this
TCP/IP along with the device driver.  this TCP/IP was different from
anyone else's; it was entirely written from scratch for STREAMS
environment, before any real concrete standards for TPI or DLPI
existed.  some of the older TPI interface is present in the
implementation, but the device driver interface is very different, and
would pose serious rewriting for modern operating systems, whether or
not the target TCP/IP suite is based on STREAMS.

an older release of Vxworks had a optional VME backplane STREAMS
driver for this UNIX TCP/IP.  i believe there are several sites using
this driver currently within SVR3.X on motorola MVME cpu based
systems.  if you compare this backplane device driver with the
original BSD style backplane driver you can figure out how to port a
NSE MVME37X driver to HP/UX and SunOS, both of which are based on BSD
networking code.   as for the BPP/CE motorola might still have some
documentation on this.

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, 4001 San Leandro St. #3, Oakland, CA 94601	(510)436-2884

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP/IP & Mbuf configuration
Date: Fri, 23 Dec 1994 02:38:14 GMT
From: hjb@netcom20.netcom.com (squeedy)
Organization: Peaceful Star, Oakland, CA
Message-ID: <HJB.94Dec22183814@netcom20.netcom.com>
References: <9412142227.AA04474@jupiter.mtvyp> <3cqj6i$s30@fnnews.fnal.gov>
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com (squeedy)

>>>>> "David" == David Berg <berg@fnal.fnal.gov> writes:
In article <3cqj6i$s30@fnnews.fnal.gov> berg@fnal.fnal.gov (David Berg) writes:

    Sanjay> I was wondering how to change the number of mbufs used by
    Sanjay> the network stack on vxWorks.  From what I understand, the
    Sanjay> way to do this is change a constant in the mbuf.h header
    Sanjay> file and recompile.  Is this correct?

in Vxworks 5.1 and later, yes.  in vxworks 5.0 and earlier, no.

    Sanjay> There is a concern that our system is having a
    Sanjay> producer/consumer problem with the mbufs.  Can we check
    Sanjay> the validity of this scenario out by using mbufShow?  I
    Sanjay> noticed a peg saying "number of times failed to find
    Sanjay> space".  Does this tell you the number of times an mbuf
    Sanjay> was requested, but the request was blocked because there
    Sanjay> were not any mbufs available at the time.  Are there any
    Sanjay> other ways?

    David> I believe this is the number of times it had to malloc more
    David> mbufs. What happens when you reach the max, or run out of
    David> memory? Your network hangs until something frees up.

the mbufs are allocated one or more clusters at a time.  the number
you mention is an indication of the number of times this allocation
was tried (i.e. memPartAlloc was attempted to mbuf memory partition)
but failed.  the network code tries its best to drain all the mbufs it
can, but the problem may not go away due to incorrect use of mbufs in
device drivers.

    David> I encountered a problem where one of the symptoms was that
    David> the number of allocated mbufs would shoot up, far above
    David> what should normally be used.  (There was a problem in the
    David> network interface driver in the way it queued jobs to
    David> netTask, which runs them serially.) I mention this because
    David> you may also be seeing a symptom of an underlying problem,
    David> in which case simply allocating more mbufs won't fix it.

a good network device driver should do minimal amount of mbuf
management to prevent mbuf exhaustion.  especially, smart network
drivers that loan mbufs to protocol layers have to take care and not
loan out too many (the user may not be reading), and alway fall back
to copy mode if loaning doesn't look like it's the right thing to do.

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, 4001 San Leandro St. #3, Oakland, CA 94601	(510)436-2884

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Can VxWorks coexist with other OS on VMEbus?
Date: Fri, 23 Dec 1994 02:18:30 GMT
From: hjb@netcom20.netcom.com (squeedy)
Organization: Peaceful Star, Oakland, CA
Message-ID: <HJB.94Dec22181830@netcom20.netcom.com>
References: <3co9fa$gm8@usenet.INS.CWRU.Edu>
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com (squeedy)

>>>>> "Yoohwan" == Yoohwan Kim <yxk14@po.CWRU.Edu> writes:
In article <3co9fa$gm8@usenet.INS.CWRU.Edu> yxk14@po.CWRU.Edu (Yoohwan Kim) writes:

    Yoohwan> I'm working on a project with multiple robots and
    Yoohwan> controllers.  We want to develop a C++ program on a
    Yoohwan> separate host computer to control the existing robot
    Yoohwan> controller.  Our controller has motion processors, vision
    Yoohwan> processors, I/O boards, system processor, and a Motorola
    Yoohwan> 68030 board which may be used to run a downloaded
    Yoohwan> program. Rather than developing tedious shared memory and
    Yoohwan> message passing routines, we prefer to use an existing
    Yoohwan> product.  The whole VMEbus is governed by the V+
    Yoohwan> Operating system which runs on the system processor. Will
    Yoohwan> VxWorks cooperate with the the existing OS ?

yes.

    Yoohwan> It seems that even in heterogeneous system, all the
    Yoohwan> processor boards should run VxWorks to properly
    Yoohwan> communicate, is that true ?  If VxWorks cannot do it, is
    Yoohwan> there any other real time OS which can coexist with other
    Yoohwan> OS on the same VMEbus ?

vxworks coexists fine with other OS'es on VMEbus.  i have done work
that involved SunOS, Solaris, and Motorola SVR3  running on the same
backplane as multiple VxWorks based boards.

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, 4001 San Leandro St. #3, Oakland, CA 94601	(510)436-2884

---------------------------

Newsgroups: comp.os.vxworks
Subject: Embedded Systems Design Symposium
Date: Thu, 22 Dec 1994 12:54:49 GMT
From: keesb@neth.hp.com (Kees Bos EMO)
Organization: HP-Sales Office-The Netherlands
Message-ID: <3dbsup$88o@hpuamsa.neth.hp.com>

[ Article crossposted from comp.realtime ]
[ Author was Kees Bos EMO (keesb@neth.hp.com) ]
[ Posted on 22 Dec 1994 12:52:01 GMT ]

Dear Designer,

This is the final notice for the 1995 Hewlett-Packard Embedded Ssytems Design
Symposium.  The symposium is a one-day event consisting of the presentation
of two technical papers. There is NO charge for attendance. 
Papers will be given by industry experts and consultants on a variety of 
important topics as detailed at the end of this notice.

If you are interested in attending please reply to this message to:

        keesb@hpaichd.neth.hp.com

Please include your postal mailing address so that an invitation can be sent
to you immediately.

Regards,

Kees Bos
Hewlett-Packard

*************************************************************************

Venues and dates are as follows:

        Date            Stop
	-----		----
	Jan 30		Madrid          
	Feb  1     	Toulouse       
	Feb  2		Grenoble
	Feb  3     	Les Ulis     
	Feb  6     	Bracknell    
	Feb  7     	Manchester 
	Feb  8     	Edinburgh
	Feb 10    	Dublin    
	Feb 13    	Brussels 
	Feb 14    	Bad Homburg     
	Feb 15    	Munich         
	Feb 17    	Milano        
	Feb 20    	Zurich       
	Feb 22    	Vienna      
	Feb 24    	Berlin     
	Feb 27    	Helsinki  
	Mar  1     	Copenhagen
	Mar  3     	Amsterdam 
	---           	 ----

Papers Presented as follows:

Methods for Successful Embedded Hardware Design.

This session includes several examples of current methods and
skills, as well as recommendations for streamlining product
design.  The module, which targets experienced engineers, covers
a range of topics including complex system design, ASIC design,
programmable logic design, PC board design, custom design
considerations, hardware/firmware/software architecture
trade-offs, and real-time system design.

Using a Real-Time Kernel in Embedded Systems.

This session examines various techniques for mapping out
software to work in conjunction with real-time kernels.  The
presentation investigates performance reliability tradeoffs,
shared data decisions, memory allocation methods, error-prone
software strategies (interrupt routines, re-entrant code), task
management, module partitioning, interrupt routines (data
sharing, memory buffers, polling), asynchronous service
routines, timers, and stack problems.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Green Hills
Date: Sun, 25 Dec 1994 23:36:36
From: terra@tiac.net (Ophira Rosolio Aharonson)
Organization: Terra Computers Inc.
Keywords: Fortran compilers
Message-ID: <terra.88.00179CD9@tiac.net>

Looking for info about Green Hills (addrees, phone, fax, e-mail) or any other 
supplier of FORTRAN compiler under VXworks, Thanks Ophira terra@tiac.net
Ophira Rosolio-Aharonson
Terra@Computers Inc.
terra tiac.net

---------------------------

Newsgroups: comp.os.vxworks,comp.os.realtime
Subject: Timer interrupts in VxWorks
Date: 26 Dec 1994 21:17:07 -0500
From: partho@cs.umd.edu (partho pratim mishra)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Message-ID: <3dntf3$12p@seine.cs.umd.edu>

 I was thinking of driving a VxWorks task off the timer interrupt
(i.e using the timerLib facilities). I would like to be able to do 
things at a fairly fine time granularity e.g. on the order of several
hundred milliseconds. The VxWorks manuals suggest that running the
clock at a frequency greater than 600 Hz will chew up most of the
available cpu cycles.

>tickAnnounce(2)     VXWORKS REFERENCE MANUAL      tickAnnounce(2)

>NAME
>    tickAnnounce() - announce a clock tick to the kernel

>SYNOPSIS
>     void tickAnnounce (void)

>DESCRIPTION

> This routine informs the kernel of the passing of time.   It
>    should  be  called from an interrupt service routine that is
>    connected to the system clock.  The most common  frequencies
>    are  60Hz  or  100Hz.  Frequencies in excess of 600Hz are an
>    inefficient use of processor power because the  system  will
>    spend  most  of  its  time advancing the clock.  By default,
>     this routine is called by usrClock() in usrConfig.c.

 Does anyone have any practical experience with driving the system
at a higher clock rate eg 1000 Hz or 2000 Hz? Any idea why 600 Hz
is the magic number given that interrupt processing times are
supposed to be less than 100 microsecs.

Thanks

Partho Mishra

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Timer interrupts in VxWorks
Date: 27 Dec 1994 08:41:06 GMT
From: vwnemg@NEON2.iap.uni-bonn.de (Patrick Umlauf)
Organization: Institut fuer Angewandte Physik, Universitaet Bonn
Message-ID: <3dojv2$nlt@news.rhrz.uni-bonn.de>
References: <3dntf3$12p@seine.cs.umd.edu>

     partho pratim mishra wrote in article <3dntf3$12p@seine.cs.umd.edu> :
>
> I was thinking of driving a VxWorks task off the timer interrupt
>(i.e using the timerLib facilities). I would like to be able to do 
>things at a fairly fine time granularity e.g. on the order of several
>hundred milliseconds. The VxWorks manuals suggest that running the
>clock at a frequency greater than 600 Hz will chew up most of the
>available cpu cycles.
>
>>tickAnnounce(2)     VXWORKS REFERENCE MANUAL      tickAnnounce(2)
>
>>NAME
>>    tickAnnounce() - announce a clock tick to the kernel
>
>>SYNOPSIS
>>     void tickAnnounce (void)
>
>>DESCRIPTION
>
>> This routine informs the kernel of the passing of time.   It
>>    should  be  called from an interrupt service routine that is
>>    connected to the system clock.  The most common  frequencies
>>    are  60Hz  or  100Hz.  Frequencies in excess of 600Hz are an
>>    inefficient use of processor power because the  system  will
>>    spend  most  of  its  time advancing the clock.  By default,
>>     this routine is called by usrClock() in usrConfig.c.
>
> Does anyone have any practical experience with driving the system
>at a higher clock rate eg 1000 Hz or 2000 Hz? Any idea why 600 Hz
>is the magic number given that interrupt processing times are
>supposed to be less than 100 microsecs.
>
>Thanks
>
>Partho Mishra
>

My version of VxWorks only accepts rates of 50 or 100 Hz for the system
clock. These numbers are predefined in the source of sysLib.c. Changes are
of course possible but not useful. Since the usrClock controls task scheduling
and system duties every tick uses lots of cpu-time for changing environment
variables or performing delay and watchdog facilities.
100 ticks per second should therefore be the upper limit, otherwise the system
will be occupied with itself.

But why not using the sysAuxClk-Routines (sysLib.h)?
The auxClk-timer's interrupts only call a user definable routine, nothing else.
In my sources this routine is just an incremental counter to provide a clock 
of 1 msec resolotion. I use it with a dac-device as a function generator for
any desirable wave forms to scan a laser. 
I think the rates for auxClk should not exceed 2000 Hz to preserve system 
efficiency.
 

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

            /\            Patrick Umlauf                      
           /  \           Institut fuer Angewandte Physik     
          /    \          Universitaet Bonn                   
         /      \         Wegelerstrasse 8                   
        / \|/    \        D-53115 Bonn, Germany
       / > *----- \
      /   /|\      \      FAX 0228 - 733474
     /              \           
    /________________\    E-Mail: vwnemg@NEON2.iap.uni-bonn.de
    
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Timer interrupts in VxWorks
Date: 27 Dec 1994 18:22:57 GMT
From: berg@fnal.fnal.gov (David Berg)
Organization: FERMILAB, Batavia, IL
Message-ID: <3dpm21$44c@fnnews.fnal.gov>
References: <3dntf3$12p@seine.cs.umd.edu>
Reply-To: berg@fnal.fnal.gov

In article 12p@seine.cs.umd.edu, partho@cs.umd.edu (partho pratim mishra) writes:
> I was thinking of driving a VxWorks task off the timer interrupt
>(i.e using the timerLib facilities). I would like to be able to do 
>things at a fairly fine time granularity e.g. on the order of several
>hundred milliseconds. The VxWorks manuals suggest that running the
>clock at a frequency greater than 600 Hz will chew up most of the
>available cpu cycles.

Even 60 Hz, which is 17 msec granularity, would meet a "several hundred
milliseconds" requirement. What rate do you really need?

>
> Does anyone have any practical experience with driving the system
>at a higher clock rate eg 1000 Hz or 2000 Hz? Any idea why 600 Hz
>is the magic number given that interrupt processing times are
>supposed to be less than 100 microsecs.

We routinely run mv167's with a system clock rate of 1000 Hz to obtain
millisecond scheduling resolution; for our application, this consumes
only about 2% of the idle cycles, so the impact is minimal.

I don't know where WRS obtained the 600 Hz figure. Actual impact will
depend upon application, and of course on the specifics of the target
board. We use 33 MHz MVME167s, for which the system clock is based on
a timer that can be set to any rate within a wide range. Other boards
may have timers with limited programmability, so they can only be set
to a few specific rates (eg, 50 Hz, 100 Hz).

- --------------------------+---------------------------------------------
   "A nanosecond here,    |    David M. Berg      (berg@fndaut.fnal.gov)
   a nanosecond there,    |  Computing Division
 and pretty soon you're   |    Fermilab MS120
talking about Real Time." |      PO Box 500        tel: 708-840-3021
(apologies to the late    |   Batavia IL 60510     fax: 708-840-2783
 Sen. Everett Dirksen)    |

---------------------------

Newsgroups: comp.os.vxworks
Subject: FTP site for MVE166/167
Date: 28 Dec 1994 19:13:48 GMT
From: Steve Rejto <srejto@ll.mit.edu>
Organization: MIT Lincoln Laboratory
Message-ID: <3dsddc$phr@testnews.llan>

Is there an FTP site which has VxWorks drivers on it. In particular
i'm looking for routines for source code to drivers for the 
MVE166/167 (serial ports.parrallel port,SCSI) etc.

Thanks,

srejto@ll.mit.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Help!  ISR causes NFS to die!
Date: 30 Dec 1994 17:24:09 -0600
From: sabolcik@natinst.com (Ross Sabolcik)
Organization: National Instruments, Austin, TX
Message-ID: <3e24qp$4gt@eagle.natinst.com>

Hello All:

I am having the following problem which has been causing me great
grief.  I have a small test program running on my embedded computer
which generates a series of bus errors, then attemtps to read and
write to a NFS mounted remote file.  The program is shown below:

int toto(void)
{
for(;;)
  {
    A16Base = 0xffff0000;
    for(la = 0; la < 85; la++){
      manId = (uint16)*((uint16 *)(A16Base + 0xC000 + (0x40 * 5) + 0));

      manId = (uint16)*((uint16 *)(A16Base + 0xC000 + (0x40 * 6) + 0));

      manId = (uint16)*((uint16 *)(A16Base + 0xC000 + (0x40 * 7) + 0));
    }

    /*read the loop count */
    if ( (fd = fopen(OUTFILE, "r")) == NULL)
      {
        printf("ERROR :   fdFichier = 0x%x\n", *fd);
        return(-1);
      }

    fscanf(fd,"%ld", &count);
    fclose(fd);

    count++;

    /* write the loop count */
    if ( (fd = fopen(OUTFILE, "w+")) == NULL)
      {
        printf("ERROR : fichier :   fdFichier = 0x%x\n", *fd);
        return(-1);
      }

    fprintf(fd,"%ld", count);
    fclose(fd);
    
  }
}

The pointer dereferences shown above cause Bus Errors (I do not see
this problem when the pointer dereference doesn't Bus Error). 

 After running a variable number of loops, one of the fopen calls will
fail causing the program to exit.  When I get back to the shell
prompt, I have lost all of my remote file systems.  Any attempt to
change into a remote directory or examine the files on a remote file
system fails.  I am able to do a stack dump from the shell prompt when
I attempt to access a remote file and here is what I get:

 44e70 _ls            +1e : _opendir (449e6)
 22716 _opendir       +e  : _open (449e6, 0, 0)
 2a65c _open          +80 : _iosOpen (321fa0, 31dee4, 0, 0)
 2b314 _iosOpen       +32 : 1ae54 ([321fa0, 31dee4, 0, 0, 449e7])
 1af1e _nfsUnmount    +1ba: _nfsLookUpByName (321fae, 31dd90, 3220ee, 31dd28, 31dd08)
 1bd5a _nfsLookUpByName+da : 1c920 (321fae, 186a3, 2, 4, &_xdr_diropargs, 31dcb4, &_xdr_diropres, 31dd28)
 1c94c _nfsFileAttrGet+328: 1c78a (3fdb84, 321fae, 186a3, 2)
 1c828 _nfsFileAttrGet+204: _clntudp_create (31d7b0, 186a3, 2, 5, 0, 3fdb88)
 3eb5e _clntudp_create+24 : _clntudp_bufcreate ([31d7b0, 186a3, 2, 5, 0])
 3e9cc _clntudp_bufcreate+88 : _pmap_getport (31d7b0, 186a3, 2, 11)
 3f0f8 _pmap_getport  +94 : 3eb66 (3fdb5c, 3, &_xdr_pmap, 31d6bc, &_xdr_u_short, 31d6b6, 3c, 0)
 3ecec _clntudp_create+1b2: _semQPut (100, 31d664, 0, 0, 3237d0)

Now the semQPut looks purty suspicious to me.  So what I am thinking is.....

something (most likely my ISR) is corrupting the memory location used
by the semQPut shown above.  This corruption makes the semaphore
appear to be taken/locked.  This causes the file system call shown
above to wait for the semaphore to free.  However, no one has taken
the semaphore (it was corrupted) and eventually the call times out.

My problem is that semQPut is an undocumented kernel call (I
can't find any documentation), so I am not sure what it really does.

THE QUESTION IS HERE
      |  |
    ---  ---
    \      /
     \    /
      \  /
       \/
Does anyone with more vxWorks NFS experience have any idea what is
really going on in the stack dump I've shown above?

Any help would be greatly appreciated.

- --------------------------------------------------------------------------------
                                 Ross Sabolcik
                             VXI Software Engineer
                              National Instruments          
                           6504 Bridge Point Parkway
                             Austin, TX 78730-5039                             
- --------------------------------------------------------------------------------
- --------------------------------------------------------------------------------
Email: sabolcik@natinst.com
- --------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: dosFs VOLUME_NOT_AVAILABLE
Date: 28 Dec 1994 18:59:56 -0800
From: alann@tx.abekas.com (Alan Nishioka)
Organization: Abekas Video Systems. Inc.
Message-ID: <3dt8nc$2lq@tx.abekas.com>

THE SITUATION:
We are using VxWorks 5.1 with a dosFs filesystem on an Iomega Io20s
scsi floptical drive.

THE SYMPTOMS:
If you insert a disk and then immediately access it, dosFs returns:

- -> ls
error reading entry (errno=0x380001)
value = -1 = 0xffffffff = scsiready.o_bss + 0xc7cb8463

The errno is for S_dosFsLib_VOLUME_NOT_AVAILABLE.
Subsequent accesses return (forever):

- -> ls
Can't open ".".
value = -1 = 0xffffffff = scsiready.o_bss + 0xc7cb8463

THE PROBLEM:
DosFs gets a device not ready and refuses to try again.  The problem is
more severe with a 20MB floptical than it is with a 1.44MB floppy because
the floptical drive is not ready for a longer period of time.

Our current solution of inserting a disk and counting slowly to ten is
not acceptable for our customers :-)

THE QUESTION:
Does anybody know how to get around this?  I have looked in all the manuals
and in some mail about using vxWorks with floppies. 
We don't have source to dosFsLib.
_______________________________________________________________________________
Alan Nishioka	             alann@abekas.com                      415 599-3024
Abekas Video Systems         101 Galveston Drive        Redwood City  CA  94063

---------------------------

Newsgroups: comp.os.vxworks
Subject: Motorola MC68681 driver
Date: Wed, 4 Jan 1995 13:37:38 GMT
From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1995Jan4.133738.17760@hgl.signaal.nl>
Sender: usenet@hgl.signaal.nl (USENET News System)

Hello,

We are currently developing a Vxworks application with a 68020 processor
and a MC68681 duart.

question :
	We are looking now for a MC68681 driver that supports the serial IO
	and that uses the MC68681 timer for the system clock.

Please email me if you have some information.

	Thanks,
		--Ben--

- -- 
==============================================================================
= B.J.M. Vloedbeld    Dept:SDA-DID-DIM   Org:Hollandse Signaalapparaten B.V. =
= Adress : P.O.box 42 7550 GD Hengelo, The Netherlands                       =
= Phone :+31-74-483994 FAX:+31-74-484009  email:bjm_vloedbeld@hgl.signaal.nl =
=============================================================[Unclassified]===

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQ and ftp site info
Date: 04 Jan 1995 21:37:02 GMT
From: wilson@ssdd475a.erim.org (Paul Wilson)
Organization: Environmental Research Institute of Michigan, Ann Arbor, Michigan
Message-ID: <WILSON.95Jan4163703@ssdd475a.erim.org>
Sender: news@newsspool.erim.org

Is there an FAQ available for this group?  Where might I obtain it?
Also, I have a requirement to produce a Sun readable TAR tape from 
a vxworks application.  Is there a netware package to do that?

	Thanks in advance for assistance.

	regards,
		Paul Wilson
		wilson@erim.org

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQ and ftp site info
Date: 04 Jan 1995 22:09:32 GMT
From: wilson@ssdd475a.erim.org (Paul Wilson)
Organization: Environmental Research Institute of Michigan, Ann Arbor, Michigan
Message-ID: <WILSON.95Jan4170932@ssdd475a.erim.org>
Sender: news@newsspool.erim.org

Is there an FAQ available for this group?  Where might I obtain it?
Also, I have a requirement to produce a Sun readable TAR tape from 
a vxworks application.  Is there a netware package to do that?

	Thanks in advance for assistance.

	regards,
		Paul Wilson
		wilson@erim.org

---------------------------

Newsgroups: comp.os.vxworks,gnu.gcc.help
Subject: ld MEMORY command, multiple regions per section possible?
Date: 4 Jan 95 22:26:52 GMT
From: kab@dtl.labs.tek.com (Kent Black)
Organization: DTL, Tektronix, Inc.
Keywords: a.out, MEMORY
Message-ID: <6986@crl.labs.tek.com>
Followup-To: comp.os.vxworks
Sender: news@crl.labs.tek.com

I would like to be able to put a globally accessible object (an OS
specific symbol table for debugging) into some slow (or even optional)
memory.  I'm thinking a chunk of ROM for text, a smallish chunk of RAM
for data and bss, and "somewhere else" for this other big chunk of
initialized data (otherwise I'm short of usable RAM).

Using a.out format (68k arch), is it possible to have a section, in
particular .data, divided among memory regions?

Consider the following ld script:
    
    OUTPUT_FORMAT("a.out-sunos-big")        /* output .o file format */
    TARGET("a.out-sunos-big")               /* input .o file format */
    ENTRY("_romSP")                         /* entry point */
    
    MEMORY  {
            rom : ORIGIN = 0xfB000000, LENGTH = 2M
            ram : ORIGIN = 0x06020000, LENGTH = 512K
            }
    
    SECTIONS {
            .text : {
                    CREATE_OBJECT_SYMBOLS
                    *(.text)
                    _etext  =  .;
                    } > rom
    
            .data : {
                    *(.data)
                    _builtForRom = .;
                    SHORT(0);
                    _edata  =  .;
                    } > ram
    
            .bss SIZEOF(.data) + ADDR(.data) :
                    {
                    *(.bss)
                    [ COMMON ]
                    _end = .;
                    __end = .;
                    } > ram
            }
    
Now, my first thought is that I could simply add an optional read of
"symtable.o" into some arbitrary address from the .data segment, but that
fails when .data > ram doesn't "fit".

Clever alternatives welcome.

- -- kab

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: FAQ and ftp site info
Date: Thu, 5 Jan 1995 08:15:17 GMT
From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld)
Organization: Hollandse Signaal apparaten BV
Message-ID: <1995Jan5.081517.13934@hgl.signaal.nl>
References: <WILSON.95Jan4170932@ssdd475a.erim.org>
Sender: usenet@hgl.signaal.nl (USENET News System)

Paul Wilson (wilson@ssdd475a.erim.org) wrote:
: Is there an FAQ available for this group?  Where might I obtain it?
: Also, I have a requirement to produce a Sun readable TAR tape from 
: a vxworks application.  Is there a netware package to do that?

: 	Thanks in advance for assistance.

: 	regards,
: 		Paul Wilson
: 		wilson@erim.org

here some lines from the original vxworks FAQ :

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  

This FAQ was compiled by hjb@netcom.com using comments by readers of
comp.os.vxworks as well as his own limited knowledge of VxWorks.  Credits
appear at the end.  Comments and indications of doubt are enclosed in []s in
the text.  Each section begins with dashes ("-") on a line of their own,
then the section number.  This should make searching for a specific section
easy.

This FAQ is also available via anonymous ftp in:
        rtfm.mit.edu:/pub/usenet/news.answers/vxworks-faq.Z
        ftp.uu.net:/usenet/news.answers/vxworks-faq.Z 
        cs.toronto.edu:/pub/usenet/comp.answers/vxworks-faq.Z
        ftp.netcom.com:/pub/hjb/vxfaq.gz

- -- 
==============================================================================
= B.J.M. Vloedbeld    Dept:SDA-DID-DIM   Org:Hollandse Signaalapparaten B.V. =
= Adress : P.O.box 42 7550 GD Hengelo, The Netherlands                       =
= Phone :+31-74-483994 FAX:+31-74-484009  email:bjm_vloedbeld@hgl.signaal.nl =
=============================================================[Unclassified]===

---------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI floppy disk drive
Date: Thu, 5 Jan 1995 19:44:28 GMT
From: jch@netcom.com (Jack Hwang)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <jchD1y6u4.Gt9@netcom.com>

This is an old news.  Teac discontinue SCSI floppy disk drive FD235SJ.
But due to some bureautic clumsiness, the company I am working with
did not act on time to secure the supplies.  Now it all comes to me
to find alternatives.  Does anyone know there is a replacement available
which is compatiable with MVME147?  (Even 147 itself is discontinued!
DXXN!!!)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Stability
Date: 4 Jan 1995 19:50:52 GMT
From: prabhala@penafiel.irvine.dg.com (Venkata Prabhala)
Organization: Data General Corporation, Research Triangle Park, NC
Keywords: VxWorks
Message-ID: <3eeu6s$hcs@dg-irv.irvine.dg.com>

I am a new to RTOS's.  But I am certainly UNIX type!  I  have been wondering
if someone on this group could comment on the stability of VxWorks as a
development environment in a Unix host-based environment. How well does
VxWorks hold up to its promise of remote host-based development/debugging?
I  would like to hear both positive and negative comments to help my decision.
It would also help if someone could point out where I can obtain comparative
studies about different RTOSs like VxWorks, VRTX, QNX, pSOS, Solaris etc.

You may e-mail me if you think  it would increase the S/N ratio on the news
group.

Thanks.
- -- Venkat

- -- 

Venkata Prabhala, Data General Corporation	|  (prabhala@irvine.dg.com)   
2603 Main St., Ste. 360			 	|  FAX:   +1 714 724 3956
Irvine, CA 92714			 	|  VOICE: +1 714 724 3569

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: SCSI floppy disk drive
Date: Fri, 6 Jan 1995 14:04:38 GMT
From: clegg@ssd.fsi.com
Organization: Flightsafety International, Broken Arrow, OK
Message-ID: <1995Jan6.140438.24584@dev1.ssd.fsi.com>
References: <jchD1y6u4.Gt9@netcom.com>
Reply-To: clegg@ssd.fsi.com
Sender: news@dev1.ssd.fsi.com

In <jchD1y6u4.Gt9@netcom.com>, jch@netcom.com (Jack Hwang) writes:
>This is an old news.  Teac discontinue SCSI floppy disk drive FD235SJ.
>But due to some bureautic clumsiness, the company I am working with
>did not act on time to secure the supplies.  Now it all comes to me
>to find alternatives.  Does anyone know there is a replacement available
>which is compatiable with MVME147?  (Even 147 itself is discontinued!
>DXXN!!!)
>
I would appreciate a copy of any information you have concerning a
good alternative.  If possible, could you tell me what the media code
is for the suggested drive?
Thanks in advance,
Roger Clegg
clegg@ssd.fsi.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Fortran compiler & tools/ Vxworks on Alpha
Date: Fri, 6 Jan 1995 13:07:14
From: terra@tiac.net (Ophira Rosolio Aharonson)
Organization: Terra Computers Inc.
Keywords: Fortran, Programing tools,
Message-ID: <terra.114.000D1F3C@tiac.net>

Looking for info on suppliers of Fortran compilers for Vxworks on Alpha. 
Thanks 
Ophira Rosolio-Aharonson
Terra@Computers Inc.
terra tiac.net

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: DOS & large drive
Date: Fri, 6 Jan 1995 19:04:33 GMT
From: jfinley@netcom.com (John Finley)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <jfinleyD1zznL.Loz@netcom.com>
References: <9501061458.AA04567@positron.med.ge.com>

Mike Cook (cook@positron.med.ge.com) wrote:

: Anybody out there using large drives (> 4 gigabyte) with VxWorks DOS?

[snip]

: Question 1: 
: Is there anyway I can turn off the buffered I/O or reduce the buffer size?

: Ideally, I would like to be able to be able to open a dos file, seek to an 
: offset that is not cluster aligned and start reading/writing without having the 
: system read/write more than two additional disk sectors.

: Question 2:
: If the answer to Question 1 is NO (unless you have source code)....I don't.

: I'm tempted to try to read/write to the DOS contiguous files using Raw I/O.
: Would this be advisable? 

: Question 3:
: Is there a simple means to obtain the clustor number (or ideally the disk
: sector) for the start of a DOS contiguous file? (to aid my raw i/o if I choose
: to go that route)

: Question 4:
: Do you have any other suggestions as to how to improve the performance?

: Mike Cook
: GE Medical Systems
: cookm@med.ge.com
: (414) 548-4791

I've never used a >4GB drive, but I do have two-year-old dosFsLib
source.

Q1: Cluster buffering looks pretty central to everything. The only
time it's not used is when you open the entire disk as a 'raw volume'.
I don't think you can turn it off or make it other than the cluster
size.

Q2: This seems reasonable, however...

Q3: It's very simple in the source, but the necessary structure
typedef (DOS_FILE_DESC), which contains the number of the first
cluster in the file, is local to dosFsLib.c. Converting from cluster
number to sector number is a scale and offset. I guess I don't know
how you'd get the DOS_FILE_DESC* from the fd anyway, but that may be
easy. Someone with current source (WRS) could write a function to
get the sector offset of the start of a file pretty easily. If you
can get them to look at it. I think it'd be a terrific ioctl to add
to the library.

Q4: If you're only writing, be sure to open the file write-only. It
looks like this will avoid reading in the cluster where your write
ends (if not aligned). If you do this, then for both writes and
reads, the extra overhead of non-cluster-alignment looks to be
(a) bcopy of data to/from the cluster buffer for partial cluster at
beginning/end of read or write; and (b) extra overhead of more and
smaller calls to the SCSI driver to do the transfer.

Sorry I don't have a solution,
John Finley
jfinley@netcom.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Database on VxWorks
Date: Sat, 7 Jan 1995 09:08:34 GMT
From: aisic@actcom.co.il (Ilan aisic)
Organization: ACTCOM - Internet Services in Israel
Message-ID: <D212qA.FHK@actcom.co.il>
Sender: news@wang.com

Does anyone know if there's a commercial or non-commercial
database that is available on VxWorks?
- --ilan

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Changing file times.
Date: Wed, 4 Jan 1995 00:14:57 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Message-ID: <georg.789178497@sgl.ists.ca>
References: <1994Dec20.152127.9206@picker.com> <froeber.787946114@labs-n.bbn.com>
Sender: news@newshub.ists.ca

froeber@bbn.com (Fred Roeber) writes:
>heller@nm.picker.com (Mark Heller) writes:
>>	I'm running VxWorks 5.1.1 and looking for a way to change
>>	the dates on files on a Dos filesystem.
>See the function dosFsTimeSet in VxWorks.   Fred

Just a comment on using dosFsTimeSet() ... this would have to be done in
somewhat of a kludgy fashion, e.g. you would "back date" the dosFs time using
dosFsTimeSet(), then do a dummy modify of the file, then return the dosFs
time to normal. This requires that no other dosFs modify activity takes place,
or other files may get erroneous times. Also it won't work if you've used
dosFsDateTimeInstall().

An alternate way is to modify the in-memory DOS_DIR_ENT dosde_time and
dosde_date fields, then set dosde_modified and flush the file.
Ideally you would need to take certain VxWorks system semaphores while you do
this to be safe (I could give more info if needed).

Georg.
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: Looking For A File Transfer Protocol
Date: 7 Jan 1995 17:32:21 -0800
From: randyr@treehouse.org (Randy Riggins)
Organization: The Treehouse
Message-ID: <3enfb5$86@treehouse.org>

I don't know much about FTP but, Wind River's FTP documentation states that it copies the entire file into local memory before performing the transfer. Thus restricting the size of the largest file that can be transferred to the amount of the available local memory.

I need a means of transferring 1M to 2G byte files between VxWorks targets. 
Using NFS to provide transparent file access is not an option. 

Does any know of a different VxWorks based file transfer protocol that streams the data between the disk and the network? Are there other versions of FTP available?

Thanks, Randy Riggins

---------------------------

Newsgroups: comp.os.vxworks
Subject: Looking for new VxWorks File System
Date: 9 Jan 95 10:35:48 EST
From: tpd@icf.hrb.com (THOMAS P. DONNELLY)
Organization: HRB Systems, Inc.
Message-ID: <1995Jan9.103548.22647@hrbicf>

Does anyone know of a third party that provides a VxWorks file system
besides DOS and RT11?

We have all sorts of problems with the buggy DOS F.S. and RT11 hasn't
the flexibility of subdirectories.  One that can handle large disks
(greater than 1 gig) would be ideal.

Thanks in advance

	Tom

---------------------------

Newsgroups: comp.os.vxworks
Subject: Can't ftp thor.atd.ucar.edu
Date: 9 Jan 1995 18:09:33 GMT
From: bonaker@amasd.anatcp.rockwell.com (Joe Bonaker)
Organization: Rockwell
Message-ID: <3eru4t$to@huron.eel.ufl.edu>
Reply-To: bonaker@amasd.anatcp.rockwell.com

I can no longer anonymously ftp(8) into the VxWorks archive site.  Has
this service been discontinued or superceded by the E-mail queries?

    % ftp thor.atd.ucar.edu
    Connected to thor.atd.ucar.edu.
    421 Service not available, remote server has closed connection
    ftp> 

Thanks,

Joe B.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Can't ftp thor.atd.ucar.edu
Date: 9 Jan 1995 19:13:07 GMT
From: vanandel@stout.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <3es1s3$766@ncar.ucar.edu>
References: <3eru4t$to@huron.eel.ufl.edu>
Sender: vanandel@canoe (Joe Van Andel)

The VxWorks archive has been moved to
ftp://ftp.atd.ucar.edu/pub/vxworks

- -- 
	Joe VanAndel  		    Internet: vanandel@ncar.ucar.edu
	National Center for 	    Web http://www.atd.ucar.edu/jva/home.html
	Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: Fortran Compiler for Alpha/VXworks
Date: Mon, 9 Jan 1995 17:24:01
From: terra@tiac.net (Ophira Rosolio Aharonson)
Organization: Terra Computers Inc.
Message-ID: <terra.129.001166F9@tiac.net>

Needed: info availability of Fortran compiler and tools for Alpha VXworks. 
Thanks
Ophira Rosolio-Aharonson
Terra@Computers Inc.
terra tiac.net

---------------------------

Newsgroups: comp.os.vxworks
Subject: Cartridge Tape Driver
Date: Thu, 5 Jan 95 09:24:29 GMT
From: TaeKyung Chung <tkchung@shi_dd3.shi3.samsung.co.kr>
Organization: SNU,KOREA
Message-ID: <1995Jan5.092429.1479@news.snu.ac.kr>
Sender: usenet@news.snu.ac.kr (NEWS POSTER)

I want to receive about how to install Cartridge Tape Driver 
in VxWorks.
If anyone know about that, mail or posting in this newsgroup.
Help me....
And, I want to know that "Backup Device in VxWorks using any device"

Thanks you......

=================
My Email Address : g1khahn@super.samsung.co.kr
                   tkchung@jurasic.shi3.samsung.co.kr
                     ===================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: smObjLocalToGlobal() Question 
Date: Thu, 5 Jan 95 09:45:00 GMT
From: TaeKyung Chung <tkchung@shi_dd3.shi3.samsung.co.kr>
Organization: SNU,KOREA
Message-ID: <1995Jan5.094500.1684@news.snu.ac.kr>
Sender: usenet@news.snu.ac.kr (NEWS POSTER)

Hello....
Happy New year !!!!

I use 2 CPU Card (MVME167) and VxWorks O/S...
For Example,
One MVME167 use this routine

  int START

  smNameAdd(START,smObjLocalToGlobal( int A ),T_SM_BLOCK)

Another MVME167 use routine

  int *StartFlag=0
  int START_SEM

  if (smNameFind(START_SEM,&StartFlag,&type,NO_WAIT) == OK)
      	StartFlag= (int *)smObjectGlobalToLocal(StartFlag);

In this case, I want to set *StartFlag is 1, and then I want to pass 
StartFlag value using smObjLocalToGlobal Function.

But, The value StartFlag is not changed when another MVME167 acess
StartFlag value.

Help me....

How to change StartFlag value......?
and then another Function call without using smObjLocalToGlobal().

anyway....
I want to change Global parameter....
and then any MVM167 will read changed same value.....

please....
help me......

================
My Email Address : g1khahn@super.samsung.co.kr
		   tkchung@jurasic.shi3.samsung.co.kr
		=======================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Email address Wind River Systems, Visicom
Date: 10 Jan 95 10:49:34 GMT
From: wouters@ict.nl (Rick Wouters)
Organization: ICT Automatisering Deventer B.V.
Keywords: Motif, VxWorks, GUI, X
Message-ID: <2088@ictser.UUCP>
Reply-To: wouters@ict.nl
Sender: news@ictser.UUCP

Could someone send me email addresses of the above mentioned
companies ?

Because I'm looking for information about Motif GUI builders and/or
toolkits for VxWorks, any suggestions and experience related to this 
topic would be welcome, too.

Thanks in advance.

Rick.

- ------------------------------------------------------------------------
Rick Wouters                            ICT Automatisering Deventer B.V.
e-mail:         wouters@ict.nl          P.O. Box 701
Telephone:      +31-(0)5700-33888       7400 AS  Deventer
Fax:            +31-(0)5700-21362       The Netherlands
- ------------------------------------------------------------------------

---------------------------

End of New-News digest
**********************

From gphillips@se01.wg2.waii.com  Tue Jan 10 04:55:11 1995
From: "Gary L. Phillips" <gphillips@se01.wg2.waii.com>
Date: Tue Jan 10 04:55:18 PST 1995
Subject: UNSUBSCRIBE
UNSUBSCRIBE

From randy@opid330.litton.com  Tue Jan 10 08:54:54 1995
From: randy@opid330.litton.com (randy)
Date: Tue Jan 10 08:55:01 PST 1995
Subject: Flash EEPROM Packs
Anybody have a source of Flash EEPROM packs that might attach to a
MVME147 and MVME167 card?

Tanx
*****************************************
*                                       *
*  Randy Ryan                           *
*  Litton Data Systems                  *
*                                       *
*  Email: randy@opid330.dsd.litton.com  *
*  (Note:  Return Address on header is  *
*  incorrect)                           *
*                                       *
*****************************************

From ddavies@xmission.com  Tue Jan 10 22:05:52 1995
From: Doug Davies <ddavies@xmission.com>
Date: Tue Jan 10 22:06:00 PST 1995
Subject: Re: Programming FLASH on the MV162
> Submitted-by: del@rst.com (Mark Del Giorno)
>  
> I'm looking for some source code that can burn FLASH on a MVME162
> (it uses the Intel 28F020).  My ultimate goal is to be able to burn
> my application into FLASH and run on power up (embedded - with no
> ethernet attached).  Wind River has a way that I can download a hex
> file via a serial link - this is o.k., but I can't believe I can't
> accomplish the same thing via the ethernet connection.  When I asked
> them for code to burn the FLASH, I got the following response:

I have burned several boot ROMs over the ethernet on both the mv162
and the mv166 (both of which have on-board flash).  This is done by
booting the board with the Motorola bug ROM, and using its facilities
to burn the flash.

As I recall, the procedure for the mv162 is something like this:

1) Compile your application and convert the 'hex' output (Motorola S
   record) to a binary format.

2) Remove jumper GPI3 (pins 9 & 10 of J22 jumper header) on the mv162.
   (Caveat, I haven't done this for a while and in the back of my mind
   I remember something about this jumper location not being correct
   for either the mv162 or the mv166 .  <grin>  You may want to consult
   the mv162 documentation, what you want is the board to boot up using
   the Motorola bug ROM).

3) Power up the mv162, also insure that the Ethernet port on the mv162
   is connected to the network.

4) After the '162-BBug>' prompt, type (or verify the following:

   162-BBug>niot
   Controller LUN = 00?
   Device LUN     = 00?
   Node Control Memory Address = FFE10000?
   Client IP Address = 0.0.0.0? <input INET # of mv162 board here>
   Server IP Address = 0.0.0.0? <input INET # of host here>
   Subnet IP Address Mask = 255.255.255.255?
   Broadcast IP Address = 0.0.0.0?
   BOOTP/RARP Request Retry = 00?
   TFTP/ARP Request Retry = 00?

   162-BBug>niop
   Controller LUN = 00?
   Device LUN     = 00?
   Get/Put        = G?
   File Name      = ? <input name of binary file here>
   Memory Address = 0000E000? <input address on mv162 here, see note below>
   Length         = 00000000?
   Byte Offset    = 00000000?

   Note that the input address on the mv162 entered above is the location
   that the binary file will be loaded into.  At this point you should see
   some status indicating that the file loaded successfully.  If you get
   an error statups of 0400, this indicates that the RTC clock is not
   running.  To fix this error, use the 'set' command to set the date &
   time and get the RTC clock running, ie:

      162-BBug>set 0929941405

      The format is MMDDYYHHMM.  After running the 'set' command repeat
      the 'niop' command and then continue.

5) Now copy the binary file from RAM into the flash:

   162-BBug>pflash <RAM address>:20000 ffa00000

   <Various information displayed here>

   Program FLASH Memory (Y/N)? y

   Note that at this point you should get status about the progress
   of the command.  This will take several minutes to complete.  The
   syntax of the pflash command is:

      pflash <binary file RAM addr>:<file length> <flash destination addr>

6) Re-install jumper GPI3 (pins 9 & 10 of J22 jumper header) on the
   mv162 and power up.

Hope this helps (and that it works...  <grin>)

-Douglas Davies (ddavies@xmission.com)

From daemon@vxw.ee.lbl.gov  Wed Jan 11 04:00:27 1995
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 11 04:00:34 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 11 04:00:17 PST 1995

        Subject: VxWorks drivers for Sbus FDDI cards
        Subject: VME to Sbus adaptors
        Subject: sysStartType

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks drivers for Sbus FDDI cards
Date: 10 Jan 1995 22:00:59 GMT
From: mcdono@atcwest.com (Tim McDonough)
Organization: Alliant Techsystems
Message-ID: <3ev02r$3or@news.cerf.net>
Reply-To: mcdono@atcwest.com

I've found numerous Single Attached FDDI Single Slot SBUS cards for our
SPARC host but no drivers. Anyone know where I can find a driver for
VxWorks 5.1 and such a card?

				Thanks

- ---
Tim McDonough                   |   The opinions voiced are my own and
Alliant Techsystems             |   do not reflect those of my employer
mcdono@atcwest.com              |   or the Susquehanna Hat Company.

---------------------------

Newsgroups: comp.os.vxworks
Subject: VME to Sbus adaptors
Date: 10 Jan 1995 18:03:25 -0700
From: spitcher@oz.sim.es.com (Stanford Pitcher)
Organization: A poorly-installed InterNetNews site
Keywords: VMEbus SBus
Message-ID: <3evaot$8nr@oz.sim.es.com>

Hello,

Our application requires a 'hard' real-time link between a SPARCstation
running Solaris 2.3 and a MVME-162 card running vxWorks. We need to keep 
the two applications (one on each system -  cycling at rates up to 
50 Hz) in sync with other.  We hoped to use TCP/IP sockets but are
experiencing frequent glitches where the Sun's app does not respond for 
several frames (sometimes as many as 30).  We are assuming that although
we are running the Sun's app at real-time priority level, the net task
(which runs at some level we can't change) is being bumped which causes
the glitch. Another guess is that occasionally the net task hiccups
for some reason.  Anybody know???

Anyway, if we can't get sockets to work.  We'll probably try a bus
adaptor between the SBus and the VMEbus.  The one we are considering is
made by Bit 3.  They have two models: with and without DMA.  They supply 
some 'utility' code in FORTH or you can buy their 'support software' which 
includes a device driver, read/write/lseek, interrupt handlers, etc.  
They don't mention what its coded in.  

Finally, my questions:

1) Does anyone have any opinions/experiences on bus adapters in general
   and 3 Bits products (including their software) in particular?

2) Does anyone have any ideas on how we might improve our ethernet
   performance?

Thanks alot,

Stan 

spitcher@sim.es.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: sysStartType
Date: Wed, 11 Jan 1995 08:46:04 GMT
From: rsgawera@wg.icl.co.uk (Raj Gawera)
Organization: International Computers Limited
Message-ID: <D28GCt.AsE@oasis.icl.co.uk>
Reply-To: rsgawera@wg.icl.co.uk
Sender: news@oasis.icl.co.uk

Dear VxWorkers,
	I am having trouble with interrogating sysStartType in usrInit().
It always seems to be 0 ie warm start, even if I power off-on the board. Anyone
know any tricks that have to be done to use the sysStartType variable ? I am 
using a Radstone ENET 1 board with v5.1 vxWorks.

	cheers,
		Raj

Raj Gawera
rsgawera@wg.icl.co.uk

---------------------------

End of New-News digest
**********************

From @lazarus.nrtc.northrop.com:lam@csd.nad.northrop.com  Wed Jan 11 09:49:32 1995
From: Christine Lam <lam@csd.nad.northrop.com>
Date: Wed Jan 11 09:49:39 PST 1995
Subject: Re: Thanks

Thanks to whoever replied to my email regarding
socket recvfrom time out problem.

Christine Lam

From randy@opid330.litton.com  Wed Jan 11 15:39:04 1995
From: randy@opid330.litton.com (randy)
Date: Wed Jan 11 15:39:10 PST 1995
Subject: Compile options
Does anybody know what the convention(s) are for levels of optimization
with driver code.

I was attempting to do level 2 optimization.  The problem is, for the
register locations that are strobed, multiple strobes to that address
appear to be getting cut out of compiled code.  Perhaps because the
compiler sees that I'm writing the same value to an address?

This is with the GNU C compiler supplied with VxWorks 5.1.

Tanx
*****************************************
*                                       *
*  Randy Ryan                           *
*  Litton Data Systems                  *
*                                       *
*  Email: randy@opid330.dsd.litton.com  *
*  (Note:  Return Address on header is  *
*  incorrect [not under my control      *
*  either!)                             *
*                                       *
*****************************************

From stevem@syd.csa.com.au  Wed Jan 11 16:56:34 1995
From: stevem@syd.csa.com.au (Steven McCoy)
Date: Wed Jan 11 16:56:41 PST 1995
Subject: Re: Bus Error with 32MByte MVME167
Re:

> Our Ada application executes without a problem on a MVME167-B 
> (25 MHz, 16 MBytes) and a MVME167-33A (33 MHz, 16 MBytes). A recent
> upgrade to the MVME167-34A (33 MHz, 32 MBytes) has suddenly
> caused the same code to generate a Bus error or at times an Illegal 
> Instruction. This always occurs when executing i() or checkStack()
> commands from the shell. Note that we do not have a problem with
> the pi() command.
> 
> e.g.
> 
> Bus Error
> Program Counter: 0x00000008
> Status Register: 0x3000
> Access Address : 0x08eb7376 <-- Way out of range.
> Special Status : 0x0125
> 
> shell restarted.
> 
> or
> 
> Illegal Instruction
> Program Counter: 0x00000012
> Status Register: 0x3008
> 
> shell restarted.

Thanks for all the replies regarding this problem. It turns out 
that our problem was caused by an Ada task entry that was too long. 
The task IFF_SERVICE_RECEIVED_POINT_TO_POINT_MESSAGES_TASK_TYPE in 
the Ada package IFF_SERVICE_RECEIVED_POINT_TO_POINT_MESSAGES will 
have the following name and entry in the VxWorks symbol table,

adaT28  _A_iff_service_received_point_to_point_messages_task_type.iff_service_received_point_to_point_messages

The entry length here is 100 characters excluding the _A prefix. This 
task works fine on a 16 MByte board but causes problems on a 32 MByte
board. The limit appears to be 99 characters when using 32 MBytes. I'm   
not sure why this is the case. An extra byte appears to be required   
for something else. Someone may want to shed some light here.

The i(), and checkStack() commands impose name limits, 
"char name[MAX_SYS_SYM_LEN + 1]", where MAX_SYS_SYM_LEN = 100
from sysSymTbl.h. The Ada tasks are automatically assigned the 
names adaT1, adaT2, ... The MAX_SYS_SYM_LEN also applies for
the entry point in the symbol table where our problem lay.

Steven McCoy
CSC Australia
A Unit of Computer Sciences Corporation
stevem@assip.csasyd.oz.au

From elliotts@stanilite.com.au  Wed Jan 11 17:51:36 1995
From: elliotts@stanilite.com.au (Stephen Elliott - ENG - TEMP)
Date: Wed Jan 11 17:51:43 PST 1995
Subject: Re: Compile options
randy@opid330.litton.com (randy) wrote:
>  
> ...
> I was attempting to do level 2 optimization.  The problem is, for the
> register locations that are strobed, multiple strobes to that address
> appear to be getting cut out of compiled code.  Perhaps because the
> compiler sees that I'm writing the same value to an address?
> ...
You should be using "volatile" on the strobed regiser variables.

-- 
Steve Elliott - Stanilite Electronics, 424, Lane Cove Rd, NSW 2113, Australia
        Voice : +61 2 325 1667
          Fax : +61 2 325 1799
        eMail : elliotts@stanilite.com.au
 

From stan@lassen.rti.com  Wed Jan 11 22:25:53 1995
From: stan@lassen.rti.com (Stan Schneider)
Date: Wed Jan 11 22:26:00 PST 1995
Subject: Re: Compile options
>> Submitted-by randy@opid330.litton.com  Wed Jan 11 15:39:04 1995

>> Does anybody know what the convention(s) are for levels of optimization
>> with driver code.
>> 
>> I was attempting to do level 2 optimization.  The problem is, for the
>> register locations that are strobed, multiple strobes to that address
>> appear to be getting cut out of compiled code.  Perhaps because the
>> compiler sees that I'm writing the same value to an address?
>> 
>> This is with the GNU C compiler supplied with VxWorks 5.1.
>> 

gcc will (almost?) always optimize "unnecessary" memory accesses, unless the
variable is declared "volatile", regardless of optimization level.  This is in
compliance with the ANSI spec.  So, adding "volatile" to your hardware register
definitions is the right way to fix this (IMHO).  Gcc also has a HACK called
the "-volatile" flag that makes everything act as if it were declared
volatile.  It's good for testing to see if the optimizer has bitten you, but
should otherwise be avoided, as it really messes up the compiler's
performance.

HTH,

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From sergi@hpbpq11.bpo.hp.com  Thu Jan 12 00:36:01 1995
From: Sergi Casas(QA Software testing) <sergi@hpbpq11.bpo.hp.com>
Date: Thu Jan 12 00:37:47 PST 1995
Subject: Re: Compile options
> 
> Submitted-by randy@opid330.litton.com  Wed Jan 11 15:39:04 1995
> Submitted-by: randy@opid330.litton.com (randy)
>  
> Does anybody know what the convention(s) are for levels of optimization
> with driver code.
> 
> I was attempting to do level 2 optimization.  The problem is, for the
> register locations that are strobed, multiple strobes to that address
> appear to be getting cut out of compiled code.  Perhaps because the
> compiler sees that I'm writing the same value to an address?
> 
> This is with the GNU C compiler supplied with VxWorks 5.1.
> 
> Tanx
> *****************************************
> *                                       *
> *  Randy Ryan                           *

	I think your problem is actually caused by the optimization process,
but you can solve it easily by using the keyword "volatile" when declaring
the pointers to those hardware registers that you'd like to make sure are
accessed as many times as your C program refers to them.

Example:

	volatile char *ParallelControlReg;

	...

	{
	   ParallelControlReg |= STROBE;
           ParallelControlReg |= STROBE;
           ParallelControlReg &= ~STROBE;
	...
	}

Hope this helps.

-- 

|============================================================================|
| Sergi Casas                #####  /  ##### Firmware Engineer               |
| Hewlett-Packard Company    ###   /_  _ ###                                 |
| Barcelona Division (BCD)   ##   / / / / ## e-mail: sergi@hp-bpo.bpo.hp.com |
| Avda. Graells, 501         ##  / / /_/  ## Phone : +34 3 582 1475          |
| 08190 S. Cugat (Barcelona) ###    /    ### Fax   : +34 3 582 2515          |
| SPAIN                      ##### /   ##### HP-Telnet:    712 1475          |
|============================================================================|

From daemon@vxw.ee.lbl.gov  Thu Jan 12 04:00:27 1995
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 12 04:00:36 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 12 04:00:17 PST 1995

        Subject: sysStartType and sysInit()
        Subject: Final Call For Papers: SIGPLAN Workshop on LCTRTS
        Subject: problem with time()
        Subject: Re: problem with time()

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: sysStartType and sysInit()
Date: Wed, 11 Jan 1995 13:24:17 GMT
From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera)
Organization: International Computers Limited
Message-ID: <D28t8I.7tD@oasis.icl.co.uk>
Reply-To: rsgawera@ss11.wg.icl.co.uk
Sender: news@oasis.icl.co.uk

Dear VxWorkers,
	After a bit of digging around and following the vxWorks boot
sequence, I came across the sysInit routine in sysALib.s. This routine gets called
after decompression from romStart() and is the entry point for the decompressed
vxWorks. the call to sysInit has the startType as a parameter but the sysinit routine
does not look at this parameter, it simply calls usrInit() with a parameter of BOOT_WARM_AUTOBOOT (which is 0).  It is this value which is then stored in sysStartType so every boot looks like a warm boot.
   I altered sysInit() to look at the parameter it was passed on the stack and forward
it to usrInit() so sysInit now looks like :

_sysInit:
        movew   #0x3700,sr               /* temporarily, for the debug stage */
        movel   a7@(0x4),d7              /* put startType in d7 */
        movel	#_sysInit,a7	 /* set stack to grow down from code */
        movel	d7,a7@-                  /* push start type from d7 */
        jsr	_usrInit	 /* never returns - starts up kernel */
This works and sysStartType now reflects the reboot type. The question is, is the 
original sysInit routine bugged, or was it designed to make every boot look like a
warm boot ? I know sysALib.s is part of the BSP but I've checked two 680x0 BSPs and 
their both identical.  Can anyone with SPARC/other BSPs shed any light on their sysInit() routines.
This is all on a 680x0 based ENET 1 with v5.1 standalone vxWorks.

		cheers,
			Raj

Raj Gawera
rsgawera@wg.icl.co.uk

---------------------------

Newsgroups: comp.os.vxworks
Subject: Final Call For Papers: SIGPLAN Workshop on LCTRTS
Date: 11 Jan 1995 14:24:59 -0500
From: sshong@cs.umd.edu (Seongsoo Hong)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Message-ID: <3f1bab$keb@bird.cs.umd.edu>

			       CALL FOR PAPERS
			   ACM SIGPLAN Workshop on
	    Languages, Compilers and Tools for Real-Time Systems
		 (In Conjunction with ACM SIGPLAN PLDI/PEPM)
			    La Jolla, California
			      June 21-22, 1995
				      

ACM SIGPLAN LCT-RTS '95 is an interface between two dynamic fields of computer
science and engineering: programming languages and real-time systems. The 
time is right for this workshop:  top researchers in these areas are
addressing many similar problems, but with slightly different perspectives
and technologies.  LCT-RTS provides a forum where these researchers can share
their results and directions, and where they can potentially form new
collaborations based on common interests.

MOTIVATION: Until recently real-time systems development was the province 
of experienced specialists, who were faced with a variety of custom
kernels, non-standard languages and vendor-specific device interfaces.
System integration inevitably involved a complicated process of taking 
timing measurements, hand-tuning the code, and then re-measuring.
  These ad-hoc techniques have not scaled to support modern systems. 
There is a growing desire to adopt advanced design strategies, standard 
kernels, reusable modules, generic languages and the like.  Also, the 
majority of real-time developers is longer drawn from the ranks of 
embedded controls experts; rather, it is composed of animators, 
physicists, video producers, musicians, medical technicians, 
automotive engineers, manufacturing engineers, etc.  New software 
approaches are needed to support these new systems, and this new 
generation of real-time programmers.

THE WORKSHOP: ACM SIGPLAN LCT-RTS '95 is devoted to investigating 
software technologies for contemporary real-time systems.  
Original submissions are invited in all areas relevant to this 
theme, including (but not restricted to) the following topics:

  *  Programming Languages for Real-Time: Industrial and Research 
  *  Design: Requirements, System Specification, Analysis
  *  Exception Handling: Semantics, Policies, Mechanisms 
  *  Prototyping Languages 
  *  Timing Analysis: Static and Dynamic Approaches
  *  Scheduling Analysis  
  *  Realtime on RISC: Caches, Register Windows, Pipelines  
  *  Realtime Memory Management and Garbage Collection   
  *  Support for Parallelism and Data Placement
  *  Program Transformation and Optimization for Real-Time Performance
  *  Profiling, Measurement and Debugging 
  *  System Integration and Testing

Of particular interest are case studies, or experimental results based 
on application-building experiences; for example in interactive graphics,
imaging, manufacturing, etc.

Papers should report new research, and should not exceed 5000 words
(approximately 10 pages typeset 10-point on 16-point spacing, or 15
typewritten double-spaced pages).  Short papers are also welcomed, which
describe existing implementations, work-in-progress, or new problems 
and important issues.  Short papers should not exceed 3000 words (6 pages).  
All accepted papers will be presented at the workshop and published in 
the proceedings, which will be distributed at the workshop.

SUBMISSION:  Please submit seven (7) copies of papers, to: 

    ACM SIGPLAN LCT-RTS
    Attn: Richard Gerber 
    Department of Computer Science 
    University of Maryland 
    College Park, MD 20742 USA

Papers will be reviewed the program committee for appropriateness of 
content and presentation.  Proceedings will be distributed at the 
workshop.

IMPORTANT DATES

Submission of draft paper:   23 January 1995
Notification of acceptance:  22 March 1995
Final version due:           15 May 1995

PROGRAM COMMITTEE

Alan Burns (University of York)           
Richard Gerber, Co-Chair (University of Maryland)
Rajiv Gupta (Univ of Pittsburgh)
Mary Hall (Caltech)                 
Connie Heitmeyer (Naval Research Lab)
Insup Lee (University of Pennsylvania)    
Al Mok (University of Texas at Austin)
Thomas Marlowe, Co-Chair (Seton Hall University, NJIT RTCL)
Steve Tjiang (Synopsys Inc.)        
                                      
PROGRAM CO-CHAIRS  

Richard Gerber                           Thomas Marlowe 
Department of Computer Science           Department of Mathematics 
University of Maryland                   Seton Hall University 
College Park, MD  20742, USA             South Orange NJ 07079, USA
telephone: +1 301 405 2710               telephone: +1 201 761 9784     
fax: +1 301 405 6707                     fax: +1 201 761 9596
rich@cs.umd.edu                          marlowe@cs.rutgers.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: problem with time()
Date: 11 Jan 1995 20:20:20 GMT
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <3f1ei4$17n@grover.jpl.nasa.gov>

On any unix machine, time() provides the number of seconds since 1970.
On VxWorks time() provides the number of seconds since the first
time() call after reboot (at least on 5.1.1).  Anyone know of a way to
way to set the # of seconds so I can get time() to work properly?

Matt

- -- 
matthew.r.wette@jpl.nasa.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: problem with time()
Date: 11 Jan 1995 21:14:23 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.95Jan11161423@oats.frc.ri.cmu.edu>
References: <3f1ei4$17n@grover.jpl.nasa.gov>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

In article <3f1ei4$17n@grover.jpl.nasa.gov> mwette@mr-ed.jpl.nasa.gov (Matt Wette) writes:

> On any unix machine, time() provides the number of seconds since 1970.
> On VxWorks time() provides the number of seconds since the first
> time() call after reboot (at least on 5.1.1).  Anyone know of a way to
> way to set the # of seconds so I can get time() to work properly?
> 
> Matt
> 

If your target board has a time-of-day/calendar chip (such as the
MK48T02 or similar), you can write your own version of time() that
accesses this chip. I've done this successfully before by including
the code in usrConfig.c. I'm not certain right now, but you may have
to remove the original time() from the vxWorks library. 

Without such a chip, I'm guessing the only way to get actual time is
via the net, e.g. NTP or something like that, or through external
hardware (like a digitizer and camera looking at a wristwatch :-)

- -Henning
- --
Henning Pangels           |   hmp@cs.cmu.edu     |     Field Robotics Center
Senior Research Programmer|   (412) 268-8911     |Carnegie-Mellon University
- ----------------------------------------------------------------------------
        I am a .signature virus.  Copy me into your .signature today!

---------------------------

End of New-News digest
**********************

From leonid@rst.co.il  Thu Jan 12 06:41:50 1995
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Thu Jan 12 06:41:56 PST 1995
Subject: Re: problem with time()
The basic VxWorks package lacks the knowledge of absolute time,
i.e. it only can start from the time it booted last. What you can do,
is get the absolute time from somewhere else, and use the function
clock_settime() to set the time once, then you can call time() 
or clock_gettime() to get the current time. This is practically
sufficient for most purposes. In some rare cases you may want
to fiddle with clcok_setres() to change the presumed sysClk frequency
in order for your target time() to be in sync with an external
time reference.

There are basically three ways to get the absolute time at initialization
time, and optionaly synchronize with later on:

1. The chapest is the battery-backed Reat Time Clock on your board
(Mot use MK48T0x, others the 7170)
2. Use the "rdate" protocol to get the time from your closest
Unix station on the network. Take the Unix "rdate" program source
and port it to VxWorks (really easy stuff).
3. There is a wide range of time reference devices that can be
hooked up via a serial link, their price ranges widely, so is their
accuracy.

If your target LAN is somehow hooked up into the Internet, that's your
cheapest source for accurate time.

My experience with NTP is not so good, these protocols average
clocks of network stations, in my experience all SUNs are inaccurate.
And NTP wastes an unnecesarily large amount of BW and CPU. That is
unless you need a millisecond time synchronization ...

I hope this clears things a bit.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
R S T  Software Industries Ltd.         Fax:   +972-3-559-8244
3 Hashikma st. Industrial Zone,         E-Mail: leonid@rst.co.il
P.O.Box 11502, AZUR 58017, Israel       WindRiver Distributor

From leif@tsl.uu.se  Thu Jan 12 07:32:37 1995
From: leif@tsl.uu.se
Date: Thu Jan 12 07:32:43 PST 1995
Subject: Driver for GreenSpring IP-Stepper
Does anyone have a VxWorks driver or interface routines for the
GreenSpring IP-Stepper that they would like to share...

leif
-------------------------------------------------------------------------------
Leif Thuresson, The Svedberg Laboratory, Uppsala University, Sweden
leif@tsl.uu.se

From hebo@mbari.org  Thu Jan 12 08:34:24 1995
From: Bob Herlien <hebo@mbari.org>
Date: Thu Jan 12 08:34:32 PST 1995
Subject: Re: problems with time()

> On any unix machine, time() provides the number of seconds since 1970.
> On VxWorks time() provides the number of seconds since the first
> time() call after reboot (at least on 5.1.1).  Anyone know of a way to
> way to set the # of seconds so I can get time() to work properly?
> 
> Matt

Get the usrTime library from the VxWorks archive.  It implements time(),
gettimeofday(), settimeofday(), etc, in a Unix-compatible fashion.
It includes code for the MK48T08 real-time clock chip, as implemented
on the MVME-162 CPU board.  If you use some other clock chip or CPU,
you'll need to modify this code, but it should be very straightforward.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org

From hebo@mbari.org  Thu Jan 12 08:47:58 1995
From: Bob Herlien <hebo@mbari.org>
Date: Thu Jan 12 08:48:04 PST 1995
Subject: Re: problem with time()
I sent my earlier response to this question before reading Leonid's
response below.  Although I usually agree with Leonid's advice, I couldn't
let this pass without comment.

> My experience with NTP is not so good, these protocols average
> clocks of network stations, in my experience all SUNs are inaccurate.
> And NTP wastes an unnecesarily large amount of BW and CPU. That is
> unless you need a millisecond time synchronization ...

Granted, the original requestor just wanted a working time() function,
so NTP is overkill.  In fact, the only part of the NTP port for VxWorks
that he needs is usrTime, which is much simpler to configure than NTP itself.

But I disagree with your comments.  Suns have had, indeed, a checkered
history with regard to accurate time; mostly, I understand (I don't use
them myself) due to dropping clock interrupts.  I believe that these
problems have been solved.  In the early days of NTP, Suns required
particular tweaking.

But I'm constantly amazed that NTP is able to keep such accurate time
while using such miniscule system resources, particularly net and CPU
bandwidth.  In steady state, it sends messages to your peers once every
16 minutes.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org

From mea@mclean.sparta.com  Thu Jan 12 10:57:15 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 12 10:57:21 PST 1995
Subject: IP Multicast
Greetings!

  This has been asked before, but we'll try again since I haven't seen any
responses.  Has anyone implemented (or are in the process of implementing)
IP Multicast under VxWorks?  It doen't have to be free (although that would 
be nice ;-).  

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From guthrie@power.amasd.anatcp.rockwell.com  Thu Jan 12 12:06:47 1995
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Thu Jan 12 12:06:54 PST 1995
Subject: IP Multicast
To all:

        Mike Anderson writes the following:

> Submitted-by mea@mclean.sparta.com  Thu Jan 12 10:57:15 1995
> Submitted-by: mea@mclean.sparta.com (Mike Anderson)
>  
> Greetings!
> 
>   This has been asked before, but we'll try again since I haven't seen any
> responses.  Has anyone implemented (or are in the process of implementing)
> IP Multicast under VxWorks?  It doen't have to be free (although that would 
> be nice ;-).  
> 
> Regards,

I would also be interested in responses to this question.

        Robert Guthrie
        email: guthrie@power.amasd.anatcp.rockwell.com

From wgsu12!rmarplcd@kns.com  Thu Jan 12 13:58:35 1995
From: wgsu12!rmarplcd@kns.com (Russell Marple)
Date: Thu Jan 12 13:58:42 PST 1995
Subject: 3rd party C++ class libraries
Greetings,

I'm looking into using the WindC++ Gateway. I'd like to hear from anyone 
which has used any 3rd party class libraries with VxWorks (ex. Rogue Wave's
libraries tools.h++ or views.h++). Any comments on what worked (or didn't) 
would be appreciated.

I'm using:
	VxWorks 5.1.1
	MVME147 target

Regards,

Russ

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+       Russ Marple                             e-mail: marple@kns.com
+       Kulicke and Soffa Industries, Inc.      voice:  215-784-6232
+       2101 Blair Mill Road                    fax:    215-659-7588
+       Willow Grove, PA  19090
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From sidney@alfred.ca.boeing.com  Thu Jan 12 15:28:25 1995
From: sidney@alfred.ca.boeing.com
Date: Thu Jan 12 15:28:31 PST 1995
Subject: GE FANUC DNC2 Communication Protocol Implementation

Has anyone implemented the FANUC DNC2 communication protocol on VxWorks or
on any Unix machine ?

Sidney

***************************************************
* email:     sidney@alfred.ca.boeing.com          *
* voice:     (206)931-2140                        *
* usSnail:   P.O. Box 3707 M/S 5K-14              *
*            Seattle, Wa 98124                    *
*                                                 *
*Disclaimer: The contents of this message in no   *
*            way reflects the Opinions either real*
*            or imaginary of the Boeing Company.  *
*            All Opinions/rantings are my own and * 
*            only I am responsible for them.      *
***************************************************

From vogel@fz.telekom.de  Fri Jan 13 05:08:37 1995
From: vogel@fz.telekom.de (Veit Vogel)
Date: Fri Jan 13 05:08:44 PST 1995
Subject: 3rd party C++ class libraries

Hi,

> I'm looking into using the WindC++ Gateway. I'd like to hear from anyone 
> which has used any 3rd party class libraries with VxWorks (ex. Rogue Wave's
> libraries tools.h++ or views.h++). Any comments on what worked (or didn't) 
> would be appreciated.

We have just the same question especially for tools.h++ and we appreciate 
any comments. Does someone has any experiences????

We are using VxWorks version 5.1.1 on Force boards 30 and 40 together with 
WindC++ Gateway.

Thanks for comments and greetings to the outside world

Veit Vogel

=================================================
| Veit Vogel, FZ 222 c                          |
| Telekom Forschungszentrum                     | 
|                                               |
| Am Kavalleriesand 3                           |
| D-64295 Darmstadt                             |
| Germany					|
|                                               |
| Phone: +49 6151 83 2573                       |
| Fax:   +49 6151 83 4590                       |
| email: vogel@fz.telekom.de                    |
=================================================

From mkrokosz@astro.ge.com  Fri Jan 13 06:17:59 1995
From: Matthew Krokosz <mkrokosz@astro.ge.com>
Date: Fri Jan 13 06:18:05 PST 1995
Subject: Non-Blocking Socket "send/write"

I have a vxWorks application that connects to a remote application
via TCP/IP sockets.  Once connected to the remote application, the
vxWorks application sends data to the remote application.  I need
to prevent the "write" call to the socket from blocking.  I have 
tried using the ioctl with the FIONBIO option but that did not 
work.  

The condition I am seeing this write block is when the remote
application does not service its socket.  I have produced a test
case where the remote application goes into an infinite loop once
it starts to receive data via the socket.  This causes the remote
application not to read any more data from its TCP receive buffer.
Once the remote application goes into the infinite loop, the 
vxWorks application which is writing to the socket will block
after writing X bytes to the sockets.  I think that X bytes is 
equal to the size of the TCP receive buffer on the remote 
side plus the size of the TCP send buffer on the vxWorks side.
By observing the send buffer with "inetstatShow" it is apparent
that the write does block after the send buffer fills to its
max, which probably occurs after the remote receiver buffer fills
to its max.  

Ideally I would like to make this "write/send" system call 
non-blocking, but using the ioctl did not work.  I could 
prevent the vxWorks application from getting into this blocking
situation if I could obtain the number of bytes in the send
buffer before writing to the socket.  I could then prevent
the application from writing to the socket if it would max out
the send buffer and create a blocking situation.  I can not
seem to find out how to obtain the number of bytes in the send
buffer.  Any help would be appreciated!

*************************************************************************
|  Matthew Krokosz			email: mkrokosz@astro.ge.com	|
|  Martin Marietta Astro Space		phone: (609) 490-7194		|  	
|  Princeton, NJ							|
|     									|
*************************************************************************

From eugenel@condorsys.com  Fri Jan 13 09:45:58 1995
From: eugenel@condorsys.com (Eugene Leung X714)
Date: Fri Jan 13 09:46:04 PST 1995
Subject: MVME162 IndustryPacks
Does anyone know if someone makes an IndustryPack mezzanine for a 1553B interface?
And what about ARINC 429?

Eugene

================================================================================
-                                                                              -
- Eugene Leung                        +  email:  eugenel@condorsys.com         -
- Sr. S/W Engineer                    +  phone:  (408)371-9580 ext 714         -
- Condor Systems Inc.                 +  fax:    (408)371-9589                 -
- 2133 Samaritan Dr.                                                           -
- San Jose, CA 95124                                                           -
-                                                                              -
================================================================================

From jtosey@glenayre.com  Fri Jan 13 10:07:34 1995
From: jtosey@glenayre.com (Joseph Tosey [4572])
Date: Fri Jan 13 10:07:42 PST 1995
Subject: Maximizing Ethernet Throughput
We are evaluating a board using the 82596 ethernet chip.  According
to the specs, it can handle full duplex transfers.

Question:  Has you tried connecting two ethernet devices,
           point-to-point, using a flavor of NULL-modem cable?

           One application for this is connecting a high end server to
           an ethernet switch so that the switch acts as a concentrator.
           Doing this should allow transfers of 10 Mbps in each
           direction for an aggregate throughput of 20 Mbps.

	   How did you do it?  What kind of cabling did you use?
           Any special drivers?  What results did you get?
-------------------------------------------------------------------------------
Joseph Tosey                            Fax:            +1 604 293 4317
Manager, OS & Networking                Reception:      +1 604 293 1611
Glenayre Electronics                    Voice Mail:     +1 604 293 4399 x4572
1570 Kootenay St, Vancouver, BC
V5K 2B8                                 Timezone:       PST/PDT (same as US/CA)
Canada

From mea@mclean.sparta.com  Fri Jan 13 15:40:56 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Jan 13 15:41:03 PST 1995
Subject: Re: Maximizing Ethernet Throughput
Greetings!

> Submitted-by: jtosey@glenayre.com (Joseph Tosey [4572])
>  
> We are evaluating a board using the 82596 ethernet chip.  According
> to the specs, it can handle full duplex transfers.
> 
> Question:  Has you tried connecting two ethernet devices,
>            point-to-point, using a flavor of NULL-modem cable?
> 
>            One application for this is connecting a high end server to
>            an ethernet switch so that the switch acts as a concentrator.
>            Doing this should allow transfers of 10 Mbps in each
>            direction for an aggregate throughput of 20 Mbps.
> 
> 	   How did you do it?  What kind of cabling did you use?
>            Any special drivers?  What results did you get?

I have used a special Null modem-type cable to hook two twisted pair
XCVRs back to back as a point-to-point Ethernet.  You only got 10 MBPs, but
it did work and only required 2 $40 XCVRs and a piece of twisted-pair
wiring with RJ-45 jacks on them.  I presume that, if your SBC had a 
TP interface on it, that you could hook two of them back to back with
just a $5 cable.  I've never used the Ethernet switches, so I can't comment
on that aspect.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From Greg.Gordon@dlep1.itg.ti.com  Sat Jan 14 19:27:46 1995
From: Greg.Gordon@dlep1.itg.ti.com
Date: Sat Jan 14 19:27:52 PST 1995
help 

From daemon@vxw.ee.lbl.gov  Sun Jan 15 04:00:26 1995
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 15 04:00:34 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 15 04:00:17 PST 1995

        Subject: Writing GUIs with an embedded OS
        Subject: Re: Writing GUIs with an embedded OS
        Subject: Any RIP-2, OSPF, etc. VxWorks ports?
        Subject: Re: VME to Sbus adaptors
        Subject: Re: MVME162 IndustryPacks
        Subject: VxWorks development environment?

-------------------------------------------------------

Newsgroups: comp.os.vxworks,comp.os.os9
Subject: Writing GUIs with an embedded OS
Date: 13 Jan 1995 20:13:12 GMT
From: ffdixon@bgtys3.bnr.ca (Frederick Dixon)
Organization: Bell-Northern Research
Keywords: GUI
Message-ID: <3f6mso$q9l@bcarh8ab.bnr.ca>

Hi everyone,

I'm looking for advice from people who have experience writing
GUI's with embedded operating systems -- specifically VX-Works or OS/9.

I work at Bell-Northern Research, the research arm of Northern
Telecom.  My current project involves building a prototype hand-held
device that has a touch-screen LCD interface.

We're searching for an embedded OS for the device to drive its 160x240
LCD display.  A lot of design work is going into the user interface --
ink notes, buttons, windows, scrolling lists, and animation, and sound
- -- requiring the OS (and its libraries) to handle complex graphics.  We
don't want to write the low-level graphics code ourselves!  Instead,
we would like to design the interface with a GUI builder.

RAM and ROM space are at a premium.  X-Windows is just way to big.

I would very interested in hearing from anyone who has experience in
these areas.

Cheers,... Fred Dixon, ffdixon@bnr.ca
           Software Developer, Bell-Northern Research

---------------------------

Newsgroups: comp.os.vxworks,comp.os.os9
Subject: Re: Writing GUIs with an embedded OS
Date: Fri, 13 Jan 95 21:17:18 GMT
From: arb@rtsi.com (Allan R. Batteiger)
Organization: Real-Time Services Inc
Keywords: GUI
Message-ID: <3f6ubu$j57@news.onramp.net>
References: <3f6mso$q9l@bcarh8ab.bnr.ca>

ffdixon@bgtys3.bnr.ca (Frederick Dixon) wrote:

>I'm looking for advice from people who have experience writing
>GUI's with embedded operating systems -- specifically VX-Works or OS/9.
>
>I work at Bell-Northern Research, the research arm of Northern
>Telecom.  My current project involves building a prototype hand-held
>device that has a touch-screen LCD interface.
>
>We're searching for an embedded OS for the device to drive its 160x240
>LCD display.  A lot of design work is going into the user interface --
>ink notes, buttons, windows, scrolling lists, and animation, and sound
>-- requiring the OS (and its libraries) to handle complex graphics.  We
>don't want to write the low-level graphics code ourselves!  Instead,
>we would like to design the interface with a GUI builder.
>
>RAM and ROM space are at a premium.

I can give you @ options for OS9
Option 1: Gwindows  Produced by Gespac.
   Very nice user I/F very easy to work with and build user apps.
   I can provide users references if you would like to e-mail or talk to them.

Option 2: RAVE Produced by Microware
   Also has a nice user I/F
   Advantage is built in sound support.  Gwindows does not directly support sound.
   Possible Disadvantage:  You need to check with Microware But I am not sure if
   RAVE is supported with OS9 3.0 (latest version).
   I may be able to provide user references but it has been a while.

- -------------------------------------
Allan R. Batteiger         -       President
Real-Time Services Inc.
E-mail: arb@rtsi.com      PH. (214) 245-4239

---------------------------

Newsgroups: comp.os.vxworks,comp.protocols.tcp-ip
Subject: Any RIP-2, OSPF, etc. VxWorks ports?
Date: 13 Jan 1995 22:45:45 GMT
From: bonaker@amasd.anatcp.rockwell.com (Joe Bonaker)
Organization: Rockwell
Keywords: VxWorks RIP OSPF BGP GateD
Message-ID: <3f6vqp$43p@huron.eel.ufl.edu>
Followup-To: poster
Reply-To: bonaker@amasd.anatcp.rockwell.com

Does anyone have VxWorks versions of the following Internet protocols
for share/sale?  (I'm only aware of the routed/RIP implementation on
the VxWorks ftp archive.)

    Cornell's GateD	-- kitchen sink:  RIP-[12], OSPF2, EGP2, BGP[234] ...
    RIP-2		-- RFC 1388
    OSPF		-- Version 2, RFC 1247
    BGP			-- Version 3, RFC 1268 or Version 4, RFC 1467
    Path MTU Discovery	-- RFC 1191
    Router Discovery	-- RFC 1256 (in.rdisc via ICMP raw sockets)
    IEEE 802 netif	-- Example driver supporting both 802 and Ether encap
                           

Please E-mail any relevant info; I'll followup in comp.os.vxworks.

Thanks,

Joe B.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VME to Sbus adaptors
Date: Sat, 14 Jan 1995 17:42:07 +0000
From: david@signus.demon.co.uk (David Firth)
Organization: Home
Message-ID: <1995Jan14.174207.585@signus.demon.co.uk>
References: <3evaot$8nr@oz.sim.es.com>
Sender: usenet@demon.co.uk

Stanford Pitcher (spitcher@oz.sim.es.com) wrote:
: Hello,

: 50 Hz) in sync with other.  We hoped to use TCP/IP sockets but are
: experiencing frequent glitches where the Sun's app does not respond for 
: several frames (sometimes as many as 30).  We are assuming that although
: we are running the Sun's app at real-time priority level, the net task

If the delay occurs roughly once every 30 seconds it might be the
update process. We have suffered a similar problem using SunOS 4.1.3
which is why we are considering vxworks!

- -- 
David Firth <david@signus.demon.co.uk>

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: MVME162 IndustryPacks
Date: 15 Jan 1995 05:28:51 GMT
From: pjg@tesla.svl.trw.com (Paul Gyugyi)
Organization: TRW Avionics & Surveillance Group
Message-ID: <PJG.95Jan14212851@tesla.svl.trw.com>
References: <9501131745.AA10930@csibtfr>

In article <9501131745.AA10930@csibtfr> eugenel@condorsys.com (Eugene Leung X714) writes:

   Does anyone know if someone makes an IndustryPack mezzanine for a 1553B interface?
   And what about ARINC 429?

Ballard Technology makes an ARINC 429 IndustryPack.  They also will
package it as a Motorola 162 with up to four ARINC IP's, with firmware
to store the individual data in pre-assigned VME adresses (in case you
are looking for a low software development solution).
Each IP module has two HI-8282 chips, providing a total of four inputs
and two outputs.  Ballard's number is (206) 339-0281.

Disclaimer:  I have not used these; I just have some literature from them.

- --
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Paul Gyugyi                    Paul_Gyugyi@smtp.svl.trw.com  |
| paul@gyugyi.com                gyugyi@earthsea.stanford.edu  |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks development environment?
Date: Sat, 14 Jan 1995 10:14:27 +0100
From: henryg@abc.se (Henry Gessau)
Organization: None whatsoever
Message-ID: <pNv5lqkSwREJ077yn@abc.se>

Hi all,

We are in the process of changing our embedded hardware from
80186-based to 68360. At the same time we will go from a home-made
monitor to VxWorks. We are a bit worried about the iron required for
a decent development environment.

It seems that the best (best supported, most utilities) is some sort
of Unix workstation (Sun?). The problem is that we (about 50 of us)
would then have to aquire Unix workstations since we are currently
running PC's.

What would we be missing out on if we stuck to our PC's? Surely there
is some support for MS-Windows? How about Windows NT?

- --
Henry Gessau     henryg@abc.se / sighg@eb.se / 100073.2031@compuserve.com

---------------------------

End of New-News digest
**********************

From jtosey@glenayre.com  Sun Jan 15 19:57:48 1995
From: jtosey@glenayre.com (Joseph Tosey [4572])
Date: Sun Jan 15 19:57:55 PST 1995
Subject: Re: Maximizing Ethernet Throughput
> > We are evaluating a board using the 82596 ethernet chip.  According
> > to the specs, it can handle full duplex transfers.
> > 
> > Question:  Have you tried connecting two ethernet devices,
> >            point-to-point, using a flavor of NULL-modem cable?
> > 
> >            One application for this is connecting a high end server to
> >            an ethernet switch so that the switch acts as a concentrator.
> >            Doing this should allow transfers of 10 Mbps in each
> >            direction for an aggregate throughput of 20 Mbps.
> > 
> > 	       How did you do it?  What kind of cabling did you use?
> >            Any special drivers?  What results did you get?
> 
> I have used a special Null modem-type cable to hook two twisted pair
> XCVRs back to back as a point-to-point Ethernet.  You only got 10 MBPs, but
> it did work and only required 2 $40 XCVRs and a piece of twisted-pair
> wiring with RJ-45 jacks on them.  I presume that, if your SBC had a 
> TP interface on it, that you could hook two of them back to back with
> just a $5 cable.  I've never used the Ethernet switches, so I can't comment
> on that aspect.

I'm not sure that we're on the same wavelength.  From what I
understand, you are still running half-duplex, while I
wish to run full-duplex.  Did I understand you correctly?  I.e.,
both ends simultaneously transmitted and received?  In the 1992
Intel "32-Bit Local Area Network (LAN) Component User's Manual"
(82596 manual), section 1.26.2 "Full-Duplex Operation"
paragraph, it says:
--
"The 82596 does not use the CSMA/CD protocol when it is
configured for full-duplex operation.  During full-duplex
operation the 82596 can transmit regardless of the state of its
receiver--with one exception.  The 825896 will not transmit a
new frame if the receiver is continuously active between the
previous frame transmission and the new transmit-pending
frame.  During the full duplex operation, the IFS timer is
inactive and collisions cannot occur."
--
This is the capability I wish to deploy.  I first came across
this idea a few years ago when I read an article about someone
who connected to a drone sub through a three-mile cable using a
similar technique.

Thanks in advance.
-------------------------------------------------------------------------------
Joseph Tosey                            Fax:            +1 604 293 4317
Manager, OS & Networking                Reception:      +1 604 293 1611
Glenayre Electronics                    Voice Mail:     +1 604 293 4399 x4572
1570 Kootenay St, Vancouver, BC
V5K 2B8                                 Timezone:       PST/PDT (same as US/CA)
Canada

From leonid@rst.co.il  Sun Jan 15 23:41:36 1995
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sun Jan 15 23:41:43 PST 1995
Subject: Re: Maximizing Ethernet Throughput
If you got two Ethernet stations with 10baseT sockets, it's
quite easy to connect them point to point (see below). This however
does not necesarily mean it' going to work full duplex just because
of that. Some chip/driver combinations can do full-duplex, some
don't. These that do, usually are like this not intentionally,
cause Full Duplex Ethernet is a new thing.

In 10BaseT there is also a DTE/DCE-like relation: the work station,
PC or 10baseT MAU are like DTEs, the HUB or LANswitch is kinda DCEish.
Usually you connect a station to a HUB, which requires a one-to-one
cable, connecting ins {1,2}; {3,6}. The parens determine the pairs.

If for some reason you want to connect two DTEs point-to-point, 
just make a cable like this:

	1	->	3
	2	->	6

	3	->	1
	6	->	2

You can get by without a HUB in some situations by this. You can also
connect two HUBs to one another with the same type of cable.

Special note to Joseph Tosey: your Ethernet switch is probably a DCE
so a twisted cable wont do it for you.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
R S T  Software Industries Ltd.            or: +972-50-307-142
3 Hashikma st. Industrial Zone,         Fax:   +972-3-559-8244
P.O.Box 11502, AZUR 58017, Israel       E-Mail: leonid@rst.co.il

From daemon@vxw.ee.lbl.gov  Mon Jan 16 04:00:36 1995
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 16 04:00:43 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 16 04:00:16 PST 1995

        Subject: Re: VxWorks development environment?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks development environment?
Date: 15 Jan 1995 15:53:22 GMT
From: btadlock@metronet.com
Organization: Texas Metronet
Message-ID: <3fbgdj$ib3@feenix.metronet.com>
References: <pNv5lqkSwREJ077yn@abc.se>

In article <pNv5lqkSwREJ077yn@abc.se>
henryg@abc.se (Henry Gessau) wrote:

> Hi all,
> 
> We are in the process of changing our embedded hardware from
> 80186-based to 68360. At the same time we will go from a home-made
> monitor to VxWorks. We are a bit worried about the iron required for
> a decent development environment.
> 
> It seems that the best (best supported, most utilities) is some sort
> of Unix workstation (Sun?). The problem is that we (about 50 of us)
> would then have to aquire Unix workstations since we are currently
> running PC's.
> 
> What would we be missing out on if we stuck to our PC's? Surely there
> is some support for MS-Windows? How about Windows NT?

You do not want to use ms-windows/nt based development toolsfor vxWorks
development, you will be much happier with the Unix based development system.
I just completed a vxworks project using a 68360 and we used a SUN Host and
PC's running a ms-windows based Xserver called Xvision that connected to the 
sun and allowed us to run the SUN based development system from our PC's.
email me direct if you want more details. 
BTW, I wrote almost all of the low level 68360 code/drivers for the project.
Hope This Helps!
btadlock@metronet.com

---------------------------

End of New-News digest
**********************

From djb@rtp.co.uk  Mon Jan 16 06:30:49 1995
From: djb@rtp.co.uk (David Bullimore)
Date: Mon Jan 16 06:30:55 PST 1995
Subject: Target Mode SCSI

Dear All,

Has anyone produced target mode SCSI support for VxWorks? We want to use
a VxWorks sytem as a slave on the SCSI bus.

Thanks

David

***********************************************
* David Bullimore                             *
* Real Time Products Ltd. (RTP Ltd.)          *        
* Unit 8                                      *
* Holt Court                                  *
* Aston Science Park                          *
* Birmingham                                  *
* B7 4EJ                                      *
* England                                     *
*                                             *
* Phone:      +44.21.333 6955                 *
* Fax:        +44.21.333 5433                 *
*                                             *
* Email       djb@rtp.co.uk                   *
***********************************************

From mea@mclean.sparta.com  Mon Jan 16 06:33:54 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 16 06:34:01 PST 1995
Subject: Re: VxWorks Development Environment
Greetings!

> From: henryg@abc.se (Henry Gessau)
> Hi all,
> 
> We are in the process of changing our embedded hardware from
> 80186-based to 68360. At the same time we will go from a home-made
> monitor to VxWorks. We are a bit worried about the iron required for
> a decent development environment.
> 
> It seems that the best (best supported, most utilities) is some sort
> of Unix workstation (Sun?). The problem is that we (about 50 of us)
> would then have to aquire Unix workstations since we are currently
> running PC's.
> 
> What would we be missing out on if we stuck to our PC's? Surely there
> is some support for MS-Windows? How about Windows NT?

  Well Henry, there are several alternatives.  First, if your PCs are 
networked together, you can always purchase a single Sun (or one of the
ISA-bus based Opus SPARCards that plug into your PC) and then use one
of the many fine X-Windows emulators that run under MS-DOG.  I've used
Hummingbird's Exceed and VisonWare's Xvision products with great success.
That seems to fit with WRS's licensing policy of 10 users on a single
development host.  You may want to buy a couple of hosts (and don't
forget the 2nd/3rd development (fortunately at half price) license :-), 
to support all 50 of your developers.  I can't immediately recall if 10 
users means 10 *simultaneous* users or not.  Anyone from WRS care to 
clarify?

  Alternatively, you could use VxWorks for Windows and run the Green
Hills Multi compiler/debugger on the PC.  I'm not sure if CPU32+
architectures are supported yet on that product, but I'm sure that they
soon will be if they aren't already.  However, for the number of people
you're talking about, this approach would probably be more expensive
than the Sun approach owing to the per seat cost of the Multi
development environment.  The advantage here is using your current PCs
and the possible use of a floating license manager (Green Hills has
this for the Sun, I'm not sure about the PC) such that you only buy,
say 10 licenses, and only 10 people at a crack can be
compiling/debugging simultaneously.  I don't know about the status of
support for Windows NT, but since Microsoft keeps slipping shipment 
(and I've heard many complaints about the current NT development
environment), I don't know that I'd count on NT in 1995.

  Since programmers tend to spend far more time in the editor than actually
compiling or using the source code debuggers (and you can always use printf 
statements ;-) this may work for you.  Also, don't forget those target
licenses and the ability to use the symbolic debugger provided with
VxWorks.  I used that one by itself for the first 4 years I worked with
VxWorks and it's really quite powerful.

HTH,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From leonid@rst.co.il  Tue Jan 17 00:46:52 1995
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Tue Jan 17 00:47:00 PST 1995
Subject: Milspec SPARC
Could anyone give me a pointer to where I can buy an off-the-shelf Millitary
board (VME) based on one of the SPARC processors ?
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
R S T  Software Industries Ltd.         Fax:   +972-3-559-8244
3 Hashikma st. Industrial Zone,         E-Mail: leonid@rst.co.il
P.O.Box 11502, AZUR 58017, Israel       WindRiver Distributor

From daemon@vxw.ee.lbl.gov  Tue Jan 17 04:00:37 1995
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 17 04:00:45 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 17 04:00:17 PST 1995

        Subject: Micro Tec compiler?
        Subject: VxWorks phone #

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Micro Tec compiler?
Date: 16 Jan 1995 21:27:34 GMT
From: wenchao@po.EECS.Berkeley.EDU (Wenchao Yang)
Organization: University of California, at Berkeley
Message-ID: <3feoc6$s48@agate.berkeley.edu>

Hi,

	We are planing to migrate VxWorks from MIPS R3000
to 68EC040, and the cross compiler we have for the 
48EC040 is the Micro Tec cross compiler. So is there
anyone who has successfully used the Micro Tec compiler
for the VxWorks? 

	Any informaiton would be greatly appreciated.

- --wenchao--
wenchao@storage.tandem.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks phone #
Date: 16 Jan 1995 18:03:31 GMT
From: matt@lachman.com (Matt Harper)
Organization: Lachman Technology, Inc., Naperville, IL
Message-ID: <3fecdj$bff@genesis.npr.legent.com>

Does anyone have the phone # / email address for the company that
writes VxWorks?  I would like to get some marketing liturature &
product info.

Thanks in advance,

     Matthew Harper                          Telephone: 708-505-9555 X317      
     Legent Corp., Lachman Networking Div    Fax: 708-505-9574                 
     1901 N. Naper Blvd.                     Internet: matt@npr.legent.com
     Naperville  IL 60563 USA

---------------------------

End of New-News digest
**********************

From mcolavit@huey.jpl.nasa.gov  Tue Jan 17 10:50:39 1995
From: mcolavit@huey.jpl.nasa.gov (Mark Colavita)
Date: Tue Jan 17 10:50:46 PST 1995
Subject: IP module for f/o TAXI
Hi,

Does anyone know of an IP (IndustryPack) module providing a fiber optic TAXI
interface using the HP DLT/DLR 6000 transmitter/receiver or similar?
or even a copper implementation?  Thanks.

Mark Colavita                             mcolavit@huey.jpl.nasa.gov
Jet Propulsion Laboratory, MS: 306-388    tel: 818-354-7835
4800 Oak Grove Dr.  Pasadena, CA 91109    fax: 818-393-9471

From eugenel@condorsys.com  Tue Jan 17 18:02:59 1995
From: eugenel@condorsys.com (Eugene Leung X714)
Date: Tue Jan 17 18:03:05 PST 1995
Subject: psos exploder ?
Does anyone know if there's an exploder for psos?

================================================================================
-                                                                              -
- Eugene Leung                        +  email:  eugenel@condorsys.com         -
- Sr. S/W Engineer                    +  phone:  (408)371-9580 ext 714         -
- Condor Systems Inc.                 +  fax:    (408)371-9589                 -
- 2133 Samaritan Dr.                                                           -
- San Jose, CA 95124                                                           -
-                                                                              -
================================================================================

From johncal@sunshine.labs.tek.com  Tue Jan 17 19:17:59 1995
From: johncal@sunshine.labs.tek.com (John Calvin)
Date: Tue Jan 17 19:18:05 PST 1995
Subject: Power PC compilers <What are people using?>
Greetings:

Were embarking on a project using the Beta version of the Wind River 
Power PC port. In talking to their sales people, so are a lot of other
people. If this is truly the case then there are plenty of people
with the same question we have.

What compiler are people using for Power PC's?

Currently our only semi supported option is the  Green Hill's compiler
and this needs to be purchased separately.  Will anybody share their 
comments on how well this has worked out? 

Diab Data I hear is working on one, but it will be a while.

GNU I've been advised, is 8 to 10 months away from a Power-PC compiler.
Can anybody confirm this? 

Motorola apparently has a Power PC compiler,  which according to some
sources has the highest level of optimization. This is hardly surprising,
as they know more about the Power PC than anyone. To use this would
require its "ecoff" output files be converted to an "elf" format or a re-
write of the targets symbolic linker to accept ecoff. Either way is equally
unpleasant. Has anyone done this already? 

Any thoughts from others considering the same questions would be appreciated.
Thanks in advance.

Cheers

  John Calvin, Design Technology Research Lab, Tektronix Inc.
  14150 S.W.  Karl Braun Drive  P.O. Box 500,  M.S. 50-662
  Beaverton OR 97077  U.S.A.
  John.C.Calvin@tek.com, 503-627-4840,  Fax 503-627-7875

From bolz@mars.egt.fr  Tue Jan 17 23:39:09 1995
From: Bernard Bolz <bolz@mars.egt.fr>
Date: Tue Jan 17 23:39:15 PST 1995
Subject: GNU compiler on PC for 68k targets
Hi everybody,

We are using gcc on HP 9000 for 68k targets, and we would like to generate
the same code from PC's.
So we are looking for a port of gcc for PC's, which can produce code for 68k.
Does anyone know of such a compiler?

Any help would be greatly appreciated.

B. BOLZ.
--
+------------------------------------+------------------------------------+
| Bernard BOLZ                       | European Gas Turbines              |
| EGT PEDL                           | 3, avenue des Trois Chenes         |
| tel: (33) 84.55.63.88              | 90018 BELFORT Cedex                |
| fax: (33) 84.55.35.21              | FRANCE                             |
| E-Mail: bbolz@egt.fr               |                                    |
+------------------------------------+------------------------------------+

From mea@mclean.sparta.com  Wed Jan 18 06:08:46 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Wed Jan 18 06:08:52 PST 1995
Subject: Re: GNU compiler on PC for 68k targets
Greetings!

> Submitted-by bolz@mars.egt.fr  Tue Jan 17 23:39:09 1995
> Submitted-by: Bernard Bolz <bolz@mars.egt.fr>
>  
> Hi everybody,
> 
> We are using gcc on HP 9000 for 68k targets, and we would like to generate
> the same code from PC's.
> So we are looking for a port of gcc for PC's, which can produce code for 68k.
> Does anyone know of such a compiler?
> 

According to their ad in Embedded Systems Mag, Hundred Acre Consulting in
Reno, Nevada (+1-702-829-9700) has such a beast with one year of support
in source code for $495 ($US).  I've not used it myself, but to get the
sources and binaries ready to run with 1 year of support for <$500 sounds
like a deal to me.  If nothing else, it would get you close without having
to start from scratch.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From daemon@vxw.ee.lbl.gov  Thu Jan 19 04:00:33 1995
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 19 04:00:47 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 19 04:00:21 PST 1995

        Subject: Re: problem with time()
        Subject: VME ATM with VxWorks drivers...
        Subject: How can I test for existence of a file?
        Subject: Re: VxWorks Development Environment
        Subject: Problems connecting to target via serial line	
        Subject: FAQs, FTP & Web sites, etc.
        Subject: Opening Local DOS FS files
        Subject: Re: Non-Blocking Socket "send/write"
        Subject: Re: Problems connecting to target via serial line	
        Subject: Re: Problems connecting to target via serial line
        Subject: execute()
        Subject: Re: Power PC compilers <What are people using?>
        Subject: svc_run
        Subject: Re: VME ATM with VxWorks drivers...
        Subject: Re: Opening Local DOS FS files
        Subject: Bus Errors
        Subject: XDI SMT port to VxWorks
        Subject: IPOctal
        Subject: Re: VxWorks Development Environment

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: problem with time()
Date: Fri, 13 Jan 1995 20:38:43 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Message-ID: <georg.790029523@sgl.ists.ca>
References: <3f1ei4$17n@grover.jpl.nasa.gov> <HMP.95Jan11161423@oats.frc.ri.cmu.edu>
Sender: news@newshub.ists.ca

hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:
>Without such a chip, I'm guessing the only way to get actual time is
>via the net, e.g. NTP or something like that, or through external
>hardware (like a digitizer and camera looking at a wristwatch :-)

One of the easiest ways to get time over the net is RDATE. Here is some
sample code.

Georg.

- --------------------------- rdate.c --------------------------
#include <vxWorks.h>
#include <stdlib.h>
#include <string.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sockLib.h>
#include <hostLib.h>

/* well-known internet port number for rdate,
     from Unix /usr/include/netinet/in.h  (missing in VxWorks) */
#define IPPORT_TIMESERVER      37

STATUS rdate_get(const char* hostname, unsigned long* time)
/*
 * Get the time from remote host using RDATE protocol.
 * 'hostname' is the host name or inet address to use.
 * 'time' returns the time as an integer number of seconds since midnight,
 *        January first, 1900 (subtract 2208988800 to convert to Unix time,
 *        which is in seconds since midnight, January first, 1970).
 *        Note that the rdate time format will overflow in about 2036.
 * Return value is VxWorks status code, errno==S_hostLib_UNKNOWN_HOST
 * means host name not found.
 */
{
   struct sockaddr_in socka;
   int sockfd;               /* socket descriptor */
   struct timeval timeout;   /* timeout value to pass to connectWithTimeout() */
   unsigned long tmptime;    /* time value read */

   bzero((char *)&socka, sizeof(socka));
   socka.sin_family = AF_INET;

   /* Decode a.b.c.d numeric IP address, if illegal must be a host name */
   socka.sin_addr.s_addr = inet_addr(hostname);
   if (socka.sin_addr.s_addr == -1L)  {     /* -1 means invalid address */
      /* look up host name */
      socka.sin_addr.s_addr = hostGetByName((char*)hostname);
      if (socka.sin_addr.s_addr == -1L)  {  /* -1 means error */
         /* errno will be S_hostLib_UNKNOWN_HOST here if host name not found */
         return(ERROR);
      }
   }

   socka.sin_port = IPPORT_TIMESERVER;
   if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)  {
      return(ERROR);
   }

   /* call connect() with a timeout of 8 seconds */
   timeout.tv_sec=8;
   timeout.tv_usec=0;
   if (connectWithTimeout(sockfd, (struct sockaddr *)&socka, sizeof(socka),
                          &timeout) < 0)  {
      close(sockfd);        /* ignore errors, not crucial */
      return(ERROR);
   }

   /* read 4 bytes from socket, the time */
   if (nread(sockfd, (char*)&tmptime, sizeof(unsigned long))
                                                     < sizeof(unsigned long)) {
      close(sockfd);        /* ignore errors, not crucial */
      return(ERROR);
   }

   close(sockfd);        /* ignore errors, not crucial */

   /* Note that the ntohl macro is a no-op on a 68000 series processor, but
        technically should be there as the rdate protocol is defined to return
        bytes in network order. */
   *time = ntohl(tmptime);

   return(OK);
}
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: VME ATM with VxWorks drivers...
Date: Tue, 17 Jan 1995 13:17:56 GMT
From: heyes@codahp.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.95Jan17081758@codahp.cebaf.gov>
Followup-To: comp.os.vxworks
Sender: usenet@murdoch.acc.Virginia.EDU

We are putting together an ATM network with several VME based VxWorks
systems. I had a look three months ago and couldn't find a VME card with
VxWorks drivers for ATM. Does anyone have any better information. If I
don't find anything soon I'll be buying a FORE card and writing my own
driver...
- --

		Graham

- -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Graham Heyes,CEBAF,12000 Jefferson Ave,Newport News,VA 23606,Tel:(804) 249-7030

---------------------------

Newsgroups: comp.os.vxworks
Subject: How can I test for existence of a file?
Date: Tue, 17 Jan 1995 13:23:28 GMT
From: gamin@ireq-robot.hydro.qc.ca (Martin Boyer)
Organization: La division Robotique de l'Institut de recherche d'Hydro-Quebec
Message-ID: <GAMIN.95Jan17082328@pellan.ireq-robot.hydro.qc.ca>
Followup-To: comp.os.vxworks
Sender: news@ireq.hydro.qc.ca (Netnews Admin)

I am trying to test for the existence of a file (in an NFS-mounted
partition) under VxWorks 5.1.1.

Testing the return value of the following functions gives me enough
information, but it also prints an error message on the console if the
file doesn't exist (which I don't want).

    stat(filename, &st)
	=> OK if the file exists
	=> Error if not (but also prints an error message)

    open(hostconfig, READ, 0)
	=> a file descriptor if the file exists
	=> Error if not (but also prints an error message)

I was looking for something like the UNIX "access" function, but
couldn't find it.  I'd be willing ro "redirect standard error to
/dev/null" if that would get rid of the error message and if I knew
how to do that in VxWorks.

Thanks for any help.

- --
Martin Boyer				mboyer@ireq-robot.hydro.qc.ca
Division Robotique			mboyer@ireq-robot.uucp
Institut de recherche d'Hydro-Quebec    +1 514 652-8412
Varennes, QC, Canada   J3X 1S1

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Development Environment
Date: 17 Jan 1995 15:02:17 GMT
From: btadlock@metronet.com
Organization: Texas Metronet
Message-ID: <3fgm5p$2v2@feenix.metronet.com>
References: <9501161439.AA01068@locutus>

In article <9501161439.AA01068@locutus>
mea@mclean.sparta.com (Mike Anderson) wrote:

> Greetings!
> 
>> From: henryg@abc.se (Henry Gessau)
>> Hi all,
>> 
>> We are in the process of changing our embedded hardware from
>> 80186-based to 68360. At the same time we will go from a home-made
>> monitor to VxWorks. We are a bit worried about the iron required for
>> a decent development environment.
>> 
>> It seems that the best (best supported, most utilities) is some sort
>> of Unix workstation (Sun?). The problem is that we (about 50 of us)
>> would then have to aquire Unix workstations since we are currently
>> running PC's.
>> 
>> What would we be missing out on if we stuck to our PC's? Surely there
>> is some support for MS-Windows? How about Windows NT?
> 
>   Well Henry, there are several alternatives.  First, if your PCs are 
> networked together, you can always purchase a single Sun (or one of the
> ISA-bus based Opus SPARCards that plug into your PC) and then use one
> of the many fine X-Windows emulators that run under MS-DOG.  I've used
> Hummingbird's Exceed and VisonWare's Xvision products with great success.
> That seems to fit with WRS's licensing policy of 10 users on a single
> development host.  You may want to buy a couple of hosts (and don't
> forget the 2nd/3rd development (fortunately at half price) license :-), 
> to support all 50 of your developers.  I can't immediately recall if 10 
> users means 10 *simultaneous* users or not.  Anyone from WRS care to 
> clarify?
> 
>   Alternatively, you could use VxWorks for Windows and run the Green
> Hills Multi compiler/debugger on the PC.  I'm not sure if CPU32+
> architectures are supported yet on that product, but I'm sure that they
> soon will be if they aren't already.  However, for the number of people
> you're talking about, this approach would probably be more expensive
> than the Sun approach owing to the per seat cost of the Multi
> development environment.  The advantage here is using your current PCs
> and the possible use of a floating license manager (Green Hills has
> this for the Sun, I'm not sure about the PC) such that you only buy,
> say 10 licenses, and only 10 people at a crack can be
> compiling/debugging simultaneously.  I don't know about the status of
> support for Windows NT, but since Microsoft keeps slipping shipment 
> (and I've heard many complaints about the current NT development
> environment), I don't know that I'd count on NT in 1995.
> 
>   Since programmers tend to spend far more time in the editor than actually
> compiling or using the source code debuggers (and you can always use printf 
> statements ;-) this may work for you.  Also, don't forget those target
> licenses and the ability to use the symbolic debugger provided with
> VxWorks.  I used that one by itself for the first 4 years I worked with
> VxWorks and it's really quite powerful.

Have you ever tried the vxWorks for ms-windows ?  I here it leaves alot 
to be desired.  Also, the greenhills development system is prob. the worst
Ive ever seen and/or used.  I tried for several months to get their system to
work and never got anywhere.  Their  support was awful at best.  
The Wind Rivers platform may not be the best BUT at least it WORKS !
Do yourself a favor and purchase 2 or 3 SUN hosts and get Xvisions 
Xserver for the PC, You WILL BE GLAD YOU DID !

 
                                       

---------------------------

Newsgroups: comp.os.vxworks,jpl.comp.vxworks
Subject: Problems connecting to target via serial line	
Date: Tue, 17 Jan 1995 17:55:34 GMT
From: jhops@gumby.NoSubdomain.NoDomain (Jonathan M. Hops)
Organization: Jet Propulsion Laboratory
Message-ID: <1995Jan17.175534.6416@llyene.jpl.nasa.gov>
Sender: jhops@gumby (Jonathan M. Hops)

This question probably belongs on a Solaris bulletin board, 
post here first:

I'm trying to setup my system so that I can get my hkv4f target
console to come up in a shell on my Solaris 2.3 Sparc LX.

I was able to get it to work once, but since then I keep
getting a CAN'T ACCESS DEVICE when I issue a "cu".

This occurs even after I cycle power and reboot both systems.

Maybe I'm doing something wrong with the /etc/uucp/Devices file
or not setting up my pmadm command correctly.

Any ideas or references for me? 

             _/ _/_/_/_/_/ _/          Jonathan M. Hops (818)354-1970
============_/=_/======_/=_/========>  Jet Propulsion Laboratory
           _/ _/_/_/_/_/ _/            M/S 238-528
  _/      _/ _/         _/             4800 Oak Grove Drive
 _/      _/ _/         _/              Pasadena, California
_/_/_/_/_/ _/         _/_/_/_/_/_/     91109  USA
                                        
- --------------------------------------------------------------
"Integrity without knowledge is weak and useless, and knowledge
without integrity is dangerous and dreadful."
- -- SAMUEL JOHNSON 1709P1784

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQs, FTP & Web sites, etc.
Date: 17 Jan 1995 21:24:26 GMT
From: joemct@hurricane.cds.tek.com ( CDS)
Organization: Tektronix Colorado Data Systems, Englewood, Co.
Message-ID: <3fhcia$lk0@tekgen.bv.tek.com>

Net surfers,

	Please post pointers to vxWorks FAQs, web sites, FTP sites, and
any other interesting repositories of "real-time" info that you know of.
I would like to expand my knowledge and need a place to start.

	Thanks in advance.

***************************************************
* McJoe can be found lurking in the following     *
* shadowy places:                                 *
*                                                 *
*  josephm@banyan.bv.tek.com                      *
*  TheMcJoe@aol.com                               *
*                                                 *
* "He knows that changes aren't permanent...      *
*     But change is!!!"                           *
*                       - Rush                    *
***************************************************

---------------------------

Newsgroups: comp.os.vxworks
Subject: Opening Local DOS FS files
Date: Tue, 17 Jan 1995 23:32:10 GMT
From: geger@phantom.den.mmc.com (George Eger)
Organization: Martin Marietta Astronautics Group
Keywords: DOS fopen
Message-ID: <1995Jan17.233210.18052@den.mmc.com>
Sender: news@den.mmc.com (News Admin)

OK, I give.  What's the trick to opening a file on a local DOS FS SCSI
disk?  I can ls() or ll() and see it.  I can copy() it to stdout.  But
my program, which successfully opens files on my remote Sun and reads them,
can't open the same file when copied to a local SCSI disk.  In both
cases, I'm using 

  inFD = fopen(filenameStr, "r");

The across-the-net works great.  The local gives back inFD = NULL, but
errno is also 0.

Any ideas will be welcome.  I'm trying to read local script files, and
it is kind of a drag when I can read them from across the net, but
not off the local disk.

TIA,

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Non-Blocking Socket "send/write"
Date: Tue, 17 Jan 1995 22:48:13 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD2KnCD.7tK@netcom.com>
References: <199501131418.JAA26364@a9926.ASTRO.GE.COM>

In article <199501131418.JAA26364@a9926.ASTRO.GE.COM>,
Matthew Krokosz  <mkrokosz@astro.ge.com> wrote:
>
>I have a vxWorks application that connects to a remote application
>via TCP/IP sockets.  Once connected to the remote application, the
>vxWorks application sends data to the remote application.  I need
>to prevent the "write" call to the socket from blocking.  I have 
>tried using the ioctl with the FIONBIO option but that did not 
>work.  

FIONBIO does work.  are you sure you are turning FIONBIO *on*?

>
>The condition I am seeing this write block is when the remote
>application does not service its socket.  I have produced a test
>case where the remote application goes into an infinite loop once
>it starts to receive data via the socket.  This causes the remote
>application not to read any more data from its TCP receive buffer.
>Once the remote application goes into the infinite loop, the 
>vxWorks application which is writing to the socket will block
>after writing X bytes to the sockets.  I think that X bytes is 
>equal to the size of the TCP receive buffer on the remote 
>side plus the size of the TCP send buffer on the vxWorks side.
>By observing the send buffer with "inetstatShow" it is apparent
>that the write does block after the send buffer fills to its
>max, which probably occurs after the remote receiver buffer fills
>to its max.  
>

if your socket level buffer on the send side is full, and you have
FIONBIO turned on, your write() will return EWOULDBLOCK.

>Ideally I would like to make this "write/send" system call 
>non-blocking, but using the ioctl did not work.  I could 
>prevent the vxWorks application from getting into this blocking
>situation if I could obtain the number of bytes in the send
>buffer before writing to the socket.  I could then prevent
>the application from writing to the socket if it would max out
>the send buffer and create a blocking situation.  I can not
>seem to find out how to obtain the number of bytes in the send
>buffer.  Any help would be appreciated!
>
>

you can use getsockopt() with SOL_SOCKET, SO_SNDBUF, to retrieve the size
of your socket's send buffer.

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, Oakland, CA

---------------------------

Newsgroups: comp.os.vxworks,jpl.comp.vxworks
Subject: Re: Problems connecting to target via serial line	
Date: Tue, 17 Jan 1995 23:00:26 GMT
From: miked@wrs.com (Mike Deliman)
Organization: Wind River Systems, Inc.
Message-ID: <D2Knwr.E4H@wrs.com>
References: <1995Jan17.175534.6416@llyene.jpl.nasa.gov>
Sender: news@wrs.com (News Manager)

In article <1995Jan17.175534.6416@llyene.jpl.nasa.gov> jhops@gumby.NoSubdomain.NoDomain (Jonathan M. Hops) writes:
>
>I'm trying to setup my system so that I can get my hkv4f target
>console to come up in a shell on my Solaris 2.3 Sparc LX.
>
>I was able to get it to work once, but since then I keep
>getting a CAN'T ACCESS DEVICE when I issue a "cu".

Hello Mr. Hops,

Check your /etc/remote file for the serial port your hkv4f is
connected to, and be sure it's entry is correct. Then 
tip <entry>
e.g.
tip ttya

and that should do it.

       Regards,
       -mike
- -- 
- ------------------------------------------------------------------------------
  Mike Deliman <> miked@wrs.com <> phone: 510-748-4100 <> facs: 510-814-2164
  Snail Mail:  Wind River Systems,  1010 Atlantic Ave,  Alameda CA 94501 USA
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks,jpl.comp.vxworks
Subject: Re: Problems connecting to target via serial line
Date: 17 Jan 1995 23:44:13 GMT
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <3fhkod$2lj@grover.jpl.nasa.gov>
References: <1995Jan17.175534.6416@llyene.jpl.nasa.gov>

In article <1995Jan17.175534.6416@llyene.jpl.nasa.gov>, jhops@gumby.NoSubdomain.NoDomain (Jonathan M. Hops) writes:
|> 
|> This question probably belongs on a Solaris bulletin board, 
|> post here first:
|> 
|> I'm trying to setup my system so that I can get my hkv4f target
|> console to come up in a shell on my Solaris 2.3 Sparc LX.
|> 
|> I was able to get it to work once, but since then I keep
|> getting a CAN'T ACCESS DEVICE when I issue a "cu".
|> 
|> This occurs even after I cycle power and reboot both systems.
|> 
|> Maybe I'm doing something wrong with the /etc/uucp/Devices file
|> or not setting up my pmadm command correctly.
|> 
|> Any ideas or references for me? 

I was able to talk to my HKV4F from Solaris 2 ("out of the box") using
kermit ($ kermit -l /dev/term/b -b 9600).  I don't know about cu, but
I can toss a kermit binary your way if it will help.

Matt
- -- 
matthew.r.wette@jpl.nasa.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: execute()
Date: Wed, 18 Jan 1995 00:08:07 GMT
From: geger@phantom.den.mmc.com (George Eger)
Organization: Martin Marietta Astronautics Group
Keywords: shell yacc 
Message-ID: <1995Jan18.000807.21794@den.mmc.com>
Sender: news@den.mmc.com (News Admin)

I am running a user interface program from the VxWorks shell and would like
to allow the user to 'escape' to the shell to execute shell commands.

I found execute() in the call stack for the normal shell, and if I hand it a
pointer to the character string of the command requested, it seems to
do that command okay.

The problem is, on exit from my program, I get error messages like:

0x77c468 (tShell): memPartFree: invalid block 0x719eb4 in partition 0x84176

due to yyparse() not being re-entrant.

Is there a better way to do this?  I really don't want to have to build my own
shell command parser.  Why can't execute() or yyparse() be made
re-entrant?  Is this fixed/improved/considered for VxWorks 5.2/5.X/6.0?

TIA,

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Power PC compilers <What are people using?>
Date: Wed, 18 Jan 1995 18:04:40 GMT
From: moore@ced.utah.edu (Tim Moore)
Organization: University of Utah Center for Engineering Design
Message-ID: <MOORE.95Jan18110440@ruin.ced.utah.edu>
References: <9501180316.AA16552@sunshine.LABS.TEK.COM>
Sender: news@ced.utah.edu

In article <9501180316.AA16552@sunshine.LABS.TEK.COM> johncal@sunshine.labs.tek.com (John Calvin) writes:

   GNU I've been advised, is 8 to 10 months away from a Power-PC compiler.
   Can anybody confirm this? 

gcc already generates code for the PowerPC.  The sticking point might be
gdb, gas, and the other binutils.  However, they already generate /
read rs6000 binaries, so it seems likely that PowerPC ports are pretty
close.

- --

Tim Moore                Sarcos Research Corp.               moore@ced.utah.edu
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush

---------------------------

Newsgroups: comp.os.vxworks
Subject: svc_run
Date: Wed, 18 Jan 1995 17:53:32 GMT
From: shurstik@ceco.ceco.com (Susan L. Hurstik)
Organization: Commonwealth Edison Company
Message-ID: <D2M4D8.52y@ceco.ceco.com>
Reply-To: shurstik@ceco.ceco.com
Sender: root@ceco.ceco.com (Operator)

Hello,

I need to support call-back functionality for an rpc app I wrote.  In order to do this, I need to write my own svc_run routine.  I have done this under solaris with no problem.  Under vxWorks however, I'm not sure what parametes to pass to the select call.  Has anyone done this before or has access to the source vxWorks uses for svc_run?  Here is what the routine looks like on a Sun app:

int asyncSvcRun()
{
        fd_set  readfds;
        struct timeval timeout;
        int     dtbsize;
        int     retVal;

        int     i;
        extern int      errno;

        struct rlimit rlp;
        getrlimit(RLIMIT_NOFILE,  &rlp);
        dtbsize = (int)rlp.rlim_cur;

        readfds = svc_fdset;  /* svc_fdset is a global var */

        timeout.tv_sec = 0;
        timeout.tv_usec = 0;

        switch(i = select(dtbsize, &readfds, NULL, NULL, &timeout)){
            case -1:
            case 0:
                    retVal = 0;
                    break;
            default:
                    retVal = 1;
                    svc_getreqset(&readfds);
                    break;
        }

        return(retVal);
}

Thanks in advance

- -Sue

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VME ATM with VxWorks drivers...
Date: Wed, 18 Jan 1995 04:50:19 GMT
From: afraser@hookup.net (Andrew Fraser)
Organization: HookUp Communication Corporation, Oakville, Ontario, CANADA
Message-ID: <afraser.177.2F1C9E0A@hookup.net>
References: <HEYES.95Jan17081758@codahp.cebaf.gov>

In article <HEYES.95Jan17081758@codahp.cebaf.gov> heyes@codahp.cebaf.gov (Graham Heyes) writes:
>We are putting together an ATM network with several VME based VxWorks
>systems. I had a look three months ago and couldn't find a VME card with
>VxWorks drivers for ATM. Does anyone have any better information. If I
>don't find anything soon I'll be buying a FORE card and writing my own
>driver...
>--
Call Newbridge Microsystems (613) 592-0714.  I know they have a VME ATM card, 
but I don't know what software or drivers are available.

- -Andy

    ----------------------------------------------------------------
   |       Andrew Fraser             ******                   ***** |
   |    Senior Hardware Engineer     ***** *                 *****  |
   |                                 **** ***  ***** *****  ***** * |
   |   Tel: (613) 596-9922 ext 251   *** ****  **** *****  ***** ** |
   |   Fax: (613) 596-0574           ** *****  *** *****  ***** *** |
   | Email: andrewf@dy4.isis.org     * *****   ** *****  ***** **** |
   |        afraser@hookup.net       ******    * *****        ***** |
   | DY 4 Systems Inc.                          *****               |
   | 21 Fitzgerald Rd., Nepean                 *****                |
   | Ontario, Canada K2H 9J4         CUSTOMER FIRST, QUALITY ALWAYS |
    ----------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Opening Local DOS FS files
Date: Wed, 18 Jan 1995 05:14:16 GMT
From: jfinley@netcom.com (John Finley)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <jfinleyD2L57t.G26@netcom.com>
References: <1995Jan17.233210.18052@den.mmc.com>

George Eger (geger@phantom.den.mmc.com) wrote:
: OK, I give.  What's the trick to opening a file on a local DOS FS SCSI
[edit]
:   inFD = fopen(filenameStr, "r");
[edit]
: ||==========================================================================
: ||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||

You aren't perchance using unescaped backslashes, are you?
The C string "\sd0\newfile.dat" has an embedded newline and
something else; you'd probably want "\\sd0\\newfile.dat".
(Or better, "/sd0/newfile.dat")
- -John Finley
jfinley@netcom.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Bus Errors
Date: 18 Jan 1995 23:01:36 GMT
From: jroberts@.jpl.nasa.gov (James A. Roberts)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Message-ID: <3fk6kg$lap@grover.jpl.nasa.gov>
Reply-To: jroberts@.jpl.nasa.gov

I am having problems with random bus errors in bcopy and bfill when using msg queues 
and taskSpawn in 5.02-B on a hkv3f.

I am using the patch for the fp exceptions from the FAQ (item 31) and it helped a lot,
 but I still have the problem when under a heavy load.

any suggestions?

- ---
James A. Roberts

---------------------------

Newsgroups: comp.os.vxworks
Subject: XDI SMT port to VxWorks
Date: 17 Jan 1995 23:55:15 GMT
From: sri@buggy.tdd.sj.nec.com (Sri Chaganty)
Organization: DCSD, NEC America, San Jose California
Message-ID: <3fhld3$duv@elvis.syl.sj.nec.com>

I am interested to know the expereinces of any one who might have
ported XDI's SMT software to VxWorks environment.

Please send your replies to my e-mail address at
sri@dcsd.sj.nec.com

Thanks in advance.

Sri.

---------------------------

Newsgroups: comp.os.vxworks
Subject: IPOctal
Date: 18 Jan 1995 19:06:52 GMT
From: maskrey@pooh.sdd.trw.com (Ken Maskrey)
Organization: Data Technologies Division, TRW Inc.
Keywords: IP Serial
Message-ID: <3fjosc$bik@yakko.sdd.TRW.COM>

I remember someone a while back had source for one of the
Octal Industry Packs(IPs). Could someone either send me the
source, if available, or point me to where I can get it?

Thanks,
Ken Maskrey
TRW

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Development Environment
Date: 19 Jan 1995 07:50:45 GMT
From: PJDJ44A@prodigy.com (Stan Hilinski)
Organization: Prodigy Services Company  1-800-PRODIGY
Message-ID: <3fl5kl$7che@usenetp1.news.prodigy.com>

btadlock@metronet.com  wrote:
>Have you ever tried the vxWorks for ms-windows ?  I here it leaves alot 

>to be desired.  Also, the greenhills development system is prob. the 
worst
>Ive ever seen and/or used.  I tried for several months to get their 
system to
>work and never got anywhere.  Their  support was awful at best.  
>The Wind Rivers platform may not be the best BUT at least it WORKS !
>Do yourself a favor and purchase 2 or 3 SUN hosts and get Xvisions 
>Xserver for the PC, You WILL BE GLAD YOU DID !

I won't dispute the gentleman's difficulties with Greenhill's Multi, but 
I think
it's important to say they we've had a completely different experience 
with
it. I personally think it's a terrific development tool for both vxworks 
and
sun platforms. We have used it in at least one major project and plan to
use it in others. As for support, it's been great. I e-mail problems 
and
suggestions to customer support, and I usually get a response within a 
couple hours. And on the occasions I needed a patch, they've mailed them
the same day. Naturally, I've resorted to the phone for real emergencies
for instantaneous help.  All in all, it's been a wonderful tool.

Stan Hilinski, Goddard Spaceflight Center, Greenbelt, Md

---------------------------

End of New-News digest
**********************

From guthrie@power.amasd.anatcp.rockwell.com  Thu Jan 19 08:17:07 1995
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Thu Jan 19 08:17:16 PST 1995
Subject: XDI SMT port to VxWorks
(Sri Chaganty writes)

> Newsgroups: comp.os.vxworks
> Subject: XDI SMT port to VxWorks
> Date: 17 Jan 1995 23:55:15 GMT
> From: sri@buggy.tdd.sj.nec.com (Sri Chaganty)
> Organization: DCSD, NEC America, San Jose California
> Message-ID: <3fhld3$duv@elvis.syl.sj.nec.com>
> 
> I am interested to know the expereinces of any one who might have
> ported XDI's SMT software to VxWorks environment.
> 
> Please send your replies to my e-mail address at
> sri@dcsd.sj.nec.com
> 
> 
> Thanks in advance.
> 
> 
> Sri.
> 
> ---------------------------

I would also be interested in responses to this question.

	Robert Guthrie
	e-mail : guthrie@power.amasd.anatcp.rockwell.com

From dunk@ftms.com  Thu Jan 19 09:09:07 1995
From: Michael Dunk <dunk@ftms.com>
Date: Thu Jan 19 09:09:14 PST 1995
Subject: Re: svc_run
> I need to support call-back functionality for an rpc app I wrote.
> In order to do this, I need to write my own svc_run routine.
> I have done this under solaris with no problem.  Under vxWorks however,
> I'm not sure what parameters to pass to the select call.  Has anyone
> done this before or has access to the source vxWorks uses for svc_run?

The calling syntax to the select call is the same under vxWorks.
The only tricky part to writing your own svc_run is accessing svc_fdset.
Under vxWorks 5.0.3, svc_fdset is unique to each task. We accessed it
using the following routine (this may have changed in 5.1):

#include <rpc/rpcGbl.h>

extern WIND_TCB *taskIdCurrent;

void
VCSGetfdset( fdPtr )
fd_set          *fdPtr;
{
	struct svc              *ms = &taskRpcStatics->svc;

	*fdPtr = ms->svc_fdset;
}

We do not use this function anymore, as we found it more efficient to
break up our application into multiple tasks, one of which uses the
standard svc_run call.
----

-----------------------------------------
Michael F. Dunk
Extrel FTMS Inc.
6416 Schroeder Road
Madison, Wisconsin, 53711-2424
(608)-273-8262
dunk@ftms.com
-----------------------------------------

From mea@mclean.sparta.com  Thu Jan 19 15:30:21 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 19 15:30:28 PST 1995
Subject: Re: FAQs, FTP & Web Sites, etc.
Greetings!

  Well, some progress is finally being made!  We have a new address for 
the VxWorks FAQ.  That address is:

ftp.mclean.sparta.com (157.185.32.10).  (The old address still works as well).

Anonymous FTP is up and seems to be working.  I've been trying to access
the names I was given as FAQ masters on the net to post a new copy of
the FAQ, but to no avail.  Does anyone have the addresses of the folks I
need to talk to about becoming the *official* keeper of the VxWorks FAQ?
Any pointers would be appreciated.  

I'm also working on updating the FAQ to bring in the running threads about
MV167 flash programming, etc.

I am also soliciting any info from the group relating to available
device drivers, consulting, etc. that would be appropriate for the FAQ
and its related files.  I hope to have a revised FAQ and associated
files on-line by Feb 1.  Please send any info you have and I'll do my
best to include it in this new revision.

We also have a *rudementary* web server up at:

http://www.mclean.sparta.com

I'm currently working on getting entries added for the User's Group 
archives mirror here as well as the FAQ and related files.  I would like
to have entries for the User's Group Meetings as well.  Can the west
coast stuckee please contact me so I can get that info into the hopper?

For those groups that are adding their own web servers, if you would
like a pointer from SPARTA's home page to yours for things like consulting
or driver work, please include that info in your submissions to me and
we'll add a link.

Again, I apologize for the delays in getting all of this up to date and
functioning.  I always takes longer and costs more than you expect ;-).

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From stan@lassen.rti.com  Thu Jan 19 18:13:10 1995
From: stan@lassen.rti.com (Stan Schneider)
Date: Thu Jan 19 18:13:16 PST 1995
Subject: Nitro 60

Does anyone have any experience with the Nitro 60 board from Heurikon?

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From daemon@vxw.ee.lbl.gov  Fri Jan 20 04:00:31 1995
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 20 04:00:41 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 20 04:00:20 PST 1995

        Subject: Re: Opening Local DOS FS files
        Subject: help with ls()
        Subject: EtherXpress Pro Driver VxWorks
        Subject: Re: svc_run
        Subject: Restarting a task at a specified location?
        Subject: Re: help with ls()
        Subject: Re: GNU compiler on PC for 68k targets
        Subject: Re: Programming FLASH on the MV162
        Subject: Re: Power PC compilers <What are people using?>
        Subject: Re: VME ATM with VxWorks drivers...
        Subject: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
        Subject: Re: Writing GUIs with an embedded OS

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Opening Local DOS FS files
Date: Thu, 19 Jan 1995 15:23:25 GMT
From: geger@phantom.den.mmc.com (George Eger)
Organization: Martin Marietta Astronautics Group
Keywords: DOS fopen
Message-ID: <1995Jan19.152325.20200@den.mmc.com>
References:  <1995Jan17.233210.18052@den.mmc.com>
Sender: news@den.mmc.com (News Admin)

In article <1995Jan17.233210.18052@den.mmc.com>, geger@phantom.den.mmc.com (George Eger) writes:
|> OK, I give.  What's the trick to opening a file on a local DOS FS SCSI
|> disk?  I can ls() or ll() and see it.  I can copy() it to stdout.  But
|> my program, which successfully opens files on my remote Sun and reads them,
|> can't open the same file when copied to a local SCSI disk.  In both
|> cases, I'm using 
|> 
|>   inFD = fopen(filenameStr, "r");
|> 
|> The across-the-net works great.  The local gives back inFD = NULL, but
|> errno is also 0.
|> 
|> Any ideas will be welcome.  I'm trying to read local script files, and
|> it is kind of a drag when I can read them from across the net, but
|> not off the local disk.
|> 

Actually, the way I get a filename is to read in a line of user ascii
from stdin using fgets(), look for a '<', and call fopen with the rest
of the string.  Here's a condensed fragment of what I'm doing:

extern int errno;
FILE *inFD, *LastInFD;

int get_token(char *inputLine,
				FILE *inFD,
				FILE *newFD)
{

	if (fgets(&(inputLine[0]),
				MAX_CHAR_PER_LINE,
				inFD) != NULL)
		{
		if (input[0] == '<')
			{
			newFD = fopen(&(inputLine[1]), "r");

			if (newFD == NULL)
				{
				logMsg("Failed to open script file %s (errno %d)\n",
						&(inputLine[1]), errno);
				return(FAILED_OPENING_SCRIPT);
				}
			
			else return(READING_NEW_SCRIPT);
			}

		else return(GOT_TOKEN);
		}
	
	else return(END_OF_INPUT);
}

I've tried using a file name including the device name of the local disk
( </sd0/takecntl.bat ) and,  by first setting the current working directory
to /sd0 ( -> cd "/sd0/" ) just the filename ( <takecntl.bat ).

The code takes the NULL pointer path and I get the error message
and the filename I put in, but errno = 0.

This is very perplexing... since it can read a remote file on my Unix
box when the full path or the relative path is supplied.

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: help with ls()
Date: 19 Jan 1995 17:35:14 GMT
From: schof@predator.uucp (Steven Schofield)
Organization: University of California at Berkeley
Message-ID: <3fm7si$h7t@agate.berkeley.edu>

I need help with the 'openDir' command and the
'stat', 'fstat' commands.

I can open() a file and read from, but I can't get
the fstat or stat of the file. Infact I can't even
do a ls() or ll() command from the shell.  I'm doing 
this accross the net.

Any ideas?

Thanks

Steve

---------------------------

Newsgroups: comp.os.vxworks
Subject: EtherXpress Pro Driver VxWorks
Date: 19 Jan 1995 18:56:48 GMT
From: RRCM76A@prodigy.com (W Chenevert)
Organization: Prodigy Services Company  1-800-PRODIGY
Message-ID: <3fmclg$24j4@usenetp1.news.prodigy.com>

We are looking for an EtherXpress Pro driver for VxWorks.  Wind R doesn't 
seem intrested in developing one.  They have driver for EtherXpress but 
not EtherXpree Pro and there is quite a difference in the hardware.  If 
anyone knows where we can get this driver I would appreciate it.

W.J. Chenevert    (wjchenevert@halnet.com)
- -
  W CHENEVERT  RRCM76A@prodigy.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: svc_run
Date: Thu, 19 Jan 1995 16:22:45 GMT
From: mtvgae01@ntmtv.com (Geoffrey A Espin)
Organization: Northern Telecom Inc, Mountain View, CA
Message-ID: <D2nutx.Htx@ntmtv.com>
References:  <D2M4D8.52y@ceco.ceco.com>
Sender: news@ntmtv.com

In article <D2M4D8.52y@ceco.ceco.com>, shurstik@ceco.ceco.com (Susan L. Hurstik) writes:
|> I need to support call-back functionality for an rpc app I wrote.
|>In order to do this, I need to write my own svc_run routine.
|>I have done this under solaris with no problem.  Under vxWorks however,
|>I'm not sure what parametes to pass to the select call.
|>Has anyone done this before or has access to the source vxWorks
|>uses for svc_run?  Here is what the routine looks like on a Sun app:

Looks good to me.
If you look in unsupported/demo/sprites there's an example.
The svc_run() routine is called svc_doit().

|>         struct rlimit rlp;
|>         getrlimit(RLIMIT_NOFILE,  &rlp);
|>         dtbsize = (int)rlp.rlim_cur;

AKA getdtablesize() which VxWorks never had.  The undocumented variable
<maxFiles> contains this value which is defined in config/all/configAll.h
by the macro NUM_FILES(50).  Actually, the set width that you care about
is the highest 'fd' bit set -- you could use ffsMsb() (finds most
significant bit set) to specify the value (this might be more efficient
for select()).

Geoff
- -- 

  __/ _/      _/_/_/     Geoffrey Espin mtvgae01@ntmtv.com
 _/_|_/        _/        (415)940-2992 Fax (415)966-1067
_/ __/orthern _/elecom   685A E. Middlefield, PO Box 7277, Mtn View, CA 94039

---------------------------

Newsgroups: comp.os.vxworks
Subject: Restarting a task at a specified location?
Date: Thu, 19 Jan 1995 15:41:09 -0700
From: cobarruvias@asd1.jsc.nasa.gov (John R. Cobarruvias)
Organization: NASA/JSC
Message-ID: <cobarruvias-190195154109@ekm085.jsc.nasa.gov>
Followup-To: comp.os.vxworks

Bear with me folks, I am trying to understand someone elses design and code
from it.........(and worst of all, the designer is no longer in the
area......)

I have a task (TASK A) that does the following:

1) spawned at initialization time
2) performs task specific one time only initialization (such as ties a
Signal Handler to a RESET_SIGNAL)
3) Then waits on a semaphore
4) Upon getting the semaphore, performs its task
5) Gives up the semaphore
6) Goes to 3 (wait mode again)

But.....If the application receives a RESET interrupt, the ISR sends a
signal to TASK A, if it is active (not waiting for the semaphore). The
signal handler must then do the following:

1) reset various parameters
2) then instruct TASK A to give up the semaphore, and then restart at 3
above, which is to wait for the semaphore again.

So the question is: How can the signal handler perform its processing, then
instruct TASK A to restart at the point of waiting for the semaphore
regardless of where in the code the task was "signaled" to stop?

Hey folks, any help would be appreciated!

John R. Cobarruvias

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: help with ls()
Date: Thu, 19 Jan 1995 21:46:18 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD2o9t6.3Kv@netcom.com>
References: <3fm7si$h7t@agate.berkeley.edu>

In article <3fm7si$h7t@agate.berkeley.edu>,
Steven Schofield <schof@predator.uucp> wrote:
>
>I need help with the 'openDir' command and the
>'stat', 'fstat' commands.
>
>I can open() a file and read from, but I can't get
>the fstat or stat of the file. Infact I can't even
>do a ls() or ll() command from the shell.  I'm doing 
>this accross the net.
>

vxworks has no consistency in this area because it does not have a
consistent file system model; it does not have a real file system --
their filesystems are bunch of drivers that act like file systems.
some of these drivers do a better job, some don't.  not all of them do the
same set of operations consistently.  it all depends on which file system
device driver you're using.  

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, Oakland, CA

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU compiler on PC for 68k targets
Date: 19 Jan 1995 22:08:15 GMT
From: billr@saab.CNA.TEK.COM (Bill Randle)
Organization: Tektronix, Inc., Redmond, OR
Message-ID: <3fmnsf$r58@marlyn.cna.tek.com>
References: <9501180739.AA22729@mars.egt.fr>
Reply-To: billr@saab.CNA.TEK.COM

In article <9501180739.AA22729@mars.egt.fr>, Bernard Bolz <bolz@mars.egt.fr> writes:
|> We are using gcc on HP 9000 for 68k targets, and we would like to generate
|> the same code from PC's.
|> So we are looking for a port of gcc for PC's, which can produce code for 68k.
|> Does anyone know of such a compiler?

You don't mention what OS on the PCs, but something to think about would be to
run Linux (or similar OS) on the PCs [you can have split Linux/DOS partitions
on the hard drive]. I've successfully ported gcc 2.6.2 to run under Linux/486
as a 68k cross compiler. Works just fine. [I did have to tweak the config file
a little.] I also compiled the binutils to get as68k, ld68k, nm68k, et.al.

- -- 
	-Bill Randle
	Tektronix, Inc.
	billr@saab.CNA.TEK.COM

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Programming FLASH on the MV162
Date: 19 Jan 1995 18:57:05 GMT
From: switt@triceratops.hac.com (Steve Witt)
Organization: Hughes Aircraft Company
Message-ID: <3fmcm1$1r9@hacgate2.hac.com>
References: <199501101734.KAA03798@xmission.xmission.com>

The manual page that comes with the MVME-162 BSP describes how to
program the on-board FLASH over the Ethernet interface pretty well.
'man mv162'.

The Motorola BUG ROM is used to do this and there is a jumper on the
board to tell the board to boot out of ROM or FLASH.

The trickiest part of the whole operation for me was to figure
out how to configure TFTP on the Sun to allow the file transfer.
This isn't explained in the VxWorks documentation (and I'm not
saying it should be) but you need to modify the entry in /etc/inetd.conf
for TFTP.  There is a directory on this line that is the directory
from which your bootable image is TFTP'd.  

- --------------------------------------------------------------------------
Steve Witt                                   switt@triceratops.hac.com
Hughes Aircraft Company

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Power PC compilers <What are people using?>
Date: Thu, 19 Jan 1995 23:55:09 GMT
From: chris@wrs.com (Chris Ford)
Organization: Wind River Systems, Inc.
Message-ID: <chris.790559709@wrs.com>
References: <9501180316.AA16552@sunshine.LABS.TEK.COM>
Sender: news@wrs.com (News Manager)

Hello,

johncal@sunshine.labs.tek.com (John Calvin) asks:
> What compiler are people using for Power PC's?

All the vendors you mentioned are fine companies.  We work with several
of them at Wind River, as each has strengths that appeal to certain
customers.  We advise you to consider standards compliance now so you
aren't locked into a proprietary solution later.

The leaders in the embedded community are rallying around the Embedded
Application Binary Interface (EABI), a derivative of SVR4 for PowerPC.

For PowerPC EABI information, please contact:

          Stephen Sobek           |                Kevin Burke
Microcontroller Technologies Group|            Technology Products
             Motorola             | International Business Machines Corporation
  6501 William Cannon Drive West  |           3039 Cornwallis Road
          Mail Stop OE45          |             Mail Stop H83/061
         Austin, TX 78735         |      Research Triangle Park, NC 27709
      steve@avar.sps.mot.com      |          kevin_burke@vnet.ibm.com

>  John Calvin, Design Technology Research Lab, Tektronix Inc.
>  14150 S.W.  Karl Braun Drive  P.O. Box 500,  M.S. 50-662
>  Beaverton OR 97077  U.S.A.
>  John.C.Calvin@tek.com, 503-627-4840,  Fax 503-627-7875

- --
Chris Ford     <chris@wrs.com>
Wind River Systems Engineering
- -- 
Chris Ford     <chris@wrs.com>
Wind River Systems Engineering

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VME ATM with VxWorks drivers...
Date: 19 Jan 1995 22:15:13 -0700
From: bgeer@xmission.com (bgeer)
Organization: XMission Public Access Internet (801 539 0900)
Message-ID: <3fngt1$b2v@xmission.xmission.com>
References: <HEYES.95Jan17081758@codahp.cebaf.gov> <afraser.177.2F1C9E0A@hookup.net>

afraser@hookup.net (Andrew Fraser) writes:

 >In article <HEYES.95Jan17081758@codahp.cebaf.gov> heyes@codahp.cebaf.gov (Graham Heyes) writes:
 >>We are putting together an ATM network with several VME based VxWorks
 >>systems. I had a look three months ago and couldn't find a VME card with
 >>VxWorks drivers for ATM. Does anyone have any better information. If I
 >>don't find anything soon I'll be buying a FORE card and writing my own
 >>driver...
 >>--
 >Call Newbridge Microsystems (613) 592-0714.  I know they have a VME ATM card, 
 >but I don't know what software or drivers are available.

Interphase also has ATM cards.  Their first ATM was one of their 5211
FDDI cards depopulated with an ATM daughter card.  I'm told they are
nearing release of a new layout VME w/ ATM with a media (fiber,
copper, ?) daughter card.  Not sure about drivers yet, tho their 5211
has a readily available driver which might be re-cooked for ATM.

Bob
- -- 
<>  Bob `Bear' Geer   <>               *                /    <>
<> bgeer@xmission.com <>     _o     *   o *      ,_____/o    <>
<>  Salt Lake City,   <>    -\<,     * <\      ~~,__/  > ~~  <>
<>    Ootah, USA      <>    O/ O    __ /__,           /      <>

---------------------------

Newsgroups: comp.os.vxworks,comp.sys.m68k,alt.industrial.computing,sci.electronics,rec.radio.amateur.space
Subject: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
Date: 18 Jan 1995 03:03:02 GMT
From: grusin@benji.Colorado.EDU (GRUSIN MICHAEL)
Organization: University of Colorado, Boulder
Message-ID: <3fi0d6$hbr@CUBoulder.Colorado.EDU>

We are looking for an off-the-shelf, MIL SPEC (883B), 68020/30/40,
embedded system board for flight on a research satellite.  If anyone
has pointers to companies which supply such boards, I'd appreciate
hearing about them! 

Thanks, -Mike Grusin (grusin@rintintin.colorado.edu)

---------------------------

Newsgroups: comp.os.vxworks,comp.os.os9
Subject: Re: Writing GUIs with an embedded OS
Date: Fri, 20 Jan 1995 11:25:57 GMT
From: werner@sunscipw.cern.ch (Per Werner)
Organization: CERN
Keywords: GUI
Message-ID: <D2pBrA.JDu@news.cern.ch>
References:  <3f6mso$q9l@bcarh8ab.bnr.ca>
Reply-To: werner@sunscipw.cern.ch (Per Werner)
Sender: news@news.cern.ch (USENET News System)

I have used Motif 1.1 from Microware for GUI application
which run on OS9, SunOS4.1.3 and ULTRIX 4.3.
Microware Motif/X11R4 is not bug free but it works OK.
Maybe Microware or someone else has a later port.
I used G++ 1.40 and wrote a small class library with
objects like Messsage, SelectionBox, FileSelectionBox,
Question, ScrolledText etc.

Hope this can help
Per  E. Werner
 
****************************************************************************
*                                                                          *
* Mail address : Per.Werner@cern.ch                                        *
* Telephone    : ++41 22 767  4932                                         *
* Organization : CERN - European Laboratory for Particle Physics           *
*                RD24 - ECP Division - Data Acquisition Systems Group      *
* RD24 WWW URL : http://www1.cern.ch/RD24                                  *
* SCI  WWW URL : http://www1.cern.ch/RD24 (is there another one ?)         *
* High Speed Interconnect (SCI, HIPPI, FiberChannel and ATM) -             *
*      WWW URL : http://www1.cern.ch/HSI                                   *
*                                                                          *
****************************************************************************

---------------------------

End of New-News digest
**********************

From sergi@hpbpq11.bpo.hp.com  Fri Jan 20 05:24:27 1995
From: Sergi Casas(QA Software testing) <sergi@hpbpq11.bpo.hp.com>
Date: Fri Jan 20 05:24:37 PST 1995
Subject: Re: Restarting a task
> 
> So the question is: How can the signal handler perform its processing, then
> instruct TASK A to restart at the point of waiting for the semaphore
> regardless of where in the code the task was "signaled" to stop?
> 
> Hey folks, any help would be appreciated!
> 
> 
> John R. Cobarruvias

	Look at "setjmp()", "longjmp()" mechanism in the vxWorks manuals. The
explanation is not very good there, but you can find these calls in any
standard C book.

	If you just don't return from the signal handler but rather jump into
step 3 with longjmp() ... it should work; I've never tried this, though.

Hope this helps.
-- 

|============================================================================|
| Sergi Casas                #####  /  ##### Firmware Engineer               |
| Hewlett-Packard Company    ###   /_  _ ###                                 |
| Barcelona Division (BCD)   ##   / / / / ## e-mail: sergi@hp-bpo.bpo.hp.com |
| Avda. Graells, 501         ##  / / /_/  ## Phone : +34 3 582 1475          |
| 08190 S. Cugat (Barcelona) ###    /    ### Fax   : +34 3 582 2515          |
| SPAIN                      ##### /   ##### HP-Telnet:    712 1475          |
|============================================================================|

From zot!Schilling.com!stevec@netcom.com  Fri Jan 20 08:11:33 1995
From: stevec@schilling.com (Steve Cohan)
Date: Fri Jan 20 08:11:40 PST 1995
Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
> We are looking for an off-the-shelf, MIL SPEC (883B), 68020/30/40,
> embedded system board for flight on a research satellite.

Radstone Technology has a line of MIL-STD-883 products, including an '020/'881
processor board.  I don't know if there are any other processor boards, but
there are other peripheral boards (memory, scsi, 1553, pwr supplies,...).
Contact:

Radstone Technology Corp.
20 Craig Rd.
Montvale, NJ  07645
800-368-2738

......................................................................
.								     .
. Steve Cohan                           Telerobotics for nuclear,    .
. Control Systems Engineer              subsea, and other hazardous  .
. Schilling Development, Inc.           environments                 .
.                                                                    .
.                                                                    .
. 1632 Da Vinci Court			tel   : 916 753 6718         .
. Davis, CA  95616			fax   : 916 753 8092         .
.					email : stevec@schilling.com .
.                                                                    .
......................................................................

From brwenholz@smtpgate.read.tasc.com  Fri Jan 20 08:19:46 1995
From: Bruce Wenholz <brwenholz@smtpgate.read.tasc.com>
Date: Fri Jan 20 08:19:53 PST 1995
Subject:  subscribe

From vilardebo@nrlvax.nrl.navy.mil  Fri Jan 20 09:02:04 1995
From: vilardebo@nrlvax.nrl.navy.mil
Date: Fri Jan 20 09:02:11 PST 1995
Subject: dual port (VME) memory on FORCE CPU-30 and CPU-40

I have been trying to figure out how to set up dual port memory on the 
FORCE CPU-30 and CPU-40.  I want to have 512K bytes of memory set for
VME access (dual ported).  I think this probably will require programming
the FGA and moving sysMemTop().  But I don't have much detail.

If anyone has an example in either C or Ada it would be greately
appreciated.  

I am using the GNU C/C++, VxWorks 5.1, Compilier and the TARTAN v4.3.1
Ada compilier for VxWorks.

Thanks
Ken Vilardebo
Mnemonics, Inc.

From mea@mclean.sparta.com  Fri Jan 20 09:14:11 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Jan 20 09:14:35 PST 1995
Subject: Re: Restarting a task at a specified location?
Greetings!

John R. Cobarruvias writes:

> 
> I have a task (TASK A) that does the following:
> 
> 1) spawned at initialization time
> 2) performs task specific one time only initialization (such as ties a
> Signal Handler to a RESET_SIGNAL)
> 3) Then waits on a semaphore
> 4) Upon getting the semaphore, performs its task
> 5) Gives up the semaphore
> 6) Goes to 3 (wait mode again)
> 
> But.....If the application receives a RESET interrupt, the ISR sends a
> signal to TASK A, if it is active (not waiting for the semaphore). The
> signal handler must then do the following:
> 
> 1) reset various parameters
> 2) then instruct TASK A to give up the semaphore, and then restart at 3
> above, which is to wait for the semaphore again.
> 
> 
> So the question is: How can the signal handler perform its processing, then
> instruct TASK A to restart at the point of waiting for the semaphore
> regardless of where in the code the task was "signaled" to stop?
> 
> Hey folks, any help would be appreciated!
> 

  Well, signal handlers work differently depending on which version of
VxWorks you're using.  First, a signal handler, when fired off, causes
an asynchronous change in the thread of control of the process the 
signal handler is associated with.  In plain English, this means that
a signal handler works a lot like an ISR in the sense that a task can be
running along, get a signal, jump to the signal handler and run the handler
and then return back to the original point in the task and continue 
execution.  Typically, signal handlers were used for error recovery but
they can be used for both interprocess communication and for "event"
notification.  VxWorks only supports a few of the standard BSD signals, but
you can write your own signal handling support for things such as the 
asynchronous I/O signal SIGIO as many of us in the VxWorks community 
already have.  

  Now, as to the differences in behavior between versions.  In 5.0.X, if
your task was blocked at a semTake and you got a signal, the signal handler
would only run when the task it was associated got resheduled.  That is, 
after the semTake completed/timed out.  Under 5.1.X, the signal handler
will run even if the task was blocked at the semTake.  Therefore, if you're
running under 5.1.X, then your problem is simple.  Just set your signal handler
up to reset your variables, do the semGive if necessary (or do a taskRestart 
and let your original code do it for you) and use setjmp/longjmp to "goto" 
a particular location in your original task (this is not necessary if you 
used taskRestart).  

If you're using 5.0.X, the problem is a little more complicated.  Your
ISR would have to send the signal and then do a semGive (make sure the 
semaphore is not a mutex variety 'cause those can't be given from 
interrupt level) so the signal handler would run.  Then have the signal
handler do the cleanups as outlined in the 5.1.X discussion. 

Hope this helps,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      
  

From vilardebo@nrlvax.nrl.navy.mil  Fri Jan 20 09:28:30 1995
From: vilardebo@nrlvax.nrl.navy.mil
Date: Fri Jan 20 09:28:36 PST 1995
Subject: Ada on VxWorks
Re:
	Original question from Matt Whiting whiting_ms@corning.com
about Ada on VxWorks.

	I have been using TARTAN Works V4.3.1 Ada compiler, it seems
to be a pretty well behaved product.  
	It runs on an unmodified VxWorks kernel (unlike VADS works).
	TARTAN is only up to 5.1 VxWorks currently.
	You can get information from
Glen Lawson
(813)724-3555
Fax:(813)726-8144
(813)724-1081
TARTAN, INC.
McCormic Dr.
Suite 103
Bldg 2651
Clearwater FL  34619

	So far I have gotten good support from both TARTAN and Wind River.

Ken Vilardebo
Mnemonics, Inc.

From mea@mclean.sparta.com  Fri Jan 20 09:31:16 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Jan 20 09:31:26 PST 1995
Subject: Re: Heurikon Nitro 60
Greetings!

> 
> Submitted-by stan@lassen.rti.com  Thu Jan 19 18:13:10 1995
> Submitted-by: stan@lassen.rti.com (Stan Schneider)
>  
> 
> Does anyone have any experience with the Nitro 60 board from Heurikon?
> 
>         -- Stan

  We were one of Heurikon's beta-test sites for the Nitro 60 (50 MHz 68060)
and we are now using the Nitro 60 in a couple of our production systems.  
I have to say that this thing is F-A-S-T!  It toasts our 33 MHz 68040s
by a factor of 3-4.  Our Nitro 60 also sports dual SCSI and dual Ethernets
via Heurikon's Corebus mezzanine bus.  Very nice :-).  We use them in
some custom 3-slot VME bus crates that we build into Sampsonite briefcases
and heat also does not seem to be a problem with these boards.  They also
support VME64 via the VIC64 interface.

  The VxWorks port is solid except for one minor problem.  That is that 
the tRdbTask for remote source debugging hasn't been ported yet for the 
'060.  Since my code doesn't have bugs, I haven't missed the debugger 
yet ;-).  I'm told that the 5.2 release will support the VxGDB debugger.  
In the mean time, you can still use the symbolic debugger and printf/logMsg 
calls.

HTH,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From Doug.Owens@quickmail.llnl.gov  Fri Jan 20 09:51:32 1995
From: "Doug Owens" <Doug.Owens@quickmail.llnl.gov>
Date: Fri Jan 20 09:51:39 PST 1995
Subject: Unsubscribe
                       Subject:                               Time:9:49 AM
  OFFICE MEMO          Unsubscribe                            Date:1/20/95

I was subscribed to the exploder for owens@lodtm.llnl.gov.  Please unsubscribe
- the system is gone and the mail is backing up.
Thanks
Doug Owens

From vilardebo@nrlvax.nrl.navy.mil  Fri Jan 20 10:21:00 1995
From: vilardebo@nrlvax.nrl.navy.mil
Date: Fri Jan 20 10:21:07 PST 1995
Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards

	General A-Tronics has a 68040 based board with a built in 1553,
	contact keith@gac.usa.com

Ken Vilardebo
Mnemonics, Inc.

From stan@lassen.rti.com  Fri Jan 20 14:31:55 1995
From: stan@lassen.rti.com (Stan Schneider)
Date: Fri Jan 20 14:32:01 PST 1995
Subject: Rom emulators

Does anyone out there have experience with ROM emulators (good or bad)?  Anyone
using XLNT system's products?

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From satish@ltis.loral.com  Fri Jan 20 16:43:15 1995
From: Satish Mali <satish@ltis.loral.com>
Date: Fri Jan 20 16:43:21 PST 1995
Subject: Re: Rom emulators

Excellent. I highly recommend them. Even though the price may look a little
steep at the beginning, the time it saves is worth it.

Thanks
-satish

********************************************************************************
* Satish Mali                            email : satish@ltis.loral.com         *
*               I speak only for myself and not for my employer                *
********************************************************************************

From daemon@vxw.ee.lbl.gov  Sat Jan 21 04:00:27 1995
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 21 04:00:35 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 21 04:00:17 PST 1995

        Subject: Fast SCSI disk write/read
        Subject: Re: Programming FLASH on the MV162
        Subject: re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
        Subject: What happened to Telesystems SLW ?
        Subject: VxSim
        Subject: Re: VxSim

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Fast SCSI disk write/read
Date: Fri, 20 Jan 1995 10:12:41 GMT
From: pbiereic@eso.org (Peter Biereichel)
Organization: ESO - European Southern Observatory, Garching by Munich
Message-ID: <1995Jan20.101241.25243@eso.org>
Sender: news@eso.org

Does anyone know about a SCSI library/driver for fastest possible
data transfer to a SCSI disk? A file system is not needed.
We just want to dump data in "burst mode".

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Peter Biereichel       pbiereic@te1.hq.eso.org        ph: ++49  89-32006-266
ESO, European Southern Observatory                    fax:++49  89-3202362
Karl-Schwarzschild-Str.2, D-85748 Garching, GERMANY
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Programming FLASH on the MV162
Date: Fri, 20 Jan 1995 14:10:54 +0000
From: anj@mail.ast.cam.ac.uk (Andrew Johnson)
Organization: Royal Greenwich Observatory
Message-ID: <anj.234.01097319@mail.ast.cam.ac.uk>
References: <199501101734.KAA03798@xmission.xmission.com> <3fmcm1$1r9@hacgate2.hac.com>

In article <3fmcm1$1r9@hacgate2.hac.com> switt@triceratops.hac.com
(Steve Witt) writes:

>The trickiest part of the whole operation for me was to figure
>out how to configure TFTP on the Sun to allow the file transfer.
>This isn't explained in the VxWorks documentation (and I'm not
>saying it should be) but you need to modify the entry in /etc/inetd.conf
>for TFTP.  There is a directory on this line that is the directory
>from which your bootable image is TFTP'd.  

You should be careful about moving tftpd away from /tftpboot, and make sure 
that the directory you use or any of its subdirectories does not contain any 
confidential data. TFTP is not secure (it can't be by definition), so anyone 
with network access to your system will be able to read these files.

- - Andrew

          ,_}\_.        Andrew Johnson, Technology Division
         /      \       Royal Greenwich Observatory
~~~~~~~~| ,--/;. )~~~~  Madingley Road, Cambridge, UK
    .,  |/  (/  U       Phone: +44 (0)1223 374823
  .`., /_\ . .          Email: anj@mail.ast.cam.ac.uk
     wwWWWww'           WWW: http://cast0.ast.cam.ac.uk/~anj/

---------------------------

Newsgroups: comp.os.vxworks
Subject: re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
Date: 20 Jan 1995 16:37:08 GMT
From: msjl@ix.netcom.com (Mark Lambert)
Organization: Netcom
Message-ID: <3foork$jen@ixnews2.ix.netcom.com>
References: <9501201600.AA08954@Schilling.com>

> Radstone Technology has a line of MIL-STD-883 products, including an
> '020/'881 processor board.  I don't know if there are any other
> processor boards, but there are other peripheral boards (memory,
> scsi, 1553, pwr supplies,...).

Can I just clarify the processor question:
      `020, `030, `040 and i860 boards are currently available.
      PowerPC coming soon.

- -- 
Mark Lambert                               Radstone Technology Corp.,
Field Applications Engineer                3333 Bowers Avenue, Suite 130,
                                           Santa Clara, CA 95054
                      ++++++++++++++++++++++++++++++++++++++++++++++++++++
Tel: (408) 727-4585   +E-mail: lambert@radstone.co.uk                    +
Fax: (408) 727-4797   +       (NB. Please use this in preference to the  +
                      +            address in the header of this posting)+
                      ++++++++++++++++++++++++++++++++++++++++++++++++++++

---------------------------

Newsgroups: comp.os.vxworks,comp.dcom.lans.ethernet
Subject: What happened to Telesystems SLW ?
Date: 20 Jan 1995 19:04:19 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.95Jan20140419@oats.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

A few years back, we purchased a wireless ethernet bridge (ARLAN 620)
from Telesystems SLW, located at the time in Toronto, Canada. We've
been pretty happy with the equipment, and were thinking of getting
another unit for a new project - alas, they seem to have disappeared
from the face of the earth! Would anyone happen to know their fate? 

In looking for an alternative, I'd be interested in hearing what
people are using these days in the area of wireless networking. Any
recommendations? 

Thanks,

- -Henning

- --
Henning Pangels           |   hmp@cs.cmu.edu     |     Field Robotics Center
Senior Research Programmer|   (412) 268-8911     |Carnegie-Mellon University
- ----------------------------------------------------------------------------
                     Fast, Cheap, Good: Choose Any Two

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxSim
Date: Fri, 20 Jan 1995 20:04:54 GMT
From: heiple@ct.picker.com (HEIPLE, HOLLY)
Organization: Picker
Keywords: VxSim
Message-ID: <1995Jan20.200454.3862@picker.com>
Reply-To: heiple@ct.picker.com
Sender: news@picker.com

Does anybody have any experience using VxSim?  We are considering buying it based on the literature but I am wondering how much a developer would really use it.  Why not just use the target?  Any comments or words of wisdom?

Thanks,
Holly Heiple

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxSim
Date: Sat, 21 Jan 1995 02:48:26 GMT
From: marc@wrs.com (Marc Shepard)
Organization: Wind River Systems, Inc.
Keywords: VxSim
Message-ID: <D2qIGr.8v3@wrs.com>
References: <1995Jan20.200454.3862@picker.com>
Sender: news@wrs.com (News Manager)

In article <1995Jan20.200454.3862@picker.com> heiple@ct.picker.com writes:
>Does anybody have any experience using VxSim?  We are considering
>buying it based on the literature but I am wondering how much a developer
>would really use it.  Why not just use the target?  Any comments or words
>of wisdom?

I use it all the time here at WRS to prototype new code.
You don't have to scrounge for hardware in order to test your code.
You can call "PRINTF" (which calls the underlying UNIX printf) anywhere
in your code, even exception handlers, ISRs (which are implemented as
UNIX signals), or context switch code.
Also, it's much faster to reboot than real hardware.

- -- 
                      ```
                     (o o)
- -----------------oOO--(_)--OOo--------------------
marc@wrs.com                         (510)814-2142

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sun Jan 22 04:00:50 1995
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 22 04:00:57 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 22 04:00:29 PST 1995

        Subject: Position available
        Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Position available
Date: Fri, 20 Jan 1995 12:38:28 GMT
From: dicicco@peb.com (Darrell S. DiCicco)
Organization: Princeton Electronic Billboard, Inc.
Keywords: image processing, real-time, video insertion
Message-ID: <9501200738.AA28526@Performa>
Reply-To: dicicco@peb.com (Darrell S. DiCicco)
Sender: news@nntpxfer.psi.com

									January 20, 1995

        Intended for posting on  the  real time users bulletin board.

         PEB is a fast growing Princeton based company applying computer 
vision and image processing to real-time advertising.   We have an immediate 
opening for  a software engineer/ programmer to join our team in developing 
the  next generation of our propriety live video insertion system (L-vis).  
	
	We are looking for a tenacious, goal-oriented, pro-active individual 
who works well within a team and delivers results on time.  Extensive 
knowledge of C/C++ required.  Familiarity with image processing techniques 
and/or real time systems necessary.  Knowledge of Solaris OS,  vxWorks and 
UNIX a plus.

	Competitive salary and comprehensive benefits offered.

	Send resume to  rjr@peb.com

         or  write/fax to:
         
          Roy Rosser
          PEB Inc.
	 47 Hulfish Street, Suite 500
          Princeton, NJ 08542

          (609) 924 9399
          (609) 924 0634

---------------------------

Newsgroups: comp.os.vxworks,comp.sys.m68k,alt.industrial.computing,sci.electronics,rec.radio.amateur.space
Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
Date: Sat, 21 Jan 1995 15:52:49 UNDEFINED
From: lacovara@ollie.jsc.nasa.gov (R. C. Lacovara)
Organization: GeoControl Systems, Incorporated
Message-ID: <lacovara.227.0078D738@ollie.jsc.nasa.gov>
References: <3fi0d6$hbr@CUBoulder.Colorado.EDU>

In article <3fi0d6$hbr@CUBoulder.Colorado.EDU> grusin@benji.Colorado.EDU (GRUSIN MICHAEL) writes:
>From: grusin@benji.Colorado.EDU (GRUSIN MICHAEL)
>Subject: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
>Date: 18 Jan 1995 03:03:02 GMT

>We are looking for an off-the-shelf, MIL SPEC (883B), 68020/30/40,
>embedded system board for flight on a research satellite.  If anyone
>has pointers to companies which supply such boards, I'd appreciate
>hearing about them! 

>Thanks, -Mike Grusin (grusin@rintintin.colorado.edu)

There are some possibilities. Try Radstone. Let me know if you find a good one.
R. C. Lacovara, Ph. D.
Engineer
GeoControl Systems            voice: 713 333 2561
1720 NASA Road 1              fax:   713 333 2966
Houston, Texas 77058

Texas is the largest and grandest State of the United States. It retains the right to fly its flag at the same height as that of the United States. Texas must not be abbreviated, like NJ or RI: NJ fits between Houston and San Antonio, with RI to spare. Al

---------------------------

End of New-News digest
**********************

From micf@lannet.com  Sun Jan 22 05:24:32 1995
From: micf@lannet.com (Michael Feldman)
Date: Sun Jan 22 05:24:38 PST 1995
Subject: vxWorks ports of ATM stuff
Hello,

I was wondering if anyone has information on the commercial ports of an ATM 
stuff (signalling, ILMI, etc.) to vxWorks. 
If anyone has any information on this board, could you respond by e-mail?

Thank you.

Michael Feldman, Lannet Data Communications, Israel

micf@lannet.com

From daemon@vxw.ee.lbl.gov  Mon Jan 23 04:00:25 1995
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 23 04:00:33 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 23 04:00:16 PST 1995

        Subject: IP multicast in VxWorks ???
        Subject: Re: Fast SCSI disk write/read

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: IP multicast in VxWorks ???
Date: Sun, 22 Jan 1995 14:21:01 GMT
From: segrest@bobseg.enet.dec.com ()
Organization: Me and only Me
Message-ID: <1995Jan22.142101.24919@datum.nyo.dec.com>
Reply-To: segrest@bobseg.enet.dec.com ()
Sender: usenet@datum.nyo.dec.com (USENET News System)

Greetings,

Has any work been done to provide IP multicast support in VxWorks ???

I am working with someone that needs to embed an application currently 
implemented with Solaris into a rom loaded VxWorks environment.

- -- 
Bob Segrest

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Fast SCSI disk write/read
Date: Sun, 22 Jan 1995 21:58:30 GMT
From: dat85715@indirect.com (D'Anne Thompson)
Organization: Internet Direct, indirect.com
Message-ID: <D2tuDJ.Fwn@indirect.com>
References:  <1995Jan20.101241.25243@eso.org>
Sender: dat85715@bud.indirect.com

>Does anyone know about a SCSI library/driver for fastest possible
>data transfer to a SCSI disk? A file system is not needed.
>We just want to dump data in "burst mode".
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Peter Biereichel       pbiereic@te1.hq.eso.org        ph: ++49  89-32006-266
>ESO, European Southern Observatory                    fax:++49  89-3202362
>Karl-Schwarzschild-Str.2, D-85748 Garching, GERMANY
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

SCSI data rates are physically limited by the hardware at both ends,
even more by the disk than the initiator cpu.  If you are asking about
software, then there really are only two choices I know of.

1. Stock VxWorks SCSI library.  You can call the library routines
scsiWrtSecs and scsiRdSecs directly to avoid any file system overhead.

2. Contact rtp.ltd.co.uk to get their upgraded SCSI library with full
SCSI-2 command tagging/queing support.  This REQUIRES a scsi-2
compliant disk that supports command tagging/queing.  Command
tagging/queing will help to reduce the software overhead in between
data segments, since multiple requests can be queued up at the hardware
level.

If you are asking about hardware, then the slowest element controls the
data rate.

Generic Asynch SCSI transfers - Max rate 5MB/sec
Synchronous SCSI-2 transfers - Max rate 10MB/sec
Wide Synch SCSI-2 transfers - Max rate 20MB/sec

All of the above are the hardware burst rates and do not include
software overhead.  As such the movement of data from user buffer to
disk device (or vice versa) will be slower than the stated values.

The only company I know of that can provide you with an SBC solution
with a Wide Synchronous SCSI interface onboard is Synergy Microsystems.
 We have a VxWorks driver that works with the standard VxWorks SCSI
Library and provides a continuous sustained data rate of 16.9212 MB/sec
(average of both read/write) using the scsiRdSecs and scsiWrtSecs()
interface.  I work for Synergy.  Our sales office is at 619-452-0020. 

D'Anne Thompson
dat85715@indirect.com
dee@ioinc.tucson.az.us

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Mon Jan 23 16:21:02 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 23 16:21:09 PST 1995
Subject: WORM Drive Access
Greetings!

  Anyone out there in Netland have experience with WORM Drives and the 
raw filesystem?  What I need to do is to seek out someplace on the media,
write all of the data, then seek back to 0 to write a descriptor that tells
me where I got the data, date/time and how big it is, etc.  I'd like to
have the descriptor at a known location, but I can't write it a-priori
'cause I don't know beforehand how much data I'll grab on this pass of
the satellite.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      
 

From daemon@vxw.ee.lbl.gov  Tue Jan 24 04:00:30 1995
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 24 04:00:39 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 24 04:00:20 PST 1995

        Subject: Re: Restarting a task at a specified location?
        Subject: Re: IP multicast in VxWorks ???
        Subject: Re: What happened to Telesystems SLW ?
        Subject: Re: VxSim
        Subject: Re: dual port (VME) memory on FORCE CPU-30 and CPU-40
        Subject: Re: Rom emulators
        Subject: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Restarting a task at a specified location?
Date: 23 Jan 1995 16:15:58 GMT
From: johncoby@blkbox.com (John Cobarruvias)
Organization: The Black Box, Houston, Tx (713) 480-2686 
Message-ID: <3g0knu$i5k@news.blkbox.com>
References: <cobarruvias-190195154109@ekm085.jsc.nasa.gov>

John R. Cobarruvias (cobarruvias@asd1.jsc.nasa.gov) wrote:

I HAVE INCLUDED THE ANSWER TO MY QUESTION BELOW:

> Bear with me folks, I am trying to understand someone elses design and code
> from it.........(and worst of all, the designer is no longer in the
> area......)

> I have a task (TASK A) that does the following:

> 1) spawned at initialization time
> 2) performs task specific one time only initialization (such as ties a
> Signal Handler to a RESET_SIGNAL)
> 3) Then waits on a semaphore
> 4) Upon getting the semaphore, performs its task
> 5) Gives up the semaphore
> 6) Goes to 3 (wait mode again)

> But.....If the application receives a RESET interrupt, the ISR sends a
> signal to TASK A, if it is active (not waiting for the semaphore). The
> signal handler must then do the following:

> 1) reset various parameters
> 2) then instruct TASK A to give up the semaphore, and then restart at 3
> above, which is to wait for the semaphore again.

> So the question is: How can the signal handler perform its processing, then
> instruct TASK A to restart at the point of waiting for the semaphore
> regardless of where in the code the task was "signaled" to stop?

> Hey folks, any help would be appreciated!

The signal handler runs in the tasks context, so if you want the task
to give the semaphore, just have the tasks signal handler do the
semGive.

To get the task to sync up again, use longjmp. The following psuedo
code
is the idea (although I am typing it now, so it probably has lot's of
problems - but it is the right idea):

SEM_ID semId;
jmp_buf jmpBuf;

taskA ()
   {
   intialize();

   signal (signo, handler);     /* actually, sigaction is better */

   setjmp (jmpBuf);

   for (;;)
       {
       semTake(semId, WAIT_FOREVER);
       doStuff();
       semGive (semId);
       }
   }

handler ()
    {
    semGive (semId);
    longjmp (jmpBuf, 1);
    }

THANKS TO: marc@wrs.com

> John R. Cobarruvias

- --
John R. Cobarruvias
Still trying to put together a sig file.........

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: IP multicast in VxWorks ???
Date: 23 Jan 1995 10:38:01 -0700
From: krussell@xmission.com (Kevin Russell)
Organization: XMission Public Access Internet (801-539-0900)
Message-ID: <3g0php$7c1@xmission.xmission.com>
References: <1995Jan22.142101.24919@datum.nyo.dec.com>

I implemented IP multicast in 5.1.1.  I basically took the net sources 
from Wind River and merged it with the bsd sources from Steve Deering, 
the author of the Multicast RFC.  His code is available via FTP from 
gregorio.standford.edu as vmtp-ip/ipmulticast.tar.Z.  It took only about 
two days to implement the protocol level stuff.  The hardware filtering 
requirements can be implemented if desired without a lot of additional 
effort at the driver level.  I did not implement the multicast routing 
features.

Kevin Russell
801-977-1638

segrest@bobseg.enet.dec.com wrote:

: Greetings,

: Has any work been done to provide IP multicast support in VxWorks ???

: I am working with someone that needs to embed an application currently 
: implemented with Solaris into a rom loaded VxWorks environment.

: -- 
: Bob Segrest

---------------------------

Newsgroups: comp.os.vxworks,comp.dcom.lans.ethernet
Subject: Re: What happened to Telesystems SLW ?
Date: 23 Jan 1995 19:22:40 GMT
From: nelson@crynwr.crynwr.com (Russell Nelson)
Organization: Crynwr Software
Message-ID: <NELSON.95Jan23142240@crynwr.crynwr.com>
References: <HMP.95Jan20140419@oats.frc.ri.cmu.edu>

In article <HMP.95Jan20140419@oats.frc.ri.cmu.edu> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:

   A few years back, we purchased a wireless ethernet bridge (ARLAN 620)
   from Telesystems SLW, located at the time in Toronto, Canada. We've
   been pretty happy with the equipment, and were thinking of getting
   another unit for a new project - alas, they seem to have disappeared
   from the face of the earth! Would anyone happen to know their fate? 

They got bought out by Telxon, in Akron Ohio USA, and they've moved to
Markham ONT.  Their phone number is +1-905-475-7171.  They say they
have no email address.

- --
- -russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress?

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxSim
Date: 23 Jan 95 08:45:28 -0500
From: whiting_ms@corning.com (whiting_ms@corning.com (Matt Whiting))
Organization: Corning Incorporated
Message-ID: <1995Jan23.084528.1@corning.com>
References: <1995Jan20.200454.3862@picker.com>

In article <1995Jan20.200454.3862@picker.com>, heiple@ct.picker.com (HEIPLE, HOLLY) writes:
> Does anybody have any experience using VxSim?  We are considering buying it
> based on the literature but I am wondering how much a developer would really
> use it.  Why not just use the target?  Any comments or words of wisdom?
> 
> Thanks,
> Holly Heiple
> 
> 
> 
- -- 

We tried to use it recently during an evaluation of VxWorks, but found that it
doesn't run under Solaris.  This is documented in the release notes, but we
didn't notice that and our sales guy knew we had Solaris and failed to mention
it either.  So just be sure that you have SunOS if you do plan to use VxSIM.

Just using the target is OK assuming you have a target!  We'd planned to use
VxSIM as our target system was on back order.  It could also be advantageous if
you wanted to do development at multiple sites and each site didn't have a
target sytem available.

- -------------------------------------------------------------------------------
Matthew S. Whiting, P.E. | Corning Incorporated  | (607) 974-6317 phone
Sr. Project Engineer     | HP-ME-03-073          | (607) 974-6752 fax
whiting_ms@corning.com   | Corning, NY 14831     |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: dual port (VME) memory on FORCE CPU-30 and CPU-40
Date: 23 Jan 1995 19:35:37 GMT
From: Shash Chatterjee <ChatterjeeS@esdi.lfwc.lockheed.com>
Organization: Lockheed Missiles and Space Co.
Message-ID: <3g10e9$o92@butch.lmsc.lockheed.com>
References: <0098ABE6.0DE10C20.36@nrlvax.nrl.navy.mil>

vilardebo@nrlvax.nrl.navy.mil wrote:
>
> 
> I have been trying to figure out how to set up dual port memory on the 
> FORCE CPU-30 and CPU-40.  I want to have 512K bytes of memory set for
> VME access (dual ported).  I think this probably will require programming
> the FGA and moving sysMemTop().  But I don't have much detail.
> 
> If anyone has an example in either C or Ada it would be greately
> appreciated.  
> 
> I am using the GNU C/C++, VxWorks 5.1, Compilier and the TARTAN v4.3.1
> Ada compilier for VxWorks.
> 
> Thanks
> Ken Vilardebo
> Mnemonics, Inc.

There's not much to this.  First, make sure that dual-port RAM
is enabled.  The as-supplied BSP for VxWorks 5.1.1/CPU-30 enables
DPR only for processor 0.  Look in sysProcNumSet() in 
$(VW)/config/frc30/sysLib.c, and you'll see:

    /* enable dual porting of memory.  It is disabled in sysHwInit() */

    *FGA_ENAMCODE  = FGA_ENAMCODE_EXTUSRDAT_RW | FGA_ENAMCODE_EXTSUPDAT_RW;

Make sure that you move it outside the "if (procnum == 0) {} " block.
The config.h file defines a macro "LOCAL_MEM_BUS_ADRS", which turns
out to be 16M per processor starting at 0x1000000 (ie, the first
processor is at 0x1000000, the second is at 0x2000000, etc).  The
same goes for the CPU-40.  One thing to note, by default
only EXTENDED (A32D32) Supervisory Data accesses are allowed.

That's all there is to it.

Hope this helps.

+-----------------------------------------------------------------+
+ INTERNET (SMTP): ChatterjeeS@lfwc.lockheed.com                  +
+ LFWC     (SMTP): ChatterjeeS@esdi (ChatterjeeS@[134.189.222.82])+
+ LFWC   (MSMAIL): Sasvata.Chatterjee (CHTTRS)                    +
+-----------------------------------------------------------------+
+ Shash Chatterjee                                                +
+ Electronic Systems Design & Integration                         +
+ Lockheed Fort Worth Company                                     +
+ P.O. Box 748, MZ2273           VOICE/VOICE-MAIL: (817) 763-1495 +
+ Ft. Worth, TX 76101                         FAX: (817) 777-2115 +
+-----------------------------------------------------------------+

Shash

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Rom emulators
Date: Tue, 24 Jan 1995 01:24:31 GMT
From: dana@wrs.com (Dana Burd)
Organization: Wind River Systems
Message-ID: <D2vyKy.2A6@wrs.com>
References: <9501201943.AA01518@lassen>
Reply-To: dana@wrs.com
Sender: news@wrs.com (News Manager)

> Does anyone out there have experience with ROM emulators (good or bad)?  Anyone
> using XLNT system's products?

We have a couple of netROMs from XLNT around WRS.... excellent sums it up.
They are invaluable when doing a BSP...  For debugging particularly
sensisitive code, the communication channel (from target to host) works
well.  I hear that XLNT even has a VxWorks network driver that
capitalizes on this feature, although it does not offer great bandwidth
(someone mentioned ~40kB/sec, but don't quote me on that...).

Cannot say whether it is worth the $$$ (I didn't shell out for it), but
it has saved me serious amounts of time...

- -Dana

+--------------------------------------------------------------+
| Dana Burd                           Wind River Systems, Inc. |
| Software Development Engineer       1010 Atlantic Avenue     | 
| dana@wrs.com                        Alameda, CA 94501        | 
+--------------------------------------------------------------+

---------------------------

Newsgroups: comp.os.vxworks
Subject: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
Date: 24 Jan 1995 10:18:21 GMT
From: pete@fof.nft.no (Pete J Story)
Organization: nft
Message-ID: <3g2k5d$irt@nftdf.fof.nft.no>
Sender: pete@nftdf (Pete J Story)

I am using sockets on vxworks.  Occasionally I get a failure indication
from write(2), and errno is then set to the magic number 0x3d0002, which
most vxworks users will recognise from a task listing.  This number comes
from objLib, and means "S_objLib_OBJ_UNAVAILABLE".  But what does it 
mean in terms of my write call?  Has it worked, or has it not?  If not,
what am I supposed to do about it?
 
Any ideas?
 
pete@fof.nft.no
 
PS, this is an *old* vxworks, 5.0.2b on sparc.  I can't upgrade, because
it is really vadsworks (for Ada) and there is no newer version for Ada 
usage.

---------------------------

End of New-News digest
**********************

From sergi@hpbpq11.bpo.hp.com  Tue Jan 24 05:55:54 1995
From: Sergi Casas(QA Software testing) <sergi@hpbpq11.bpo.hp.com>
Date: Tue Jan 24 05:56:01 PST 1995
Subject: Re: comp.os.vxworks newsdigest
> In article <1995Jan20.200454.3862@picker.com>, heiple@ct.picker.com (HEIPLE, HOLLY) writes:
> > Does anybody have any experience using VxSim?  We are considering buying it
> > based on the literature but I am wondering how much a developer would really
> > use it.  Why not just use the target?  Any comments or words of wisdom?
> > 
> > Thanks,
> > Holly Heiple
> > 
> > 
> > 
> - -- 
> 
> We tried to use it recently during an evaluation of VxWorks, but found that it
> doesn't run under Solaris.  This is documented in the release notes, but we
> didn't notice that and our sales guy knew we had Solaris and failed to mention
> it either.  So just be sure that you have SunOS if you do plan to use VxSIM.

	It works also pretty smooth on HP-UX 9.0 over Apollo 700 machines 
(PA-RISC).

	It is a quite comfortable development environment, specially for
prototyping code before you have any real target. The only important tool it
lacks is vxGdb: currently the only debugger is the standard HP-UX one, say
"xdb". It just doesn't know anything on tasks nor windKernel structures, but
in the first stages of code development it is usually enough.

	One alternative is to use evaluation boards of your target processor
with ethernet connexion. It is quite fast (rebooting vxSim is almost immediate)
and you have a real vxWorks with all the tools. It is usually much more
expensive because each board (or target) allows only one engineer working at
a time, so you'll often need to have more than one board (or target). We here 
use both approaches depending on the phase of the project and the kind of bugs 
we are looking for.

-- 

|============================================================================|
| Sergi Casas                #####  /  ##### Firmware Engineer               |
| Hewlett-Packard Company    ###   /_  _ ###                                 |
| Barcelona Division (BCD)   ##   / / / / ## e-mail: sergi@hp-bpo.bpo.hp.com |
| Avda. Graells, 501         ##  / / /_/  ## Phone : +34 3 582 1475          |
| 08190 S. Cugat (Barcelona) ###    /    ### Fax   : +34 3 582 2515          |
| SPAIN                      ##### /   ##### HP-Telnet:    712 1475          |
|============================================================================|

From jeffs@wrs.com  Tue Jan 24 14:46:27 1995
From: Jeff Steinley <jeffs@wrs.com>
Date: Tue Jan 24 14:46:33 PST 1995
Subject: EPC-7 & INDY 500 BSPs?
Greetings.

Has anyone created the VxWorks Board Support Package s/w for either of the
following boards/workstations:

1) EPC-7 board from Radisys Corporation
    (80486-Based PC compatible VXIbus System Controller board)

2) Indy 500 workstation from Silicon Graphics (or similiar SGI workstation)

Any information regarding the above BSPs would be greatly appreciated.

Thanks,
Jeff

+-----------------------------------------------------------+
|  Jeff Steinley                    Phone: (214) 386-8592   |
|  Field Application Engineer       Fax  : (214) 386-8594   |
|  Wind River Systems, Inc.         Email: jeffs@wrs.com    |
|                                                           |
|  Mailing Address: 4201 Spring Valley Road, Suite 1400     |
|                   Dallas, TX    75244                     |
+-----------------------------------------------------------+

From mumcu@venus.aselsan.com.tr  Tue Jan 24 23:37:44 1995
From: Ahmet MUMCU <mumcu@venus.aselsan.com.tr>
Date: Tue Jan 24 23:37:51 PST 1995
Subject: ADA Tools for vxworks
Does anyone have experience on the following ADA environments for vxworks?

- Verdix Vadsworks
- Tartan 
- Greenhill MULTI

Any positive or negative feedback on performance, environment, support
will be highly appreciated.

--------------------------------------------------------------------
- AHMET MUMCU
- ASELSAN INC.
- PO BOX 101 YENIMAHALLE
- ANKARA 06172 
- TURKEY
- 
- Fax: 90-312-3545205
- Tel: 90-312-3851900
- Email: mumcu@venus.aselsan.com.tr
--------------------------------------------------------------------

From daemon@vxw.ee.lbl.gov  Wed Jan 25 04:00:30 1995
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 25 04:00:38 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 25 04:00:16 PST 1995

        Subject: Re: Fast SCSI disk write/read
        Subject: Telneting to Non-Shell
        Subject: Re: Fast SCSI disk write/read
        Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
        Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Fast SCSI disk write/read
Date: Tue, 24 Jan 1995 19:17:26 GMT
From: dlenrow@world.std.com (David R Lenrow)
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <D2xC92.Ipw@world.std.com>
References: <1995Jan20.101241.25243@eso.org> <D2tuDJ.Fwn@indirect.com>

While D'Anne Thompson provided a nice low level discussion of the
limits on SCSI i/o, an important variable affecting throughput for vxworks
(or any) applications is the i/o buffering algorithm. Reading/Writing
multiples of SCSI block size, and coalescing adjacent I/O's can save any of:
	SCSI command exchanges
	SCSI arbitration cycles
	Head seeking/thrashing
	VME bus cycles
	VME interrupts
	i/o function call times
	etc.

Experiments timing a 1MB read/write request compared against 1MB worth
of small, misaligned, and discontiguous read/write requests may shock you.

Also, for recording of bursty realtime data, large i/o buffers can allow you to
exceed the peak rates of your i/o device if average throughput is managable.

You may need to change your application to behave optimally as a SCSI
client. I have previously implemented an i/o process which puts write
requests in a multi megabyte FIFO buffer and asynchronously calls write
for coalesced, aligned transfers. This setup allowed data with 4MB/sec.
peak rates rates to be written to a 1.5 MB/sec tape drive and could buffer
enough data to survive the tape drives head movement delay on startup 
(> 30 seconds). 

I think I know where you can buy source/binaries for a vxworks SCSI tape
driver with similar mods if interested. 

Good Luck.
- -drl

---------------------------

Newsgroups: comp.os.vxworks
Subject: Telneting to Non-Shell
Date: 24 Jan 1995 20:02:33 GMT
From: billag@b4pphff (Bill Gutknecht)
Organization: Bell-Northern Research
Message-ID: <3g3mcp$431@nrtphba6.bnr.ca>

	I'd like to remove the VxWorks shell for the production 
	version of my product, and replace it with a menu based
	system.  This seems to work well with devices connected
	to the console.

	I'd like to be able to telnet in as well ... but that 
	doesn't seem to automagically work (surprise surprise).
	It was my impression that telnetd changed the global 
	stdin/stdout/stderr to point to the pseudoterminal that
	telnetd is connected to, hence redirecting the shell.
	If that is so, why doesn't my menu get redirected?

	Am I totally off base here?  

	Any help would be greatly appreciated ... 

	Bill
	
- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
BNR/Northern Telecom             ask me 'What is the Riddle of Steel?'  If I 
Research Triangle Park, NC       do not know it, he will cast me out of 
billag@bnr.ca                    Valhalla and laugh at me ... "
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Fast SCSI disk write/read
Date: 24 Jan 1995 22:48:40 GMT
From: friedl@cher.heurikon.com (Ted Friedl)
Organization: Heurikon Corporation
Message-ID: <3g4048$367@zebu.heurikon.com>
References: <1995Jan20.101241.25243@eso.org> <D2tuDJ.Fwn@indirect.com>

[D'Anne Thompson writes...]
>2. Contact rtp.ltd.co.uk to get their upgraded SCSI library with full
>SCSI-2 command tagging/queing support.  This REQUIRES a scsi-2
>compliant disk that supports command tagging/queing.  Command
>tagging/queing will help to reduce the software overhead in between
>data segments, since multiple requests can be queued up at the hardware
>level.

It should be said that command tagging/queuing is only useful in the
case when two or more independent tasks are sharing the same device.
For a single task beating on a disk, command tagging/queuing is
nothing but overhead.

>The only company I know of that can provide you with an SBC solution
>with a Wide Synchronous SCSI interface onboard is Synergy Microsystems.
> We have a VxWorks driver that works with the standard VxWorks SCSI
>Library and provides a continuous sustained data rate of 16.9212 MB/sec
>(average of both read/write) using the scsiRdSecs and scsiWrtSecs()
>interface.  I work for Synergy.  Our sales office is at 619-452-0020. 

Heurikon provides 4 SBC solutions with VxWorks utilizing the NCR 53c720
wide/fast SCSI-DMA controller: the Nitro40 (68040-based), Nitro60
(68060-based), Laguna (MIPS R4000-based) and V960D (i960CF-based).
Each SBC, with VxWorks, can provide a continuous sustained data rate
of 20MB/sec (w/large data transfers) with local bus bandwidth
to spare.

Of course, most mechanical devices cannot sustain 20MB/sec but Heurikon
can recommend devices that use the SCSI bus efficiently so additive
throughput can be achieved.

Ted Friedl
Software Engineer
Heurikon Corporation

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
Date: Wed, 25 Jan 95 10:26:12 GMT
From: jpcalvez@ifremer.fr (Jean Pierre Calvez)
Organization: Ifremer
Message-ID: <1995Jan25.102612.11770@molene.ifremer.fr>
References: <3g2k5d$irt@nftdf.fof.nft.no>
Reply-To: jpcalvez@ifremer.fr
Sender: news@molene.ifremer.fr

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
Date: Wed, 25 Jan 95 10:30:59 GMT
From: jpcalvez@ifremer.fr (Jean Pierre Calvez)
Organization: Ifremer
Message-ID: <1995Jan25.103059.11948@molene.ifremer.fr>
References: <3g2k5d$irt@nftdf.fof.nft.no>
Reply-To: jpcalvez@ifremer.fr
Sender: news@molene.ifremer.fr

I encounter a similar phenomenon. I am testing a serial driver and get
S_objLib_OBJ_TIMEOUT during a read. This is not an error generated by the driver.
Has it to do with the system interface between user software and drivers?

I am working with the release 5.1.1 of vxworks on a MVME147 CPU board.

---------------------------

End of New-News digest
**********************

From lfoster@astro.ge.com  Wed Jan 25 05:00:27 1995
From: "Larry D. Foster" <lfoster@astro.ge.com>
Date: Wed Jan 25 05:00:35 PST 1995
Subject: qsort problem
Fellow VxWorks users,

We are experiencing an intermittent problem using the qsort function.  The 
routine that uses the qsort function is called during the start of our
application.  Sometimes (most of the time) our application starts without
any problem, but there are times that the qsort function call causes an error.
We get a "DATA ACCESS EXCEPTION..." and using trace we see that qsort is 
the problem.  We are using qsort after we add an entry to sorted (with qsort)
list; the entry is added at the bottom of the list.  One important fact here
is that the qsort has been called many times BEFORE we get the error.

In our attempts to find out what is happening, we looked (dumped) at the 
memory used for the list that we're sorting.  We see that the qsort call
has worked (the list is sorted), but one of the entries has been truncated.
We are sorting based on an ASCII string and when the entry gets truncated, 
the sorting is no longer correct (ie. we have one entry out of place).

While we're not sure that the truncated entry is the problem, we're fairly
certain that the qsort function is the root of our problem.  We would 
appreciate any comments about this problem as well as hearing about other
user's experience with the qsort function.

Thanks, Larry

Larry Foster		Phone: (609) 490-7063
Martin Marietta		email: lfoster@ge.astro.com
Princeton, NJ

From crispen@eight-ball.hv.boeing.com  Wed Jan 25 07:23:02 1995
From: crispen@eight-ball.hv.boeing.com (Bob Crispen)
Date: Wed Jan 25 07:23:09 PST 1995
Subject: Re: ADA Tools for vxworks
Ahmet MUMCU <mumcu@venus.aselsan.com.tr> asks:
 
>Does anyone have experience on the following ADA environments for vxworks?
>
>- Verdix Vadsworks
>- Tartan 
>- Greenhill MULTI
>
>Any positive or negative feedback on performance, environment, support
>will be highly appreciated.

Dunno about ADA (American Dental Association?) but I've used the
VADSWorks Ada for years.  Like it.  Pretty near bulletproof.  The
only negative I can think of is that some time ago they distributed
a lovely floating point math package for the 020/030, but it seems
to have disappeared and been replaced by calls to libm.a routines.
Hunt down that old math package.

I hear tell that Verdix (now Rational) and Wind River have worked
things out so that not a speck of VxWorks code has to be changed
for VADSWorks; VADSWorks will now run seamlessly on top of VxWorks,
which is good news since us Ada folks always seemed to be at least one
generation behind C folks in what we could do in the operating system.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |    668: The neighbor of the Beast    |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

From greg@eng.nmr.varian.com  Wed Jan 25 10:00:00 1995
From: greg@eng.nmr.varian.com (Greg Brissey x6951)
Date: Wed Jan 25 10:00:07 PST 1995
Subject: Slip/PPP 
Dear vxPerts,

I am look for anyone with experience in using slip and/or ppp
between a SUN 4.1.3 or 2.4 and vxWorks 5.1.1 target.

I have slip working but it is painfully slow :(,
are there any ways of speeding it ?  (if so how?)

Would ppp be faster and/or better solution.
I have a copy of ppp 1.3 for vxWorks.
Where do I get a copy of ppp for the SUN 4.1.3 ?

Any suggestion or comments would be greatly appreciated.

Thanks in Advance,

Greg Brissey
greg.brissey@nmr.varian.com

From stan@lassen.rti.com  Wed Jan 25 17:01:46 1995
From: stan@lassen.rti.com (Stan Schneider)
Date: Wed Jan 25 17:01:53 PST 1995
Subject: Re: Telneting to Non-Shell

Hi Bill,

>>	I'd like to remove the VxWorks shell for the production 
>>	version of my product, and replace it with a menu based
>>	system.  This seems to work well with devices connected
>>	to the console.

>>	I'd like to be able to telnet in as well ... but that 
>>	doesn't seem to automagically work (surprise surprise).
>>	It was my impression that telnetd changed the global 
>>	stdin/stdout/stderr to point to the pseudoterminal that
>>	telnetd is connected to, hence redirecting the shell.
>>	If that is so, why doesn't my menu get redirected?

>>	Am I totally off base here?  

This is what rshell does:

    ioTaskStdSet(0, 0, sd);
    ioTaskStdSet(0, 1, sd);
    ioTaskStdSet(0, 2, sd);

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From daemon@vxw.ee.lbl.gov  Thu Jan 26 04:00:30 1995
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 26 04:00:39 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 26 04:00:20 PST 1995

        Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
        Subject: Re: What happened to Telesystems SLW ?
        Subject: GUI solution for VxWorks
        Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABL
        Subject: Network Interface Ethernet COntrollers
        Subject: DCE on vxWorks?
        Subject: Re: Fast SCSI disk write/read
        Subject: Re: ADA Tools for vxworks
        Subject: Re: Host Linux

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?
Date: Wed, 25 Jan 95 11:39:05 GMT
From: jpcalvez@ifremer.fr (Jean Pierre Calvez)
Organization: Ifremer
Message-ID: <1995Jan25.113905.15162@molene.ifremer.fr>
References: <3g2k5d$irt@nftdf.fof.nft.no>
Reply-To: jpcalvez@ifremer.fr
Sender: news@molene.ifremer.fr

A correction to my precedent post. My error was due to a timeout occuring on a 
semaphore in the driver.

Errors on semaphore cause messages of the kind: "S_objLib_XXXXX".
I have constated this on version 5.0.1 and version 5.1.1.

---------------------------

Newsgroups: comp.os.vxworks,comp.dcom.lans.ethernet
Subject: Re: What happened to Telesystems SLW ?
Date: Wed, 25 Jan 1995 15:37:21 GMT
From: ramey@gnat.den.mmc.com (Mat Ramey)
Organization: Martin Marietta Astronautics, Denver
Message-ID: <RAMEY.95Jan25083721@gnat.den.mmc.com>
References: <HMP.95Jan20140419@oats.frc.ri.cmu.edu>
Sender: news@news2.den.mmc.com (News Admin)

In article <HMP.95Jan20140419@oats.frc.ri.cmu.edu> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:

> A few years back, we purchased a wireless ethernet bridge (ARLAN 620)
> from Telesystems SLW, located at the time in Toronto, Canada. We've
> been pretty happy with the equipment, and were thinking of getting
> another unit for a new project - alas, they seem to have disappeared
> from the face of the earth! Would anyone happen to know their fate? 

We recently bought an ARLAN 620 ourselves ... I have the following for their
new address:

	Telesystems SLW
	85 Scarsdale Road, Suite 201
	Don Mills, Ontario, Canada
	(905) 475-7171

> In looking for an alternative, I'd be interested in hearing what
> people are using these days in the area of wireless networking. Any
> recommendations? 

I had seriously considered buying Proxim's RangeLan2 Ethernet Bridge.  It is a
2.4 GHz spread-spectrum device vs. Arlan's 928 Mhz spread-spectrum, and it was
also less expensive at the time; however, it was still under Beta-testing at
the time (about 1 yr ago?) ... maybe they're ready to go by now!

	Proxim Inc.
	295 North Barnardo Ave.
	Mountain View, CA  94043
	tel: (415) 960-1630 or (800) 229-1630
	fax: 415.964.5181

Also, some notes I had once extracted from the comp.sys.robotics FAQ:

	Motorola Radio-Telephone Systems Group, Arlington Heights, ILL
	tel: 708.632.5000
	  AltairNet: 18GHz-based system design for wireless, indoors
	  networking.  The boxes are fairly large, about the size of a
	  shoebox, and are relocatable but not portable. Problem is that is
	  really isn't for mobile applications.  Area is really like swiss
	  cheese. Not a problem for fine adjustment in stationary applications
	  but a big problem for mobile devices.
	[I talked to: Koz Geiss @ 708.576.8216]

	NCR sells the WaveLAN, which has about a 1Mbit/sec data rate.  Not
	exactly "ethernet", but interfaceable to most networks using MS-DOS
	boxes as routers.

	Tetherlink in California is experimenting with a 2Mbit/sec cellular
	system that is designed for roving portables. [Need address]
	
	Cylink
	310 N. Mary Avenue
	Sunnyvale, CA 94086
	tel: 408.735.5800
	fax: 408.735.6643
	  AirLink - series of highspeed synch or async modems to 256kb/s.
	Interfaces include V.11, RS-232, EIA-530. Spread spectrum device
	operating in 902-928Mhz range.
	
- -- 

 Mat Ramey          	     Martin Marietta Astronautics
 ramey@den.mmc.com	     P.O. Box 179 Mail Stop 4372  ,,,
 ph: 303-977-4339	     Denver, Colorado  80201     (- -)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~oOOo~(_)~oOOo~~

---------------------------

Newsgroups: comp.os.vxworks
Subject: GUI solution for VxWorks
Date: 25 Jan 1995 18:09:19 GMT
From: stevet@an.hp.com (Steve Toro)
Organization: Hewlett Packard Andover Site
Message-ID: <3g644f$r8o@hpaneqb4.an.hp.com>

	I am looking for a Graphical User Interface solution for VxWorks that
is not VxWindows (that is, not based on X/Motif), but provides
the primitives for building a GUI and takes less resources (memory and CPU).
Does any one know about 3rd parties that have ported something like
GFX or Metawindows or something similar into VxWorks?  
I am very interested to know about this.  Thank you in advance for your help.

Regards,

Steve

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks, errno=0x3d0002, OBJ_UNAVAILABL
Date: 25 Jan 1995 18:24:43 GMT
From: bonaker@amasd.anatcp.rockwell.com (Joe Bonaker)
Organization: Rockwell
Message-ID: <3g651b$2b0@huron.eel.ufl.edu>
References: <1995Jan25.113905.15162@molene.ifremer.fr>
Reply-To: bonaker@amasd.anatcp.rockwell.com

pete@fof.nft.no (Pete J Story) writes:

>I am using sockets on vxworks.  Occasionally I get a failure indication
>from write(2), and errno is then set to the magic number 0x3d0002, which
>most vxworks users will recognise from a task listing.  This number comes
>from objLib, and means "S_objLib_OBJ_UNAVAILABLE".  But what does it 
>mean in terms of my write call?  Has it worked, or has it not?  If not,
>what am I supposed to do about it?

jpcalvez@ifremer.fr (Jean Pierre Calvez) responds:

>I encounter a similar phenomenon. I am testing a serial driver and get
>S_objLib_OBJ_TIMEOUT during a read. This is not an error generated by the driver.
>Has it to do with the system interface between user software and drivers?

[Next post....]

>A correction to my precedent post. My error was due to a timeout occuring on a 
>semaphore in the driver.
>
>Errors on semaphore cause messages of the kind: "S_objLib_XXXXX".
>I have constated this on version 5.0.1 and version 5.1.1.

This example illustrates one of my frustrations with VxWorks'
well-intended, module-level descriptive errnos:  "too much of a good
thing," as the underlying, inter-task objects' errors are propogated to
callers.  This works great in the simple case where each error results
in perror() printouts to reveal the root of the problem.  But in cases
where some errors are considered "soft," e.g., timeouts or NO_WAIT
contention, this approach burdens the driver/library service provider
(or more likely, its users) with enumeration of all possible
descriptive errors.  In general, the VxWorks man pages are remiss in
defining errnos and associated conditions.   The driver or library
developer must "hunt and peck" to determine exactly what errnos are
generated by the underlying semaphore/queue objects under certain
failure scenarios, else propogate these undocumented errors to the
users.

We developed a serial driver which sat on a mutual exlusion semaphore.
A non-blocking read/write operation's semTake(2) errnos had to be
caught by the driver and mapped into more conventional EWOULDBLOCK or
EIO errnos to allow the driver user to take appropriate action based on
the errno.  Based on available VxWorks documentation, our driver
developer had no idea that S_objLib_OBJ_UNAVAILABLE would be the errno
resultant from a NO_WAIT semTake() when the sempaphore was busy.
Fortunately, the VxWorks shell made it fairly painless to stimulate the
semaphore busy condition and discover the resultant errno.

Guess I'm lobbying for better enumeration and description of errnos in
the VxWorks man pages.  This would allow a driver/library developer
the option of propogating errnos or mapping them to more conventional,
Unix errnos.

Joe B.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Network Interface Ethernet COntrollers
Date: 25 Jan 1995 18:54:23 GMT
From: jorge@b4pph131.bnr.ca (Jorge Rodriguez contractor)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <3g66ov$438@brtph500.bnr.ca>

I am interested  in any suggestions for  Ethernet Controllers
used with a Vxworks based system.  I am in the process of 
identifying possible controllers for my system and would like to hear
suggestions from previous experience.

Any comments would be greatly appreciated, specially 
 advantages/disadvantages of a particular controller.

Anxiously awaiting,

   Jorge Rodriguez           
   Bell Northern Research        
   (919) 991-4638              
   Email:Jorge@bnr.ca     

---------------------------

Newsgroups: comp.os.vxworks
Subject: DCE on vxWorks?
Date: Tue, 24 Jan 95 11:53:58 PDT
From: Miller_DF@Corning.com
Message-ID: <1995Jan24.115551.715@corning.com>

The version of vxWorks which we are using currently supports the Sun version
of remote procedure calls.  Is anyone aware of a version of vxWorks which 
supports OSF DCE remote procedure calls?

Thanks.
Don Miller
Corning, Inc.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Fast SCSI disk write/read
Date: 25 Jan 1995 16:46:32 -0600
From: buchele@arlut.utexas.edu (Steven Buchele)
Organization: Applied Research Labs - The University of Texas at Austin
Keywords: SCSI
Message-ID: <3g6kc8$k7a@csdsun1.arlut.utexas.edu>
References: <1995Jan20.101241.25243@eso.org> <D2tuDJ.Fwn@indirect.com> <3g4048$367@zebu.heurikon.com>
Sender: Steven W. Buchele

>Heurikon provides 4 SBC solutions with VxWorks utilizing the NCR 53c720
>wide/fast SCSI-DMA controller: the Nitro40 (68040-based), Nitro60
>(68060-based), Laguna (MIPS R4000-based) and V960D (i960CF-based).
>Each SBC, with VxWorks, can provide a continuous sustained data rate
>of 20MB/sec (w/large data transfers) with local bus bandwidth
>to spare.
>
>Of course, most mechanical devices cannot sustain 20MB/sec but Heurikon
>can recommend devices that use the SCSI bus efficiently so additive
>throughput can be achieved.
>
>Ted Friedl
>Software Engineer
>Heurikon Corporation

Yes, but you need to drive the software drivers from AP Labs.  The
drivers that Heurikon supplys are from VxWorks 5.02 and won't work
with any release later (such as the current 5.1.1 or 5.2).

Using
  Heurikon 4220 Cougar board
  VxWorks on a MV167:33MHz
  AP Labs aio software driver
  Seagate 2GB Baraccuda

we have seen raw file system performance in the range of 4.7MB/sec
(using 1MB buffers).

BTW The Heurikon + AP Labs combo has been quite easy to configure and
get going.

Steven Buchele
Applied Research Labs
Austin, Texas

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: ADA Tools for vxworks
Date: 25 Jan 1995 22:46:03 GMT
From: djohnson@space.honeywell.com (David Johnson)
Organization: Honeywell, Inc.
Message-ID: <djohnson-2501951753390001@130.181.9.248>
References: <9501250737.AA05575@lbl.gov>

In article <9501250737.AA05575@lbl.gov>, Ahmet MUMCU
<mumcu@venus.aselsan.com.tr> wrote:

> Does anyone have experience on the following ADA environments for vxworks?
> 
> - Verdix Vadsworks
> - Tartan 
> - Greenhill MULTI
> 
Honeywell Space Systems of Clearwater Florida has used the Vadsworks
environment and Ada for several aerospace projects.  To start with, I
would send an email to Thomas Smith "smith@space.honeywell.com".  Tom will
either know the answer or be able to point you in the right direction.

David Johnson "djohnson@space.honeywell.com"

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Host Linux
Date: Thu, 26 Jan 1995 00:58:24 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD2zMpD.Hsr@netcom.com>
References: <gerlachD2z00u.JCu@netcom.com>

In article <gerlachD2z00u.JCu@netcom.com>,
Matthew H. Gerlach <gerlach@netcom.com> wrote:
>Hello fellow embedded hackers,
>
>According to the FAQ, Wind River supports the following hosts:
>Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS.
>
>Has it ever been considered or tried to use a PC running Linux as the host
>for vxworks development.  It seems to me the only real requirement of the
>host is that it supports various TCP/IP protocols and that one can build
>the appropriate cross-compiler variant of the GNU tools.
>

this is true.  you can roll your own compiler tools.

i have built m68k x-devel tools using GNU stuff before on linux.
i used to use it to compile my realtime kernel for a wirewrapped 68k
prototype i have.

the binaries for the tools should still be available in:

	cnuce_arch.cnr.it (131.114.1.10) /pub/micros/gnu-motorola 

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, Oakland, CA

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Thu Jan 26 06:52:42 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 26 06:52:50 PST 1995
Subject: Re: comp.os.vxworks newsdigest
Greetings!

> From: buchele@arlut.utexas.edu (Steven Buchele)
> 

[ extra deleted...]

> Yes, but you need to drive the software drivers from AP Labs.  The
> drivers that Heurikon supplys are from VxWorks 5.02 and won't work
> with any release later (such as the current 5.1.1 or 5.2).
> 
> Using
>   Heurikon 4220 Cougar board
>   VxWorks on a MV167:33MHz
>   AP Labs aio software driver
>   Seagate 2GB Baraccuda
> 
> we have seen raw file system performance in the range of 4.7MB/sec
> (using 1MB buffers).
> 
> BTW The Heurikon + AP Labs combo has been quite easy to configure and
> get going.

I think Steve is confusing Heurikon with Interphase.  Heurikon doesn't make
the Cougar, Interphase does.

However, I believe that Steve's message taken with D'Anne's and Ted's 
regarding SCSI speeds is significant.  My own experiences with drives
such as the Seagate Hawk 2 (ST31200N, ST32400N) as well as the 
Barracuda and the (now defunct) DEC DSP series drives, shows quite
a bit of fluctuation in performance from drive to drive and depending
on the technique for reading and writing to the media.

In using the VxWorks I/O system (read/write) with 1 MB buffers, you can
typically expect to see 3.5-5 MBytes/sec sustained (using Sync SCSI-2).
I'm still waiting on my SCSI analyzer to show up so I can't tell you much
about the SCSI-Fast or Fast/Wide interfaces.  However, when you drop 
down to low-level scsiRdSecs/scsiWrtSecs (with the proper SCSI controller
chip) your data rates can jump up by a factor of 2-4x.  

The apparent "slowness" of the I/O system is one of the prices we pay 
for portability/maintainability.  Most programmers understand "read"
and "write" when they see it in the code.  We know from our "C" manuals
how the data stream pointers are updated.  All of this is reasonably
well-defined, but carries with it the burden of overhead.

One of the really nice things about VxWorks is that we have the ability 
to bypass all of the overhead and go right to the metal.  The low-level
hooks are usually alread provided by WRS or by one of us when we write
the driver in the first place.  Unfortunately, in many cases we must
sacrifice things like portability and trade off development time 
(and money) to get the speed.  

As they say, "good, cheap, fast.  Pick any two" ;-).

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      
    

From mea@mclean.sparta.com  Thu Jan 26 06:52:48 1995
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 26 06:53:01 PST 1995
Subject: Re: Slip/PPP
Greetings!

> Submitted-by: greg@eng.nmr.varian.com (Greg Brissey x6951)
>  
> Dear vxPerts,
> 
> I am look for anyone with experience in using slip and/or ppp
> between a SUN 4.1.3 or 2.4 and vxWorks 5.1.1 target.
> 
> I have slip working but it is painfully slow :(,
> are there any ways of speeding it ?  (if so how?)
> 
> Would ppp be faster and/or better solution.
> I have a copy of ppp 1.3 for vxWorks.
> Where do I get a copy of ppp for the SUN 4.1.3 ?
> 

  I currently use SLIP from my Opus SPARCard 5 (a 95 MHz uSPARC 2 under 
SunOS 4.1.3) to an ISA-bus based 68302 running VxWorks.  The best speed 
I can get out of the Sun Serial ports is 38.4K.  That speed is usable
for most work, but it's pretty slow in comparison to Ethernet :-(.
To get faster than 38.4, I have had to resort to the SBus based Aurora 
400SX 4-port, high-speed serial board for the Unix side.  That board
can handle up to 115 KBps with no problems.  Then I boosted the speed
of the 68302 and can run at 78 KBPs without a problem.  An alternative
would be to use a PC with 16550 UARTS running SLIP.  The PC can also
support the 115 KBPs data rates.

  PPP won't help you all that much.  It does have some facilities for
header compression ala CSLIP and that would be of help if your problems
required mostly interactive, character-by-character access.  However, I
got the impression that raw serial port speed is your problem.  One other
technique that I have used successfully is to use another VxWorks system
with an Ethernet as the interface to the main net and use /tyCo/1 (or
what ever you have) as the SLIP front end.  You can then tune the speeds
of the serial link as appropriate for your application.

HTH,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From dan@radguard.co.il  Thu Jan 26 09:15:24 1995
From: Dan Frommer <dan@radguard.co.il>
Date: Thu Jan 26 09:15:30 PST 1995
Subject: Stack modifications
Folks,

I'd like to make a couple of minor modifications to the TCP/IP stack,
namely to the modules ip_input and ip_output. Since I don't have access
to the source code and wouldn't like to pay the hefty price tag, I'd like
to replace the above modules with modified ones based on Tahoe sources.

Has anyone attempted to go through a similar exercise? Can anyone shed
some light on the differences between the original Tahoe code and the one
used in VxWorks?

Any inputs or insights will be highly appreciated!

Thanks,

--
Dan Frommer                                Voice: +972-3-6459592
RADGuard, Ltd.                               Fax: +972-3-6480859
                                           Email: dan@radguard.co.il

From Doug.Owens.CHEM#u#235#u#05@quickmail.llnl.gov  Thu Jan 26 09:38:31 1995
From: "Doug Owens" <Doug.Owens.CHEM#u#235#u#05@quickmail.llnl.gov>
Date: Thu Jan 26 09:38:37 PST 1995
Subject: Unsubscribe
                       Subject:                               Time:9:49 AM
  OFFICE MEMO          Unsubscribe                            Date:1/20/95

I was subscribed to the exploder for owens@lodtm.llnl.gov.  Please unsubscribe
- the system is gone and the mail is backing up.
Thanks
Doug Owens

From dwampl@atl.com  Thu Jan 26 09:51:03 1995
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Thu Jan 26 09:51:09 PST 1995
Subject: Re: GUI solution for VxWorks
> 	I am looking for a Graphical User Interface solution for VxWorks that
> is not VxWindows (that is, not based on X/Motif), but provides
> the primitives for building a GUI and takes less resources (memory and CPU).
> Does any one know about 3rd parties that have ported something like
> GFX or Metawindows or something similar into VxWorks?  
> I am very interested to know about this.  Thank you in advance for your help.

Has anyone tried using Tcl/Tk with Vxworks?  This is X-based, of course, but
I believe it may be slightly smaller and faster than Motif (because it doesn't
use Xt or Motif libraries).

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

From wynia@iroc.arc.nasa.gov  Thu Jan 26 11:03:37 1995
From: "James P. Wynia" <wynia@iroc.arc.nasa.gov>
Date: Thu Jan 26 11:03:45 PST 1995
Subject: unsubscribe
unsubscribe

-- 
 ----------------------------< Jim P. Wynia >-----------------------------
  Sterling Software @ NASA Ames Research Center/    Phone: (415) 604-4797
  MS 221-6                                  /       FAX:   (415) 604-0071
  Moffett Field, CA  94035-1000          /email: wynia@viper.arc.nasa.gov
 -------------------------------------------------------------------------

From daemon@vxw.ee.lbl.gov  Fri Jan 27 07:08:58 1995
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 27 07:09:07 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 27 04:00:43 PST 1995

        Subject: VxWorks device driver for 8/4 mill EXABYTE tape unit (SCSI interface)
        Subject: Re: IP multicast in VxWorks ???
        Subject: GNU GDB for VxWorks
        Subject: Re: Any experience with 68060 boards?
        Subject: Re: Power PC compilers <What are people using?>
        Subject: fopen on local SCSI doesn't ignore CR
        Subject: Re: comp.os.vxworks newsdigest
        Subject: What does "workQPanic" mean?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks device driver for 8/4 mill EXABYTE tape unit (SCSI interface)
Date: Thu, 26 Jan 1995 16:17:16 GMT
From: adaless@relay.nswc.navy.mill   (Anthony DAlessandro dep.F32)
Organization: NSWC DAHLGREN VA
Keywords: 
          I would like any information on creating a vxworks SCSI device driver  
    for EXABYTE tape drives .
Message-ID: <1995Jan26.161716.10051@relay.nswc.navy.mil>
Sender: jporter@jasper (Jackie Porter (F32))

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: IP multicast in VxWorks ???
Date: 26 Jan 1995 16:57:25 GMT
From: sarkar@aesir.mit.edu (ss)
Organization: m
Message-ID: <3g8k9l$81c@senator-bedfellow.MIT.EDU>
Reply-To: sarkar@aesir.mit.edu

In message <1995Jan22.142101.24919@datum.nyo.dec.com>, 
segrest@bobseg.enet.dec.com () writes:

>
>Greetings,
>
>Has any work been done to provide IP multicast support in VxWorks ???
>
>I am working with someone that needs to embed an application currently 
>implemented with Solaris into a rom loaded VxWorks environment.
>
>-- 
>Bob Segrest
>

I would also like to receive copies of any email on this topic. 

thanks

serge sarkar

---------------------------

Newsgroups: comp.os.vxworks
Subject: GNU GDB for VxWorks
Date: 26 Jan 1995 11:36:17 -0600
From: dvernon@fohnix.metronet.com (David Vernon)
Organization: Texas Metronet, Internet for the Individual  214-705-2901 (info)
Message-ID: <3g8mih$1hc@fohnix.metronet.com>

I just read this in the VxWorks FAQ:

>> With a little bit of hacking, regular GDB works just fine. Personally,
>> I find GUI to a debugger gets in the way of real work.  I use GNU
>> Emacs GDB interface which works well and can be easily customized.

Can anyone detail for me the "little bit of hacking" that is required
to get GDB to work with VxWorks? 

Thanks for any input.

Dave Vernon
dvernon@metronet.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Any experience with 68060 boards?
Date: 26 Jan 1995 19:54:40 GMT
From: synergy@nic.cerf.net (John E. Clark)
Organization: CERFnet Dial n' CERF Customer
Message-ID: <3g8um0$7g2@news.cerf.net>
References: <9411171915.AA28760@glenvcr.glenayre.com>

In article <9411171915.AA28760@glenvcr.glenayre.com> jtosey@glenayre.com (Joseph Tosey [4572]) writes:
+167 with copyback caching.  They have made some significant
+changes to the caching model in the 060 which cripples it from
+our point of view.  The 040 supports snooping to maintain cache
+coherency, but the 060 does not.

While snooping assists the programer in writing code, snooping
slows the memory down on all DMA transfers that must be snooped.
While code is executing out of cache, a peripheral device may
be hanging out to dry on snooped cylces.

+As a result our application, which does not know about caching
+modes at all, can no longer run in copyback caching mode.  We
+tried to put in cache flushes around disk and serial i/o
+operations, but they happen very frequently as I/O request
+rates climb.  We are currently using the 060 in writethrough
+mode, and our processor utilization tools tell us that is
+reducing performance a full 50%.

Obviously I don't know about your application, nor enviornment.
However, one trick is to use the MMU to map the same physical
memory to two different virtual address regions. One region is
marked as copy-back, the other no-cache. Io transfers are done
via the no-cache region and 'code' is executed out of the
CBC region.

Just as obvious, if code is part of the I/O transfer, then
a 'cinva' needs to be done before execution starts. As the
region would have been filled by acesses to the non-cached zone,
but code is excuted out of the CBC zone.

+The point is that the 68060 affects applications, not just the
+OS.  Your application has to understand the caching model if it
+writes to buffers which are DMAed.  This was not necessary for
+the 040 and other earlier processors.

Well, here 'cache ignorance' was easier to overlook, but there
was a 'hit'. But with ETHERNET at about a Meg/sec. and SCSI often
bursty, but overall lower than say 1-2 Meg/sec. one could overlook
the 'hit'. But now with faster SCSI, 100 Meg-a-bit ETHERNET,
155 Meg-a-bit ATM, and Fiber of one sort or another all starting at
100 Meg-a-bit, and going up, the 'hit' is going to be more pronounced.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Power PC compilers <What are people using?>
Date: 26 Jan 1995 20:03:21 GMT
From: synergy@nic.cerf.net (John E. Clark)
Organization: CERFnet Dial n' CERF Customer
Message-ID: <3g8v69$7i3@news.cerf.net>
References: <9501180316.AA16552@sunshine.labs.tek.com>

In article <9501180316.AA16552@sunshine.labs.tek.com> johncal@sunshine.labs.tek.com (John Calvin) writes:
+
+What compiler are people using for Power PC's?
+
+
+GNU I've been advised, is 8 to 10 months away from a Power-PC compiler.
+Can anybody confirm this? 

Uh? The current GNU binutils, and gcc are capable of generating PPC
code to produce an elf binary output. It's not exactly 'straightforward'
as say 'configure --host=sunos4 --target==power-pc', but it is do-able.

As for 'optimization', beats me.... The gcc-ppc was built on the rs6000
processor work, so if it was optimized for that architecture, it may
have some beenfit in the ppc.

Then there's gdb... but who uses debuggers anyway, really?

---------------------------

Newsgroups: comp.os.vxworks
Subject: fopen on local SCSI doesn't ignore CR
Date: Thu, 26 Jan 1995 22:52:32 GMT
From: geger@phantom.den.mmc.com (George Eger)
Organization: Martin Marietta Astronautics Group
Keywords: fopen SCSI
Message-ID: <1995Jan26.225232.5686@den.mmc.com>
Followup-To: Opening local SCSI
Sender: news@den.mmc.com (News Admin)

I had posted a message about why:

	fgets(&(filename[0]), SOME_MAX, stdin);
	NewFD = fopen(&(filename[0]), "r");

worked on a remote Unix directory, but failed on a local SCSI disk.

Thanks to Alan Nishioka	(alann@abekas.com), I found my problem.  Turns
out that the fopen() on a local DOS filesystem is sensitive to the 
NEWLINE at the end of the string.  So by trimming out the ending NEWLINE,
I can open the local files from my program.

I guess that the mechanism to open a remote file on my Unix host must
trim out (or maybe Unix ignores) the ending NEWLINE that fgets()
puts in the string buffer.

Thanks to all,

GWE
- -- 

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: comp.os.vxworks newsdigest
Date: 27 Jan 1995 02:03:32 GMT
From: friedl@cher.heurikon.com (Ted Friedl)
Organization: Heurikon Corporation
Message-ID: <3g9k9k$8nh@zebu.heurikon.com>
References: <9501261458.AA01071@locutus>

In article <9501261458.AA01071@locutus>,
Mike Anderson <mea@mclean.sparta.com> wrote:
>                                       My own experiences with drives
>such as the Seagate Hawk 2 (ST31200N, ST32400N) as well as the 
>Barracuda and the (now defunct) DEC DSP series drives, shows quite
>a bit of fluctuation in performance from drive to drive and depending
>on the technique for reading and writing to the media.

I have been checking drives as they pass through my hands and taking
notes when possible.  The following results are from the second (2nd)
20 seconds of reading 524,288 byte buffers sequentially from the 
outside track toward the inside (i.e. w/512-byte block device, 
read LBA 0-1023, 1024-2047, ...).

All drives were tested with a 100ns period and 8 req/ack offset with
their factory-default mode pages.  Some wide drives were also
measured running 8-bit...  

8-bit (or default)
                    disc / comp = ratio  sustained_rate / bus_time = burst_rate
Ciprico AS6701       358    358      1       9.38 MB/s      96.4 %    9.72 MB/s
Fuji M2694ESA        903    146      6       3.79 MB/s      41.3 %    9.20 MB/s
HP C2247               0    145      0       3.79 MB/s      99.4 %    3.82 MB/s
HP C3323A              0    184      0       4.77 MB/s      99.3 %    4.80 MB/s
Qntm Atlas XP32150 18225    279     65       7.26 MB/s      78.5 %    9.25 MB/s
Qntm Empire 1080SWD  883    147      6       3.82 MB/s      39.0 %    9.79 MB/s
Qntm Empire 540S     878    146      6       3.80 MB/s      38.8 %    9.79 MB/s
Qntm Lightning 540S 4972    142     35       3.69 MB/s      56.0 %    6.60 MB/s
Seagate ST12550WD    705    204      3       5.35 MB/s      56.9 %    9.39 MB/s
Seagate ST31200W     647    162      3       4.21 MB/s      44.5 %    9.46 MB/s
                                                      (MB = 1,000,000 bytes!)

16-bit
                    disc / comp = ratio  sustained_rate / bus_time = burst_rate
Ciprico AS6701 4+1   665    665      1      17.42 MB/s      93.5 %   18.63 MB/s
DEC DSP3107LW       3082    182     16       4.74 MB/s      41.7 %   11.34 MB/s
Qntm Empire 1080SWD  608    147      4       3.82 MB/s      27.4 %   13.91 MB/s
Seagate ST12550WD   1170    208      5       5.43 MB/s      30.9 %   17.55 MB/s
Seagate ST31200W     841    162      5       4.21 MB/s      23.7 %   17.73 MB/s
                                                      (MB = 1,000,000 bytes!)

The more efficient drives have better additive performance when sharing
the same bus.  For example two Quantum Empires 540S's can sustain 7.43 MB/s 
while two comparable HP C2247's can only sustain 4.14 MB/s.  On the 
other hand, drives that tend to grab the bus and not let go (like the
HP C2247) look better than others sharing the bus when the others are 
the more polite variety. 

Ted Friedl
Software Engineer
Heurikon Corporation

---------------------------

Newsgroups: comp.os.vxworks
Subject: What does "workQPanic" mean?
Date: Thu, 26 Jan 1995 23:59:14 GMT
From: claus@pepiiu1.SLAC.Stanford.EDU (Ric Claus)
Organization: Stanford Linear Accelerator Center
Message-ID: <CLAUS.95Jan26155914@pepiiu1.SLAC.Stanford.EDU>
Reply-To: claus@slac.stanford.edu (Ric Claus)
Sender: news@unixhub.SLAC.Stanford.EDU

I have been plagued by the message

workQPanic: Kernel work queue overflow.

after running some 7 or 8 application codes in the context of a "shell", all of
which I wrote.  The application codes handle DSP processor boards that all run
the same code.  Thus, the interrupt timing is pretty bursty, but no higher than
5 to 10 at "a time" (< 100 nS window?).  The shell provides the ISR and
packages the interrupt messages to be sent to the application's task level
handler.  (Perhaps the ISR takes too long?)  When invoking an application, it
is loaded from a Unix disk through ethernet. Starting it causes two tasks to be
created successively.  When the first finishes and returns, the second is
started.

It sure seems like VxWorks is running out of some resource, but I can't figure
out what.  When I checkStack after every application invocation, I see that all
stacks have been used to no more than half the alloted memory.  The INTERRUPT
stack never uses more than 268 bytes out of 1000.  I see no signs of anything
being corrupted anywhere.  Perhaps task descriptors aren't being recycled?

When I memShow after every application invocation, I see that memory usage is
well bounded and nowhere close to the edge.  Memory usage is application
dependent, but if I invoke the same application as the one before the previous
application, memory usage goes back to the same values.  As an aside, I was not
expecting this to be true because I understood that there was a memory leak
associated with taskSpawns.  Unless memShow does not properly account for all
the memory used, I see no leaks due to tasks being created and properly 
finishing (i.e. not taskDeleted, by me at least).

It's hard to look around after workQPanic occurs because it causes a reboot.
I'm also not sure where to look.  I've looked in the VxWorks manuals for what
this message might mean, but have come up empty handed.  It would be nice if it
(and a bunch of other things) were in the index...

The hardware is a 25 MHz Force 40 with 4 Meg and an Eagle 02 (ethernet and VSB)
running version 5.1.1 VxWorks.

  Thanks in advance for any light anyone can shed on this.

	Ric Claus  (415.926.2697)

---------------------------

End of New-News digest
**********************

From @icineca.cineca.it:sandri@deis58.cineca.it  Fri Jan 27 12:50:44 1995
From: sandri@deis58.cineca.it (Mario Sandri)
Date: Fri Jan 27 12:50:51 PST 1995
Subject: Unsubscribe

Dear Sirs,

please unsubscribe me.
Thanks
						Mario Sandri

From bordua@csg.lbl.gov  Fri Jan 27 13:13:47 1995
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Fri Jan 27 13:13:53 PST 1995
Subject: Re: Unsubscribe
Unsubscribed.

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory

From daemon@vxw.ee.lbl.gov  Sat Jan 28 04:00:32 1995
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 28 04:00:46 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 28 04:00:21 PST 1995

        Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
        Subject: Re: dual port (VME) memory on FORCE CPU-30 and CPU-40
        Subject: 5.1 qsort
        Subject: Can SLIP use any non block device driver ?
        Subject: Re: GNU GDB for VxWorks
        Subject: Re: 5.1 qsort
        Subject: Re: GNU GDB for VxWorks
        Subject: Re: How can I test for existence of a file?
        Subject: Re: GNU GDB for VxWorks
        Subject: Re: GNU GDB for VxWorks
        Subject: Re: GNU GDB for VxWorks
        Subject: Removable Media for VME + VxWorks
        Subject: Re: Slip/PPP
        Subject: msgQLib
        Subject: Re: VxSim
        Subject: scsiIoctl() takes 300 microseconds?

-------------------------------------------------------

Newsgroups: comp.os.vxworks,comp.sys.m68k,alt.industrial.computing,sci.electronics,rec.radio.amateur.space
Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
Date: 27 Jan 1995 12:31:34 GMT
From: aranders@kosepc01.delcoelect.com (Alan Anderson)
Organization: Delco Electronics Corporation, Kokomo, Indiana
Message-ID: <3gap36$p9f@kocrsv08.delcoelect.com>
References: <3fi0d6$hbr@CUBoulder.Colorado.EDU> <lacovara.227.0078D738@ollie.jsc.nasa.gov>
Reply-To: aranders@kosepc01.delcoelect.com (Alan Anderson)

Pardon the severely off-topic note, but I just had to respond.

In <lacovara.227.0078D738@ollie.jsc.nasa.gov>, 
lacovara@ollie.jsc.nasa.gov (R. C. Lacovara) writes:
>[note deleted, .sig retained]
>Texas is the largest and grandest State of the United States. It retains the 
              ^^^^^^^
>right to fly its flag at the same height as that of the United States. Texas
>must not be abbreviated, like NJ or RI: NJ fits between Houston and San
>Antonio, with RI to spare. Al

Watch out, Texas, or Alaska might split in two and make you the *third*
largest state!

= === ===   === = = =   === === === === =   = === =   = = ===   = = === =
Alan Anderson                               | Ignorance can be fixed,
(I speak AT, not FOR, Delco Electronics)    | but stupidity is permanent.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: dual port (VME) memory on FORCE CPU-30 and CPU-40
Date: Mon, 23 Jan 1995 18:02:30 GMT
From: healy@nosc.mil (Mike Healy)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1995Jan23.180230.11551@nosc.mil>
References: <0098ABE6.0DE10C20.36@nrlvax.nrl.navy.mil>
Sender: news@nosc.mil

On CPU-30 and CPU-40 you need to set some registers in the FGA
to specify the address to reference the shared memory across
the VME bus. Check the FGA manual.

sysMemTop uses the following macro from frc40.h:

/* PIT macro to return local memory size in bytes */

#define FRC40_MEM_SIZE  \
        (0x2000000 >> ((*PIT_PBDR (FRC40_PIT2_BASE_ADRS)) & 0x7))

from config.h for CPU-40, vxWorks 5.1:

/*
 * Local-to-Bus memory address values:
 * The CPU-40 dual port memory address is under software control and may be
 * changed by programming the FGA-002. For more information on the user
 * programmable options of the Force FGA-002 see the CPU-40 or FGA-002
manual.
 *
 * To determine the actual memory size use sysMemTop().  The constant
 * LOCAL_MEM_SIZE is used to configure the MMU in sysLib.c.  For optimal
use
 * of cache, build VxWorks with LOCAL_MEM_SIZE set to the size of the
 * CPU-40's local RAM
 */

#define LOCAL_MEM_LOCAL_ADRS    0x00000000
#define LOCAL_MEM_BUS_ADRS      (0x01000000*(sysProcNumGet()+1)) /*
16M*proc# */
#define LOCAL_MEM_SIZE      0x00400000  /* minimum memory available */

I think if you adjust both of these MEM_SIZE values you'll end up
with memory at the top of the address space of the boards that
will be protected from vxWorks use.

Mike Healy

healy@nosc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: 5.1 qsort
Date: Wed, 25 Jan 1995 16:40:05 GMT
From: healy@cod.nosc.mil (Mike Healy)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1995Jan25.164005.15811@nosc.mil>
Sender: news@nosc.mil

We have run into a problem with qsort on our 5.1
CPU-40 SGI version. It is returning corrupt data.
We have no problem with qsort from our 5.1.1 CPU-40
Sun version. Is there a fixed version for the SGI 
available somewhere?

Thanks

Mike Healy

healy@nosc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: Can SLIP use any non block device driver ?
Date: Fri, 27 Jan 1995 08:36:33 GMT
From: lee@dradeb.demon.co.uk (Lee)
Organization: DRA Bedford
Message-ID: <lee.1.00089C42@dradeb.demon.co.uk>
Sender: news@demon.co.uk (Usenet Administration)

          We have two VME systems connected by ARINC429 and would like to run 
           TCP/IP over the link.  If we implemented a non block device driver 
          (ie open,read,write, ioctrl etc) for the 429 board could the SLIP 
          driver use it.

          Any information, advice or links would be great.

          martin@drabed.demon.co.uk

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: Fri, 27 Jan 1995 14:13:01 GMT
From: clegg@ssd.fsi.com
Organization: Flightsafety International, Broken Arrow, OK
Message-ID: <1995Jan27.141301.19732@dev1.ssd.fsi.com>
References: <3g8mih$1hc@fohnix.metronet.com>
Reply-To: clegg@ssd.fsi.com
Sender: news@dev1.ssd.fsi.com

In <3g8mih$1hc@fohnix.metronet.com>, dvernon@fohnix.metronet.com (David Vernon) writes:
>I just read this in the VxWorks FAQ:
>
>>> With a little bit of hacking, regular GDB works just fine. Personally,
>>> I find GUI to a debugger gets in the way of real work.  I use GNU
>>> Emacs GDB interface which works well and can be easily customized.
>
>Can anyone detail for me the "little bit of hacking" that is required
>to get GDB to work with VxWorks? 
>
I would be interested in this also.
Thanks
R. Clegg
_____________________________  __ _ _                    
                              |__|_|_|==========__       
                             [===  /              \      
                             |     \ FlightSafety  )     
                              |     \       SSD   )      
                             |===|===\           )       
                             |_\_|___|\=========)        
                             [___________________]       
                                \ \/ /   \ \/ /          
                                 \/ /     \ \/           
The best safety device           / /\     /\ \           
in any aircraft is a         ___/ /\_\___/_/\ \__        
well trained pilot.     ____[____________________]_____  
clegg@ssd.fsi.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: 5.1 qsort
Date: 27 Jan 1995 16:42:27 GMT
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <3gb7pj$17j@grover.jpl.nasa.gov>
References: <1995Jan25.164005.15811@nosc.mil>

In article <1995Jan25.164005.15811@nosc.mil>, healy@cod.nosc.mil (Mike Healy) writes:
|> 
|> We have run into a problem with qsort on our 5.1
|> CPU-40 SGI version. It is returning corrupt data.
|> We have no problem with qsort from our 5.1.1 CPU-40
|> Sun version. Is there a fixed version for the SGI 
|> available somewhere?

qsort in 5.1 is broken.  You can get a version of qsort from the GNU
glibc distribution, or from the Cygnus newlib distribution, which is
included below.

Matt

/*
FUNCTION
<<qsort>>---sort an array

INDEX
	qsort

ANSI_SYNOPSIS
	#include <stdlib.h>
	void qsort(void *<[base]>, size_t <[nmemb]>, size_t <[size]>,
		   int (*<[compar]>)(const void *, const void *) );

TRAD_SYNOPSIS
	#include <stdlib.h>
	qsort(<[base]>, <[nmemb]>, <[size]>, <[compar]> )
	char *<[base]>;
	size_t <[nmemb]>;
	size_t <[size]>;
	int (*<[compar]>)();

DESCRIPTION
<<qsort>> sorts an array (beginning at <[base]>) of <[nmemb]> objects.
<[size]> describes the size of each element of the array.

You must supply a pointer to a comparison function, using the argument
shown as <[compar]>.  (This permits sorting objects of unknown
properties.)  Define the comparison function to accept two arguments,
each a pointer to an element of the array starting at <[base]>.  The
result of <<(*<[compar]>)>> must be negative if the first argument is
less than the second, zero if the two arguments match, and positive if
the first argument is greater than the second (where ``less than'' and
``greater than'' refer to whatever arbitrary ordering is appropriate).

The array is sorted in place; that is, when <<qsort>> returns, the
array elements beginning at <[base]> have been reordered.

RETURNS
<<qsort>> does not return a result.

PORTABILITY
<<qsort>> is required by ANSI (without specifying the sorting algorithm).

Supporting OS subroutines required: <<close>>, <<fstat>>, <<isatty>>,
<<lseek>>, <<read>>, <<sbrk>>, <<write>>.
*/

/*
 * qsort.c
 * Original Author:	G. Haley
 *
 * Sorts an array of nmemb objects, the initial member of which is pointed to
 * by base. The size of each object is specified by size. The contents of the
 * array are sorted in ascending order according to a comparison function
 * pointed to by compar, which is called with two arguments pointing to the
 * objects being compared. The function shall return an integer less than,
 * equal to or greater than zero if the first argument is considered to be
 * respectively less than, equal to or greater than the second. If two members
 * compare as equal, their order in the sorted array is unspecified.
 */

#include <stddef.h>
#include <stdlib.h>
#include <string.h>

static int
_DEFUN (find_pivot, (base, i, j, size, compar),
	_PTR base _AND
	int i _AND
	int j _AND
	size_t size _AND
	int (*compar) ())
{
  _PTR first_key;
  _PTR next_key;
  int k, res;

  first_key = (_PTR) (((char *) base) + (i * size));
  next_key = first_key;

  for (k = i + 1; k <= j; k++)
    {
      next_key = (_PTR) (((char *) next_key) + size);
      res = (*compar) (next_key, first_key);

      if (res > 0)
	return k;
      else if (res < 0)
	return i;
    }

  return -1;
}

static void
_DEFUN (swap, (base, i, j, size),
	_PTR base _AND
	int i _AND
	int j _AND
	size_t size)
{
#ifdef __GNUC__
  _PTR temp = __builtin_alloca (size);
#else
  static _PTR temp = NULL;
  static size_t max_size = 0;
#endif

  _PTR elem1, *elem2;

#ifndef __GNUC__
  if (size > max_size)
    {
      temp = realloc (temp, size);
      max_size = size;
    }
#endif

  elem1 = (_PTR) (((char *) base) + (i * size));
  elem2 = (_PTR) (((char *) base) + (j * size));

  memcpy (temp, elem1, size);
  memcpy (elem1, elem2, size);
  memcpy (elem2, temp, size);
}

static int
_DEFUN (partition, (base, i, j, pivot_index, size, compar),
	_PTR base _AND
	int i _AND
	int j _AND
	int pivot_index _AND
	size_t size _AND
	int (*compar) ())
{
  int left, right;

  left = i;
  right = j;

  do
    {
      swap (base, left, right, size);

      if (pivot_index == left)
	pivot_index = right;
      else if (pivot_index == right)
	pivot_index = left;

      while (compar ((_PTR) (((char *) base) + (left * size)),
		     (_PTR) (((char *) base) + (pivot_index * size))) < 0)
	left++;

      while (compar ((_PTR) (((char *) base) + (right * size)),
		     (_PTR) (((char *) base) + (pivot_index * size))) >= 0)
	right--;

    }
  while (left <= right);

  return left;
}

static void
_DEFUN (inside_qsort, (base, i, j, size, compar),
	_PTR base _AND
	int i _AND
	int j _AND
	size_t size _AND
	int (*compar) ())
{
  int pivot_index, mid;

  if ((pivot_index = find_pivot (base, i, j, size, compar)) != -1)
    {
      mid = partition (base, i, j, pivot_index, size, compar);

      inside_qsort (base, i, mid - 1, size, compar);
      inside_qsort (base, mid, j, size, compar);
    }
}

_VOID 
_DEFUN (qsort, (base, nmemb, size, compar),
	_PTR base _AND
	size_t nmemb _AND
	size_t size _AND
	int (*compar) ())
{
  inside_qsort (base, 0, nmemb - 1, size, compar);
}

- -- 
matthew.r.wette@jpl.nasa.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: 27 Jan 1995 15:39:18 GMT
From: bowman@waterloo.hp.com (Don Bowman)
Organization: H-P Panacom Div, Waterloo, ON Canada
Message-ID: <3gb436$2f8@hppadbk.waterloo.hp.com>
References: <3g8mih$1hc@fohnix.metronet.com>

David Vernon (dvernon@fohnix.metronet.com) wrote:
: I just read this in the VxWorks FAQ:

: >> With a little bit of hacking, regular GDB works just fine. Personally,
: >> I find GUI to a debugger gets in the way of real work.  I use GNU
: >> Emacs GDB interface which works well and can be easily customized.

: Can anyone detail for me the "little bit of hacking" that is required
: to get GDB to work with VxWorks? 

Just run configure and make.

The magic for us was:
configure --target vxworks960 hppa1.1-hpux

- --
bowman@waterloo.hp.com ** 519-883-3019 ** http://www.waterloo.hp.com/~bowman

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: How can I test for existence of a file?
Date: Fri, 27 Jan 1995 16:26:04 +0000
From: markE@baesema1.demon.co.uk (Mark Endacott)
Organization: BAeSEMA
Message-ID: <791223964snz@baesema1.demon.co.uk>
References: <GAMIN.95Jan17082328@pellan.ireq-robot.hydro.qc.ca>
Reply-To: markE@baesema1.demon.co.uk
Sender: usenet@demon.co.uk

In article <GAMIN.95Jan17082328@pellan.ireq-robot.hydro.qc.ca>
           gamin@ireq-robot.hydro.qc.ca "Martin Boyer" writes:

> I am trying to test for the existence of a file (in an NFS-mounted
> partition) under VxWorks 5.1.1.
> 
> Testing the return value of the following functions gives me enough
> information, but it also prints an error message on the console if the
> file doesn't exist (which I don't want).
> 
>     stat(filename, &st)
>         => OK if the file exists
>         => Error if not (but also prints an error message)
> 
>     open(hostconfig, READ, 0)
>         => a file descriptor if the file exists
>         => Error if not (but also prints an error message)
> 
> I was looking for something like the UNIX "access" function, but
> couldn't find it.  I'd be willing ro "redirect standard error to
> /dev/null" if that would get rid of the error message and if I knew
> how to do that in VxWorks.
> 
Don't know about the 'access' function although there may be one, however
redirection of i/o is easy. vxWorks uses Fd's 0,1 and 2 as the default stdin,
stdout and stderror, these can be manipulated with the routines ioGlobalStdSet,
ioGlobalStdGet,ioTaskStdGet and ioTaskStdSet. The difference between them being
the task routines only change the stdio for the task and not all tasks.
All you have to do is call the following

ioTaskStdSet ( task_id,3,new_fd);

Where 'new_fd' is the fd of a null file.

There may already be a 'null' Fd already opened by vxWorks, I can't remember 
and I don't currently have access to our target hardware that runs vxWorks.
Try typing iosFdShow at the console and see what it gives you in terms of
open Fd's.

One thing I am unsure of is, if the 'error handler' that is generating the 
message on your console is tied to the task's I/O or the Global I/O. If its
global you can use the global routines however this will route ALL stderror
traffic to NULL. 

- -- 
Mark Endacott

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: 27 Jan 1995 18:20:11 GMT
From: synergy@nic.cerf.net (John E. Clark)
Organization: CERFnet Dial n' CERF Customer
Message-ID: <3gbdgr$6qf@news.cerf.net>
References: <3g8mih$1hc@fohnix.metronet.com>

In article <3g8mih$1hc@fohnix.metronet.com> dvernon@fohnix.metronet.com (David Vernon) writes:
+I just read this in the VxWorks FAQ:
+
+>> With a little bit of hacking, regular GDB works just fine. Personally,
+>> I find GUI to a debugger gets in the way of real work.  I use GNU
+>> Emacs GDB interface which works well and can be easily customized.
+
+Can anyone detail for me the "little bit of hacking" that is required
+to get GDB to work with VxWorks? 

The GDB that one can pick up from prep.ai.mit.edu has in it an RPC
interface to vxworks. I don't know how straight forward it would be
to included that in the build for your local gdb. I don't know if
there's a convienent 'configure' option or what. Also, there may
be a difference between the current supported vxworks RPC interface
and the one that's in the prep distribution.

There are a couple of other 'remote' debugging interfaces there as
well. One of which will go over a serial line... for the really
minimally inclined...

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: Fri, 27 Jan 1995 21:46:30 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD3335J.6C0@netcom.com>
References: <3g8mih$1hc@fohnix.metronet.com> <3gbdgr$6qf@news.cerf.net>

In article <3gbdgr$6qf@news.cerf.net>,
John E. Clark <synergy@nic.cerf.net> wrote:
>
>The GDB that one can pick up from prep.ai.mit.edu has in it an RPC
>interface to vxworks. I don't know how straight forward it would be
>to included that in the build for your local gdb. I don't know if
>there's a convienent 'configure' option or what. Also, there may
>be a difference between the current supported vxworks RPC interface
>and the one that's in the prep distribution.

recent versions of GDB that has vxworks target "configure" will build and
work fine on machines that are known to be supported, but YMMV.
it won't do anything unless you buy the vxworks portion of the RPC/debug
interface stub, which is not included in GDB (costs big bucks).  
so much for the free software...

>
>There are a couple of other 'remote' debugging interfaces there as
>well. One of which will go over a serial line... for the really
>minimally inclined...
>

this option is not "minimally inclined".  this actually works much better,
IMHO.  vxgdb never worked properly every time i attempted to use it in the
past and most only for task/app debugging (can't do real low level
debugging), full of bugs in the debugger itself, etc.  but YMMV, again.

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, Oakland, CA

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: Fri, 27 Jan 1995 22:01:31 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD333uJ.7zw@netcom.com>
References: <3g8mih$1hc@fohnix.metronet.com>

In article <3g8mih$1hc@fohnix.metronet.com>,
David Vernon <dvernon@fohnix.metronet.com> wrote:
>I just read this in the VxWorks FAQ:
>
>>> With a little bit of hacking, regular GDB works just fine. Personally,
>>> I find GUI to a debugger gets in the way of real work.  I use GNU
>>> Emacs GDB interface which works well and can be easily customized.
>
>Can anyone detail for me the "little bit of hacking" that is required
>to get GDB to work with VxWorks? 
>
>Thanks for any input.
>
>Dave Vernon
>dvernon@metronet.com
>

get latest GDB source distribution.  i used 4.8 (old but compatible with
DUEL extention language).   read installation doc and build for proper
target and host pair using configure script.  you may or may not have to
hack on the config files.  a lot of times, things dont build right unless
you're using extremely vanilla setup.  you just have to go around and fix
various files that are missing/ or not compiling.  you also have to decide
whether you're gonna use RPC based (like vxgdb) app debugging or plain old
serial remote debugging (better, IMHO).  the former requires you to buy
expensive little remote module from WRS.  the latter does not.  just look
at remote-*.c files and pick the closes one that might work with your
setup.  i usually pick m68k-stub.c and hack on it to make it work with
vxworks.  hook up over null modem and you have a real remote debugger that
can do low-level debugging as well as application debugging!

- --
Hwa-Jin Bae (hjb@netcom.com)
Peaceful Star, Oakland, CA

---------------------------

Newsgroups: comp.os.vxworks
Subject: Removable Media for VME + VxWorks
Date: 27 Jan 1995 16:41:43 -0600
From: buchele@arlut.utexas.edu (Steven Buchele)
Organization: Applied Research Labs - The University of Texas at Austin
Message-ID: <3gbsr7$7kd@csdsun1.arlut.utexas.edu>

We are looking for some sort of removeable media for our project
so that the sponsor can easily/quickly take home data, but does not
have to wait for the whole hard drive to be archived.

Our system is a MV167 running VxWorks with a couple of SCSI 2
differental Elite 9 GB drives controlled by an Interphase 4220 Cougar
running the AP Labs aio/ados drivers.

FYI
Results of our Interphase 4220 + AP Labs aio/ados drivers Test
Raw file system: 4.7 MB/sec 1MB buffer
DOS file system: 3.8 MB/sec 1MB buffer
The system
MV167 + VxWorks 5.1.1 + Interphase 4220 + Seagate Hawk 1GB + aio/ados drivers.

Steve Buchele
Applied Research Labs
buchele@arlut.utexas.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Slip/PPP
Date: Fri, 27 Jan 1995 22:15:08 GMT
From: hjb@netcom.com (Hwa-Jin Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <hjbD334H8.99y@netcom.com>
References: <9501251803.AA10068@eng.nmr.varian.com>

In article <9501251803.AA10068@eng.nmr.varian.com>,
Greg Brissey x6951 <greg@eng.nmr.varian.com> wrote:
>Dear vxPerts,
>
>I am look for anyone with experience in using slip and/or ppp
>between a SUN 4.1.3 or 2.4 and vxWorks 5.1.1 target.
>
>I have slip working but it is painfully slow :(,
>are there any ways of speeding it ?  (if so how?)
>

yeah... no doubt it's slow.  i honestly don't think anyone really did any
work on that SLIP driver ever since i hacked it up at WRS.  like, nobody
bothered to add a simple VJcompression stuff onto it.  sigh.

>Would ppp be faster and/or better solution.
>I have a copy of ppp 1.3 for vxWorks.
>Where do I get a copy of ppp for the SUN 4.1.3 ?
>

well... WRS should by now have a PPP done by an outside help.  if it's done
right, it should have VJ compressions.    it prolly is about 10 times
bigger than the slip driver, and i'm not sure of actual performance
characteristics.   Don Brooks are you there ?  ;-)
PPP for SUN can be gotten everywhere on internet.  ftp.uu.net, for one.

>Any suggestion or comments would be greatly appreciated.
>
>Thanks in Advance,
>
>Greg Brissey
>greg.brissey@nmr.varian.com
>

---------------------------

Newsgroups: comp.os.vxworks
Subject: msgQLib
Date: 27 Jan 1995 09:59:00 GMT
From: kauer@aut.alcatel.at (Helmut Kauer)
Organization: Alcatel Austria AG
Keywords: intertask communication, binary data, message queue
Message-ID: <3gag54$5oo@ccsun5.aut.alcatel.at>
Reply-To: kauer@aut.alcatel.at

Hi all,

For intertask communication we want to use the message queue library (msgQLib), but want to transfer binary data. 
The library seems to accept only character strings and stops at a \0 character!!

Has anybody an idea, how to handle this problem??

Thanks Helmut !!

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxSim
Date: Sat, 28 Jan 1995 01:52:37 GMT
From: davem@micom.com (David Monachello)
Organization: Micom Communications Corp.
Message-ID: <1995Jan28.015237.8960@micom.com>
References: <1995Jan20.200454.3862@picker.com> <1995Jan23.084528.1@corning.com>
Sender: news@micom.com

whiting_ms@corning.com (Matt Whiting) (whiting_ms@corning.com) wrote:
: In article <1995Jan20.200454.3862@picker.com>, heiple@ct.picker.com (HEIPLE, HOLLY) writes:
: > Does anybody have any experience using VxSim?  We are considering buying it
: > based on the literature but I am wondering how much a developer would really
: > use it.  Why not just use the target?  Any comments or words of wisdom?
: > 
: > Thanks,
: > Holly Heiple
: > 
: > 
: > 
: -- 

: We tried to use it recently during an evaluation of VxWorks, but found that it
: doesn't run under Solaris.  This is documented in the release notes, but we
: didn't notice that and our sales guy knew we had Solaris and failed to mention
: it either.  So just be sure that you have SunOS if you do plan to use VxSIM.

: Just using the target is OK assuming you have a target!  We'd planned to use
: VxSIM as our target system was on back order.  It could also be advantageous if
: you wanted to do development at multiple sites and each site didn't have a
: target sytem available.

hi,

Do you know if wind river plans to rectify the solaris problem? We have used vxsim
very successfully in the development of our product and we plan to continue to use
it for debugging and simulation even after the project has been fully ported to the
target hardware. 

Using vxsim also allows us to run multiple copies of our product on a single sparc 
station to test the interaction between them.

There does seems to be a few problems with vxsim however. Signals seem to behave strangely
and excluding certain vxworks features causes unresolved references. 

bye,
dave monachello

---------------------------

Newsgroups: comp.os.vxworks
Subject: scsiIoctl() takes 300 microseconds?
Date: 27 Jan 1995 18:14:59 GMT
From: edh@antlabw1.svl.trw.com (ED)
Organization: svl.trw.com
Message-ID: <3gbd73$86p@gatekeeper.svl.trw.com>

I'm using vxWorks 5.1, the beta version of the SCSI-2 library, and a board
with an NCR 710 SCSI chip.

I have to use the scsiIoctl() command to send commands to my SCSI device.
However, it takes 300 microseconds to do send one -- timed by sending
out a hardware pulse just before and after the scsiIoctl().  And I
need it to run significantly faster than that.

I've tried experimenting with some of the options, but I can't find
anything that helps.  Has anyone else seen this problem?

- --
Ed Haymore
edh@antlabw1.esl.com

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sun Jan 29 04:00:26 1995
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 29 04:00:33 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 29 04:00:16 PST 1995

        Subject: Anyone got DEC VxWorks V3.1:

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Anyone got DEC VxWorks V3.1:
Date: 29 Jan 1995 13:23:15 +1100
From: jb@werple.mira.net.au (John Birrell)
Organization: werple public-access unix, Melbourne
Message-ID: <3geu6j$bnm@werple.mira.net.au>

We have been trying to obtain DEC VxWorks V3.1 from Digital for months now.
The most we can get is the SPD which tells us that the AXP board support kit
is part of V3.1. Digital delivered us OSF/1 V3.0 Layered Products dated
Sep 94, but this contained V3.0 which only has the Motorola board support kit.

Has anyone received V3.1? If so, how did you get it? Are you using the AXP
board support kit? If so are there any problems that we can avoid if we ever
get it?

As you may gather, I'm annoyed.

John Birrell
CIMlogic Pty Ltd

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Mon Jan 30 04:00:26 1995
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 30 04:00:33 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 30 04:00:16 PST 1995

        Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards

-------------------------------------------------------

Newsgroups: comp.os.vxworks,comp.sys.m68k,alt.industrial.computing,sci.electronics,rec.radio.amateur.space
Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
Date: Sun, 29 Jan 1995 13:20:42 UNDEFINED
From: lacovara@ollie.jsc.nasa.gov (R. C. Lacovara)
Organization: GeoControl Systems, Incorporated
Message-ID: <lacovara.242.00586C65@ollie.jsc.nasa.gov>
References: <3fi0d6$hbr@CUBoulder.Colorado.EDU> <lacovara.227.0078D738@ollie.jsc.nasa.gov> <3gap36$p9f@kocrsv08.delcoelect.com>

In article <3gap36$p9f@kocrsv08.delcoelect.com> aranders@kosepc01.delcoelect.com (Alan Anderson) writes:
>From: aranders@kosepc01.delcoelect.com (Alan Anderson)
>Subject: Re: Info wanted on off-the-shelf MIL-SPEC embedded controller boards
>Date: 27 Jan 1995 12:31:34 GMT

>Pardon the severely off-topic note, but I just had to respond.

>In <lacovara.227.0078D738@ollie.jsc.nasa.gov>, 
>lacovara@ollie.jsc.nasa.gov (R. C. Lacovara) writes:
>>[note deleted, .sig retained]
>>Texas is the largest and grandest State of the United States. It retains the 
>              ^^^^^^^
>>right to fly its flag at the same height as that of the United States. Texas
>>must not be abbreviated, like NJ or RI: NJ fits between Houston and San
>>Antonio, with RI to spare. Al

>Watch out, Texas, or Alaska might split in two and make you the *third*
>largest state!

I believe that I have made this point in the past, but...

I'm not sure that actual Alaskans ever discuss dividing their state. But 
Texans do not, even as a joke. Dem's fight'n words, pard'ner...

In any event, I also maintain that the apparent size of Alaska is due to a 
consipriacy of map-makers and their projections. 

Hop-along-Bob...

R. C. Lacovara, Ph. D.
GeoControl Systems            voice: 713 333 2561
Houston, Texas 77058

Please be advised that there exists a probability P that 
any opinions expressed above are not shared by GeoControl 
or NASA, at least for 1-(1/Avogadro's number) < P < 1.

---------------------------

End of New-News digest
**********************

From Glenn_Tanaka@milstar.sp.trw.com  Mon Jan 30 14:15:36 1995
From: "Glenn Tanaka" <Glenn_Tanaka@milstar.sp.trw.com>
Date: Mon Jan 30 14:15:45 PST 1995
Subject: IO Driver for ACL-II+
Hi there,

I am using VxWorks For Windows 5.1 on a X86 target. I was wondering if anyone
out there has a driver for an Advanced Communication Link (ACL) II+ serial
I/O card. I would appreciate any help. Thank you,

Glenn Tanaka
TRW Space & Electronics
Email: glenn.tanaka@trw.com
Ph#: (310) 812.1461

From maden@aco.psi.ch  Tue Jan 31 01:27:23 1995
From: "David Maden (PSI, CH-5232 Villigen-PSI)" <maden@aco.psi.ch>
Date: Tue Jan 31 01:27:31 PST 1995
Subject: RE: Anyone got DEC VxWorks V3.1
John Birrell asks:

>   Has anyone received V3.1 [of DEC's VxWorks]?

Yes, we have. We took delivery of an AXPvme64 earlier this month (January)
and then discovered that AXP support was not in the VxWorks Vn3.0 which
was the version on our OSF/1 distribution CDROM (OSF/1 Vn 3.0 Rev. 347,
I think). Frantic calls to DEC eventually produced a casette of VxWorks Vn3.1
which we installed.

Low and behold, AXP support was in it, the make files successfully made a
system image and we eventually booted VxWorks over Ethernet into the AXPvme
(after getting all the BOOTP/TFTP setup right on the OSF/1 host). Since then,
we have received a CDROM of the VxWorks Vn3.1 distribution.

I should add that DEC were very helpful in getting us through this startup
phase.

Hope this helps, David Maden, Paul Scherrer Institute, Villigen, Switzerland.

BTW, I wrote a note to document my fight to get the AXPvme booted for the first
time which might be useful to others (I am new to the Unix mentality and
hence, probably, the fight and hence, probably, the note will not be that
useful to others!). Just in case, though, it is accessible on the
international DECnet via VAXnotes as Note 29.1 in conference
20550::TIPS_N_TRICKS. The note is a bit long (there's lots of console log
reproduced for completeness' sake) to publish here. If you want a copy and
can't get it via VAXnotes, e-mail me.

From klf@redifon.demon.co.uk  Tue Jan 31 03:37:46 1995
From: Kieren Feakes <klf@redifon.demon.co.uk>
Date: Tue Jan 31 03:37:54 PST 1995
Subject: Re: MVME167 memory problem

Hi there,

We are using VxWorks version 5.1.1 with a Motorola MVME 167-33A board. If an 
attempt is made to write to any part of a specific 8 kbyte block of memory 
near the top of DRAM a bus error occurs (eg by using the VxWorks "m" command).
The address of the 8 kbyte block appears at a constant offset from the top 
of the on-board memory; with 4 Mbytes of DRAM, the block's address is 
0x3E6000..0x3E7FFF, with 16 Mbytes the address is 0xFE6000..0xFE7FFF.

Does anybody know the reason for this or a way to make this area writable ?

Regards,

Kieren Feakes

################################################################################
Redifon Technology	Phone 	0372-376677
			Fax	0372-379480
			Email	klf@redfion.demon.co.uk
################################################################################

From daemon@vxw.ee.lbl.gov  Tue Jan 31 04:00:27 1995
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 31 04:00:34 PST 1995
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 31 04:00:18 PST 1995

        Subject: Re: What does "workQPanic" mean?
        Subject: ISA/PCI Synchronous Serial Cards
        Subject: Re: GNU GDB for VxWorks

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: What does "workQPanic" mean?
Date: 30 Jan 1995 13:04:09 -0500
From: mroske@rapnet.sanders.lockheed.com (9240)
Organization: Lockheed Sanders
Message-ID: <3gj9mp$f6g@rapnet.sanders.lockheed.com>
References: <CLAUS.95Jan26155914@pepiiu1.SLAC.Stanford.EDU>

Ric Claus (claus@pepiiu1.SLAC.Stanford.EDU) wrote:

: workQPanic: Kernel work queue overflow.

: after running some 7 or 8 application codes in the context of a "shell", all of
: which I wrote.  The application codes handle DSP processor boards that all run

: It sure seems like VxWorks is running out of some resource, but I can't figure
: out what.  When I checkStack after every application invocation, I see that all
: stacks have been used to no more than half the alloted memory.  The INTERRUPT
: stack never uses more than 268 bytes out of 1000.  I see no signs of anything
: being corrupted anywhere.  Perhaps task descriptors aren't being recycled?

: When I memShow after every application invocation, I see that memory usage is
: well bounded and nowhere close to the edge.  Memory usage is application
: dependent, but if I invoke the same application as the one before the previous
: application, memory usage goes back to the same values.  As an aside, I was not
: expecting this to be true because I understood that there was a memory leak
: associated with taskSpawns.  Unless memShow does not properly account for all
: the memory used, I see no leaks due to tasks being created and properly 
: finishing (i.e. not taskDeleted, by me at least).

: It's hard to look around after workQPanic occurs because it causes a reboot.
: I'm also not sure where to look.  I've looked in the VxWorks manuals for what
: this message might mean, but have come up empty handed.  It would be nice if it
: (and a bunch of other things) were in the index...

: The hardware is a 25 MHz Force 40 with 4 Meg and an Eagle 02 (ethernet and VSB)
: running version 5.1.1 VxWorks.

We're running the same board with the same VxWorks.  I have seen the
same error when I try to run a large program directly within the shell.
I found out that using the 'sp' command to spawn the program as a task
eliminated the error.  This gives a default stack size.  If you are
using
taskSpawn to start your application, you might want to try using sp and
see if it works differently.  Let me know how it works out, because we
may run into the same problem when our application is fully developed...

Mike Roske
mroske@mailgw.sanders.lockheed.com

---------------------------

Newsgroups: comp.os.linux.networking,comp.sys.ibm.pc.hardware.networking,comp.os.vxworks
Subject: ISA/PCI Synchronous Serial Cards
Date: 30 Jan 1995 20:54:00 GMT
From: smeg@bnr.ca (Maarten Koning)
Organization: Bell-Northern Research Canada
Keywords: sync, serial, PCI, ISA
Message-ID: <3gjjl8$7ug@bcarh8ab.bnr.ca>
Reply-To: smeg@bnr.ca

Hello,

  I am looking for manufacturers of PCI-based or ISA-based synchronous
  serial interface cards for use in a PC.  If you know of any companies
  that manufacture the interface types listed below, could you please mail
  me their names and/or phone numbers.  Also, if you have any information
  or opinion on the quality/price/performance of those cards, I would be
  interested to hear about that too.

  I am looking for info on synchronous V.11, V.24, V.35, T1/DS1 and E1 cards.

  I will summarize the results to these groups in one week.

Many thanks...

  Maarten Koning (smeg@bnr.ca)

ps. I am *not* looking for information on ISDN, async, ATM or HIPPI cards.

pps. I am *not* looking for information on cards with other buses such as
     VME, SBUS etc.

ppps. Please do not send me 'me too' requests, unless I fail to post the
      summary! ;-)

- -- 
//include1 pgm=disclaimer,parm='my opinions only'
Maarten Koning | Internet:  smeg@bnr.ca        | Phone: (613) 763-8796
BNR Ltd.       |    This space for rent        | FAX:   (613) 763-2626

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GNU GDB for VxWorks
Date: 31 Jan 1995 05:19:54 GMT
From: synergy@nic.cerf.net (John E. Clark)
Organization: CERFnet Dial n' CERF Customer
Message-ID: <3gkh9q$2dm@news.cerf.net>
References: <3g8mih$1hc@fohnix.metronet.com> <3gbdgr$6qf@news.cerf.net> <hjbD3335J.6C0@netcom.com>

In article <hjbD3335J.6C0@netcom.com> hjb@netcom.com (Hwa-Jin Bae) writes:
+In article <3gbdgr$6qf@news.cerf.net>,
+John E. Clark <synergy@nic.cerf.net> wrote:
+>
+>There are a couple of other 'remote' debugging interfaces there as
+>well. One of which will go over a serial line... for the really
+>minimally inclined...
+>
+
+this option is not "minimally inclined".  this actually works much better,
+IMHO.  vxgdb never worked properly every time i attempted to use it in the
+past and most only for task/app debugging (can't do real low level
+debugging), full of bugs in the debugger itself, etc.  but YMMV, again.

My 'minimally inclined' was refering to a system sans 'ethernet'.
As I have never used vxgdb, but rather the 'scratch head' until
bald method with vxworks, until finally someone who liked it came
along.

And low and behold, it's just as well....

---------------------------

End of New-News digest
**********************

From mitchell@harpo.aaec.com  Tue Jan 31 05:56:26 1995
From: mitchell@harpo.aaec.com
Date: Tue Jan 31 05:56:33 PST 1995
Subject: Re: What does "workQPanic" mean?
>Ric Claus (claus@pepiiu1.SLAC.Stanford.EDU) wrote:
>
>
>: workQPanic: Kernel work queue overflow.
>
>: after running some 7 or 8 application codes in the context of a "shell", all
>of
>: which I wrote.  The application codes handle DSP processor boards that all
>run
>
If memory serves correct, this error will be generated if something leaves
IACK asserted even after the appropriate IACK cycle is run.  This could
happen if your DSP card asserts an interrupt and requires some special
handshake other than an IACK (such as writing a control register).  Some
designs two sets of jumpers for interrupts:  one selects which IRQ line to
drive, the other which IACK code to respond to.  If these two settings are
inconsistent, the board will leave IACK asserted (and you may get spurrious
interrupt exceptions - but they might not be printed before the reboot).
Try disabling DSP interrupts.

If your DSP boards can also be VME masters, then life can get more
complicated.  You may want try running your tasks with the DSPs idle or
running something "safe" if the DSP boards normally do VME writes (I had
DSP boards write to both of a MV147's mailbox registers to signal different
events).

>: It sure seems like VxWorks is running out of some resource, but I can't
>figure
>: out what.  When I checkStack after every application invocation, I see that
>all
>: stacks have been used to no more than half the alloted memory.  The INTERRUPT
>: stack never uses more than 268 bytes out of 1000.  I see no signs of anything
>: being corrupted anywhere.  Perhaps task descriptors aren't being recycled?

The work queue is a very low level resource that is involved with the
handling of intterupt events, before they are placed in the INTERRUPT
context, which is why you didn't see anything wrong.  If overflows when
things happen too fast for interrupts to be serviced.  A high intterupt
rate (like a timer interrupting at a 10KHz rate) will also cause this
error.

>
>: When I memShow after every application invocation, I see that memory usage is
>: well bounded and nowhere close to the edge.  Memory usage is application
>: dependent, but if I invoke the same application as the one before the
>previous
>: application, memory usage goes back to the same values.  As an aside, I was
>not
>: expecting this to be true because I understood that there was a memory leak
>: associated with taskSpawns.  Unless memShow does not properly account for all
>: the memory used, I see no leaks due to tasks being created and properly
>: finishing (i.e. not taskDeleted, by me at least).
>

My understanding is that memory "leaks" will occur if the task is spawned
with the context save option, which saves the task info on purpose (so its
not really a leak).  They also occur if string constants are used on the
shell command line.
-> sp myTask,"Hello World\n"
will "leak" 13 bytes for the string storage (only a pointer to the string
goes on the task's stack).

>: The hardware is a 25 MHz Force 40 with 4 Meg and an Eagle 02 (ethernet and
>VSB)
>: running version 5.1.1 VxWorks.

Check for VSB interrupts too while your're at it (assuming DSP boards are
VSB equipped) - though I don't think anybody uses them.

Happy Hunting!

  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace Electronics |  tel: (617) 890-4200
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |  Opinions are my own, not AAEC's

From daly@aries.sbc.anl.gov  Tue Jan 31 06:33:34 1995
From: Bob Daly <daly@aries.sbc.anl.gov>
Date: Tue Jan 31 06:33:41 PST 1995
Subject: RE: Anyone got DEC VxWorks V3.1
I would appreciate info. on booting AXPvme.

Thanks for your help

Bob Daly
Argonne National Lab

return address 
rtd@aps.anl.gov

From lia!lia.com!glenn@netcom.com  Tue Jan 31 17:05:03 1995
From: glenn@lia.com (Glenn Herteg)
Date: Tue Jan 31 17:05:11 PST 1995
Subject: VxWorks/Solaris mounting problem
I am experiencing a problem at a client site, and would like to know if
anyone else has seen this.  The environment is:

    VxWorks ver 4.0.2
    Kernel: PSOS ver 4.1
    PHILE ver 2.11

The client has recently attached Solaris 2.3 machines to his network,
previously containing just SunOS 4 machines.  He has long been able to
export filesystems from the VxWorks machine and mount them under SunOS 4.
But when he tries to mount them under Solaris 2, he gets an error message
like "NFS service not responding".

The problem is all the more mysterious because he is still able to mount
the filesystem under SunOS 4, and is able to ping and rlogin to the VxWorks
machine from Solaris 2; so basic connectivity is assured.  We have already
run into and fixed the problem with root being, by default, in too many
groups (/etc/group; > 8) under Solaris 2, which yielded messages about
client authentication failures.  But now we are stumped.

Any clues out there?

Glenn Herteg
IA Corporationi
glenn@lia.com

From thor@thor.atd.ucar.edu  Tue Jan 31 23:00:26 1995
From: thor@thor.atd.ucar.edu (Rich Neitzel)
Date: Tue Jan 31 23:00:34 PST 1995
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
------------------------------------------------
VxWorks sources:

total 13650
lrwxrwxrwx   1 thor     other          5 Dec 16 17:31 README -> index
-rw-r--r--   1 thor     other      22132 Sep 20 07:52 ansi.p1
-rw-r--r--   1 thor     other      22717 Sep 20 07:52 ansi.p2
-rw-r--r--   1 thor     other      24174 Sep 20 07:52 ansi.p3
-rw-r--r--   1 thor     other       8108 Sep 20 07:52 ansi.patch1
-rw-r--r--   1 thor     other      37126 Sep 20 07:52 ansilib01
-rw-r--r--   1 thor     other      18913 Sep 20 07:52 ansilib02
-rw-r--r--   1 thor     other       2671 Sep 20 07:52 benchmarks
-rw-r--r--   1 thor     other       7168 Sep 20 07:52 bitcnt
-rw-r--r--   1 thor     other      11437 Sep 20 07:52 c++builtin.shar
-rw-r--r--   1 thor     other      22330 Sep 20 07:52 c++headers.p1
-rw-r--r--   1 thor     other      22775 Sep 20 07:52 c++headers.p2
-rw-r--r--   1 thor     other      29052 Sep 20 07:52 camaclib1
-rw-r--r--   1 thor     other      25095 Sep 20 07:52 camaclib2
-rw-r--r--   1 thor     other      31005 Sep 20 07:52 camaclib3
-rw-r--r--   1 thor     other      37770 Sep 20 07:52 cbench.shar
-rw-r--r--   1 thor     other       7371 Sep 20 07:52 cntsem_class.shar
-rw-r--r--   1 thor     other       5853 Sep 20 07:52 crc.shar
-rw-r--r--   1 thor     other       8917 Sep 20 07:52 deadman.shar
-rw-r--r--   1 thor     other      41669 Sep 20 07:52 dhrystones01
-rw-r--r--   1 thor     other      19170 Sep 20 07:52 dirlib01
-rw-r--r--   1 thor     other      25681 Sep 20 07:52 dt1451
-rw-r--r--   1 thor     other       4905 Sep 20 07:53 dup.shar
-rw-r--r--   1 thor     other       5944 Sep 20 07:52 fcompress.shar
-rw-r--r--   1 thor     other      11561 Sep 20 07:53 flags_class.shar
-rw-r--r--   1 thor     other      88109 Sep 20 07:53 flash.zip
-rw-r--r--   1 thor     other      44762 Sep 20 07:53 force.p1
-rw-r--r--   1 thor     other      40154 Sep 20 07:53 force.p2
-rw-r--r--   1 thor     other      80491 Sep 20 07:53 force.shar
-rw-r--r--   1 thor     other       2453 Sep 20 07:53 gcc+68040
-rw-r--r--   1 thor     other       6106 Sep 20 07:53 getdate
-rw-r--r--   1 thor     other       9774 Sep 20 07:53 hkv30extintutil.shar
-rw-r--r--   1 thor     rsf        24394 Jan 31 15:04 index
-rw-r--r--   1 thor     other       2694 Sep 20 07:53 ivecalloc.shar
-rw-r--r--   1 thor     other      35245 Sep 20 07:53 joblib2.p1
-rw-r--r--   1 thor     other      18110 Sep 20 07:53 joblib2.p2
-rw-r--r--   1 thor     other       9079 Sep 20 07:53 lclflag.shar
-rw-r--r--   1 thor     other     174829 Sep 20 07:53 lexyacc.tar.gz
drwxr-xr-x   2 thor     other        512 Sep 20 07:53 libX11
-rw-r--r--   1 thor     rsf        14059 Nov  4 16:03 libg++-2.6.1.patch
-rw-r--r--   1 thor     rsf         1302 Nov 23 10:34 libgcc2-2.6.2.patch
-rw-r--r--   1 thor     rsf         1862 Dec 29 10:50 libgcc2-2.6.3.patch
-rw-r--r--   1 thor     rsf         1222 Nov  4 16:03 libio-2.6.1.patch
-rw-r--r--   1 thor     rsf          277 Nov  4 16:03 libobjc.patch
drwxr-xr-x   2 thor     other        512 Sep 20 07:53 libx11
-rw-rw-r--   1 ftp      other       3515 Nov  2 15:29 loadmeter.shar
-rw-r--r--   1 thor     other      10399 Sep 20 07:53 math.shar
-rw-r--r--   1 thor     other      11950 Sep 20 07:53 math2
-rw-r--r--   1 thor     other      26655 Sep 20 07:53 monitor.shar
-rw-r--r--   1 thor     other      18733 Sep 20 07:53 msgque_class.shar
-rw-r--r--   1 thor     other     829713 Sep 20 07:53 ntpv3.1.tar.gz
-rw-r--r--   1 thor     other    1010176 Sep 20 07:53 ntpv3.tar.gz
-rw-r--r--   1 thor     other       1082 Sep 20 07:53 objc.patch
-rw-r--r--   1 thor     other      19422 Sep 20 07:53 ping01
-rw-r--r--   1 thor     other      20494 Sep 20 07:53 pipe.shar
-rw-r--r--   1 thor     other      15418 Sep 20 07:53 poolLib
-rw-r--r--   1 thor     other      15418 Sep 20 07:53 poollib
-rw-r--r--   1 thor     other      13204 Sep 20 07:53 ring.shar
-rw-r--r--   1 thor     other       6614 Sep 20 07:53 semCnt
-rw-r--r--   1 thor     other       6614 Sep 20 07:53 semcnt
-rw-r--r--   1 thor     rsf        48659 Dec  2 10:25 snmp2.01
-rw-r--r--   1 thor     rsf        48658 Dec  2 10:25 snmp2.02
-rw-r--r--   1 thor     rsf        48666 Dec  2 10:25 snmp2.03
-rw-r--r--   1 thor     rsf        48723 Dec  2 10:25 snmp2.04
-rw-r--r--   1 thor     rsf        48869 Dec  2 10:25 snmp2.05
-rw-r--r--   1 thor     rsf        48632 Dec  2 10:25 snmp2.06
-rw-r--r--   1 thor     rsf        48658 Dec  2 10:25 snmp2.07
-rw-r--r--   1 thor     rsf        48652 Dec  2 10:25 snmp2.08
-rw-r--r--   1 thor     rsf        48714 Dec  2 10:25 snmp2.09
-rw-r--r--   1 thor     rsf        48615 Dec  2 10:25 snmp2.10
-rw-r--r--   1 thor     rsf        49185 Dec  2 10:25 snmp2.11
-rw-r--r--   1 thor     rsf        49214 Dec  2 10:25 snmp2.12
-rw-r--r--   1 thor     rsf        49203 Dec  2 10:25 snmp2.13
-rw-r--r--   1 thor     rsf        49239 Dec  2 10:25 snmp2.14
-rw-r--r--   1 thor     rsf        49176 Dec  2 10:25 snmp2.15
-rw-r--r--   1 thor     rsf        49216 Dec  2 10:25 snmp2.16
-rw-r--r--   1 thor     rsf        49182 Dec  2 10:25 snmp2.17
-rw-r--r--   1 thor     rsf        49188 Dec  2 10:25 snmp2.18
-rw-r--r--   1 thor     rsf        49189 Dec  2 10:25 snmp2.19
-rw-r--r--   1 thor     rsf        49200 Dec  2 10:25 snmp2.20
-rw-r--r--   1 thor     rsf        48646 Dec  2 10:25 snmp2.21
-rw-r--r--   1 thor     rsf        48671 Dec  2 10:25 snmp2.22
-rw-r--r--   1 thor     rsf        49229 Dec  2 10:25 snmp2.23
-rw-r--r--   1 thor     rsf        49235 Dec  2 10:25 snmp2.24
-rw-r--r--   1 thor     rsf        49268 Dec  2 10:25 snmp2.25
-rw-r--r--   1 thor     rsf        48682 Dec  2 10:25 snmp2.26
-rw-r--r--   1 thor     rsf        49223 Dec  2 10:25 snmp2.27
-rw-r--r--   1 thor     rsf        48676 Dec  2 10:25 snmp2.28
-rw-r--r--   1 thor     rsf        48818 Dec  2 10:25 snmp2.29
-rw-r--r--   1 thor     rsf        49308 Dec  2 10:25 snmp2.30
-rw-r--r--   1 thor     rsf        49294 Dec  2 10:25 snmp2.31
-rw-r--r--   1 thor     rsf        48634 Dec  2 10:26 snmp2.32
-rw-r--r--   1 thor     rsf        48708 Dec  2 10:26 snmp2.33
-rw-r--r--   1 thor     rsf        49055 Dec  2 10:26 snmp2.34
-rw-r--r--   1 thor     rsf        48724 Dec  2 10:26 snmp2.35
-rw-r--r--   1 thor     rsf        48736 Dec  2 10:26 snmp2.36
-rw-r--r--   1 thor     rsf        48667 Dec  2 10:26 snmp2.37
-rw-r--r--   1 thor     rsf        48626 Dec  2 10:26 snmp2.38
-rw-r--r--   1 thor     rsf        48653 Dec  2 10:26 snmp2.39
-rw-r--r--   1 thor     rsf        14122 Dec  2 10:26 snmp2.40
-rw-r--r--   1 thor     other       2308 Sep 20 07:53 ss1.bnch
-rw-r--r--   1 thor     other      41196 Sep 20 07:53 stevie01
-rw-r--r--   1 thor     other      35279 Sep 20 07:53 stevie02
-rw-r--r--   1 thor     other      35278 Sep 20 07:53 stevie03
-rw-r--r--   1 thor     other      35012 Sep 20 07:53 stevie04
-rw-r--r--   1 thor     other      34502 Sep 20 07:53 stevie05
-rw-r--r--   1 thor     other      37476 Sep 20 07:53 stevie06
-rw-r--r--   1 thor     other      30073 Sep 20 07:53 stevie07
-rw-r--r--   1 thor     other      31562 Sep 20 07:53 stevie08
-rw-r--r--   1 thor     other      37360 Sep 20 07:53 stevie09
-rw-r--r--   1 thor     other      20662 Sep 20 07:53 stevie10
-rw-r--r--   1 thor     other      25717 Sep 20 07:53 stevie11
-rw-r--r--   1 thor     other      28075 Sep 20 07:53 stevie12
-rw-r--r--   1 thor     other      31852 Sep 20 07:53 stevie13
-rw-r--r--   1 thor     other      16225 Sep 20 07:53 string.shar
-rw-r--r--   1 thor     other       8424 Sep 20 07:53 syslog.shar
-rw-r--r--   1 thor     other      15096 Sep 20 07:53 task_class.shar
-rw-r--r--   1 thor     other      16171 Sep 20 07:53 taskmon.shar
-rw-rw-r--   1 thor     other     417608 Jan 31 14:43 tclvx7.0v5.tar.gz
-rw-r--r--   1 thor     other      10523 Sep 20 07:53 tod.shar
-rw-r--r--   1 thor     other      19912 Sep 20 07:53 tp41.shar
-rw-r--r--   1 thor     other      25790 Sep 20 07:53 ty335.shar
-rw-r--r--   1 thor     other      44504 Sep 20 07:53 usrTime.shar
-rw-r--r--   1 thor     other      44504 Sep 20 07:53 usrtime.shar
-rw-r--r--   1 thor     other       4945 Sep 20 07:53 veclist01
-rw-r--r--   1 thor     other      25814 Sep 20 07:53 vtape.shar
-rw-r--r--   1 thor     other      43671 Sep 20 07:53 vwcurses01
-rw-r--r--   1 thor     other      40180 Sep 20 07:53 vwcurses02
-rw-r--r--   1 thor     other      38308 Sep 20 07:53 vwcurses03
-rw-r--r--   1 thor     other      31181 Sep 20 07:53 vwcurses04
-rw-r--r--   1 thor     other      31798 Sep 20 07:53 vwcurses05
-rw-r--r--   1 thor     other      31459 Sep 20 07:53 vwcurses06
-rw-r--r--   1 thor     other      24279 Sep 20 07:53 vwcurses07
-rw-r--r--   1 thor     rsf         4973 Nov  4 16:01 vx_cplusplus
-rw-r--r--   1 thor     other      40485 Sep 20 07:53 vxrouted01
-rw-r--r--   1 thor     other      40512 Sep 20 07:53 vxrouted02
-rw-r--r--   1 thor     other      40482 Sep 20 07:53 vxrouted03
-rw-r--r--   1 thor     other      40472 Sep 20 07:53 vxrouted04
-rw-r--r--   1 thor     other      40526 Sep 20 07:53 vxrouted05
-rw-r--r--   1 thor     other      40540 Sep 20 07:53 vxrouted06
-rw-r--r--   1 thor     other      40552 Sep 20 07:53 vxrouted07
-rw-r--r--   1 thor     other      22675 Sep 20 07:53 vxrouted08
-rw-r--r--   1 thor     other      29720 Sep 20 07:53 vxrsh.p1
-rw-r--r--   1 thor     other      26002 Sep 20 07:53 vxrsh.p2
-rw-r--r--   1 thor     other      13713 Sep 20 07:53 vxrsh.p3
-rw-r--r--   1 thor     other       4702 Sep 20 07:53 wdog_class
-rw-r--r--   1 thor     other      40860 Sep 20 07:53 xmodem.01
-rw-r--r--   1 thor     other      40463 Sep 20 07:53 xmodem.02
-rw-r--r--   1 thor     other      40403 Sep 20 07:53 xmodem.03
-rw-r--r--   1 thor     other      40451 Sep 20 07:53 xmodem.04
-rw-r--r--   1 thor     other      40721 Sep 20 07:53 xmodem.05
-rw-r--r--   1 thor     other       9333 Sep 20 07:53 xmodem.06