From mea@sparta.com  Tue Sep  1 05:19:43 1992
From: mea@sparta.com (Mike Anderson)
Date: Tue Sep  1 05:19:51 PDT 1992
Subject: Re: general info needed
> 
> Submitted-by ramos@mtunm.att.com  Mon Aug 31 16:21:44 1992
> Submitted-by: ramos@mtunm.att.com
>  
> We're looking into using either VxWorks or pSOS+ on a intel i960-based 
> embedded system dedicated to communications processing.  I have experience 
> as an application builder on pSOS+ and have access to people who got pSOS+
> running on a custom hardware platform.  Unfortunately, 
> I don't know anyone with VxWorks experience.  My questions are these:
> 
> 1) How hard is it to get VxWorks running on a custom platform using the 
>    porting kit and how does it compare to pSOS+?

The folks to ask about this are Hughes Network Systems in Gaithersburg.
My company supplied them the Heurikon i960s and got their software
folks up and running on i960s under VxWorks while their hardware folks
got their custom boards fabbed.  They then did the port to their new 
platform and its been operational for several months.  They also
did a complete trade study on PSOS+ vs. VxWorks before starting on this
project and chose VxWorks hands down.  I think that one of the key factors
was Intel's support of VxWorks and the GNU environment.

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

We use the i960 almost exclusively for all of our synchronous protocol
jobs.  The on-chip DMA and the kernel support is excellent and the software
speed picks up with each new rev.  For example, we started in late 1990
with Heurikon i960s (33 MHz i960CAs) that did about 7K dhrystones.  Without
changeing the hardware at all we are now at 25K dhrystones.  All of that
through subsequent revs to VxWorks and the GNU compiler.  As far as robustness
and bugs are concerned, I frankly feel that the i960 version of VxWorks is
more bug-free (largely owing to HNS and Intel hammering the kernel to
death) than the 68K flavors of VxWorks.  With Heurikon's new Rev 3 boards
you can even avoid the big-endian/little-endian problems 'cause they have
hardware to do the byte swaps.

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

We do up to 8 channel serial I/O via Xycom XVME-400 boards and via the
4 on-board ports in both async and sync (HDLC, SDLC, BiSync and
Monosync) using the 8530 SCC chips on a single i960.  We had to write
all the protocols ourselves but the mechanisms to support framing and
all of the bit/byte level interrupts is already provided in VxWorks. 
A couple of quick ioctl hacks to the tyCo drivers supplied in source with
the boards and you've got sync comm.

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

I don't have use the debuggers ;-).  Truthfully, I find that the GNU
environment for debugging is much more friendly than the XRAY+ and
just as easy to use.  I run the xVxGdb from my PC under PC-Xview and it works
like a charm.  The ability to interact with the shell directly is an
important tool in itself.  You can do things just like you were a 
program and then save it off to a file to be compiled.  Much more
friendly than dealing strictly through XRAY.



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

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================



From pdw@sunbar.mc.duke.edu  Tue Sep  1 07:09:30 1992
From: pdw@sunbar.mc.duke.edu (Patrick D. Wolf)
Date: Tue Sep  1 07:09:37 PDT 1992
Subject: NFS file server for vxWorks SCSI Disks

Has anybody written a file server for a vxWorks SCSI Disk. I realize there
are problems mixing real time and NFS Server functions but I would settle
for read only. So, what I am looking for is a way to NFS mount for reading,
disks that are located on my vxWorks target from my Sun host. Any
suggestions or code would be welcome.

Patrick Wolf
pdw@sunbar.mc.duke.edu
919-660-5114
Duke University Medical Center




From bobf@verdix.com  Tue Sep  1 07:46:33 1992
From: Bob Foery <bobf@verdix.com>
Date: Tue Sep  1 07:46:40 PDT 1992
Subject: Re: NFS file server for vxWorks SCSI Disks 

>Has anybody written a file server for a vxWorks SCSI Disk. I realize there
are problems mixing real time and NFS Server functions but I would settle
for read only. So, what I am looking for is a way to NFS mount for reading,
disks that are located on my vxWorks target from my Sun host. Any
suggestions or code would be welcome.

Patrick,

This question has come up a few times in the past.  Enclosed are extracts
from previous posts.

I recently grabbed SOS from Simtel20.  If you would like a copy, I'd be happy
to send it to you.

Hope this helps,

Bob Foery
Verdix Corporation
bobf@verdix.com

=============================================================================
Submitted-by omni!hwajin@apple.com  Fri Oct 25 15:26:03 1991
Submitted-by: hwajin@omni.com (Hwa-Jin Bae)

>PC-based NFS SERVER?  I've seen many NFS CLIENTS on PC's (not running unix)
>but not many (or any) SERVERS.  If a pc is running NFS SERVER code it is
>significantly (in complexity) beyond being a BOOTP server.

FYI, a GNU copylefted NFS server for MS-DOG exists.
It's called SOS and written by none other than some people at LBL.
=============================================================================
Submitted-by mea@sparta.com  Mon Jan 20 09:07:52 1992
Submitted-by: mea@sparta.com (Mike Anderson)

Greetings!

  There's a public domain NFS Server implementation called SOS (Steve's Own
Server, I believe) that runs on PCs using PC-NFS.  Its available from
the Simtel20 anonymous FTP archives in the UNIX-C directories.  It doesn't
target VxWorks directly, but it is source that should come close.

Good Luck and please send a working version to the user's group archives,
=============================================================================



From hill@luke.atdiv.lanl.gov  Tue Sep  1 09:19:43 1992
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Tue Sep  1 09:19:50 PDT 1992
Subject: Re: task switch hook

> > 
> >Has anyone tested the task switch hook routines in Vx...
> 
> I hooked a small routine that would write the Id of tasks being switched in
> and out to a fixed location in global (VME) RAM. 

I wrote a similar code which reported the task id of each task modifying
a set of contiguous bytes.

Jeff


From daemon@vxw.ee.lbl.gov  Wed Sep  2 04:00:49 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep  2 04:00:56 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep  2 04:00:42 PDT 1992

        Subject: C++ development
        Subject: how to implement a controller (aka need to periodically trigger task)
        Subject: MIPS port
        Subject: RARP for vxworks
        Subject: 68040 A32D16 gotcha

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

Newsgroups: comp.os.vxworks
Subject: C++ development
Date: Mon, 31 Aug 1992 22:14:18 GMT
From: heidelgs@ntmtv.UUCP (Greg Heidel)
Organization: Northern Telecom Inc, Mountain View, CA
Message-ID: <1992Aug31.221418.15438@ntmtv>
Sender: heidelgs@ntmtv (Greg Heidel)

I have read on the net that several companies have ported the GNU C++ compiler
to VxWorks.  I am interested in what debugging capabilities are available
when developing in this environment (both source-level and run-time).

...thanks for any info

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

Newsgroups: comp.os.vxworks
Subject: how to implement a controller (aka need to periodically trigger task)
Date: Tue, 1 Sep 1992 16:45:10 GMT
From: doctor@kronos.arc.nasa.gov (Terry Fong)
Organization: NASA/ARC Information Sciences Division
Keywords: controller, 5.0.2
Message-ID: <1992Sep1.164510.27845@kronos.arc.nasa.gov>
Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov)

Hi all,

This may be a FAQ item (is there one for this group?), but I'd like to
hear some opinions on a question:

  Using VxWorks 5.0.2, what is the best way to implement a digital 
  controller? In other words, what is the best approach to get a 
  task to trigger at a specific frequency (i.e., 10-100 Hz) such that
  system resources are minimally used? Do you setup an ISR off of the
  clock to signal (or semaphore) a pended task? Do you use watchdog
  timers repeatedly? Do you run a task at a high priority and let it
  poll a timer?

Please send any/all responses to:  terry@ptolemy.arc.nasa.gov

I'll post a summary of the answers I receive. Thanks in advance!

- -Terry

 





- -- 
_______________________________________________________________________________
 "You do not understand anything     | Terry Fong <terry@ptolemy.arc.nasa.gov>
  until you understand it in more    | NASA Ames, M/S 269-3, Moffett Field, CA
  than one way..." -- Marvin Minsky  | (415) 604-6063, FTS-464-6063

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

Newsgroups: comp.os.vxworks
Subject: MIPS port
Date: Tue, 1 Sep 1992 23:17:15 GMT
From: smd@s1.gov (Scott M. Denton)
Organization: Lawrence Livermore Laboratory, Livermore  CA
Message-ID: <1992Sep1.231715.28356@s1.gov>
Reply-To: smd@s1.gov (Scott M. Denton)
Sender: usenet@s1.gov


Where would I find a sample VxWorks port to the MIPS R3000?

Thanks,
Scott Denton

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

Newsgroups: comp.os.vxworks
Subject: RARP for vxworks
Date: Tue, 01 Sep 92 23:57:05 GMT
From: dbander@netcom.com (David B. Andersen)
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Message-ID: <27jn4#j.dbander@netcom.com>
Sender:  David B. Andersen

Many is the time I have wished that vxWorks supported RARP.  When I ship
a product it is a real pain to make sure that some piece of non-volatile
memory has the proper inet address.  It is also difficult to have to 
describe to a customer how to change a product's inet address.

So why is it that Wind River does not have support for RARP?  Has anybody
whipped up their own version of RARP that they would be willing to share?

Thanks in advance.




- -- 
/------------------------------------------------------------------\
|     David B. Andersen             (dbander@netcom.com)           |
\------------------------------------------------------------------/

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

Newsgroups: comp.os.vxworks
Subject: 68040 A32D16 gotcha
Date: 2 Sep 92 02:17:30 GMT
From: flash@austin.lockheed.com (James W. Melton)
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744
Message-ID: <1181@shrike.com>

Recently, we had the joy of porting a small, custom device driver
that was developed on an MV147 to a Tadpole TP41. There was a
little gotcha that should be of interest to the net at large.

The device is an ancient beast that operates in the A32D16 VME
space. We have 1 register that contains a 32 bit value.
Apparently, (according to a guy at Tadpole), prior versions of the
680x0 processor family would detect if a 32-bit write was destined
for a D16 address and break the transfer into two 16-bit transfers
to sequential word addresses. Not so with the 68040. If you ask for
a 32-bit write to an address, it attempts to comply. If the target
address is in D16 space, only the low-order 16 bits will be written
to the target address.

If all the technical details are incorrect, please free to correct
me. The bottom line is, when in D16, only do 16-bit transfers.

- ----
- -- 
Jim Melton, novice guru
email:      flash@austin.lockheed.com | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"

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

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


From daemon@vxw.ee.lbl.gov  Thu Sep  3 04:01:31 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep  3 04:01:39 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep  3 04:01:25 PDT 1992

        Subject: Good book on VxWorks?
        Subject: Wanted: sample DMA routines
        Subject: vxWorks for the R3000

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

Newsgroups: comp.os.vxworks
Subject: Good book on VxWorks?
Date: 2 Sep 92 16:32:17 GMT
From: rajiv@bongo.cc.utexas.edu (Rajiv Arora)
Organization: The University of Texas at Austin, Austin TX
Message-ID: <78937@ut-emx.uucp>
Reply-To: rajiv@bongo.cc.utexas.edu (Rajiv Arora)
Sender: news@ut-emx.uucp


Until a few hours ago, I had never heard about VxWorks. Can anyone recommend a
good book that describes the philosophy of VxWorks--I presume it is some kind
of real-time OS? Also, is VRTX a similar OS?

I'm looking for references to get a general understanding of these OS's, not a
detailed description. Any help would be appreciated.


- -- 
******************************************************************************
* Rajiv Arora			Email: rajiv@bongo.cc.utexas.edu	     *
*				Phone: (512) 795-9015			     *
******************************************************************************

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

Newsgroups: comp.os.vxworks
Subject: Wanted: sample DMA routines
Date: 2 Sep 1992 16:34:31 GMT
From: jclesius@bbn.com (Jeff Clesius)
Keywords: MVME167, DMA
Message-ID: <la9r8nINNct9@news.bbn.com>


Does anyone know of any sample routines available for DMA transfer
using the VMEchip2 on a Motorola MVME167?  I am conducting an evaluation
of the board and it would be nice to check out the performance of the
on-board DMA.


Thanks (in advance),
Jeff Clesius  (jclesius@bbn.com)
BBN Systems and Technologies
50 Enterprise Center, Suite 200
Middletown, RI 02840-5202
(401) 849-2543 (voice)
(401) 849-8611 (fax)

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

Newsgroups: comp.os.vxworks
Subject: vxWorks for the R3000
Date: 2 Sep 92 13:52:45 GMT
From: junel@bilbo.heurikon.com (June Liesch)
Organization: Heurikon Corporation, Madison, WI
Message-ID: <1686@heurikon.heurikon.com>
Reply-To: junel@heurikon.heurikon.com (June Liesch)
Sender: news@heurikon.heurikon.com



>Where would I find a sample VxWorks port to the MIPS R3000?
>
>Thanks,
>Scott Denton

You could get a demo (or purchase) vxWorks 5.0.5-beta2 for the
R3000 from Heurikon Corporation (1-800-327-1251). 

June

- --------------------------------------------------------------------------------
June Liesch                |  "I don't think much of our profession, but con-
Software Customer Support  |  trasted with respectability, it's comparatively
Heurikon Corporation       |  honest."  - The Pirate King, from G&S's
junel@heurikon.com         |              "The Pirates of Penzance" 
- --------------------------------------------------------------------------------

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

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


From mea@sparta.com  Thu Sep  3 13:15:37 1992
From: mea@sparta.com (Mike Anderson)
Date: Thu Sep  3 13:15:57 PDT 1992
Subject: DDCMP Drivers
Greetings!

  I remember back last June there was some interest in finding DDCMP
drivers for VxWorks.  Did anyone have any success?  If so, I'd like
to hear about it 'cause a friend of mine was curious about hooking
up to VAXen using this protocol.

Thanks,


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

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================



From daemon@vxw.ee.lbl.gov  Fri Sep  4 04:01:32 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Sep  4 04:01:39 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Sep  4 04:01:26 PDT 1992

        Subject: Re: RARP for vxworks

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

Newsgroups: comp.os.vxworks
Subject: Re: RARP for vxworks
Date: 3 Sep 92 15:52:58 EST
From: els@icf.hrb.com (Eric L. Schott)
Organization: HRB Systems, Inc.
Message-ID: <1992Sep3.155259.19519@icf.hrb.com>
References: <27jn4#j.dbander@netcom.com>

In article <27jn4#j.dbander@netcom.com>, dbander@netcom.com (David B. Andersen) writes:
> Many is the time I have wished that vxWorks supported RARP.  When I ship
> a product it is a real pain to make sure that some piece of non-volatile
> memory has the proper inet address.  It is also difficult to have to 
> describe to a customer how to change a product's inet address.

RARP would be nice.  However, RARP does not address the issue
of board swaps.  That is, when a board fails, the bootparams file
would need updated.  It would be nice if the application could have
control of the address broadcast.  For example, I could use a value
from the printer port to uniquely identify a board.
- -- 

Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"

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

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


From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Fri Sep  4 06:38:11 1992
From: Carl Lacy <lacy@draper.com>
Date: Fri Sep  4 06:38:18 PDT 1992
Subject: Driver for Excaliber 1553
   Would anyone have or know of a VxWorks driver for the Excaliber
EXC-1553-C bus interface board?

					Thanks for info,

					Carl Lacy,  MS 3F
					Charles Stark Draper Laboratory
					555 Technology Square
					Cambridge, Mass.   02139
					   (617) 258-3228
					   (617) 258-1880 (fax)
					   lacy@coyote.draper.com
				


From shaffer@stef.crd.ge.com  Fri Sep  4 12:12:13 1992
From: shaffer@stef.crd.ge.com (Phil Shaffer)
Date: Fri Sep  4 12:12:33 PDT 1992
Subject: MK48T08 TIme-of-Day Chip Interface Code
Has anyone written interface code for the MK48T08 (or MK48T02 or MK48T12)
Timekeeper RAM chip? This chip provides time-of-day (seconds through
year) as well as non-volatile RAM, and is widely used on processor
cards.  In particular, I would be interested in C functions to:
 - set or display the time and date, e.g. as in the Unix date command;
 - read the time, e.g. as in the Unix time() or ftime() functions;
 - a version of calendarHostInit() to start the Ada calendar from the
   MK48Txx, rather than from a Unix host (for VADSworks).

I would think this code would be of wide interest because of the
frequency of use of this chip. I didn't seen anything that looked likely
in the vxWorks archive.

Thanks in advance for any help.

     Phillip L. Shaffer                  shaffer_phillip@ae.ge.com
     GE Aircraft Engines, MS A320
     1 Neumann Way
     Cincinnati, OH 45215


From hebo@mbari.org  Fri Sep  4 14:23:47 1992
From: Bob Herlien <hebo@mbari.org>
Date: Fri Sep  4 14:23:54 PDT 1992
Subject: Re: MK48T08 TIme-of-Day Chip Interface Code
Phil,

Get my NTP port from files ntpvx* on the archives at thor.atd.ucar.edu.
When you unpack it, you'll find two subdirectories.  ./ntp contains the
NTP port itself, which you probably don't need.  ./usrTime contains a set
of Unix-compatible time functions, including gettimeofday(), settimeofday(),
time(), stime(), adjtime(), asctime(), ctime(), gmtime(), and localtime().

To use the usrTime functions, you need to implement just two functions for
your clock hardware:  rtc_read() and rtc_write().  However, the library as
shipped contains drivers for the MKT02 chip as implemented on the SBE VPU-30
CPU board, since that's the hardware we're using.

It's all explained in the README file.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org
"Limit congressmen to two terms.  One in office.  One in jail."


From csibtfr!tims@apple.com  Fri Sep  4 14:53:57 1992
From: csibtfr!tims@apple.com (Tim Seaman)
Date: Fri Sep  4 14:54:07 PDT 1992
Subject: Re:  MK48T08 TIme-of-Day Chip Interface Code

----- Begin Included Message -----

shaffer@stef.crd.ge.com writes...

Has anyone written interface code for the MK48T08 (or MK48T02 or MK48T12)
Timekeeper RAM chip? This chip provides time-of-day (seconds through
year) as well as non-volatile RAM, and is widely used on processor
cards.  In particular, I would be interested in C functions to:
 - set or display the time and date, e.g. as in the Unix date command;
 - read the time, e.g. as in the Unix time() or ftime() functions;
 - a version of calendarHostInit() to start the Ada calendar from the
   MK48Txx, rather than from a Unix host (for VADSworks).

I would think this code would be of wide interest because of the
frequency of use of this chip. I didn't seen anything that looked likely
in the vxWorks archive.

Thanks in advance for any help.

     Phillip L. Shaffer                  shaffer_phillip@ae.ge.com
     GE Aircraft Engines, MS A320
     1 Neumann Way
     Cincinnati, OH 45215

----- End Included Message -----

We have some simple code here which we use to program and
retrieve time/date information using the MK48T02 on a Tadpole
TP32V CPU Board. 


/* %W%	%G%                              -*- Mode: C -*- 
 * 
 * Copyright (c) Condor Systems Inc.
 * 
 * mk48t02.c
 * 
 * Description     : 
 * 
 * Author          : Tim Seaman
 * Created On      : Fri Sep  4 14:30:13 1992
 * Last Modified By: Tim Seaman
 * Last Modified On: Fri Sep  4 14:31:13 1992
 * 
 * VERSION   SPR   MODIFIER   DATE AND TIME
 * 
 */

#include "vxWorks.h"

typedef struct
	{
	int	hour;			/* 0 - 23 */
	int	minute;			/* 0 - 59 */
	int	second;			/* 0 - 59 */
	int	hundredthSec;		/* 0 - 99 */
	} SYS_TIME;

typedef struct
	{
	int	year;			/* 1990 - 2089 */
	int	month;			/* 1 - 12 */
	int	day;			/* 1 - 31 */
	int	dayOfWeek;		/* 1 - 7, Sun = 1 */
	} SYS_DATE;

/* MK48T02 RTC stuff for Tadpole TP32V */

#define RTC_ADDR_0	((char *) 0x004007f8)	/* RTC Register 0 - Control & Cal */
#define RTC_ADDR_1	((char *) 0x004007f9)	/* RTC Register 1 - Seconds + ST */
#define RTC_ADDR_2	((char *) 0x004007fa)	/* RTC Register 2 - Minutes */
#define RTC_ADDR_3	((char *) 0x004007fb)	/* RTC Register 3 - Hour + KS */
#define RTC_ADDR_4	((char *) 0x004007fc)	/* RTC Register 4 - Day-of-Week + FT */
#define RTC_ADDR_5	((char *) 0x004007fd)	/* RTC Register 5 - Day-of-Month */
#define RTC_ADDR_6	((char *) 0x004007fe)	/* RTC Register 6 - Month */
#define RTC_ADDR_7	((char *) 0x004007ff)	/* RTC Register 7 - Year */

#define RTC_WR_BIT	0x80				/* write bit */
#define RTC_RD_BIT	0x40				/* read bit */
#define RTC_CONTROL_CAL_VALUE	0x00	/* current calibration value */

/* forward references */

static void writeTpRtc();
static void readTpRtc();
static void intToBcd();
static int bcdToInt();


/*******************************************************************************
 *
 * timeDateSet - set time and date
 *
 * Returns:  OK if success, else ERROR
 *
 */
STATUS
timeDateSet(pTime, pDate)
    SYS_TIME *pTime;			/* ptr to time data */
    SYS_DATE *pDate;			/* ptr to date data*/
{
	unsigned char bcdData[7];
	
	/* Convert SYS_TIME and SYS_DATE info to bcd for RTC */

	/* hundredthSec ignored, since TP32V doesn't support it */

	intToBcd(pTime->second, &bcdData[0], 2);
	bcdData[0] &= 0x7f;
	intToBcd(pTime->minute, &bcdData[1], 2);
	bcdData[1] &= 0x7f;
	intToBcd(pTime->hour, &bcdData[2], 2);
	bcdData[2] &= 0x3f;
	intToBcd(pDate->dayOfWeek, &bcdData[3], 2);
	bcdData[3] &= 0x07;
	intToBcd(pDate->day, &bcdData[4], 2);
	bcdData[4] &= 0x3f;
	intToBcd(pDate->month, &bcdData[5], 2);
	bcdData[5] &= 0x1f;
	intToBcd((pDate->year % 100), &bcdData[6], 2);
	bcdData[6] &= 0xff;

	writeTpRtc(bcdData);
	
    return (OK);
}


/*******************************************************************************
 *
 * timeDateGet - get time and date
 *
 * Returns: OK if success, else ERROR
 *
 */
STATUS
timeDateGet(pTime, pDate)
    register SYS_TIME *pTime;		/* ptr to where time is returned */
    register SYS_DATE *pDate;		/* ptr to where date is returned */
{
	unsigned char bcdData[7];

	readTpRtc(bcdData);

    pTime->hundredthSec = 0;
    pTime->second       = bcdToInt(bcdData[0] & 0x7f);
    pTime->minute       = bcdToInt(bcdData[1] & 0x7f);
    pTime->hour 		= bcdToInt(bcdData[2] & 0x3f);
    pDate->dayOfWeek 	= bcdToInt(bcdData[3] & 0x07);
    pDate->day 			= bcdToInt(bcdData[4] & 0x3f);
    pDate->month 		= bcdToInt(bcdData[5] & 0x1f);
    pDate->year 		= bcdToInt(bcdData[6] & 0xff);

    if (pDate->year > 89)			/* then 20th century */
	pDate->year += 1900;
    else
	pDate->year += 2000;

    return (OK);
}


/*******************************************************************************
 *
 * writeTpRtc - Write time & date to TadPole TP32V RTC (real-time-clock)
 *
 * Returns: none
 *
 */
static void 
writeTpRtc(timeData)
unsigned char timeData[];
{
    int oldlevel;			/* current interrupt level mask */

	/* Perform write sequence to MK48T02 Device */
	/* Set WR (write) bit */
	/* Set all time/date values */
	/* Reset WR bit to set new time into RTC */

    oldlevel = intLock();		/* disable interrupts */

	*RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE | RTC_WR_BIT;

	*RTC_ADDR_1 = timeData[0];	/* seconds */
	*RTC_ADDR_2 = timeData[1];	/* minutes */
	*RTC_ADDR_3 = timeData[2];	/* hours */
	*RTC_ADDR_4 = timeData[3];	/* day-of-week */
	*RTC_ADDR_5 = timeData[4];	/* day */
	*RTC_ADDR_6 = timeData[5];	/* month */
	*RTC_ADDR_7 = timeData[6];	/* year */
	
	*RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE;
	
    intUnlock(oldlevel);		/* enable interrupts */
	
}


/*******************************************************************************
 *
 * readTpRtc - Read time & date from TadPole TP32V RTC (real-time-clock)
 *
 * Returns: none
 *
 */
static void 
readTpRtc(timeData)
unsigned char timeData[];
{
    int oldlevel;			/* current interrupt level mask */

	/* Perform read sequence from MK48T02 Device */
	/* Set RD (read) bit to latch current time/date */
	/* Read all time/date values */
	/* Reset RD bit */

    oldlevel = intLock();		/* disable interrupts */

	*RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE | RTC_RD_BIT;

	timeData[0] = *RTC_ADDR_1;	/* seconds */
	timeData[1] = *RTC_ADDR_2;	/* minutes */
	timeData[2] = *RTC_ADDR_3;	/* hours */
	timeData[3] = *RTC_ADDR_4;	/* day-of-week */
	timeData[4] = *RTC_ADDR_5;	/* day */
	timeData[5] = *RTC_ADDR_6;	/* month */
	timeData[6] = *RTC_ADDR_7;	/* year */
	
	*RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE;

    intUnlock(oldlevel);		/* enable interrupts */
	
}


/*************************************************************
*
* intToBcd - convert an integer to binary-coded decimal.
*
* This procedure will convert the integer parameter to
* binary-coded decimal.
*
* RETURNS:
*	pointer to BCD value
*
*/
static void 
intToBcd(intValue, bcdPtr, nbrDigits)
    long intValue;	/* value to be encoded */
    unsigned char bcdPtr[];	/* ptr to BCD results */
    int  nbrDigits;	/* nbr of BCD digits */
    {

	register ii;		/* loop counter */
	register jj;		/* loop counter */
	unsigned char bcdText[10];

	if (nbrDigits == 6)
	    sprintf (bcdText, "%06ld", intValue);
	else if (nbrDigits == 4)
	    sprintf (bcdText, "%03ld", intValue);
	else if (nbrDigits == 2)
	    sprintf (bcdText, "%02ld", intValue);

	/*  encode a maximum of 3 BCD bytes */

	jj = 0;
	for (ii = 0; ii < nbrDigits/2; ii++)
	{
	    if (bcdText[jj] == 0)
		break;

	    bcdPtr[ii] = (bcdText[jj] - 0x30);
	    jj++;
	    bcdPtr[ii] = bcdPtr[ii] << 4;

	    if (bcdText[jj] == 0)
		break;

	    bcdPtr[ii] |= (bcdText[jj] - 0x30);
	    jj++;
	}

    }  /* end intToBcd */


/*************************************************************
*
* bcdToInt - convert a 1-byte BCD value to an integer value.
*
* This procedure will convert a 1-byte binary-coded decimal
* value to an integer value.
*
* RETURNS:
*	integer value
*
*/
static int
bcdToInt (bcdVal)
    unsigned char bcdVal;	/* BCD value */
    {

	int totalVal = 0;	/* converted value */

	/*  convert the BCD digits to int */

	totalVal = (((bcdVal & 0xf0)>>4)*10) + (bcdVal & 0x0f);

	return (totalVal);

    }  /* bcdToInt */





From daemon@vxw.ee.lbl.gov  Sat Sep  5 04:00:40 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep  5 04:00:48 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep  5 04:00:34 PDT 1992

        Subject: Seeking vxWorks pricing structure
        Subject: summary--how to implement a controller

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

Newsgroups: comp.os.vxworks
Subject: Seeking vxWorks pricing structure
Date: Fri, 4 Sep 1992 14:12:12 GMT
From: chuck@westford.ccur.com (Chuck Palmer)
Organization: Concurrent Computer Corp. Westford MA.
Message-ID: <1992Sep4.141212.1962@westford.ccur.com>
Sender:  chuck@westford.ccur.com

I have used vxWorks in the past as part of a client's project.
I now find myself examining its use for another project which
I am costing out. A while back, I saw the pricing as part of
a Heurikon processor. I was reasonably confused by it all.

Could someone explain how the licensing works. The product
would be for resale, and would (hopefully) involve selling
multiple "units". There would be multiple people developing
for the end product on multiple workstations.

The benefit of your experience is greatly appreciated.


			chuck palmer
			chuck@westford.ccur.com

- -- 
    |    Charles Palmer                        (x2997)                  |
    |    chuck@westford.ccur.com                508-392-2997            |
    |    One Technology Way                Fax: 508-392-2492            |
    |    Westford, Ma. 01886                                            |

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

Newsgroups: comp.os.vxworks
Subject: summary--how to implement a controller
Date: 5 Sep 92 01:08:38 GMT
From: doctor@kronos.arc.nasa.gov (Terry Fong)
Organization: NASA/ARC Information Sciences Division
Keywords: controller, periodic tasks
Message-ID: <1992Sep5.010838.2171@kronos.arc.nasa.gov>
Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov)

Hi all,

Last week I asked for suggestions on how to implement a digital
controller using VxWorks. The problem is essentially to determine what
is the most efficient method for periodically executing a task (or a
section of code). Depending on how fast you want to run (i.e., how
short a period is involved) and how much latency (jitter) you can tolerate,
there are three basic approaches:

1) LOW FREQUENCY

If the controller runs at less than about 60 Hz, and latency on the
order of a few milliseconds is not a problem, the easiest method is to
run a high priority task that uses taskDelay() to wait between cycles.
The caveats are that taskDelay() runs at system clock granularity and
that the task needs to complete in less than a clock tick (or "time"
will be lost). It is possible to run faster than 60 Hz if you change
the system clock speed (though this will mess up other timing
functions), or if you use an auxiliary clock (if your board has one).

2) MEDIUM - HIGH FREQUENCIES 

For controllers that run between 30 and 10,000 Hz, a better method
than using taskDelay() is to setup a controller task that synchs on a
binary semaphore. The semaphore is given at the required frequency by
an ISR tied to either the system or auxiliary clock. This is the
recommended method for task synchronization by Wind River Systems, and
is covered in the VxWorks programmer's guide in the synchronization
using semaphores section. Sample code is: 

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

    SEM_ID SynchSemaphore;

    /*
     * This routine runs at interrupt level.  The semaphore lets the loop in
     * Controller execute one time.
     */
    int ControllerISR (void)
    {
	semGive(SynchSemaphore);
	return(0); 
    }

    /*
     * Here is the controller. Spawn this task to start the controller
     */
    STATUS Controller (void)
    {
	SynchSemaphore = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY);

	/* Connect the timer to the aux. clock interrupt */
	if (sysAuxClkConnect((FUNCPTR) ControllerISR, 0) == OK) {
	    sysAuxClkRateSet (100);  /* trigger interrupt at 100 Hz */
	    sysAuxClkEnable();
	    rebootHookAdd((FUNCPTR) sysAuxClkDisable);
	}
	else {
	    printErr ("Controller: the aux clock is not available\n");
	    return ERROR;
	}

	while (TRUE) {
	    /* wait for the synch */
	    semTake(SynchSemaphore, WAIT_FOREVER);

	    /* do control function here ... */
	}

	return OK;	/* NOT REACHED */
    }

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

3) HIGH FREQUENCY / LOW LATENCY

If the controller needs to run *really* fast (greater than 10 KHz) or
if low latency (jitter) is critical, then as much processing as
possible should be done at the interrupt level (since this runs at the
highest priority with the lowest latency). One method is to do
everything in the ISR. This has problems, however, if other concurrent tasks
can't handle interrupts that long. Another approach is to do things
similiar to the previous method (i.e., synch a task off of a
semaphore), but to try to do some/all of the calcuations in the ISR
and to disable the system clock (since the kernel steals 100-300 usecs
servicing the clock interrupt). 


Many thanks to Fred Roeber, Georg Feil, Stan Schneider, Andrew
Mitchell, and Clark Briggs!!!


- -Terry
- -- 
_______________________________________________________________________________
 "You do not understand anything     | Terry Fong <terry@ptolemy.arc.nasa.gov>
  until you understand it in more    | NASA Ames, M/S 269-3, Moffett Field, CA
  than one way..." -- Marvin Minsky  | (415) 604-6063, FTS-464-6063

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

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


From briggs@thalia.jpl.nasa.gov  Sat Sep  5 08:12:32 1992
From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
Date: Sat Sep  5 08:12:39 PDT 1992
Subject: how to implement a controller
Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as:

there are three basic approaches:

1) LOW FREQUENCY

If the controller runs at less than about 60 Hz, and latency on the
order of a few milliseconds is not a problem, the easiest method is to
run a high priority task that uses taskDelay() to wait between cycles.
The caveats are that taskDelay() runs at system clock granularity and
that the task needs to complete in less than a clock tick (or "time"
will be lost). It is possible to run faster than 60 Hz if you change
the system clock speed (though this will mess up other timing
functions), or if you use an auxiliary clock (if your board has one).


2) MEDIUM - HIGH FREQUENCIES
For controllers that run between 30 and 10,000 Hz, a better method
than using taskDelay() is to setup a controller task that synchs on a
binary semaphore. The semaphore is given at the required frequency by
an ISR tied to either the system or auxiliary clock. This is the
recommended method for task synchronization by Wind River Systems, and
is covered in the VxWorks programmer's guide in the synchronization
using semaphores section. Sample code is:

code omitted for brevity...

3) HIGH FREQUENCY / LOW LATENCY
 
If the controller needs to run *really* fast (greater than 10 KHz) or
if low latency (jitter) is critical, then as much processing as
possible should be done at the interrupt level (since this runs at the
highest priority with the lowest latency). One method is to do
everything in the ISR. This has problems, however, if other concurrent tasks
can't handle interrupts that long. Another approach is to do things
similiar to the previous method (i.e., synch a task off of a
semaphore), but to try to do some/all of the calcuations in the ISR
and to disable the system clock (since the kernel steals 100-300 usecs
servicing the clock interrupt).

end of copy of Terry's story...

My Comments:
method 1): changing sysclk from 60hz should not be a problem, in
most respects.  good code can get the sysclk freq and shouldnt code
in 60hz.  I have run sysclk all the way up until the system cant
service the sysclk interrupts fast enough.  This was my first attempt
at running fast controllers.  I got violent frowns from WRS when I
turned sysclk up.  It seems there is nothing inherently wrong with this
its just that they never intended for us to do that to their system.
The most significant problem is this causes the scheduler to run
a lot more and sink a lot of cpu cycles. (In version 4.0 this was
horribly expensive.)
 
Method 2) is the way we run in our labs.  It works well enough, but
is limited by only one sysauxclk.  The isr gets tricky if you are trying
to control several tasks at different rates.
 
We have used method 3, too.  The biggest difficulty, beyond the obvious
poor behavior of tieing up the cpu, it that the processing done in the
ISR really has no context.  this means no file I/O (no surprise, no one
would really violate convention that much would they? you bet they would!)and no floating point!
 
I suggested turning off sysclk, which seems like another
terrible thing to do.  It works but can have severe consequences.  This
makes sense to me only if the task is soooo important it is necessary
to starve everything else, including the network deamons. But, we've
been there too.
 
A final method, is to simply never give up the CPU.  We do this to get
14Khz with 50MHz 68030s.  Make your task highest priority, never sleep,
spin on a sync byte (set by the auxclk isr or a companion cpu), turn off
sysclk, no file I/O....  This simply dedicates the entire cpu to your
task.
 
Thanks to Terry for the prompt posting and the work to get the information.
Clark Briggs
briggs@csi.jpl.nasa.gov


From carl@umd5.umd.edu  Mon Sep  7 20:38:24 1992
From: carl@umd5.umd.edu
Date: Mon Sep  7 20:38:32 PDT 1992
Subject: Re: general info needed 

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

<relevant comments deleted>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thats all for now!

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


From chip@csd.nad.northrop.com  Tue Sep  8 09:58:27 1992
From: Peter Ross <chip@csd.nad.northrop.com>
Date: Tue Sep  8 09:58:34 PDT 1992
Subject: Fortran compiler
Hi 
I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030)
that is compatible with vxworks. I'd appreciate any info on where I might
obtain one. Thanks 
                Chip



From mea@sparta.com  Tue Sep  8 11:09:01 1992
From: mea@sparta.com (Mike Anderson)
Date: Tue Sep  8 11:09:08 PDT 1992
Subject: Re: Fortran compiler
Greetings!

> Submitted-by chip@csd.nad.northrop.com  Tue Sep  8 09:58:27 1992
> Submitted-by: Peter Ross <chip@csd.nad.northrop.com>
>  
> Hi 
> I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030)
> that is compatible with vxworks. I'd appreciate any info on where I might
> obtain one. Thanks 
>                 Chip
> 

  I've just gone through this effort recently and I'll give you the dump
on what I found.  First, WRS is working with Oasys for a customer to produce
a FORTRAN compiler for VxWorks.  This product should be in Beta-test by
the end of this month with shipping soon after.  To make it compatible
with the GNU environment, you need to tell the compiler to output assembler
and then assemble the file using the GNU assembler.  Easily done in 
a script file.  I've sent Oasys one of my FORTRAN benchmarks to convert
to assembly, assembled it with as68k and loaded it into VxWorks (68030 and
68040) with no problems.  Oasys claims to be working on having an 
integrated debugger facility for VxWorks using both their FORTRAN and
their C++ ready to be shipped with the FORTRAN compiler when it is
released.

  Another other option is to grab the FORTRAN-to-C translator from
att.research.com and hack it to work with VxWorks.  I have done this
and I have a working translator that can target both 68030s and 68040s
running VxWorks.  I haven't tested it thoroughly, but I did take 5,000
lines of FORTRAN code and pass it through the translator and then
through the GNU compiler and run it on VxWorks with zero modifications
along the way :-).  The code was very floating-point intensive with some
formatted I/O.  The way the translator handled things like named common
blocks was most interesting.  It doesn't clean up the code as far as
nasties like GOTOs are concerned, but it sure goes a long way towards a
reasonable savings in effort.  I also understand there are commercial
products that do this sort of thing that can do some of the restructuring.
I'm afraid that I don't have any info about how good they are for 
VxWorks.

Hope this helps,

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

Process Distribution/Control and Communications for Distributed Systems

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

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





From daemon@vxw.ee.lbl.gov  Wed Sep  9 04:00:57 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep  9 04:01:06 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep  9 04:00:40 PDT 1992

        Subject: Re: how to implement a controller
        Subject:  ERROR: Remote debug server (RDB) not installed.
        Subject: Re:  ERROR: Remote debug server (RDB) not installed.
        Subject: Re: ERROR: Remote debug server (RDB) not installed.
        Subject: another controller technique
        Subject: periodic task execution

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

Newsgroups: comp.os.vxworks
Subject: Re: how to implement a controller
Date: 8 Sep 92 18:42:11 GMT
From: sjk@strl.labs.tek.com (Steven John King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <4736@crl.LABS.TEK.COM>
References: <9209051514.AA08750@thalia.jpl.nasa.gov>
Followup-To: comp.os.vxworks
Reply-To: sjk@strl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <9209051514.AA08750@thalia.jpl.nasa.gov>, briggs@thalia.jpl.nasa.gov (Clark Briggs) writes:
|> Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as:

[Requirements #1 and #2 deleted]

|> 3) HIGH FREQUENCY / LOW LATENCY
|>  
|> If the controller needs to run *really* fast (greater than 10 KHz) or
|> if low latency (jitter) is critical, then as much processing as
|> possible should be done at the interrupt level (since this runs at the
|> highest priority with the lowest latency). One method is to do
|> everything in the ISR. This has problems, however, if other concurrent tasks
|> can't handle interrupts that long. Another approach is to do things
|> similiar to the previous method (i.e., synch a task off of a
|> semaphore), but to try to do some/all of the calcuations in the ISR
|> and to disable the system clock (since the kernel steals 100-300 usecs
|> servicing the clock interrupt).
|> 
|> end of copy of Terry's story...

[Requirements #1 and #2 deleted]
 
|> We have used method 3, too.  The biggest difficulty, beyond the obvious
|> poor behavior of tieing up the cpu, it that the processing done in the
|> ISR really has no context.  this means no file I/O (no surprise, no one
|> would really violate convention that much would they? you bet they would!)and no floating point!
|>  
|> I suggested turning off sysclk, which seems like another
|> terrible thing to do.  It works but can have severe consequences.  This
|> makes sense to me only if the task is soooo important it is necessary
|> to starve everything else, including the network deamons. But, we've
|> been there too.
|>  
|> A final method, is to simply never give up the CPU.  We do this to get
|> 14Khz with 50MHz 68030s.  Make your task highest priority, never sleep,
|> spin on a sync byte (set by the auxclk isr or a companion cpu), turn off
|> sysclk, no file I/O....  This simply dedicates the entire cpu to your
|> task.

Another method, that helps lower both the interrupt latency and context
switch time is to write your own interrupt routine and connect it directly
to the vector, as follows:

1) Copy the wrapper routine generated by intConnect().  If you don't have
   source, simply do an "i" on the routine attached to the clock interrupt.
   You may have to search through the vectors (starting at intVecBaseGet())
   on a running target to find the wrapper code.

2) Remove the calls to intEnt() and intExit().  Instead increment intCnt
   (a global) where intEnt() is called.  Decrement intCnt where intExit()
   is called.

   NOTE: This works for most VxWorks routines that can be called from
         interrupt-level.  NO PROMISE THAT IT WILL ALWAYS WORK.  ;^)

3) If your interrupt handler doesn't receive a parameter, don't push one
   onto the stack.

4) If your "C" routine saves/restores D2, don't save/restore it in this
   routine.  I believe GNU saves it.  Other compilers must not.

5) Perform an RTE at the end of the handler.

6) Connect the handler to the interrupt vector using intVecSet().  Optionally
   save the old on using intVecGet() before the intVecSet().

NOTES:This only saves context switch overhead if the task that will start
      after the interrupt is dismissed is the highest priority task that is
      ready to execute.  In case #3 this will likely be true.  You save the
      lookup overhead in this case.

      In either case you save some of the overhead of the default wrapper
      routine.

      This method is only for the brave, crazy and/or skilled.  Wind River
      probably won't accept support calls if you need help debugging this
      change.

|> Thanks to Terry for the prompt posting and the work to get the information.

Agreed!

- -- 
Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)

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

Newsgroups: comp.os.vxworks
Subject:  ERROR: Remote debug server (RDB) not installed.
Date: Tue, 8 Sep 1992 20:26:39 GMT
From: vanandel@rsf.atd.ucar.edu (Joe VanAndel)
Organization: NCAR/UCAR
Keywords: RDB
Message-ID: <1992Sep8.202639.10441@ncar.ucar.edu>
Sender: news@ncar.ucar.edu (USENET Maintenance)

I am trying to build a vxWorks kernel (5.02) with RDB support.  I added the following line 
#define INCLUDE_RDB

to config.h
for the target I'm building, and re-compiled all the objects.  But when I boot, I get the message:

0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed.

So, what am I missing?
- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	NCAR - ATD/RSF  			
	P.O Box 3000		Fax:	 303-497-2044
	Boulder, CO 80307-3000	Voice:	 303-497-2071 

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

Newsgroups: comp.os.vxworks
Subject: Re:  ERROR: Remote debug server (RDB) not installed.
Date: Tue, 8 Sep 1992 22:05:03 GMT
From: markf@wrs.com (Mark Fox)
Organization: Wind River Systems, Inc.
Keywords: RDB
Message-ID: <BuA5CG.AH2@wrs.com>
References: <1992Sep8.202639.10441@ncar.ucar.edu>
Sender: news@wrs.com (News Manager)

vanandel@rsf.atd.ucar.edu (Joe VanAndel) writes:
>I am trying to build a vxWorks kernel (5.02) with RDB support.  I added the
>following line 
>#define INCLUDE_RDB
>
>to config.h
>for the target I'm building, and re-compiled all the objects.  But when I boot, I get the message:
>
>0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed.

For VxWorks 5.0.2, VxGDB support is provided on a separate distribution
tape.  This tape includes the host executables (debugger, GUI, and command
driver), as well as the archive module (rdb.a) containing the code for the
remote debug RPC server that runs as a task under VxWorks.  The message
above indicates that the VxGDB distribution has not been installed in the
VxWorks tree.

To install the VxGDB distribution, untar the VxGDB tape into a temporary
directory, then run the script "installVxgdb" that you will find in the
root of the resulting tree.  This script will prompt you for the location
of the VxWorks tree into which you wish to install VxGDB.  For more details,
see Part I, Section 2 of the "VxGDB User's Guide."

Mark Fox
Wind River Systems
markf@wrs.com

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

Newsgroups: comp.os.vxworks
Subject: Re: ERROR: Remote debug server (RDB) not installed.
Date: 8 Sep 92 21:39:56 GMT
From: sjk@strl.labs.tek.com (Steven John King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Keywords: RDB
Message-ID: <4737@crl.LABS.TEK.COM>
References: <1992Sep8.202639.10441@ncar.ucar.edu>
Followup-To: comp.os.vxworks
Reply-To: sjk@strl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <1992Sep8.202639.10441@ncar.ucar.edu>, vanandel@rsf.atd.ucar.edu (Joe VanAndel) writes:
|> I am trying to build a vxWorks kernel (5.02) with RDB support.  I added the following line 
|> #define INCLUDE_RDB
|> 
|> to config.h
|> for the target I'm building, and re-compiled all the objects.  But when I boot, I get the message:
|> 
|> 0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed.

To which they should add the message:

0xf1234 (tRootTask): INFO: Copy the rdb.a from your vxGdb distribution
                     into the appropriate library directory of your vxWorks
                     distribution and rebuild.

Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)

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

Newsgroups: comp.os.vxworks
Subject: another controller technique
Date: 8 Sep 92 22:43:22 GMT
From: brad@huey.Jpl.Nasa.GOV (Brad Hines)
Organization: JPL Spatial Interferometry Group
Keywords: vxworks controller
Message-ID: <1992Sep8.224322.18705@jato.jpl.nasa.gov>
Reply-To: brad@huey.Jpl.Nasa.GOV
Sender: nobody@jato.jpl.nasa.gov

I initially mailed this to Terry concerning a technique we use for
implementing controllers, and he suggested that it might be worth
posting.

===========


From brad Tue Sep  8 14:34:06 1992
To: doctor@kronos.arc.nasa.gov
Subject: periodic task execution


I just saw your summary of responses to how to periodically schedule
tasks, and I thought you might be interested in my 2 cents about how we
do it in our lab.

We use a technique related to the semGive scheme.  We use an external
clock (from an IRIG time code reader card to get microsecond timing
resolution) hooked to an ISR.  Rather than calling semGive to resume
the desired controller task, which then has to go through system tables
to find out who's waiting on the semaphore and then make a taskResume
call, we just call the taskResume ourselves (after all, you get the
task id for the task when you first spawn it).  Basically, the thinking
is why go through the extra layer of abstraction of the semaphore when
all you really want to do is resume a specific task (semaphores are
more appropriate when there may be more than one task waiting on a
given resource).  At the end (or beginning) of each task iteration,
there is a taskSuspend(0) call (so the taskResume/taskSuspend pair
replaces the semGive/semTake pair), which is also faster than the
semTake.  Finally, the taskResume is naturally deterministic; the
semGive probably isn't since the OS has to deal with the bookkeeping
involved when multiple tasks wait for the same semaphore.  (As an
aside, my personal opinion is that WRS recommends semaphores for this
kind of thing because WRS is proud of their semaphores, and heck, it
just sounds more like real computer science.)

If there are several periodic tasks to run, you have a couple of
options.  For example, I have written a deterministic high-speed
periodic task scheduling library for use in a project here which
supplies the ISR and routines to add and delete tasks from the queue of
tasks to run periodically, as well as lots of ways of manipulating the
task queues.  In addition, it allows for one task which runs at
interrupt level.

We ended up using this in one part of the project, but in another part
that needs very high speed, we instead chained the various controller
tasks together, combining the do-it-in-the-ISR and the taskResume
techniques.  In our system, the ISR runs at 5-10 kHz depending on base
CPU speed, and there are three standard VxWorks tasks that run at lower
speeds (800 Hz, 200 Hz, and 2 Hz).  The tasks are chained together -
i.e, if the ISR runs at 8 kHz, it calls taskResume to resume the 800 Hz
task on every 10th iteration.  The 800 Hz task calls taskResume to
resume the 200 Hz task on every 4th iteration, and the 200 Hz task
calls taskResume to resume the 2 Hz task every 100th time through.
It's not as elegant as some of the other techniques, but it is the
fastest of all the techniques mentioned for this kind of system, and
it's also the simplest and most direct.

Hope this is helpful or at least interesting.

- -Brad



- -- 
Brad Hines
Internet: brad@huey.jpl.nasa.gov
Jet Propulsion Lab, Pasadena, California

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

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


From fjr@ssd.ray.com  Wed Sep  9 06:31:27 1992
From: Roeber <fjr@ssd.ray.com>
Date: Wed Sep  9 06:31:34 PDT 1992
Subject: Re:  VxGDB
Mark Fox from WRS writes:

>  For VxWorks 5.0.2, VxGDB support is provided on a separate distribution
>  tape.  This tape includes the host executables (debugger, GUI, and command
>  driver), as well as the archive module (rdb.a) containing the code for the
>  remote debug RPC server that runs as a task under VxWorks.  The message
>  above indicates that the VxGDB distribution has not been installed in the
>  VxWorks tree.
>  
>  To install the VxGDB distribution, untar the VxGDB tape into a temporary
>  directory, then run the script "installVxgdb" that you will find in the
>  root of the resulting tree.  This script will prompt you for the location
>  of the VxWorks tree into which you wish to install VxGDB.  For more details,
>  see Part I, Section 2 of the "VxGDB User's Guide."

Is VxGDB an added cost option?  The posting didn't make it clear one way or
the other.  If it costs extra, how much is it for a 680X0 system using
a SPARC host?  Also, is VxGDB a window based version of gdb or a standard
text based version?  Thanks for the info.

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|



From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Wed Sep  9 10:46:31 1992
From: Carl Lacy <lacy@draper.com>
Date: Wed Sep  9 10:46:39 PDT 1992
Subject: usrTime for mvme167
   I am working at bringing up ttcp on VxWorks, using the port graciously
provided by Marc E. Fiuczynski  (mef@ehsl.mitre.org)  This requires use 
of Bob Herlien's usrTime library, also graciously provided on the 
VxWorks archive.  However, as available it's 'rtc_read' and 'rtc_write'
functions are targetted for the MK48T02 Real-Time Clock Chip on VPU-30.

   (God, don't you love working with public domain software!?!)

   Before I convert these over to my current target, a MVME167, I thought I'd
check if anyone might have already done so.

					Thanks,

					Carl Lacy,  MS 3F
					Charles Stark Draper Laboratory
					555 Technology Square
					Cambridge, Mass.   02139
					   (617) 258-3228, 258-1558
					   (617) 258-1880 (fax)
					lacy@coyote.draper.com
				


From pdw@sunbar.mc.duke.edu  Wed Sep  9 14:00:29 1992
From: pdw@sunbar.mc.duke.edu (Patrick D. Wolf)
Date: Wed Sep  9 14:00:35 PDT 1992
Subject: DOS free space

Does anybody have a nifty way for determining the free space left on a DOS
file system disk? 
Thanks in advance,`
Patrick Wolf
pdw@sunbar.mc.duke.edu
Duke University Medical Center
919-660-5114


From interf!zeus!brackett@uunet.uu.net  Wed Sep  9 14:31:33 1992
From: interf!zeus!brackett@uunet.uu.net (Todd Brackett)
Date: Wed Sep  9 14:32:03 PDT 1992
Subject: Your usergroup's meeting
Hello everybody,

I just want to remind you about the East Coast VxWorks Usergroup 
Meeting in Boston, MA next week.  We have set up a very interesting
meeting and I want to make sure that you all try to attend.  We will
have, for the first time, actual hands on demos of third party software
and systems on hand.  We will be hearing from Dave Wilner all about the
new bells and whistles due in the next release of VxWorks.  As we are 
meeting just after the BUSCON East show you can try to convince the boss
it is a two for one deal (good luck!).  

See you all there.......

1992 VxWorks Users Group 
Friday, September 18
Sheraton Hotel and Towers
Boston MA. 

8:30 a.m. -- 5 p.m., with
a break at noon for lunch.
 
Regards,

-------------------------------------------------------
|Todd S. Brackett                 |Voice:703 790 8500 |
|Interferometrics, Inc.           |FAX:  703 848 2492 |
|8150 Leesburg Pike               |                   |
|Vienna, VA 22182                 |                   |
|-----------------------------------------------------|
|Internet:brackett@interf.com                         |
|Uunet:   uunet!interf!brackett                       |
-------------------------------------------------------


From nora@wrs.com  Wed Sep  9 15:43:22 1992
From: nora@wrs.com
Date: Wed Sep  9 15:43:31 PDT 1992
Subject: users group meeting
VxWorks Users:
Here is a follow-up to Todd Bracketts email:
There is still time to sign up for the VxWorks Users Group Meeting,
September 18, 1992 at the Sheraton Hotel and Towers in Boston, MA.  If you
register in advance you will receive $10 off the $50 fee.  Email
nora@wrs.com or call Nora Patterson at 1-800-545-WIND, to sign up by Friday
Sept. 11.   
								
In addition to David Wilner, Tony Barbagallo, of WRS, and Mike Teimann of
Cygnus Support, we will have presentations given by:

Mike Anderson, SPARTA, Inc.
SPARTA will be discussing our latest release of the ARTSE(Tm) process
distribution, control and communications executive.  ARTSE(Tm) presents to
the applications programmer a platform-independent communications layer
that supports Sun 3, Sun 4, Silicon Graphics and DECStation as well as
VxWorks-based hosts.  This communications layer is based on a
SPARTA-developed reliable datagram facility that can sustain > 4MBPs
transfer rates between two SPARCStation 1+-class machines over Ethernet. 
Process allocation and message routing is handled via an iconic
point-and-shoot style user interface with messages being able to be
delivered to multiple destinations without multiple application-level write
calls ala multicast.  SPARTA will be demonstrating ARTSE(Tm) using our
robot demo that incorporates 2 VxWorks CPUs, a SPARCStation and our
home-brew robot (Z80-based controlled from VxWorks).
								

Stan Schneider, Real-Time Innovations, Inc.
Stan Schneider from Real-Time Innovations, Inc. will give a short
presentation
on RTI's StethoScope product, including a live demonstration.
        StethoScope is a graphical monitoring and data collection utility
designed expressly to work with VxWorks.  It lets programmers examine and
analyze  real-time applications while they're running.  StethoScope can
monitor, graph, store, and analyze any variable or memory location in your
system.  It provides direct visibility of many things that no other tool
can show.
        StethoScope includes the ScopeProfile dynamic execution profiler
for VxWorks.  ScopeProfile analyzes the execution flow of a real-time
program on a procedure-by-procedure basis.  It shows you exactly how your
VxWorks program is utilizing the CPU.
								

Mike Trest, VisiCom Laboratories
VisiCom's primary business is a line of emulators and communications
controllers for military applications.  VisiCom is also a VxWorks reseller
who provides services to builders of custom embedded hardware systems.
        Custom BSP's and device drivers for VME and NON-VME environments is
VisiCom's forte.   In addition to hardware and system design activities,
VisiCom's staff of over 130 includes over 40 software professionals who
work with VxWorks/VADSworks applications, BSPs, and drivers on a daily
basis.
        Mike Trest will be presenting VisiCom's X-Windows product
VX-Windows (tm). VX-Windows brings high speed X-Server capabilities to your
real-time designs. VX-Windows incorporates the standard MIT X libraries and
a complete  X-Server which supports several hardware boards.  VX-Motif is
also available. 
        Users group attendees will see demonstration clients written with
windX, VX-Windows, VX-Motif all sharing a common display.  A survey of
actual fielded applications will be reviewed.  Mike will be available to
answer your one-on-one questions.

								
Garth Gullekson, Bell-Northern Research
Garth Gullekson, from Bell-Northern Research, will be giving an overview of
the concepts of ObjecTime.  ObjecTime is a new object-oriented CASE tool,
targeted for real-time systems.  It supports the ROOM methodology, which
allows the creation of executable analysis or design models. It is based
primarily on communicating hierarchically decomposed finite-state machines
with well defined message-based protocols between them.  Inheritance can be
applied to architectures and high-level designs, not just C++ code
segments.  Future plans for the product include the  ability to take
detailed ObjecTime designs and run them unaltered on VxWorks-based product
platforms

								
Lloyd Bishop, Tadpole Technology
Tadpole Technology will discuss its philosophy to custom board design and
how that has enabled Tadpole's customers to meet technology and
time-to-market pressures.  We will also discuss how that approach has
resulted in an extensive range of single board computers available to the
general market.  Soon to be announced product will also be discussed.

								
Sven Spoerri, Atlantic Aerospace Electronics Corp.
Ultranet is a high performance network consisting of hardware and software
that will support data transfer rates between host computers of up to 1
Gigabit/second.  Atlantic Aerospace Electronics Corp. has ported the
software driver for Ultra's VME host adapter so that applications running
under the VxWorks real-time operating system kernel can transfer data over
an Ultra network using standard TCP/IP network protocols.  Data transfer
rates of up to 12 Mbytes/sec have been achieved between VME systems with
68030 single board computers running VxWorks communicating over an Ultra
network.  The talk will provide an overview of the hardware and software,
performance results and suggest potential applications.


See you there.



From daemon@vxw.ee.lbl.gov  Thu Sep 10 04:00:56 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 10 04:01:03 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 10 04:00:49 PDT 1992

        Subject: Re: DOS free space
        Subject: Re:  VxGDB
        Subject: Re: Fortran compiler

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

Newsgroups: comp.os.vxworks
Subject: Re: DOS free space
Date: 9 Sep 92 23:21:19 GMT
From: scoob@bnr.ca (Christian Marcotte)
Organization: Bell-Northern Research, Ontario, Canada
Message-ID: <1992Sep9.232119.3528@bnr.ca>
References: <9209092057.AA15841@pat.mc.duke.edu>
Sender: news@bnr.ca (usenet)

In article <9209092057.AA15841@pat.mc.duke.edu> pdw@sunbar.mc.duke.edu (Patrick D. Wolf) writes:
>
>Does anybody have a nifty way for determining the free space left on a DOS
>file system disk? 


Use ioctl on with:
	FIONFREE:      Return amount of free space on volume.

This will return the number of bytes free based on the number for free 
clusters in the FAT.


- -- 
- ---------------------------------------------------------------------------
Christian Marcotte                Bell-Northern Research
scoob@bnr.ca                      3500 Carling Ave
Telephone: (613) 763-2782         Nepean, Ont., Canada K1Y 4H7

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

Newsgroups: comp.os.vxworks
Subject: Re:  VxGDB
Date: Thu, 10 Sep 1992 04:19:03 GMT
From: markf@wrs.com (Mark Fox)
Organization: Wind River Systems, Inc.
Message-ID: <BuCHBr.6xx@wrs.com>
References: <199209091258.AA22296@pike.ssd.ray.com>
Sender: news@wrs.com (News Manager)

Fred Roeber asks:

> Is VxGDB an added cost option?  The posting didn't make it clear one way or
> the other.  If it costs extra, how much is it for a 680X0 system using
> a SPARC host?  

At one point remote debugging support was offered as an unbundled option,
but since just about everyone wanted it, WRS decided to bundle it with the
OS.  (This is true for customers purchasing VxWorks directly from WRS; I
don't know what the situation is for VARs.)

> Also, is VxGDB a window based version of gdb or a standard
> text based version?  Thanks for the info.

VxGDB has an X-based GUI.

Mark Fox
Wind River Systems
markf@wrs.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Fortran compiler
Date: 9 Sep 92 13:26:52 EST
From: els@icf.hrb.com (Eric L. Schott)
Organization: HRB Systems, Inc.
Message-ID: <1992Sep9.132652.19540@icf.hrb.com>
References: <9209081655.AA16599@csd.nad.northrop.com>

In article <9209081655.AA16599@csd.nad.northrop.com>, chip@csd.nad.northrop.com (Peter Ross) writes:
>
> I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030)
> that is compatible with vxworks. I'd appreciate any info on where I might
> obtain one. Thanks 

An approach I have not tried, but which MAY be viable is to get the
GNU Fortran (now in alpha) and build it as a cross compiler.
- -- 

Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"

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

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


From daemon@vxw.ee.lbl.gov  Sat Sep 12 04:00:26 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep 12 04:00:33 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep 12 04:00:19 PDT 1992

        Subject: 167BUG Diagnostics and VxWorks
        Subject: Re: 167BUG Diagnostics and VxWorks
        Subject: Re: usrTime for mvme167
        Subject: Re: 167BUG Diagnostics and VxWorks

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

Newsgroups: comp.sys.m68k,comp.os.vxworks,comp.realtime
Subject: 167BUG Diagnostics and VxWorks
Date: 11 Sep 92 13:53:04 GMT
From: r2c@icf.hrb.com (Robert J. Cole)
Organization: HRB Systems, Inc.
Keywords: 167BUG, VxWorks, Diagnostics
Message-ID: <1992Sep11.085304.19546@icf.hrb.com>
Followup-To: comp.os.vxworks


	I am attempting to write c diagnostic routines for the Motorola
167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
board and on power-up, boots and passes control to vxWorks.  167BUG
exists in the first two PROMS and VxWorks in the second set.  VxWorks
boot ok in this configuration.  The intention is to run the user diagnostic 
routines on the 167 board which will make use of the resident Motorola 
diagnostic routines already in ROM, however this effort seems to be rife
with difficulty.	
	
	Has anyone done anything similar to what I am attempting and is
able to offer any advice?
 
Rob Cole.  r2c@icf.hrb.com

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

Newsgroups: comp.os.vxworks
Subject: Re: 167BUG Diagnostics and VxWorks
Date: 11 Sep 92 16:56:40 GMT
From: sjk@strl.labs.tek.com (Steven King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Keywords: 167BUG, VxWorks, Diagnostics
Message-ID: <4744@crl.LABS.TEK.COM>
References: <1992Sep11.085304.19546@icf.hrb.com>
Followup-To: comp.os.vxworks
Reply-To: sjk@strl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <1992Sep11.085304.19546@icf.hrb.com>, r2c@icf.hrb.com (Robert J. Cole) writes:
 
|> 	I am attempting to write c diagnostic routines for the Motorola
|> 167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
|> board and on power-up, boots and passes control to vxWorks.  167BUG
|> exists in the first two PROMS and VxWorks in the second set.  VxWorks
|> boot ok in this configuration.  The intention is to run the user diagnostic 
|> routines on the 167 board which will make use of the resident Motorola 
|> diagnostic routines already in ROM, however this effort seems to be rife
|> with difficulty.	
|> 	
|> 	Has anyone done anything similar to what I am attempting and is
|> able to offer any advice?

I helped someone do similar work on a Force CPU-30.  We obtained the
CPU-30 diagnostics that Force uses in manufacturing.  They were written
in motorola assembler, so we converted them to use the as syntax.

What we did was link romInit() at a different address.  At the address that
romInit() used to live, the diagnostic routines were placed.  The diagnostics
transferred control to romInit() upon completion.

Another method is to allow VxWorks to initialize the hardware and call
the diagnostic routine immediately after sysHwInit().  Of course, you
won't be able to run write/read memory tests where VxWorks lives, and
you won't be able to mess with any hardware registers that were previously
initialized.  It's much easier to develop code using this method, and
you simply have to link it in with bootrom.hex (or whatever ROM version
you build).  Also, when you deploy a system and a "real" version of
VxWorks lives in all the ROMs you can easily link in the diagnostics
with this larger version of VxWorks.

Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)

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

Newsgroups: comp.os.vxworks
Subject: Re: usrTime for mvme167
Date: 11 Sep 92 18:07:28 GMT
From: mef@athos.rutgers.edu (Marc E. Fiuczynski)
Organization: Rutgers Univ., New Brunswick, N.J.
Message-ID: <Sep.11.14.07.27.1992.5761@athos.rutgers.edu>
References: <9209091746.AA12150@coyote.draper.com>

Hi,

Hope you can get the clock stuff to work on your processor.  Does your
processor support time-of-day-clock sysclass?  I got ttcp to work on
our MATRIX 320 and 330 boards using these system calls.  

By the way, I'm not working at MITRE anymore.  My summer internship
with them ended aug. 28th.  Until next summer my email address will be
mef@cs.washington.edu.

Marc
- -- 
______________________________________________________________________________
Marc E. Fiuczynski	\\  Home: (703) 815-8920	Work: (703) 883-5632
mef@cs.rutgers.edu 	//  UUCP: {backbone}!rutgers!cs.rutgers.edu!mef

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

Newsgroups: comp.os.vxworks
Subject: Re: 167BUG Diagnostics and VxWorks
Date: Fri, 11 Sep 1992 21:58:27 GMT
From: gcall@systemname.uucp (Glen Call)
Organization: Motorola Computer Group Marketing
Keywords: 167BUG, VxWorks, Diagnostics
Message-ID: <1992Sep11.215827.8578@phx.mcd.mot.com>
References:  <1992Sep11.085304.19546@icf.hrb.com>
Sender: gcall@systemname (Glen Call)


>	I am attempting to write c diagnostic routines for the Motorola
>167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
>board and on power-up, boots and passes control to vxWorks.  167BUG
>exists in the first two PROMS and VxWorks in the second set.  VxWorks
>boot ok in this configuration.  The intention is to run the user diagnostic 
>routines on the 167 board which will make use of the resident Motorola 
>diagnostic routines already in ROM, however this effort seems to be rife
>with difficulty.	
>	
>	Has anyone done anything similar to what I am attempting and is
>able to offer any advice?
> 
>Rob Cole.  r2c@icf.hrb.com


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

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


From daemon@vxw.ee.lbl.gov  Tue Sep 15 04:01:09 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 15 04:01:16 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 15 04:00:54 PDT 1992

        Subject: interphase 4211 driver??

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

Newsgroups: comp.os.vxworks
Subject: interphase 4211 driver??
Date: Mon, 14 Sep 1992 19:55:04 GMT
From: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.92Sep14145504@dadev.cebaf.gov>
Sender: usenet@murdoch.acc.Virginia.EDU

Does anyone have a driver for the Interphase 4211
FDDI interface. As far as I know WRS are supposed 
to have a driver for free  but I haven't been able
to get hold of it yet. I've got the hardware and
want to get going as quickly as possible.
	If anyone has a copy of the driver which
they can E-mail or give ftp coordinates for that
would be a great help. 

	Thanks,
		Graham Heyes

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

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


From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Tue Sep 15 09:50:35 1992
From: Carl Lacy <lacy@draper.com>
Date: Tue Sep 15 09:50:44 PDT 1992
Subject: interphase 4211 driver??
   Yes, AP Labs sells one.  I've been working with it for several weeks
and after some confusion, porting, and debugging it appears to be working.
(At least on a MVME167 with 5.0.2).

   However, there is a pesky license issue, or I would be happy to email you
a copy of it.  The following is from their user's guide cover page;  give
them a call and see what you can work out.


					Good luck,

					Carl Lacy,  MS 3F
					Charles Stark Draper Laboratory
					555 Technology Square
					Cambridge, Mass.   02139
					   (617) 258-3228
					   (617) 258-1880 (fax)
					   lacy@coyote.draper.com
				




                         AP Labs User's Guide for the
                      Interphase V/FDDI 4211 Peregrine
                            VxWorks Device Driver

                       Document #: VS-DRV-FDDI4211-1.0
                              September 20. 1991


                                 Prepared By:

                    Advanced Processing Laboratories, Inc.
                              6215 Ferris Square
                         San Diego, California 92121
                                (619) 546-8626



From daemon@vxw.ee.lbl.gov  Wed Sep 16 04:00:57 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep 16 04:01:04 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep 16 04:00:50 PDT 1992

        Subject: Best way to implement a task at exactly XX Hertz
        Subject: Re: Best way to implement a task at exactly XX Hertz
        Subject: Force CPU-40 ethernet address

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

Newsgroups: comp.os.vxworks
Subject: Best way to implement a task at exactly XX Hertz
Date: Tue, 15 Sep 1992 15:07:21 GMT
From: muts@fys.ruu.nl (Peter Mutsaers)
Organization: Rijks Universiteit Utrecht
Message-ID: <MUTS.92Sep15170713@ruunfs.fys.ruu.nl>
Sender: usenet@fys.ruu.nl (News Control)

As the subject says, I wonder what the best way is to implement a task
which must run at precise time intervals.

In UNIX I'd use setitimer and handle SIGALRM, but this is not
available.

What I would htink of in VxWorks is more clumsy as I would have
thought to be necessary, to my surprise, so maybe I am overlooking
something. Do you have a better idea than the following?:

Say I want to run at exactly 20 Hz:
- - use a special timer task with top priority
- - make it do: 1) taskDelay for 49 ms (a bit less than 50)
              2) poll until tickGet is modulo 50 ms
              3) give a semafore that the periodic job is pending on.

This way I always immediately run when the 50ms mark is passed; but
still I think it is clumsy that I cannot set a timer to expire in 1
process which then sleeps until it expires.

Any improvements/ideas welcomed,
- --
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |        Quod licet bovi, non licet Jovi

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

Newsgroups: comp.os.vxworks
Subject: Re: Best way to implement a task at exactly XX Hertz
Date: 15 Sep 92 20:02:06 GMT
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Organization: Abiogenesis 4 Less
Message-ID: <1992Sep15.200206.20042@wdl.loral.com>
References: <MUTS.92Sep15170713@ruunfs.fys.ruu.nl>
Reply-To: bard@cutter.ssd.loral.com
Sender: news@wdl.loral.com

In article <MUTS.92Sep15170713@ruunfs.fys.ruu.nl>, muts@fys.ruu.nl (Peter Mutsaers) writes:
# As the subject says, I wonder what the best way is to implement a task
# which must run at precise time intervals.

[...]

# Say I want to run at exactly 20 Hz:
# - use a special timer task with top priority
# - make it do: 1) taskDelay for 49 ms (a bit less than 50)
#               2) poll until tickGet is modulo 50 ms
#               3) give a semafore that the periodic job is pending on.
# 
# This way I always immediately run when the 50ms mark is passed; but
# still I think it is clumsy that I cannot set a timer to expire in 1
# process which then sleeps until it expires.
# 
# Any improvements/ideas welcomed,

Howzabout a watchdog timer?  If you don't want your 50Hz code to run
at interrupt level, have the watchdog call a routine that gives a
semaphore that your task is pending on.

- -- 
J H Woodyatt
Space Systems/Loral

"there's a lot going on that you miss. nothing soft about THESE
machines. mean, timeless, mean, purposeful, crammed with meaning."
                                                  -- Andrew Palfreyman

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

Newsgroups: comp.os.vxworks
Subject: Force CPU-40 ethernet address
Date: 16 Sep 92 05:46:25 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep16.054625.26551@afterlife.ncsc.mil>

I've just started using a Force CPU-40 with an Eagle-1 module (ethernet).
Looking at usrConfig.c, it appears that the ethernet address for the board
is not set.  (Well, the first 4 bytes are set to Force's default, but the
lower 2 bytes are always 0.)  How do others deal with this?  Would Force
or WRS care to comment?
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

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


From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Wed Sep 16 04:46:41 1992
From: Carl Lacy <lacy@draper.com>
Date: Wed Sep 16 04:46:48 PDT 1992
Subject: 4211 Driver experience
   Well, I'm using the AP Labs drivers for the Interphase 4211 FDDI 
in VxWorks as a network interface with TCP/IP.  I'm fairly inexperienced 
with network drivers, but it seems to operate fine after some initial 
debugging of the source.  (The driver hadn't been run on a MVME167 
previously.)  I've run rlogin and ttcp so far, with no obvious problems.

   As to performance, I can't say much yet as the initial thruput with
the default parameters of ttcp was only ~1 mbyte/sec, so I need to
play some more.   Here's the initial performance run, but PLEASE take it
with a grain of salt.  I'm still checking out ttcp options, and would
welcome any input from more experienced users.


Invocation of ttcp on two VxWorks targets:
----------------------------------------------------
Bri:  vxttcp 0,0,5005,"140.102.134.20",0,1,1,0,0
             |                         |
             TCP                       REC, SINK, VERBOSE, X, X

Itz:  vxttcp 0,0,5005,"140.102.134.10",1,1,1,0,0
             |                         |
             TCP                       XMT, SINK, VERBOSE, X, X

(Default of 8Kbyte blocks)

Output of ttcp 
----------------------------------------------------

ttcp-t: 16777216 bytes in 17.56 real seconds = 932.82 KB/sec +++
ttcp-t: 16777216 bytes in 17.56 CPU seconds = 932.82 KB/cpu sec
ttcp-t: 2048 I/O calls, msec/call = 8.78, calls/sec = 116.60
ttcp-t: 0.0user 17.5sys 0:17real 100%
ttcp-t: buffer address 0x700000



From @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Wed Sep 16 06:03:04 1992
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Date: Wed Sep 16 06:03:11 PDT 1992
Subject: Re: Best way to implement a task at exactly XX Hertz
Now I'm starting to get worried.  All the suggestions I've seen aren't
anything like what I've always done.  The following seems so obvious
(so I'm starting to think that it's wrong!):

(a) The guy who runs at interrupt level:

int clock_heartbeat;
int clock_task_id;
STATUS clock_resume_status;
void resume_clock()
{
        clock_heartbeat++;
        clock_resume_status = taskResume(clock_task_id);
}

(b) The guy who executes at task level:

foo()
{
#define ME 0
	int my_heartbeat;
	clock_task_id = taskIdSelf();
	for (;;) {
		my_heartbeat = clock_heartbeat;
		putc('.', stdout);
		if (my_heartbeat == clock_heartbeat)
			taskSuspend(ME);
	}
}

(c) Connecting the clock (could go into foo just before the loop):

	clock_heartbeat = 0;
	sysAuxClkDisable();
	sysAuxClkRateSet(RATE);
	sysAuxClkConnect(resume_clock, 0);
	sysAuxClkEnable();

Caveat: there may be some grammatical errors in the above -- I copied
it from some Ada that pragma Interfaces to the VxWorks C routines.

There's a couple of nice features.  For one thing, you get catch-up
protection if you overrun (which you're likely to with putc unless you
do it real slow).  For another, you can substitute intConnect for
sysAuxClkConnect and get the same result.

So what have I been doing wrong?

+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From mitchell@aaec1.aaec.com  Wed Sep 16 06:55:52 1992
From: mitchell@aaec1.aaec.com
Date: Wed Sep 16 06:55:58 PDT 1992
Subject: Re: Best way to implement a task at exactly XX Hertz

># Say I want to run at exactly 20 Hz:
># Peter Mutsaers.

>Howzabout a watchdog timer?  If you don't want your 50Hz code to run
>at interrupt level, have the watchdog call a routine that gives a
>semaphore that your task is pending on.
>J H Woodyatt

Many CPU boards have an aux timer, and supply sysAuxClkRateSet and
sysAuxClkIntConnect or some such thing in the board support package.  The 
advantage here is that the execution period does not have to be a multiple
of the system clock as with the watch dog stuff.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
 
                                



From ntmtv!fleishma@ames.arc.nasa.gov  Wed Sep 16 08:44:17 1992
From: ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman)
Date: Wed Sep 16 08:44:25 PDT 1992
Subject: Re(2): Best way to implement a task at exactly XX Hertz

Bob Crispen writes:

>  Submitted-by @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Wed Sep 16 06:03:04 1992
>   
>  Now I'm starting to get worried.  All the suggestions I've seen aren't
>  anything like what I've always done.  The following seems so obvious
>  (so I'm starting to think that it's wrong!):
>  
>  (a) The guy who runs at interrupt level:
>  
>  int clock_heartbeat;
>  int clock_task_id;
>  STATUS clock_resume_status;
>  void resume_clock()
>  {
>          clock_heartbeat++;
>          clock_resume_status = taskResume(clock_task_id);
>  }
>  
>  (b) The guy who executes at task level:
>  
>  foo()
>  {
>  #define ME 0
>  	int my_heartbeat;
>  	clock_task_id = taskIdSelf();
>  	for (;;) {
>  		my_heartbeat = clock_heartbeat;
>  		putc('.', stdout);
>  		if (my_heartbeat == clock_heartbeat)
>  			taskSuspend(ME);
>  	}
>  }

There is at least one area to worry in the taskSuspend-taskResume approach.
It is based on assumption that your task is SUSPENDed only by you.

I know at least 2 points where this assumption is wrong:
	- breakpoint
	- bus error

In bus-error case (unless you have signal-based recovery) the result will
be disasterous: ISR will taskResume and your task will hit bus-error again
(and again and again ...).

I would go with simple binary semaphore approach.

-----------------------------------------------------------
Emanuel Fleishman		voice: (415) 940-2346
Northern Telecom,		  fax: (415) 966-1067
685 E. Middlefield Road		 UUCP: ames!ntmtv!fleishma
Mountain View, CA 94039		 ARPA: fleishma@ntmtv.com
				   or: ntmtv!fleishma@ames.arc.nasa.gov
------------------------------------------------------------



From daemon@vxw.ee.lbl.gov  Thu Sep 17 04:00:29 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 17 04:00:39 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 17 04:00:23 PDT 1992

        Subject: Re: Best way to implement a task at exactly XX Hertz
        Subject: Re: Force CPU-40 ethernet address
        Subject: re: Best way to implement a task at exactly XX Hertz
        Subject: Re: Best way to implement a task at exactly XX Hertz
        Subject: RFD: comp.sys.vmebus
        Subject: Re: re: Best way to implement a task at exactly XX Hertz

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

Newsgroups: comp.os.vxworks
Subject: Re: Best way to implement a task at exactly XX Hertz
Date: Wed, 16 Sep 1992 06:50:36 GMT
From: muts@fys.ruu.nl (Peter Mutsaers)
Organization: Rijks Universiteit Utrecht
Message-ID: <MUTS.92Sep16085035@ruunfs.fys.ruu.nl>
References: <MUTS.92Sep15170713@ruunfs.fys.ruu.nl> <1992Sep15.200206.20042@wdl.loral.com>
Sender: usenet@fys.ruu.nl (News Control)

>>On 15 Sep 92 20:02:06 GMT, bard@cutter.ssd.loral.com (J H Woodyatt) said:

  J> Howzabout a watchdog timer?  If you don't want your 50Hz code to
  J> run at interrupt level, have the watchdog call a routine that
  J> gives a semaphore that your task is pending on.

I thought about this, but the problem with this is that I lose time in
between and there is no resynchronization with the system clock. Each
time when the timer expires at takes a while before I can set the
watchdog timer again, thus I lose a bit of time in between. This might
disrupt our algorithm. 
- --
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |        Quod licet bovi, non licet Jovi

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

Newsgroups: comp.os.vxworks
Subject: Re: Force CPU-40 ethernet address
Date: Wed, 16 Sep 1992 16:27:07 GMT
From: carl@wrs.com (Carl Chesbrough)
Organization: Wind River Systems, Inc.
Message-ID: <carl.716660827@wrs.com>
References: <1992Sep16.054625.26551@afterlife.ncsc.mil>
Sender: news@wrs.com (News Manager)

smb@afterlife.ncsc.mil (Steve M. Burinsky) writes:

>I've just started using a Force CPU-40 with an Eagle-1 module (ethernet).
>Looking at usrConfig.c, it appears that the ethernet address for the board
>is not set.  (Well, the first 4 bytes are set to Force's default, but the
>lower 2 bytes are always 0.)  How do others deal with this?  Would Force
>or WRS care to comment?
>-- 

>Steve M. Burinsky
>smb@afterlife.ncsc.mil

This is from the 5.0.2b sysLib.c file for the frc40:

- -----------------------------------
/*
 * The Force CPU-40 has the licensed inet number of 00.80.42.c0.xx.xx where
 * the last four digits are the last four digits of the serial number.
 * Unfortunately there is no way to read the serial number from software so
 * we synthesize a unique ethernet address by placing the lowest two bytes of
 * the internet number in the lowest two bytes of the ethernet address.
 * This is done in usrRoot() in usrConfig().
 */

unsigned char lnEnetAddr[6] = {0x00, 0x80, 0x42, 0xc0, 0x00, 0x00};
- -----------------------------------

Then from the usrConfig.c file:

- -----------------------------------
#if defined(TARGET_FRC_37) || defined(TARGET_FRC_30) || defined(TARGET_FRC_40)
        /* Force 30 ,37 & 40 are supposed to use the board serial number as the
         * last two bytes of the ethernet address, but this is not currently
         * available at run-time (i.e. in non-volatile RAM), so we use the
         * bottom two bytes of the internet address instead.
         */
        if (strcmp (devName, "ln") == 0)
            {
            IMPORT char lnEnetAddr [];      /* ethernet addr for lance */

            u_long inet = inet_addr (inetAdrs);
            lnEnetAddr [4] = (inet >> 8) & 0xff;
            lnEnetAddr [5] = inet & 0xff;
            }
#endif  /* TARGET_FRC_37 or _30 or _40 */

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

This will be changing in the next release (check with sales for timing).
We are allocating 2 bytes in NVRAM which will hold the lower 2 bytes for the
ethernet address.

Hope this helps,
Carl C. Chesbrough
Wind River Systems
1010 Atlantic Avenue
Alameda, California  94501
(510) 748-4100

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

Newsgroups: comp.os.vxworks
Subject: re: Best way to implement a task at exactly XX Hertz
Date: Wed, 16 Sep 1992 21:06:51 GMT
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Organization: Abiogenesis 4 Less
Message-ID: <1992Sep16.210651.8373@wdl.loral.com>
References:  <9209161313.AA06318@sparky.noname>
Reply-To: bard@cutter.ssd.loral.com
Sender: news@wdl.loral.com

In article <9209161313.AA06318@sparky.noname>, mitchell@aaec1.aaec.com writes:
# 
# ># Say I want to run at exactly 20 Hz:
# ># Peter Mutsaers.
# 
# >Howzabout a watchdog timer?  If you don't want your 50Hz code to run
# >at interrupt level, have the watchdog call a routine that gives a
# >semaphore that your task is pending on.
# >J H Woodyatt
# 
# Many CPU boards have an aux timer, and supply sysAuxClkRateSet and
# sysAuxClkIntConnect or some such thing in the board support package.  The 
# advantage here is that the execution period does not have to be a multiple
# of the system clock as with the watch dog stuff.

Indeed.  Mine don't.  If they did, I could have multiple tasks pending
on semaphore/watchdog combinations running at a multiple of the system
clock rate, and I could use the auxillary clock to fake a set of
watchdog timers to give semaphores to tasks running at multiples of
the auxillary clock rate.

So far, all the examples I've seen are multiples of my system clock
rate: 100 Hz, and it failed to register on me that the question might
have applied to how to get a task to run at exactly 75 Hz.  On my
boards, I'd have to kludge up something that approximated 75 Hz, and
it wouldn't be as good as using the auxillary clock.

I suppose I could probably borrow one of the baud rate generators on
the Z8530 DUARTs or something, if I hadn't already run out of unused
timer-like devices.

Sorry to waste all that bandwidth.

- -- 
J H Woodyatt
Space Systems/Loral

"there's a lot going on that you miss. nothing soft about THESE
machines. mean, timeless, mean, purposeful, crammed with meaning."
                                                  -- Andrew Palfreyman

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

Newsgroups: comp.os.vxworks
Subject: Re: Best way to implement a task at exactly XX Hertz
Date: 16 Sep 92 17:26:33 GMT
From: muts@fys.ruu.nl (Peter Mutsaers)
Organization: Rijks Universiteit Utrecht
Message-ID: <MUTS.92Sep16192632@ruunfs.fys.ruu.nl>
References: <9209161256.AA20057@efftoo.boeing.com>
Sender: usenet@fys.ruu.nl (News Control)

On Wed, 16 Sep 92 07:56:12 CDT, crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> said:

  c> So what have I been doing wrong?

Nothing! I didnt' know about sysAuxClk**. So this is very helpful and
indeed the way to go, thanks.

I only thought about sysClk** but didn't want to change usrClock and
import extra overhead in the 200Hz timing for a 20Hz talk.
- --
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |        Quod licet bovi, non licet Jovi

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

Newsgroups: news.announce.newgroups,news.groups,comp.realtime,comp.robotics,comp.lang.c,comp.sys.m68k,comp.os.os9,comp.os.misc,comp.lang.ada,comp.os.vxworks,comp.sys.sun.hardware
Subject: RFD: comp.sys.vmebus
Date: 17 Sep 92 00:09:09 GMT
From: dstewart+@cs.cmu.edu (David B Stewart)
Organization: The Robotics Institute, Carnegie Mellon University
Message-ID: <Bup4FB.ExL@uunet.uu.net>
Followup-To: news.groups
Sender: tale@uunet.uu.net (David C Lawrence)

This is a Request For Discussion (RFD) regarding creation of an unmoderated
newsgroup for discussing all aspects of computing related to the VMEbus
and VMEbus-based systems:

    comp.sys.vmebus	   Discussions on hardware and software for VMEbus.


The VMEbus is one of the more popular standards for developing
open-architecture applications based on off-the-shelf hardware.  Many hardware
components, operating systems, and applications are based on this standard, yet
there currently is no USENET group where discussions of this standard,
and related items, are appropriate.

The proposal is to create comp.sys.vmebus as a forum for discussing issues
related to developing VMEbus-based systems.  This includes discussion on the
VMEbus Specification; VMEbus-based hardware, such as CPU boards and I/O devices;
secondary buses such as VSB, VXI, and VMX; open-architecture applications based
on the VMEbus; and hardware-dependent software, such as device drivers and bus
communication protocols.  The group is also available for questions and
answers, so that developers of VMEbus-based hardware and software can get
feedback or help with any problems they may encounter.

Discussions should not be about hardware-independent software which use the
VMEbus, such as the operating system or language being used, as there are other
comp.* newsgroups dedicated to those functions.

The discussion on this proposal will take place in news.groups.

Please see the pertinent postings in news.answers and news.announce.newgroups
for the rules that will be followed in creating a newsgroup
(cf. <spaf-howto_715578991@cs.purdue.edu>).
- -- 
David B. Stewart  - email: <dstewart@cmu.edu>            The Robotics Institute
snail mail:       - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213
Current Projects: - Chimera 3.0 Real-Time Operating System
		  - Reconfigurable Sensor-Based Control Systems

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

Newsgroups: comp.os.vxworks
Subject: Re: re: Best way to implement a task at exactly XX Hertz
Date: 17 Sep 92 01:40:54 GMT
From: dat@noao.edu (D'Anne Thompson)
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Message-ID: <1992Sep17.014054.15436@noao.edu>
References: <1992Sep16.210651.8373@wdl.loral.com>
Sender: news@noao.edu

To all who need accurate timing and plan to use their sysClkxxx or
sysClkAuxxx routines:  BEWARE.

Some cpu boards generate their system clock interrupts (and auxilliary
clock interrupts) from baud rate generator type devices.  These devices
cannot synthesize any random interrupt rate.

As an example, consider the Heurikon V2F cpu's that I use.  The baud
rate generator uses a 2.4576MHz crystal (thats a common frequency).
The board support package code is setup only to use the divide by 200
prescale mode of the M68901 multi-function-peripheral chip.
An attempt to set the system clock to run at 60 hertz results in the
following.

    2457600 / (200 * 60) = 204 with remainder of 9600

Now if you work backwards you find that the frequency of the clock
is actually (2457600 / (200 * 204)) = 60.24 Hertz.

Even rounding the earlier result to 205 generates a clock rate of 
59.94 Hertz.

In the case of the Heurikon V2F board I was forced to use a system
clock rate of 64 Hertz in order to have an accurate clock.
(2457600 / (200 * 64)) = 192 with no remainder.

In summary, if a truly accurate interrupt rate is needed, you had better
investigate your system clocks at the device level before just assuming
that "sysClkRateSet(60)" is going to do what you think it will!

I now have access to WWV satellite clocks (IRIG) and I use them to adjust
the clock rate set in my MFP chip so that I get exactly 64 * 60 * 60 * 24
clock ticks per day.  Now that the IRIG system is installed I could use
it to maintain an even 60 hertz clock rate, but I'm not about to mess with
something thats working).
- -- 
D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732, Tucson, AZ 85726    (602) 325-9335
dat@noao.edu  {...}!uunet!noao.edu!dat

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

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


From @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Thu Sep 17 05:51:55 1992
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Date: Thu Sep 17 05:52:02 PDT 1992
Subject: Re(2): Best way to implement a task at exactly XX Hertz
ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman) sez:

>There is at least one area to worry in the taskSuspend-taskResume approach.
>It is based on assumption that your task is SUSPENDed only by you.
>
>I know at least 2 points where this assumption is wrong:
>        - breakpoint
>        - bus error
>
>In bus-error case (unless you have signal-based recovery) the result will
>be disasterous: ISR will taskResume and your task will hit bus-error again
>(and again and again ...).
>
>I would go with simple binary semaphore approach.

You're right about the BERR -- the sound of a terminal shrieking is
still in my recent memory.

Can you expand a little on the semaphore thing, please?  And how does
it behave when there's an overrun?

BTW, I think I know the *worst* way to execute a task at XX Hz --
call netJobAdd from interrupt to execute your routine at task level.
Actually, depending on your requirements, that might not be all bad,
depending on the priority you give netTask (I think you'd be better
off making a duplicate of netTask).  For one thing, you could easily
manage multiple-clock overruns.  Hmmmmm -- for some requirements
that might be just the ticket.

Thanks,
Bob
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Thu Sep 17 08:21:13 1992
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Date: Thu Sep 17 08:21:22 PDT 1992
Subject: Re: Best way to implement a task at exactly XX Hertz
dat@noao.edu (D'Anne Thompson) sez:

>To all who need accurate timing and plan to use their sysClkxxx or
>sysClkAuxxx routines:  BEWARE.
>
>Some cpu boards generate their system clock interrupts (and auxilliary
>clock interrupts) from baud rate generator type devices.  These devices
>cannot synthesize any random interrupt rate.

That's one of the lovable things about computers.  I recall an experiment
where we actually used that "feature".  We wanted to measure how long
it took a message to get from one bucket to another over FDDI, so we
had the sender generate an interrupt when he sent it and the receiver
generate another interrupt when he got it.  The message was sent when
the aux clock ticked, and for reasons we won't go into here, the receiver
had to poll the FDDI board at some rate, controlled by its aux clock.

We hooked up the IRQ lines to an o'scope.  It turned out that one board
was an MVME147 and the other was an MVME133XT.  Because the clocks were
a *little* bit different, we simply watched them approach the polling
frequency over a period of several minutes and, voilla! the answer.

It's been traditional in the flight simulation business to sell 50 Hz
or 25 Hz max iteration rate simulators to European customers and
60 Hz or 30 Hz simulators to American customers for that very reason --
the clock on board could only generate certain frequencies.

Actually, in a distributed simulator, we have been syncing the various
buckets on a clock tick message over FDDI.  We can stand a (not too bad)
distribution about a known frequency better than we can stand a
variety of frequencies on the system.  Of course, other applications
will have other requirements.

+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From prb@aplexus.jhuapl.edu  Thu Sep 17 08:54:58 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Thu Sep 17 08:55:05 PDT 1992
Subject: Fastest General Purpose CPU Board
Hello World,

We are currently running a system with many MVME-167 68040 Boards.
But we need to reduce the size significantly in the future. 
Thus we would like to upgrade to faster boards.
Perhaps an R4000, HP PA risc, Sparc, etc.

Suggestions (especially with SpecMarks) are requested.

	Thanx,	

        Paul R. Bade
        Johns Hopkins University / Applied Physics Lab
        (301)-953-5000 x8681
        prb@aplexus.jhuapl.edu



From lauren@wrs.com  Thu Sep 17 15:41:20 1992
From: lauren@wrs.com
Date: Thu Sep 17 15:41:27 PDT 1992
Subject: NFS Server ?
Does anyone know of an NFS Server for VxWorks?



From daemon@vxw.ee.lbl.gov  Sun Sep 20 04:00:45 1992
From: daemon@vxw.ee.lbl.gov
Date: Sun Sep 20 04:00:53 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Sep 20 04:00:39 PDT 1992

        Subject: Spurious interrupts on MVME167 boards
        Subject: Re: how to implement a controller

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

Newsgroups: comp.os.vxworks,comp.sys.m68k
Subject: Spurious interrupts on MVME167 boards
Date: Fri, 18 Sep 1992 12:23:05 GMT
From: nina@fynu.ucl.ac.be (Alain Ninane - FYNU)
Organization: University of Louvain (LLN) - Nuclear Physics Dept.
Keywords: spurious - interrupts - mvme167 - mvme147 - vxworks
Message-ID: <1992Sep18.122305.17296@info.ucl.ac.be>
Followup-To: comp.os.vxworks
Sender: news@info.ucl.ac.be (News Administrator)

Hardware : MVME147, MVME167
Software : VxWorks 5.0.2

Folks,

I have an application which handle VMEbus interrupts
requested by a data acquisition board (to be precise, a
CAMAC branch).  In the user level code, I enclose critical
sections by the sysIntDisable() and sysIntEnable()
routines.  The code was working well, in any condition, on
MVME147 boards.  However, when I started to use the new
MVME167 and under an heavy load of interrupts, I started to
receive a lot of spurious interrupts.

For those who are not aware of what a spurious interrupt
is, let me tell you that such an exception occurs when the
processor tries to read, without succes, the interrupt
vector during an IACK cycle. It's like a bus error in the
vector read operation.

Fortunately, some times ago (July '92), there was a
discussion about spurious interrupts on Motorola boards. A
nice summary was posted by shaffer@stef.crd.ge.com.  In
short, the best way to protect critical sections is not to
disable the VMEbus interrupt handler but instead to raise
the processor priority. Indeed, that solves the problem.

Now, the question ... In the summary, people says that the
spurious interrupt appears when one turns off interrupts in
the middle of an IACK cycle ... How is this possible ? As
far as I know, the IACK cycle is started by the processor
itself. It cannot therefore do something else (and in
particular, it cannot disable the interrupt handler in the
VMEChip2). Am I wrong ? Does the IACK cycle be started by
the VMEChip2 itself ?

I would like to hear any comment on this.

Thanks,

Alain 

- -- 
Dr. Alain H. Ninane     | Tel : +32-10-47.32.73 - Fax: +32-10-45.21.83
University of Louvain   | Internet: Ninane@fynu.ucl.ac.be
Nuclear Physics Dept.   | Ch. du Cyclotron, 2
B-1348 Louvain-la-Neuve | BELGIUM               

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

Newsgroups: comp.os.vxworks
Subject: Re: how to implement a controller
Date: 19 Sep 92 01:42:50 GMT
From: lim@telerobotics.jpl.nasa.gov (David Lim)
Organization: Jet Propulsion Laboratory
Message-ID: <LIM.92Sep18174250@oriole.jpl.nasa.gov>
References: <9209051514.AA08750@thalia.jpl.nasa.gov>
Reply-To: lim@telerobotics.jpl.nasa.gov
Sender: news@elroy.jpl.nasa.gov (Usenet)


In general would you recommend rearranging the task priorities of VxWorks
tasks such that yours is the highest. I.e. would you put your task at priority
1 and move all the vxWorks tasks to be higher than yours, with the exception of
excTask?

I suppose another alternative is to place your task at priority 0 along with
excTask and logTask. But that seems dangerous if your task encounters an
exception. 

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

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


From daemon@vxw.ee.lbl.gov  Mon Sep 21 04:00:42 1992
From: daemon@vxw.ee.lbl.gov
Date: Mon Sep 21 04:00:50 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Sep 21 04:00:35 PDT 1992

        Subject: MailBoxInterupt
        Subject: MVME117 & ST3283N Help wanted
        Subject: Processor disappearing from backplane network
        Subject: Re: interphase 4211 driver??

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

Newsgroups: comp.os.vxworks
Subject: MailBoxInterupt
Date: 20 Sep 92 18:59:26 GMT
From: skoft@itk.unit.no (Gunleiv Skofteland)
Organization: Norwegian Institute of Technology / SINTEF, Trondheim, Norway
Message-ID: <SKOFT.92Sep20195926@robert.itk.unit.no>
Sender: news@ugle.unit.no (NetNews Administrator)


I want to send messages (12 bytes) from one CPU (mv165) to another
(mv147) at 30 Hz on VME backplane. I am concidering using
mailboxinterupts, but I don't know how to use it. I would welcome any
help from experienced users. 

The messages are positions estimated from video-images, and are inputs
to a robot controller. Real time is very important. 


I have tried using sockets for the communication, but it
fails at this speed due to latency.



- --
Gunleiv Skofteland
Institutt for Teknisk Kybernetikk	: Tel	+47 7 594386
NTH					: Fax	+47 7 594399
7034 Trondheim				: Email	skoft@itk.unit.no

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

Newsgroups: comp.os.vxworks
Subject: MVME117 & ST3283N Help wanted
Date: 20 Sep 92 22:37:53 GMT
From: eks@pe.dk (Eigil Krogh Soerensen)
Organization: Purup Electronics A/S, Denmark
Keywords: Seagate ST3283N MVME117 MVME117-bug VersaDOS
Message-ID: <1818@pe.dk>


I'm trying to get a Seagate ST3283N disk drive running with a MVME117 board
and VersaDOS.

Hope someone can help with the following two problems.

1.
When connected to the MVME117 board the terminator power must come from the
SCSI bus and the termination on the drive must be 220/330 ohms passive.

I have two descriptions of how to configure the drive that way 
a)
"Seagate ST3283 Family: Installation Guide, Rev. A" 
b)
"Seagate ST3283 SCSI Interface Drive Product Manual"

When I follow these descriptions the drive acts as if it has no SCSI terminators
at all.

How is the right way to jumper/configure the drive.


2.
If I set the SCSI-bus termination jumpers slight different from the descriptions
the drive *acts* as if the SCSI-bus termination works. BUT now the MVME117
initiator hangs when the drive is accessed. This counts both for the MVME117-
bug and the opr.-sys. VersaDOS.

Why is that ?

MVME117-bug version is 1.x
MVME117 scsi firmware version is 1.1
VersaDOS version is 4.51.

The MVME117 initiator system is not able to handle dis-/reconnect. That 
shouldn't be any problem as the drive is not allowed to dis-/reconnect
unles it is allowed to by the initiator. Is there a problem here with the
ST3282N drive ?


The MVME117 system runs fine with a Seagate ST4350N WREN IV 94171-350 drive !



Thank you in advance.

Eigil Krogh Sorensen

(eks@pe.dk)

Purup Prepress.

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

Newsgroups: comp.os.vxworks
Subject: Processor disappearing from backplane network
Date: 21 Sep 92 03:11:47 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep21.031147.27873@afterlife.ncsc.mil>

Under 5.0.2:
I have two Force CPU-40s, one of which acts as a gateway between the
ethernet and the backplane network.  After proc 1 boots via the
gateway, it recv()'s a TCP stream from proc 0.  Every 2 seconds proc 0
send()'s ~100kB to proc 1 in ~64B chunks.  During normal operation,
bpShow() on each processor shows that there are 2 processors on the
backplane net, and the number of input packets from proc 1 tracks the
number of output packets from proc 0.

After about 30 hours of operation, the send() on proc 0 fails with
an errno of EPIPE (actually S_iosLib_EPIPE, I think).  From what I can
tell, this occurs because proc 0 believes there is no reader on the
socket being written.

A bpShow() on each processor at this point shows some strange things.
First, bpShow() on either processor now only reports that proc 0 is on
the backplane network.  Secondly, while proc 1 shows ~5 million input
packets and ~3 million output packets (which I assume are due to TCP
acknowledgements), proc 0 shows 50 input packets and 51 output
packets.

Once in this state, no further backplane network communication can
be initiated or completed.  Attempting to connect from one processor
to the other results in an ETIMEDOUT.

Has anyone seen any similar behavior?  Any suggestions as to where to
look or what to look for next?

Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

Newsgroups: comp.os.vxworks
Subject: Re: interphase 4211 driver??
Date: 21 Sep 92 03:37:42 GMT
From: flash@austin.lockheed.com (James W. Melton)
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744
Message-ID: <1204@shrike.com>
References: <9209151650.AA13188@coyote.draper.com>

In article <9209151650.AA13188@coyote.draper.com> lacy@draper.com (Carl Lacy) writes:
>
>   Yes, AP Labs sells one.  I've been working with it for several weeks
>and after some confusion, porting, and debugging it appears to be working.
>(At least on a MVME167 with 5.0.2).
>

Actually, the driver should be available from your friendly
Interphase sales person. The driver belongs to Interphase; they
paid AP Labs to write it. However, don't look for much support. AP
Labs won't talk to you unless you bought it from them and
Interphase is just now spinning up their vxWorks expertise.

Caution: The driver AS SHIPPED assumes the following nasty things:

	1) That VME addressing is the same as local addressing.
	   There is even a comment where sysLocalToBusAdrs *should*
	   be that they chose a macro because it is faster. Didn't
	   work on my board (Tadpole TP-41)
	2) That the DMA address space is in A24 (STD) space. Sorry,
	   but in my architecture everything is in A32 (EXT) space.
	   Changing THAT required the technical expertise of a nice
	   guy at Interphase.

That said, the board seems to work great. After following the sales
channels at Interphase, I *did* get the support I needed to get the
driver working, including finding out that I had it cabled wrong!
(makes a difference) The folks at Interphase went the extra mile.
The folks at AP Labs wouldn't even get out of their chair.

Just my experience.



- -- 
Jim Melton, novice guru
email:      flash@austin.lockheed.com | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"

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

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


From interf!zeus!brackett@uunet.uu.net  Mon Sep 21 06:47:32 1992
From: interf!zeus!brackett@uunet.uu.net (Todd Brackett)
Date: Mon Sep 21 06:47:39 PDT 1992
Subject: job in DC
Interferometrics Inc. is looking for an experienced VxWorks programmer
to work on a sattelite ground station system and other projects.
Candidates should have 2+ years experience with VxWorks on 68K targets.

Please respond directly to the address below if interested.

Thanks,

-------------------------------------------------------
|Todd S. Brackett                 |Voice:703 790 8500 |
|Interferometrics, Inc.           |FAX:  703 848 2492 |
|8150 Leesburg Pike               |                   |
|Vienna, VA 22182                 |                   |
|-----------------------------------------------------|
|Internet:brackett@interf.com                         |
|Uunet:   uunet!interf!brackett                       |
-------------------------------------------------------



From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Mon Sep 21 07:55:40 1992
From: Carl Lacy <lacy@coyote.draper.com>
Date: Mon Sep 21 07:55:48 PDT 1992
Subject: Re: interphase 4211 driver??
   Yes, those were the problems with the AP Labs driver that I saw also.  
I also got no help from AP Labs (as Interphase was the licensee), and spent 
4 weeks debugging the driver for my target.

   Also if you're using the driver, consider adding

	return (0);

to the end of the initialization section.  In my mvme167 target that
function did not explicitly set its return, so the caller, set_if_addr, 
saw a failure code, and then did not set the IP address in the driver's
ifnet data structure.  This left the driver with an IP address of 0.0.0.0,
with resulting ARP duplicate address problems.

   Bottom line:  If you're using the AP Labs driver, just buy a support 
contract from them. 


From psm%helios.nosc.mil@nosc.mil  Mon Sep 21 11:30:44 1992
From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
Date: Mon Sep 21 11:30:52 PDT 1992
Subject: Evaluating VME CPUs
We are about to launch an evaluation of the following VME boards for
suitability to our application:

Performance Technology PT-VME141
Force CPU40
Synergy SV430

Besides the general 'performance' (criteria for which we have yet to
define) of the boards, we are particularly interested in Ada support,
and in how well they are able to handle at least 4 high-speed
(>256kbits) synchronous serial I/O channels.  I'd appreciate hearing
from anyone else who has looked into these boards. I'd also
appreciate hearing about what other people have used for evaluation
criteria of such products in the past.

Scot McIntosh





From daemon@vxw.ee.lbl.gov  Tue Sep 22 04:00:56 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 22 04:01:04 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 22 04:00:42 PDT 1992

        Subject: Re: Processor disappearing from backplane network
        Subject: VxGDB Single Step Problem
        Subject: Re: VxGDB Single Step Problem
        Subject: Re: Processor disappearing from backplane network

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

Newsgroups: comp.os.vxworks
Subject: Re: Processor disappearing from backplane network
Date: Mon, 21 Sep 1992 15:54:27 GMT
From: geger@phantom.den.mmc.com (George Eger (303) 971-6974)
Organization: Fault Tolerant Avionics, Martin Marietta Astronautics Group
Keywords: BP Interface
Message-ID: <1992Sep21.155427.18141@den.mmc.com>
References:  <1992Sep21.031147.27873@afterlife.ncsc.mil>
Sender: news@den.mmc.com (News)

In article <1992Sep21.031147.27873@afterlife.ncsc.mil>, smb@afterlife.ncsc.mil
(Steve M. Burinsky) writes:
|> Under 5.0.2:
|> I have two Force CPU-40s, one of which acts as a gateway between the
|> ethernet and the backplane network.  After proc 1 boots via the
|> gateway, it recv()'s a TCP stream from proc 0.  Every 2 seconds proc 0
|> send()'s ~100kB to proc 1 in ~64B chunks.  During normal operation,
|> bpShow() on each processor shows that there are 2 processors on the
|> backplane net, and the number of input packets from proc 1 tracks the
|> number of output packets from proc 0.
|> 
|> After about 30 hours of operation, the send() on proc 0 fails with
|> an errno of EPIPE (actually S_iosLib_EPIPE, I think).  From what I can
|> tell, this occurs because proc 0 believes there is no reader on the
|> socket being written.
|> 
|> A bpShow() on each processor at this point shows some strange things.
|> First, bpShow() on either processor now only reports that proc 0 is on
|> the backplane network.  Secondly, while proc 1 shows ~5 million input
|> packets and ~3 million output packets (which I assume are due to TCP
|> acknowledgements), proc 0 shows 50 input packets and 51 output
|> packets.
|> 
|> Once in this state, no further backplane network communication can
|> be initiated or completed.  Attempting to connect from one processor
|> to the other results in an ETIMEDOUT.
|> 
|> Has anyone seen any similar behavior?  Any suggestions as to where to
|> look or what to look for next?
|> 
|> Thanks.
|> -- 
|> 
|> Steve M. Burinsky
|> smb@afterlife.ncsc.mil

I think you should check to see if the Force card has rebooted.  I have some
experience w/ a MVME-167 acting as gateway for 4 SBE VCOM-100 FDDI cards.
When the 167 goes down/reboots, it zero's its own memory, which happens
to include the BP control block and buffer pool.  The SBE's are left waiting
for an indication of something to happen (through mailboxes that were 
listed/attached in the old BP control block).  The 167 has disconnected the
SBE's, so it no longer knows about them, and the SBE's never check to see
if they are still attached to the BP.

Try using a block of offboard memory on a separate card.  The proc 0 Force
card should be set to not clear this memory, so it may be able to have it
come back up without loosing the proc 1 attachment.

Check to see if proc 0 Force is rebooting/restarting the BP interface.  Probably
a symptom of another problem anyway.

Good Luck.

George Eger

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

Newsgroups: comp.os.vxworks
Subject: VxGDB Single Step Problem
Date: Mon, 21 Sep 1992 14:22:22 GMT
From: gould@waterloo.hp.com
 (Dan Gould)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <BuxMLA.K3J@waterloo.hp.com>
Sender: news@waterloo.hp.com (NetNews)


Sometimes, but not always, the VxGDB Next function attempts to step into
VxWorks system calls (eg: printf()). When this happens, it is difficult
and sometimes impossible to get back to the execution stream of interest.

I am debugging a remote target, and am using the X-Windows version of
VxGDB.

Does anyone know what causes this?

- --
Dan Gould
gould@waterloo.hp.com

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

Newsgroups: comp.os.vxworks
Subject: Re: VxGDB Single Step Problem
Date: Tue, 22 Sep 1992 00:23:48 GMT
From: markf@wrs.com (Mark Fox)
Organization: Wind River Systems, Inc.
Message-ID: <BuyEFp.8A6@wrs.com>
References: <BuxMLA.K3J@waterloo.hp.com>
Sender: news@wrs.com (News Manager)

gould@waterloo.hp.com (Dan Gould) writes:

> Sometimes, but not always, the VxGDB Next function attempts to step into
> VxWorks system calls (eg: printf()). When this happens, it is difficult
> and sometimes impossible to get back to the execution stream of interest.

Internally, the "next" command actually does single-step into functions.
When this happens, VxGDB sets a temporary breakpoint at the next instruction
to be executed in the calling frame, then silently continues the target task.
All of this should be invisible to the user.

The behavior you describe can occur when you attempt to "next" over a 
function whose address is unknown to VxGDB.  This situation will arise
when VxGDB, in the process of connecting to a target system, can't find
an object module that was loaded into the VxWorks target during a previous
debugging session.  In this case, when you give the "target" command, you'll
see something like this:

    (vxgdb) targ tmarkf
    Attaching remote machine across net...
    Connected to tmarkf.
    Reading symbol data from /folk/markf/vw.502b/config/mv147/vxWorks...
    (no debugging symbols found)...done.
    test2.o: No such file or directory.

If you now try to single-step over a function located in "test2.o," VxGDB
will step into the function as normally, then halt the target program.
It does this because--not knowing the address of the function in which the
program is executing--it thinks you might have stepped to some random
address not in your program, and wants to warn you about this.

If this is happening when you step over a call to printf (), it might be
that VxGDB was unable to locate the VxWorks boot image when connecting to
the target.  This will happen if, for some reason, the boot file is not
accessible to VxGDB via the pathname specified to the VxWorks target as
boot parameter.

Of course, if there is a breakpoint set within the code you're stepping over,
the target program will hit that breakpoint.  But from your description, I
don't think that this is what is happening, since this would have been less
mysterious--VxGDB would have told you that the target program was stopping
at a breakpoint.

In any case, you should be able to use the "finish" command to get back to
the frame from which the "next" command was issued.

Mark Fox
Wind River Systems

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

Newsgroups: comp.os.vxworks
Subject: Re: Processor disappearing from backplane network
Date: 22 Sep 92 03:43:18 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Keywords: BP Interface
Message-ID: <1992Sep22.034318.641@afterlife.ncsc.mil>
References: <1992Sep21.031147.27873@afterlife.ncsc.mil> <1992Sep21.155427.18141@den.mmc.com>

In article <1992Sep21.155427.18141@den.mmc.com> geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes:
>
>I think you should check to see if the Force card has rebooted.

Neither processor is rebooting.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

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


From tlusco@inquisitor.gsfc.nasa.gov  Tue Sep 22 06:14:59 1992
From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco)
Date: Tue Sep 22 06:15:08 PDT 1992
Subject: DR11W Communications

Has anyone out there used a DR11W under VxWorks?

We are trying to use VMIC's DR11W-A card with some Heurikon V3Ds
to do some acquisition from DR11W devices.  So far we have had
problems getting the cards to initiate DMA cycles.

If anyone has any experience with DR11W or similar interfaces, we 
would appreciate any help you can give.  Please contact me privatly or on
the list, whichever is most convenient.

Brief problem description:

One crate with V3D as controller, 64MB memory card and DR11W, 
One crate with V3D as controller, 64MB memory card and DR11W, additional
V3D CPUs.  As a test case, we are trying to get one crate to talk to the
other crate through the DR11Ws.  We set one DR11W as reader, one as writer.
then initiate DMA transfer.  Plugging in a bus analyzer on the read side shows that
two words were transferred into memory...sometimes.  Sometimes we only get one, 
sometimes none at all.  Very frustrating.

Tom Lusco
electronics Engineer
XTE spacecraft GSE
NASA/GSFC
tlusco@inquisitor.gsfc.nasa.gov


From enorgren@ehsl.mitre.org  Tue Sep 22 07:45:32 1992
From: enorgren@ehsl.mitre.org (Eric J Norgren)
Date: Tue Sep 22 07:45:39 PDT 1992
Subject: submitting articles 
Exploder Rep:

	I am currently working in the Electronic Hardware Standards Laboratory 
( EHSL ) in Reston, VA.  We are developing real-time data/voice/video 
communication systems for the Army, Navy, and Air Force.  We are working
on standards for a real-time voice data transfer protocol as well as a 
standardized call setup protocol for connecting to different hosts.

	I would like to submit article(s) to the exploder.  What is the 
procedure for submitting articles to the exploder?  Thank you for your
assistance.


Sincerely,

Eric Norgren


From tom@as.arizona.edu  Tue Sep 22 11:08:52 1992
From: tom@as.arizona.edu (Thomas J. Trebisky)
Date: Tue Sep 22 11:08:59 PDT 1992
Subject: DR11W software
There was recent interest in software for a VMIC DR11W board.  The following
may not be of interest since my work was done for the Ikon Corp board, but
anyway....

I wrote software for the Ikon corp. "buffered VMEbus DR11-W emulator" that
is presently running fine under VxWorks.  I don't know if this would be of
any use to you, but I could make it available to you if you have any interest.
Let me know.  This was used in a VME box with a MVME147A cpu board, but 
very little of the software should be specific to that cpu.


	Tom



From psm%helios.nosc.mil@nosc.mil  Wed Sep 23 08:32:12 1992
From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
Date: Wed Sep 23 08:32:19 PDT 1992
Subject: Re: submitting articles
Has anyone put up the NFSSTONE benchmark program under vxworks?





From mitchell@aaec1.aaec.com  Wed Sep 23 14:01:30 1992
From: mitchell@aaec1.aaec.com
Date: Wed Sep 23 14:01:38 PDT 1992
Subject: Re: Spurious interrupts
>Now, the question ... In the summary, people says that the
>spurious interrupt appears when one turns off interrupts in
>the middle of an IACK cycle ... How is this possible ? As
>far as I know, the IACK cycle is started by the processor
>itself. It cannot therefore do something else (and in
>particular, it cannot disable the interrupt handler in the
>VMEChip2). Am I wrong ? Does the IACK cycle be started by
>the VMEChip2 itself ?
>
>I would like to hear any comment on this.
>
>Thanks,
>
>Alain 
>

There is a finite amount of time from the interrupt assertion to the
processor running the IACK cycle.  Even if there were no other interrupters
to the CPU, this time would be non-zero, and this type of failure could 
occur because the signal must propagate all the way to the CPU, which then
has to finish any instructions that are in process.  In this case, spurious
interrupts are unlikely, since the probability of hitting the peripheral
while it is asserting IRQ is low.  Thus its not turning off the interrupter
during
an IACK cycle, but during an IRQ before the IACK.

If the CPU is servicing an interrupt of equal or higher priority, or is
under and "intlock", it will not run the IACK cycle until these conditions
are cleared.  Since the 68030 will consider any interrupt that is valid for
2 CPU cycles, (correct me if I'm wrong) if an interrupt came in during an
"intlock" and the interrupter was disabled during the same intlock, then a
spurrious interrupt will occur after the intUnlock when the CPU runs the
IACK cycle.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
 
                                



From daemon@vxw.ee.lbl.gov  Thu Sep 24 04:01:38 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 24 04:01:46 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 24 04:01:31 PDT 1992

        Subject: FORSALE: 68020 VME System $650
        Subject: Force CPU-40 BP_TAS hardware bug?
        Subject: network numbers for backplane networks
        Subject: Re: Evaluating VME CPUs

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

Newsgroups: comp.os.vxworks
Subject: FORSALE: 68020 VME System $650
Date: Thu, 24 Sep 1992 00:00:41 GMT
From: sja@world.std.com (Stuart J Adams)
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <Bv22p6.uw@world.std.com>

I have the following VME system for sale for $650 or best offer.

3 slot VME enclosure w/ power supply
  This is a Series 3 enclosure from Electronic Solutions
  with a 175W power supply. It is 3.5" x 19.75" x 17" and
  is rack mountable.
  Complete Manuals

Motorola MVME134/D1 16MHz 68020 VME CPU Card with 68851 PMMU
   4 MBytes RAM
   2 Serial Ports
   Battery Backey Clock/NVRAM
   MVME134BUG in ROM
   Complete Manuals on Board and ROM Monitor

Motorola MVME333-2 Intelligent Communications Controller VME Card
  This a 10MHz 68010 based six channel serial controller card
  with 512K RAM.
   MVME333BUG in ROM
   Complete Manuals on Board and ROM Monitor

MVME705A/D2 Serial Transciever Module
  Transceiver Module for the above board. Connects to P2 on VME
  bus and brings serial channels to DB-25 connectors
  Complete Manuals

This is system was hardly used and is in mint condition.
(No dust, scratches, marks, etc.)

Thanks,
Stuart Adams
sja@world.std.com


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

Newsgroups: comp.os.vxworks
Subject: Force CPU-40 BP_TAS hardware bug?
Date: 24 Sep 92 02:47:22 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep24.024722.14909@afterlife.ncsc.mil>

I've heard that the Force CPU-40 suffers from a hardware bug that makes a
test-and-set (TAS) instruction on the VMEbus unreliable (whatever that means).
In any case, I've been having problems booting a CPU-40 across the backplane.
After "Loading...", things hang about 30% of the time.  Rumor has it that
changing BP_TAS to FALSE (choosing software TAS on the bp net) will fix
my problem.  Anyone else run into this?

Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

Newsgroups: comp.os.vxworks
Subject: network numbers for backplane networks
Date: 24 Sep 92 03:14:02 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep24.031402.15646@afterlife.ncsc.mil>

Currently, I allocate a unique network number for every crate I have with
a backplane network running.  Since my group has lots of crates under
development, I could chew up a large number of network numbers over the next
few years.  I have considered using subnetting to help me make better use
of network numbers.

I considered allocating a new network number for each project.  Then, I
would subnet that network for each instance (copy of a given crate) that
I create.  However, I haven't had much success making this work.  From what
documentation I can find on subnetting, I think I'm trying to do something
it was not intended for.  Everyone I've talked to knows just enough about
subnetting to not be sure if this should work.  

How do you deal with network numbers for backplane networks?

Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

Newsgroups: comp.os.vxworks
Subject: Re: Evaluating VME CPUs
Date: 23 Sep 92 12:55:21 EST
From: els@icf.hrb.com (Eric L. Schott)
Organization: HRB Systems, Inc.
Message-ID: <1992Sep23.125521.19586@icf.hrb.com>
References: <9209211832.AA05757@helios.nosc.mil>

In article <9209211832.AA05757@helios.nosc.mil>, psm%helios.nosc.mil@nosc.mil (Scot McIntosh) writes:
> We are about to launch an evaluation of the following VME boards for
> suitability to our application:
> 
> Performance Technology PT-VME141
> Force CPU40
> Synergy SV430
> 
> Besides the general 'performance' (criteria for which we have yet to
> define) of the boards, we are particularly interested in Ada support,
> and in how well they are able to handle at least 4 high-speed
> (>256kbits) synchronous serial I/O channels.  I'd appreciate hearing
> from anyone else who has looked into these boards. I'd also
> appreciate hearing about what other people have used for evaluation
> criteria of such products in the past.

We did a similar evaluation of single board computers, some of which
are in you list.  We began testing with following "standalone" tests:
  1.  DMA (VMEbus to SBC memory)
  2.  TCP socket speeds to a SparcStation
  3.  Raw dhrystones (dhry-2)
These tests showed significant differences between products.  The key
results were:
  1.  VMEbus speeds had dramatic ranges.  One board max'ed out at 3.8
      Megabyte/s and another max'ed at 40.9 MB/s.  Some boards did/
      did not support D32 BLT and D64 BLT.
  2.  TCP speeds were rather consistent (0.45 MB/s) except for two
      boards: one was 0.065 MB/s and another was 0.822 MB/s.
  3.  Most boards ran 9500 Dhrys/s.  One board had full cache control
      and was running 23,188 Dhrys/s.
For those interested, one specific board had the highest rates in all
three catagories.

We then took the best two performing boards and executed one "combined"
benchmark which did simultaneous execution of the above three tests.
Fixed quantities were chosen for the test so that all three transfers
on the slowest board completed at nearly the same time.  This test
showed dramatic results:
              Standalone           Combined
   Board   Net   DMA   Dhry    Net   DMA   Dhry
     A    .491   4.4   9375   .256   3.8    161
     B    .822  19.4  23188   .878  15.9   6138
   DMA was either D32 or D32 BLT.
When all was done, we bought board "B."  (See if you can determine
which entry is "puzzling.")

In summary:
  1.  Select good benchmark tests
  2.  Be sure to have one "simulated application"
  3.  Watch the cache issues:  some boards support hardware to invalidate
      cache, so don't.
  4.  Ignore ALL vendor claims.  Run your own benchmarks.  Work with
      the vendors to resolve discrepencies.
- -- 

Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"

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

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


From fjr@rayssd.ssd.ray.com  Thu Sep 24 11:47:24 1992
From: Roeber <fjr@ssd.ray.com>
Date: Thu Sep 24 11:47:32 PDT 1992
Subject: Re: network numbers for backplane networks
>  Subject: network numbers for backplane networks
Steve M. Burinsky writes:
>  
>  Currently, I allocate a unique network number for every crate I have with
>  a backplane network running.  Since my group has lots of crates under
>  development, I could chew up a large number of network numbers over the next
>  few years.  I have considered using subnetting to help me make better use
>  of network numbers.
>  
>  I considered allocating a new network number for each project.  Then, I
>  would subnet that network for each instance (copy of a given crate) that
>  I create.  However, I haven't had much success making this work.  From what
>  documentation I can find on subnetting, I think I'm trying to do something
>  it was not intended for.  Everyone I've talked to knows just enough about
>  subnetting to not be sure if this should work.  
>  
>  How do you deal with network numbers for backplane networks?

It took us a while to figure out how to subnet our network and get all the
routing issues worked out.  It works just fine now under VxWorks.  Each
crate is it's own subnet.  While you can get things set up this way, a new
protocol that WRS announced support for at last weeks user group meeting
should go a long way towards making multiple crate networks much easier to
set up and maintain.  Basically, WRS has added support for "proxy arp" to
their network code.  Since it sounds like you are trying to prepare for the
future rather than address a current problem, I would suggest you just wait
till the next release of VxWorks is available and then configure proxy arp
to do what you want (I'm sure the documentation that comes with the release
will make it very clear how to configure it ;-).   Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|


From daemon@vxw.ee.lbl.gov  Fri Sep 25 04:00:55 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Sep 25 04:01:04 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Sep 25 04:00:47 PDT 1992

        Subject: Re: network numbers for backplane networks
        Subject: Re: Force CPU-40 BP_TAS hardware bug?
        Subject: Proxy arp (was "network numbers for backplane networks")
        Subject: Re: Spurious interrupts (SUMMARY)

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

Newsgroups: comp.os.vxworks
Subject: Re: network numbers for backplane networks
Date: 24 Sep 92 23:08:39 GMT
From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Sep24160839@iphasew.iphasew.com>
References: <1992Sep24.031402.15646@afterlife.ncsc.mil>
Sender: hwajin@iphasew.com


>>>>> On 24 Sep 92 03:14:02 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said:

Steve> I considered allocating a new network number for each project.
Steve> Then, I would subnet that network for each instance (copy of a
Steve> given crate) that I create.  However, I haven't had much
Steve> success making this work.  From what documentation I can find
Steve> on subnetting, I think I'm trying to do something it was not
Steve> intended for.  Everyone I've talked to knows just enough about
Steve> subnetting to not be sure if this should work.

using subnets with backplane devices work fine -- i know several people
who have done this in the past.  also, i heard a rumor that the new
release of vxworks has proxy arp, which should allow another solution
that will work nicely for backplane nets.  i know somewhere in
those archive disks of wind river, there are some application
notes about this stuff -- at least about subnetting over bp, etc., so
i'd talk to them for help.

	~hwajin

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

Newsgroups: comp.os.vxworks
Subject: Re: Force CPU-40 BP_TAS hardware bug?
Date: 24 Sep 92 23:03:01 GMT
From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Sep24160301@iphasew.iphasew.com>
References: <1992Sep24.024722.14909@afterlife.ncsc.mil>
Sender: hwajin@iphasew.com

>>>>> On 24 Sep 92 02:47:22 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said:

Steve> I've heard that the Force CPU-40 suffers from a hardware bug
Steve> that makes a test-and-set (TAS) instruction on the VMEbus
Steve> unreliable (whatever that means).  In any case, I've been
Steve> having problems booting a CPU-40 across the backplane.  After
Steve> "Loading...", things hang about 30% of the time.  Rumor has it
Steve> that changing BP_TAS to FALSE (choosing software TAS on the bp
Steve> net) will fix my problem.  Anyone else run into this?

you probably already know tas being good for implementing something
like semaphores since it's automic test-and-update.  in vme/m68k
context, tas is implemented using rmw (read-modify-write) cycle, which
is automic, if your board's bus interface logic doesn't implement this
properly, tas'ing to off-board memory won't always work.  on boards that
have trouble with tas (i'm using one), you can use software-tas option
in backplane driver, which emulates tas by checking the location
several times after it is test-and-set.  if you still have trouble
with this, you can try turning data-cache off.  in 4.0.x vxworks,
you do this by modifying sysALib.s in your bsp (sysCacheEnable routine).
in 5.0+ vxworks, i think wrs added cacheLib, so you should use the
routines in cacheLib.

	~hwajin

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

Newsgroups: comp.os.vxworks
Subject: Proxy arp (was "network numbers for backplane networks")
Date: Fri, 25 Sep 1992 04:19:52 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep25.041952.22130@afterlife.ncsc.mil>
References: <199209241328.AA00372@pike.ssd.ray.com>

Could someone please explain what proxy arp will or won't do for me?

- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

Newsgroups: comp.os.vxworks
Subject: Re: Spurious interrupts (SUMMARY)
Date: Fri, 25 Sep 1992 09:33:46 GMT
From: Ninane@fynu.ucl.ac.be (Alain Ninane - FYNU)
Organization: University of Louvain (LLN) - Nuclear Physics Dept.
Message-ID: <1992Sep25.093346.23760@info.ucl.ac.be>
Followup-To: comp.os.vxworks
Sender: news@info.ucl.ac.be (News Administrator)


Folks,
One week ago, I posted a request about spurious interrupts on a
MVME167 board.  I knew the solution but I wanted to understand
why the problem was cured.

Original posting:
>  Hardware : MVME147, MVME167
>  Software : VxWorks 5.0.2

>  I have an application which handle VMEbus interrupts
>  requested by a data acquisition board (to be precise, a
>  CAMAC branch).  In the user level code, I enclose critical
>  sections by the sysIntDisable() and sysIntEnable()
>  routines.  The code was working well, in any condition, on
>  MVME147 boards.  However, when I started to use the new
>  MVME167 and under an heavy load of interrupts, I started to
>  receive a lot of spurious interrupts.
>  
>  For those who are not aware of what a spurious interrupt
>  is, let me tell you that such an exception occurs when the
>  processor tries to read, without succes, the interrupt
>  vector during an IACK cycle. It's like a bus error in the
>  vector read operation.
>  
>  Fortunately, some times ago (July '92), there was a
>  discussion about spurious interrupts on Motorola boards. A
>  nice summary was posted by shaffer@stef.crd.ge.com.  In
>  short, the best way to protect critical sections is not to
>  disable the VMEbus interrupt handler but instead to raise
>  the processor priority. Indeed, that solves the problem.
>  
>  Now, the question ... In the summary, people says that the
>  spurious interrupt appears when one turns off interrupts in
>  the middle of an IACK cycle ... How is this possible ? As
>  far as I know, the IACK cycle is started by the processor
>  itself. It cannot therefore do something else (and in
>  particular, it cannot disable the interrupt handler in the
>  VMEChip2). Am I wrong ? Does the IACK cycle be started by
>  the VMEChip2 itself ?

Phillip L. Shaffer (shaffer_phillip@ae.ge.com) says that:
> As I understand it, IACK is initiated by an interrupt, which is
> of course asynchronous with instruction execution, so you can be
> executing an instruction that disables just as an interrupt is
> occurring -- thus the occasional problem.

and, Andrew Mitchell (mitchell@aaec.com) writes:
> There is a finite amount of time from the interrupt assertion to the
> processor running the IACK cycle.  Even if there were no other interrupters
> to the CPU, this time would be non-zero, and this type of failure could 
> occur because the signal must propagate all the way to the CPU, which then
> has to finish any instructions that are in process.  In this case, spurious
> interrupts are unlikely, since the probability of hitting the peripheral
> while it is asserting IRQ is low.  Thus its not turning off the interrupter
> during an IACK cycle, but during an IRQ before the IACK.

Below, I have tried to sketch a scenario.  If an interrupt comes at
the same time the CPU is executing the instruction to disable the
VMEbus interrupts, the IACK will be started but will failed due to
the disabled interrupter (--> spurious irq).  The situation is even
worst if I listen to the Andrew's comment about time propagation on
the board.  The (not yet spurious) IRQ could be started even before
the CPU executes the code to disable the interrupter.

If the interrupts are ``disabled'' by raising the processor priority,
the problem doesn't occur because the IACK cycle is not started (if
it started, the ISR would be executed - a forbidden situation with
regards to the CPU status register !).

    ---- Time axis ------->
    |<--   Disable instruction    ->|

    -----   -----   -----   -----    -----   -----    -----   -----
    |   |   |   |   |   |   |   |    |   |   |   |    |   |   |   |
    |   |   |   |   |   |   |   |    |   |   |   |    |   |   |   |
  ---   -----   -----   -----   -----    -----   ------   -----   ----

                                |
                                |
      /------>------>----->----- ----\
     /                          |     \
    /                           |      \  (IACK cycle)
   /                            \       \
  /                              \       \
(IREQ)                            \
                              (Interrupter disabled)

Now, the problem has never occured on MVME147.  We were first
confronted to it on MVME167.  I suspect therefore that the design of
either the MC68040, the VMEChip2, the PCC2 or the MVME167 leads to
critical courses which were not on the MVM147.

Thanks to all people who give me some hints !

Alain
- -- 
Dr. Alain H. Ninane     | Tel : +32-10-47.32.73 - Fax: +32-10-45.21.83
University of Louvain   | Internet: Ninane@fynu.ucl.ac.be
Nuclear Physics Dept.   | Ch. du Cyclotron, 2
B-1348 Louvain-la-Neuve | BELGIUM               

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

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


From mea@sparta.com  Fri Sep 25 05:14:17 1992
From: mea@sparta.com (Mike Anderson)
Date: Fri Sep 25 05:14:26 PDT 1992
Subject: Re: Proxy ARP
Greetings!

>Could someone please explain what proxy arp will or won't do for me?
>
>- -- 
>
>Steve M. Burinsky
>smb@afterlife.ncsc.mil

Begin Proxy ARP lesson...

  The Address Resolution Protocol (ARP) is used in the event that host A
wishes to communicate with host B and A knows B's internet (i.e.,
logical) address but not B's Ethernet (i.e., physical network)
address.  An ARP request is broadcast by A to the network that
essentially says "please tell me the physical address of the host that
corresponds to this internet address."  In a normal ARP request, all
hosts on the broadcast medium receive the message, but only the host
that actually has the desired internet address responds.  This response
is in the form of an ARP reply packet that essentially says the
following logical address can be found via this physical address.  The
requesting host (host A) then adds this information to its ARP cache
for future reference (the ARP cache can be viewed using the arp -a
command).  As long as the newly cached address keeps being used, the
entry will stay in the cache and no new ARP requests will be needed.
If the cache gets flushed or that entry ages until it gets removed from
the cache, then a new ARP request will be needed if A is to talk to B
again.  For what its worth, I believe that at least some
implementations of UNIX will have all of the hosts that see the ARP
reply cache the logical to physical mapping as well just in case they
need it later.

 ARP requests are broadcasts.  By definition, broadcasts are not
automatically forwarded across gateways (including CPU 0 in a VxWorks
backplane).  This is not a bug but a *feature* to keep the Internet
from being clogged with local broadcast packets.  Therefore, CPUs in
VxWorks backplanes have no means to answer ARP requests by themselves.
Therefore, without an explicit route to get to CPUs on the backplane
(entered via route add or via routed), hosts on the main net cannot
"see" VxWorks CPUs.

  Enter Proxy ARP.  With Proxy ARP, CPU 0 can answer the ARP request for 
a CPU in the backplane by giving CPU 0's physical network address in the
ARP reply.  This means that the requesting host will simply send all
of the packets destined for, say, CPU 1 to CPU 0 and then CPU 0 will have
to forward them (this forwarding is done without the requesting host's
knowledge and no new routing table entries are made).  This also means
that we will no longer have to set the backplane up as a separate
network and establish routes.  With Proxy ARP, the CPUs on the VxWorks 
backplane will no longer appear as though they are using a gateway 
because the Proxy ARP daemon on CPU 0 will make the backplane "look"
just like an extension of the main net with a group of hosts on it.

  As I understand it, the implementation of Proxy ARP for VxWorks 5.1 will
use the base internet address of CPU 0 as a starting address and then
use the CPU number as an offset to determine the new internet number for
the VxWorks CPUs.  E.g., if CPU 0 is 192.48.111.20, then CPU 1 would be
192.48.111.21, CPU 2 would be 192.48.111.22, etc.  This could be an annoying
limitation for some applications, but will probably be offset by the greater
ease of set up and maintenance of Internet numbers for Systems Admin
types who usually don't understand how VxWorks backplanes operate and 
can't quite figure out why you *need* all those network numbers for those
dinky little VMEbus chassis.

End of Proxy ARP lesson...

Hope this helps,


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

Process Distribution/Control and Communications for Distributed Systems

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

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



From daemon@vxw.ee.lbl.gov  Sat Sep 26 04:00:46 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep 26 04:00:54 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep 26 04:00:39 PDT 1992

        Subject: 2nd RFD: comp.sys.vmebus

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

Newsgroups: news.announce.newgroups,news.groups,comp.realtime,comp.robotics,comp.lang.c,comp.sys.m68k,comp.os.os9,comp.os.misc,comp.lang.ada,comp.os.vxworks,comp.sys.sun.hardware
Subject: 2nd RFD: comp.sys.vmebus
Date: Fri, 25 Sep 1992 13:08:57 GMT
From: dstewart+@cs.cmu.edu (David B Stewart)
Organization: The Robotics Institute, Carnegie Mellon University
Message-ID: <Bv4xux.5vL@uunet.uu.net>
Followup-To: news.groups
Sender: tale@uunet.uu.net (David C Lawrence)

This is the 2nd Request for Discussion (RFD) regarding creation of an
unmoderated newsgroup 'comp.sys.vmebus' for discussing all aspects of computing
related to the VMEbus and VMEbus-based systems.

So far the following summarizes what has been discussed on news.groups about
the proposed creation of comp.sys.vmebus:

1- No objections yet.  Some say this newsgroup is long overdue.

2- Naming the newsgroup 'comp.sys.vme' VS. 'comp.sys.vmebus'.
    The shorter name was recommended by one netter, saying that it is a common
    abbreviation.  However, not everyone agrees since VMEbus is the official
    name, and VME is the name of a mainframe operating system.  Based on this,
    I plan on keeping the name 'comp.sys.vmebus' when we have the Call for
    Votes (CFV).

3- One person recommends that the charter of the newgroup be expanded to
    include other buses related to VMEbus, such as Futurebus+.
    Additional discussion on this point is encouraged.  

All discussions should take place in news.groups.

The Call for Votes will occur on Oct. 17 at the earliest, according to the
USENET rules for creating a new newsgroup.  
(cf.  <spaf-howto_715578991@cs.purdue.edu>).

The original Request for Discussion follows:

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

This is a Request for Discussion (RFD) regarding creation of an unmoderated
newsgroup for discussing all aspects of computing related to the VMEbus
and VMEbus-based systems.

comp.sys.vmebus	   Discussions on hardware & software for VMEbus.


The VMEbus is one of the more popular standards for developing
open-architecture applications based on off-the-shelf hardware.  Many hardware
components, operating systems, and applications are based on this standard, yet
there currently is no USENET group where discussions of this standard,
and related items, are appropriate.

The proposal is to create comp.sys.vmebus as a forum for discussing issues
related to developing VMEbus-based systems.  This includes discussion on the
VMEbus Specification; VMEbus-based hardware, such as CPU boards and I/O devices;
secondary buses such as VSB, VXI, and VMX; open-architecture applications based
on the VMEbus; and hardware-dependent software, such as device drivers and bus
communication protocols.  The group is also available for questions and
answers, so that developers of VMEbus-based hardware and software can get
feedback or help with any problems they may encounter.

Discussions should not be about hardware-independent software which use the
VMEbus, such as the operating system or language being used, as there are other
comp.* newsgroups dedicated to those functions.

The discussion on this proposal will take place in news.groups 

Please see the pertinent postings in news.answers and news.announce.newgroups
for the rules that will be followed in creating a newsgroup
(<spaf-howto_715578991@cs.purdue.edu>).
- -- 
David B. Stewart  - email: <dstewart@cmu.edu>            The Robotics Institute
snail mail:       - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213
Current Projects: - Chimera 3.0 Real-Time Operating System
		  - Reconfigurable Sensor-Based Control Systems

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

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


From daemon@vxw.ee.lbl.gov  Tue Sep 29 04:00:57 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 29 04:01:04 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 29 04:00:50 PDT 1992

        Subject: Locking Interrupts..

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

Newsgroups: comp.os.vxworks
Subject: Locking Interrupts..
Date: 29 Sep 92 04:17:11 GMT
From: zafer@bcars474.UUCP (Zafer Elbi)
Organization: Bell-Northern Research, Ottawa, Canada
Keywords: VxWorks
Message-ID: <1992Sep29.041711.8216@bnr.ca>
Sender: zafer@bcars474 (Zafer Elbi)


 

For the following code:

int lock = intLock();
..
..
..--->  Task switch
..
intUnlock();

If there is a task switch occurs in the middle of the interrupt routine, can
the preempting task unlock the interrupts again?

Thanks for the reply..

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

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


From prb@aplexus.jhuapl.edu  Tue Sep 29 05:30:44 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Tue Sep 29 05:30:51 PDT 1992
Subject: Re: comp.os.vxworks newsdigest
zafer writes:
 

-> For the following code:

-> int lock = intLock();
-> ..
-> ..
-> ..--->  Task switch
-> ..
-> intUnlock();

-> If there is a task switch occurs in the middle of the interrupt routine, can
-> the preempting task unlock the interrupts again?


If there are no interrupts allowed, there will be no clock interrupts or 
other interrupts to bring about a task switch. So the answer is,
there is no prempting task.

		Paul Bade


From fjr@rayssd.ssd.ray.com  Tue Sep 29 07:40:49 1992
From: Roeber <fjr@ssd.ray.com>
Date: Tue Sep 29 07:40:56 PDT 1992
Subject: Re: task locking and interrupt locking
>  zafer writes:
>   
>  
>  -> For the following code:
>  
>  -> int lock = intLock();
>  -> ..
>  -> ..
>  -> ..--->  Task switch
>  -> ..
>  -> intUnlock();
>  
>  -> If there is a task switch occurs in the middle of the interrupt routine, can
>  -> the preempting task unlock the interrupts again?
>  
>  
>  If there are no interrupts allowed, there will be no clock interrupts or 
>  other interrupts to bring about a task switch. So the answer is,
>  there is no prempting task.
>  
>  		Paul Bade

While Paul is right that there will be no implicit task switchs, I assume the
original question would be what happens if the code that had interrupts
locked out did an explicit task switch (e.g. resumed a higher priority
task).  Personally, I don't know why someone would do that but I seem to
remember that VxWorks will handle such a situation correctly, unblocking
interrupts for the new task and restoring the lockout when the original
task runs again.  This is covered in the CAVAET section of the intLock
manual page.    Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|





From mitchell@aaec1.aaec.com  Tue Sep 29 12:11:44 1992
From: mitchell@aaec1.aaec.com
Date: Tue Sep 29 12:11:51 PDT 1992
Subject: Re: Locking Interrupts..
>Sender: zafer@bcars474 (Zafer Elbi)
>
>For the following code:
>
>int lock = intLock();
>..
>..
>..--->  Task switch
>..
>intUnlock();
>
>If there is a task switch occurs in the middle of the interrupt routine, can
>the preempting task unlock the interrupts again?
>
>Thanks for the reply..
>
>---------------------------

Interrupt service routines are never preempted by tasks.  They run at
interrupt
level on the CPU, which is kind of like "higher than 0" priority.  They
have no task context and many vxWorks "things" won't work.  The only thing
that can
preempt an interrupt is a higher priority interrupt (or another level 7 if
currently a level 7 (NMI)).  This is for a 680x0, and is the way the chip
works;  I don't know about other CPU families.  intLock() is rarely needed
in an ISR, since the same level interrupt is ignored, other interrupts tend
to be unrelated, no task will run until all pending interrupts are finshed,
and ISR's typically do some simple I/O and/or give semaphores. 

intLock at the task level is quite different; it locks out all interrupts 
(except NMI level 7 - which one tries to avoid using for non-fatal events),
and is very useful when manipulating data that is also used by an ISR. 
Long intLocks() should be avoided because they increase latency, making the
system "less" real-time.  The current interrupt mask is part of the task
context, and is switched with the rest of the task.  If a task is at one
intLock level and is switched out, then the interrupt level mask in the CPU
will be set to the new task's intLock level, and restored when the original
task is switched back in.  If the intLock level is at the default level 7,
then the only way to get a context switch is for the current task to ask
for one via a semGive or other kernel call (see CAVEAT under intLock()). 
intLock levels other that 7 are set with intLockLevelSet(), which sets up
the control word to be used by the "quick" intLock(), intUnlock(). 
intLevelSet() dets the level directly, but is slower than intLock and
intUnlock.
  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200 
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
 
                                



From daemon@vxw.ee.lbl.gov  Wed Sep 30 04:00:32 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep 30 04:00:43 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep 30 04:00:24 PDT 1992

        Subject: Beginner questions on VxWorks
        Subject: Re: comp.os.vxworks newsdigest
        Subject: bug with mutex semaphores in 5.0.2???
        Subject: re: comp.os.vxworks newsdigest
        Subject: Re: 167BUG Diagnostics and VxWorks
        Subject: Re: Locking Interrupts..
        Subject: Re: bug with mutex semaphores in 5.0.2???
        Subject: Intertask communication mechanisms
        Subject: Re: Intertask communication mechanisms

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

Newsgroups: comp.os.vxworks
Subject: Beginner questions on VxWorks
Date: 29 Sep 92 14:31:20 GMT
From: Laurent.vonAllmen@imt.unine.ch
Organization: University of Neuchatel, Switzerland
Message-ID: <1992Sep29.143120.870@unine.ch>

Hello!

Sorry for this beginner request but we are starting a new projet and we have
little time to make a choice. We are evaluating VxWorks:

We would like to answer the following questions:

	- Which types of processor are supported?
	- Is a VME driver included?
	- Which mass storage facility?
	- Any remote debugging?
	- Posix conformance?

We would be grateful if either we receive the answers or we are given
references about these OS comparisons/benchmarks.

Please e-mail answers to

X.400 :  C=ch; A=arcom; P=switch; O=unine; OU=imt; S=vonAllmen; G=Laurent
Internet-style :  Laurent.vonAllmen@imt.unine.ch

Any help mostly welcome. Thank you.

Laurent von Allmen

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

Newsgroups: comp.os.vxworks
Subject: Re: comp.os.vxworks newsdigest
Date: 29 Sep 92 14:41:21 GMT
From: vreeburg@fys.ruu.nl (Jurriaan Vreeburg)
Organization: Physics Department, University of Utrecht, The Netherlands
Message-ID: <1992Sep29.144121.7175@fys.ruu.nl>
References: <9209291230.AA17923@aplexus.jhuapl.edu>

In <9209291230.AA17923@aplexus.jhuapl.edu> prb@aplexus.jhuapl.edu (Paul R. Bade) writes:

>zafer writes:
> 

>-> For the following code:

>-> int lock = intLock();
>-> ..
>-> ..
>-> ..--->  Task switch
>-> ..
>-> intUnlock();

>-> If there is a task switch occurs in the middle of the interrupt routine, can
>-> the preempting task unlock the interrupts again?


>If there are no interrupts allowed, there will be no clock interrupts or 
>other interrupts to bring about a task switch. So the answer is,
>there is no prempting task.

Not completely true. See the man-pages for intLock():


IMPORTANT CAVEAT
intLock() can be called both from interrupt and from task level. When called from a task
context, (which is the case with Zafer), the interrupt lock level is part of the task's context.
Locking out interrupts DOES NOT PREVENT RESCHEDULING. Thus, if a task locks out interrupts and
then invokes kernel services that cause the task to block or causes a higher priortity task to
be ready, then rescheduling will occur and interrupts will be unlocked while other tasks run.
Rescheduling may be expicitly disabled wirh taskLock().

To answer Zafer's question: the preempting task can not intUnlock(), because the lock is not
part of its own context.
 
- -- 
Jurriaan Vreeburg                             email: vreeburg@fys.ruu.nl
Department of Physics and Astronomy           tel.:  (+31)-(0)30-534566
P.O. Box 80.000
3508 TA  Utrecht  Holland

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

Newsgroups: comp.os.vxworks
Subject: bug with mutex semaphores in 5.0.2???
Date: Tue, 29 Sep 1992 17:51:43 GMT
From: doctor@kronos.arc.nasa.gov (Terry Fong)
Organization: NASA/ARC Information Sciences Division
Keywords: semaphore, bug, 5.0.2
Message-ID: <1992Sep29.175143.20505@kronos.arc.nasa.gov>
Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov)

Hi all,

I seem to be having a problem with mutual exclusion semaphores: they
don't seem to work at all!!!! For example, given the following code:

- ------------------------------------------------------------------------------
#include "vxWorks.h"
#include "semLib.h"

SEM_ID semId;

waitAndPrint ()
{
  extern SEM_ID semId;

  while (1) {
    semTake (semId, WAIT_FOREVER);
    printf ("got semId!\n");
  }
}
- ------------------------------------------------------------------------------

I compile under 5.0.2 using cc68k:

  cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \
	-I/usr1/vw/h -c  waitAndPrint.c

Then in the VxWorks shell:

- -> semId = semMCreate (1)		(note: 1 = SEM_Q_PRIORITY)
semId = 0x33fdcec: value = 54264916 = 0x33c0454
- -> ld < waitAndPrint.o
value = 0 = 0x0
- -> semTake (semId, -1)			(note: -1 = WAIT_FOREVER)
value = 0 = 0x0

By this point, the semId should be empty and anything that attempts to
take it should pend. So, I start up the waitAndPrint task:

- -> waitAndPrint
got semId!
got semId!
got semId!
got semId!
.
.
.
(Ctrl-C)

As you can see, waitAndPrint NEVER pends. It ALWAYS is able to take
the semaphore. If I replace "semMCreate (1)" with "semBCreate (1, 1)"
(i.e., use a regular binary semaphore), everything works as expected
(i.e., waitAndPrint pends). So, am I doing something wrong? Or is
there a bug here?

- -Terry

- -- 
_______________________________________________________________________________
Q:"What do you do with your life?"   | Terry Fong <terry@ptolemy.arc.nasa.gov>
A:"Nothing. But I do it terribly     | NASA Ames, M/S 269-3, Moffett Field, CA
   well!" - John Drake (Secret Agent)| (415) 604-6063 voice, 604-4036 fax

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

Newsgroups: comp.os.vxworks
Subject: re: comp.os.vxworks newsdigest
Date: Tue, 29 Sep 1992 21:41:30 GMT
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Organization: Abiogenesis 4 Less
Message-ID: <1992Sep29.214130.9257@wdl.loral.com>
References:  <9209291230.AA17923@aplexus.jhuapl.edu>
Reply-To: bard@cutter.ssd.loral.com
Sender: news@wdl.loral.com

prb@aplexus.jhuapl.edu (Paul R. Bade) writes:
# If there are no interrupts allowed, there will be no clock interrupts or 
# other interrupts to bring about a task switch. So the answer is,
# there is no prempting task.

I thought context switches could occur in the absence of clock
interrupts when a task is made ready by giving a semaphore.


- -- 
J H Woodyatt (a.k.a. Dr. Strychnine)
Space Systems/Loral

Help keep Las Vegas clean.  Eat your kill.

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

Newsgroups: comp.os.vxworks
Subject: Re: 167BUG Diagnostics and VxWorks
Date: Tue, 29 Sep 1992 23:48:24 GMT
From: pat@wrs.com (Patrick Boylan)
Organization: Wind River Systems, Alameda CA
Keywords: 167BUG, VxWorks, Diagnostics
Message-ID: <BvD64p.KtG@wrs.com>
References:  <1992Sep11.085304.19546@icf.hrb.com>
Reply-To: pat@wrs.com
Sender: news@wrs.com (News Manager)

In article <1992Sep11.085304.19546@icf.hrb.com>, r2c@icf.hrb.com (Robert J. Cole) writes:
|> 
|> 	I am attempting to write c diagnostic routines for the Motorola
|> 167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
|> board and on power-up, boots and passes control to vxWorks.  167BUG
|> exists in the first two PROMS and VxWorks in the second set.  VxWorks
|> boot ok in this configuration.  The intention is to run the user diagnostic 
|> routines on the 167 board which will make use of the resident Motorola 
|> diagnostic routines already in ROM, however this effort seems to be rife
|> with difficulty.	
|> 	
|> 	Has anyone done anything similar to what I am attempting and is
|> able to offer any advice?
|>  
|> Rob Cole.  r2c@icf.hrb.com

Rob,

I've done something similar for the Motorola MVME-147 and MVME-133.

The procedure involves booting MBUG, then upon successful MBUG boot,
MBUG searches for a boot block.  This boot block is used to jump start 
vxWorks.  Diagnostic results from MBUG were no more than pass/fail (if it 
failed it would not make it to vxWorks).  The results are printed out onto 
the console which was good enough for us.
Unfortunatley it was difficult to extract the individual diagnostics 
procedures from MBUG.  As far as I remember there was no jump table, nor was 
it well enough modularized to allow for this much execution granularity, 
even with the source code.

This is the procedure for using MBUG power up test procedures and
then vectoring to VxWorks.  These steps are specifically for the MVME147 and 
MVME133.  The MVME-167 might be different, however.

Install MBUG PROMS in bank0.

Reconfigure jumpers for the larger size EPROMS (see documentation for 
the target).

Build VxWorks with a ROM start address equal to the bank1 base address instead 
of bank0.  This is changed in the VxWorks file "vw/<target>/config.h".
Optionally poke the BOOT block (shown below) into these ROMs also 
using the editor of the PROM programmer.  I put it at address 0xffa1f800 on 
the MVME133XT.  Incidentally, another option is to put the bootblock direclty 
into non-volatile RAM.

Install the newly built VxWorks PROMS in bank1.

In order to cause MBUG to autovector to vxWorks.
MBUG completes self test, then checks the romboot flag (set from the MBUG
debugger), then if an address is specified when the romboot is turned
on, then this address is searched first for the boot block, if the bootblock 
is not found at this address, memory is searched for a bootblock in
NVRAM, RAM, or ROM .  Note that the boot blovk has to be on an 8KByte 
(0x2000) boundary).

The boot block can be inserted into non-volatile RAM.
This makes it easier for testing, and is easier and quicker to set up.
The MV133XT nonvolatile RAM is in the RTC which is located at 0xfffc0000
There are 2040 bytes available but the first 256 are used for the VxWorks boot
line.  Try putting the boot block at 0xfffc0300.  Take a look at the memory to 
make sure it is not being used by MBUG.

The MVME147 battery backed RAM should be at 0xfffe0000.

Using MBUG search through this novram for a block that is not being used.

Modify memory to insert the following data into the NV RAM:

Boot block data for the MVME133XT follows:
xxxx000:  424f 4f54 0000 0018  0000 0016 7678 576f   *BOOT........vxWo*
xxxx010:  726b 7320 d2b6 0000  4e56 0000 dffc 0000   *rks ....NV......*
xxxx020:  0000 48d7 0000 4ef9  fff2 0008 7000 4e5e   *..H...N.....p.N^*
xxxx030:  4e75 ffff 

Boot block data for the MVME147 follows:
xxxx000:  424f 4f54 0000 0018  0000 0016 7678 576f   *BOOT........vxWo*
xxxx010:  726b 7320 d2b6 0000  4e56 0000 dffc 0000   *rks ....NV......*
xxxx020:  0000 48d7 0000 4ef9  ffa0 0008 7000 4e5e   *..H...N.....p.N^*
xxxx030:  4e75 ffff 

The boot block for other processors is the same except the appropriate bank 1
execution address should be inserted into offset 28.  In the first case it 
is 0xfff20008 which is the MVME133XT ROM bank1 base address + 8.

The MVME147 bank1 execution address is 0xffa00008.
Then insert the checksum.  This is the last word of the boot block 
(at offset 32).  This is sum from the first word of the bootblock 
(offset 0) to the last word of the bootblock (0x30), but inverted so that 
the total checksum including this word should add up to zero.

Note: I can't remember whether it is 16 bit or 8 bit checksum.  Look at MBUG documentation or try it.

Configure romboot parameters in MBUG, using the rb command.

Turn on RB, assign the address where the boot block is located (saves time)
and rom boot on power up only (this allows you to use the RESET switch to
get back to MBUG).

Cycle power to test rom boot procedure.

If it takes a while and sits at a message saying searching for boot block,
then either the boot block has not been found, the address is wrong, or
the checksum does not match.  If the address is wrong and the boot block is 
located at an 8KByte (0x2000) boundary then it should be found eventually.  
It just may take a while.

When it is found note the address that it was found at and specify this 
address as the search start address to save some time.

Hope that helps.

Regards,
Patrick
- -- 
 Patrick Boylan, Consulting Engineer, FAE Asia/Pacific
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA  94501
 email: pat@wrs.com   tel: (510)748-4100   fax: (510)814-2010

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

Newsgroups: comp.os.vxworks
Subject: Re: Locking Interrupts..
Date: 29 Sep 92 23:46:37 GMT
From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Sep29164637@iphasew.iphasew.com>
References: <1992Sep29.041711.8216@bnr.ca>
Sender: hwajin@iphasew.com

>>>>> On 29 Sep 92 04:17:11 GMT, zafer@bcars474.UUCP (Zafer Elbi) said:

Zafer> int lock = intLock();
Zafer> ..
Zafer> ..
Zafer> ..--->  Task switch
Zafer> ..
Zafer> intUnlock();

Zafer> If there is a task switch occurs in the middle of the interrupt
Zafer> routine, can the preempting task unlock the interrupts again?


i suppose the answer is yes, since anyone can call intUnlock() if they
want to but whether it is desirable to do so is another matter.  the
interrupt mask information is part of the task context -- in m68k
world, status register contains this info which gets saved and
restored per context switch.  what you may or may not want to do is to
disable the task switch (taskLock()/taskUnlock()) depending on whether
you're really concerned about locking out interrupts and not being
context switched out (which could alter the interrupt masks depending
on which task gets switched in).

	~hwajin

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

Newsgroups: comp.os.vxworks
Subject: Re: bug with mutex semaphores in 5.0.2???
Date: 30 Sep 92 03:22:25 GMT
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Sep29202225@mondo.iphasew.com>
References: <1992Sep29.175143.20505@kronos.arc.nasa.gov>
Sender: hwajin@iphasew.com

>>>>> On 29 Sep 92 17:51:43 GMT, doctor@kronos.arc.nasa.gov (Terry Fong) said:
Terry> Nntp-Posting-Host: tardis-arclan.arc.nasa.gov


Terry> SEM_ID semId;
Terry> waitAndPrint ()
Terry> {
Terry>   extern SEM_ID semId;
Terry>   while (1) {
Terry>     semTake (semId, WAIT_FOREVER);
Terry>     printf ("got semId!\n");
Terry>   }
Terry> }

Terry> -> semId = semMCreate (1)		(note: 1 = SEM_Q_PRIORITY)
Terry> semId = 0x33fdcec: value = 54264916 = 0x33c0454
Terry> -> ld < waitAndPrint.o
Terry> value = 0 = 0x0
Terry> -> semTake (semId, -1)			(note: -1 = WAIT_FOREVER)
Terry> value = 0 = 0x0



interesting... it looks like when you compiled the above program, _semId 
gets defined as a common global symbol, not an unknown (external) symbol
(rightly so because you didn't declare it "extern") and
when you create a _semId from the shell it gets entered into
vxWorks symbol table, but subsequently loading the module
overwrites the symbol table entry for _semId.  you may verify
this by printing address of semId from the shell before and after
the loading.  [ i haven't tried this theory so i could be wrong,
but at least that's the way i remember the way vxWorks loader worked ].
the result is that you're not doing the semTake on _semId you
think you're using, and the new one probably contains 0 values
for the counter so semTake just returns, and returns, and....



	~hwajin

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

Newsgroups: comp.os.vxworks
Subject: Intertask communication mechanisms
Date: 30 Sep 92 05:29:36 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Sep30.052936.15428@afterlife.ncsc.mil>

I'm exploring my alternatives for intertask communication among tasks on
the same or other boards.

I need:
1.  High throughput.
2.  Ordered delivery.
3.  High reliability (but < 100% is potentially acceptable).
4.  Multicasting (one sender, several receivers).

Given that the only physical communications medium accessable to all of the
processors is the backplane, it would seem that my alternatives are:

1.  TCP on the backplane network.
2.  UDP on the backplane network.
3.  Some shared memory mechanism that I implement.
4.  Some other (unknown to me) mechanism.

My concerns are that:

1.  TCP throughput is too low.
2.  UDP throughput is too low and potentially too unreliable or unordered.
3.  I have to write my own mechanism.
4.  There is something better out there that I'm not aware of.

Any suggestions, comments, or questions are welcomed.  Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

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

Newsgroups: comp.os.vxworks
Subject: Re: Intertask communication mechanisms
Date: Wed, 30 Sep 1992 08:58:25 GMT
From: muts@fys.ruu.nl (Peter Mutsaers)
Organization: Rijks Universiteit Utrecht
Message-ID: <MUTS.92Sep30105823@ruunfs.fys.ruu.nl>
References: <1992Sep30.052936.15428@afterlife.ncsc.mil>
Sender: usenet@fys.ruu.nl (News Control)

On 30 Sep 92 05:29:36 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said:

  SMB> 1.  TCP throughput is too low.
  SMB> 2.  UDP throughput is too low and potentially too unreliable or unordered.
  SMB> 3.  I have to write my own mechanism.
  SMB> 4.  There is something better out there that I'm not aware of.

Why not simply use shared memory (assuming your VME board supports it)
and use TCP sockets to tell that data is available to the other board.
- --
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |        Quod licet bovi, non licet Jovi

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

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


From briggs@thalia.jpl.nasa.gov  Wed Sep 30 08:19:15 1992
From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
Date: Wed Sep 30 08:19:23 PDT 1992
Subject: Intertask Communications Mechanisms
Steve M. Burinsky writes, while looking for communications schemes:

>My concerns are that:

>1.  TCP throughput is too low.
>2.  UDP throughput is too low and potentially too unreliable or unordered.

But Steve gave no speed requirements.  There are a lot of advantages to using
TCP or UDP simply because they exist and are so flexible and transportable.
Before taking 1 & 2 above as givens, consider your real speed needs vs
development effort carefully.  It has been my experience that TCP speeds
(even over ethernet) are quite acceptible and if continuous transfer speed
requirements are really that high, the overall system design and component
load balancing must be done very carefully.

I wont offer any firm speed figures, but I seem to remember discussion in
here pointing out ethernet transfer speeds of 400K bytes (or bits? whats a
factor of 8 anyway?).  With care, backplane speeds should be substantially
higher, but again I offer no figures for lack of memory.

Remember, WRS firmly believes sockets, etc, can be slicked up to provide
sufficient transfer speed for most applications, while maintaining standards.
(I got this I believe from the last West Coast User Group Meeting.)

Peter Mutsaers adds:
>Why not simply use shared memory (assuming your VME board supports it)
>and use TCP sockets to tell that data is available to the other board.
I think that is an excellent compromise that avoids moving large amounts of
data across the sockets.

Clark Briggs
briggs@csi.jpl.nasa.gov


From dit@bach.jhuapl.edu  Wed Sep 30 10:43:41 1992
From: dit@bach.jhuapl.edu (Daryl I. Tewell)
Date: Wed Sep 30 10:43:49 PDT 1992
Subject: Re: bug with mutex semaphores

Regarding:

>    I seem to be having a problem with mutual exclusion semaphores: they
>  don't seem to work at all!!!! For example, given the following code:
>  
>  - ------------------------------------------------------------------------------#include "vxWorks.h"
>  #include "semLib.h"
>  
>  SEM_ID semId;
>  
>  waitAndPrint ()
>  {
>    extern SEM_ID semId;
>   
>    while (1) {
>      semTake (semId, WAIT_FOREVER);
>      printf ("got semId!\n");
>    }
>  }
>  - ------------------------------------------------------------------------------ 
>  I compile under 5.0.2 using cc68k:
>   
>    cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \
>          -I/usr1/vw/h -c  waitAndPrint.c
>   
>  Then in the VxWorks shell:
>   
>  - -> semId = semMCreate (1)             (note: 1 = SEM_Q_PRIORITY)
>  semId = 0x33fdcec: value = 54264916 = 0x33c0454
>  - -> ld < waitAndPrint.o
>  value = 0 = 0x0
>  - -> semTake (semId, -1)                        (note: -1 = WAIT_FOREVER)
>  value = 0 = 0x0
>   
>  By this point, the semId should be empty and anything that attempts to
>  take it should pend. So, I start up the waitAndPrint task:
>   
>  - -> waitAndPrint
>  got semId!
>  got semId!
>  got semId!
>  got semId!


   Here's my SWAG:

   When you assign semId before loading waitAndPrint.o, you are using an
instance of semId that already exists in the symbol table (presumably 
from a previous load).  If none had existed, you would have gotten the
message:

new symbol "semId" added to symbol table

The subsequent load of waitAndPrint adds another instance of semId to the
symbol table.  The first instance of semId is the one accessed at the shell
level (by virtue of its being the first instance found in the symbol table
by the shell), and the second (or last) instance is the one accessed by
waitAndPrint (because the access to semId by waitAndPrint need not be 
satisfied by a symbol table reference).  Since the last instance of semId
is never initialized, the semTake call in waitAndPrint returns ERROR
(invalid semaphore id), which you do not check for.

   You can use a little defensive programming to test this theory, i.e.
try checking for an ERROR return from semTake.  If this is indeed the
problem, then you must move your initial semCreate and semTake calls into
waitAndPrint, where they will necessarily access the same semId variable.



From mea@sparta.com  Wed Sep 30 12:24:04 1992
From: mea@sparta.com (Mike Anderson)
Date: Wed Sep 30 12:24:19 PDT 1992
Subject: Re: Intertask Communications Mechanisms
Greetings!

>  
> Steve M. Burinsky writes, while looking for communications schemes:
> 
> >My concerns are that:
> 
> >1.  TCP throughput is too low.
> >2.  UDP throughput is too low and potentially too unreliable or unordered.
> 
> But Steve gave no speed requirements.  There are a lot of advantages to using
> TCP or UDP simply because they exist and are so flexible and transportable.
> Before taking 1 & 2 above as givens, consider your real speed needs vs
> development effort carefully.  It has been my experience that TCP speeds
> (even over ethernet) are quite acceptible and if continuous transfer speed
> requirements are really that high, the overall system design and component
> load balancing must be done very carefully.
> 
> Remember, WRS firmly believes sockets, etc, can be slicked up to provide
> sufficient transfer speed for most applications, while maintaining standards.
> (I got this I believe from the last West Coast User Group Meeting.)
> 
> Peter Mutsaers adds:
> >Why not simply use shared memory (assuming your VME board supports it)
> >and use TCP sockets to tell that data is available to the other board.
> I think that is an excellent compromise that avoids moving large amounts of
> data across the sockets.

  I firmly agree with Clark and Peter.  We can sustain > 4 MBPs (about
520 KBytes/Sec) between two SPARC 1+ class machines via Ethernet using
our ARTSE(Tm) Datagram Protocol (reliable datagrams).  Providing that
there are no overly restrictive latency issues, sockets can be used
to signal across the bus (using the backplane driver) to waiting tasks
when memory blocks have been copied.  A faster mechanism would
be hardware interrupts or mailbox interrupts, but sockets can easily provide
a simple, software only solution to interprocessor comms.  I would tend to lean
towards reliable datagrams over stream sockets simply because there is
less CPU overhead associated with datagrams (i.e., your program doesn't
have to poll the socket to read *all* of the data... its either there
or its not).



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

Process Distribution/Control and Communications for Distributed Systems

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

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



From mea@sparta.com  Wed Sep 30 12:38:53 1992
From: mea@sparta.com (Mike Anderson)
Date: Wed Sep 30 12:39:39 PDT 1992
Subject: Re: bug with mutex semaphores
Greetings!

> Submitted-by dit@bach.jhuapl.edu  Wed Sep 30 10:43:41 1992
> Submitted-by: dit@bach.jhuapl.edu (Daryl I. Tewell)
>  
> 
> Regarding:
> 
> >    I seem to be having a problem with mutual exclusion semaphores: they
> >  don't seem to work at all!!!! For example, given the following code:
> >  
> 
>    Here's my SWAG:
> 
>    When you assign semId before loading waitAndPrint.o, you are using an
> instance of semId that already exists in the symbol table (presumably 
> from a previous load).  If none had existed, you would have gotten the
> message:
> 
> new symbol "semId" added to symbol table
> 
> The subsequent load of waitAndPrint adds another instance of semId to the
> symbol table.  The first instance of semId is the one accessed at the shell
> level (by virtue of its being the first instance found in the symbol table
> by the shell), and the second (or last) instance is the one accessed by
> waitAndPrint (because the access to semId by waitAndPrint need not be 
> satisfied by a symbol table reference).  Since the last instance of semId
> is never initialized, the semTake call in waitAndPrint returns ERROR
> (invalid semaphore id), which you do not check for.
> 

Daryl is quite correct on this point, but there is one other thing to
take into account.  When you created the semId from the shell, you 
used:
-> semId = semMCreate (1)

This put a symbol into the symbol table by the name of "semId".  However,
the gcc compiler generated a symbol "_semId" as a result of the  

SEM_ID semId;

declaration.  When referencing variable from the shell, the shell will first
try to find a variable that matches exactly what you typed in and if
that fails, it then prepends an "_" and looks again before telling you
it doesn't exist.  Therefore, after you've created the the semId from the
shell and then loaded the compiled code, you now have two variables in
the symbol table namely, "semId" and "_semId" and both of them are 
distinct.  Try to use lkup "semId" and you'll see what I mean.  The bottom
line is to be wary about creating variables from the shell that will be 
used by "C" code later.  Always use the "_" when creating such variables
to avoid confusion.  Also, if you're doing things from the shell, use 
the 

extern SEM_ID semId;

declaration and the

_semId = semMCreate(1)

shell command (create from the shell and THEN load the code) and the two
references will use the same entry from the symbol table.  I found out
about this while teaching real-time programming courses to my customers.
It was certainly mysterious the first time.

Good Luck,


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

Process Distribution/Control and Communications for Distributed Systems

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

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




From umphreys@acet02.amil.co.il  Wed Sep 30 17:38:08 1992
From: umphreys@acet02.amil.co.il (Ray Umphreys)
Date: Wed Sep 30 17:38:16 PDT 1992
Subject: re: Newsgroups: comp.os.vxworks

doctor@kronos.arc.nasa.gov (Terry Fong) writes:

>I seem to be having a problem with mutual exclusion semaphores: they
>don't seem to work at all!!!! For example, given the following code:
>
>- ------------------------------------------------------------------------------
>#include "vxWorks.h"
>#include "semLib.h"
>
>SEM_ID semId;
>
>waitAndPrint ()
>{
>  extern SEM_ID semId;
>
>  while (1) {
>    semTake (semId, WAIT_FOREVER);
>    printf ("got semId!\n");
>  }
>}
>- ------------------------------------------------------------------------------
>
>I compile under 5.0.2 using cc68k:
>
>  cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \
>	-I/usr1/vw/h -c  waitAndPrint.c
>
>Then in the VxWorks shell:
>
>- -> semId = semMCreate (1)		(note: 1 = SEM_Q_PRIORITY)
>semId = 0x33fdcec: value = 54264916 = 0x33c0454
>- -> ld < waitAndPrint.o
>value = 0 = 0x0
>- -> semTake (semId, -1)			(note: -1 = WAIT_FOREVER)
>value = 0 = 0x0
>
>By this point, the semId should be empty and anything that attempts to
>take it should pend. So, I start up the waitAndPrint task:
>
>- -> waitAndPrint
>got semId!
>got semId!
>got semId!
>got semId!
>.
>.
>.
>(Ctrl-C)
>
>As you can see, waitAndPrint NEVER pends. It ALWAYS is able to take
>the semaphore. If I replace "semMCreate (1)" with "semBCreate (1, 1)"
>(i.e., use a regular binary semaphore), everything works as expected
>(i.e., waitAndPrint pends). So, am I doing something wrong? Or is
>there a bug here?

No, there is no bug.  Mutual exclusion semaphores can be taken mutiple times
by the SAME task ( and should be given the same number of times ).  The take
will block only if it is executed from another task.  In your example both 
the semTake and the waitAndPrint are executed in the shell's task context.  
If you spawn waitAndPrint as a task, then it will block the way you want.



From thor@thor.atd.ucar.edu  Wed Sep 30 23:00:29 1992
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Wed Sep 30 23:00:37 PDT 1992
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
send index from unix
------------------------------------------------
VxWorks sources:

total 1637
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor        37126 Jun 12 13:31 ansilib01
-rw-r--r--  1 thor        18913 Jun 12 13:31 ansilib02
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6  1991 dhrystones01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor         9054 Jun 12 13:32 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
lrwxrwxrwx  1 root            6 Aug 14  1991 libx11 -> libX11
-rw-r--r--  1 thor        25077 Oct  9  1990 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor        41667 Feb  5  1992 ntpvx01
-rw-r--r--  1 thor        38524 Feb  5  1992 ntpvx02
-rw-r--r--  1 thor        41997 Feb  5  1992 ntpvx03
-rw-r--r--  1 thor        39218 Feb  5  1992 ntpvx04
-rw-r--r--  1 thor        39625 Feb  5  1992 ntpvx05
-rw-r--r--  1 thor        28741 Feb  5  1992 ntpvx06
-rw-r--r--  1 thor        32516 Feb  5  1992 ntpvx07
-rw-r--r--  1 thor        37119 Feb  5  1992 ntpvx08
-rw-r--r--  1 thor        41643 Feb  5  1992 ntpvx09
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14  1991 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14  1991 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1  1992 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        19912 Aug 27 13:52 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22  1991 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22  1991 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22  1991 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22  1991 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22  1991 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22  1991 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22  1991 vwcurses07
-rw-r--r--  1 thor         4636 Feb  4  1992 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16  1992 wdog_class
Unix sources:

total 82
-rw-r--r--  1 thor         1192 Mar 13  1990 index
drwxr-xr-x  2 thor          512 Mar 17  1992 patch
-r--r--r--  1 thor        11744 Apr 11  1989 shar.shar
-rw-r--r--  1 thor        19698 Nov 15  1989 vxtool
-rw-r--r--  1 thor        21934 Jan 31  1990 vxview
-rw-r--r--  1 thor        14151 Feb  9  1990 vxview.patch
-r--r--r--  1 thor         9869 Feb  1  1989 xc.shar
drwxr-xr-x  2 thor          512 Feb 11  1990 xdbx

Richard Neitzel thor@thor.atd.ucar.edu          Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjo'i med sitt shinn
303-497-2057                                    jagar borni inn.