HDTenEightyP/NetNews huggingface dataset:
From: hwajin@iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks
Subject: re: Request Basic VxWorks Info
Date: Mon, 13 Apr 92 11:30 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov



>>         3) What is the default size for a UDP socket (what is the maximum
>> length that can be used in sendto(), without first using setsockopt())?
>> Is this configurable by the user?
>
>4400 bytes, if I remember well. It was some time ago that I've handled that.
>Didnt look for a configuration parameter to change this. Used setsockopt
>on the socket before that socket was passed to RPC.


Global variables (not changed from 4.3 Tahoe network code):

udp_sendspace = 2048
udp_recvspace = 4 * (1024 + sizeof (struct sockaddr_in));

These are adjustable  via setsockopt() SO_SNDBUF and SO_RCVBUF on
per socket basis.

>> 
>>         4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
>> of RPC use setsockopt() to allow 8Kbyte UDP transmissions?
>
>No. I think I reported this to WRS, so maybe your version already will
>include a fix to this.
>NFS client code however has it's own RPC library, which apparently works
>just great with 8KB buffers.
>

NFS code uses setsockopt() to allow 8 K byte UDP transmissions over RPC.
NFS uses the same RPC library as everyone else.

Other RPC applications would control socket buffer size themselves --
this is the standard method  --  SunOS RPC library does the same.
From: els@icf.hrb.com (Eric L. Schott)
Newsgroups: comp.os.vxworks
Subject: Re: TCP Bandwith on VxWorks
Date: 6 Apr 92 16:00:45 GMT
Organization: HRB Systems, Inc.

In article <27550006@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>> Does anybody know what's the maximum data throughput achivable at the socket
>> (TCP) interface in VxWorks.  As this figure depends highly on the particular
>> hardware used, please specify the type and speed of CPU and network.
> 
> We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an
> Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this
> data rate there appears to be enough horsepower left to do other things.
> 

I have measured over 800 Kbytes/sec between an 040 SBC (VxWorks)
and a SPARCstation 2 (SunOS 4.1.1).  We used TCP sockets.
-- 

Eric L. Schott, HRB Systems, Inc.   814/238-4311
  Internet: ELS@ICF.HRB.COM
Newsgroups: comp.os.vxworks
From: paulg@tplrd.tpl.oz.au (Paul Gittings)
Subject: Differences between shell and sp task starts??
Originator: paulg@sydrd19
Organization: Telectronics Pacing Systems
Date: Fri, 10 Apr 92 06:32:07 GMT


This is a beginners question and I apologize in advance if I've wasted
bandwidth by asking for information which I should have been able to find 
in the manual (I did look, Honest).

Are there any major differences in a tasks environment when it is run
from the shell:

   -> main

to when it is spawned off using "sp" ?:

   -> sp main

The reason I ask is that we have just started to play around with vxworks
and I wrote a simple "socket" program which, prints a line of text sent to
it from the unix boxes (code is at the end of this article).  Well if I run 
the program from the shell everything works, if I use sp to spawn off the 
program the target locks up and has to be reset with the off/on button.  I 
traced through with vxgdb and for some reason it shows that accept() has 5 
arguments instead of the 3 I would expect.  The extra two are 0xeeeeeeee, 
which is what vxworks writes to the stack right?   Within accept() (or a 
function called by accept() ) a call is made to bcopy() with 0xeeeeeeee as 
the length of the copy, no wonder the target locks up :-).

We have vxWorks 5.0.2 and our target is National Instruments  VXIcpu030.

Cheers,
Paul Gittings
________________________________________T_e_l_e_c_t_r_o_n_i_c_s__|/\  __
                                                 Pacing Systems     \/
7 Sirius Rd, Lane Cove, NSW 2066, Australia
61-2-4136963 (voice), 61-2-4136868 (fax). 
Telex: AA 120576      ACSnet/AARnet/usent: paulg@tplrd.tpl.oz.au      
------------------------------------------------------------------------

/* Hacked sample program to try out sockets on vxi target */

#include "vxWorks.h"

#include "types.h"
#include "in.h"
#include "socket.h"

struct sockaddr_in cnnSocket;

main()
{
int sd,ns;
char buf[256];
int fromlen;


sd = socket(PF_INET,SOCK_STREAM,0);

if(sd < 0)
  {
  perror("socket");
  exit(1);
  }


bzero((char *) &cnnSocket, sizeof(struct sockaddr_in));
cnnSocket.sin_family = AF_INET;
cnnSocket.sin_addr.s_addr = htonl(INADDR_ANY);
cnnSocket.sin_port = 7000;

if(bind(sd, (struct sockaddr *) &cnnSocket, sizeof(struct sockaddr_in)) < 0)
  {
  perror("test->bind");
  exit(1);
  }

if(listen(sd,1) == ERROR)
  {
  perror("test->listen");
  exit(1);
  }

printf("Socket = %d\n", sd);

for(;;)
  {
  ns = accept(sd, &cnnSocket, &fromlen);
  if( ns == ERROR)
    {
    perror("test->accept");
    exit(1);
    }
  read(ns, buf, sizeof(buf));
  printf("server read '%s'\n", buf);
  close(ns);
  }
}



Newsgroups: comp.os.vxworks
From: jsnow@javelin.sim.es.com (John Snow)
Subject: UNIX compatible rsh for VxWorks?
Keywords: rsh vxworks
Organization: Evans & Sutherland Computer Corporation
Date: Thu, 16 Apr 1992 16:25:32 GMT

Now that we have a UNIX compatible rsh deamon for VxWorks
that allows UNIX boxes to rsh to a VxWorks node, does
anyone have a UNIX compatible rsh command that will
run under VxWorks? We would like to be able to rsh from
VxWorks back to UNIX or from VxWorks to VxWorks.

Doesn't seem like it would be to difficult to write rsh
for VxWorks since VxWorks already supports rcmd. But,
not being one to reinvent the wheel, I was wondering if
someone has already done it.

Please, no responses about VxRsh - it's not UNIX compatible.

-- 
-----------------------------------------------------------------------------
John F. Snow                         INET:           jsnow@javelin.sim.es.com
Evans & Sutherland Computer Corp.    
Salt Lake City, Utah                 America Online: JohnSnow  GEnie: J.SNOW2
From: mkb@frc.ri.cmu.edu (Mike Blackwell)
Newsgroups: comp.os.vxworks
Subject: Stethoscope
Date: 15 Apr 92 19:19:28 GMT
Reply-To: mkb@cs.cmu.edu
Organization: Field Robotics Center, CMU

Could someone please send me a contact (email or phone) for the
Stethoscope product? I think it will perfectly solve a problem I'm
having. Thanks...		-mike-
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.os.vxworks
Subject: Re:  Defining Embedded Systems
Date: 15 Apr 92 22:31:47 GMT
Article-I.D.: visicom.173
Organization: VisiCom Laboratories, Inc., San Diego, California

Bob Crispen writes:


>In the flight simulation business, there are people who need to be concerned
>with exactly the same kinds of things that concern people who design black
>boxes, controllers, and so on.  They need to know about interrupts, hard time
>deadlines, scheduling, resource locking, device control, and so on.

These aspects make flight simulators real-time systems, not necessarily
embedded systems.  A flight simulator can also be considered an embedded 
system, the characteristics that determine this being that the computer(s) 
is embedded inside of controls, gauges, and other sundry devices not 
normally part of a general purpose computer.

There are real-time systems, and there are embedded systems, and then there
are real-time embedded systems.  'Real-time' and 'embedded' are often
used interchangeably, but to me they are quite distinct, the former
implying a set of temporal requirements, and the latter implying a set
of hardware/sensor interaction requirements.  I don't know how often I've 
seen something advertised as being a real-time tool, when really it's 
just an embedded systems tool.

>(2) Embedded systems are systems that are actually embedded in something.

This I like better.

>I *love* religious discussions like this, and it really just depends on
>where you start drawing your boundaries.  I prefer to start at the extremes
>(to find out if they really are extremes) rather than at the middle.

Good point.   Can anyone think of a system that directly interacts with 
sensors, gauges, or other non-general-purpose hardware that we would NOT 
consider to be an embedded system?   There may be a kernal of a definition
here... (no pun intended) unless of course one of Bob Crispen's extreme's
blows this out of the water ;-)

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
			+1 619 457 2111    FAX +1 619 457 0888
From: pat@wrs.com (Patrick Boylan)
Newsgroups: comp.os.vxworks
Subject: Re: rlogin to a target clobbers remote user name
Date: 15 Apr 92 06:34:34 GMT
Organization: Wind River Systems, Inc.

hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:


>Has anyone else observed this? 

>After a completed rlogin session to a vxWorks target, whoami on that
>target's console returns a null string. This happens even if I did
>nothing but rlogin and logout.

As Hwajin mentioned this problem surfaced when login security was introduced for 5.0.
The original user and password before a secure login is restored from originalUser and 
originalPasswd.  These were not stored.

The problem has been fixed for the next release and the patch for 5.0 and 5.0.2 is
as follows:

-> remCurIdGet (&originalUser, &originalPasswd);

Patrick
--
 Patrick Boylan, Consulting Engineer, FAE Asia/Pacific
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA 94501
 pat@wrs.com	(510)748-4100
Newsgroups: comp.os.vxworks
From: fester@etorofu.island.COM ()
Subject: Heurikon for sale
Originator: fester@etorofu
Organization: Island Graphics, Marin County, California
 
Date: Mon, 13 Apr 1992 20:13:25 GMT

$1200 OBO

Mike Fester	day 	(415) 491-1000 x190
		evening	(415) 750-9220

or email me at fester@island.com


-- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."
From: rg@msel.unh.edu (Roger Gonzalez)
Subject: accepted method of ld'ing many .o files
Organization: UNH Marine Systems Engineering Lab
Distribution: comp
Date: Fri, 17 Apr 1992 13:14:13 GMT


Now that I'm getting moving beyond one or two object file test programs into a
big project, I'm curious how people handle the need to load large numbers of
object files.

I was thinking about having some C code generated through shell scripts and
the makefile that would automatically produce some code like this:

char *app-name[] = {
	"/path/objfile1.o",
	"/path/objfile2.o",
	"/path/objfile3.o",
	"/path/objfile4.o",
	"/path/objfileN.o",
	0
};

boot(app, variable args)
{
	foreach string in app, do a ld
	then invoke the first one with the variable args.
}

Am I missing something easier?

-Roger


--
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)
From: susanna@tomato.lbl.gov (Susanna Jacobson)
Newsgroups: comp.os.vxworks
Subject: SCSI DMA from offboard VME mem
Date: Fri, 10 Apr 92 14:35:21 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

In hopes of saving hours of search through catalogs and calls to sales
offices, I ask you, the vxWorks community, for pointers to VME boards
that

	1.  Do DMA to SCSI from off-board memory.

	2.  Run vxWorks or run with vxWorks software.

And of course if you have actually used used such a board, I'd like to
hear about your experience.

(I guess I wouldn't object to an SBC with DMA to SCSI from its onboard
8MB of VSB-port data memory, in excess of any system memory.  However I
am also guessing that boards fitting that description are less likely
to exist than what I have specified above.)

The current system setup includes a VME crate, with an MVME147 running
a "Taper" process among others, that receives data via VSB from other
VME crates and then writes to tape via the 147's SCSI.  (MVME165's in
the other VME crates write directly into dual-ported VME/VSB memory
cards in the Taper crate.)  Since the 147 does DMA to SCSI only from
on-board memory, data must first be transferred from the dual-ported
memory to the 147 onboard memory.  (The 147 is running Version 5.0.1 of
VxWorks; the 165 Version 5.0.2.)  The goal of this query is to learn
whether we can add a board to the VME crate that will eliminate that
intermediate mem-to-mem copy.

Any information welcome.  
========================================================================
Susanna Jacobson			MS 46A-1123
SRJacobson@LBL.Gov			Lawrence Berkeley Laboratory
VOICE:  (510) 486-7801			1 Cyclotron Road
FAX:    (510) 486-5936			Berkeley, CA 94720
========================================================================
From: hwajin@iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks
Subject: re: Differences between shell and sp task starts??
Date: Mon, 13 Apr 92 11:44 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


>Well, first there was a syntax error in the code:
>
>sd = socket(PF_INET,SOCK_STREAM,0);
>
>should have been
>
>sd = socket(AF_INET,SOCK_STREAM,0);

PF_INET == AF_INET.  This isn't syntax error, it is now a preferred
way to specify protocol families. [ there is a reason for this. ]

From the original program,

>  ns = accept(sd, &cnnSocket, &fromlen);

Notice that fromlen is never initialized to any value.  The last
argument to accept() is a value/result.  You should set it to
something like "sizeof (struct sockaddr_in)".  [ there is a reason
for this. ]

*hwajin
From: leonid@amil.co.il (Leonid Rosenboim)
Newsgroups: comp.os.vxworks
Subject: re: Vx Exploder Digest
Date: Sun, 12 Apr 92 17:08:29 IDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


> Date: 9 Apr 92 15:09:54 GMT
> From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
> Organization: Brookhaven National Laboratory, Upton, NY 11973
> 
> ..... 
>         2) What is the maximum number of (simultaneously active) sockets
> in a VxWorks system? Is this configurable by the user?

Configurable, actually as maximum number of file descriptors.

> 
>         3) What is the default size for a UDP socket (what is the maximum
> length that can be used in sendto(), without first using setsockopt())?
> Is this configurable by the user?

4400 bytes, if I remember well. It was some time ago that I've handled that.
Didnt look for a configuration parameter to change this. Used setsockopt
on the socket before that socket was passed to RPC.
> 
>         4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
> of RPC use setsockopt() to allow 8Kbyte UDP transmissions?

No. I think I reported this to WRS, so maybe your version already will
include a fix to this.
NFS client code however has it's own RPC library, which apparently works
just great with 8KB buffers.

> ....
> 
>         6) Does VxWorks provide some mechanism for allowing a task to
> 'clean up' I/O objects when it is deleted? Specifically, if a task
> creates a socket and binds to an address, but then the task is deleted,
> will that socket (and address) continue to be in use by 'the system',
> even though the task has been deleted (effectively 'orphaned')?

By default, the socket will not be deleted, simply because the application
could have passed the FD on to some other task. If you want to do such
a cleaup, you can use the taskDeleteHookCreate() and program whatever you
want to be done when the task is deleted.

>         I would be content with the answer that VxWorks has a 'signal'
> interface, allowing one to install a 'signal' handler which can do the
> cleanup. Although this would require me to *only* delete tasks with
> signals, this is acceptable. The VRTX32 solution of 'task delete hooks'
> is ideal, because there is no restriction on *how* the task was deleted.

Vx's solution is as ideal then.

> 
>         7) Is there any word on Xclient in the near future?
Sure there is. It's a whole product from WRS ! Plus there is one from 3rd
party too, and an Xserver from 3rd party if you fancy.

> 
>         8) Does VxWorks provide 'C' function prototypes for it's system calls?
> 
Yes, and they're supposed to come out right with the current release.

> Thanx in advance - Larry

You're welcome.
---------------------------------------------------------------------
| Leonid Rosenboim                                                  |
| Freelance Consultant                   P.O.Box 13652, Azur ISRAEL |
| Computer Systems and Networks          Phone: +972-3-5561-661     |
---------------------------------------------------------------------
From: bard@cutter.ssd.loral.com (James Woodyatt)
Newsgroups: comp.os.vxworks
Subject: Exabyte 8200/8500 driver wanted for VxWorks 5.0.2
Date: 10 Apr 92 12:43:53 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Does such a beast exist? We've got a bunch of 8200's now and we're
replacing them with 8500's. I've got a driver that came from
I'm-not-sure-where that we use under VxWorks 4.0.2 but it makes some
faulty assumptions about the filesystem for 5.0 and the SCSI interface
is otherworldly.

Before I go blindly into the task of porting this monster, is there any
chance of finding a driver already built to go with the 5.0 scsiLib?
I've heard rumors that such a creature exists, and that someone on the
net knows where to find it. Is this true?

Please point me in the right direction.

--
 __________________________________________________________________
|
| James Woodyatt                 VOICE:  (415) 852-5429
| Space Systems/Loral (M/S G87)  FAX:    (415) 852-6286
| 3825 Fabian Way                E-MAIL: bard@cutter.ssd.loral.com
| Palo Alto, CA  9430
|
From: mkb@frc.ri.cmu.edu (Mike Blackwell)
Newsgroups: comp.os.vxworks
Subject: Stethoscope found
Date: 16 Apr 92 14:09:44 GMT
Reply-To: mkb@frc.ri.cmu.edu
Organization: Field Robotics Center, CMU

I now have the contacts for Stethoscope. Sheesh, I must be the only person in the
world who didn't know...		cheers, -m-
Newsgroups: comp.os.vxworks
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Subject: Request Basic VxWorks Info
Organization: Brookhaven National Laboratory, Upton, NY 11973
Date: Thu, 9 Apr 1992 15:09:54 GMT

        I wonder if some experienced VxWorks users could answer
some questions for a non-user (me :-), so that I can make a rational
decision about using it in an upcoming project (where network support
is crucial) ?

        1) Has anyone used VxWorks NFS work with NFS servers from either :
HP/Apollo NFS (Domain 10.3.5) or SGI (IRIX 4.0)? What other NFS servers have
you used?

        2) What is the maximum number of (simultaneously active) sockets
in a VxWorks system? Is this configurable by the user?

        3) What is the default size for a UDP socket (what is the maximum
length that can be used in sendto(), without first using setsockopt())?
Is this configurable by the user?

        4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
of RPC use setsockopt() to allow 8Kbyte UDP transmissions?

        5) Does VxWorks support parts of XDR which are *not* needed for
RPC (specifically xdr_stdio_create())?

        6) Does VxWorks provide some mechanism for allowing a task to
'clean up' I/O objects when it is deleted? Specifically, if a task
creates a socket and binds to an address, but then the task is deleted,
will that socket (and address) continue to be in use by 'the system',
even though the task has been deleted (effectively 'orphaned')?
        I would be content with the answer that VxWorks has a 'signal'
interface, allowing one to install a 'signal' handler which can do the
cleanup. Although this would require me to *only* delete tasks with
signals, this is acceptable. The VRTX32 solution of 'task delete hooks'
is ideal, because there is no restriction on *how* the task was deleted.

        7) Is there any word on Xclient in the near future?

        8) Does VxWorks provide 'C' function prototypes for it's system calls?

Thanx in advance - Larry



-- 



     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_
From: lampman@moose.heurikon.com (Ray Lampman)
Newsgroups: comp.os.vxworks
Subject: Re: heurikon for sale
Date: 15 Apr 92 01:23:32 GMT
Reply-To: Ray.Lampman@Heurikon.Com (Ray Lampman)
Followup-To: comp.os.vxworks
Organization: Heurikon Corporation, Madison, WI

In article <1992Apr10.173505.3673@island.COM> fester@etorofu.island.COM writes:
#
# Heurikon  HK68 and MLZ-91/21 Microcomputer. Includes all manuals and
# documentation. Still in the box.
#
# $1200 OBO
#
# Mike Fester	day 	(415) 491-1000 x190
# 		evening	(415) 750-9220
#
# or email me at fester@island.com

I wasn't aware that the MLZ-91 has had VxWorks ported to it.  Can
Heurikon  get  a  copy?  :-)  Maybe  this  article  would be more
appropriate in one of the "forsale" groups. Here's a list:

comp.forsale.computers
misc.computers.forsale
misc.forsale
misc.forsale.computers

Ray.Lampman
VxWorks Coordinator
Heurikon Corporation
--
Ray.Lampman@Heurikon.Com  ,^-_    "I say, what it occurs to me to
8310 Excelsior Drive      L   `;  say, when I think I hear people
Madison, WI 53717, USA    \ . J   say things, more I can not say"
+1 608 828 3431            L__]   - the man in the shack, D Adams
From: harvey@yuba.wrs.com (Harvey Wong)
Newsgroups: comp.os.vxworks
Subject: Stethescope
Date: Thu, 16 Apr 92 11:58:26 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Dear VxWorks Users,

Wind River Systems is now a distributor for Real-Time Innovation's
Stethoscope product.  WRS will be shipping and supporting this unique
data collection and graphical monitoring tool by the end of April.

Stethoscope allows developers to choose any program variable and
watch them change in real-time.  This data can also be saved for
later analysis.  Stethoscope also includes a dynamic execution profiler
which enables developers to analyze the execution flow of their
aplication and how the CPU is being used.

Please feel free to call WRS directly at 510/748-4100 for more information.

Sincerely,

Harvey Wong
Wind River Systems, Inc.
From: Bob Herlien <hebo@mbari.org>
Newsgroups: comp.os.vxworks
Subject: re: Embedded Systems
Date: Thu, 16 Apr 92 7:50:34 PST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

> From: rlk@VisiCom.COM (Bob Kitzberger)
>
> Good point.   Can anyone think of a system that directly interacts with 
> sensors, gauges, or other non-general-purpose hardware that we would NOT 
> consider to be an embedded system?   There may be a kernal of a definition
> here... (no pun intended) unless of course one of Bob Crispen's extreme's
> blows this out of the water ;-)
> 
> 	.Bob.
> 
In the early '70s (around '70-'72) I did some work on the original PLATO
system at the University of Illinois.  PLATO was one of the early computer-
aided-instruction machines.  At the time, it was being migrated from a 
CDC 1600 to a CDC 6600 (both general-purpose, although now ancient, machines).

I was working with (taking a special projects class in) the EE department.  
We had a "typical" EE lab setup:  oscilloscope, function generator, oscillator,
etc., all wired through sensors & guages so that the students' configuration
could be sensed by the main CPU.  We wrote CAI software to "teach" EE lab.  
This software ran in a typical (for the day) timesharing type environment.
This was not an embedded system -- we had no embedded CPU's (this was before
the age of micros.  Oops, my age is showing :-).

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