From bemills@sandia.gov  Fri Nov  1 08:25:09 1996
From: bemills@sandia.gov (Barbara Mills)
Date: Fri Nov  1 08:25:12 PST 1996
Subject: anyone at Sandia have an MV167 to lend?
Hi.  I'm in need of an MV167 for about a month.  Does anyone
at Sandia National Labs have one I could use?  Thanks in
advance.
_______________________________________________________
|                                                     |
| Barbara E. Mills          Voice (505) 845-9826      |
| bemills@sandia.gov        Fax   (505) 844-2925      |
|_____________________________________________________|
From tothl@ascs.aro.allied.com  Fri Nov  1 09:39:37 1996
From: tothl@ascs.aro.allied.com (Lou Toth)
Date: Fri Nov  1 09:39:55 PST 1996
Subject: unsubscribe
unsubscribe
From intrepid!minidds@uunet.uu.net  Fri Nov  1 10:30:02 1996
From: intrepid!minidds@uunet.uu.net (Lee Kappel)
Date: Fri Nov  1 10:30:05 PST 1996
Subject: PowerPC Interrupt Levels
We're using Tornado/VxWorks 5.3 with an mv1604 board support
package.  What are the valid levels for intLockLevelSet?
Also, what is the format of the key returned by intLock?
We are seeing intLock return 0xB030 or 0x9030
Kyle
hoyt@eci-cec.com
minidds@eci-cec.com
From daemon@csg.lbl.gov  Sat Nov  2 04:00:32 1996
From: daemon@csg.lbl.gov
Date: Sat Nov  2 04:00:36 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Nov  2 04:00:25 PST 1996
        Subject: Re: Tornado on WinNT
        Subject: Re: Kbhit
        Subject: PPP and Tornado
        Subject: PPP and VxWorks
        Subject: Using Tornado with emacs
        Subject: Re: Using Tornado with emacs
        Subject: odd behaviour of slow disk drive...
        Subject: Re: Video driver on VxWorks
        Subject: Are you happy with Vx Works and Wind River
        Subject: Re: Routing question
        Subject: Clarification Of Question - Re: Non Terminating TCP/IP Sockets
        Subject: Seeking XDR functions/types
        Subject: Re: Seeking XDR functions/types
        Subject: BSP for Arnewsh SBC360 board
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Tornado on WinNT
Date: Thu, 31 Oct 1996 10:28:48 -0800
From: Frank Weissig <faw@teleport.com>
Organization: Teleport - Portland's Public Access (503) 220-1016
Message-ID: <3278EFE0.3999@teleport.com>
References: <557mjj$bti@cobra.Minn.Net>
Reply-To: faw@teleport.com
Dave Hansen wrote:
>
> Apologies if this appears multiple times.  My news server has been
> "throttling" and I don't think my previous attempts have made it
> out...
>
> We will be beginning an evaluation of VxWorks and Tornado for a new
> product we're starting work on.  My new computer will arrive with NT
> 4.0 installed.  The Tornado docs specify NT 3.51, and previous
> messages in this group have indicated that Wind River is less than
> completely supportive of 4.0.  So I have a 3.51 CD and the latest
> service pack downloaded, and I'm all ready to revert once the system
> arrives.
You shouldn't have to do that.  I've been using Tornado 1.0 on 4.0 for a
couple of months and there are no show-stoppers, just some annoyances.
And for all I know, these same problems may apear under 3.51 - I don't
have time to do regression testing for WRS.  The three most annoying
problems:
1) When you are debugging and the debugged process is running, the
target server and debugger processes on the NT side suck up 100% of the
CPU time.  This makes performance sluggish, to say the least!
2) The GUI display of local variables is buggy.  In particular, display
of pointers to structures doesn't always (if ever) seem to work.
However, the character-mode gdb window works fine, so you can get around
it.
3) If you have files open in Tornado's pathetic little editor, you get
frequent spurious message boxes telling you that the file contents have
been changed.
>
> But the sales guy and the AE from Wind River say this is no longer
> true (and in fact never was).
Here's a quote from Gary Percy at WRS tech support from August 20:
>>I left something out of my email yesterday. I should have stated
>>that the 4.0 version of NT had not yet been validated by WRS.
>>We have validated 3.51.
>>
>>You are right that 4.0 is now the current version of NT, but it
>>is still the case that it has yet to be validated by WRS.
That's the last I've ever heard on the problems I submitted. I'll let
you decide how that fits with what the sales guy and AE told you...
I wouldn't use lack of tech support as a reason for not going to NT
4.0.  So far, I've found WRS tech support to be nearly worthless
anyway.  The scenario on everything I've submitted has been:
1) Send problem descrption to WRS.
2) Get response asking for small test case.
3) Spend time writing test case, send it to WRS.
4) Never hear anything again.
> Their only caution was to ensure the
> FTP server is installed on the Tornado host (this is not the default
> for 4.0).  So how about it?  Has anyone recently been turned away by
> Wind River support for having 4.0 installed rather than 3.51?
>
> Also, are there any other gems of wisdom regarding Tornado on NT out
> there?  I know UN*X would probably be a better option for various
> reasons, but that option is not available to me. (at least I don't
> have to try Win95 :)
>
> Thanks in advance,
>
>                                         -=Dave
>
> I can barely speak for myself, so I surely can't speak for B-Tree
>
> |==================================================================|
> | Dave Hansen           |       B-Tree Verification Systems, Inc.  |
> | dhansen@btree.com     |       5929 Baker Rd, Suite 475           |
> | (VOICE) 612-930-4112  |       Minnetonka, MN  55345-5955         |
> | (FAX)   612-936-2187  |                                          |
> |==================================================================|
- --
Frank Weissig
Senior Staff Engineer
STEP Technology, Inc.
frank@steptech.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Kbhit
Date: Fri, 01 Nov 1996 09:24:28 -0800
From: Graham Waters <waters@triumf.ca>
Organization: TRIUMF
Message-ID: <327A324C.318@triumf.ca>
References: <32769BCC.23FB72DA@leland.stanford.edu>
eric olsen wrote:
>
> Is there a kbhit function?
> If so, where?
>
> thanks,
>
>
I wish there was I usually do something like this :
/*
 kbhit:
	returns TRUE if character waiting
	This functions suspends the shell and sets the console in RAW mode.
	The shell is restored when the keyboard is hit.
*/
int kbhit(int ioFd, char *byte)
{
	int old, options, rawmode, shellId;
	if (!rawmode)	/* do this on first call */
	{
	  options = ioctl(ioFd,FIOGETOPTIONS,0)	/* current console */
	  old = options;
	  options = options & ~OPT_LINE & ~OPT_ECHO;
	  ioctl(ioFd, FIOSETOPTIONS, options)		/* unbuffered mode */
	  shellId = taskNameToId("tShell");
	  taskSusp[end(shellId);	/* prevent the shell intercepting
characters *?
	  rawmode = 1;
          return(0);
	}
	else
	{
	  status = ioctl(ioFd, FIOREAD,(int)&BytesUnread);	/* key hit?
*/
	  if (nBytesUnread > 0)
	  {
		read(ioFd,byte,nBytesUnread);		/* read the key just
hit */
		status = ioctl(ioFd,FIOFLUSH,0);
		ioctl (ioFd, FIOSETOPTIONS, old;	/* restore line mode
*/
		rawmode = 0;
		taskResume(shellId);
		return(1)			/* return 1 if key hit */
	  }
	  else
		return(0);			/* return 0 if no key hit */
	}
}
Good luck
Graham.
+-----------------------------------------------------------------------+
| Graham Waters, Control System Eng          Internet: waters@triumf.ca |
| TRIUMF --- University of British Columbia,	phone: (604)-222-1047   |
| Vancouver, BC, Canada                           Fax: (604)-222-7307   |
|                                                http://www.triumf.ca   |
+-----------------------------------------------------------------------+
---------------------------
Newsgroups: comp.os.vxworks
Subject: PPP and Tornado
Date: Thu, 31 Oct 1996 14:20:44 +0100
From: Rune Okstad <Rune.Okstad@microdesign.no>
Organization: Micro Design AS
Message-ID: <3278A7AB.44E1@microdesign.no>
Reply-To: Rune.Okstad@microdesign.no
Hi!
We have connected two computers via an RS485 serial line and want to use
TCP/IP. With AIX on one side and VxWorks on the other, what are my
options for an underlying protocol, and where do I get a suitable
implementation of it. Can I use PPP?
I appreciate all answers.
Thanks,
Rune Okstad.
---------------------------
Newsgroups: comp.os.vxworks
Subject: PPP and VxWorks
Date: Thu, 31 Oct 1996 14:29:38 +0100
From: Rune Okstad <Rune.Okstad@microdesign.no>
Organization: Micro Design AS
Message-ID: <3278A9C2.3843@microdesign.no>
Reply-To: Rune.Okstad@microdesign.no
Hi!
We have connected two computers via an RS485 serial line and want to use
TCP/IP. With AIX on one side and VxWorks on the other, what are my
options for an underlying protocol, and where do I get a suitable
implementation of it. Can I use PPP?
I appreciate all answers.
Thanks,
Rune Okstad.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Using Tornado with emacs
Date: Thu, 31 Oct 96 14:31:52 GMT
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <55b98o$jsr@idiom.com>
Reply-To: chaos@idiom.com
Some of you have sent email asking me how to use emacs as IDE instead of
the default Tornado GUI/IDE for development.   All you have to do is
set up environment variables correctly.  Here's an example of a batch
file that will set up to use Tornado compilers in the DOS shell:
- ---------------------------
set CPU=CPU32
set TOOL=gnu
set WIND_HOST_TYPE=x86-win32
set WIND_BASE=c:\Tornado
PATH C:\Tornado\host\x86-win32\lib\gcc-lib\m68k-wrs-vxworks\2.6-95q2;c:\tornado\host\x86-win32\bin;%PATH%
- -----------------------------
Furthermore, you can also edit, compile, etc. inside GNU emacs (ported
to NT), if you set up things correctly.  Here's my $HOME/_emacs profile:
- -------------------------------
;;
;;
(c-set-style "bsd")
(setq c-basic-offset 8)
(setq-default c-basic-offset 8)
(require 'hilit19)
;(global-set-key [f3] 'isearch-forward)
(setq-default win32-pass-optional-keys-to-system t)
;(setq-default isearch-wrapped t)
(setenv "CPU" "CPU32")
(setenv "TOOL" "gnu")
(setenv "WIND_HOST_TYPE" "x86-win32")
(setenv "BOARD" "vina")
(setenv "PATH" "C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2;c:\\tornado\\host\\x86-win32\\bin;C:\\WINNT35\\system32;C:\\WINNT35;c:\\bin;c:\\brief;c:\\emacs\\emacs-19.33\\bin;c:\\tornado\\host\\x86-win32\\bin;c:\\bat;c:\\usr\\bin")
(setq-default auto-save-default nil)
(setq my-path '("C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2" "c:\\tornado\\host\\x86-win32\\bin" "c:\\bat" ))
(setq-default exec-path (append my-path exec-path))
;(set-background-color "black")
;(set-foreground-color "grey")
;(set-cursor-color "green")
;(set-default-font   "-*-Courier New-normal-r-*-*-16-120-*-*-c-*-*-ansi-")
(set-default-font  "-*-Courier-normal-r-*-*-16-120-*-*-c-*-*-ansi-")
;(set-default-font   "-*-Lucida Console-bold-r-*-*-13-97-*-*-c-*-*-ansi-")
(global-unset-key "\C-x\C-q")
(global-set-key "\C-x\C-q" 'toggle-read-only)
;(global-unset-key "\C-x\C-b")
;(global-set-key "\C-x\C-b" 'electric-buffer-list)
(global-unset-key "\C-x\C-e")
(global-set-key "\C-x\C-e" 'compile)
(global-unset-key "\M-g")
(global-set-key "\M-g" 'goto-line)
;(enable-flow-control)
(setenv "RCSPATH" "%d/rcs/%f")
(setenv "CVSROOT" "z:/")
(setenv "TZ" "PST8PDT")
(setenv "LOGNAME" "hjb")
(setenv "USER" "hjb")
(setq-default explicit-shell-file-name "c:\\4dos\\4nt.exe")
(setq-default shell-file-name "c:\\4dos\\4nt.exe")
(display-time)
(setq-default visible-bell t)
;(require 'cc-compat)
;; (setq gdb-command-name "gdbm68k")
;
; initial geometry
;
(set-frame-height frame-initial-frame 42 )
(setq initial-frame-alist '((top . 1) (left . 120) (width . 80) (height . 42)))
- --------------------------------------------
As far as the gdb goes, you can run gdbm68k either from command line
or instead NT gnu emacs DOS shell window.  You have to be running
a target server, and specify "target wtx targetservername".
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using Tornado with emacs
Date: Thu, 31 Oct 96 14:40:40 GMT
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <55b9p8$jsr@idiom.com>
References: <55b98o$jsr@idiom.com>
My news reader's editor inserted some bogus line-breaks into my last
article which makes the examples hard to use.  I'll attempt here to
fix it... (such are joys of using primitive OS'es and applications
on PeeCee's)...
example 1 (a batch file)
- ----------------------------------------------
set CPU=CPU32
set TOOL=gnu
set WIND_HOST_TYPE=x86-win32
set WIND_BASE=c:\Tornado
PATH C:\Tornado\host\x86-win32\lib\gcc-lib\m68k-wrs-vxworks\2.6-95q2;c:\tornado\host\x86-win32\bin;%PATH%
- ------------------------------------------------
example 2 (emacs profile)
- ---------------------------------------------------
;;
;;
(c-set-style "bsd")
(setq c-basic-offset 8)
(setq-default c-basic-offset 8)
(require 'hilit19)
;(global-set-key [f3] 'isearch-forward)
(setq-default win32-pass-optional-keys-to-system t)
;(setq-default isearch-wrapped t)
(setenv "CPU" "CPU32")
(setenv "TOOL" "gnu")
(setenv "WIND_HOST_TYPE" "x86-win32")
(setenv "BOARD" "vina")
(setenv "PATH" "C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2;c:\\tornado\\host\\x86-win32\\bin;C:\\WINNT35\\system32;C:\\WINNT35;c:\\bin;c:\\brief;c:\\emacs\\emacs-19.33\\bin;c:\\tornado\\host\\x86-win32\\bin;c:\\bat;c:\\usr\\bin")
(setq-default auto-save-default nil)
(setq my-path '("C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2" "c:\\tornado\\host\\x86-win32\\bin" "c:\\bat" ))
(setq-default exec-path (append my-path exec-path))
;(set-background-color "black")
;(set-foreground-color "grey")
;(set-cursor-color "green")
;(set-default-font   "-*-Courier New-normal-r-*-*-16-120-*-*-c-*-*-ansi-")
(set-default-font  "-*-Courier-normal-r-*-*-16-120-*-*-c-*-*-ansi-")
;(set-default-font   "-*-Lucida Console-bold-r-*-*-13-97-*-*-c-*-*-ansi-")
(global-unset-key "\C-x\C-q")
(global-set-key "\C-x\C-q" 'toggle-read-only)
;(global-unset-key "\C-x\C-b")
;(global-set-key "\C-x\C-b" 'electric-buffer-list)
(global-unset-key "\C-x\C-e")
(global-set-key "\C-x\C-e" 'compile)
(global-unset-key "\M-g")
(global-set-key "\M-g" 'goto-line)
;(enable-flow-control)
(setenv "RCSPATH" "%d/rcs/%f")
(setenv "CVSROOT" "z:/")
(setenv "TZ" "PST8PDT")
(setenv "LOGNAME" "hjb")
(setenv "USER" "hjb")
(setq-default explicit-shell-file-name "c:\\4dos\\4nt.exe")
(setq-default shell-file-name "c:\\4dos\\4nt.exe")
(display-time)
(setq-default visible-bell t)
;(require 'cc-compat)
;; (setq gdb-command-name "gdbm68k")
;
; initial geometry
;
(set-frame-height frame-initial-frame 42 )
(setq initial-frame-alist '((top . 1) (left . 120) (width . 80) (height . 42)))
- --------------------------------------------
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: odd behaviour of slow disk drive...
Date: Thu, 31 Oct 1996 23:18:38 +0000
From: rms <richard@carapace.demon.co.uk>
Organization: X
Message-ID: <YR3WcCAOPTeyEwTl@carapace.demon.co.uk>
Reply-To: richard@carapace.demon.co.uk
Dear Sirs
We make a board with video ram. Only 16 bit or higher accesses are
permitted. Our platform is essentially a PC.
We now make a reduced specification version, for which our buyer found a
supply of inexpensive low performance low capacity disk drives.
The drives work perfectly EXCEPT when writing to the video store. ( by
which I mean that I point a read() command at the video ram and let
vxWorks write into the ram directly. ) Needless to say only even numbers
of bytes are ever requested.
My hardware man says that 8 bit accesses must be being created.
To test this I tried reading into a traditional RAM buffer and then
writing to the video RAM with an INT16* to guarantee 16 bit access.
When I do this there is no problem.
Allthouh this SEEMS to have fixed the problem I remain woried that under
load conditions my fully fledged systems may show the same problem. I am
loath to buffer everything on grounds of speed.
I considered that some timeing, critical section or shared access
problem was being exaserbated(sp?) by the slow drive but I doubt that is
the case as the disturbances are in fixed locations.
How can disk speed affect the read() mechanism?
Yours faithfully
'BAFFLED'
Responses by E-Mail please to richard.simmons@oxtel.com
- --
rms
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Video driver on VxWorks
Date: Thu, 31 Oct 1996 23:23:46 +0000
From: rms <richard@carapace.demon.co.uk>
Organization: X
Message-ID: <CRUQsGACUTeyEwx0@carapace.demon.co.uk>
References: <326F11EB.47BD@ozy.dec.com> <326F88C9.14A1@finley.com>
 <554iuv$lep@isoit109.bbn.hp.com>
Reply-To: richard@carapace.demon.co.uk
In article <554iuv$lep@isoit109.bbn.hp.com>, Juergen Sang
<jusa@bbn.hp.com> writes
>John Finley (john@finley.com) wrote:
>: Rami Smair wrote:
>
>: > I'm likely to be writing video driver on VxWorks, I need any
>: >
>: > Any help would be appreciated.
>
>: If you providing more specific information, it's more likely
>: someone will pop up and say "I've done that already".
>
>In fact, there is a commercially Windowing System (MetaGrafix)
>available for at least DOS, pSOS+/386 and VX-Works 386. It
>supports nice features as windowing, 16 bit fonts, all drawing
>functions you expect (incl. Beziers etc. pp.). We have used
>it in our latest products, and were quite pleased.
>
Do you have an E-Mial address for MetaGraphics?
Thanks
Richard.
- --
rms
---------------------------
Newsgroups: comp.os.vxworks
Subject: Are you happy with Vx Works and Wind River
Date: Thu, 31 Oct 1996 17:04:25 -0800
From: Jim Jaskol <jim_k._jaskol@corp.disney.com>
Organization: The Walt Disney Company
Message-ID: <32794C99.67F9@corp.disney.com>
We currently use pSOS, and are thinking about using VxWorks.  I would
like advice from current VxWorks users--especially those who have used
pSOS.
     How is the development environment?
     How good is the support from Wind River?
     Are there lots of board support packages?
     Are the board support packages of high quality?
And please don't limit your comments to the above questions.  If there's
something I should know before jumping in, let me know.
Thanks,
Jim Jaskol
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Routing question
Date: Thu, 31 Oct 96 19:49:36 GMT
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <55brsd$58d@idiom.com>
References: <01bbc7f1$42930e00$4c79d9ce@daysbetween>
To disable IP forwarding, turn off global variable ipforwarding.
For example, from shell
- -> ipforwarding=0
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Clarification Of Question - Re: Non Terminating TCP/IP Sockets
Date: Fri, 01 Nov 1996 08:23:38 -0500
From: Ray Gilbert <rgilbert@gic.gi.com>
Organization: General Instruments Communications Division
Message-ID: <3279F9DA.711@gic.gi.com>
References: <327503B6.7860@gic.gi.com> <32779160.3AF8@peacefulstar.oakland.ca.us>
Reply-To: rgilbet@gic.gi.com
When the SCO client is shutdown, the shutdown code does a kill -9
on all the tasks communicating with the VxWorks based server (ugly
huh).  Now, it seems that on some level, the client system "cleans up"
the socket connections to the server, except for 2 or 3 that just
linger.  The fioRead call gets an error for those sockets that are
"cleaned up" and everything is OK, but I am still stuck with the
lingering connections.  That is the part that I cannot figure out.  Why
would some connections close fine, and others just vanish?
Ray
H.J. Bae wrote:
>
> It depends on what you mean when you "shutdown" the clients.
> If you properly shutdown client applications using shutdown()
> followed by close() socket calls, the server side should
> receive a TCP FIN, and read() on server socket will return
> with error, which will tell you when client goes away.
> If you just power down (withoug doing graceful shutdown of
> Unix OS) on the client side, server won't know anything
> about client going away.
> --
> http://peacefulstar.oakland.ca.us
> mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Seeking XDR functions/types
Date: 31 Oct 1996 22:25:35 GMT
From: scott@tcville.es.hac.com
Organization: Hughes Aircraft
Message-ID: <55b90v$k93@hacgate2.hac.com>
Reply-To: scott@tcville.es.hac.com
I am seeking some XDR functions/source to allow
data xport (socket based) between a VxWorks target
and a Unix host (AIX & Solaris).
Thanks for any/all assistance,
   E. Scott Channell
- ---
Hughes Aircraft Co.		voice:	(310) 616-1059
Image and Signal Processing Lab	addr:	scott@tcville.es.hac.com
PO Box 902, EO/E01/A172, El Segundo, Ca. 90245
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Seeking XDR functions/types
Date: 1 Nov 1996 18:50:16 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <55ect8$g3c@elaine23.Stanford.EDU>
References: <55b90v$k93@hacgate2.hac.com>
In article <55b90v$k93@hacgate2.hac.com>,  <scott@tcville.es.hac.com> wrote:
>I am seeking some XDR functions/source to allow
>data xport (socket based) between a VxWorks target
>and a Unix host (AIX & Solaris).
>
>Thanks for any/all assistance,
>   E. Scott Channell
>
>---
>Hughes Aircraft Co.		voice:	(310) 616-1059
>Image and Signal Processing Lab	addr:	scott@tcville.es.hac.com
>PO Box 902, EO/E01/A172, El Segundo, Ca. 90245
>
xdr functions should be built into the kernel image
especially if rpcLib is included (i.e. RPC uses XDR
for data transmission to heterogeneous hosts. To check
try lkup from shell
- -> lkup "xdr"
Should see functions like
xdr_int
xdr_long
xdr_short
...
See SunOS documentation for more info on how to use XDR functions.
Here's some sample code I threw together to give you an idea how
to use XDR with sockets.
void sendXdrMsg(char *msg, BOOL (*xdrfcn)(), int bufferLen)
{
	XDR   out ;
	char *buffer ;
	/* Create buffer to hold XDR encoded msg and tie to an XDR out stream */
	buffer = malloc(bufferLen) ;
	xdrmem_create(&out, buffer, bufferLen, XDR_ENCODE);
	/* Encode msg in XDR */
	if ( (*xdrfcn)( &out, msg))
        {
	    /* send XDR encoded msg over socket */
	    send(socketFd, buffer, bufferLen, 0) ;
	}
	/* destroy XDR out stream and buffer */
	xdr_destroy(&out);
	free(buffer);
}
typedef struct Foo {
	int a ;
	long b ;
} Foo ;
/* user defined xdr function for Foo */
BOOL xdr_Foo(XDR *xdrs, Foo *pfoo)
{
	return( xdr_int(xdrs, &(pfoo->a)) &&
	        xdr_long(xdrs, &(pfoo->b)) ) ;
}
sender()
{
	int msg1 ;
	Foo msg2 ;
	sendXdrMsg(&msg1, xdr_int, sizeof(msg1)) ;
	sendXdrMsg(&msg2, xdr_Foo, sizeof(msg2)) ;
}
You should be able to figure out the rest using this
simple example. The receiver would use a function
recvXdrMsg() which would use XDR_DECODE for xdr_memcreate(),
and it call xdrfcn() after doing a recv() for socket.
To really do messages your xdr_Foo() should exploit
xdr_union and a type field.
---------------------------
Newsgroups: comp.os.vxworks
Subject: BSP for Arnewsh SBC360 board
Date: 1 Nov 1996 11:21:13 -0800
From: Christopher J. Netter
Organization: Lucent Technologies
Message-ID: <55dij9$hmu@lex.zippo.com>
Greetings,
Has anyone put together a BSP for the Arnewsh SBC360.  This is a VME board from
Arnewsh (Fort Collins,CO) with a Motorola 68360 on it.  We have a half dozen
around and it seems like a waste to not make use of them.
Thanks,
Chris Netter
Lucent Technologies
cnetter@lucent.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Sat, 02 Nov 1996 06:12:15 GMT
From: sgaeke@cris.com (Steve Gaeke)
Organization: Concentric Internet Services
Message-ID: <55eecn$oj7@herald.concentric.net>
References: <32794C99.67F9@corp.disney.com>
Jim Jaskol <jim_k._jaskol@corp.disney.com> wrote:
We have not been real pleased with the Tornado port to x86.  There was
a lot of good salesmanship up front but after we jumped into it, we
found almost everything was still pretty buggy or promises were made
and not kept.  I wish now we had gone with pSOS.  Why are you thinking
of dropping pSOS and what platform are you developing for?
sgaeke@cris.com
/////////////////////////////////////////////////////////////
My opinions are my own and do not reflect those of my employer.
/////////////////////////////////////////////////////////////
>We currently use pSOS, and are thinking about using VxWorks.  I would
>like advice from current VxWorks users--especially those who have used
>pSOS.
>     How is the development environment?
>     How good is the support from Wind River?
>     Are there lots of board support packages?
>     Are the board support packages of high quality?
>And please don't limit your comments to the above questions.  If there's
>something I should know before jumping in, let me know.
>Thanks,
>Jim Jaskol
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 1 Nov 1996 20:45:30 -0800
From: ralerche@lindy.stanford.edu (Robert A. Lerche)
Organization: MSB Associates
Message-ID: <55ejla$9gm@lindy.stanford.edu>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net>
I just selected VxWorks / Tornado for a client developing a network
access device.
So far I'm very satisfied with the support I've gotten, though it has
been a bit of a struggle since we are using the 68EN302 as our
processor and the board support package for it just became available.
The BSP is for the Motorola FADS302 board; I had to make a few small
changes to get it to work in our target.
I have to say that the first-line technical support is not as
knowledgeable as I might wish, but they are courteous and will
escalate a problem after they understand that they are unable to solve
it.  I think they're a little bit swamped, too.
I think the tools work best if you install the target server on a Unix
platform, rather than trying to use PC's running Win95 as target
servers.  Maybe Windows NT works, but Win95 doesn't really work if you
try to use a third system as the client.
---------------------------
End of New-News digest
**********************
From adler@bnlku5.phy.bnl.gov  Sat Nov  2 08:35:52 1996
From: "Steve Adler" <adler@bnlku5.phy.bnl.gov>
Date: Sat Nov  2 08:35:55 PST 1996
Subject: This is a test....
This is a test.
From adler@bnlku5.phy.bnl.gov  Sat Nov  2 12:45:41 1996
From: "Steve Adler" <adler@bnlku5.phy.bnl.gov>
Date: Sat Nov  2 12:45:43 PST 1996
Subject: vxworks and linux
I submitted this posting before and got no answer. I don't
know if its because no one cares or if my posting didn't go
through. In any case, I won't post this again.
-------------VxWorks on Linux Survey-------------------
Please fill out and return to adler@bnlku5.phy.bnl.gov
1) I would be interested in a release of VxWorks/Tornado which
   hosts off a PC running Linux.
     YES
     NO
If you answered yes the question 1, go to question 2 else
go to question 5.
2) Knowledge of Linux: Check the item which pertains to you.
   I'm a Linux guru and have no trouble maintaining Linux on my
     PC
   I'm a Linux novice and need help maintaining my system
   I've heard of Linux but have never used it or have talked to
     anyone who has or is using it.
3) Linux distribution: Currently I use or maintain PC's with the
     following Linux distributions (check more than one if you use
     or maintain PC's with more than one distribution)
      Redhat
      Debian
      Slakware
      Other specify here ->
      None
4) Wind River support for Linux: Check the item which describes
     the level of support you expect from Wind River Systems if
     they released the Linux host platform.
   a) I only need support for Tornado and other VxWorks related software
     products.
   b) Item a) and help with generic Unix questions regarding my writing
      and debugging VxWorks software.
   c) Item a), b) and help maintaining my Linux system.
Stop here:
Thanks for filling out the survey.
5) Non Linux interest: Check the item which best describes your
      attitude towards Linux and or VxWorks on a PC platform
   I run VxWorks off a Unix workstation (Sun, HP, SGI etc.) and have
     no need to use Linux.
   Linux is public domain software and therefore too unreliable
     to use in my work developing VxWorks code. I'll never be
     able to get the support I need.
   I don't know what Linux is, so I'm not interested.
   I run Windows 95 on my PC and VxWorks support for Windows 95
     suits me just fine.
   I run Windows NT on my PC and VxWorks support for Windows NT
     suits me just fine.
Stop here:
Thank you for filling out the survey.
Steve Adler.
From wbeebe@gate.net  Sun Nov  3 16:45:23 1996
From: William Beebe <wbeebe@gate.net>
Date: Sun Nov  3 16:45:25 PST 1996
Subject: unsubscribe
unsubscribe
From tmorris@me.umn.edu  Mon Nov  4 07:55:03 1996
From: "Ted Morris" <tmorris@me.umn.edu>
Date: Mon Nov  4 07:55:06 PST 1996
Subject: Re: vxworks and linux
>
> Submitted-by adler@bnlku5.phy.bnl.gov  Sat Nov  2 12:45:41 1996
> Submitted-by: "Steve Adler" <adler@bnlku5.phy.bnl.gov>
>
> I submitted this posting before and got no answer. I don't
> know if its because no one cares or if my posting didn't go
> through. In any case, I won't post this again.
>
> -------------VxWorks on Linux Survey-------------------
>
> Please fill out and return to adler@bnlku5.phy.bnl.gov
>
> 1) I would be interested in a release of VxWorks/Tornado which
>    hosts off a PC running Linux.
>
  ===> YES
>      NO
>
> If you answered yes the question 1, go to question 2 else
> go to question 5.
>
> 2) Knowledge of Linux: Check the item which pertains to you.
>
>    I'm a Linux guru and have no trouble maintaining Linux on my
>      PC
>
  ===> I'm a Linux novice and need help maintaining my system
>
>    I've heard of Linux but have never used it or have talked to
>      anyone who has or is using it.
>
> 3) Linux distribution: Currently I use or maintain PC's with the
>      following Linux distributions (check more than one if you use
>      or maintain PC's with more than one distribution)
>
>       Redhat
>       Debian
>       Slakware
 ===>   Other specify here -> MatLAB, massive sortie of pub. domain software
>       None
>
> 4) Wind River support for Linux: Check the item which describes
>      the level of support you expect from Wind River Systems if
>      they released the Linux host platform.
>
===>  a) I only need support for Tornado and other VxWorks related software
>      products.
>
>    b) Item a) and help with generic Unix questions regarding my writing
>       and debugging VxWorks software.
>
>    c) Item a), b) and help maintaining my Linux system.
>
> Stop here:
>
> Thanks for filling out the survey.
>
>
thank YOU, no problem!
Ted
>
>
     _/_/_/     _/_/    _/_/    _/_/ _/_/_/      _/_/     _/_/_/
   _/         _/  _/   _/ _/  _/ _/ _/    _/   _/  _/   _/
  _/        _/    _/  _/  _/_/  _/ _/    _/  _/    _/  _/
 _/        _/_/_/_/  _/   _/   _/ _/    _/  _/_/_/_/  _/
 _/_/_/   _/    _/  _/        _/ _/_/_/    _/    _/   _/_/_/
------------------------------------------------------------------------------
Ted Morris
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology                                   FAX: 612-625-8884
University of Minnesota
111 Church St. S.E. (Rm 125)
Mpls  MN   55455
"A lie can travel halfway around the world before the truth can get
its shoes on." [Actually, NOT Mark Twain]
------------------------------------------------------------------------------
From daemon@csg.lbl.gov  Tue Nov  5 04:00:40 1996
From: daemon@csg.lbl.gov
Date: Tue Nov  5 04:00:43 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Nov  5 04:00:37 PST 1996
        Subject: Re: Tcl/Tk
        Subject: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Anyone using ZBufs?
        Subject: Serial Port Programming in VM30
        Subject: Re: Virtual to Physical address conversion.
        Subject: Re: Problem with free()
        Subject: VME interrupt levels & vectors
        Subject: Re: pc-486 serial ports 3+4
        Subject: Re: Floating Point From ROM
        Subject: web server on vxw?
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Video driver on VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Tcl/Tk
Date: Fri, 01 Nov 1996 11:06:49 -0700
From: "Loay (Louie) Abu-Husein" <loay@boi.hp.com>
Organization: Color LaserJet and Consumable Division, R&D Labs
Message-ID: <327A3C39.20EF@boi.hp.com>
References: <3275C320.893@llnl.gov>
I am trying to port Tcl To VxWorks but I ran into problems
with the following system calls that Tcl have but not VxWorks:
1.  System calls used to build pipes:
    fcntl(), pipe(), dup2(), fork()
2.  System calls used for host and user identification such as:
    getuid(), getpwnam()
3.  Also how to handel environment variables such as the use
    of the char **environ  Global variable.
I have written stubs and disabled functionality temporarly
until a more permenant solution is found.  Does anyone know
the answer to 1 and 2 in perticular.
Thanks.
- --
    _/  _/  _/_/_/ Loay (Louie) Abu-Husein
   _/  _/  _/  _/  Intranet:  http://hpbs4896.boi.hp.com/
  _/_/_/  _/_/_/   Internet:  http://www.boi.hp.com/
 _/  _/  _/        EMail:     mailto:loay@hpbs4896.boi.hp.com
_/  _/  _/
---------------------------
Newsgroups: comp.os.vxworks
Subject: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board
Date: Thu, 31 Oct 1996 20:03:25 -0500
From: "Thomas A. Bond" <tom@realtime1.com>
Organization: Realtime Software Solutions, Inc.
Message-ID: <32794C5D.102F27DC@realtime1.com>
Hello,
	Is there a protocol available for downloading code to a
VxWork DEC apha board from a WinNT Intel/DEC based PC?
The startup code would be downloaded from the WinNT machine to the
Vxworks DEC aplha board via some boot loader code using some type of
protocol.  Is there a version of tftp available for WinNT or any other
viable protocol to accomplish this task?  Thanks!
				Tom
- --
      +=============================================================+
      ||                                                           ||
      ||                 What the world needs today !              ||
      ||                                                           ||
      ||                    //                                     ||
      ||                   //    // ///// // // // //              ||
      ||                  //    // // // // //  ///                ||
      ||                 ///// // // // ///// // //                ||
      ||                                                           ||
      ||             The choice of a smarter generation !          ||
      ||                                                           ||
      +=============================================================+
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Mon, 04 Nov 1996 12:59:04 -0500
From: rypma@waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Division
Message-ID: <rypma-0411961259040001@hppadhtr1.waterloo.hp.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <gerlachE0CtwF.Ju2@netcom.com>
In article <gerlachE0CtwF.Ju2@netcom.com>, gerlach@netcom.com (Matthew H.
Gerlach) wrote:
>Interesting, my experience with GNU tools in general has been great, and
>Wind River's use of the GNU tools, IMHO is a compelling reason to use
>VxWorks.
I second Matthew's comments. It is in many ways _because_ of the Gnu
tools that we were able to avoid problems and move ahead,
sometimes in spite of Wind River. The Gnu tools made us independent
of Wind River's ability to support tools. We put tgdb (tcl front end to
gdb) in place of Wind Rivers version and are happier with it. We have
a choice in which vendor (or ourselves, for that matter) does tool support.
- --
- -----
Ted Rypma, Waterloo, Ontario, Canada  ===   rypma@waterloo.hp.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Anyone using ZBufs?
Date: Tue, 29 Oct 1996 04:57:12 GMT
From: jay@fallcreek.com (Jay Slupesky)
Organization: Fall Creek Systems, Inc.
Message-ID: <5543lo$jg7@clark.zippo.com>
Reply-To: jay@fallcreek.com
Hello,
Has anyone tried using ZBufs to improve the performance of
socket-based programs?  I have a simple routine that reads data from
one socket and writes it to another.  When I use ZBufs, the program
actually runs much SLOWER than when  I use read() and write().
Using ZBufs should make the program faster, not slower, since it
eliminates two data copies.
Anyone have any thougnts?
Jay Slupesky    Fall Creek Systems, Inc.
Pleasanton, California, USA
jay@fallcreek.com  http://users.aol.com/jslupesky
"Professional Internet user on closed circuit.  Do not attempt."
---------------------------
Newsgroups: comp.os.vxworks
Subject: Serial Port Programming in VM30
Date: Mon, 04 Nov 1996 18:10:15 +0900
From: Jun-pyo Hong <g9611110@inhavision.inha.ac.kr>
Organization: BISE Lab., Inha Univ.
Message-ID: <327DB2F7.21DF@inhavision.inha.ac.kr>
I am using VxWorks(V5.1.1) on the VM30.
Working Computer and OS is Workstation and SUN-OS.
VM30 board is mounted VME bus.
I am trying to program two serial ports on VM30.
If anyone have been that, please help me.
Thanks to read.
J.P.Hong
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Virtual to Physical address conversion.
Date: 4 Nov 1996 20:44:57 GMT
From: friedl@cher.heurikon.com (Ted Friedl)
Organization: Heurikon Corporation
Message-ID: <55lkk9$7rp@badger.heurikon.com>
References: <327E1257.65792670@ccii.co.za> <55l8r1$hbc@news.sei.cmu.edu>
In article <55l8r1$hbc@news.sei.cmu.edu>,
Theodore Marz <tfm@sei.cmu.edu> wrote:
>
>In article <327E1257.65792670@ccii.co.za>, Casey Crellin <casey@ccii.co.za> writes:
>  This is speaking from a Motorola 68K perspective (mvme-167).
[snip]
For code portability between different target platforms, it is
probably best to use the macros supplied in cacheLib.h.
See CACHE_DMA_VIRT_TO_PHYS() and CACHE_DMA_PHYS_TO_VIRT().
Ted Friedl
Senior Software Engineer
Heurikon Corporation
Madison, WI
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Problem with free()
Date: Sun, 03 Nov 1996 04:26:49 GMT
From: brucew@phoenix.net (Bruce)
Organization: BranPaul Systems
Message-ID: <55h6v8$e8c$1@uhura.phoenix.net>
References: <51mket$t5n@mark.ucdavis.edu>
In comp.os.vxworks
saquresh@taco.engr.ucdavis.edu (Shehrzad Ahmed Qureshi)
wrote:
>    My problem is when I try to free these pointers.  I will make a call
>such as
>    free ((char *) &rec->priority[1]) and will get an error like this
it should be free( rec->priority[1]);
drop the address operator as it is already a pointer.
---------------------------
Newsgroups: comp.os.vxworks
Subject: VME interrupt levels & vectors
Date: 25 Oct 1996 08:59:03 GMT
From: "Ron Gross" <rgross@precisiondata.com>
Organization: Precision Data Services
Message-ID: <01bbc25a$6bec15e0$f371e8c7@rgross.venus.star.net>
We have a MVME-133XT (68020) running 4.0.2VxWorks (working on moving to
5.2) and have installed a new card in out VME rack (DeltaTau PMAC-VME).
This card provides three interrupt vectors on one interrupt level,
depending on what the interrupt was for.  I have not setup interrupts on
VxWorks before, and the docs (4.0.2 and 5.2) do not seem to talk about
levels.
1.  How do I tell VxWorks about the interrupt level (3 or 4 can be used)?
Does VxWorks just trap all level interrupts and automatically get the
vector number and use that to 'vector' to the selected routine?
2.  Do I use a seperate routine to handle each interrupt vector?
- --
Ron Gross
Precision Data Services
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: pc-486 serial ports 3+4
Date: 24 Oct 1996 14:03:57 -0700
From: dzhu@enlil.jpl.nasa.gov (David Zhu)
Organization: jpl
Message-ID: <tr1vic0m5vm.fsf@enlil.jpl.nasa.gov>
References: <326B827B.4D87@mail.imech.uni-duisburg.de>
Sender: dzhu@enlil.jpl.nasa.gov
In article <326B827B.4D87@mail.imech.uni-duisburg.de> Stefan Vogel <vogel@mail.imech.uni-duisburg.de> writes:
>
>
>   Hi,
>
>   I would like to use the serial ports 3 and 4
>   on a pc-board. Has anyone experience in this
>   Subject??
>
>   Stefan
>
>
>
>
We've installed a quad serial board on a PC104 system.  Since it is
only a 8-bit board, it cannot use interrupt above 7.  But it supports
shared interrupt; so we rewrote the interrupt handler.  If shortage of
interrupt lines are not a problem, you only need to modify pc.h and
create the devices after bootup.
David
- --
- ----------------------------------------------------------------------
David Q. Zhu
Jet Propulsion Laboratory          e-mail: David.Zhu@jpl.nasa.gov
MS 198-235                          phone: 818-354-9058 (office)
4800 Oak Grove Dr.
Pasadena, CA  91109
- ----------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Floating Point From ROM
Date: Tue, 05 Nov 1996 02:48:07 GMT
From: jdeffner@west.net (john deffner)
Organization: West.Net Communications
Message-ID: <55m9gm$hib@daffy.sb.west.net>
References: <01bbc9b4$6e2d9d40$dc4698c2@prsf56re.prestel.co.uk>
On 3 Nov 1996 18:26:01 GMT, "Robin Smith"
<rob@robin-smith.prestel.co.uk> wrote:
>We are using VxWorks 5.1.1 under Rational Ada and are having problems with
>floating point when blowing an app into ROM.  It works fine when built as a
>RAM image but the same floating point call (any of sin/cos/sqrt) causes the
>task to terminate.
>Can any body help?
>
>Thanks
>Robin
Well, this may not be applicable, but it sure was puzzling when I was
working with it - We're running 5.3 on a 386ex board that is very
similar to the intel eval board except for some chip selects and
memory bus widths.
The system crashed on takeoff on our board unless we disabled the
floating point. It turned out vxWorks was probing for the coprocessor
using a routine called fppProbeSup. Neither the eval board (which
worked) or our board (which doesn't) has a coprocessor, but
fppProbeSup returns a 'not found' on the eval board and hangs the bus
on our board.
There's something very bad about our board and  It may be the bus
width difference between the flash on the eval board and on ours. Kind
of a hard problem to troubleshoot. I ended up hacking the hex code to
remove the part of fppProbeSup that probes for the coprocessor
(replaced it with nops) so it just returns 'not found'.
---------------------------
Newsgroups: comp.os.vxworks
Subject: web server on vxw?
Date: Tue, 05 Nov 1996 02:57:11 GMT
From: jdeffner@west.net (john deffner)
Organization: West.Net Communications
Message-ID: <55ma1l$hlh@daffy.sb.west.net>
There's been some talk in the trades about embedded web servers so you
could use a standard browser as an interface and talk http to the
embedded processor.
We've got an infrared video camera running vxWorks that could use a
new user interface one of these days. Has anyone any information or
thoughts on this for vxWorks?
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Mon, 04 Nov 1996 08:48:45 -0500
From: "Mark J. Nelson" <Mark_Nelson@Kodak.COM>
Organization: Eastman Kodak Company
Message-ID: <327DF43D.7EE2@Kodak.COM>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net>
Reply-To: "Mark J. Nelson" <Mark_Nelson@Kodak.COM>
Steve Gaeke wrote:
> Jim Jaskol <jim_k._jaskol@corp.disney.com> wrote:
>
> We have not been real pleased with the Tornado port to x86.
We've been using the Wind River Systems pc486 bsp on a Pentium
target system with very few problems.  I've rarely had to go to
tech support; on the few occasions I have, I've gotten quite
reasonable response.
> >     How is the development environment?
Good.
> >     How good is the support from Wind River?
Not bad.
> >     Are there lots of board support packages?
We were really interested in one particular bsp...
> >     Are the board support packages of high quality?
Seems good so far.
- --
Mark J. Nelson   Eastman Kodak Company
                 Development Engineer
                 mailto:Mark_Nelson@Kodak.COM
		 voice (716)588-6226 / fax (716)477-6811
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Mon, 04 Nov 1996 09:37:27 -0600
From: Steve Woloschek <woloschekS@med.ge.com>
Organization: GE Medical Systems
Message-ID: <327E0DB7.6513@med.ge.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net>
I second Steve's comments. But most of my problems stem
from the fact that WRS uses GNU tools. IMOH, this is a real
downfall. I have had many problems with these tools and
getting support through WRS for GNU problems is impossible.
Even though the salesman said it would not be an issue, since
Cygnus was great about problems! Ya right!
If I were to do it again I would pick pSOS
Steve Woloschek
Steve Gaeke wrote:
>
> Jim Jaskol <jim_k._jaskol@corp.disney.com> wrote:
>
> We have not been real pleased with the Tornado port to x86.  There was
> a lot of good salesmanship up front but after we jumped into it, we
> found almost everything was still pretty buggy or promises were made
> and not kept.  I wish now we had gone with pSOS.  Why are you thinking
> of dropping pSOS and what platform are you developing for?
>
> sgaeke@cris.com
>
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Video driver on VxWorks
Date: 4 Nov 1996 15:17:22 GMT
From: jusa@bbn.hp.com (Juergen Sang)
Organization: Hewlett Packard GmbH Germany
Message-ID: <55l1e2$94l@isoit109.bbn.hp.com>
References: <326F11EB.47BD@ozy.dec.com> <326F88C9.14A1@finley.com>
rms (richard@carapace.demon.co.uk) wrote:
: Do you have an E-Mial address for MetaGraphics?
I used to use sales@metagraphics.com
They also have a web server, as far as I recall.
- --
Cu, J|rgen
- ------------------------------------------------------------------
J|rgen Sang                           Phone +49-7031-14-2302
Hewlett Packard GmbH                  FAX   +49-7031-14-7023
Bvblingen Instruments Division        Email jusa@bbn.hp.com
Herrenberger Str. 130
71034 Bvblingen                       WWW (HP internal access)
Germany                               http://bidro63.bbn/jusa.html
- ------------------------------------------------------------------
---------------------------
End of New-News digest
**********************
From evdsande@emt.ie.philips.nl  Tue Nov  5 04:48:14 1996
From: "E. v.d. Sande" <evdsande@emt.ie.philips.nl>
Date: Tue Nov  5 04:48:16 PST 1996
Subject: RE: Are you happy with Vx Works and Wind River
Jim Jaskol wrote:
>We currently use pSOS, and are thinking about using VxWorks.  I would
>like advice from current VxWorks users--especially those who have used
>pSOS.
>
>     How is the development environment?
>     How good is the support from Wind River?
>     Are there lots of board support packages?
>     Are the board support packages of high quality?
>
>And please don't limit your comments to the above questions.  If there's
>something I should know before jumping in, let me know.
In response to what Steve Gaeke stated:
We are also not very pleased with the Tornado port to x86. We are using
Tornado on a PC-host running windows-95 and a dedicated target system based
on a 80386EX processor. We ran into a lot of problems implementing vxWorks
on our target system and support from windriver was everything except
satisfactory.
We started evaluating pSOS, so our question is also : Why are you thinking
of dropping pSOS and switch to vxWorks ?
evdsande@emt.ie.philips.nl
Best Regards Eric van der Sanden
_______________________________________________________
Philips Electronic Manufacturing Technology B.V.
Ing. E. van der Sanden
Electrical Development
Building BY-041
P.O.box 218
5600 MD  Eindhoven
The Netherlands
Tel: +31 40 2722762
Fax: +31 40 2724610
E-mail: evdsande@emt.ie.philips.nl
_______________________________________________________
From leonid@rst.co.il  Tue Nov  5 07:26:59 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Tue Nov  5 07:27:02 PST 1996
Subject: Re: Floating Point on MIPS
On 3 Nov 1996 18:26:01 GMT, "Robin Smith"
<rob@robin-smith.prestel.co.uk> wrote:
>We are using VxWorks 5.1.1 under Rational Ada and are having problems with
>floating point when blowing an app into ROM.  It works fine when built as a
>RAM image but the same floating point call (any of sin/cos/sqrt) causes the
>task to terminate.
>Can any body help?
>
>Thanks
>Robin
We have encountered a similar problem, which also relates to VADS
Ada on VxWorks 5.2 and MIPS R4000 processor.
Here is the problem: If the program is in C, the C compiler generates
directly machine instructions for the math functions. inline.
Ada in contrast, will call the functions of the same names inside the
VxWorks libraries. Turns out these functions work incorrectly,
as they can not be tested with a "C" application, the compiler
will never generate calls to these functions. Ada does.
the solution was to create a small file in assembly, which contains
new definitions for the math functions, with the body of each
function simply calling the machine instruction appropriate.
This assembly file was placed in the BSP directory, and linked
in to the kernel.
I hope this helps.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From ddavies@worf.dvg.com  Tue Nov  5 08:10:58 1996
From: ddavies@worf.dvg.com (Douglas Davies)
Date: Tue Nov  5 08:11:00 PST 1996
Subject: RE: Are you happy with Vx Works and Wind River
I hope that the Wind River folks are paying attention to this thread
and several other recent threads; ie. C++ compiler support, C++ I/O
streams support/pricing, GNU tool quality/support, etc.
IMHO you have some substantial quality and pricing issues to address...
I have been using VxWorks for almost 8 years now.  In the beginning,
I was very impressed with the quality, etc..  That however changed
with the "slick" marketing and exorbitant pricing of tornado.
In short, I am no longer impressed...  And you can bet that I will be
investigating other RTOS options before we begin any new development.
-Doug
Douglas Davies
Director of Software Engineering
Utah Scientific, Inc.
From slirosi@gic.gi.com  Tue Nov  5 09:00:18 1996
From: "Lirosi, Salvatore (HT-MS)" <slirosi@gic.gi.com>
Date: Tue Nov  5 09:00:26 PST 1996
Subject: Zbufs
==> jay@fallcreek.com wrote:
=> Has anyone tried using ZBufs to improve the performance of
=> socket-based programs?  I have a simple routine that reads data from
=> one socket and writes it to another.  When I use ZBufs, the program
=> actually runs much SLOWER than when  I use read() and write().
=> Using ZBufs should make the program faster, not slower, since it
=> eliminates two data copies.
=> Anyone have any thougnts?
I've spent about 2 weeks investigating the usefulness of UDP over zbufs for
our application.
What I've found is that the zbuf interface is not worth using unless you are
simply reading into a socket and writing to another without any data
manipulation.  In addition, the data should be consistently more than 512
bytes in size per read operation.
Sal LiRosi
From mea@mclean.sparta.com  Tue Nov  5 09:45:32 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Tue Nov  5 09:45:34 PST 1996
Subject: RE: Are you happy with Vx Works and Wind River
Jim Jaskol wrote:
>     How is the development environment?
>     How good is the support from Wind River?
>     Are there lots of board support packages?
>     Are the board support packages of high quality?
>And please don't limit your comments to the above questions.  If there's
>something I should know before jumping in, let me know.
With regards to my viewpoint on VxWorks, I find the following things to
be true:
1)  The development environment in VxWorks is as good as that of any
    other *embedded* RTOS.  That is, it would be wonderful to have
    and IDE like Microsoft Visual C++ with the integrated debugger, etc.
    PSOS kinda has that with the Microtec toolset and XRAY etc.  However,
    WRS's use of the GNU toolset means that we can control the sources for
    the major components of the tools chain and can ask for help from the
    'net to resolve issues.  Yes, there are some bugs in the GNU toolset.
    However, in the years since WRS switched to the GNU tools, I have yet
    to find a *serious* compiler bug (even when developing BSPs for new
    boards).  I think Windview (especially when coupled with RTI's
    Stethoscope product) is extremely useful, especially if you don't have
    the bucks for an ICE.  However, I'm not as bullish on Tornado.  More
    on that in a later paragraph.
2)  WRS's support capabilities are, I believe, typical of the industry.  That
    is to say, WRS has good people who mean well and are trying to fulfill
    the support requirements of a *very* diverse community.  Unfortunately,
    I believe that there are too few support folks for the size of the user
    base.  Also, I have a feeling that there is a general lack of what I'll
    refer to as "real-world" embedded systems development experience.  Perhaps
    the support folks should be cycled through the engineering department
    to give them a better understanding of the O/S and its features.
3)  As to BSPs, I seriously doubt that you could find an RTOS with more BSPs
    than VxWorks. Also, the quality of the BSPs are generally good.  There
    are, of course, going to be problems.  Some companies that are, say OS9
    shops, may not do as complete a job of a VxWorks BSP as a dedicated
    VxWorks-oriented vendor.  This is largely owing to lack of VxWorks BSP
    experience.  However, you do get most of that BSP code as source, so
    like the GNU environment, you can tailor the BSP locally to meet your
    requirements.  I guess the bottom line on the BSPs is to make sure
    that your hardware vendor has a good deal of experience with VxWorks
    so that they can help address any BSP deficiencies you may find.
4)  Now, what about Tornado?  If you were to believe all of the press (and
    the WRS salescritters), Tornado is a radically new development approach
    that will revolutionize the industry.  However, I believe that in an
    effort to increase sales, improve the stock price, etc. that many at WRS
    have lost sight of the *real* product.  That is, the base VxWorks O/S
    that runs on the target.  Tornado seems to be well suited for the
    development model of those large companies such as HP wherein they are
    embedding VxWorks into a printer.  That is, when you don't have much
    RAM, no serial console ports, and maybe no Ethernet, then Tornado
    represents a fine development environment *in theory*.  And, I
    believe, that the Unix implementation comes pretty close to realizing
    that environment in practice.  However, from what I've heard from the
    net, I believe that there are some serious problems (memory leaks, etc.)
    in the Tornado product under Win 95 & Win NT.
    Let's face it people, Win 95 & NT do not have the same level of robustness
    that you find in a BSD or System V derived Unix.  I, personally, like
    both Win 95 & NT.  But, when you introduce folks that are used to
    writing Win 3.1 or MSDOS code into a multi-threaded O/S with semaphores,
    event-queuing, etc. they are going to miss many of the concepts.  This
    has many implications.  First, if the WRS development team for the 95 &
    NT platform came from a Unix background, they're no doubt frustrated
    by the new (and continually changing) Win32 API.  Evidence the new
    WINHEC driver specification for both platforms.  Just the size of
    the Win32 API is daunting.  Alternatively, if the developers came from
    a Windows environment, they must be going nuts with all of the new
    concepts in the 32-bit address space, events, Ring 0 VXDs and all of
    the rest of the stuff that's new to 95 & NT.
    Now, from a support perspective, if you open the RTOS to all of these
    Win 3.1 developers, you've just opened Pandora's box.  Just the
    implications of a preemptive, priority-based scheduler can be
    overwhelming to folks that have never seen such a creature before.  This
    causes more support calls, which means a higher burden on the support
    techs to educate the customer, which results in poorer service across
    the board because of lack of cycles.  Real-time programming is not
    as simple as writing a database app.  Should WRS have tried to move
    Tornado to the 95 & NT platform?  I believe that the answer is yes.
    But, WRS needed to beef up their  support organization to handle the
    influx of calls from people just trying to grasp the basic concepts
    of the RTOS.
    And what of Tornado for those of us who work in the VMEbus world?  As
    I've said, my impression of Tornado is that it's well suited for the
    truly "embedded" applications such as printers and truck transmissions.
    That's most of WRS's west coast business.  But, here on the East coast,
    many of us are still using VME for mission critical kinds of systems
    such as launch control and signal processing.  Evidence the East coast
    user's group meeting wherein over 90% of the attendees were using VMEbus.
    In the VME environment, I believe that the extra overhead of the
    network traffic generated by Tornado and it's host-based shell, loader
    and symbol table have a negative impact on our ability to perform
    hard real-time applications.  Many of you have seen the problems of
    trying to run 20-30 targets when you're using Tornado and need a window
    for each target.  But, WRS provided the mechanisms to deal with this
    problem by allowing us to reconfigure the *target* RTOS to look and
    act like VxWorks 5.2.  With the shell, loader and symbol table on the
    target, we can eliminate all of that non-deterministic network traffic.
To summarize:
  IMHO, VxWorks is still the best RTOS on the street for a wide variety of
jobs.  It's as well supported as any other product out there.  If you like
GNU, great you can use it.  If you don't, then buy the compilers from
Diab Data, Green Hills or Centerline and you can still use VxWorks on the
target.  Yes, there are outright hacks in VxWorks.  Have you seen Windows
NT lately?  Talk about hacks ;-).  Tornado is a good thing if you application
hardware has limited RAM/connectivity.  Reconfigure Tornado to look like 5.2
if you're using the VMEbus with *lots* of targets.  In any case, it's the
operating system on the *target* that matters, not so much the development
tools (once you get to a certain point ;-).
  To WRS, you've got a good product.  Don't let the marketeers or your own
marketing hype make you lose sight of the *real* product.  The VxWorks RTOS.
Don't cut your engineering staff to save money.  You'll only lose in the
long run if the real product suffers from lack of talent being applied.
Tornado is neat, but all the fancy GUIs in the world won't help if the can't
meet our real-time deadlines.  Look at symmetric multiprocessing.  How
about fixing the MSDOS file system so we can exchange media with 95 & NT
boxes?  What about SCSI-2 (fast/wide) support (and SCSI-3)?  Multi-initiator
SCSI transfers between processors?  Multicast IP support.  Just to name a few.
WRS used to be an engineering-driven company, I sometimes get the impression
that you're now marketing driven.  Your profitablility is good (your
pricing policy needs serious work though).  But, don't forget the user base
that got you there.  We picked VxWorks because your RTOS was light years
ahead of the competition technically, not because you've got a nifty ad in
Computer Design Magazine.
End of tirade,
============================================================================
===
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
============================================================================
===
From pean@mbari.org  Tue Nov  5 10:04:15 1996
From: Andrew Pearce <pean@mbari.org>
Date: Tue Nov  5 10:04:17 PST 1996
Subject: RE: Are you happy with Vx Works and Wind River
Hi,
regretfully, I must second Doug's remarks. We have found the
support at WRS to be almost non existent. Getting their attention
on a problem  always seems to be a hassle and the follow through
is sadly lacking. IMHO, WRS has adopted a pricing scheme for their
products which would be appropriate for a well supported product.
I would be happy to pay the costs if the support was there, useful
product enhancements were frequent, bugs were tracked, listed in
some accessible fashion (so we don't keep rediscovering the same
problems), fixed in a timely manner and rolled into the next release.
Maybe Tornado will solve all my problems. :)
Prehaps we should have a different format for the vxWorks users
group. At present, it seems more like a soap box for WRS corporate
policy than a forum where users can get together and talk about
the issues they face day to day. There is useful information
here which WRS could use to enhance their products and improve
support if they are willing to listen.
--
Andrew Pearce                            | email: pean@mbari.org
Monterey Bay Aquarium Research Institute | tel:   (408) 775-1746
7700 Sandholt Rd                         | fax:   (408) 775-1646
Moss Landing, CA 95039                   | URL:   http://www.mbari.org/~pean
"Coping's easy.  Not pureeing your loved ones, that's the hard part."
Basil Fawlty
From jdeangcd@eng.kns.com  Tue Nov  5 12:08:01 1996
From: jdeangcd@eng.kns.com (Joe DeAngelo)
Date: Tue Nov  5 12:08:08 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
Jim Jaskol wrote:
>     How is the development environment?
>     How good is the support from Wind River?
>     Are there lots of board support packages?
>     Are the board support packages of high quality?
I've got to agree with Mike Anderson. VxWorks is technically a very nice
product, when you look at the product, the kernel. The development tools
are not the fanciest, but they are robust and work on robust platforms, and
are the up to the state of the industry for embedded systems. There is a VERY
strong Board Support Package presence.
Service from WRS, however, has been disappointing to me. And it is not limited
to the technical expertise of the service reps. There are administrative
problems, where although on support contract, upgrades for supported
components are very difficult to get in a timely fashion, particularly for
those components provided through WRS from a third party. Even quotes from
their sales people seem to be difficult to get!
As far as Tornado is concerned, there are a few very nice technical improvements but basically is seems to me as far as the kernel is concerned, that its just
a minor upgrade. I don't have experience with Tornado, and may NEVER have it
because I've been waiting for a quote from the sales guy for over a month.
Joe DeAngelo
From vince@lassen.rti.com  Tue Nov  5 12:55:10 1996
From: vince@rti.com (Vince Chen)
Date: Tue Nov  5 12:55:12 PST 1996
Subject: Re: [Fwd: Re: Tcl/Tk]
Our port of Tcl can be found at:
ftp://ftp.atd.ucar.edu/pub/vxworks/vx/tclvx7.3.tar.gz
It should contain the full source.
-vince
==========================================================================
=                                         =                              =
=   Vincent Chen                          =   email: vince@rti.com       =
=   Real-Time Innovations, Inc.           =   Phone: (408) 720-8312      =
=   155A Moffett Park Drive, Suite 111    =   Fax:   (408) 734-5009      =
=   Sunnyvale, CA 94089                   =                              =
==========================================================================
From stan@rti.com  Tue Nov  5 15:40:57 1996
From: Stan Schneider <stan@rti.com>
Date: Tue Nov  5 15:40:59 PST 1996
Subject: WRS User's group meeting
Hi all!
Well, the recent thread on the exploder makes this especially relevant...
The 1997 Wind River Users Conference and Exhibition will be held January 13 and
14, 1997 at Techmart, Santa Clara, California.  The proposed agenda is
attached.  Be sure to attend!
There is a considerable change in format this year.  In particular, we are
trying to make the user's group (and Wind River) more responsive to the user's
needs.  For the newer users, there are two much-requested short courses on
VxWorks and Tornado.  For everyone, there will be much less marketing-style WRS
presentations, and more focus-group meetings.  There will also be Q&A sessions
with WRS technical and management panels.
I also think it's time for the user's group to "grow up", draft and adopt a
purpose statement and bylaws and become more independent.  So, we will convene
a steering committee to discuss the organization and format.  If you're
interested in serving on the committee, please drop me an email
(stan@rti.com).
        -- Stan
           stan@rti.com
Agenda at a glance
Moday January 13, 1997
        Pre-conference Training sessions	9:00am to 4:00pm
        Conference opening			4:15pm to 4:30pm
        Keynote address           		4:30pm to 5:00pm
        Welcome reception			5:00pm to 7:00pm
Tuesday January 14, 1997
        Wind River presentations		8:30am to 9:30am
        Breakout sessions			9:30am to 11:00am
        Application stories			11:15am to 12:00pm
        Breakout sessions			1:30pm to 3:00pm
        Corporate question and answer panel     3:00pm to 3:45pm
        Technical question and answer panel     4:00pm to 4:45pm
        Breakout sessions summary and closing   4:45pm to 5:15pm
        Exhibition and reception		5:30pm to 7:30pm
More details:
Users Conference and Exhibition
Santa Clara,  January 13 and 14, 1997
-----------------
Pre-conference training Sessions (Monday January 13, 1997 - 9:00am to 4:00pm)
*Training session #1:   Overview on how to build a BSP.
*Training session #2:   Real-time Multitasking, Semaphores and Intertask
Communication.
These training sessions are for users who have intermediate level of skill
and want to aquire some good expertise in these fields.
Each session is a subset of an existing Wind River training class. We're
offering these high quality, professional classes - worth $500 - to Users
Conference and Exhibition attendees at a greatly reduced rate.
Conference Opening (4:00pm to 5:00pm)
* Opening by Stan Schneider PhD., Conference Chair
Stan was one of the first VxWorks users while at Stanford, and authored many
tools for the VxWorks environment.  Stan is now President of Real-Time
Innovations, Inc.
* Keynote address: Watch this space!
Welcome reception. (from 5:00pm to 7:00pm)
-----------------
Tuesday January 14, 1997
Wind River presentations: ( 8:30am to 9:30am)  * Welcome and introduction
David Larrimore, Vice President of Marketing - Wind River Systems
David Fraser, Vice President of Engineering - Wind River Systems
Breakout sessions: (9:30am to 11:00am, repeated 1:30 to 3:00pm)
Each session offers you a more intimate setting in which to meet with other
users and top Wind River engineers and discuss a single topic in depth. The
four sessions will be repeated after lunch, so you'll have a chance to join two
of the four.
  * BSP Issues
  * Tools
  * Java
  * VxWorks Kernel (configuration, Tornado compatibility, future directions,
    etc.)
Application Stories: (11:15am to 12:00pm)
* Embedded System Virtual Memory with VxWorks presented by Jeff Szczepanski
of Xerox.
An embedded system implementation that uses data compression hardware in
conjunction with virtual memory techniques to extend available RAM space of
a system.
* Tornado for I2O presented by David Wilner, Chief Technical Officer, WRS
Technical design of the I2O standard with emphasis on the IRTOS API and how to
write I2O-compliant drivers.  The basic objective of I2O is to provide an I/O
device driver architecture that is independent of both the specific device
being controlled and the host operating system.
Corporate question and answer panel (from 3:00 to 3:45pm)
Have your questions answered by Wind River top management in an interactive
forum.  Panelists:
David Fraser, Vice President of Engineering
David Larrimore, Vice President of Marketing
Linda Postenrieder, Customer Support Manager
Markus Robinson, Quality Engineering Manager
David Wilner, Chief Technical Officer
Technical question and answer panel:  (4:00 to 4:45pm)
Come prepared to have Wind River's top engineers analyze your technical
issues and answer any technical questions in this interactive session.
John  Fogelin, Chief Technologist
Jose Gonzales, Networking Group Manager
John Hartmann, Tools Group Manager
Kent Long, Runtime Group Manager
Francis Saint Amant, Director, Customer Services
D'Anne Thompson, Senior Development Engineer
David Wilner, Chief Technical Officer
Conference Closing  (4:45pm to 5:15pm)
        * Summary of breakout sessions
        * Closing remarks
Exhibition and reception: (5:15pm to 7:30pm)
Enjoy refreshments while visiting approximately 30 exhibitions by Wind
River Tornado Partners.
From jhend@primenet.com  Tue Nov  5 17:40:14 1996
From: John R Henderson <jhend@primenet.com>
Date: Tue Nov  5 17:40:16 PST 1996
Subject: 5.3 compability 5.2 compability mode
How do you put 5.3 into 5.2 compatibility mode?
        ____________________________
       | John R. Henderson, HMSC    |
       | Hughes Missile Systems Co. |
       | (520) 792-0162             |
       | Email:jhend@primenet.com   |
       |____________________________|
From alexh@eikon.e-technik.tu-muenchen.de  Wed Nov  6 01:46:47 1996
From: Alexander Helmke <alexh@eikon.e-technik.tu-muenchen.de>
Date: Wed Nov  6 01:46:59 PST 1996
Subject: unsubscribe
Hi, Folks!
I need to unsubscribe from the vxWorks Users Group
since I have another acces to the mailings now.
Though it's interesting, I don't want to read everything twice...
Thank you,
Alex
--
************************************************************
Alexander Helmke			Karl-Theodor-Str. 56
+49-89-338690				80803 Muenchen
alexh@eikon.e-technik.tu-muenchen.de	Germany
helmke@lpr.e-technik.tu-muenchen.de
************************************************************
From alexh@eikon.e-technik.tu-muenchen.de  Wed Nov  6 01:47:00 1996
From: Alexander Helmke <alexh@eikon.e-technik.tu-muenchen.de>
Date: Wed Nov  6 01:47:02 PST 1996
Subject: unsubscribe
Hi, Folks!
I need to unsubscribe from the vxWorks Users Group
since I have another acces to the mailings now.
Though it's interesting, I don't want to read everything twice...
Thank you,
Alex
--
************************************************************
Alexander Helmke			Karl-Theodor-Str. 56
+49-89-338690				80803 Muenchen
alexh@eikon.e-technik.tu-muenchen.de	Germany
helmke@lpr.e-technik.tu-muenchen.de
************************************************************
From rasolofo@cenbg.in2p3.fr  Wed Nov  6 02:22:27 1996
From: "H. Rasolofo 399" <rasolofo@cenbg.in2p3.fr>
Date: Wed Nov  6 02:22:30 PST 1996
Subject: unsubscribe
I need to unsubscribe from vxWorks Users Group
regards.
From avlasblo@best.ms.philips.com  Wed Nov  6 03:17:41 1996
From: Arjon Vlasblom <avlasblo@best.ms.philips.com>
Date: Wed Nov  6 03:17:43 PST 1996
Subject: Re: unsubscribe
At 01:47 06-11-96 PST, you wrote:
>
> Submitted-by alexh@eikon.e-technik.tu-muenchen.de  Wed Nov  6 01:47:00 1996
> Submitted-by: Alexander Helmke <alexh@eikon.e-technik.tu-muenchen.de>
>
> Hi, Folks!
>
> I need to unsubscribe from the vxWorks Users Group
> since I have another acces to the mailings now.
>
> Though it's interesting, I don't want to read everything twice...
>
> Thank you,
>
That doesn't mean you also have to send it twice.
Arjon
--                                ////
                                 (0 0)
 _____________________________o00_( )_00o______________________________
/                                                                      \
|  Arjon Vlasblom                     High Tech Automation BV          |
|  voice: +31 499 474725              Ekkersrijt 4006, 5692 DA Son     |
|  fax  : +31 499 474799              The Netherlands                  |
|  email: arjon.vlasblom@hta.nl       http://www.hta.nl                |
|----------------------------------------------------------------------|
|      T H E   E M B E D D E D   S O F T W A R E   C O M P A N Y       |
|----------------------------------------------------------------------|
| Disclaimer: This message does not necessarily reflect the company's  |
|             opinion just my own humble one.                          |
\______________________________________________________________________/
From daemon@csg.lbl.gov  Wed Nov  6 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Wed Nov  6 04:00:26 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Nov  6 04:00:20 PST 1996
        Subject: Re: Virtual to Physical address conversion.
        Subject: Re: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board
        Subject: Does Vxworks(for x86) support a PCI ethernet card.
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Floating Point From ROM
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Sound Card drivers ??
        Subject: Re: Are you happy with Vx Works and Wind River
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Virtual to Physical address conversion.
Date: 4 Nov 1996 17:23:45 GMT
From: tfm@sei.cmu.edu (Theodore Marz)
Organization: The Software Engineering Institute
Message-ID: <55l8r1$hbc@news.sei.cmu.edu>
References: <327E1257.65792670@ccii.co.za>
In article <327E1257.65792670@ccii.co.za>, Casey Crellin <casey@ccii.co.za> writes:
|> Hi,
|>
|> I would like to convert an addrtess from virtual to physical.
|>
|> Similar to the unix ktop() or vtop() functions.
|>
|> How do I do this?
|>
|> I see in the manuals there is a vmContextShow() whose output
|> includes both physical and virtual addresses.
|>
|> I would imagine I owuld use the sysPhysMemDesc[]
|> But how?
|>
|>
|> Thanks
|>
|> Casey
|>
|>
|> --
|> Casey Crellin
|> casey@ccii.co.za
|>
|> CCII Systems (Pty) Ltd
|> -----------------------------------------------------------------------------
Casey,
  This is speaking from a Motorola 68K perspective (mvme-167).
Unless you are running the (add on software) VxVMI, there is no difference
between the logical and physical address.
sysPhysMemDesc addresses how much/where PHYSICAL memory is from a board's
perspective.
If you are using the MMU with VxVMI, then you can create virtual memory
contexts, one of which is the global virtual context.  This context is
inherited by all other virtual contexts and is initialized as being equivalent
to the memory specified in sysPhysMemDesc.
You would create a new virtual context as per the manual, using information in
the system tables to determine where the end of physical memory was / what the
next free virtual address is and create a new virtual memory context.
You can then allocate memory (by the page) and map it into this context.  If
you do not want it accessable to everyone, you have to map it out in the
global virtual context.
VxWorks doesn't give you any help in managing virtual memory contexts or any
help in managing the virtual address space.  It is fairly easy to establish
each task in it's own virtual memory context and protect it in the global
virtual context (except for the stack and the TCB, which have to be writable
for everyone, it has to do with task establishment and context switching).
There is sample context switch hook code that works in the manual.
Need more info? Post again.
Basically, unless you are using VxVMI, or are messing with the MMU yourself,
there is no translation between logical and physical addresses, at least on a
board local point of view.
BTW - it doesn't seem that VxVMI is a terribly popular package.  Or at least,
people just let it run in it's default mode, which makes text segments
read-only in a single (global virtual) context.
Ted Marz
Software Engineering Institute
Carnegie Mellon University
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board
Date: Tue, 05 Nov 1996 11:56:42 +0100
From: Philippe Le Foll <le-f1769@eurobretagne.fr>
Organization: France Telecom Interactive
Message-ID: <327F1D6A.3F3857D2@eurobretagne.fr>
References: <32794C5D.102F27DC@realtime1.com>
NT provide both in version 3.5 and 4.0 an ftp server that accept
anonymous connection, this should fit your requirement, you may
also check for sosnt with is a free implementation of a small
nfs server on NT.
phillf@iu-vannes.fr
Thomas A. Bond wrote:
>
> Hello,
>
>         Is there a protocol available for downloading code to a
> VxWork DEC apha board from a WinNT Intel/DEC based PC?
> The startup code would be downloaded from the WinNT machine to the
> Vxworks DEC aplha board via some boot loader code using some type of
> protocol.  Is there a version of tftp available for WinNT or any other
> viable protocol to accomplish this task?  Thanks!
>
>                                 Tom
>
> --
>       +=============================================================+
>       ||                                                           ||
>       ||                 What the world needs today !              ||
>       ||                                                           ||
>       ||                    //                                     ||
>       ||                   //    // ///// // // // //              ||
>       ||                  //    // // // // //  ///                ||
>       ||                 ///// // // // ///// // //                ||
>       ||                                                           ||
>       ||             The choice of a smarter generation !          ||
>       ||                                                           ||
>       +=============================================================+
---------------------------
Newsgroups: comp.os.vxworks
Subject: Does Vxworks(for x86) support a PCI ethernet card.
Date: Tue, 05 Nov 1996 12:32:42 -0800
From: eric olsen <eolsen@leland.stanford.edu>
Organization: stanford university
Message-ID: <327FA46A.C09DCB@leland.stanford.edu>
Are there any drivers for a PCI ethernet card for the x86 port
of vxworks??? I see that there are 5 or 6 cards supported by
the kernel, are any of them PCI cards, or does anyone have a
driver for a PCI card????
thanks,
- --------------------------------------------------------------
"How can I lose to such an idiot?"
                            Aaron Nimzovich(1886-1935)
 eric olsen
 eolsen@leland.stanford.edu
- --------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Tue, 05 Nov 1996 08:05:57 -0600
From: Steve Woloschek <woloschekS@med.ge.com>
Organization: GE Medical Systems
Message-ID: <327F49C5.69DF@med.ge.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <gerlachE0CtwF.Ju2@netcom.com> <rypma-0411961259040001@hppadhtr1.waterloo.hp.com> <55md5u$5b@idiom.com>
My issue with gnu is due to its lack of support for
ieee695. I have worked with the 2.6 release from Cygnus
for a win32 host.
This version of the linker provides a.out-sunos-big and
theoritically it supports srec, symbolsrec and binary.
None of the BDM's or ICE's that we have support a.out. They use
ieee695 or srecord. The GNU linker core dumped anytime I tried
to use any other format besides a.out. objcopy was no better.
I downloaded the 2.7 version from the web for a unix host and configured
for iee695. Guess what, it only provided global debug information.
(no local symbols or file information) Again, not very useful.
And again certain options core dumped the linker and objcopy.
I tried coff format also with no luck.
I have used MRI before, and at least the tools did not crash when
using certain options.
If you can use a.out it probably works great. Or if you could spend
the time to debug and fix the tools it is probably ok. I needed
ieee695 support which gnu did not support well. Maybe things have
changed.
Just my .02 worth,
Steve Woloschek
H.J. Bae wrote:
>
> GNU toolchain certainly works better than any other
> cross-deveopment tools I've used, including pSOS with
> MRI tools.  Have you actually used those tools?
> You can't be serious.
>
> http://peacefulstar.oakland.ca.us
> mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Tue, 5 Nov 1996 12:41:33 GMT
From: valentin@netcom.com (Valentin Pepelea)
Organization: Netcom Communications, Santa Clara, CA
Message-ID: <valentinE0EDx9.Hzu@netcom.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com>
Sender: valentin@netcom11.netcom.com
In article <327E0DB7.6513@med.ge.com> Steve Woloschek <woloschekS@med.ge.com> writes:
>I second Steve's comments. But most of my problems stem
>from the fact that WRS uses GNU tools. IMOH, this is a real
>downfall. I have had many problems with these tools and
>getting support through WRS for GNU problems is impossible.
>Even though the salesman said it would not be an issue, since
>Cygnus was great about problems! Ya right!
I am quite surprized by your statement. I have found the GNU tool chain to
be very reliable. A little less featurefull than the opposition in regard to
embedded systems, but more reliable in the fewer features that are provided.
Perhaps the difficulties you encountered are caused by the fact that you used
a WRS intermediary rather than purchasing support from, and talking directly
to, Cygnus Support. An intermediary who does not fully understand your problem
always filters away essential elements.
I have dealt with four compiler houses in the recent past: Diab Data for
PPC, Green Hills for PPC, Microtec for 68K and GNU (Cygnus) for 68K and Sparc.
The best support by far came from Diab Data. My problem report seemed to have
reached the actual code writer instantanously, and the answer was right on the
mark. Microtec support always went through a customer support intermediary,
but the correct answer always came within 2 days. Our Cygnus support was
through e-mail only, and also provided correct answers within 2 days.
If you use pSOS, you have to go through ISI when having problems with Green
Hill's Multi development system. I was lucky to be contracting at ISI when
I ran into problems, so I could just walk down the hall to get answers, but
the experience of going through an intermediary still seemed unpleasant.
>If I were to do it again I would pick pSOS.
There are many good reasons to pick pSOS. But this is not necessarely one of
them. May I suggest Microtec tools? I still own some rapidly-dwindling stock
in its parent company. :-)
Valentin
- --
"An operating system without virtual memory      Valentin Pepelea
 is an operating system without virtue."         Embedded Sytems Consultant
                                                 (415) 346-7105
                     - Ancient Inca Proverb      valentin@netcom.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Floating Point From ROM
Date: 3 Nov 1996 18:26:01 GMT
From: "Robin Smith" <rob@robin-smith.prestel.co.uk>
Organization: [not set]
Message-ID: <01bbc9b4$6e2d9d40$dc4698c2@prsf56re.prestel.co.uk>
We are using VxWorks 5.1.1 under Rational Ada and are having problems with
floating point when blowing an app into ROM.  It works fine when built as a
RAM image but the same floating point call (any of sin/cos/sqrt) causes the
task to terminate.
Can any body help?
Thanks
Robin
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 96 04:18:28 GMT
From: nobody@nowhere
Organization: A poorly-installed InterNetNews site
Message-ID: <55p3f1$rcg@idiom.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <gerlachE0CtwF.Ju2@netcom.com> <rypma-0411961259040001@hppadhtr1.waterloo.hp.com> <55md5u$5b@idiom.com> <327F49C5.69DF@med.ge.com>
Microtech compilers do have nice IEEE695 (or whatever) output,
which current GNU toolchains lack.  However, GNU can produce
a.out, COFF, ELF, etc. as well, unlike Microtech.  If the leverage
MRI compilers have over GNU is due to their historical support
of IEEE formats, this alone doesn't put WRS in the wrong position
for supporting GNU -- after all, it is easy to put in a bfd backend
that will handle IEEE formats; it's just that nobody has done it
yet.  The architecture of the GNU toolchain is superior.
I'm not suggesting that GNU is the ultimate solution, just that
it is a good toolchain for a lot of useful work.  Bashing WRS
for going with GNU tools instead of MRI tools seem unfair.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Sound Card drivers ??
Date: Mon, 04 Nov 1996 11:18:48 -0800
From: Pete Barrie <peter@cs.strath.ac.uk>
Organization: Comp. Sci. Dept., Strathclyde University, Glasgow, Scotland.
Message-ID: <327E4198.2163@cs.strath.ac.uk>
I need to write (or get hold of ) hardware-level info
on Soundblaster-16 so I can write some sound-sampling,
playback and simple FM synthesis code for VxWorks '486
platform in an educational application for disabled
users. Has anybody already written some code or have any
ideas on this one ?
Pete Barrie
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 5 Nov 1996 19:45:10 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <55p1k6$24c@elaine25.Stanford.EDU>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com>
In article <327E0DB7.6513@med.ge.com>,
Steve Woloschek  <woloschekS@med.ge.com> wrote:
>I second Steve's comments. But most of my problems stem
>from the fact that WRS uses GNU tools. IMOH, this is a real
                    ^^^^^^^^^^^^^^^^^^
Most people I know consider this a major plus because they
can leverage off their experience with GNU tools, use the
same compiler for front end host software, and have a high
degree of portability to other targets. Personally, the only
time I had a problem with the GNU stuff was when it incorrectly
generated floating point code for a particular processor.
We sent a bug report to GNU people (not WRS) and somebody sent
us a fix within a week. This was a couple years ago.
A while back I read that the GNU compiler was the most widely
used compiler in the embedded industry. I think WRS made the
right choice going with GNU.
>downfall. I have had many problems with these tools and
>getting support through WRS for GNU problems is impossible.
Support has been very good for me when I needed it.
>Even though the salesman said it would not be an issue, since
>Cygnus was great about problems! Ya right!
>
>If I were to do it again I would pick pSOS
It would be nice if people posted more specifics about the
problems they were having with WRS and VxWorks instead of
just bitching and moaning. Personally, I would like to know
about any potential problems. A lot of the complaints seem
more related to people having problems converting from
pSOS to VxWorks.
The most valid complaints seem to come from the Windoze users.
In this case, you all have my sympathy because WRS is heavily
UNIX biased. I'd expect the Windoze version to be shaky since
it is brand new.
Just my 0.02 cents.
---------------------------
End of New-News digest
**********************
From @positron.CTI-PET.COM:wittner%pcmail.cti-pet.com@cti-pet.com  Wed Nov  6 05:57:08 1996
From: Eli Wittner <wittner%pcmail.cti-pet.com@cti-pet.com>
Date: Wed Nov  6 05:57:10 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
Text item: Text_1
     To all:
        It is interesting that no one has mentioned that WindRiver requires
     one to buy Tornado to keep current with VxWorks.  That is, you cannot
     move to v5.3 without buying Tornado.  Further, we have been told that
     our substantial standard yearly maintenance fee (for which we have
     received minimal "upgrades" and even poorer technical support) does
     not apply, and we would have to pay a large one-time fee to "upgrade"
     to Tornado and v5.3.  Couple this with all the negative comments
     regarding the unreliability and bugginess of the product and it is
     easy to see why we are hesitant to move to Torrnado.
        On the positive side, I will agree with those who say vxWorks is a
     robust RTOS that will perform a majority, if not all, of the real-time
     tasks most of us need.  There are still a few features we use that are
     not easily duplicated by competing OS's.  It is for this reason that
     we will probably continue to use VxWorks (sans Tornado) on our current
     project, although we will continue to evaluate competing OS's on all
     new projects.
     Cheers -- Eli Wittner
     CTI Cyclotron Systems, Inc.                423-966-0072 x411 Voice
     810 Innovation Dr.                         423-966-8955      FAX
     Knoxville, TN 37932                        wittner@cti-pet.com
From dorlic@gte.net  Wed Nov  6 06:38:36 1996
From: "Dan H. Orlic" <dorlic@gte.net>
Date: Wed Nov  6 06:38:38 PST 1996
Subject: two questions...
hiya folks,
Does anyone know if VxWorks 5.2 supports password encryption?
and ...
Why in the world doesn't V5.2 have "cret"?
Thanks,
Dan Orlic
Electrospace systems
Richardson, texas
From han2326@aminet.co.kr  Wed Nov  6 07:18:58 1996
From: "Han, Jeong Soo" <han2326@aminet.co.kr>
Date: Wed Nov  6 07:19:00 PST 1996
Subject: Q:vxWorks_rom.hex on the PEP VSBC4(VIUC) board
Hi,
Does anyone have experience like my problem on the PEP VSBC4[VIUC] board
?
I use vxWorks 5.2 & solaris 2.4 platform.
My problem is ;
  I have implemented multiprocessing system using shared memory(1Mb) on
  the PEP VM30.
  The VSBC4[VIUC] board have only 1MB SRAM of main memory.(no DRAM)
  In the developing stage to download with ethernet board,
  my application program is well running. But, the rommable
  image(vxWorks_rom.hex: size 350 KB) is not running. I used total 1MB
  ROM(4Mbit x 2).
  To find out whether or not make error, I have exclude some objects to
  reduce the size of rommable image from 350KB to 250KB with same make
  process and have tested it using total 256 KB(1Mbit x 2). The result is
  that the reduced image is well operating.
  The VSBC4[VIUC] board manual is written that the board support up to
  2MB.
  Someone adviced to me that the copies from ROM to RAM in the booting
  sequence of the bootable image is not a real image size(350 KB ~ 500
  KB), but the total size of ROM and then I have to use total 256 KB ~
  512 KB ROM instead of 1MB ROM in the 1MB main memory board.
Is it true ?  I did't believe it.
How can I implement the bootable system to my all program ?
I am not available 2Mbit ROM immediately.
Any hints or helps would be appreciated.
Thanks,
J.S.Han
From Michael.Wenzel@med.siemens.de  Wed Nov  6 09:42:56 1996
From: Michael Wenzel <Michael.Wenzel@med.siemens.de>
Date: Wed Nov  6 09:42:58 PST 1996
Subject: VxWorks Help !
Dear Ladies and Gentleman,
We are using a FORCE SYS68K/CPU-30 Board with a running
VxWorks Version 5.1.1 . This CPU is conncted a
VME BUS via a SCSI II Controller to a SEAGATE ST32550N
Disk (2.1 GByte).
Now, we would like to use a defracmentation or squezze
command for the disk, but the VxWorks dose not have one.
How could we implement such kind of an command into our
system or dose one already exist ?
Many thnaks in advance for yor help and assistance.
Best Regrads,
Michael Wenzel
From beeman1@llnl.gov  Wed Nov  6 09:57:31 1996
From: Bart Beeman <beeman1@llnl.gov>
Date: Wed Nov  6 09:57:34 PST 1996
Subject: Shared memory?
Hi all,
I am new to vxWorks and RTOS in general so please excuse this (hopefully)
simple question. I have a motorolla MVME162 in a system with a sparc as the
backplane master, there is also a mercury processor with it's own real time
processes. The mercury is to provide update data I need for the 162 real
time controll process (fast steering mirror). Ideally I would set up a
large portion of memory to be shared for passing the 162 control block as
well as a data circular buffer. However when reading through the config.h
of the 162 there is a comment stating that only the backplane master (in
this case not the 162) has it's RAM dual-ported onto the VME bus. I very
much would like to pass at least 2 data words to the 162 as quickly as
possible as not to loose sync of the mercury with it's systems. Seems the
best way is to write directly to the 162 ram, is this possible?  If the 162
ram cannot be mapped to the vme bus can I at least get to the ram of the
other processors?
I saw mention of mailboxes in the config.h file as well, what are these? I
can't seem to find any more info on them. Perhaps I could use them for my
control block and then a socket for the less critical circ. buffer?
Thanks for the help
Bart
Bart Beeman
Lawrence Livermore National Laboratory
beeman1@llnl.gov
(510) 422-5938 voice
From burt@xylan.com  Wed Nov  6 14:30:51 1996
From: burt@xylan.com (Burt Cyr)
Date: Wed Nov  6 14:30:53 PST 1996
Subject: Re:  two questions...
==================================================================
    v  _                                 Xylan, Inc.
  ____(_)___    Burt Cyr                 26679 Agoura Rd. Suite 100
  _-_-__-_-_-_    burt@xylan.com         Calabasas, CA 91302
  --_-_--_-_-                            (818) 878-4533
==================================================================
From adler@bnlku5.phy.bnl.gov  Wed Nov  6 18:49:03 1996
From: Stephen Adler <adler@bnlku5.phy.bnl.gov>
Date: Wed Nov  6 18:49:05 PST 1996
I just got myself an mvme1306 and I'm soon to get an MPMC202 which
is a fast ethernet pmc card which will plug into the mvme1306.
Has anyone worked with this combo before? When I ordered the
pair, some how I got the notion that there was a vxworks driver
for the mpmc202 but when I talked to WRS people, they were
quick to reply that they had no driver for this board. So,
anyone out their with an mpmc202 driver?
Steve Adler.
From daemon@csg.lbl.gov  Thu Nov  7 04:00:23 1996
From: daemon@csg.lbl.gov
Date: Thu Nov  7 04:00:26 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Nov  7 04:00:21 PST 1996
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Task stuck when trying to open file on the harddisk
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: HELP: How to get useful debug info out of an NMI interrupt?
        Subject: Re: HELP: How to get useful debug info out of an NMI interrupt?
        Subject: Re: Software Archives
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: causing a task switch
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 1996 06:36:00 GMT
From: sgaeke@cris.com (Steve Gaeke)
Organization: Concentric Internet Services
Message-ID: <55p19f$ju4@herald.concentric.net>
References: <9611052007.AA27240@wgsu13.kns.com>
jdeangcd@eng.kns.com (Joe DeAngelo) wrote:
>Jim Jaskol wrote:
>>     How is the development environment?
>>     How good is the support from Wind River?
>>     Are there lots of board support packages?
>>     Are the board support packages of high quality?
>I've got to agree with Mike Anderson. VxWorks is technically a very nice
>product, when you look at the product, the kernel. The development tools
>are not the fanciest, but they are robust and work on robust platforms, and
>are the up to the state of the industry for embedded systems. There is a VERY
>strong Board Support Package presence.
Maybe the development tools under UNIX but not Windows.
>Service from WRS, however, has been disappointing to me. And it is not limited
>to the technical expertise of the service reps. There are administrative
>problems, where although on support contract, upgrades for supported
>components are very difficult to get in a timely fashion, particularly for
>those components provided through WRS from a third party. Even quotes from
>their sales people seem to be difficult to get!
>As far as Tornado is concerned, there are a few very nice technical improvements
>but basically is seems to me as far as the kernel is concerned, that its just
>a minor upgrade. I don't have experience with Tornado, and may NEVER have it
>because I've been waiting for a quote from the sales guy for over a month.
>Joe DeAngelo
Although I am admittedly a novice, my impressions is that Tornado is
not a minor upgrade and was rushed to market, especially for the host
tools on x86.  We still do not have a released Windview and
Stethoscope for the 95/NT host even though these were suppose to
materialize much earlier this year.  The TCL language is currently
only documented for UNIX hosts (NO Windows examples or libraries) and
I don't believe any of the GUI additions are supported under x86 (see
appendix F I believe of the TCL API).  Your suggestion of building the
embedded shell makes sense except now you don't have any Tornado tools
since they rely heavily on a host based symbol table and there is
currently no way to synchronize or re-build one from a targeted shell.
Someone else made a point of real-time.  Try running your tornado
tools while your target is running.  It is _very_ intrusive.  I
believe we are ripped away by the WDB agent during intial
communication on the order of 100ms.  We are hoping the next release
will fix many of these problems.
I agree there is no perfect RTOS / Tool suite out there, but when you
pay for technical support and you are told to check the news groups
for help, there is something seriously wrong.  I have gotten this
answer many times.  It will probably continue to be a bumpy ride,  but
in the end, I think WRS will pull it together.  It's just right now
they lack adequate responsive support.
*** I would still like to hear any comparisions from the pSOS people,
especially for x86 targets and W95/NT hosts.
steve.
#########################################################
The opinions expressed are my own and do not reflect the opions of my
employer.
#########################################################
---------------------------
Newsgroups: comp.os.vxworks
Subject: Task stuck when trying to open file on the harddisk
Date: Wed, 06 Nov 1996 12:05:25 +0200
From: Dani Gutzeit <gdani@ksl.co.il>
Organization: NetVision LTD.
Message-ID: <328062E5.41C67EA6@ksl.co.il>
We upgraded our VxWorks version from 5.1 to 5.2
 Now sometimes we have a problem when trying to open ( for write )
 a file on harddisk.
 The task is stuck with following stack:
- -> tt 0xaea324
  a240 _vxTaskEntry   +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
38b1a2 _x_main        +358: 38aaac (9c7de0)
38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078)
d968fe _XtDispatchEvent+4a : d9667e (aea078)
d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc)
d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00,
c1db10, 8])
daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8,
aea078])
daf830 __XtMatchAtom  +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8])
daf0de __XtMatchAtom  +292: df3ea8 (c117c8, aea078, 0, ac7fb0)
df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0,
ae9ed8])
df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94,
ae9e80, c117fc, 0])
d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80)
4a8000 _diepSaveCB    +8a : _Save_Die_Parameters (a405c4, 565f6c)
a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4)
a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0)
a17858 _dbSaveObject  +1c : _dbFopen (ae9bdc, ae9c16, a1783a)
a177d2 _dbFopen       +10 : _fopen (ae9c16, a1783a)
  c218 _fopen         +34 : _open (ae9c16, 601, 1b6)
 28fce _open          +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6)
 29ce4 _iosOpen       +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16])
 570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5])
 540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90)
 55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4)
 54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c)
 28c2c _hashTblRemove +5c : _sllPrevious (f71590)
 The task status is READY.
Can anybody help?
Thanks
Dani
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 1996 08:38:57 -0800
From: Michael Levasseur <levass@gdesystems.com>
Organization: GDE Systems Inc.
Message-ID: <3280BF21.41C67EA6@gdesystems.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <55p1k6$24c@elaine25.Stanford.EDU>
Notice anything perculur? There is this long indepth thread
and not a single post from Wind River!!!! Don't Wind River's
people look at the net. Aren't they in the 90's or are they still
working in a vacuum.
I've had other issues with Board manufacturers, compiler venders
and application venders and usually when I've posted discussions
on the net I've gotten their $.02 worth. I've even gotten calls
from some of those companies when I flamed them.
I use the news groups to solve and discuss many complex issues and
I'm totally suprised that no Wind River people have commented.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 6 Nov 1996 15:33:28 GMT
From: gerlach@netcom.com (Matthew H. Gerlach)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Message-ID: <gerlachE0GGJt.8n1@netcom.com>
References: <rypma-0411961259040001@hppadhtr1.waterloo.hp.com> <55md5u$5b@idiom.com> <327F49C5.69DF@med.ge.com>
Sender: gerlach@netcom23.netcom.com
In article <327F49C5.69DF@med.ge.com> Steve Woloschek <woloschekS@med.ge.com> writes:
>My issue with gnu is due to its lack of support for
>ieee695. I have worked with the 2.6 release from Cygnus
>for a win32 host.
>
I think this question comes up a lot; it might even be in the faq.
I ran into the same problem bringing up a non-VxWorks i960 board.  I
used coff format, but the ICE wanted ieee.  The GNU tool chain for
i960's from intel contain a tool to generate iee suitable for many ices.
Matthew
---------------------------
Newsgroups: comp.os.vxworks
Subject: HELP: How to get useful debug info out of an NMI interrupt?
Date: Wed, 06 Nov 1996 09:54:57 -0500
From: Yamudda Wezamibootz <neilr@inigo.us.dg.com>
Organization: Data General Corporation, Westboro, MA
Message-ID: <3280A6C0.77A2@inigo.us.dg.com>
(Yes, I've tried to find help in the manuals.)
The reason I ask is, I'm working on some custom hardware that's prone to
bus hangs, and don't have ready access to an ICE.  I managed to talk the
hardware folks into making the board do an NMI on a bus timeout.
I figured, at the NMI, I could gather some state, and then spit it out
on the serial port.  But it's not working.  So I need to debug my debug
routine.
I'd also like to know what task got interrupted, since this would be the
task that hung the bus.  Then maybe I could force a GPF on the task, and
get some info from the GPF message.
Oh, and when this happens, I lose network connectivity, and my shell on
the serial port will echo keystrokes and spit occasional messages, but
nothing else.  The whole kernel seems comatose, as if crucial system
tasks have gone south.  (Why, oh why, is the WDB target server
implemented as a task?  Just so it can crash when I need it most?)
Any thoughts out there?  Thanks.
(Running vxWorks 5.3 on a 386EX.  Host is Tornado 1.0 on NT 3.51.  WDB
is RPC over ethernet.)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: HELP: How to get useful debug info out of an NMI interrupt?
Date: 6 Nov 1996 22:26:57 GMT
From: malloryc@aol.com
Organization: America Online, Inc. (1-800-827-6364) (1.10)
Message-ID: <19961106222900.RAA24854@ladder01.news.aol.com>
References: <3280A6C0.77A2@inigo.us.dg.com>
Sender: news@aol.com
Use a logic analyzer with a preprocessor for state disassembly. The newer
logic analyzer are also C source aware.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Software Archives
Date: Wed, 06 Nov 1996 15:02:55 -0800
From: Frank Weissig <faw@teleport.com>
Organization: Teleport - Portland's Public Access (503) 220-1016
Message-ID: <3281191F.78B4@teleport.com>
References: <32767112.7636E565@leland.stanford.edu>
Reply-To: faw@teleport.com
eric olsen wrote:
>
> I understand that there is an archive containing publically
> available libraries, etc for vxworks.
> I am looking for a port of the curses library(to the pc platform).
>
> Where is this archive located??????
>
ftp://ftp.atd.ucar.edu/pub/vxworks/vx/
- --
Frank Weissig
Senior Staff Engineer
STEP Technology, Inc.
frank@steptech.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 1996 21:05:41 -0700
From: Wes Peters <softweyr@xmission.com>
Organization: Softweyr LLC
Message-ID: <32816014.71D@xmission.com>
References: <9611051610.AA27410@worf.dvg.com>
Reply-To: softweyr@xmission.com
Douglas Davies wrote:
> I hope that the Wind River folks are paying attention to this thread
> and several other recent threads; ie. C++ compiler support, C++ I/O
> streams support/pricing, GNU tool quality/support, etc.
With respect to this, which compiler(s) are you using?  We have used
GCC,
first 2.6.1 then 2.7.2, very successfully.  My partner-in-crime and I
developed an 85,000-line custom C++ system this year using GCC for C++
on VxWorks 5.2; we experienced no significant problems with the system
or the tools.  We do not use iostreams as they are far too large for the
high-speed i/o requirements of our system, but I imagine the GNU libg++
could be ported to VxWorks.
> IMHO you have some substantial quality and pricing issues to address...
I haven't experienced any problems with the VxWorks kernel on M68000
platform.  I haven't used Tornado yet, and don't really expect too in
the
future; the systems I'm working on are not memory bound, and the new
systems
use easily expanded SIMM memory.
> I have been using VxWorks for almost 8 years now.  In the beginning,
> I was very impressed with the quality, etc..  That however changed
> with the "slick" marketing and exorbitant pricing of tornado.
Have any of your recent experiences changed your mind about the VxWorks
kernel itself, or just the mis-features of Tornado?
> In short, I am no longer impressed...  And you can bet that I will be
> investigating other RTOS options before we begin any new development.
- ---
             "Where am I, and what am I doing in this handbasket?"
Wes Peters
Softweyr LLC
softweyr@xmission.com
http://www.xmission.com/~softweyr
---------------------------
Newsgroups: comp.os.vxworks
Subject: causing a task switch
Date: Wed, 06 Nov 1996 23:17:53 -0800
From: Todd Hoff <tmh@possibility.com>
Organization: Possibility Outpost
Message-ID: <32818D21.390B@possibility.com>
Reply-To: tmh@possibility.com
For our system integrity system we have a task that
periodically wakes up our agents to cause a task switch.
If a task has not switched in a certain period of time it
is assumed dead. For agents this is easy because all
agent's block on a semaphore which i can just give.
For tasks i'm not sure how to make them perform a task switch in
a general fashion. None of the task library methods
seem appropriate. taskDelay works on the current task.
suspending and resuming a task is risky and i'm not sure
it would do what i want anyway. Any ideas?
Thanx
- -------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell
---------------------------
End of New-News digest
**********************
From 100656.1507@CompuServe.COM  Thu Nov  7 06:02:13 1996
From: John Shaw <100656.1507@CompuServe.COM>
Date: Thu Nov  7 06:02:20 PST 1996
Subject: Re: two questions
>Subject: two questions...
>Submitted-by dorlic@gte.net  Wed Nov  6 06:38:36 1996
>Submitted-by: "Dan H. Orlic" <dorlic@gte.net>
>hiya folks,
>Does anyone know if VxWorks 5.2 supports password encryption?
Hi Dan,
Yup is the answer to your first question. But you must add INCLUDE_SECURITY in
either bsp/config.h or vw/config/all/configAll.h.... There is a slight problem
with that
though, if the option is included... remote logins become secure and require
users
to enter a name and password.... with a few mods to vw/config/all/usrConfig.c
you
can make this feature optional. The way I have accomplished this is shown
below:-
	#ifdef INCLUDE_SHELL
	#ifdef INCLUDE_SECURITY
	loginInit ();
	if ((sysFlags & SYSFLG_NO_SECURITY) == 0)
	{
		shellLoginInstall (loginPrompt, NULL);
		loginAddUser (LOGIN_USER_NAME, LOGIN_PASSWORD);
	}
	#endif INCLUDE_SECURITY
The boot parameter flag for a processor should have 0x20 set to disable remote
login password entry.
Application code should include loginLib.h to access a few functions. The most
important is loginDefaultEncrypt (char * in, char * out). You supply a string
that
holds a readable password (in) and the function will encrypt this (out). You can
then compare the encryption with a known password encryption. There is also
a UNIX binary in vw/bin/sun4/vxencrypt that, when run, requests a non-echoed
password and outputs the encrypted password to stdout.
I suspect that the encryption algorithm is NOT one that could be used on really
secure systems. Only WRS know. You can supply your own encryption function
via a call to loginEncryptInstall ().
Hope this helps.
John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK.
100656.1507@compuserve.com
From mea@mclean.sparta.com  Thu Nov  7 06:59:46 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Thu Nov  7 06:59:48 PST 1996
Subject: Re: causing a task switch
At 04:00 AM 11/7/96 PST, you wrote:
>Subject: causing a task switch
>Date: Wed, 06 Nov 1996 23:17:53 -0800
>From: Todd Hoff <tmh@possibility.com>
>Organization: Possibility Outpost
>Message-ID: <32818D21.390B@possibility.com>
>Reply-To: tmh@possibility.com
>
>For our system integrity system we have a task that
>periodically wakes up our agents to cause a task switch.
>If a task has not switched in a certain period of time it
>is assumed dead. For agents this is easy because all
>agent's block on a semaphore which i can just give.
>For tasks i'm not sure how to make them perform a task switch in
>a general fashion. None of the task library methods
>seem appropriate. taskDelay works on the current task.
>suspending and resuming a task is risky and i'm not sure
>it would do what i want anyway. Any ideas?
>
Greetings!
  First, you can do a taskDelay(0) in your respective tasks to force them
to give up the CPU without incurring any actual delay.  But, another approach
would be to have your manager task wake up (at a relatively high priority) and
adjust the priority of the task you want to awaken up above the rest of
the "managed" tasks and then do a taskDelay in the manager task.  If that
newly elevated task is the highest priority ready to run, then it will be
switched in and it will execute.  Make sure that the manager task is a
higher priority than the newly elevated task so when the taskDelay expires,
the manager takes over the CPU and can adjust the priorities again.
  There are other actions that can case a context switch though (to the
"pended" state rather than the "delayed" state).  Things like semGives
and semTakes of already available semaphores can also cause these context
switches (but these *will* incur some delay over and above the raw context
switch time).
HTH,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From MikeMcQuade@connect.com  Thu Nov  7 07:33:02 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Nov  7 07:33:05 PST 1996
Subject: Re:
At 06:49 PM 11/6/96 PST, you wrote:
>Submitted-by adler@bnlku5.phy.bnl.gov  Wed Nov  6 18:49:03 1996
>Submitted-by: Stephen Adler <adler@bnlku5.phy.bnl.gov>
>
>
>I just got myself an mvme1306 and I'm soon to get an MPMC202 which
>is a fast ethernet pmc card which will plug into the mvme1306.
>Has anyone worked with this combo before? When I ordered the
>pair, some how I got the notion that there was a vxworks driver
>for the mpmc202 but when I talked to WRS people, they were
>quick to reply that they had no driver for this board. So,
>anyone out their with an mpmc202 driver?
>
I believe that this card is the same as a RNS 2300, if thats the case, Ross
Micro Systems
has a driver, Ive been using a 2300 (100 Base-Tx) board with Ross's driver.
The driver works good, the installation was easy, the documentation is very
complete, and their
support is excellent.
Mike.
MikeMcQuade@connect.com
From burns.pentek.com!tkl@pentek.com  Thu Nov  7 08:01:31 1996
From: tkl@burns.pentek.com (Terry K. Lim)
Date: Thu Nov  7 08:01:33 PST 1996
Subject: MPMC-202 Driver
> I just got myself an mvme1306 and I'm soon to get an MPMC202 which
> is a fast ethernet pmc card which will plug into the mvme1306.
> Has anyone worked with this combo before? When I ordered the
> pair, some how I got the notion that there was a vxworks driver
> for the mpmc202 but when I talked to WRS people, they were
> quick to reply that they had no driver for this board. So,
> anyone out their with an mpmc202 driver?
>
> Steve Adler.
A Wind River sales person told me that they have a driver for the DEC
21140 chip that is on the MPMC-202, but not a port to the MPMC-202.
--
Terry Lim                          |   Voice: (201) 818-5900
Director of Software Engineering   |   FAX:   (201) 818-5941
Pentek, Inc.                       |   WWW:   http://www.pentek.com
From tmorris@me.umn.edu  Thu Nov  7 08:25:48 1996
From: "Ted Morris" <tmorris@me.umn.edu>
Date: Thu Nov  7 08:25:50 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
Ditto.
>
> Text item: Text_1
>
>      To all:
>
>         It is interesting that no one has mentioned that WindRiver requires
>      one to buy Tornado to keep current with VxWorks.  That is, you cannot
>      move to v5.3 without buying Tornado.  Further, we have been told that
>      our substantial standard yearly maintenance fee (for which we have
>      received minimal "upgrades" and even poorer technical support) does
>      not apply, and we would have to pay a large one-time fee to "upgrade"
>      to Tornado and v5.3.  Couple this with all the negative comments
>      regarding the unreliability and bugginess of the product and it is
>      easy to see why we are hesitant to move to Torrnado.
>
>         On the positive side, I will agree with those who say vxWorks is a
>      robust RTOS that will perform a majority, if not all, of the real-time
>      tasks most of us need.  There are still a few features we use that are
>      not easily duplicated by competing OS's.  It is for this reason that
>      we will probably continue to use VxWorks (sans Tornado) on our current
>      project, although we will continue to evaluate competing OS's on all
>      new projects.
>
>      Cheers -- Eli Wittner
>
>      CTI Cyclotron Systems, Inc.                423-966-0072 x411 Voice
>      810 Innovation Dr.                         423-966-8955      FAX
>      Knoxville, TN 37932                        wittner@cti-pet.com
>
>
> **********
>
Ted Morris           "WWW = World Wide Wait"
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884
From tmorris@me.umn.edu  Thu Nov  7 09:49:00 1996
From: "Ted Morris" <tmorris@me.umn.edu>
Date: Thu Nov  7 09:49:03 PST 1996
Subject: A good book...
Howdy all,
I would like to know if any of you out in the ether could recommend a
decent text book appropriate for Junior/Senior level engineering
students that covers basic concepts in real-time programming and
operating systems.  The book should offer simple excersises and/or
examples if possible.  But first here's some relevant background:
******
We will be offering new controls class starting this Winter (Jan-1)
for undergraduate engineering students that requires them to use
VxWorks.  We will be using VxSIM as a teaching tool for them to
explore implimenting various control stategies in a real-time
programming environment.  Essentially, we already have real-time
simulators of various kinds of sensors and dynamic plants that model
the actual devices quite accurately.
When each student feels confident that their control algorithms work,
their tasks are recompiled and tried on the real devices.
Note that unforntunately the current course prerequisites follow a
very arcane, outdated protocol which does not even require students to
have any background in C/C++.  Most are familiar with UNIX.  Basic
Linear Controls, Dynamic Systems, and FORTRAN programming are the only
requirements.  *****
thanks in advance!
Ted
Ted Morris
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884
From stan@rti.com  Thu Nov  7 11:51:12 1996
From: Stan Schneider <stan@rti.com>
Date: Thu Nov  7 11:51:14 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
>> Date: Wed, 06 Nov 1996 06:36:00 GMT
>> From: sgaeke@cris.com (Steve Gaeke)
>> We still do not have a released Windview and Stethoscope for the 95/NT
>> host even though these were suppose to materialize much earlier this
>> year.
StethoScope for 95/NT on Tornado has been released since last Spring; we're
sorry if you somehow got mixed up.  We have an update release that went FCS
late last month.  This will be available from WRS this month; if you're on
maintenance, you should get it.  If you're in a bigger hurry, you can send your
license info to "info@rti.com"; we'll set you up to download it from our (new)
web-based shipping system today.
>> Your suggestion of building the embedded shell makes sense except now
>> you don't have any Tornado tools since they rely heavily on a host based
>> symbol table and there is currently no way to synchronize or re-build
>> one from a targeted shell.
There are several solutions.  Leonid posted an unsuppored free TCL script &
target module that coordinates the host and target symbol tables after a load;
you can get it from his web site (www.rst.co.il).  We have added a "target
server server" that serves the host-based symbols back to the target to RTILib
(free with StethoScope).  With it, your target can utilize the host-based
symbol functions such as symLib and ldLib.  One of these should work for you
until WRS addresses the issue.
>> Try running your tornado tools while your target is running.  It is
>> _very_ intrusive.  I believe we are ripped away by the WDB agent during
>> intial communication on the order of 100ms.
Part of this is probably because you're running tWdbtask at its default very
high priority.  Try lowering it below your critical tasks.  WRS ships it at
high priority because it's more foolproof that way (harder for users to lock it
out with their own task), but it's not great for real-time response.  The
target-based shell has (had?) the same issue.
        -- Stan
=============================================================================
=                                           =                               =
=   Stan Schneider                          =   email: stan@rti.com         =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312 x104  =
=   155A Moffett Park Drive, Suite 111      =   Fax:   (408) 734-5009       =
=   Sunnyvale, CA 94089                     =   http://www.rti.com          =
=                                           =                               =
=============================================================================
From MikeMcQuade@connect.com  Thu Nov  7 14:44:59 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Nov  7 14:45:02 PST 1996
Subject: Testing a location over the VME bus.
I have a question, in the application Im working on, I need
to be able to determine the number of cards available.
Since some configurations have only two cards, and other
units may have four, Im stuck having to probe addresses
to see if a given card is available.
Im using both MVME-1603 and 1604 boards, on the 1603, I can
access addresses where there is no hardware, this returns
garbage, but on the 604, if I try to access an address where
there is no hardware, I get an exception.
Any ideas why the 604 generates an exception, and the 603 doesn't ?
Any suggestions on how to test if a board is available ?
Thanks in advance.
MikeMcQuade@connect.com
From wbrown@csg.lbl.gov  Thu Nov  7 15:05:01 1996
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Thu Nov  7 15:05:03 PST 1996
Subject: Re: Testing a location over the VME bus.
What about using vxMemProbe( )?
Disclaimer:  Any opinions are my own and have	    |  -bill
    nothing to do with the official policy or the   |   wlbrown@lbl.gov
    management of L.B.L, who probably couldn't      |   Berkeley, CA
    care less about employees who play with trains. |   aka wlbrown@netcom.com
From Edward_D._Shober@dvg.com  Thu Nov  7 15:41:50 1996
From: Edward_D._Shober@utsci.com (Edward D. Shober)
Date: Thu Nov  7 15:41:53 PST 1996
Subject: Re: 5.3 compability 5.2 compability mode
>How do you put 5.3 into 5.2 compatibility mode?
When I ported our 5.2 BSPs to 5.3 the only real trick I
remember having to do was to #define INCLUDE_TYCODRV_5_2
in config.h.
Good luck,
Ed (eshober@utsci.com)
From Edward_D._Shober@dvg.com  Thu Nov  7 16:17:01 1996
From: Edward_D._Shober@utsci.com (Edward D. Shober)
Date: Thu Nov  7 16:17:07 PST 1996
Subject: Re: Q:vxWorks_rom.hex on the PEP VSBC4(VIUC) board
>  Someone adviced to me that the copies from ROM to RAM in the booting
>  sequence of the bootable image is not a real image size(350 KB ~ 500
>  KB), but the total size of ROM and then I have to use total 256 KB ~
>  512 KB ROM instead of 1MB ROM in the 1MB main memory board.
>
>Is it true ?  I did't believe it.
>How can I implement the bootable system to my all program ?
>I am not available 2Mbit ROM immediately.
I fixed this problem on our system by setting ROM_SIZE in config.h
and the makefile to just over the application size instead of to
the actual, available ROM size. If the application grows bigger
make should fail and you can increase the ROM_SIZE as needed.
Good luck,
Ed (eshober@utsci.com)
From guthrie@power.amasd.anatcp.rockwell.com  Thu Nov  7 16:23:13 1996
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Thu Nov  7 16:23:24 PST 1996
Subject: unsubscribe
unsubscribe
From tkb@mclean.sparta.com  Thu Nov  7 17:37:26 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Thu Nov  7 17:37:28 PST 1996
Subject: Re: 5.3 compability 5.2 compability mode
At 03:41 PM 11/7/96 PST, you wrote:
>Submitted-by Edward_D._Shober@dvg.com  Thu Nov  7 15:41:50 1996
>Submitted-by: Edward_D._Shober@utsci.com (Edward D. Shober)
>
>>How do you put 5.3 into 5.2 compatibility mode?
>
put a line like the following in your config.h file:
#define INCLUDE_CONFIGURATION_5_2
If you want to use CrossWind w/o Tornado, you'll need the remote debugger
task running.  To include that add this line also:
#define  INCLUDE_RDB
HTH
-----------------------------------------
     /\\     Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  7926 Jones Branch Drive
 / \\\\\  \\ Suite 900
 \  \\\\\ // McLean, VA 22102
  \  //////
   \//////   Voice: 703 448 0210
    \////    FAX:   703 893 5494
     \//     WWW:   www.mclean.sparta.com
From froeber@bbn.com  Thu Nov  7 18:53:23 1996
From: Fred Roeber <froeber@bbn.com>
Date: Thu Nov  7 18:53:30 PST 1996
Subject: Re: harddisk open problem
On Thu, 7 Nov 1996, Dani Gutzeit wrote:
> We upgraded our VxWorks version from 5.1 to 5.2
>  Now sometimes we have a problem when trying to open ( for write )
>  a file on harddisk.
>
>  The task is stuck with following stack:
>
> - -> tt 0xaea324
>   a240 _vxTaskEntry   +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
> 38b1a2 _x_main        +358: 38aaac (9c7de0)
> 38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078)
> d968fe _XtDispatchEvent+4a : d9667e (aea078)
> d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc)
> d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00,
> c1db10, 8])
> daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8,
> aea078])
> daf830 __XtMatchAtom  +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8])
> daf0de __XtMatchAtom  +292: df3ea8 (c117c8, aea078, 0, ac7fb0)
> df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0,
> ae9ed8])
> df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94,
> ae9e80, c117fc, 0])
> d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80)
> 4a8000 _diepSaveCB    +8a : _Save_Die_Parameters (a405c4, 565f6c)
> a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4)
> a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0)
> a17858 _dbSaveObject  +1c : _dbFopen (ae9bdc, ae9c16, a1783a)
> a177d2 _dbFopen       +10 : _fopen (ae9c16, a1783a)
>   c218 _fopen         +34 : _open (ae9c16, 601, 1b6)
>  28fce _open          +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6)
>  29ce4 _iosOpen       +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16])
>  570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5])
>  540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90)
>  55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4)
>  54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c)
>  28c2c _hashTblRemove +5c : _sllPrevious (f71590)
You aren't really just trying to write to a file.  From this trace, it
looks like you are running a lot of extra packages including X Windows,
and some data base code.  The error you are seeing could be caused by
incompatabilities in any one of those packages and will be hard to track down.
You may want to check with the vendors of these other packages as to
whether they think there stuff is compatible with 5.2 the same as it
was with 5.1.
It would appear from the trace that the open call is calling the DOS
open function which is calling the DOS file creation function.  I must
admit I can't imagine why the file creation would end up invoking the
hash table functions.  Maybe, your stack allocations for tasks is not
sufficient with the new release and you are clobbering some task's stack.
You should use checkStack to check this.
In general, we had few problems upgrading from VxWorks 5.1 to 5.2.
Hope that helps.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
   |   See http://www.bbn.com/tv for TraceMaker info    |
From 100656.1507@CompuServe.COM  Fri Nov  8 02:27:58 1996
From: John Shaw <100656.1507@CompuServe.COM>
Date: Fri Nov  8 02:28:00 PST 1996
Subject: Re: Shared Memory?
>Subject: Shared memory?
>Submitted-by beeman1@llnl.gov  Wed Nov  6 09:57:31 1996
>Submitted-by: Bart Beeman <beeman1@llnl.gov>
>Hi all,
>I am new to vxWorks and RTOS in general so please excuse this (hopefully)
>simple question. I have a motorolla MVME162 in a system with a sparc as the
>backplane master, there is also a mercury processor with it's own real time
>processes. The mercury is to provide update data I need for the 162 real
>time controll process (fast steering mirror). Ideally I would set up a
>large portion of memory to be shared for passing the 162 control block as
>well as a data circular buffer........
Hello Bart,
We are using several Motorola 167 and 162 68K cards in a chassis using
the shared memory backplane anchor for booting. We also use mailbox interrupts
between processors. These are really signals passed across the VMEbus that
may then interrupt a specific processor or a group of processors in the chassis.
There is very little written about them, but VxWorks uses mailbox interrupts so
any
system files will contain useful information.
Have a look at any LBIV_GCSR_XXXX definitions in the following header:
vw/h/drv/vme/vmechip2.h, and the source file vw/src/drv/vme/vmeChip2Vme.c too.
VxWorks uses the LBIV_GCSR_SIG3 mailbox and you should not! We use the
LBIV_GCSR_SIG2 mailbox as a one-to-one processor signal and both LBIV_GCSR_LM0
and LBIV_GCSR_LM1 mailboxes as a signal to a group of processors.
With regards to the 162 acting as a VME slave window, it is capable. There are
two
approaches. You could modify vw/config/bsp/sysLib.c so that the VMECHIP2_VSAR1
and VMECHIP2_VSATR1 registers are programmed to open a shared memory window
at a given VME A32 base address, in the sysProcNumSet () function. But there is
a much
better way that avoids changing VxWorks system files too much. The application
can
instead open a shared memory window by allocating non-cached memory and by then
programming the VMEChip2 on the MVME162 carefully to provide address translation
between VME and CPU-local address spaces.
Have a look at the Motorola manual on the MVME162 for details on the VMEchip2
and
it's miriad functions. I can, if you wish, email you the source for the
application-based
method of opening a shared memory window. Just email me!
Remember, the processor (Mercury) that needs to write the data across the VMEbus
to
the 162 must have a window into VME A32 space that it can write to without a bus
error.
The 68k processors usually had these windows defined statically in sysLib.c by
adding
entries in the sysPhysMemDesc [ ] array near the beginning of the file.
Hope this doesn't scare you too much, it's not quite as bad as it seems!
John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK.
100656.1507@compuserve.com
From daemon@csg.lbl.gov  Fri Nov  8 04:00:29 1996
From: daemon@csg.lbl.gov
Date: Fri Nov  8 04:00:32 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Nov  8 04:00:26 PST 1996
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: how to writeassembly code for a pc target ?
        Subject: Delta TAU PMAC vxworks  driver searching
        Subject: Re: causing a task switch
        Subject: Re: Task stuck when trying to open file on the harddisk
        Subject: @@@>> HOT COLLEGE BI-MALES!!!  >PRIVATE<  1-900-825-6000 xt 9794
        Subject: Looking for public-domain NFS client
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: intConnect for VMIC1182 and MVME167
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Porting Tcl Library to VxWorks!
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Clarification Of Question - Re: Non Terminating TCP/IP Sockets
        Subject: Serial ports 3+4
        Subject: Does vxWorks include echo server?
        Subject: kbhit() equivalent
        Subject: Interrupt vectors and levels
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 6 Nov 1996 14:50:35 -0700
From: softweyr@xmission.xmission.com (Softweyr LLC)
Organization: XMission Internet (801 539 0900)
Message-ID: <55r17b$ns7@xmission.xmission.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net>
Jim Jaskol <jim_k._jaskol@corp.disney.com> wrote:
 > We currently use pSOS, and are thinking about using VxWorks.  I would
 > like advice from current VxWorks users--especially those who have used
 > pSOS.
 >
 >      How is the development environment?
 >      How good is the support from Wind River?
 >      Are there lots of board support packages?
 >      Are the board support packages of high quality?
 >
 > And please don't limit your comments to the above questions.  If there's
 > something I should know before jumping in, let me know.
In my current job, we use VxWorks on our own proprietary boards with
MC68HC000 and MC68302 CPUs.  In two weeks, I'm going to a new job,
using VxWorks on NS486; that may color my opinion in the future.
We use the GNU tools on HP-UX and FreeBSD for our development
environment.  This is, essentially, the GNU development environment.  I
personally use GNU Emacs, GCC, and GDB, and am very familiar with and
productive in this environment.  A few of the poeple we've hired in the
last year, coming in from the DOS-dominated world of itty-bitty
embedded systems, have not gotten along well with our environment at
all.
We have little occasion to call Wind River support; our boards are
stable and mature and we've been on VxWorks (originally 5.1, latest
releases on 5.2) for about two years now.  The basic operating system
seems pretty thorough and bug-free in our environment, but I hear that
newer chips (to VxWorks, at least) are not as stable as the 68000
platform.
We have developed our own BSPs, since our boards are custom designs.
The engineer who maintains our BSP functionality (for the rest of this
week, anyhow) reports that your best bet for custom work is to get a
BSP for a board or CPU similar to yours and hack it up, rather than
starting from scratch.  Ours are apparently based on Motorola boards
using the CPUs we do; support ofr our other oddball devices (ie596, v25
using dual-port ram for serial ports, etc.) rely on in-house drivers
and firmware.
- ---
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Fri, 01 Nov 1996 08:01:56 -0800
From: Michael Levasseur <levass@gdesystems.com>
Organization: GDE Systems Inc.
Message-ID: <327A1EF4.41C67EA6@gdesystems.com>
References: <32794C99.67F9@corp.disney.com>
>      How is the development environment?
I've been working with VxWorks for the last six years on four seperate
defense
contracts; Seawolf Submarine BSY-2, USMC CATFAE vehicle, USN SLQ-32 and
now the
USN DIWS.
>      How good is the support from Wind River?
The only complaint I've ever had is their customer support is the worst
I've ever
delt with. They seem to ignore E-mail, they argue that all problem
reports must
go through the one person in our company that is the person listed for
customer
support.
>      Are there lots of board support packages?
I've used VxWorks on Heurikon Boards, Radstone boards, Force boards,
Motorola
boards, and DY4 boards. I've had great support from Heurikon and
Radstone. I've been
able to send E-mail to Heurikon in the morning and by afternoon I've
gotten answers.
Heurikon is by far the best!!! All of the companies have had good BSP
and have been
very helpful in fixing problems.
---------------------------
Newsgroups: comp.os.vxworks
Subject: how to writeassembly code for a pc target ?
Date: Tue, 05 Nov 1996 17:10:22 -0500
From: Farooq Bari <barif@utrc.utc.com>
Organization: UTRC
Message-ID: <327FBB4E.7FCC@utrc.utc.com>
Reply-To: barif@utrc.utc.com
Hi,
I am using a pc target with an NT host. I am interested in directly
accessing and writing to 486 or 586 registers on the pc target. Does
tornado compiler support inline assembly code ? I could not find any
sample code or documentation on this. will appreciate any  help in this
regard.
Farooq Bari
---------------------------
Newsgroups: comp.os.vxworks
Subject: Delta TAU PMAC vxworks  driver searching
Date: Thu, 07 Nov 1996 17:23:06 +0000
From: "Regis C. Schmidt" <Regis.Schmidt@obspm.fr>
Organization: Observatoire de Meudon
Message-ID: <32821AF8.2634@obspm.fr>
Hi,
I'm looking for a vxworks driver for a VME motion controler called PMAC
from Delta TAU company. If someone has already developped something like
that, I'd like to get it, and if possible, the sources of the driver.
I'm working for a non-profit organization in France so , be sure that
the sources origin will always be signalled.
Thanks by advance.
- --
Regards
- ------------------------------------------------------------------------------
Regis C. Schmidt
Observatoire de Paris-Meudon/DAEC
5, place Jules Janssen
F92195 Meudon (France)
FUEGOS Project
E-mail : Regis.Schmidt@obspm.fr
Tel : +33 1 45.07.75.27 Fax : +33 1 45.07.79.82
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: causing a task switch
Date: Thu, 07 Nov 1996 08:31:11 -0600
From: johncoby@ghgcorp.com (JOHN R. COBARRUVIAS)
Organization: Personal Account
Message-ID: <johncoby-0711960831140001@139.169.192.103>
References: <32818D21.390B@possibility.com>
In article <32818D21.390B@possibility.com>, tmh@possibility.com wrote:
> For our system integrity system we have a task that
> periodically wakes up our agents to cause a task switch.
> If a task has not switched in a certain period of time it
> is assumed dead. For agents this is easy because all
> agent's block on a semaphore which i can just give.
> For tasks i'm not sure how to make them perform a task switch in
> a general fashion. None of the task library methods
> seem appropriate. taskDelay works on the current task.
> suspending and resuming a task is risky and i'm not sure
> it would do what i want anyway. Any ideas?
taskResume, taskSuspend does just what it says. What concerns do you have
that makes this approach risky? Also, why not use a semaphore for these
tasks also?
Maybe I dont know what you mean by task switch. You mean, it is in a
pending state and you want it to go into a running state?
>
> Thanx
>
>
> -------------------------------------------------------------
> tmh@possibility.com        | The loyalty of small men can be
> http://www.possibility.com | bought cheaply, for greed has no
>                            | pride.  - Michael Kube-McDowell
- --
,-_/     .         .-,--.      ,---.     .
'  | ,-. |-. ,-.    `|__/      |  -' ,-. |-. ,-. ,-. ,-. . . .  , . ,-. ,-.
   | | | | | | |     | \  ,.   |  -. | | | | ,-| |   |   | | | /  | ,-| `-.
   | `-' ' ' ' '   `-'  ` `'   `---' `-' `-' `-^ '   '   `-' `'   ' `-^ `-'
/  |         John R. Cobarruvias johncoby@ghgcorp.com Houston, Tx
`--'
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Task stuck when trying to open file on the harddisk
Date: Thu, 7 Nov 1996 15:48:14 GMT
From: mfisher@dyn.com (Mark Fisher)
Organization: The World @ Software Tool & Die
Message-ID: <E0IBwq.20t@world.std.com>
References: <328062E5.41C67EA6@ksl.co.il>
Reply-To: mfisher@dyn.com
Sender: news@world.std.com (Mr Usenet Himself)
Dani Gutzeit <gdani@ksl.co.il> wrote:
>We upgraded our VxWorks version from 5.1 to 5.2
> Now sometimes we have a problem when trying to open ( for write )
> a file on harddisk.
> The task is stuck with following stack:
>-> tt 0xaea324
>  a240 _vxTaskEntry   +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
>38b1a2 _x_main        +358: 38aaac (9c7de0)
>38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078)
>d968fe _XtDispatchEvent+4a : d9667e (aea078)
>d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc)
>d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00,
>c1db10, 8])
>daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8,
>aea078])
>daf830 __XtMatchAtom  +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8])
>daf0de __XtMatchAtom  +292: df3ea8 (c117c8, aea078, 0, ac7fb0)
>df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0,
>ae9ed8])
>df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94,
>ae9e80, c117fc, 0])
>d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80)
>4a8000 _diepSaveCB    +8a : _Save_Die_Parameters (a405c4, 565f6c)
>a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4)
>a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0)
>a17858 _dbSaveObject  +1c : _dbFopen (ae9bdc, ae9c16, a1783a)
>a177d2 _dbFopen       +10 : _fopen (ae9c16, a1783a)
>  c218 _fopen         +34 : _open (ae9c16, 601, 1b6)
> 28fce _open          +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6)
> 29ce4 _iosOpen       +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16])
> 570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5])
> 540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90)
> 55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4)
> 54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c)
> 28c2c _hashTblRemove +5c : _sllPrevious (f71590)
> The task status is READY.
>Can anybody help?
>Thanks
Dan,
I saw this problem with sllPrevious() months ago -- it's some sort of
linked list problem as I recall. The fix is to get the latest patch
for the dosFsLib from WRS. Note this is not on their WEB page you have
to contact someone at WRS and get them to send it to you. A support
guy once told me that dosFsLib is the only part of the OS constantly
in need of maintenance.
I have also discovered a number of other problesm with dosFsLib over
the last year or so. I would recommend to anyone who notices any disk
I/O problems to get the latest dosFsLib from WRS before spending ANY
time trying to debug it. Only if the problem persists with the lateset
dosFsLib should you then try to replicate the circumstances and report
it to WRS so they can find the problem.
Mark.
---------------------------
Newsgroups: comp.os.vxworks
Subject: @@@>> HOT COLLEGE BI-MALES!!!  >PRIVATE<  1-900-825-6000 xt 9794
Date: Mon, 04 Nov 1996 06:06:10 GMT
From: Str8.Man@Nice.Folks.com
Organization: Sprynet News Service
Message-ID: <55k129$rd9@juliana.sprynet.com>
HOT COLLEGE STR8, BI, AND GAY GUYS NEEDED FOR FRIENDS AND/OR
RELATIONSHIPS!
ALL AREAS!  NOWHERE TO BIG OR SMALL FOR THE LOCATOR!
ALL PRIVATE!
ALL CONFIDENTIAL!
ALL AGES!
LADIES WELCOME!
THE LOCATOR
    1 - 9 0 0 - 8 2 5 - 6 0 0 0  xt  9 7 9 4
    1 - 9 0 0 - 8 2 5 - 6 0 0 0  xt  9 7 9 4
    1 - 9 0 0 - 8 2 5 - 6 0 0 0  xt  9 7 9 4
2.99/min
---------------------------
Newsgroups: comp.os.vxworks
Subject: Looking for public-domain NFS client
Date: 7 Nov 1996 20:04:32 GMT
From: watkins@spk.hp.com (Brian Watkins)
Organization: Hewlett-Packard, Spokane Division
Message-ID: <55tfcg$3e5@hpcvsnz.cv.hp.com>
  I have written a network driver that allows my VxWorks CPU to exchange
IP frames with another CPU that is running pSOS+ instead of VxWorks.  It
appears that this version of pSOS+ does not include a working NFS client,
which I was hoping to use for remote file access.  Is anyone aware of a
public-domain NFS client that can be made to work with pSOS+?
  Thanks in advance for any information.
- --------------------------
Brian Watkins
watkins@spk.hp.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Thu, 7 Nov 1996 21:04:03 GMT
From: breti@bit3.com (Bret Indrelee)
Organization: Bit 3 Computer Corp
Message-ID: <E0IqIr.FxF@bit3.com>
References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>
In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>,
Mike Anderson  <mea@mclean.sparta.com> wrote:
>2)  WRS's support capabilities are, I believe, typical of the industry.  That
>    is to say, WRS has good people who mean well and are trying to fulfill
>    the support requirements of a *very* diverse community.  Unfortunately,
>    I believe that there are too few support folks for the size of the user
>    base.  Also, I have a feeling that there is a general lack of what I'll
>    refer to as "real-world" embedded systems development experience.  Perhaps
>    the support folks should be cycled through the engineering department
>    to give them a better understanding of the O/S and its features.
That may be, but their documentation could certainly use a rework.
How come I don't find any mention of IVEC_TO_INUM when reading through
intLib, intConnect, etc? It is only by chance that I stumbled on to
the sysIntEnable() routine.
Another annoyance is that none of the routines say which include files
are needed. Sure, I have grep and can search the header files. I really
would rather just look up the routine and find all the information I
need to use it there.
- -Bret
- --
Bret Indrelee
breti@bit3.com		#include <std_disclaimer.h>
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: intConnect for VMIC1182 and MVME167
Date: Thu, 7 Nov 1996 21:11:35 GMT
From: breti@bit3.com (Bret Indrelee)
Organization: Bit 3 Computer Corp
Message-ID: <E0IqvB.H5q@bit3.com>
References: <55le7f$cnh@llnews.ll.mit.edu>
In article <55le7f$cnh@llnews.ll.mit.edu>,
paula l ward <plward@ll.mit.edu> wrote:
>I am trying to connect a hardware interrupt from a VMIC 1182 digital
>input board to an ISR running in vxWorks. My CPU bd is a MVME167.
>
>The interrupt register on the 1182 is set to 0x047b where 0x4 is the
>int. level and 0x7b is supposed to be the int. vector.
>
>Here's my code in a nutshell but it doesn't work. Any help is greatly
>appreciated. BTW, where does int. level 4 come into the picture?
[ snip ]
>int    intVector=0x7B; /* interrupt vector number */
>
#define	VMEIRQX	(4)
[ snip ]
>void init ()
>{
>intConnect(INUM_TO_IVEC(intVector) ,emerIsr);
 sysIntEnable(VMEIRQX);		/* Enable VMEbus IRQ4* */
>semSync = semBCreate(SEM_Q_FIFO, SEM_EMPTY);
>taskSpawn("tControl",76,0,5000,controlTask);
>}
[ snip ]
Near as I can tell from the documenation, you need to enable the
VMEbus interrupt (4 in your example) as shown. That is the impression
the documentation gives me, although I haven't had a chance to try
it out yet.
- -Bret
- --
Bret Indrelee
breti@bit3.com		#include <std_disclaimer.h>
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 6 Nov 1996 20:00:24 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <55rmso$hsl@elaine25.Stanford.EDU>
References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>
In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>,
Mike Anderson  <mea@mclean.sparta.com> wrote:
>Jim Jaskol wrote:
>    boards).  I think Windview (especially when coupled with RTI's
>    Stethoscope product) is extremely useful, especially if you don't have
>    the bucks for an ICE.  However, I'm not as bullish on Tornado.  More
>    on that in a later paragraph.
WindView is awesome if you have an application running several tasks
with different priorities. The post mortem capabilities are great too.
But its still a weak substitute for an ICE. With an ICE you become a god. ;-)
WindView is useless for very time critical apps (i.e. response times less
than say 2 milliseconds), but there are a large class of apps which don't
have such tight constraints. Overall its a great tool.
>3)  As to BSPs, I seriously doubt that you could find an RTOS with more BSPs
Very true, and their porting kit is very good. You can port their BSP to
other platforms with very little hassle.
>4)  Now, what about Tornado?  If you were to believe all of the press (and
>    the WRS salescritters), Tornado is a radically new development approach
>    that will revolutionize the industry.  However, I believe that in an
>    effort to increase sales, improve the stock price, etc. that many at WRS
>    have lost sight of the *real* product.  That is, the base VxWorks O/S
>    that runs on the target.  Tornado seems to be well suited for the
>    development model of those large companies such as HP wherein they are
>    embedding VxWorks into a printer.  That is, when you don't have much
>    RAM, no serial console ports, and maybe no Ethernet, then Tornado
>    represents a fine development environment *in theory*.  And, I
>    believe, that the Unix implementation comes pretty close to realizing
>    that environment in practice.  However, from what I've heard from the
>    net, I believe that there are some serious problems (memory leaks, etc.)
>    in the Tornado product under Win 95 & Win NT.
One strategy behind doing Tornado was to scale down the BSP so it could be used
for a bigger class of applications. So a lot of the tools were offloaded
to the host. For example, VxWorks probably lost a lot of sales to QNX
which is more scalable. Now they probably match up better with QNX. The
integrated host environment has less benefit too me than scalability.
My biggest knock against Tornado is before I could just plug in a vt100
to the serial port and go. Now I either need a UNIX box for WindSh or
I have to jump thru some hoops to get the old configuration. For a
lot of advanced users the added GUI stuff just gets in the way and slows
you down. But a lot of guys like that fancy GUI stuff.
>    the board because of lack of cycles.  Real-time programming is not
>    as simple as writing a database app.  Should WRS have tried to move
>    Tornado to the 95 & NT platform?  I believe that the answer is yes.
>    But, WRS needed to beef up their  support organization to handle the
>    influx of calls from people just trying to grasp the basic concepts
>    of the RTOS.
WRS had to support Win platform because that's the current trend ...
to reduce cost by going PC. Hopefully, companies will wake up and
demand a Linux platform instead which is far superior and cost effective.
This is what happens when you let managers pick the tools engineers use
instead of letting them decide for themselves. I've heard complaints from
engineers who switched from UNIX to Win cross development platforms and
they all complain about the lack of tools they had available on UNIX
which either don't exist on Win or they were implemented half-assed.
---------------------------
Newsgroups: comp.os.vxworks,comp.software.testing
Subject: Porting Tcl Library to VxWorks!
Date: Thu, 31 Oct 1996 17:12:31 -0700
From: "Loay (Louie) Abu-Husein" <loay@boi.hp.com>
Organization: Color LaserJet and Consumable Division, R&D Labs
Message-ID: <3279406F.1152@boi.hp.com>
Has anyone out there ported the Tcl Library to VxWorks?
- --
    _/    _/  _/_/_/_/ Loay (Louie) Abu-Husein
   _/    _/  _/    _/  Intranet:  http://hpbs4896.boi.hp.com/
  _/_/_/_/  _/_/_/_/   Internet:  http://www.boi.hp.com/
 _/    _/  _/          EMail:     mailto:loay@hpbs4896.boi.hp.com
_/    _/  _/
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 8 Nov 1996 04:33:17 GMT
From: vbv@giskard.cwru.edu ("Virgilio 'Dean' B. Velasco Jr.")
Organization: Case Western Reserve Univ.  Cleveland, Ohio (USA)
Message-ID: <55ud6d$f7p@alexander.INS.CWRU.Edu>
References: <32794C99.67F9@corp.disney.com> <327E0DB7.6513@med.ge.com> <55p1k6$24c@elaine25.Stanford.EDU> <3280BF21.41C67EA6@gdesystems.com>
In article <3280BF21.41C67EA6@gdesystems.com>,
Michael Levasseur  <levass@gdesystems.com> wrote:
>Notice anything perculur? There is this long indepth thread
>and not a single post from Wind River!!!! Don't Wind River's
>people look at the net. Aren't they in the 90's or are they still
>working in a vacuum.
I really don't think that's a fair criticism.  True, they
have not posted a reply; however, this does not mean that
they aren't following the thread.  Perhaps they wish to
observe the thread first, in order to avoid biasing the
discussion.
- --
Virgilio "Dean" Velasco Jr, Department of Electrical Eng'g and Applied Physics
        graduate student slave, roboticist-in-training and Q wannabe
http://dora.eeap.cwru.edu/vbv/vbv.html |  Remember: Wise men still seek Christ.
"And I shall shed my light over dark evil, for darkness cannot stand the light."
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Clarification Of Question - Re: Non Terminating TCP/IP Sockets
Date: Fri, 01 Nov 96 16:09:26 GMT
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <55e3b8$dro@idiom.com>
References: <327503B6.7860@gic.gi.com> <32779160.3AF8@peacefulstar.oakland.ca.us> <3279F9DA.711@gic.gi.com>
In article <3279F9DA.711@gic.gi.com>, rgilbet@gic.gi.com wrote:
>When the SCO client is shutdown, the shutdown code does a kill -9
>on all the tasks communicating with the VxWorks based server (ugly
>huh).  Now, it seems that on some level, the client system "cleans up"
>the socket connections to the server, except for 2 or 3 that just
>linger.  The fioRead call gets an error for those sockets that are
>"cleaned up" and everything is OK, but I am still stuck with the
>lingering connections.  That is the part that I cannot figure out.  Why
>would some connections close fine, and others just vanish?
OK, kill a process on Unix will close all sockets, which translates
to PRU_DETACH in tcp layer.  It's possible that some sockets remain
in final graceful close state-machine (sockets will be in FIN_WAIT_1
or FIN_WAIT_2 or TIME_WAIT state), waiting for the other side to
either ACK the FIN packets, or waiting for 2 * MSL (max segment lifetime)
before timing out.  This level of code is fairly complicated and
some Unix kernels has had some bugs over the years.  I'm not
certain what SCO kernel does, but I've seen this kind of zombie
sockets remaining in old SunOS kernels.  The only way in Unix is
to reboot!  (In VxWorks, if this happens, you can clean up manually).
Now, to avoid this problem, you can try to use SO_LINGER socket option
with linger value set to 0.  (Read setsockopt documentations on how
to do this).   If you set linger option to zero on your SCO side
sockets, when kernel cleans up sockets for the processes that are
being killed, the socket will be dropped.  Instead of going through
the FIN_1,2,TIME_WAIT sequence of state-transitions, you will be
sending RST (reset) packet to the other side, which is more abrupt
but a sure kill.
If this doesn't help, you may have to add application specific close
hand-shake in your code (send a message to the other side saying
I'm closing, before actual close(), to prompt the other side to
initiate the closing state-transition in its TCP), as well as
properly shutdown() and close()'ing on SCO side.
Good luck.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Serial ports 3+4
Date: 7 Nov 1996 13:37:13 GMT
From: pjs@mc.com (Peter Satkwich)
Organization: Mercury Computer System
Message-ID: <55som9$ft9@newsy.mc.com>
Reply-To: pjs@mc.com
Does anyone have any information on using serial ports 3 and 4 on a mvme167 or
mvme1604 board.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Does vxWorks include echo server?
Date: Thu, 7 Nov 1996 23:11:49 GMT
From: "David W. Suh" <dsuh@lucent.com>
Organization: Lucent Technologies, Denver
Message-ID: <32826CB5.4B40@lucent.com>
Sender: news@drnews.dr.lucent.com (Netnews Administration Login)
Does vxWorks include an echo server at the well known UDP and TCP
port 7?  It probably does, but I need to verify this.
- --
================================================================================
David W. Suh
Lucent Technologies
dsuh@lucent.com
================================================================================
---------------------------
Newsgroups: comp.os.vxworks
Subject: kbhit() equivalent
Date: 7 Nov 1996 18:28:05 -0700
From: jmh@dante.as.arizona.edu (J.M. Hughes)
Organization: Steward Observatory
Message-ID: <55u2b5$j9@dante.as.arizona.edu>
A little while ago someone asked about an equivalent function to the
DOS "kbhit()" call to see when keyboard input was available. I
recently encountered a situation where I need something like this
as well, and found that there are at least 3 ways to do it: (1)
create seperate threads for input and output so blocking is not an
issue, (2) use the select() function call, and (3) use ioctl with
the stdin file descriptor, which happens to be 0 (zero). I chose
method 3 because I didn't want to worry about coordinating multiple
threads, and select looked like serious overkill for what I was
trying to do. ioctl seems to work just fine, as in:
STATUS vwkbhit(void)
{
    int nio;
    ioctl(0,FIONREAD,&nio);
    if (nio)
        return 1;
    return 0;
}
Enjoy.
- --
- ------------------------------------------------------------------------------
John M. Hughes                                               VOX: 520-621-7804
Senior Systems Programmer                                    FAX: 520-621-3398
Steward Observatory, University of Arizona          jmh@canopus.as.arizona.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: Interrupt vectors and levels
Date: 7 Nov 1996 14:28:36 GMT
From: plward@ll.mit.edu (paula l ward)
Organization: MIT Lincoln Laboratory
Message-ID: <55srmk$69s@llnews.ll.mit.edu>
Sender: plw@bart (paula l ward)
I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with
someone at WRS about interrupts and they gave me the impression that each
interrupt level (1-7) could only be associated with a single vector. I was
looking in the manuals though, and saw that vectors 61 through 255 were
available to the user.
How do you associate the same interrupt level with more than one vector?
Or do you have to execute intConnect repeatedly and thereby connect it
to different vectors?
---------------------------
End of New-News digest
**********************
From AS_Bridge@MSMAIL3.HAC.COM  Fri Nov  8 05:38:34 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Nov  8 05:38:36 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Re: Shared Memory?
Sent: Fri, Nov 8, 1996 4:21 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Nov 8, 1996 5:37 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From basakc@diebold.com  Fri Nov  8 06:05:24 1996
From: Chris Basak <basakc@diebold.com>
Date: Fri Nov  8 06:05:27 PST 1996
Subject: Want x86 device driver for removable mass storage devices
I am interested in VxWorks device driver for removable mass storage
devices such as Zip drives, JAZ drives, etc.  My target is 486 PC. Can
someone refer me to a vendor who provides such a driver?
From leonid@rst.co.il  Fri Nov  8 06:31:13 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Fri Nov  8 06:31:16 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
In article <3280BF21.41C67EA6@gdesystems.com>,
Michael Levasseur  <levass@gdesystems.com> wrote:
>Notice anything perculur? There is this long indepth thread
>and not a single post from Wind River!!!! Don't Wind River's
>people look at the net. Aren't they in the 90's or are they still
>working in a vacuum.
Note that the original posting which started this thread
did not ask opinion from WRS, but from their users.
Be confident that many people at Wind River are following
this newsgroup and the exploder very very carefully, some of the senior
managers read this list on a daily basis.
Replying is a completely different issue.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
R S T  Software Industries Ltd.         Fax:   +972-3-559-8244
3 Hashikma st. Industrial Zone,         E-Mail: leonid@rst.co.il
P.O.Box 11502, AZUR 58017, Israel    	WWW: http://www.rst.co.il
From tkb@mclean.sparta.com  Fri Nov  8 06:43:55 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Fri Nov  8 06:43:57 PST 1996
Subject: Re: Are you happy with Vx Works and Wind River
>Another annoyance is that none of the routines say which include files
>are needed. Sure, I have grep and can search the header files. I really
>would rather just look up the routine and find all the information I
>need to use it there.
Try checking the SEE ALSO paragraph at the end of all manual entries.  It's
a pretty standard approach...
adios
-----------------------------------------
     /\\     Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  7926 Jones Branch Drive
 / \\\\\  \\ Suite 900
 \  \\\\\ // McLean, VA 22102
  \  //////
   \//////   Voice: 703 448 0210
    \////    FAX:   703 893 5494
     \//     WWW:   www.mclean.sparta.com
From tkb@mclean.sparta.com  Fri Nov  8 06:55:08 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Fri Nov  8 06:55:11 PST 1996
Subject: Re: Interrupt vectors and levels
>I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with
>someone at WRS about interrupts and they gave me the impression that each
>interrupt level (1-7) could only be associated with a single vector. I was
>looking in the manuals though, and saw that vectors 61 through 255 were
>available to the user.
You can use any vector not already used by the processor or any device
already running.  Check the Motorola docs for the vectors in use by default.
>How do you associate the same interrupt level with more than one vector?
The vector is parameter passed to intConnect.  You may call it repeatedly
with different vectors on the same level.
>Or do you have to execute intConnect repeatedly and thereby connect it
>to different vectors?
You can easily do what you want but spend a little time on system design
first. Can you live with multiple devices on the same interrupt level?  Will
it be possible to service all devices in the worst timing case?  Is there
any problem with priority of VME interrupts versus locally generated
interrupts?  On the VMEbus, interrupters on the same level have an implied
priority going from left to right across the backplane.  Are your boards
where they should be for your application?  And on, and on, and on....
HTH
-----------------------------------------
     /\\     Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  7926 Jones Branch Drive
 / \\\\\  \\ Suite 900
 \  \\\\\ // McLean, VA 22102
  \  //////
   \//////   Voice: 703 448 0210
    \////    FAX:   703 893 5494
     \//     WWW:   www.mclean.sparta.com
From john@bos.mcd.mot.com  Fri Nov  8 07:17:12 1996
From: John Collins <john@bos.mcd.mot.com>
Date: Fri Nov  8 07:17:14 PST 1996
Subject: unsubscribe
unsubscribe
--
******************************************************************
John Collins
Account Executive                   PH  (617) 932-6085
Motorola Computer Group             FAX (617) 932-6125
300 Unicorn Park
Woburn MA 01801
******************************************************************
From AS_Bridge@MSMAIL3.HAC.COM  Fri Nov  8 07:31:51 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Nov  8 07:31:53 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Fri, Nov 8, 1996 6:27 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Nov 8, 1996 7:29 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From mea@mclean.sparta.com  Fri Nov  8 07:33:10 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri Nov  8 07:33:12 PST 1996
Subject: Re: Interrupt vectors and levels
At 04:00 AM 11/8/96 PST, you wrote:
>From: plward@ll.mit.edu (paula l ward)
>Organization: MIT Lincoln Laboratory
>Message-ID: <55srmk$69s@llnews.ll.mit.edu>
>Sender: plw@bart (paula l ward)
>
>
>I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with
>someone at WRS about interrupts and they gave me the impression that each
>interrupt level (1-7) could only be associated with a single vector. I was
>looking in the manuals though, and saw that vectors 61 through 255 were
>available to the user.
>
This is impression about vectors and levels is *not* true.  You can, in fact,
have multiple interrupt *generators* at a given interrupt level.  However,
you can have only one interrupt *responder* (i.e., board that owns the ISR)
at a given level.  This enables you to have multiple, say, A/D boards at
some interrupt level, such as 5, provided that they all generate different
interrupt vectors.
>How do you associate the same interrupt level with more than one vector?
>
>Or do you have to execute intConnect repeatedly and thereby connect it
>to different vectors?
>
Yes.  Here is a sequence to setting up a host CPU and 3 similar I/O boards
at the same level:
The interrupt level will be 5 and the vectors that they will generate are
0xa0, 0xa8, and 0xb0.  These are arbitrary vector numbers that I just
picked out of the air.  You have an ISR called "myIoIsr" and you pass to it a
parameter telling the ISR which "board" to look at.
# Reset the boards and get them into a know state, programming Interrupt
# levels and vectors if necessary (this may be in hardware jumpers on
# some boards).  *You* have to write this function if necessary.
resetBoard0();
resetBoard1();
resetBoard2();
# Next, get the ISRs in place so that when you enable the Int Level,
# you don't get a spurious interrupt message (just in case the I/O board
# wasn't reset properly and still has an Interrupt hanging out there).
# We use intLock/intUnlock just to be sure that one of those vectors
# doesn't fire while we're installing the ISR.
intKey = intLock();
intConnect(INUM_TO_IVEC(0xa0), myIoIsr, 0);
intConnect(INUM_TO_IVEC(0xa8), myIoIsr, 1);
intConnect(INUM_TO_IVEC(0xb0), myIoIsr, 2);
intUnlock(intKey);
# Now, enable the interrupt level from the bus.
sysIntEnable(5);
HTH,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From mea@mclean.sparta.com  Fri Nov  8 07:50:57 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri Nov  8 07:50:59 PST 1996
Subject: Book(s) on VxWorks?
Greetings!
  I've had several people ask me over the years (none of them from WRS) to
consider the possibility of writing a book about VxWorks.  To my mind,
there should really be a couple of books.  One should deal with the
operational
concepts of the O/S.  Basically, an expanded Programmers Guide.  Something
that explains the RTOS from say, a Unix/Win NT/95 perspective so that
folks coming into this market from non-real time programming environments
can understand what's different about VxWorks and why it matters.  In this
book, I could see chapters on important issues being written by many of
our primary net contributors and basically being edited for consistent flow.
(How about it Stan, Fred, Leonid, et al.?)
  The second book is one that I've been lobbying for since I started using
VxWorks in 1987.  That book would essentially be a "VxWorks Bible" (ala
"Turbo C Bible") wherein all of the VxWorks functions are described, the
appropriate lib and .h files are referenced *and* a working example piece
of code is shown for your edification and enjoyment.
  What thinks ye?  I have no idea what the market for such a set of books
would be.  But I suspect that the model of the book "OS9 Insights" from the
Microware folks would be a reasonable one to start with.  That is, the
books would definately have to have some form of WRS sanction/support
(maybe even $$$).  If you think you might have some ideas or interest
in writing a chapter or so, drop me a note.  Also, if you really think
these books could be of some use, send your favorite WRS folks some
e-mail about wanting these books to be developed.  I doubt that it's going
to happen without a swell of popular support from us, the user community.
Regards,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From bff@dspcon.com  Fri Nov  8 08:34:29 1996
From: bff@dspcon.com (Robert F. Franz)
Date: Fri Nov  8 08:34:31 PST 1996
Subject: bootp,tftpd,ftpd
I am looking for a PD or shareware version of bootp,tftpd, and ftpd which
anyone has has success using to boot a vxWorks node from a WIN 95 machine. I
would also like to get source code possibly so that I could customize it.
I would like to say thank you in advance to anybody with any ideas.
-------------------------------------------------------------------------------
       DSPCon, Inc. -- leaders in digital signal processing solutions
-------------------------------------------------------------------------------
       Bob Franz
       380 FootHill Rd.
       Bridgewater, NJ 08807
       (908)722-5656 Fax:(908)722-3259
       bff@dspcon.com
-------------------------------------------------------------------------------
From lrichard@redwood.dn.hac.com  Fri Nov  8 15:19:47 1996
From: lrichard@redwood.dn.hac.com (Larry Richards)
Date: Fri Nov  8 15:19:49 PST 1996
Subject: unsubscribe
From aaronn@telerobot.com  Fri Nov  8 15:52:44 1996
From: aaronn@telerobot.com (Aaron Needles)
Date: Fri Nov  8 15:52:47 PST 1996
Subject: Need STD32, x86 CPU board w/VxWorks support
        We have an immedate need for a x86 CPU board in STD32 format with
     VxWorks support (BSP).  Please let me know if you know of any such
     boards (or likely manufacturers), or if you have had any good or bad
     experiences with these.
        Also, any pointers to Synchro/Resolver interface boards on STD32 or
     PC/104 would be appreciated.
     Thanks much,
         Aaron Needles
         aaronn@telerobot.com
         Schilling Robotic Systems, Inc.
From daemon@csg.lbl.gov  Sat Nov  9 04:00:31 1996
From: daemon@csg.lbl.gov
Date: Sat Nov  9 04:00:34 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Nov  9 04:00:28 PST 1996
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Tornado Launcher
        Subject: Re: Seeking XDR functions/types
        Subject: Virtual to Physical address conversion.
        Subject: Re: how to writeassembly code for a pc target ?
        Subject: Re: Looking for public-domain NFS client
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Interrupt vectors and levels
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Looking for public-domain NFS client
        Subject: Re: HELP: How to get useful debug info out of an NMI interrupt?
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Thu, 07 Nov 1996 09:38:39 -0500
From: CK Wong <wongck@nortel.ca>
Organization: Nortel Technology
Message-ID: <3281F46F.3E61@nortel.ca>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <55r17b$ns7@xmission.xmission.com>
Does Anyone has any experience and opinion on VxWorks regarding:
1. VxWorks on PowerPC
2. Backwork compatibility of VxWorks software releases, i.e. is
   the system computing model changes often enough to affect
   product development.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Tornado Launcher
Date: 8 Nov 1996 18:32:13 GMT
From: fred.getz@lmco.com
Organization: Lockheed Martin Federal Systems
Message-ID: <55vubd$dq3@inetserv2.fs.lmco.com>
Reply-To: fred.getz@lmco.com
When I start the launcher the launcher window appears, but none of the bitmaps, buttons, or menu items appear.
The targets and information list boxes do appear, but there is no title above either of them as shown in the
Tornado User's guide.  Obviously it's pretty useless this way.  I also get a ton of translation error messages in the
text window where start LAUNCH from.  My host is a SPARC running Sun Solaris 2.  I connect to the host via rlogin
on an x-station and am trying to run the Tornado launcher at the x-station.  I would appreciate any ideas on this.
Fred Getz - Lockheed Martin Federal Systems
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Seeking XDR functions/types
Date: Fri, 8 Nov 1996 13:32:37 GMT
From: noblenet@world.std.com (NobleNet Inc.)
Organization: NobleNet, Inc.
Message-ID: <E0K0AD.7r2@world.std.com>
References: <55b90v$k93@hacgate2.hac.com>
In article <55b90v$k93@hacgate2.hac.com>,  <scott@tcville.es.hac.com> wrote:
>I am seeking some XDR functions/source to allow
>data xport (socket based) between a VxWorks target
>and a Unix host (AIX & Solaris).
Please contact NobleNet for ONC/RPC tools and solutions for UNIX,
Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc.
        NobleNet, Inc.
        337 Turnpike Road
        Southboro, MA  01772
        Voice +1 508 460 8222
        Fax +1 508 460 3456
        <sales@noblenet.com>
        <http://www.noblenet.com/>
PRESS RELEASE
For Immediate Release
For Further Information, Please Contact:
David Burns
Vice President of Marketing
NobleNet, Inc.
Voice: (508) 460-8222
FAX: (508) 460-3456
e-mail: david.burns@noblenet.com
"The Client/Server Toolkit for C and C++ Programmers"
New Book From NobleNet Turns Programmers Into Client/Server Experts
New York, October 8, 1996 --  NobleNet, Inc. today announced the availability
of its newly published book that turns C and C++ programmers into
client/server experts.   Co-authored by middleware experts Steven Lemmo and
Rich Grehan, The Client/Server Toolkit for C and C++ Programmers  is a self-
contained instructional tool that teaches programmers how to distribute any
application or Application Programming Interface (API) across a network.
The CD-ROM software included with The Client/Server Toolkit features a unique
Windows-based client/server simulator that lets programmers gain hands-on
experience in client/server partitioning.  Programmers are guided through four
"real-world" client/server projects: distributed ODBC database, scanner
device, image engine, and datafeed.  The authors expertise combined with a
Rapid Application Development (RAD) environment, demystifies the art of
distributing complex applications.
"I learned more about client/server development in the last three days of
reading your book than I learned in the past few years of doing C and C++
programming," said Pascal Specht, Technical Sales Engineer at Precision
Software in Paris, France.
"Our new book will help any C or C++ programmer that wants to learn about
state-of-the-art client/server computing," said Steve Lemmo, co-author and
Chief Technology Officer of NobleNet.  "The techniques taught in the book will
help programmers learn to use the powerful Interface Definition Languages
(IDLs) found in today's most popular distributed computing middleware."
Beginning with a monolithic application, readers learn how to separate
programs into independent parts that communicate with each other.  While other
books on client/server computing include sample code, The Client/Server
Toolkit goes further and delivers a true client/server Software Development
Toolkit (SDK) designed for application partitioning.  Unlike other approaches,
programmers learn to build client/server applications using industry-standard
RPC technology that requires no source code changes.
"The Client/Server Toolkit is ideal for programmers that want to get a quick
immersion into client/server computing with tools that require very little
effort to learn,"  said Vincent Russo, Assistant Professor of Computer Science
at Purdue University.  "I like the fact that the book is totally self-
contained.  It has a wealth of real-world examples that provide the reader
with a thorough understanding of client/server development.  And the simulator
gives programmers hands-on experience with building and running real
client/server applications."
Although The Client/Server Toolkit is written for C and C++ programmers,
examples are given that show "drag and drop" programmers how to create
client/server applications utilizing popular GUI front-ends such as Visual
Basic, PowerBuilder, Delphi, and Developer 2000.  Distributed with the book is
a free version of NobleNet's powerful standards-based RPC product used by
client/server developers world-wide.  Programmers are presented with client
and server Windows connected by a simulated network.  Using NobleNet RPC,
applications developed on the simulator are easily deployed to over 40
platforms including 26 UNIXes, Windows 3.1, 95, and NT, NetWare, Macintosh,
OS/2, and VMS.  More than 20 Windows-based TCP/IP stacks are supported to
ensure operation in existing multi-vendor environments.
Co-author Steven Lemmo founded NobleNet, engineered NobleNet's first software
product, EZ-RPC(R), and led the team that developed the company's NetWare and
Windows-based middleware tools.  With an in-depth understanding of both
communication and application software, he is a sought after consultant on RPC
programming.  Steve has over fifteen years of experience in software
engineering and tools development in companies such as Computervision Corp.,
Sun Microsystems, Inc., and Xerox Imaging Systems, Inc.  He is widely
recognized as an expert on distributed computing and is frequently called upon
to appear at industry forums.
Co-author Rick Grehan has been on the editorial staff of BYTE Magazine for
over 11 years.  He is currently the Technical Director of BYTE Labs and the
author of BYTE's monthly CodeTalk column.  His articles have appeared in BYTE,
Embedded Systems Programming, and Forth Dimensions.  In addition, he was a
contributor to the 1993 edition of The Encyclopedia of Microcomputers,
published by Marcel Dekker, Inc.  Rick is also the designer of BYTE Magazine's
BYTEmark benchmark suite.
The Client/Server Toolkit for C and C++ Programmers is published by NobleNet.
The 350 page book with CD-ROM can be ordered for $49.95 by calling (800)-250-
6427 or (508)-893-0398.
NobleNet offers tools for distributed client/server development for procedural
and object paradigms. Incorporated in 1991, NobleNet is a world leader in
Remote Procedure Call (RPC) technology and has won numerous awards for its RPC
product family.   NobleNet also distributes IONA Technologies' industry-
leading "Orbix" CORBA-compliant Object Request Broker. The company is
headquartered in Southboro, MA, and can be reached at (508) 460-8222 or at
<http://www.noblenet.com/>.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Virtual to Physical address conversion.
Date: Mon, 04 Nov 1996 17:57:11 +0200
From: Casey Crellin <casey@ccii.co.za>
Organization: CCII Systems
Message-ID: <327E1257.65792670@ccii.co.za>
Hi,
I would like to convert an addrtess from virtual to physical.
Similar to the unix ktop() or vtop() functions.
How do I do this?
I see in the manuals there is a vmContextShow() whose output
includes both physical and virtual addresses.
I would imagine I owuld use the sysPhysMemDesc[]
But how?
Thanks
Casey
- --
Casey Crellin
casey@ccii.co.za
CCII Systems (Pty) Ltd
- -----------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: how to writeassembly code for a pc target ?
Date: 8 Nov 1996 16:51:56 -0700
From: softweyr@xmission.xmission.com (Softweyr LLC)
Organization: XMission Internet (801 539 0900)
Message-ID: <560h2s$iga@xmission.xmission.com>
References: <327FBB4E.7FCC@utrc.utc.com>
Farooq Bari <barif@utrc.utc.com> wrote:
: I am using a pc target with an NT host. I am interested in directly
: accessing and writing to 486 or 586 registers on the pc target. Does
: tornado compiler support inline assembly code ? I could not find any
: sample code or documentation on this. will appreciate any  help in this
: regard.
The GNU compilers certainly do.  You'll need to be careful that your in-
line code doesn't clash with the optimizer, which makes very effective use
of registers.  It is often difficult to determine exactly what each
register is being used for, so if you're not certain, better save the
register before using it.
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Looking for public-domain NFS client
Date: 8 Nov 1996 17:22:31 -0700
From: softweyr@xmission.xmission.com (Softweyr LLC)
Organization: XMission Internet (801 539 0900)
Message-ID: <560is7$p7u@xmission.xmission.com>
References: <55tfcg$3e5@hpcvsnz.cv.hp.com>
Brian Watkins <watkins@spk.hp.com> wrote:
:   I have written a network driver that allows my VxWorks CPU to exchange
: IP frames with another CPU that is running pSOS+ instead of VxWorks.  It
: appears that this version of pSOS+ does not include a working NFS client,
: which I was hoping to use for remote file access.  Is anyone aware of a
: public-domain NFS client that can be made to work with pSOS+?
FreeBSD, a freely available OS based on 4.4BSD-Lite, includes an
implementation of NFS, both client and server.  It is distributed with
a Berkeley-style copyright that allows you to use the code as you wish.
Check out http://WWW.FreeBSD.ORG for more info.
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Mon, 4 Nov 1996 16:31:26 GMT
From: gerlach@netcom.com (Matthew H. Gerlach)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Message-ID: <gerlachE0CtwF.Ju2@netcom.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com>
Sender: gerlach@netcom23.netcom.com
In article <327E0DB7.6513@med.ge.com> Steve Woloschek <woloschekS@med.ge.com> writes:
>I second Steve's comments. But most of my problems stem
>from the fact that WRS uses GNU tools. IMOH, this is a real
>downfall.
Interesting, my experience with GNU tools in general has been great, and
Wind River's use of the GNU tools, IMHO is a compelling reason to use
VxWorks.
Matthew
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Interrupt vectors and levels
Date: Fri, 08 Nov 1996 14:41:30 -0500
From: "Bruce K. Gitlin" <gitlin_bk@wl.corning.com>
Message-ID: <32838CEA.253C@wl.corning.com>
References: <55srmk$69s@llnews.ll.mit.edu>
paula l ward wrote:
>
> I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with
> someone at WRS about interrupts and they gave me the impression that each
> interrupt level (1-7) could only be associated with a single vector. I was
> looking in the manuals though, and saw that vectors 61 through 255 were
> available to the user.
>
> How do you associate the same interrupt level with more than one vector?
>
> Or do you have to execute intConnect repeatedly and thereby connect it
> to different vectors?
Here's how I understand interrupts.
The vector and level are separate beings.  IntConnect is used to connect a vector
to a routine that is run when an interrupt occurs, regardless of the level.
If you had a timing board, for instance, and you wanted to send an interrupt to the
CPU, you would set up the board to interrupt at whatever level you decided on,
let's say 2.  You would then have to let the timing board know what vector you were
using.
On the CPU, you would use intConnect to let the system know what to execute when an
interrupt with that vector is received.  That interrupt can be at any level that is
enabled using sysIntEnable, which in our example would be 2.
At the right time, the board would generate a level 2 interrupt with your chosen
vector.  The CPU would execute the code that the vector pointed to, and your off
and running.
If you wanted to change to level 4 (but keep the same vector), the only thing
required on the CPU is to sysIntEnable (4).  The rest would be changed on the
timing board.
Hope that helps,
Bruce
- --
       ==============================
       ||     Bruce K. Gitlin      ||
       ||      CTG / Corning       ||
      /)|      (910)397-8204       |(\
     / )| gitlin_bk@wl.corning.com |( \
    ( (==============================) )
  (((\ \)  /,)                 / ) (/ //))
  (\\\\ \_/ /                  \ \_/ /////
   \       /                    \       /
    \    _/                      \_    /
- ----/   /--------------------------\   \----
   /   /                            \   \
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Fri, 08 Nov 1996 22:21:03 GMT
From: mhayashibara@ccgate.hac.com (Matthew Y. Hayashibara)
Organization: Hughes Aircraft Company
Message-ID: <560boi$42q@hacgate2.hac.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <gerlachE0CtwF.Ju2@netcom.com> <rypma-0411961259040001@hppadhtr1.waterloo.hp.com> <55md5u$5b@idiom.com>
Reply-To: mhayashibara@ccgate.hac.com
chaos@idiom.com (H.J. Bae) wrote:
>GNU toolchain certainly works better than any other
>cross-deveopment tools I've used, including pSOS with
>MRI tools.
The MRI tools have gotten worse by the day, too. I f you haven't been
following the threads on comp.arch.embedded a few months ago, their
new PC licensing scheme is the absolute worst.
The Mentor buyout of pSOS was the last straw.
>Have you actually used those tools?
>You can't be serious.
Maybe it's just our location, but at a short contract I had at JPL,
and here at Hughes in Fullerton, getting Russ Eigle or Corey Hutchins
(he recently left to do sales in the Rockies) on the phone at the WRS
office in Laguna Hills, and now Irvine, isn't that difficult. They
have spent some time on-site, too.
We got no support whatsoever from ISI or Microtec with pSOS at my last
contract, and we had to come up with a bunch of our own workarounds,
which was very expensive schedule-wise.
Mat Hayashbara
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Looking for public-domain NFS client
Date: Fri, 08 Nov 1996 10:24:44 +0100
From: Philippe Le Foll <le-f1769@eurobretagne.fr>
Organization: France Telecom Interactive
Message-ID: <3282FC5C.4BD33D25@eurobretagne.fr>
References: <55tfcg$3e5@hpcvsnz.cv.hp.com>
Check for SUN version, the code is in public domain you
should find this on sunsite true ftp anonymous. I port a
part of it (RPC?XDR) on NT and the code is quite simple.
phillf@iu-vannes.fr
Brian Watkins wrote:
>
>   I have written a network driver that allows my VxWorks CPU to exchange
> IP frames with another CPU that is running pSOS+ instead of VxWorks.  It
> appears that this version of pSOS+ does not include a working NFS client,
> which I was hoping to use for remote file access.  Is anyone aware of a
> public-domain NFS client that can be made to work with pSOS+?
>
>   Thanks in advance for any information.
>
> --------------------------
> Brian Watkins
> watkins@spk.hp.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: HELP: How to get useful debug info out of an NMI interrupt?
Date: Fri, 08 Nov 1996 13:30:08 -0800
From: John Finley <john@finley.com>
Organization: Netcom
Message-ID: <3283A660.4BBF@finley.com>
References: <3280A6C0.77A2@inigo.us.dg.com>
Reply-To: john@finley.com
Yamudda Wezamibootz wrote:
> Any thoughts out there?  Thanks.
Sometimes I like to set aside some memory that the OS doesn't know
about, then sprintf debug messages to it.  After it dies, you
reboot and go look at the memory.
The OS can't know about the memory so it won't zero it when it boots.
Also, if the memory is DRAM, then there are who's-doing-the-refresh
considerations.
John
- --------------------------------------------------
John Finley                 Engineering Consultant
john@finley.com                  Real Time Systems
(619) 689-0032                Networking Protocols
- --------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Fri, 8 Nov 1996 23:24:40 GMT
From: breti@bit3.com (Bret Indrelee)
Organization: Bit 3 Computer Corp
Message-ID: <E0Krp5.B92@bit3.com>
References: <2.2.32.19961108144450.006ce4c0@mailhost.mclean.sparta.com>
In article <2.2.32.19961108144450.006ce4c0@mailhost.mclean.sparta.com>,
Thomas K. Buchanan <tkb@mclean.sparta.com> wrote:
>>Another annoyance is that none of the routines say which include files
>>are needed. Sure, I have grep and can search the header files. I really
>>would rather just look up the routine and find all the information I
>>need to use it there.
>
>Try checking the SEE ALSO paragraph at the end of all manual entries.  It's
>a pretty standard approach...
Yeah, it is a standard approach. Was also exactly what I was looking for.
I double checked. It seems that they only list Include Files (just above
the See Also) for the libraries, never the individual routines. IntArchLib
has the section at the end of it, but intConnect doesn't.
For some reason, I never noticed it at the end of the library man pages.
Thanks,
- -Bret
- --
Bret Indrelee
breti@bit3.com		#include <std_disclaimer.h>
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Mon, 04 Nov 96 19:46:33 GMT
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star
Message-ID: <55md5u$5b@idiom.com>
References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <gerlachE0CtwF.Ju2@netcom.com> <rypma-0411961259040001@hppadhtr1.waterloo.hp.com>
GNU toolchain certainly works better than any other
cross-deveopment tools I've used, including pSOS with
MRI tools.  Have you actually used those tools?
You can't be serious.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
End of New-News digest
**********************
From tkb@mclean.sparta.com  Sat Nov  9 08:49:57 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Sat Nov  9 08:49:59 PST 1996
Subject: Re: Tornado Launcher
>When I start the launcher the launcher window appears, but none of the
bitmaps, buttons, or menu items appear.
>The targets and information list boxes do appear, but there is no title
above either of them as shown in the
>Tornado User's guide.  Obviously it's pretty useless this way.  I also get
a ton of translation error messages in the
>text window where start LAUNCH from.  My host is a SPARC running Sun
Solaris 2.  I connect to the host via rlogin
>on an x-station and am trying to run the Tornado launcher at the x-station.
I would appreciate any ideas on this.
You are having permission problems with some of the Tcl stuff.  Look in the
vw/host/resource tree for files w/o read permissions for everyone.  Wind
River ships Tornado with permissions setup for a user and group specified at
order time.  Many files have no 'world' permissions at all.  If you like not
having world permissions on those files, you'll have to straighten out your
group permission setup.  Check with the system administrator.
HTH
-----------------------------------------
     /\\     Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  7926 Jones Branch Drive
 / \\\\\  \\ Suite 900
 \  \\\\\ // McLean, VA 22102
  \  //////
   \//////   Voice: 703 448 0210
    \////    FAX:   703 893 5494
     \//     WWW:   www.mclean.sparta.com
From daemon@csg.lbl.gov  Sun Nov 10 04:00:30 1996
From: daemon@csg.lbl.gov
Date: Sun Nov 10 04:00:32 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Nov 10 04:00:25 PST 1996
        Subject: MVME 160X Users
        Subject: Delta-Tau PMAC Driver
        Subject: VME memory cards
        Subject: Re: Seeking XDR functions/types
        Subject: NTP on VxWorks 5.2 and/or 5.3
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: MVME 160X Users
Date: Tue, 05 Nov 1996 09:35:54 +0000
From: Doug Owens <owens2@llnl.gov>
Organization: Lawrence Livermore National Lab
Message-ID: <327F0A0C.DE5@llnl.gov>
Reply-To: owens2@llnl.gov
Does the MV1603/4 board from Motorola have L2 cache available?  There
literature is a little vague on this issue.
Thanks,
Doug Owens (owens2@llnl.gov)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Delta-Tau PMAC Driver
Date: 9 Nov 1996 14:28:49 -0500
From: atathert@mtu.edu (Adam T. Atherton)
Organization: Michigan Technological University
Message-ID: <562m1h$1lf@maxwell14.ee>
I am working on a student project using the PMAC board, and if
possible I would like a copy of the driver too.
Thanks,
Adam Atherton
atathert@mtu.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: VME memory cards
Date: 6 Nov 1996 19:07:30 GMT
From: bhanson@bnr.ca (Brian Hanson)
Organization: Bell-Northern Research Ltd.
Message-ID: <55qnli$ls5@crchh327.rich.bnr.ca>
Hi all,
Does anyone had any experience(good/bad) using VME memory cards
to expand local RAM?  I am using Motorola MV167 and MV162 cards
in a shared memory network configuration.  I am interested in
any problems/issues people may have encountered, along with any
hints or advice. Any information is appreciated.
Thanks,
Brian Hanson
bhanson@nortel.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Seeking XDR functions/types
Date: 6 Nov 1996 14:29:28 -0700
From: softweyr@xmission.xmission.com (Softweyr LLC)
Organization: XMission Internet (801 539 0900)
Message-ID: <55qvvo$juh@xmission.xmission.com>
References: <55b90v$k93@hacgate2.hac.com>
scott@tcville.es.hac.com wrote:
: I am seeking some XDR functions/source to allow
: data xport (socket based) between a VxWorks target
: and a Unix host (AIX & Solaris).
Do you want XDR, or XDR-like functionality?  I have a sample C++ class
whose purpose is to allow the programmer to easily serialze and
deserialize data packets of arbitrary structure; we use it for both
serial and LAN connections.  I've used it on VxWorks, FreeBSD, and HP-UX
(so far).  I'll gladly e-mail or post it if you wish.
- ---
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: NTP on VxWorks 5.2 and/or 5.3
Date: Wed, 06 Nov 1996 12:03:06 -0800
From: Gary Steven Fish <gsfish@ccgate.hac.com>
Organization: Hughes Aircraft Co. WSS/NAMS
Message-ID: <3280EEFA.38EF@ccgate.hac.com>
Does anyone have a port or information on a port of ntp to VxWorks 5.2 and/or 5.3.
I know there is a port of ntp3.1 to VxWorks 5.02 on the VxWorks Archive, and I have that as a starting point.
I understand that there may be some issues with functions need by the current port of ntp (to the VxWorks 5.02
version) that are not available in the VxWorks 5.2 version now that some functionality has moved up to the
POSIX standards.
If you have any Information on this topic, please respond.
Thanks in advance,
Gary S. Fish
Hughes Aircraft Co.
---------------------------
End of New-News digest
**********************
From prb@aplexus.jhuapl.edu  Mon Nov 11 05:04:09 1996
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Mon Nov 11 05:04:11 PST 1996
Subject: Re: Are you happy with Vx Works
CK Wong writes:
>
> Does Anyone has any experience and opinion on VxWorks regarding:
>
> 1. VxWorks on PowerPC
>
Irregardless of what OS that you use for PowerPC, I strongly
recommend that you check out the eratta on the Universe PCIbus to
VMEbus bridge chip. The Universe bridge chip is used on practically
every PowerPC VMEbus board. Visit Tundra's web page to find
the list of eratta:  http://www.tundra.com/
Also, if you want to get the best performance using vxWorks
on PowerPC then you might want to consider the GreenHills compiler.
This definitely gave us a noticeable boost in our number crunching algorithms.
+====================================================================+
|       __     ____         __     __                                |
|      /\ \   /  \ \       /\_\__ /\ \      Johns Hopkins University |
|     /  \_\ | /\ \ \     / / /\_\\ \ \     Applied Physics Lab.     |
|    / /\ | |\ \/  \ \   / / / / / \ \ \                             |
|   /  \/ |_| \  /\ \_\ / / / / /   \ \ \   Paul R. Bade             |
|  / /\__/_/   \ \ \/_// / / / /    / / /   (301)-953-6000 x8681     |
| / / /         \ \_\  \ \/ / /    / / /    prb@aplexus.jhuapl.edu   |
| \/_/           \/_/   \__/_/     \/_/                              |
|               __     ____         __       __                      |
|              /\ \   /  \ \       /\ \     /\ \                     |
|             /  \_\ | /\ \ \     /  \_\   /  \ \                    |
|            / /\ | |\ \/  \ \   / /\ |_| / /\ \ \                   |
|           /  \/ |_| \  /\ \_\ / / / | | \/ /  \ \                  |
|          / /\  / /   \ \ \/_// / / / /    / /\ \_\                 |
|          \ \/ / /     \ \_\  \ \/ / /     \/ / / /                 |
|           \__/_/       \/_/   \__/_/        /_/_/                  |
|                                                                    |
+====================================================================+
From al@columbia.mcd.mot.com  Mon Nov 11 07:23:52 1996
From: Al Currano <al@columbia.mcd.mot.com>
Date: Mon Nov 11 07:23:55 PST 1996
Subject: Re: Cache on MVME1603/1604 Boards
the vxWorks Users Group Exploder wrote:
>
> Newsgroups: comp.os.vxworks
> Subject: MVME 160X Users
> Date: Tue, 05 Nov 1996 09:35:54 +0000
> From: Doug Owens <owens2@llnl.gov>
> Organization: Lawrence Livermore National Lab
> Message-ID: <327F0A0C.DE5@llnl.gov>
> Reply-To: owens2@llnl.gov
>
> Does the MV1603/4 board from Motorola have L2 cache available?  There
> literature is a little vague on this issue.
>
> Thanks,
> Doug Owens (owens2@llnl.gov)
>
Yes, Doug, the MVME1603 / 1604 boards are available with L2 Cache. When
these boards were first introduced about two years ago, there was no
cache option. Since then, however, a number of models have been
introduced with 256K L2 Cache. (Unfortunately, the data sheets & Web
pages don't have all of the information. I will try to get this
rectified.)
The MVME1603 is available in both 100 MHz and 200 MHz clock speeds with
256K L2 Cache. Part numbers are MVME1603-04x, -05x, -06x and -07x. The
different suffixes correspond to different I/O pinouts, clock speeds &
main memory sizes (the "x" can be 1, 2, 3 or 4, corr. to main memory
sizes of 8, 16, 32 and 64 MB). The MVME1604 is available in the 133 MHz
clock speed with 256K L2 cache. Part numbers are MVME1604-02x  and
MVME1604-03x.
Contact your local sales office (408) 991-8634 for more information.
Regards,
Al
--
Al Currano                     _/      _/    _/_/_/_/_/    _/_/_/_/_/
al_currano@mcg.mot.com         _/_/  _/_/    _/      _/    _/      _/
Motorola Computer Group        _/ _/_/ _/    _/            _/
8945 Guilford Rd., Ste 145     _/  _/  _/    _/            _/
Columbia, MD  21046            _/      _/    _/            _/    _/_/
Phone:   (410)  312-5930       _/      _/    _/      _/    _/      _/
FAX:     (410)  381-4496       _/      _/    _/_/_/_/_/    _/_/_/_/_/
From genard@imaginet.fr  Mon Nov 11 07:46:01 1996
From: genard@imaginet.fr (genard michel)
Date: Mon Nov 11 07:46:03 PST 1996
Subject: hello
salut Philippe,
je suis dans de nouvelle avneture avec ATI (nucleus)
www.atinucleus.com
les bureaux sont a courtabouef (on reveint toujours sur les leiux du crime)
tel 01 60 92 41 11
salut, pardon kenavo et j espere que toute ta famille va bien,
michel
+---------------------------------+----------------------------------+
|    genard@imaginet.fr           |  tel/voice +33 2 54 88 25 36     |
|       Michel Genard             |  fax       +33 2 54 88 50 10     |
|                                    mobile    +33 6 07 44 84 70     |
+---------------------------------+----------------------------------+
************** N E W  P H O N E  #  Take a Look ! *******************
From letchu@zeke.as.utexas.edu  Mon Nov 11 10:28:52 1996
From: Lakshmanan Narayanan <letchu@zeke.as.utexas.edu>
Date: Mon Nov 11 10:28:54 PST 1996
Subject: unsubscribe
unsubscribe
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lakshmanan Narayanan (Letchu)      Email: letchu@zeke.as.utexas.edu
McDonald Observatory               URL  : http://zeke.as.utexas.edu/letchu
University of Texas at Austin      Voice: 512-471-7450
Austin, TX 78751.	  	   Fax  : 512-471-6016
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From YF.Siu@eng.efi.com  Mon Nov 11 11:03:24 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Mon Nov 11 11:03:30 PST 1996
Subject: ATA2 IDE driver wanted ?
Anyone that's kind enough to share the source of an
ATA-2 IDE CD-ROM driver for VxWorks ?
Thanks,
YF
From dfraser@wrs.com  Mon Nov 11 18:08:16 1996
From: David Fraser <dfraser@wrs.com>
Date: Mon Nov 11 18:08:18 PST 1996
Subject: Are you happy with VxWorks
(Apologies if your get a duplicate of this message directly on
comp.os.vxworks.  We've had some weirdness from our news server forwarding
correctly)
Dear Users,
Everyone here at Wind River has been following this particular thread very
closely.  Far from ignoring the newsgroup and exploder, I think that all of
us see it as a vital link to the user community.  It's become something of
an informal policy of ours, however, not to make too many postings.  We
have in mind the double-edged sword of communication which can classify us
either as being defensive or involved in shameless self-promotion.  But
we're ready and willing to respond more immediately if that's what you want
from us, and we think it appropriate.
Since I've started, I probably should comment on the main issues that seem
to have surfaced in this thread: the functionality/usability of Tornado,
and our support capability.  As VP Engineering, with the responsibility for
Customer Service this is, after all, what I'm paid to worry about!
First of all, Tornado has been out for just about a year and was a big
effort for our company.  As a medium-sized outfit, Wind River definitely
regards a ~50 engineering year effort as significant, although for many of
you out there these would be small projects!  Far from being some piece of
"marketing fluff" as some have suggested, we engineers here had some
definite goals in mind for Tornado, over and above our traditional focus on
making VxWorks a capable OS.  These goals were (a) to make high end
development tools work on very small scale systems (little memory, no
Ethernet, for example) (b) to make the system customizable and extensible
so that it could be modified by our customers to make it work in as
productive a manner as possible and (c) to define and publish an API to the
tool framework so that all manner of development tools could be brought to
bear on the engineering problem at hand.
Whether you agree or disagree that these goals were smart priorities or
not, that's what Tornado was all about and that's what the project came up
with.  But it doesn't mean we're abandoning any focus on the RTOS, which is
after all one of our crown jewels -  we have lots of new things in the pipe
there!  We decided on these goals specifically to encourage innovation in
the tools arena and to make everything work on the deeply embedded systems
that many of our customers are working with.  Of course, we have a huge and
growing number of users with VME targets and other resource rich hardware
that may not care about the host-based tools.  But we believe the new
architecture of Tornado will bring about several advantages for these users
also.  After all, the unlimited "headroom" on the host will allow us to do
really fancy things with the shell, linker, etc. that the target-based
approach penalized us too heavily for.  And already goals (b) and (c) are
making all manner of new tools available from our partners, which is
perhaps the thing that I'm most excited about.
Beyond this, the embedded world has changed enormously.  There are many,
many more embedded developers entering our community, as people take
advantage of newer and cheaper microprocessors to build all manner of
leading edge products.  We've tried to serve these newer developers by
making Tornado available on Windows (as many come from this space) and to
make the tools easier to drive by using GUI facilities.  Of course, power
users can still dive into the command line if they wish!
With the health of this embedded business comes the challenge of extreme
growth.  Wind River is growing sales at almost 50% per year, and this
astonishing pace translates into lots of new users expecting support.  This
is our biggest challenge, and everyone in the executive staff at Wind River
is cognizant of it.  Our Customer Support operation is composed of smart
and committed individuals, but we need to constantly staff up to handle the
demand.  We're hiring as quickly as we can, both junior support engineers
and senior people with real world embedded experience, but these people are
hard to find.  We'll continue to hire the best we can find, and spend as
much as it takes on new tools and technologies to improve our
responsiveness.  Additionally we are increasing our emphasis on maintenance
releases within R&D, and placing more support function out in our field to
be "closer to the customer".  Today the ratio of R&D to service is about
2:1 and I would expect the service content to increase as we move forward.
Finally, please accept my thanks on behalf of everyone at Wind River for
your comments.  If there's something that I think sets Wind River apart
from most of the companies I've ever worked for it's that we are
enthusiasts for our technology: we want to make the best products and
services that we can.  Our outstanding low level of attrition speaks highly
to how committed and long term a team we have here working on that
objective.  Your feedback is essential at helping us.
Regards,
David Fraser
VP Engineering,
Wind River Systems
From malcolm.cifuentes@nautronix.com.au  Mon Nov 11 19:16:35 1996
From: malcolm.cifuentes@nautronix.com.au (Malcolm Cifuentes)
Date: Mon Nov 11 19:16:37 PST 1996
Subject: GNU Development
Hi all,
    I would like to know :
    1/ Is any one doing development on the PPC using the GNU compiler
       in tornado.
    2/ What steps did you take to get around the IOSTREAMS problem.
    3/ Does any one know if the Wind Foundation Classes can be used
       with the GNU compiler, and if so is any one using this combination.
thanks in advance
--
Malcolm Cifuentes
(
 Nautronix LTD
 malcolm.cifuentes@nautronix.com.au
 PH  : +61-09-430-5900
 FAX : +61-09-430-5901
)
From daemon@csg.lbl.gov  Tue Nov 12 04:00:25 1996
From: daemon@csg.lbl.gov
Date: Tue Nov 12 04:02:34 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Nov 12 04:00:23 PST 1996
        Subject: Re: Are uou happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Are you happy with VxWorks
        Subject: RAID max size?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are uou happy with Vx Works and Wind River
Date: 10 Nov 1996 12:34:16 -0800
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <565e88$6q7@idiom.com>
References: <E0n8uC.3rG@supernet.hellnet.org> <565e0f$5a0@idiom.com>
Apparently I'm nobody@nowhere, according to my brilliant
Windoze news-program.
In article <565e0f$5a0@idiom.com>,  <nobody@nowhere> wrote:
I don't mean to sound like an apologizer for Tornado,
because I don't use Tornado IDE due to its bugs, but
blaming WRS for trying to make money on their product
by hyping it is like blaming the Pope for being against
abortion.  It's the nature of business.
The fact is, even with all bugs and misfeatures, VxWorks
is the best RTOS in existence.  Unless someone comes
out with something better, we're stuck with it.  The
thing to do, then, is to encourage WRS to fix problems.
I am frequently accused of being negative on WRS for
exposing VxWorks problems.  I am also accused of bashing
WRS for selling out to military market.  I'm guilty of
both.  Although I'm less critical on the latter part now,
because WRS doesn't seem to depend as much on military
customers.  However, I'd never accuse WRS for hyping
their product.  It's all BS, but that's what marketing is.
I'd rather hope that WRS will fix a number of fundamental
problems:
1. broken stdio architecture.  The ioGlobalStd stuff has
to go.  I've seen too many people lose their mind over this.
2. broken filesystem architecture -- vxWorks does not have
one.  All filesystems are implemented as IO drivers and
libraries.  This creates a number of annoying problems and
breaks consistent interface for simple things like ls().
3. non-reentrant target shell.  Tornado adds bandages to
this problem by allowing multiple instantiations of tcl
infused shell-lookalikes.  This breaks the consistency
of user interface even more -- for example, i() implemented
in tcl vs. i() implemented in C -- there is no reconciliation
or attempt to resolve oddities that arise from this.
4. use of #include on C files in the config/all files.
#include is meant for H files not C files.  This creates
subtle problems, and there are cleaner alternatives.
5. techsupport.  It's terrible.
etc.
I could go on and on...
- --
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: 11 Nov 1996 18:30:35 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <568ngb$nb6@elaine25.Stanford.EDU>
References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> <E0IqIr.FxF@bit3.com>
In article <E0IqIr.FxF@bit3.com>, Bret Indrelee <breti@bit3.com> wrote:
>In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>,
>Mike Anderson  <mea@mclean.sparta.com> wrote:
>Another annoyance is that none of the routines say which include files
>are needed. Sure, I have grep and can search the header files. I really
>would rather just look up the routine and find all the information I
>need to use it there.
Look up the routine in the reference manual. You include the .h file
corresponding to the library the routine is defined in. For example,
to use "sigvec" you include "sigLib.h" because this routine is defined
in "sigLib". Foreach function the manual tells you what lib its in.
The old manuals said explicity which .h file to include. Now its
implicit in the name of the library (i.e. just add .h to lib name).
Don't know why they did it this way but its not that big a deal.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 1996 08:35:37 -0600
From: Steve Woloschek <woloschekS@med.ge.com>
Organization: GE Medical Systems
Message-ID: <3280A239.2CD2@med.ge.com>
References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>
I would have suggested the complete opposite of Mike's comment.
My opinion is that vxWorks is best suited for a large embedded
project. One that has ethernet and lots of Flash and RAM.
An ethernet or serial connection is exactly how WRS wants you
to debug. This scenario doesn't work well in a smaller embedded
environment, i.e. limited RAM/Flash, no ethernet, no serial.
It took me a number of phone calls to WRS and a lot of investigation
of a BSP do get the vxWorks kernel down from 120k to 50k. This
is large for some embedded environments.
Steve Woloschek
> Mike Anderson wrote:
>
> 4)  Now, what about Tornado?  If you were to believe all of the press (and
>     the WRS salescritters), Tornado is a radically new development approach
>     that will revolutionize the industry.  However, I believe that in an
>     effort to increase sales, improve the stock price, etc. that many at WRS
>     have lost sight of the *real* product.  That is, the base VxWorks O/S
>     that runs on the target.  Tornado seems to be well suited for the
>     development model of those large companies such as HP wherein they are
>     embedding VxWorks into a printer.  That is, when you don't have much
>     RAM, no serial console ports, and maybe no Ethernet, then Tornado
>     represents a fine development environment *in theory*.  And, I
>     believe, that the Unix implementation comes pretty close to realizing
>     that environment in practice.  However, from what I've heard from the
>     net, I believe that there are some serious problems (memory leaks, etc.)
>     in the Tornado product under Win 95 & Win NT.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 06 Nov 1996 08:40:24 -0600
From: Steve Woloschek <woloschekS@med.ge.com>
Organization: GE Medical Systems
Message-ID: <3280A358.6F0@med.ge.com>
References: <9611052007.AA27240@wgsu13.kns.com>
> because I've been waiting for a quote from the sales guy for over a month.
>
> Joe DeAngelo
And you can expect the sales rep to never call you again after you sign
the
deal. I left a message with ours 2 months go. Apparently there is no
follow
up to see how things are going after the deal has been signed.
WRS also owes me some code that is more than 2 months overdue past the
original agreed upon date.
Steve Woloschek
---------------------------
Newsgroups: comp.os.vxworks
Subject: Are you happy with VxWorks
Date: 8 Nov 1996 20:25:24 GMT
From: "David Fraser" <dfraser@wrs.com>
Organization: Wind River Systems
Message-ID: <01bbcdb3$e358ac60$0e2b0b93@abyss.wrs.com>
Dear Users,
Everyone here at Wind River has been following this particular thread very
closely.  Far from ignoring the newsgroup and exploder, I think that all of
us see it as a vital link to the user community.  It's become something of
an informal policy of ours, however, not to make too many postings.  We
have in mind the double-edged sword of communication which can classify us
either as being defensive or involved in shameless self-promotion.  But
we're ready and willing to respond more immediately if that's what you want
from us, and we think it appropriate.
Since I've started, I probably should comment on the main issues that seem
to have surfaced in this thread: the functionality/usability of Tornado,
and our support capability.  As VP Engineering, with the responsibility for
Customer Service this is, after all, what I'm paid to worry about!
First of all, Tornado has been out for just about a year and was a big
effort for our company.  As a medium-sized outfit, Wind River definitely
regards a ~50 engineering year effort as significant, although for many of
you out there these would be small projects!  Far from being some piece of
"marketing fluff" as some have suggested, we engineers here had some
definite goals in mind for Tornado, over and above our traditional focus on
making VxWorks a capable OS.  These goals were (a) to make high end
development tools work on very small scale systems (little memory, no
Ethernet, for example) (b) to make the system customizable and extensible
so that it could be modified by our customers to make it work in as
productive a manner as possible and (c) to define and publish an API to the
tool framework so that all manner of development tools could be brought to
bear on the engineering problem at hand.
Whether you agree or disagree that these goals were smart priorities or
not, that's what Tornado was all about and that's what the project came up
with.  But it doesn't mean we're abandoning any focus on the RTOS, which is
after all one of our crown jewels -  we have lots of new things in the pipe
there!  We decided on these goals specifically to encourage innovation in
the tools arena and to make everything work on the deeply embedded systems
that many of our customers are working with.  Of course, we have a huge and
growing number of users with VME targets and other resource rich hardware
that may not care about the host-based tools.  But we believe the new
architecture of Tornado will bring about several advantages for these users
also.  After all, the unlimited "headroom" on the host will allow us to do
really fancy things with the shell, linker, etc. that the target-based
approach penalized us too heavily for.  And already goals (b) and (c) are
making all manner of new tools available from our partners, which is
perhaps the thing that I'm most excited about.
Beyond this, the embedded world has changed enormously.  There are many,
many more embedded developers entering our community, as people take
advantage of newer and cheaper microprocessors to build all manner of
leading edge products.  We've tried to serve these newer developers by
making Tornado available on Windows (as many come from this space) and to
make the tools easier to drive by using GUI facilities.  Of course, power
users can still dive into the command line if they wish!
With the health of this embedded business comes the challenge of extreme
growth.  Wind River is growing sales at almost 50% per year, and this
astonishing pace translates into lots of new users expecting support.  This
is our biggest challenge, and everyone in the executive staff at Wind River
is cognizant of it.  Our Customer Support operation is composed of smart
and committed individuals, but we need to constantly staff up to handle the
demand.  We're hiring as quickly as we can, both junior support engineers
and senior people with real world embedded experience, but these people are
hard to find.  We'll continue to hire the best we can find, and spend as
much as it takes on new tools and technologies to improve our
responsiveness.  Additionally we are increasing our emphasis on maintenance
releases within R&D, and placing more support function out in our field to
be "closer to the customer".  Today the ratio of R&D to service is about
2:1 and I would expect the service content to increase as we move forward.
Finally, please accept my thanks on behalf of everyone at Wind River for
your comments.  If there's something that I think sets Wind River apart
from most of the companies I've ever worked for it's that we are
enthusiasts for our technology: we want to make the best products and
services that we can.  Our outstanding low level of attrition speaks highly
to how committed and long term a team we have here working on that
objective.  Your feedback is essential at helping us.
Regards,
David Fraser
VP Engineering,
Wind River Systems
---------------------------
Newsgroups: comp.os.vxworks
Subject: RAID max size?
Date: Mon, 11 Nov 1996 09:46:38 -0500
From: Richard Price <richard.price@lsoc114x.ksc.nasa.gov>
Organization: United Space Alliance
Message-ID: <32873C4E.74F6@lsoc114x.ksc.nasa.gov>
Has anyone else seen or hit the vxworks maximum disk storage size?  I believe it is somthing around 4-6 Gbytes.
Richard Price at KSC
---------------------------
End of New-News digest
**********************
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 12 06:53:42 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 12 06:53:45 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Tue, Nov 12, 1996 5:38 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 12, 1996 6:51 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From bf@kayser-threde.de  Tue Nov 12 06:55:21 1996
From: Florian Bittner <bf@kayser-threde.de>
Date: Tue Nov 12 06:55:23 PST 1996
Subject: SSI 78Q8373
Hello,
has anybody out there tried the Silicon Systems 78Q8373 Ethernet chip ?
We are going to use it in a custom hardware design with a CPU32.
I would be glad to hear about experiences and/or available software for
testing or VxWorks drivers.
Greetings from Munich,
TNX
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQB1AwUBMdks8VE0+SThqPHNAQHwoAMAouqwFY9xlm2MrOJm4Vt9QEFAxPPOJqNP
3vrdyLzRel0/nPsG3J4p/q38/DUGm69P/OUJBVGTuq8Hg53HAqUI4J3+jX1Bz/YI
rTiRta7kRTTd/skoN88CJSSA9TGsb8v0
=FwhG
-----END PGP SIGNATURE-----
Florian Bittner                 Software Engineer            __  __
Kayser-Threde GmbH              Tel +49 89 78720 83         |  |/  /
Perchtingerstr.3                Fax +49 89 78720 98         | ====<
81379 Munich                    Germany                     |__|\__\
From jbrandt@sadira.gb.nrao.edu  Tue Nov 12 06:56:24 1996
From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT)
Date: Tue Nov 12 06:56:26 PST 1996
Subject: Re: Are you happy with VxWorks
I'm glad to hear that Wind River's sales are doing so well. VxWorks is a
solid product, however, as other have stated, it lacks several technologies.
Let's face it, we all have looked around for real-time O.S's and found that
VxWorks is on the high end of the pricing scale. Well, what you pay for should
be what you get. But I find that Wind River can be quite unresponsive to our
needs.
Case in point, Multicast support. The changes to the networking code to enable
RFC-1112 level 2 multicast support have been out on the net for years now.
At least two persons I know have patched and tested the VxWorks networking
code to add multicasting, AND SENT the patches back to WRS.
Ask WRS about this and they have no knowledge of it. For pretty much zero
effort, they could have added this technology.
Why is multicasting a big deal in a RT-OS?
How many of your RT systems have some sort of monitoring? Multicast allows
a single packet sent from a VxWorks system to be delivered to any number
of monitoring stations. For efficientcy reasons multicast is the way to go.
I'm sure there are other examples like this out there.
------------------------------------------------------------------------
    _/       _/   _/_/_/_/       _/           _/_/_/     National
   _/ _/    _/   _/      _/    _/ _/        _/     _/    Radio
  _/   _/  _/   _/_/_/_/      _/____/      _/     _/     Astronomy
 _/     _/_/   _/      _/    _/     _/    _/     _/      Observatory
_/       _/   _/        _/  _/       _/    _/_/_/        Green Bank, WV
Joe Brandt (N0NYO) N.R. EMT/FF          jbrandt@nrao.edu (304)456-2210
------------------------------------------------------------------------
From jhend@primenet.com  Tue Nov 12 07:08:10 1996
From: John R Henderson <jhend@primenet.com>
Date: Tue Nov 12 07:08:12 PST 1996
Subject: VxMP
We are using the VxMP package in version 5.2.
I would like to modify the behavior of the VxMP such that the call to
usrSmObjInit does not cause the bootup to wait for processor #0 to write
a sequence number to shared memory, and for that matter, never write a
sequence to shared memory.  Currently VxMP does so every second.  Our
application essentially performs this function and I don't want to
duplicate it.  Does anyone know how I can do what I want with VxMP?
Most of all, I would like to dynamically setup the kernel to be the
master or slave at run-time.
Furthermore, is there any problem with delaying the call to
usrSmObjInit until after our application is up and running?
Thank you,
John R Henderson
HMSC
From dleviner@HiWAAY.net  Tue Nov 12 07:14:48 1996
From: David Leviner <dleviner@HiWAAY.net>
Date: Tue Nov 12 07:14:50 PST 1996
Subject: run VxWorks in FLASH?
Hi all,
I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the
embedded application and the board real estate is limited for adding more DRAM.
Because of these issues the board manufacturer (our customer) is wanting us to
look into the possibility of running VxWorks in FLASH.
First of all, I've never been presented with this memory problem. We've never had
this type of DRAM limitation. If I'm going to do this, I am assuming that I will
have to run the text section of VxWorks (instructions, constants,etc.) in FLASH
and the data section of VxWorks (i.e., C variables) in DRAM. I know with
Microsoft compilers/linkers you can relocate code in this manner. Is it
possible to do the same in the kernel build for VxWorks. If so, has anyone done
this?
Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
how?
Thanks for the advice.
--
David Leviner
Systems Engineer
Chandler/May, Inc. (CMI)
125 West Park Loop
Huntsville, AL  35806
(205)722-0175
(205)722-0144 (fax)
dleviner@HiWAAY.net
From dleviner@HiWAAY.net  Tue Nov 12 07:21:23 1996
From: David Leviner <dleviner@HiWAAY.net>
Date: Tue Nov 12 07:21:25 PST 1996
Subject: GP-IB Interface
Hi all,
Does anyone have any info on a GP-IB interface (general purpose
instrumentation bus) VxWorks driver. This interface is based on the TI
TMS9914 controller.
Thanks fo the info.
--
David Leviner
Systems Engineer
Chandler/May, Inc. (CMI)
125 West Park Loop
Huntsville, AL  35806
(205)722-0175
(205)722-0144 (fax)
dleviner@HiWAAY.net
From dleviner@HiWAAY.net  Tue Nov 12 07:24:47 1996
From: David Leviner <dleviner@HiWAAY.net>
Date: Tue Nov 12 07:24:48 PST 1996
Subject: VGA Drivers
Hi all,
Does anyone have any info on VxWorks VGA drivers.
The VGA controller is from Chips and Technologies 65535 (ISA
Implementation)
Thanks fo the info.
--
David Leviner
Systems Engineer
Chandler/May, Inc. (CMI)
125 West Park Loop
Huntsville, AL  35806
(205)722-0175
(205)722-0144 (fax)
dleviner@HiWAAY.net
From rtsc@worldnet.net  Tue Nov 12 07:51:49 1996
From: rtsc <rtsc@worldnet.net>
Date: Tue Nov 12 07:51:51 PST 1996
Subject: Disk defragmentation
I look for the source code of a DOS disk defragmenter utility
already ported or to be ported on VxWorks. If you have any
information, please contact me at bdupre@rtsc.worldnet.net.
Bernard Dupre
From Scott.Peters@agai.com  Tue Nov 12 09:22:11 1996
From: Scott Peters <Scott.Peters@agai.com>
Date: Tue Nov 12 09:22:13 PST 1996
Subject: RE: WRS User's group meeting
Hello:
Sorry to bother you if you are not the correct person to write to about
this.
In a response you said there is a WRS user conference coming up in Jan.
Please, let me know how to find out more information or to get
registration.
Thanks
Scott Peters
AG Associates
scott.peters@agai.com
From aaronn@telerobot.com  Tue Nov 12 09:46:06 1996
From: aaronn@telerobot.com (Aaron Needles)
Date: Tue Nov 12 09:46:12 PST 1996
Subject: IP Carrier board...
     Does anyone know of an IP Carrier board manufacturer for 3U VME?  Any
     hints would be greatly appreciated!
     Thanks,
         Aaron Needles
         aaronn@telerobot.com
From jford@sadira.gb.nrao.edu  Tue Nov 12 10:01:44 1996
From: jford@sadira.gb.nrao.edu (John Ford)
Date: Tue Nov 12 10:01:46 PST 1996
Subject: Re: GP-IB Interface
   Submitted-by dleviner@HiWAAY.net  Tue Nov 12 07:21:23 1996
   Submitted-by: David Leviner <dleviner@HiWAAY.net>
   Hi all,
   Does anyone have any info on a GP-IB interface (general purpose
   instrumentation bus) VxWorks driver. This interface is based on the TI
   TMS9914 controller.
   Thanks fo the info.
   --
   David Leviner
   Systems Engineer
   Chandler/May, Inc. (CMI)
   125 West Park Loop
   Huntsville, AL  35806
   (205)722-0175
   (205)722-0144 (fax)
   dleviner@HiWAAY.net
We have a C++ handler library for the Mizar VME7500, which uses the TMS9914A
chip.  You are welcome to it.  It is not a vxWorks device driver,
though.
--
John Ford
National Radio Astronomy Observatory
Green Bank, WV 24944-0002
jford@nrao.edu
From jrturne@isrc.sandia.gov  Tue Nov 12 10:26:36 1996
From: "J.R. Turner" <jrturne@isrc.sandia.gov>
Date: Tue Nov 12 10:26:38 PST 1996
Subject: Unsubscribe
Unsubscribe
Take care,
J.R. Turner, MS 1176             Intelligent Systems Robotics Center
Email: jrturne@sandia.gov        Sandia National Laboratories
Phone: (505)845-9069             PO Box 5800
Fax: (505)284-4594               Albuquerque, NM 87185-1176
From pean@mbari.org  Tue Nov 12 11:04:09 1996
From: Andrew Pearce <pean@mbari.org>
Date: Tue Nov 12 11:04:11 PST 1996
Subject: Re: IP Carrier board...
Hi,
Greenspring lists a product in their catalog that might work
for you. Its described as 3U IP carrier, part number VPIC310.
I've never this product but I have used the IP octal modules
and they work great.
--
Andrew Pearce                            | email: pean@mbari.org
Monterey Bay Aquarium Research Institute | tel:   (408) 775-1746
7700 Sandholt Rd                         | fax:   (408) 775-1646
Moss Landing, CA 95039                   | URL:   http://www.mbari.org/~pean
"Coping's easy.  Not pureeing your loved ones, that's the hard part."
Basil Fawlty
From pean@mbari.org  Tue Nov 12 11:05:27 1996
From: Andrew Pearce <pean@mbari.org>
Date: Tue Nov 12 11:05:28 PST 1996
Subject: Re: IP Carrier board...
Hi,
Greenspring lists a product in their catalog that might work
for you. Its described as 3U IP carrier, part number VPIC310.
I've never this product but I have used the IP octal modules
and they work great.
--
Andrew Pearce                            | email: pean@mbari.org
Monterey Bay Aquarium Research Institute | tel:   (408) 775-1746
7700 Sandholt Rd                         | fax:   (408) 775-1646
Moss Landing, CA 95039                   | URL:   http://www.mbari.org/~pean
"Coping's easy.  Not pureeing your loved ones, that's the hard part."
Basil Fawlty
From jhillman@wrs.com  Tue Nov 12 11:10:02 1996
From: Jon Hillman <jhillman@wrs.com>
Date: Tue Nov 12 11:10:04 PST 1996
Subject: Re: GNU Development
At 07:16 PM 11/11/96 PST, Malcolm Cifuentes wrote:
>Hi all,
>    I would like to know :
>
>    1/ Is any one doing development on the PPC using the GNU compiler
>       in tornado.
>    2/ What steps did you take to get around the IOSTREAMS problem.
>    3/ Does any one know if the Wind Foundation Classes can be used
>       with the GNU compiler, and if so is any one using this combination.
>
1/   Everyone with Tornado/PPC would use the GNU 2.7 compiler (save those
working
     with Green Hills ADA Multi.
2/   WRS provides the Wind Foundation Classes which include, among other stuff,
     iostreams.  Also included in the WFC is tools.h++, booch, vxworks wrapper
     classes for the os calls.
3/   Yes, they are indeed use WFC with GNU 2.7.
        _________________________
       | Jon Hillman, FAE        |
       | Wind River Systems      |
      /) (407) 273-4646          (\
     / ) Email:jhillman@wrs.com  ( \
   _( (|_________________________) )  />
  (((\ \)  /,)             / )  / //))/
  (\\\\ \_/ /              \ \_/ /////
   \       /                \       /
    \    _/                  \_    /
----/   /----------------------\   \----
   /   /                        \   \
From stan@rti.com  Tue Nov 12 12:11:55 1996
From: Stan Schneider <stan@rti.com>
Date: Tue Nov 12 12:11:58 PST 1996
Subject: RE: WRS User's group meeting
Hi all,
Here's some more advance info on the upcoming user's group meeting:
+++++++++++++++++++++++++++++++++++++++++++++
The upcoming Users Conference and Exhibition will be held on January 13 and
14 in Santa Clara, California.
More details and registration information will be available in a couple of
weeks on the Wind River Web at http://www.wrs.com/usrgroup.html
If you need to plan in advance with your company to attend, here is some
info about costs. Cost for the meeting depend on the option you choose:
Option 1: Pre-conference training + Conference & Exhibition
$250 for advance registration received and paid before January 6, 1997
$350 for regular or on-site registration (after January 6, 1997)
Option 2: Conference and Exhibition only
$75 for advance registration received and paid before January 6, 1997
$100 for regular or on-site registration (after January 6, 1997)
Do not hesitate to contact Claire (claire@wrs.com) or me if you
have any further questions.
        -- Stan
           stan@rti.com
From jhillman@wrs.com  Tue Nov 12 13:17:51 1996
From: Jon Hillman <jhillman@wrs.com>
Date: Tue Nov 12 13:17:53 PST 1996
Subject: Re: VGA Drivers
Sorry about the e-mail with the attachment. I hope this did not
cause a problem with you all.  I thought I was responding directly
to the persons' e-mail rather than to the exploder!  :-(
        _________________________
       | Jon Hillman, FAE        |
       | Wind River Systems      |
      /) (407) 273-4646          (\
     / ) Email:jhillman@wrs.com  ( \
   _( (|_________________________) )  />
  (((\ \)  /,)             / )  / //))/
  (\\\\ \_/ /              \ \_/ /////
   \       /                \       /
    \    _/                  \_    /
----/   /----------------------\   \----
   /   /                        \   \
From froeber@BBN.COM  Tue Nov 12 18:57:13 1996
From: Fred Roeber <froeber@BBN.COM>
Date: Tue Nov 12 18:57:16 PST 1996
Subject: Re: multicast
JOE BRANDT writes:
> But I find that Wind River can be quite unresponsive to our needs.
>
> Case in point, Multicast support. The changes to the networking code to enable
> RFC-1112 level 2 multicast support have been out on the net for years now.
>
> At least two persons I know have patched and tested the VxWorks networking
> code to add multicasting, AND SENT the patches back to WRS.
I am not going to refute Joes point about lack of response from WRS; I
have certainly felt that way enough times.  The thing is, the area of
multicast support is one case where I have some insight into WRS's
position.  It might be useful to consider this case in the broader
context of what it takes to add things to VxWorks.
While I doubt that we are one of the two people Joe refers to, I was part
of a group at my former employer that had a VxWorks source license and
needed to use multicast.  We got the PD code for implementing multicast
and put the changes into the source and passed them back to WRS. The work
wasn't that hard at all.  The only trick was that an efficient implementation
of multicast requires that you take advantage of the hardware packet
filtering that is part of many ethernet chips.  It turns out that when you
are trying to support BSPs which utilize nearly a dozen different ethernet
chips, coming up with a portable way of providing this interface is not
at all trivial; especially since the different chips use radically
different interfaces to provide such filtering.  Thus while it was easy
for us to get our one particular implementation to work, getting it working
in a general fashion would be quite tough.
> Ask WRS about this and they have no knowledge of it. For pretty much zero
> effort, they could have added this technology.
While I certainly go along with Joe that multicast would be nice to have,
I wanted to point out that it wouldn't take "pretty much zero effort".
It seems that what we need is some way of quantifying how much different
users want different capabilities.  Maybe that way we can "help" WRS focus
on trying to develop things we really need.  As an example, I remember back
to when the only way to communicate between processors over the backplane
was the backplane driver.  It's nice but slow.  At some of the user group
meetings a lot of people said a big thing they wanted was faster options
for multiprocessor communication and eventually VxMP showed up which
is quite useful in many situations.  I'm just wondering if there is some
way to create a central list of "the top ten things people want added to
VxWorks"?  Just a suggestion.    Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
   |   See http://www.bbn.com/tv for TraceMaker info    |
From p72950@gmcl.co.uk  Wed Nov 13 01:55:23 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Wed Nov 13 01:55:26 PST 1996
Subject: Re: run VxWorks in FLASH?
Hi there,
We have successfully run VxWorks from FLASH. In our case the build system
was modified to produce the FLASH version as well as the RAM loadable
and BOOTROM version. I produced a new makefile (Makefile.fl) which
*only* does the FLASH version.
The basic changes were:
Change the include of 'defs.bsp' to a local file (or in a relative directory).
More of this later.
Set ROM_TEXT_ADRS & ROM_SIZE to reflect the size & location of the FLASH
devices.
Change HEX_FLAGS to '-a $(ROM_TEXT_ADRS)'
Change the include of rules.bsp to point to a local file (same path as defs.bsp
?).
defs.bsp: Change MACH_DEP to '$(MACH_EXTRA) $(ADDED_MODULES)
rules.bsp: file follows
# rules.bsp - makefile target rules for BSP
#
# SCCS Ref: @(#)rules.bsp	1.1 8/27/96
#
# modification history
# --------------------
# 01h,27aug96,pjq  special version to produce vxWorks.fl. Added SCCS ref.
# 01g,13nov95,jeh  restored .cpp.o implicit rule
# 01f,08nov95,jeh  removed .cpp.o implicit rule
# 01e,01nov95,p_m  added LIB to rom_res build command
# 01d,01nov95,yp   added implicit rules for C++
# 01c,30oct95,dat  added targets vxWorks.res_rom_nosym and
#		   vxWorks.res_rom_nosym_mips
# 01b,27jun95,kkk  added VXSIZE.
# 01a,12jun95,yp   created from makeTarget2 v03d.
#
# DESCRIPTION
# This file contains rules used in building targets.
#
# VARIABLES
# The following variables must be defined (or not, as appropriate):
#
#     ROM_SIZE          number of bytes of ROM space as in config.h
#     LOCAL_MEM_SIZE	target RAM size as in config.h
#     BINHEX		binary->hex file conversion program
#     HEX_FLAGS         BINHEX program options
#     LD_LOW_FLAGS	ld(1) options for code in low memory
#     LD_HIGH_FLAGS	ld options for code in high memory
#     LD_PARTIAL_FLAGS  ld flags for linking partially complete objects
#     LDDEPS		host-specific dependencies prerequisite to linking
#     LDOUT_CONV	hpToBsd, coffToBsd, gswab, /bin/cat, etc.
#     COMPILE_SYMTBL	hide flags needed to get compiler to swallow symTbl.c
#     ROM_ENTRY		rom entry point (typically &romInit)
#     SYS_ENTRY		system entry point (typically &sysInit)
#     USR_ENTRY		compressed system entry point (typically &usrInit)
#
# The following variables are optionally defined:
#
#     LDFLAGS		standard ld flags for vxWorks & ROMs.
#     ROM_LDFLAGS	ld flags specific to ROM image
#
# CONSTANTS
#     CPU               cpu type
#*/
################################################################################
#
# meta build targets
#
## make will default to "exe"
exe	: vxWorks.fl.hex
release : $(RELEASE)
clean   :
	- $(RM) *.o
	- $(RM) vxWorks*
	- $(RM) bootrom*
	- $(RM) depend.$(TARGET_DIR)
.s.o :
	@ $(RM) $@
	$(CPP) $(CASFLAGS) -E $< > tmp.s
	$(CC) $(CFLAGS) -c -o $*.o tmp.s
	@ $(RM) tmp.s
.c.o :
	@ $(RM) $@
	$(CC) $(CFLAGS) -c $<
# rule for munchless C++ compiles
.cpp.o :
	@ $(RM) $@
	$(CXX) $(C++FLAGS) -c $<
# C++ compile and munch
.cpp.out :
	@ $(RM) $@
	$(CXX) $(C++FLAGS) -c $<
	@ $(RM) $@ ctdt.c
	$(NM) $*.o | munch > ctdt.c
	$(MAKE) CC_COMPILER="-traditional" ctdt.o
	$(LD) -r -o $@ $*.o ctdt.o
	@ $(RM) ctdt.c ctdt.o
################################################################################
#
# machine dependent targets
romInit_fl.o: depend.$(BSP_NAME) romInit.s
	- @ $(RM) $@
	- @ $(RM) tmp.c
	- @ $(RM) tmp.s
	- @ $(RM) tmp.i
	$(ASM_P1) romInit.s > tmp.c
	$(CC) $(CASFLAGS) -DROM_RESIDENT -DFLASH_BLD tmp.c > tmp.i
	$(ASM_P2) tmp.i > tmp.s
	$(AS) -o $@ tmp.s
	- @ $(RM) tmp.c
	- @ $(RM) tmp.i
	- @ $(RM) tmp.s
usrConfig.o : depend.$(BSP_NAME) $(USRCONFIG)
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(USRCONFIG) -o $@
bootInit.o : depend.$(BSP_NAME) $(BOOTINIT)
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(BOOTINIT)
bootInit_fl.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o
	- @ $(RM) $@
	$(CP) $(BOOTINIT) bootInit_fl.c
	$(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD bootInit_fl.c
	- @ $(RM) bootInit_fl.c
sysLib_fl.o : depend.$(BSP_NAME) sysLib.c
	- @ $(RM) $@
	$(CP) sysLib.c sysLib_fl.c
	$(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD sysLib_fl.c
	- @ $(RM) sysLib_fl.c
dataSegPad.o: depend.$(BSP_NAME) $(DATASEGPAD) $(CONFIG_ALL_H) config.h
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(DATASEGPAD) -o $@
################################## vxWorks #####################################
#
# vxWorks     - Version setup for FLASH build - no symbol table
vxWorks.fl: depend.$(BSP_NAME) bootInit_fl.o romInit_fl.o \
			usrConfig.o sysALib.o sysLib_fl.o \
			$(MACH_DEP) $(LDDEPS) $(LIBS)
	- @ $(RM) $@ tmp.o
	- @ $(RM) tmp.1
	- @ $(RM) symTbl.c
	- @ $(RM) symTbl.o
	- @ $(RM) $(IMI)
	- @ $(RM) $(IBR)
	- @ $(RM) version.c
	- @ $(RM) version.o
	$(MKVERSION) > version.c
	$(CC) -c $(CFLAGS) version.c
	- @ $(RM) version.c
	$(LD) -o $@ $(LDFLAGS) $(ROM_LDFLAGS) -e $(ROM_ENTRY) \
	    $(RES_LOW_FLAGS) romInit_fl.o bootInit_fl.o usrConfig.o \
	    sysALib.o sysLib_fl.o $(MACH_DEP) version.o $(LIBS)
	$(LDOUT_HOST) $@
	$(ROMSIZEPROG) -b $(ROM_SIZE) $@
	$(LDOUT_CONV) $@
vxWorks.fl.hex: depend.$(BSP_NAME) vxWorks.fl $(IMI)
	- @ $(RM) $@
	$(BINHEX) $(HEX_FLAGS) vxWorks.fl$(TXT_OFFSET) \
		$(IMI_SPEC)$(IMI)$(IMI_OFFSET) > $@$(MAP_EXT)
	-@ $(MV_BIN)
imi :	$(IBR)
	$(LD) -o $@ -Ttext $(IMI_TEXT_ADRS) -Tdata $(IMI_DATA_ADRS) $(IBR)
End of rules.bsp
Note that rules.bsp passes a compile time flag 'FLASH_BLD' into the
compiler. Make sure that the definitions in config.h use an #ifdef FLASH_BLD
to remap the values of ROM_TEXT_ADDRESS & ROM_TEXT_SIZE to the correct
values. This flag can be used anywhere in the BSP files to make compile
time changes to the system.
To build run the Wind River Make (we find it clashes with unix make so have
renamed it 'wrs_make')
wrs_make -f Makefile.fl
It produces the following
vxWorks.fl  - object file mapped to FLASH addresses
vxWorks.fl.hex - S-Record file ready to download to FLASH
If using Tornado you will need to either set the 'Core file' option in the
launcher to point to vxWorks.fl or modify bootConfig.c to notice it is
about to run from FLASH & change the boot parameters to point to it. (We
chose the latter method as it makes it automatic. Also we can change the
'other' parameter to RAM which causes VxWorks to load to RAM as normal).
Regards,
Phil Quiney
>Hi all,
>
>I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
>and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the
>embedded application and the board real estate is limited for adding more DRAM.
>Because of these issues the board manufacturer (our customer) is wanting us to
>look into the possibility of running VxWorks in FLASH.
>
>First of all, I've never been presented with this memory problem. We've never had
>this type of DRAM limitation. If I'm going to do this, I am assuming that I will
>have to run the text section of VxWorks (instructions, constants,etc.) in FLASH
>and the data section of VxWorks (i.e., C variables) in DRAM. I know with
>Microsoft compilers/linkers you can relocate code in this manner. Is it
>possible to do the same in the kernel build for VxWorks. If so, has anyone done
>this?
>
>Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
>how?
>
>Thanks for the advice.
>--
>David Leviner
>Systems Engineer
>Chandler/May, Inc. (CMI)
>125 West Park Loop
>Huntsville, AL  35806
>(205)722-0175
>(205)722-0144 (fax)
>dleviner@HiWAAY.net
>
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From norpires@cygnus.ci.uc.pt  Wed Nov 13 03:35:44 1996
From: "J. Norberto Pires" <norpires@cygnus.ci.uc.pt>
Date: Wed Nov 13 03:35:55 PST 1996
Subject: Re: IP Carrier board...
At 20:19 12-11-1996, you wrote:
>Submitted-by aaronn@telerobot.com  Tue Nov 12 09:46:06 1996
>Submitted-by: aaronn@telerobot.com (Aaron Needles)
>
>
>     Does anyone know of an IP Carrier board manufacturer for 3U VME?  Any
>     hints would be greatly appreciated!
>
>     Thanks,
>         Aaron Needles
>         aaronn@telerobot.com
>
Check Green-Spring Computers
1204 O'briem drive
Menlo Park, CA 94025
(415) 327 - 1200
http://www.GreenSprings.com
norberto
norpires@ci.uc.pt
norberto@andromeda.dem.uc.pt
From nkhurana@hss.hns.com  Wed Nov 13 03:56:22 1996
From: Neeraj_Khurana <nkhurana@hss.hns.com>
Date: Wed Nov 13 03:56:24 PST 1996
Subject: unsubscribe
	unsubscribe
	NEERAJ KHURANA	   nkhurana@hss.hns.com
From daemon@csg.lbl.gov  Wed Nov 13 04:00:21 1996
From: daemon@csg.lbl.gov
Date: Wed Nov 13 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Nov 13 04:00:18 PST 1996
        Subject: need symbios 53c770 scsi driver
        Subject: Problem with bind()
        Subject: Re: run VxWorks in FLASH?
        Subject: Re: Are uou happy with Vx Works and Wind River
        Subject: Is your 5.2 X86 target SLOW?
        Subject: Re: run VxWorks in FLASH?
        Subject: Re: Are you happy with Vx Works and Wind River
        Subject: Re: Are uou happy with Vx Works and Wind River
        Subject: re: multicast
        Subject: Re: run VxWorks in FLASH?
        Subject: Re: Testing a location over the VME bus.
        Subject: Re: Problem with bind()
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: need symbios 53c770 scsi driver
Date: Fri, 08 Nov 1996 11:48:49 -0700
From: Daniel Brodsky <danb@wrs.com>
Organization: Wind River Systems
Message-ID: <32838091.5027@wrs.com>
hello all,
   Does anyone know where I could get a vxworks driver for the Symbios
53C770 SCSI device?
Thanks in advance,
Dan
Dan Brodsky
Wind River Systems
danb@wrs.com
(303)486-0850
---------------------------
Newsgroups: comp.os.vxworks
Subject: Problem with bind()
Date: Wed, 13 Nov 1996 04:38:31 GMT
From: brucew@phoenix.net (Bruce)
Organization: BranPaul Systems
Message-ID: <56bjfm$inq$3@uhura.phoenix.net>
We have built a tcpserver from the example code provided in
the vxWorks manual.  As is accepts connections, it starts a
task to handle each connection.  All of this is working
fine.  The problem occurs when we close the socket for any
reason.  When we call socket() again, it opens ok, but the
bind() always fails.  We can only fix this by a reboot.
Anyone have any ideas?
Bruce
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: run VxWorks in FLASH?
Date: Wed, 13 Nov 1996 03:40:37 GMT
From: jdeffner@west.net (john deffner)
Organization: West.Net Communications
Message-ID: <56bfue$koq@daffy.sb.west.net>
References: <32889451.4C5E@HiWAAY.net>
On Tue, 12 Nov 1996 09:14:25 -0600, David Leviner
<dleviner@HiWAAY.net> wrote:
>Hi all,
>
>I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
- --cut--
>Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
>how?
>
>Thanks for the advice.
>--
>David Leviner
>Systems Engineer
>Chandler/May, Inc. (CMI)
>125 West Park Loop
>Huntsville, AL  35806
>(205)722-0175
>(205)722-0144 (fax)
>dleviner@HiWAAY.net
Actually it's pretty easy. The kernal build you want is
vxWorks.res_rom (or vxWorks.res_rom_low if you're running in a small
amount of flash). We're doing it with a 386ex bsp (1 meg of flash, 1
meg of ram) and it works fine. It should be pretty similar for a
straight 386.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are uou happy with Vx Works and Wind River
Date: Sun, 10 Nov 96 20:32:12 GMT
From: nobody@nowhere
Organization: A poorly-installed InterNetNews site
Message-ID: <565e0f$5a0@idiom.com>
References: <E0n8uC.3rG@supernet.hellnet.org>
I don't mean to sound like an apologizer for Tornado,
because I don't use Tornado IDE due to its bugs, but
blaming WRS for trying to make money on their product
by hyping it is like blaming the Pope for being against
abortion.  It's the nature of business.
The fact is, even with all bugs and misfeatures, VxWorks
is the best RTOS in existence.  Unless someone comes
out with something better, we're stuck with it.  The
thing to do, then, is to encourage WRS to fix problems.
I am frequently accused of being negative on WRS for
exposing VxWorks problems.  I am also accused of bashing
WRS for selling out to military market.  I'm guilty of
both.  Although I'm less critical on the latter part now,
because WRS doesn't seem to depend as much on military
customers.  However, I'd never accuse WRS for hyping
their product.  It's all BS, but that's what marketing is.
I'd rather hope that WRS will fix a number of fundamental
problems:
1. broken stdio architecture.  The ioGlobalStd stuff has
to go.  I've seen too many people lose their mind over this.
2. broken filesystem architecture -- vxWorks does not have
one.  All filesystems are implemented as IO drivers and
libraries.  This creates a number of annoying problems and
breaks consistent interface for simple things like ls().
3. non-reentrant target shell.  Tornado adds bandages to
this problem by allowing multiple instantiations of tcl
infused shell-lookalikes.  This breaks the consistency
of user interface even more -- for example, i() implemented
in tcl vs. i() implemented in C -- there is no reconciliation
or attempt to resolve oddities that arise from this.
4. use of #include on C files in the config/all files.
#include is meant for H files not C files.  This creates
subtle problems, and there are cleaner alternatives.
5. techsupport.  It's terrible.
etc.
I could go on and on...
---------------------------
Newsgroups: comp.os.vxworks
Subject: Is your 5.2 X86 target SLOW?
Date: 10 Nov 1996 14:18:55 -0600
From: irwin@Starbase.NeoSoft.COM (Bob Irwin)
Organization: Realtime Systems / SW Houston
Message-ID: <565dbf$kdm@Starbase.NeoSoft.COM>
If you are using the X86 bsp with vxWorks 5.2, you may have
a serious performance problem with system images that are
loaded into low memory (bootable *.st images).  To see if
your bsp has this problem, boot a vanilla vxWorks image
(with timexN support) from the network and enter the
following two shell commands.  Observe the return values.
   -> timexN bcopyBytes, 0x200000, 0x300000, 1000
   -> timexN bcopyBytes, 0x108000, 0x300000, 1000
                            ^
                       LOW_RAM_ADRS
The first command times a copy of bytes from 'high mem' to 'high mem',
while the second command times a copy of bytes from 'low mem' to
'high mem'.  If your low mem copy takes 3-4 times LONGER that
your high mem copy, You have this problem.  If you load a bootable
standalone image, it loads at LOW_RAM_ADDRESS.  If you've linked
your own code into the kernel, it's gonna run SLOW.  Not only
your code, but sysLib is loaded here (sysInByte, sysOutByte, etc).
As delivered, our bsp's LOW_RAM_ADRS was set at 0x108000
in Makefile, MakeSkel, Makefile.I80486gnu, and config.h.
The original sysPhysMemDesc showed 0x100000 as the beginning of
cached memory.  By using timexN, I found that the first 64K bytes
of 'low mem' were likely uncached.  This problem existed on
different target machines with different CPU types.
My 'workaround' was to change LOW_RAM_ADRS in the above 4 bsp
files to 0x110000.  This lets the 'low mem' copy run at normal
speed.
A TSR was openened on this several months ago with no resolution.
It has been reopened with the above test description.
I'm a consultant for Systems Interface Software, Inc. (SIS). We
have geen providing custom PC104 boxes and software to NASA
at JSC here in Houston.
   - Bob
- --
R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
I don't want to achieve immortality through my work.  I want to
achieve immortality through not dying.  - Woody Allen
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: run VxWorks in FLASH?
Date: Wed, 13 Nov 1996 08:22:14 +0000
From: Iain Tebbutt <Iain.Tebbutt@brunel.ac.uk>
Organization: Brunel University, Uxbridge, UK
Message-ID: <32898536.749A@brunel.ac.uk>
References: <32889451.4C5E@HiWAAY.net>
David Leviner wrote:
>
> Hi all,
>
> I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
- ------ snip ------
> Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
> how?
>
Look at rom resident versions of vxWorks. I use vxWorks.res_rom_nosym
which runs fine from a "ROM" type area. You will need to make sure
that the memory map in config.h and Makefile have the correct ROM
address. Using this rom resident portion of VxWorks means that the
text areas stay in ROM and RAM is only used for variables/data.
Iain (Iain.Tebbutt@brunel.ac.uk)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with Vx Works and Wind River
Date: Wed, 13 Nov 1996 08:50:32 GMT
From: valentin@netcom.com (Valentin Pepelea)
Organization: Netcom Communications, Santa Clara, CA
Message-ID: <valentinE0swK8.7B8@netcom.com>
References: <55md5u$5b@idiom.com> <560boi$42q@hacgate2.hac.com> <567s0h$evk@hacgate2.hac.com>
Sender: valentin@netcom16.netcom.com
In article <567s0h$evk@hacgate2.hac.com> mhayashibara@ccgate.hac.com writes:
>
>The Mentor buyout of pSOS was the last straw.
>
>...
>
>    Dave relates the correct acquisition; Mentor bought Microtec. But
>imagine having a compiler vendor (Microtec) who was under contract to
>ISI (who sold us the Microtec compiler AND pSOS) that migrated to a
>different RTOS (VRTX) and didn't want to support pSOS users anymore!
>That's the way it is...
Let me make some clarifications here. Mentor Graphics bought Microtec Research,
not ISI one year ago. Microtec, in return, bought Ready Systems, the makers
of the VRTX real-time kernel and the SPECTRA development system upon which
Tornado's concepts are based, three years ago.
I was at Ready Systems when SPECTRA was rolled out in 1993, and we too were
using GNU tools to compile all our code. The idea was to make a development
system and kernel that is totally independant of the compiler tool suite used,
and even allow the addition of third-party plug in tools through the use of
an open API. (sound familiar?) Indeed, demo applications were supplied for GNU,
Microtec, and Oasys (Green Hills). Later Metaware,  and Diab tools were
added for 29K and PowerPC architectures, respectively.
After the purchase of Ready Systems by Microtec, that policy of openess
continued. However, Green Hills was already at odds with Microtec and were
involved in a major lawsuit, so they dropped a continuation of cross-licencing
agreements. The purchase of Ready and its kernel, VRTX, placed Microtec in a
competitive posture vis-avis ISI. Needless to say, ISI was not happy about it
either, (would you?) and might have been trying to distance themselves since
then. Given that a *high* percentage of Microtec's sales were associated with
pSOS sales' boundling, it was and still is, in Microtec's best interest to
keep pSOS customers happy.
Valentin
- --
"An operating system without virtual memory      Valentin Pepelea
 is an operating system without virtue."         Embedded Systems Consultant
                                                 (415) 346-7105
                     - Ancient Inca Proverb      valentin@netcom.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are uou happy with Vx Works and Wind River
Date: Tue, 12 Nov 96 09:58:18 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56c2r2$obb@idiom.com>
References: <E0n8uC.3rG@supernet.hellnet.org> <565e0f$5a0@idiom.com> <tiyu3quvlta.fsf@parint.svl.trw.com>
In article <tiyu3quvlta.fsf@parint.svl.trw.com>, pjg@parint.svl.trw.com () wrote:
>In article <565e0f$5a0@idiom.com> nobody@nowhere writes:
>
>   From: nobody@nowhere
>
>Hey hj, you need to work on your headers a bit more if you are
>trying to be anonymous.
>
It was ironic that my newsreader program would do that.
I've fixed the problem and also posted a note, immediately
afterwards.  I have no reason to hide behind anonymity.
Thanks for playing... but no cookie.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: re: multicast
Date: Tue, 12 Nov 96 09:46:44 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56c25c$jvm@idiom.com>
References: <199611130250.VAA06027@satchmo.bbn.com>
In article <199611130250.VAA06027@satchmo.bbn.com>, Fred Roeber <froeber@BBN.COM> wrote:
> It turns out that when you
>are trying to support BSPs which utilize nearly a dozen different ethernet
>chips, coming up with a portable way of providing this interface is not
>at all trivial; especially since the different chips use radically
>different interfaces to provide such filtering.  Thus while it was easy
>for us to get our one particular implementation to work, getting it working
>in a general fashion would be quite tough.
Implementing the general mechanism for multicast filtering support
on network device driver interfaces is not tough at all.  Just
look at how BSD4.4 does it.  The generic interface itself is
quite simple.  It is true that each device has unique way of
setting up filters for multicast filters, therefore device
drivers have to implement it differently.  However, this does
not mean that the generic support for multicast filtering itself
is hard at all!  The devices may or may not support multicast
filtering, and the interface would still work.
Given this, the only conceivable reason for not supporting
multicast would be unwillingness to study the problem and/or
unwillingness to write/port necessary code.  The effort involved
would be trivial compared to the usefulness of multicasting
in a realtime OS.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: run VxWorks in FLASH?
Date: Tue, 12 Nov 96 09:49:30 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56c2ai$jvm@idiom.com>
References: <32889451.4C5E@HiWAAY.net>
In article <32889451.4C5E@HiWAAY.net>, David Leviner <dleviner@HiWAAY.net> wrote:
>Or to make the question easier to answer, has anyone run VxWorks in FLASH? If
> so,
>how?
>
build vxWorks.res_rom
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Testing a location over the VME bus.
Date: Wed, 13 Nov 1996 08:20:24 GMT
From: valentin@netcom.com (Valentin Pepelea)
Organization: Netcom Communications, Santa Clara, CA
Message-ID: <valentinE0sv60.5nq@netcom.com>
References: <1.5.4.32.19961107224614.00712e34@pop01.connect.com>
Sender: valentin@netcom16.netcom.com
In article <1.5.4.32.19961107224614.00712e34@pop01.connect.com> Mike McQuade <MikeMcQuade@connect.com> writes:
>
>Im using both MVME-1603 and 1604 boards, on the 1603, I can
>access addresses where there is no hardware, this returns
>garbage, but on the 604, if I try to access an address where
>there is no hardware, I get an exception.
>
>Any ideas why the 604 generates an exception, and the 603 doesn't ?
I have worked on ISI's board-support package for the MVME-1600 series boards,
not WRS', but the answer should be useful anyway.
The difference between the two processors that is relevant here is the
implementation of the MMU. The 603 uses a generic TLB (translation lookaside
buffer), where each entry in the lookaside buffer corresponds to a virtual to
psysical page translation. There are only 16 such entries available, so if a
page is accessed for which no translation is available, a trap occurs. The
trap handler then replaces one of the 16 entries.
The 604 MMU also uses a secondary 64Kb table located in main memory to
automatically store alternate translation entires. It uses a hashing algorithm
to find and replace entries that do not fit into the TLB.
It is possible to program the MMU in such a way that it either maps an address
to physical memory, mirrors address ranges repreatedly, blocks all accesses
(or only writes) or that it maps it directly to addressing ranges, regarless
of whether memory is there or not.
>Any suggestions on how to test if a board is available ?
The MMUs should be programmed to translate the VME address range trans-
parently. Therefore if a board is not present in its expected slot, or
if it broke while running, a machine check exception should occur when its
memory was accessed. The code I wrote for ISI's multi-processing pSOS+m
would cleanly recover from the exception, as the memory in question was
being accessed only after the equivalent of a setjmp() call. The equivalent
of a lonjmp() call would allow the continuation of execution from the point of
the memory access.
First, you have to ensure that both your 603 and 604 boards generate an
exception for VME memory that is not there. Perhaps WRS' BSP requires you to
indicate at configuration time at which addresses you expect other boards to
be mapped, and your problem lies there. If the problem is in their MMU code
for the 603 processor, contact their tech support staff. They might already
have a patch available. I don't see how they could implement error recovery
in their multi-processing version of the kernel without this working
properly.
Given the current public gripes re: tech support, other readers are probably
wishing you good luck. :-)
Valentin
- --
"An operating system without virtual memory      Valentin Pepelea
 is an operating system without virtue."         Embedded Systems Consultant
                                                 (415) 346-7105
                     - Ancient Inca Proverb      valentin@netcom.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Problem with bind()
Date: Tue, 12 Nov 96 09:52:09 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56c2fh$jvm@idiom.com>
References: <56bjfm$inq$3@uhura.phoenix.net>
Try this:
        int on = 1;
        setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
End of New-News digest
**********************
From p72950@gmcl.co.uk  Wed Nov 13 05:43:46 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Wed Nov 13 05:43:52 PST 1996
Subject: Re: run VxWorks in FLASH?
Hi there,
We have successfully run VxWorks from FLASH. In our case the build system
was modified to produce the FLASH version as well as the RAM loadable
and BOOTROM version. I produced a new makefile (Makefile.fl) which
*only* does the FLASH version.
The basic changes were:
Change the include of 'defs.bsp' to a local file (or in a relative directory).
More of this later.
Set ROM_TEXT_ADRS & ROM_SIZE to reflect the size & location of the FLASH
devices.
Change HEX_FLAGS to '-a $(ROM_TEXT_ADRS)'
Change the include of rules.bsp to point to a local file (same path as defs.bsp
?).
defs.bsp: Change MACH_DEP to '$(MACH_EXTRA) $(ADDED_MODULES)
rules.bsp: file follows
# rules.bsp - makefile target rules for BSP
#
# SCCS Ref: @(#)rules.bsp	1.1 8/27/96
#
# modification history
# --------------------
# 01h,27aug96,pjq  special version to produce vxWorks.fl. Added SCCS ref.
# 01g,13nov95,jeh  restored .cpp.o implicit rule
# 01f,08nov95,jeh  removed .cpp.o implicit rule
# 01e,01nov95,p_m  added LIB to rom_res build command
# 01d,01nov95,yp   added implicit rules for C++
# 01c,30oct95,dat  added targets vxWorks.res_rom_nosym and
#		   vxWorks.res_rom_nosym_mips
# 01b,27jun95,kkk  added VXSIZE.
# 01a,12jun95,yp   created from makeTarget2 v03d.
#
# DESCRIPTION
# This file contains rules used in building targets.
#
# VARIABLES
# The following variables must be defined (or not, as appropriate):
#
#     ROM_SIZE          number of bytes of ROM space as in config.h
#     LOCAL_MEM_SIZE	target RAM size as in config.h
#     BINHEX		binary->hex file conversion program
#     HEX_FLAGS         BINHEX program options
#     LD_LOW_FLAGS	ld(1) options for code in low memory
#     LD_HIGH_FLAGS	ld options for code in high memory
#     LD_PARTIAL_FLAGS  ld flags for linking partially complete objects
#     LDDEPS		host-specific dependencies prerequisite to linking
#     LDOUT_CONV	hpToBsd, coffToBsd, gswab, /bin/cat, etc.
#     COMPILE_SYMTBL	hide flags needed to get compiler to swallow symTbl.c
#     ROM_ENTRY		rom entry point (typically &romInit)
#     SYS_ENTRY		system entry point (typically &sysInit)
#     USR_ENTRY		compressed system entry point (typically &usrInit)
#
# The following variables are optionally defined:
#
#     LDFLAGS		standard ld flags for vxWorks & ROMs.
#     ROM_LDFLAGS	ld flags specific to ROM image
#
# CONSTANTS
#     CPU               cpu type
#*/
################################################################################
#
# meta build targets
#
## make will default to "exe"
exe	: vxWorks.fl.hex
release : $(RELEASE)
clean   :
	- $(RM) *.o
	- $(RM) vxWorks*
	- $(RM) bootrom*
	- $(RM) depend.$(TARGET_DIR)
.s.o :
	@ $(RM) $@
	$(CPP) $(CASFLAGS) -E $< > tmp.s
	$(CC) $(CFLAGS) -c -o $*.o tmp.s
	@ $(RM) tmp.s
.c.o :
	@ $(RM) $@
	$(CC) $(CFLAGS) -c $<
# rule for munchless C++ compiles
.cpp.o :
	@ $(RM) $@
	$(CXX) $(C++FLAGS) -c $<
# C++ compile and munch
.cpp.out :
	@ $(RM) $@
	$(CXX) $(C++FLAGS) -c $<
	@ $(RM) $@ ctdt.c
	$(NM) $*.o | munch > ctdt.c
	$(MAKE) CC_COMPILER="-traditional" ctdt.o
	$(LD) -r -o $@ $*.o ctdt.o
	@ $(RM) ctdt.c ctdt.o
################################################################################
#
# machine dependent targets
romInit_fl.o: depend.$(BSP_NAME) romInit.s
	- @ $(RM) $@
	- @ $(RM) tmp.c
	- @ $(RM) tmp.s
	- @ $(RM) tmp.i
	$(ASM_P1) romInit.s > tmp.c
	$(CC) $(CASFLAGS) -DROM_RESIDENT -DFLASH_BLD tmp.c > tmp.i
	$(ASM_P2) tmp.i > tmp.s
	$(AS) -o $@ tmp.s
	- @ $(RM) tmp.c
	- @ $(RM) tmp.i
	- @ $(RM) tmp.s
usrConfig.o : depend.$(BSP_NAME) $(USRCONFIG)
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(USRCONFIG) -o $@
bootInit.o : depend.$(BSP_NAME) $(BOOTINIT)
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(BOOTINIT)
bootInit_fl.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o
	- @ $(RM) $@
	$(CP) $(BOOTINIT) bootInit_fl.c
	$(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD bootInit_fl.c
	- @ $(RM) bootInit_fl.c
sysLib_fl.o : depend.$(BSP_NAME) sysLib.c
	- @ $(RM) $@
	$(CP) sysLib.c sysLib_fl.c
	$(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD sysLib_fl.c
	- @ $(RM) sysLib_fl.c
dataSegPad.o: depend.$(BSP_NAME) $(DATASEGPAD) $(CONFIG_ALL_H) config.h
	- @ $(RM) $@
	$(CC) -c $(CFLAGS) $(DATASEGPAD) -o $@
################################## vxWorks #####################################
#
# vxWorks     - Version setup for FLASH build - no symbol table
vxWorks.fl: depend.$(BSP_NAME) bootInit_fl.o romInit_fl.o \
			usrConfig.o sysALib.o sysLib_fl.o \
			$(MACH_DEP) $(LDDEPS) $(LIBS)
	- @ $(RM) $@ tmp.o
	- @ $(RM) tmp.1
	- @ $(RM) symTbl.c
	- @ $(RM) symTbl.o
	- @ $(RM) $(IMI)
	- @ $(RM) $(IBR)
	- @ $(RM) version.c
	- @ $(RM) version.o
	$(MKVERSION) > version.c
	$(CC) -c $(CFLAGS) version.c
	- @ $(RM) version.c
	$(LD) -o $@ $(LDFLAGS) $(ROM_LDFLAGS) -e $(ROM_ENTRY) \
	    $(RES_LOW_FLAGS) romInit_fl.o bootInit_fl.o usrConfig.o \
	    sysALib.o sysLib_fl.o $(MACH_DEP) version.o $(LIBS)
	$(LDOUT_HOST) $@
	$(ROMSIZEPROG) -b $(ROM_SIZE) $@
	$(LDOUT_CONV) $@
vxWorks.fl.hex: depend.$(BSP_NAME) vxWorks.fl $(IMI)
	- @ $(RM) $@
	$(BINHEX) $(HEX_FLAGS) vxWorks.fl$(TXT_OFFSET) \
		$(IMI_SPEC)$(IMI)$(IMI_OFFSET) > $@$(MAP_EXT)
	-@ $(MV_BIN)
imi :	$(IBR)
	$(LD) -o $@ -Ttext $(IMI_TEXT_ADRS) -Tdata $(IMI_DATA_ADRS) $(IBR)
End of rules.bsp
Note that rules.bsp passes a compile time flag 'FLASH_BLD' into the
compiler. Make sure that the definitions in config.h use an #ifdef FLASH_BLD
to remap the values of ROM_TEXT_ADDRESS & ROM_TEXT_SIZE to the correct
values. This flag can be used anywhere in the BSP files to make compile
time changes to the system.
To build run the Wind River Make (we find it clashes with unix make so have
renamed it 'wrs_make')
wrs_make -f Makefile.fl
It produces the following
vxWorks.fl  - object file mapped to FLASH addresses
vxWorks.fl.hex - S-Record file ready to download to FLASH
If using Tornado you will need to either set the 'Core file' option in the
launcher to point to vxWorks.fl or modify bootConfig.c to notice it is
about to run from FLASH & change the boot parameters to point to it. (We
chose the latter method as it makes it automatic. Also we can change the
'other' parameter to RAM which causes VxWorks to load to RAM as normal).
Regards,
Phil Quiney
p.s Sorry for the repost but somehow the subject line was missing - just in
case someone is trying to follow the thread.
>Hi all,
>
>I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
>and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the
>embedded application and the board real estate is limited for adding more DRAM.
>Because of these issues the board manufacturer (our customer) is wanting us to
>look into the possibility of running VxWorks in FLASH.
>
>First of all, I've never been presented with this memory problem. We've never had
>this type of DRAM limitation. If I'm going to do this, I am assuming that I will
>have to run the text section of VxWorks (instructions, constants,etc.) in FLASH
>and the data section of VxWorks (i.e., C variables) in DRAM. I know with
>Microsoft compilers/linkers you can relocate code in this manner. Is it
>possible to do the same in the kernel build for VxWorks. If so, has anyone done
>this?
>
>Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
>how?
>
>Thanks for the advice.
>--
>David Leviner
>Systems Engineer
>Chandler/May, Inc. (CMI)
>125 West Park Loop
>Huntsville, AL  35806
>(205)722-0175
>(205)722-0144 (fax)
>dleviner@HiWAAY.net
>
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From VXWORKS@hqgate.orbital.com  Wed Nov 13 07:12:41 1996
From: VXWORKS@hqgate.orbital.com
Date: Wed Nov 13 07:12:47 PST 1996
Subject: Job Opportunity!
     Orbital Sciences Corporation in Dulles, VA currently has an immediate
     opening for a Software Engineer.  The position involves the design,
     development, test, and integration of real-time embedded software for
     custom communications satellite hardware.  The position requires a
     minimum of 3-4 years experience, including C, real-time OS (VxWorks
     preferred), 68xxx microprocessors, and cross-platform software
     development in a UNIX environment.  Application experience in power
     systems, attitude control, or RF communications would be helpful.
     Please submit your resume to this email address (VXWORKS@orbital.com),
     or fax your resume to the attention of "Orbcomm Software Lead" to
     (703) 406-5553.
From mam@pluto.dspt.com  Wed Nov 13 07:32:27 1996
From: "Mark Menge" <mam@pluto.dspt.com>
Date: Wed Nov 13 07:32:29 PST 1996
Subject: Formatting SCSI Disks
I have been trying to format a seagate ultra scsi model ST31055
using vxWorks 5.3 and found that the format command wiped out
my page mode data. I called tech support, installed the "jumbo
patch" and ran some code they sent me which was
supposed to restore the saved page mode data, but it did not.
I finally bough a ADAPT TEC scsi controller and formatted it in my
PC and now it works fine.
WHAT THE HELL? WHY DO I HAVE TO DO THAT!
This sucks. I got deadlines and I am tired of writing code to do low level stuff
for every sticking scsi disk that comes along.
Questions:
1. Does anyone have some code that will get the default page mode
data and put it into the saved mode data? The code vxWorks sent me
assumes that when you format a drive the page mode data is restored
which is a bad assumption.
2. Is there a place where we can get/put this stuff once completed into the
 PD?
Mark A. Menge
DSP Technology Inc.
795 Higland Dr.
Ann Arbor Mi, 48108
Phone: (313) 973-1111
Fax: (313)  973-1103
Email: mmenge@dspt.com
From daemon@csg.lbl.gov  Thu Nov 14 04:00:23 1996
From: daemon@csg.lbl.gov
Date: Thu Nov 14 04:00:25 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Nov 14 04:00:20 PST 1996
        Subject: Re: Are uou happy with Vx Works and Wind River
        Subject: Long Trunk I/O
        Subject: External VME memory card with MVME162
        Subject: Re: Are you happy with VxWorks
        Subject: $$$$$$VxWorks$$$$$$
        Subject: Re: run VxWorks in FLASH?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are uou happy with Vx Works and Wind River
Date: 12 Nov 1996 17:13:53 -0800
From: pjg@parint.svl.trw.com ()
Organization: TRW SIG
Message-ID: <tiyu3quvlta.fsf@parint.svl.trw.com>
References: <E0n8uC.3rG@supernet.hellnet.org> <565e0f$5a0@idiom.com>
In article <565e0f$5a0@idiom.com> nobody@nowhere writes:
   From: nobody@nowhere
Hey hj, you need to work on your headers a bit more if you are
trying to be anonymous.
- --
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Paul Gyugyi                                  paul@gyugyi.com |
| Paul_Gyugyi@smtp.svl.trw.com          http://www.gyugyi.com/ |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
---------------------------
Newsgroups: comp.os.vxworks
Subject: Long Trunk I/O
Date: Wed, 13 Nov 1996 09:49:16 -0500
From: "Matthew R. Singer" <msinger@griffon.oe.fau.edu>
Organization: Dot-4
Message-ID: <3289DFEC.13BC7F45@griffon.oe.fau.edu>
I have an application that I need put push about 200Kb/Sec over
a cable about 2000 meters long. Plus I need to be able to send
very low speed commands in the other directions.  Any suggestions
for COTS products that may do this?
- --
- ----------------------------------------------------------------------------
			      Dot4, Inc.
		      The Real-Time Specialists
Matthew R. Singer                                    msinger@dot4.com
Real Time Systems Engineer
319 Littleton Road, Suite 304                        Voice: 508-392-8860
Westford, MA  01886                                  Fax  : 508-392-8861
- ----------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus,comp.sys.m68k
Subject: External VME memory card with MVME162
Date: 13 Nov 1996 16:32:36 GMT
From: bhanson@bnr.ca (Brian Hanson)
Organization: Bell-Northern Research Ltd.
Message-ID: <56ct74$3jt@crchh327.rich.bnr.ca>
Hi all,
I'm having trouble trying to use an external VME memory board with
a Motorola MVME162 card, and was wondering if anyone had experienced
similar problems or had any insights.
I have a test program that produces the correct results on a MVME167
card (with plenty of local RAM).  When I run the same program from a
MVME162 using the memory on the external card, it seems to run ok
(i.e. no bus errors or other exceptions) but produces incorrect results.
I have been able to obtain the correct results on the 162 by loading
the object file into local RAM, then adding the external RAM to the
system memory pool, and then running the program. (The object file
itself fits into local RAM, but the dynamic data does not.)  I have
also been able to get it to work by enabling the cache on the VME
address space that contains the external memory.  Both of these "fixes"
probably work because they reduce access to the VMEbus, but I fear
that they are just masking the real problem, which may recur at a
later time.
Any ideas?
BTW, the cards(MVME167, MVME162) are running VxWorks 5.3 in a shared
memory network configuration.
Brian Hanson
bhanson@nortel.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with VxWorks
Date: Wed, 13 Nov 1996 22:03:31 -0700
From: Wes Peters <softweyr@xmission.com>
Organization: Softweyr LLC
Message-ID: <328AA823.41C67EA6@xmission.com>
References: <199611121456.JAA10880@atlas.gb.nrao.edu>
JOE BRANDT wrote:
> At least two persons I know have patched and tested the VxWorks networking
> code to add multicasting, AND SENT the patches back to WRS.
>
> Ask WRS about this and they have no knowledge of it. For pretty much zero
> effort, they could have added this technology.
>
> Why is multicasting a big deal in a RT-OS?
> How many of your RT systems have some sort of monitoring? Multicast allows
> a single packet sent from a VxWorks system to be delivered to any number
> of monitoring stations. For efficientcy reasons multicast is the way to go.
If you didn't count Mark Matthews, then of BTS in Salt Lake City, make
that 3 persons.  The BTS product line makes heavy use of multicast on
vw 5.1 and 5.2; it works, and is very solid.  Why WRS hasn't included
this
in the distribution, or at least had one of their engineers go through
it,
bless it, and put it on an FTP server as "official unsupported" software
is beyond me.
Perhaps WRS is struggling to be come a more internet-aware company, and
does not yet realize the power of providing a resource such as a "tested
but unsupported" tools ftp site?
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters
Softweyr LLC
http://www.xmission.com/~softweyr
softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: $$$$$$VxWorks$$$$$$
Date: Thu, 14 Nov 1996 07:11:49 GMT
From: cbowen@mail.sdsu.edu (Chris Bowen)
Organization: San Diego State University
Message-ID: <56egkp$ela@hole.sdsu.edu>
If you or anyone you know has experience both as a user and as a
sytems programmer with VxWorks, I have a company that is urgent to
hire.  If you or anyone you know has experience doing ports of VxWorks
to new hardware (i.e. writing board supporting pakages) please contact
me as soon as possible.  This person must also have 3+ years
experience using UNIX.  My client prefers someone with  experience
using VMEbus.  Some EE knowledge is a plus!  Any leads or insight on
how to find this rare animal will be definitely worth your $$$$ time.
Chris Bowen
Technical Recruiter
Culver Group, Inc.
Phone: (619) 278-6767
Fax: (619) 278-2312
Email: cbowen@mail.sdsu.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: run VxWorks in FLASH?
Date: Wed, 13 Nov 1996 22:13:10 -0700
From: Wes Peters <softweyr@xmission.com>
Organization: Softweyr LLC
Message-ID: <328AAA66.167EB0E7@xmission.com>
References: <32889451.4C5E@HiWAAY.net>
David Leviner wrote:
> Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
> how?
Via a really clever boot loader.  The loader runs in DRAM and loads the
system
image using TFTP.  Once the image is loaded into DRAM, it is then
programmed into
the flash.  Then the system reboots, running from flash after the
reboot.
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters
Softweyr LLC
http://www.xmission.com/~softweyr
softweyr@xmission.com
---------------------------
End of New-News digest
**********************
From MikeMcQuade@connect.com  Thu Nov 14 10:57:01 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Nov 14 10:57:03 PST 1996
Subject: Q: using RPC/XDR with Win NT
We using RPC / XDR on an HP-UX workstation, talking to a PowerPC target, in
the future,
we would like use a PC Windows NT box to talk to the target, does anyone
know the difference
between XDR and the PC's "NDR" ?
Will XDR work with NT ?, if not, what are the possible work arounds ?
Thanks in advance.
Mike McQuade
MikeMcQuade@connect.com
From adler@bnlku5.phy.bnl.gov  Thu Nov 14 12:02:43 1996
From: "Steve Adler" <adler@bnlku5.phy.bnl.gov>
Date: Thu Nov 14 12:02:51 PST 1996
Subject: VxWorks on Linux Host Survey Results
VxWorkers,
Its been about 2 weeks since I've posted my initial VxWorks on Linux
host survey and got 39 replies. Most of them came in a few days
after my posting. In anycase, the intention of my survey was clear,
I want Wind River to support Linux as a host platform to develope vxworks
code. The resons are obvious for anyone who runs linux on their home PC.
I wanted to use the results of this survey to motivate RWS to port
their Tornado package to Linux.
Unfortuantly, I believe my results are biased. I have a feeling that
only those who are interested in Linux replied and those who are not
just ignored my survey, thus my intention of measuring the true
distribution of VxWorks users who are interested in linux may not
be correct. (Its hard to believe that 82% of the VxWorks community
want RWS to port their development code to linux) Be that as it may,
here are the results. One thing
to notice. Of the people who were not interested in VxWorks on Linux,
there was only one guy who used VxWorks on a Windows 95 platform.
The rest used workstation platforms except for one brave sole who
got VxWorks running on a PC running FreeBSD. There was one guy
who somehow was able to compile his target code on a linux system
but the debugging tools still ran on a SUN.
Thanks for your participation. I'm going to forward these results
to WRS and see what happens. Maybe if those interested in Linux
send e-mail to WRS directly we could get their attention on this
matter.
	VxWorks on Linux Host Survey Results
	Total number of replies:  39
   Linux Interest YES                        Linux Interest No
         32  (82%)                                7  (18%)
B Knowledge of Linux                  E No interestin Linux becuse....
  25  Linux Guru		         5 Use VxWorks on Workstation
   5  Linux Novice		         0 Linux is unreliable
   2  Linux Twink		         0 Don't know what Linux is
C Linux Distribution		         1 Use Windows 95
  10 Redhat			         0 Use Windows NT
   1 Debian			         1 Use FreeBSD
  12 Slakware
   2 Other
   5 None
   2 Redhat and Slakware
D Linux Support from WRS
  27 Only VxWorks Support
   3 VxWorks Support and Generic Unix Support
   2 VxWorks Support, Generic Unix Support, Linux Support
From slirosi@gic.gi.com  Thu Nov 14 12:39:16 1996
From: "Lirosi, Salvatore (HT-MS)" <slirosi@gic.gi.com>
Date: Thu Nov 14 12:39:25 PST 1996
Subject: Unsubscribe
Unsubscribe...
From jford@sadira.gb.nrao.edu  Thu Nov 14 14:08:17 1996
From: jford@sadira.gb.nrao.edu (John Ford)
Date: Thu Nov 14 14:08:19 PST 1996
Subject: Re: Q: using RPC/XDR with Win NT
   We using RPC / XDR on an HP-UX workstation, talking to a PowerPC target, in
   the future,
   we would like use a PC Windows NT box to talk to the target, does anyone
   know the difference
   between XDR and the PC's "NDR" ?
   Will XDR work with NT ?, if not, what are the possible work arounds ?
I successfully used RPC (including XDR) on NT with the help of
NobleNet`s RPC libraries for NT.  We used rpcgen on a Sun to generate
the RPC code, then compiled it using noblenet`s NT DLL libraries,
compiling with visual C++.  The native NT "DCE RPC" is *Not* compatile
with ONC (that is, Sun) RPC.  I think that someone here at NRAO has
made our ONC RPC stuff work on NT, but I'm not sure of any details.  I
suspect that for someone who knows NT, the standard RPC source code
could be easily ported.
--
John Ford
National Radio Astronomy Observatory
Green Bank, WV 24944-0002
jford@nrao.edu
From froeber@bbn.com  Thu Nov 14 18:03:49 1996
From: Fred Roeber <froeber@bbn.com>
Date: Thu Nov 14 18:03:56 PST 1996
Subject: Re: MV162 external memory problem
On Thu, 14 Nov 1996, Brian Hanson wrote:
> I have a test program that produces the correct results on a MVME167
> card (with plenty of local RAM).  When I run the same program from a
> MVME162 using the memory on the external card, it seems to run ok
> (i.e. no bus errors or other exceptions) but produces incorrect results.
>
> I have been able to obtain the correct results on the 162 by loading
> the object file into local RAM, then adding the external RAM to the
> system memory pool, and then running the program. (The object file
> itself fits into local RAM, but the dynamic data does not.)  I have
> also been able to get it to work by enabling the cache on the VME
> address space that contains the external memory.  Both of these "fixes"
> probably work because they reduce access to the VMEbus, but I fear
> that they are just masking the real problem, which may recur at a
> later time.
>
> Any ideas?
>
> BTW, the cards(MVME167, MVME162) are running VxWorks 5.3 in a shared
> memory network configuration.
This sounds like an interesting problem but you don't provide quite enough
information to determine what might be wrong.  The key thing is that since
you aren't getting bus errors you shouldn't be having problems due to data
that is corrupted due to access timeouts.  I assume that you are using
memory for this data that isn't being shared with the 167 in any way.
If the 167 was sharing any parts of the memory area then you could run
into memory coherency problems.  The fact that turning on the cache makes
things work better makes me wonder if the problem could be tied to
misaligned data access errors.  Several years ago I had a case with a
Radstone board where it incorrectly handled loading misaligned data
over the VME bus.  By aligning the data and doing only 32 bit accesses
the problem went away.  Radstone did fix the problem however.  Thing is,
I can't imagine the Moto board having a problem in this area as their
VME interface tends to be pretty well understood and I have never heard
of a problem like this with them.  You also don't mention but I
would assume your code doesn't use any sort of atomic operations (e.g
TAS instructions)?  If you do, you have to be careful to set up the
snooping control bits correctly for the memory area as there are some
known problems in this area with the Moto VME interface (the VxWOrks
BSP doc contains warnings about the problem too).  I would be interested
in hearing what you end up finding the problem to be.  I agree that this
problem isn't one to ignore since it will likely show up somewhere else.
  Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From eknuds@extremenetworks.com  Thu Nov 14 19:30:00 1996
From: Eric Knudstrup <eknuds@extremenetworks.com>
Date: Thu Nov 14 19:30:02 PST 1996
Subject: Re: Q: using RPC/XDR with Win NT
>    Will XDR work with NT ?, if not, what are the possible work arounds ?
>
> I successfully used RPC (including XDR) on NT with the help of
> NobleNet`s RPC libraries for NT.  We used rpcgen on a Sun to generate
> the RPC code, then compiled it using noblenet`s NT DLL libraries,
> compiling with visual C++.  The native NT "DCE RPC" is *Not* compatile
> with ONC (that is, Sun) RPC.  I think that someone here at NRAO has
> made our ONC RPC stuff work on NT, but I'm not sure of any details.  I
> suspect that for someone who knows NT, the standard RPC source code
> could be easily ported.
I have found source for it on the net.  I just can't remember where.
You might ask in one of the NT newsgroups.
From daemon@csg.lbl.gov  Fri Nov 15 04:00:30 1996
From: daemon@csg.lbl.gov
Date: Fri Nov 15 04:00:33 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Nov 15 04:00:24 PST 1996
        Subject: Re: Are you happy with VxWorks
        Subject: Re: Are you happy with VxWorks
        Subject: RE: Are you happy with Vx Works and Wind River
        Subject: Re: multicast
        Subject: Re: run VxWorks in FLASH?
        Subject: Re: Using GNAT Ada with VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with VxWorks
Date: 14 Nov 1996 20:17:19 GMT
From: vbv@giskard.cwru.edu ("Virgilio 'Dean' B. Velasco Jr.")
Organization: Case Western Reserve Univ.  Cleveland, Ohio (USA)
Message-ID: <56fuof$r5l@alexander.INS.CWRU.Edu>
References: <2.2.32.19961112021421.006e0954@mail.wrs.com>
In article <2.2.32.19961112021421.006e0954@mail.wrs.com>,
David Fraser  <dfraser@wrs.com> wrote:
>(Apologies if your get a duplicate of this message directly on
>comp.os.vxworks.  We've had some weirdness from our news server forwarding
>correctly)
>
>Dear Users,
>
>Everyone here at Wind River has been following this particular thread very
>closely.  Far from ignoring the newsgroup and exploder, I think that all of
>us see it as a vital link to the user community.  It's become something of
>an informal policy of ours, however, not to make too many postings.  We
>have in mind the double-edged sword of communication which can classify us
>either as being defensive or involved in shameless self-promotion.  But
>we're ready and willing to respond more immediately if that's what you want
>from us, and we think it appropriate.
    Hear, hear!  I, for one, am pleased that WRS has been following
this discussion.  Earlier on, one poster remarked that Wind River was
callous to their customers' needs, as manifested by their lack of any
posted response.  With all due respect to said poster, such remarks are
uncalled for (and somewhat below the belt).
    I say that while we should freely voice our complaints, we should
also be prepared to cut the guys some slack.
- --
Virgilio "Dean" Velasco Jr, Department of Electrical Eng'g and Applied Physics
        graduate student slave, roboticist-in-training and Q wannabe
http://dora.eeap.cwru.edu/vbv/vbv.html |  Remember: Wise men still seek Christ.
"And I shall shed my light over dark evil, for darkness cannot stand the light."
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Are you happy with VxWorks
Date: 15 Nov 1996 01:09:04 GMT
From: schaffer@rain.org (Jeff Schaffer)
Organization: RAIN Public Access Internet (805) 967-RAIN
Message-ID: <56gfrg$1l8@news.rain.org>
References: <2.2.32.19961112021421.006e0954@mail.wrs.com> <56fuof$r5l@alexander.INS.CWRU.Edu>
Virgilio 'Dean' B. Velasco Jr. (vbv@giskard.cwru.edu) wrote:
: In article <2.2.32.19961112021421.006e0954@mail.wrs.com>,
: David Fraser  <dfraser@wrs.com> wrote:
: >(Apologies if your get a duplicate of this message directly on
: >comp.os.vxworks.  We've had some weirdness from our news server forwarding
: >correctly)
: >
: >Dear Users,
: >
: >Everyone here at Wind River has been following this particular thread very
: >closely.  Far from ignoring the newsgroup and exploder, I think that all of
: >us see it as a vital link to the user community.  It's become something of
: >an informal policy of ours, however, not to make too many postings.  We
: >have in mind the double-edged sword of communication which can classify us
: >either as being defensive or involved in shameless self-promotion.  But
: >we're ready and willing to respond more immediately if that's what you want
: >from us, and we think it appropriate.
:
:
:     Hear, hear!  I, for one, am pleased that WRS has been following
: this discussion.  Earlier on, one poster remarked that Wind River was
: callous to their customers' needs, as manifested by their lack of any
: posted response.  With all due respect to said poster, such remarks are
: uncalled for (and somewhat below the belt).
:
:     I say that while we should freely voice our complaints, we should
: also be prepared to cut the guys some slack.
:
I agree totally.  Personally, I applaud the posting from WRS for its
moderation.  Unless they answer "we make a rotten system and our service
is terrible", we would all assume their answer is self-promotion (and if
they did answer that, I doubt we would do business with them).  Better to
take the route they took - let your users answer the questions and take
your chances as to whether the comments are positive or negative,
commenting ONLY when necessary. I think it takes a lot of courage on a
company's part to do that.
 --
Jeff Schaffer
TimeQuest Technologies
schaffer@rain.org
---------------------------
Newsgroups: comp.os.vxworks
Subject: RE: Are you happy with Vx Works and Wind River
Date: Fri, 15 Nov 96 02:05:15 GMT
From: banshee@banshee.com (James Moore)
Organization: Banshee Software
Message-ID: <56gj0a$sgu@q.seanet.com>
References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>
In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>, Mike Anderson <mea@mclean.sparta.com> wrote:
>With regards to my viewpoint on VxWorks, I find the following things to
>be true:
>
>1)  The development environment in VxWorks is as good as that of any
>    other *embedded* RTOS.  That is, it would be wonderful to have
>    and IDE like Microsoft Visual C++ with the integrated debugger, etc.
Having used both sets of tool chains, I have to say that the gnu/gdb setup
blows away MSVC++.  (Caveat - I've only used C on the Unix side, and C++
on the MSVC++ side.)  MSVC is pretty, but it's nowhere near as functional as
gdb for debugging.  Not having a scripting language for a debugger is a
serious defect, and I think the visual model for printing out variables is
badly flawed - when you're using gdb, you can set a breakpoint that prints a
variable and continues.  You end up with screenfuls of history that can be a
lifesaver when you're trying to find what data breaks your code.  You can also
write functions that do things like print out parts of linked lists.  There's
just nothing at all in MSVC that gives you anything like the same
functionality.
The class browser in MSVC is OK, but I haven't used C++ in a Unix environment
so I can't compare them to anything.  For straight C, the emacs tag system is
faster and more powerful than the MSVC system.  I've found that MSVC is easily
confused about where to find functions, and would frequently only bring me to
the header file, not the function implementation.
I wouldn't argue if you said that MSVC was easier to learn than a gdb setup.
It's usually easier to come up to speed on visual tools than command-line
ones.  But I don't really care how much time it takes to _learn_ the debugger,
since it's a tool I'll be using daily for a long time.  What I can do with it
is far more important, and gdb and emacs win hands down.
For writing MFC Windows code, MSVC is great - the wizards do a lot of work for
you.  But, IMHO, that's the only advantage it has over the tools on the Unix
side.  I'd gladly trade back any day.
James Moore
  Stupid elephant tricks!  http://www.wa-democrats.org/stupid/index.html
    banshee@banshee.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: multicast
Date: Thu, 14 Nov 1996 20:53:21 -0500
From: gwinn@res.ray.com (Joe Gwinn)
Organization: Raytheon Electronic Systems
Message-ID: <gwinn-1411962053210001@smc19.ed.ray.com>
References: <199611130250.VAA06027@satchmo.bbn.com>
In article <199611130250.VAA06027@satchmo.bbn.com>, Fred Roeber
<froeber@BBN.COM> wrote:
> While I doubt that we are one of the two people Joe [Brandt] refers to,
I was > part of a group at my former employer that had a VxWorks source
license and
> needed to use multicast.  We got the PD code for implementing multicast
[snip]
> ...  Thus while it was easy
> for us to get our one particular implementation to work, getting it working
> in a general fashion would be quite tough.
[snip]
> While I certainly go along with Joe [Brandt] that multicast would be
nice to  > have, I wanted to point out that it wouldn't take "pretty much
zero effort".
We still have a problem with the lack of true (high-performance)
multicast, and I really don't have any sympathy with WRS on this.
Multicast is a major need in their chosen field, and they should just
solve the problem, and not mumble about the fact that there is more than
one I/O device in the world.  That's what BSPs are for.  I have seen an
infrastructure collapse and be thrown away for lack of multicast support
in VxWorks; an entirely different approach had to be developed.  Very
painful.
I think that the true issue is that WRS sees their market niche as
improving their customers' time-to-market, which WRS translates into
putting the major attention into wizzy new (and initially buggy) tools.
The dark side is that the kernel, a survivor from the 1970s, is largely
neglected.  The advantage is that it's quite mature and stable now.  I
would hope and assume that there is a new and modern (threaded?) kernel
growing in a secret back room somewhere; one never knows.  There has to be
a limit to how long one can ride a 1970s design, and Lynx will eventually
get their LynxOS act together, and become a threat to somebody.
Joe Gwinn
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: run VxWorks in FLASH?
Date: 14 Nov 1996 18:24:21 -0800
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <56gk8l$g1f@elaine23.Stanford.EDU>
References: <32889451.4C5E@HiWAAY.net>
In article <32889451.4C5E@HiWAAY.net>,
David Leviner  <dleviner@HiWAAY.net> wrote:
>Hi all,
>
>I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH
>and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the
>embedded application and the board real estate is limited for adding more DRAM.
>Because of these issues the board manufacturer (our customer) is wanting us to
>look into the possibility of running VxWorks in FLASH.
>
>First of all, I've never been presented with this memory problem. We've never had
>this type of DRAM limitation. If I'm going to do this, I am assuming that I will
>have to run the text section of VxWorks (instructions, constants,etc.) in FLASH
>and the data section of VxWorks (i.e., C variables) in DRAM. I know with
>Microsoft compilers/linkers you can relocate code in this manner. Is it
>possible to do the same in the kernel build for VxWorks. If so, has anyone done
>this?
>
>Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so,
>how?
Yes at a previous company we did this. In fact it was the same situation
(i.e. couple months before shipping we were told we had to run out of flash,
because we were going from 4Mb to 1Mb of DRAM). Deja vu!!
You need to build a "res_rom" version of VxWorks (i.e. rom resident) which
copies its bss and data sections to ram. I can't remember the nitty gritty
details but you need to setup the variables which tell the makefile where
rom and ram are located and what the sizes are (e.g. ROM_TEXT_ADRS, ROM_SIZE,
RAM_HIGH_ADRS, RAM_LOW_ADRS). We did this for 5.2, so 5.3 may be slightly different.
Checkout chapter 9 in Tornado User's Guide this has
all the info you need to do it. If your application
also needs to run from flash then the easiest way
to handle this is to link your application code
with the kernel image. You make a relocatable
image application.o and just add line
MACH_EXTA = application.o to Makefile or MakeSkel file.
All of this is in Chapter 9.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using GNAT Ada with VxWorks
Date: 15 Nov 1996 04:46:57 GMT
From: steved@pacifier.com@199.2.117.163  (Steve Doiel)
Organization: Pacifier BBS, Vancouver, Wa.  ((360) 693-0325)
Message-ID: <56gsk1$raa@news.pacifier.com>
References: <328B724E.6033@wrga.saic.com>
Reply-To: steved@pacifier.com  (Steve Doiel)
In <328B724E.6033@wrga.saic.com>, "J. Dean Roberson" <roberson@wrga.saic.com> writes:
>Does anyone have any experience or is knowledgeable of the feasability
>of utilizing the GNAT Ada environment (part of GNU/FSF) to support Ada
>development with VxWorks?  We have an application where the customer
>would like to get away from expensive Ada support environments
>(Rational) and go all GNU.  GNAT Ada is built on top of GCC and uses the
>GNU gcc compiler, so the port shouldn't be too hard.  Any
>advice/suggestions?
Have you tried contacting ACT? (Ada Core Technologies)
They offer support for GNAT, and might be aware of such a port if it exists.
I also read a comment from Robert Dewar of ACT that made me think they
have at least considered such a port of GNAT (on comp.lang.ada).
You can check their web site at: http://www.gnat.com
I hope this helps,
Steve Doiel
---------------------------
End of New-News digest
**********************
From AS_Bridge@MSMAIL3.HAC.COM  Fri Nov 15 07:00:17 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Fri Nov 15 07:00:20 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Fri, Nov 15, 1996 5:45 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Fri, Nov 15, 1996 6:58 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From MikeMcQuade@connect.com  Fri Nov 15 07:28:18 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Fri Nov 15 07:28:21 PST 1996
Subject: Re: Q: using RPC/XDR with Win NT
At 07:30 PM 11/14/96 PST, you wrote:
>>    Will XDR work with NT ?, if not, what are the possible work arounds ?
>
>I have found source for it on the net.  I just can't remember where.
>You might ask in one of the NT newsgroups.
>
Thanks, I found the source, and some additional info at:
http://set.gmd.de/~mfg/oncrpc.html
MikeMcQuade@connect.com
From fangcj@ix.netcom.com  Fri Nov 15 09:54:19 1996
From: CJ Fang <fangcj@ix.netcom.com>
Date: Fri Nov 15 09:54:22 PST 1996
Subject: Slow VxWorks on Pentium
I am running into a severe problem on a PCI Pentium
PC. VxWorks running on a 75M PCI Pentium is about
20 times slower than on 100M 486. Wind River has
not been able to give me any data related to
VxWorks performace on Pentium. Wind River can not
even tell me when they are going to support
Pentium. I am supprised that Wind River is not
moving to Pentium.
Is anyone of you guys using Pentium? Could you
please help me if you know something about my
problem? I appreciate!
I wrote a short routine and used "timexN" to
measure the execution speed of my routine. The
results were:
Pentium: 25656 microsecs
486:     1006 microsecs
My routine:
int test()
{
   int i, j;
   for (i=0; i< 20000; i++)
      j = i+ 1;
}
Test() was the only application running after
VxWorks booted up.
From pardo@rti.com  Fri Nov 15 13:19:15 1996
From: Gerardo Pardo-Castellote <pardo@rti.com>
Date: Fri Nov 15 13:19:17 PST 1996
Subject: Re: GNU tool chain versus MSVC
> From: banshee@banshee.com (James Moore)
> Having used both sets of tool chains, I have to say that the gnu/gdb setup
> blows away MSVC++.  (Caveat - I've only used C on the Unix side, and C++
> on the MSVC++ side.)  MSVC is pretty, but it's nowhere near as functional as
> gdb for debugging.  Not having a scripting language for a debugger is a
> serious defect, and I think the visual model for printing out variables is
> badly flawed - when you're using gdb, you can set a breakpoint that prints a
> variable and continues.  You end up with screenfuls of history that can be a
> lifesaver when you're trying to find what data breaks your code.  You can also
> write functions that do things like print out parts of linked lists.  There's
> just nothing at all in MSVC that gives you anything like the same
> functionality.
I agree with James, it may be easier to bootstrap a project from
scratch using MSVC but It has a lot of frustraing limitations.  In this
respect, MSVC's "make" facility comes out to mind, it is incredibly
primitive and seems to lack the ability to use environment variables,
or even include other makefiles.  This becomes a real problem if you
work on many projects or the project starts to grow: you end up
duplicating a lot of effort whenever you need to make changes accross
the board, or start second similar project.
Give me the GNU toolchain any day.
	-Gerardo
===========================================================================
=                                           =                             =
=   Gerardo Pardo-Castellote                =   email: pardo@rti.com      =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312     =
=   155A Moffett Park Drive, Suite 111      =   Fax:   (408) 734-5009     =
=   Sunnyvale, CA 94089                     =   http://www.rti.com        =
=                                           =                             =
===========================================================================
From pardo@rti.com  Fri Nov 15 13:33:48 1996
From: Gerardo Pardo-Castellote <pardo@rti.com>
Date: Fri Nov 15 13:33:51 PST 1996
Subject: Re: Slow VxWorks on Pentium
CJ,
We have used pentiums with VxWorks and found them significantly
faster than 486's
Your results seem really unusual (impossible?). your loop is about
4 assembly instructions long and it takes more then 1 usec, thats
75 clock cycles for the 75MHz pentium. I would check the following
things:
- Check that your cache is enabled on the pentium.
- Check that the VxWorks measurement of time is correct (e.g. time
a taskDelay(600) with a stop watch.
- Are you loading the same object to both? If not check the assembly
instructions on the Pentium code.
	-Gerardo
===========================================================================
=                                           =                             =
=   Gerardo Pardo-Castellote                =   email: pardo@rti.com      =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312     =
=   155A Moffett Park Drive, Suite 111      =   Fax:   (408) 734-5009     =
=   Sunnyvale, CA 94089                     =   http://www.rti.com        =
=                                           =                             =
===========================================================================
>>
>> I am running into a severe problem on a PCI Pentium
>> PC. VxWorks running on a 75M PCI Pentium is about
>> 20 times slower than on 100M 486. Wind River has
>> not been able to give me any data related to
>> VxWorks performace on Pentium. Wind River can not
>> even tell me when they are going to support
>> Pentium. I am supprised that Wind River is not
>> moving to Pentium.
>>
>> Is anyone of you guys using Pentium? Could you
>> please help me if you know something about my
>> problem? I appreciate!
>>
>> I wrote a short routine and used "timexN" to
>> measure the execution speed of my routine. The
>> results were:
>>
>> Pentium: 25656 microsecs
>>
>> 486:     1006 microsecs
>>
>> My routine:
>>
>> int test()
>> {
>>    int i, j;
>>
>>    for (i=0; i< 20000; i++)
>>       j = i+ 1;
>> }
>>
>> Test() was the only application running after
>> VxWorks booted up.
>>
From legoas_marco_a@space.honeywell.com  Fri Nov 15 14:12:22 1996
From: "Legoas Marco A" <legoas_marco_a@space.honeywell.com>
Date: Fri Nov 15 14:12:24 PST 1996
Subject: DOS file-IO question
The subroutine below fails intermitently when the file closes. Any ideas?
I am using 5.1 with mvme167 and Fujitso 520Meg SCSI drives.
Your help will be appreciated.
Marco A. Legoas
malegoas@space.honeywell.com
================================================
int readVwFile (textFileName, bufferPtr, buffMaxSize)
     char     *textFileName;
     char     *bufferPtr;
     int      buffMaxSize;
{
extern SEM_ID accessSemId;
  FILE      *textFile;       /* FILE pointer for the text file. */
  unsigned int numOfBytes;
  unsigned char * fileBuffer;
  int rtnVal;
semTake(accessSemId,WAIT_FOREVER);
if ((textFile = fopen(textFileName, "r")) != NULL)
    {
      numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile);
      bufferPtr[numOfBytes] = '\0';
      if (numOfBytes > 0 )
        rtnVal = numOfBytes;
      else
        rtnVal = ERROR;
    }
  else
      rtnVal = ERROR;
  fclose(textFile);
  semGive(accessSemId);
  return(rtnVal);
}
=====================================================
-> tt tusrintf
f3bc _vxTaskEntry   +10 : _cvit2UITask (0, 0, eeeeeeee, eeeeeeee, eeeeeeee,
eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee)
87b7ba _cvit2UITask   +ca : _XtAppMainLoop ([af6530, 0, f3be, 0, 0])
93d688 _XtAppMainLoop +1a : _XtAppNextEvent (af6530)
94343e _XtAppNextEvent+b0 : 943288 (af6530)
9432b2 __XtRemoveAllInputs+1b8: _cvit2UiWorkProc ([0, af6530, f4e6bc, f4e6a4,
943442])
87bd0c _cvit2UiWorkProc+548: _loadText (845390, f4e578)
897a5c _loadText      +2a : _readVwFile (f4e578, 69829c, 19000)
8714b2 _readVwFile    +5e : _fclose (6bcd74)
112d2 _fclose        +5a : ___sclose (6bcd74)
12ade ___sclose      +1c : _close ([11, 0, f4e468, 112d8, 6bcd74])
307d4 _close         +8  : _iosClose ([11, f4e454, 12ae4, 11, 0])
31472 _iosClose      +7c : 28ab4 (fd8288)
28be8 _stat          +1e2: _free (6b996c)
32882 _free          +e  : _memPartFree ([8352e, 6b996c, f4e420, 28bee, 6b996c]
        )
32618 _memPartFree   +dc : _taskSuspend (0)
 value = 0 = 0x0
From froeber@bbn.com  Fri Nov 15 17:10:50 1996
From: Fred Roeber <froeber@bbn.com>
Date: Fri Nov 15 17:10:52 PST 1996
Subject: Re: Slow VxWorks on Pentium
On Fri, 15 Nov 1996, CJ Fang wrote:
> I wrote a short routine and used "timexN" to
> measure the execution speed of my routine. The
> results were:
>
> Pentium: 25656 microsecs
>
> 486:     1006 microsecs
>
> My routine:
>
> int test()
> {
>    int i, j;
>
>    for (i=0; i< 20000; i++)
>       j = i+ 1;
> }
Your performance difference could very well have nothing to do with the
processors you are using but everything to do with the compiler and compiler
options you are using.  The routine above should be turned into a null
routine by any compiler with a good optimizer.  Try making i and j volatile
or global and see if you get the same results.  In general, you should be
very careful when benchmarking compilers and processors to use non-trivial
test programs.  There are useful benchmark suites in the public domain
that I have used in the past.  It has been a while since I ran benchmarks
but the comp.benchmarks news group FAQ used to have some good pointers
on this issue.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From YF.Siu@eng.efi.com  Fri Nov 15 17:14:27 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Fri Nov 15 17:14:29 PST 1996
Subject: Re:  DOS file-IO question
>      numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile);
>      bufferPtr[numOfBytes] = '\0';
If fread() happens to return buffMaxSize number of bytes, the
next statement is going to write beyond bufferPtr. This could
cause memory corruption depending on the size of the allocated
buffer.
Good Luck,
YF
From froeber@bbn.com  Fri Nov 15 17:25:15 1996
From: Fred Roeber <froeber@bbn.com>
Date: Fri Nov 15 17:25:18 PST 1996
Subject: Re: DOS file-IO question
On Fri, 15 Nov 1996, "Legoas Marco A" wrote:
>
> The subroutine below fails intermitently when the file closes. Any ideas?
>
> ================================================
> int readVwFile (textFileName, bufferPtr, buffMaxSize)
>      char     *textFileName;
>      char     *bufferPtr;
>      int      buffMaxSize;
> {
> extern SEM_ID accessSemId;
>
>   FILE      *textFile;       /* FILE pointer for the text file. */
>   unsigned int numOfBytes;
>   unsigned char * fileBuffer;
>   int rtnVal;
>
> semTake(accessSemId,WAIT_FOREVER);
> if ((textFile = fopen(textFileName, "r")) != NULL)
>     {
>       numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile);
>       bufferPtr[numOfBytes] = '\0';
>       if (numOfBytes > 0 )
>         rtnVal = numOfBytes;
>       else
>         rtnVal = ERROR;
>     }
< CUT...>
The  "bufferPtr[numOfBytes] = '\0';" statement above could cause
problems if you get an error return (ie numOfBytes < 0) since you would
be overwriting data that wasn't part of your data area.  Not really
sure why you want to NULL terminate data you are reading with an fread
call anyway?  Usually, you want to use fgets if you are reading textual
data since that routine takes care of handling newline characters and
null terminating input data.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From daemon@csg.lbl.gov  Sat Nov 16 04:00:27 1996
From: daemon@csg.lbl.gov
Date: Sat Nov 16 04:00:29 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Nov 16 04:00:23 PST 1996
        Subject: Re: Using GNAT Ada with VxWorks
        Subject: Re: varargs on PowerPC with 5.2
        Subject: Using GNAT Ada with VxWorks
        Subject: Re: VxWorks on Linux Host Survey Results
        Subject: SCSI and ethernet driver
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using GNAT Ada with VxWorks
Date: 15 Nov 1996 16:12:12 GMT
From: tadlock@bosch.dseg.ti.com (edward tadlock)
Message-ID: <TADLOCK.96Nov15101212@bosch.dseg.ti.com>
References: <328B724E.6033@wrga.saic.com>
Reply-To: ed-tadlock@ti.com
The best suggestion is to call WRS and ask questions about your
plans and see what they suggest.
My project at TI is using Rational (VADS) Ada and VxWorks via the
VADSWorks package (be careful, some problems with VADSWorks and Tornado).
As far as I know and have been told, VADWorks is the only fully supported Ada
interface to VxWorks. If you want to use the full real-time capabilites
of VxWorks,you'll need to buy/develop something like VADSWorks with
allows the Ada run-time to use the VxWorks kernal services. To develop
this kind of an interface you will need insight into the actual source code and
design of VxWorks at the kernel level. If you need to do this
interface yourself, Wind River will sell the source for VxWorks
but they do ask a BIG price for copies of the source code.
Moving to GNAT is not impossible to do, but it might be
cheaper in the long run to buy a package from Wind River or Rational
since the price includes support. Also, unless you can get a BSP for
your chips and boards from WRS that is also something you'll have to
build yourself. WRS has a "porting" kit they sell to help you do this.
So, call WRS and ask before committing to using GNAT Ada and VxWorks
together. As always, YMMV...
                        Ed
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: varargs on PowerPC with 5.2
Date: 15 Nov 1996 17:06:59 GMT
From: litwin@robotics.jpl.nasa.gov (Todd Litwin)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Message-ID: <56i7vj$mbm@netline-fddi.jpl.nasa.gov>
References: <555bdp$cms@post.gsfc.nasa.gov>
Joe Vitale writes:
> We have run into a dead end trying to implement our own functions that
> take a variable number of arguments as input.  We are using VxWorks
> 5.2 on an Ultra PowerPC 603 motherboard.  We are using the Green Hills
> C/C++ Compiler and everything is hosted on a Solaris workstation.
I don't know anything about your specific environment. But if you are willing
to consider inserting your own support for varargs, and not using the one
provided by your development environment, then you might consider what I've
done. Back in the old days on a DEC VAX/VMS machine before DEC's C compiler
supported varargs, I wrote a set of macros which worked just fine. I've
included them below. They may not work on your system without some
modification, but give them a try. If you have any trouble understanding what
they are doing, feel free to ask. (In particular, the reason for the +3 and /4
is that VMS only pushed items onto the call stack in multiples of 4 bytes,
padding out if necessary.)
Below is the contents of varargs.h:
/****************************************************************************
*                                                                           *
*                              varargs.h                                    *
*                                                                           *
****************************************************************************/
/* varargs.h
 *    Implemented by Todd Litwin
 *    February 7, 1984
 *
 * This implementation, which conforms to the Berkeley UNIX manual quoted
 * below, has been designed to work with the VAX VMS C compiler.
 */
/*
SYNOPSIS
	#include <varargs.h>
	function(va_alist)
	va_dcl
	va_list pvar;
	va_start(pvar);
	f = va_arg(pvar, type)
	va_end(pvar);
DESCRIPTION
	This set of macros allows portable procedures that accept variable
	argument lists to be written. Routines which have variable argument
	lists (such as printf(3)) that do not use varargs are inherently
	nonportable since different machines use different argument passing
	conventions.
	va_alist is used in a function header to declare a variable argument
	list.
	va_dcl is a declaration for va_alist. Note that there is no semicolon
	after va_dcl.
	va_list is a type which can be used for the variable pvar, which is
	used to traverse the list. One such variable must always be declared.
	va_start (pvar) is called to initialize pvar to the beginning of the
	list.
	va_arg (pvar,type) will return the next argument in the list pointed
	to by pvar. Type is the type the argument is expected to be. Different
	types can be mixed, but it is up to the routine to know what type of
	argument is expected, since it cannot be determined at runtime.
	va_end (pvar) is used to finish up.
	Multiple traversals, each bracketted by va_start ... va_end, are
	possible.
[UNIX Programmer's Manual, 7th edition, 1979, VARARGS(3)]
*/
#define va_alist _VA_Arg1
#define va_dcl int _VA_Arg1;
typedef struct {
	int *ptr;
	int width;
	} va_list;
#define va_start(pvar) ((pvar.ptr = &_VA_Arg1), (pvar.width = 0))
#define va_arg(pvar, type) \
	(((int *) pvar.ptr += pvar.width), \
	(pvar.width = (((sizeof (type)) + 3) / 4)), \
	(*((type *) (pvar.ptr))))
#define va_end(pvar)
- --
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		Todd.E.Litwin@jpl.nasa.gov
---------------------------
Newsgroups: comp.os.vxworks
Subject: Using GNAT Ada with VxWorks
Date: Thu, 14 Nov 1996 14:30:31 -0500
From: "J. Dean Roberson" <roberson@wrga.saic.com>
Organization: SAIC
Message-ID: <328B724E.6033@wrga.saic.com>
Reply-To: roberson@wrga.saic.com
Does anyone have any experience or is knowledgeable of the feasability
of utilizing the GNAT Ada environment (part of GNU/FSF) to support Ada
development with VxWorks?  We have an application where the customer
would like to get away from expensive Ada support environments
(Rational) and go all GNU.  GNAT Ada is built on top of GCC and uses the
GNU gcc compiler, so the port shouldn't be too hard.  Any
advice/suggestions?
Our target boards are FORCE CPU-2CE (SPARC-yuck!) and some older
Heurikon HKV30 (68K) and Heurikon Baja (MIPS R4700) boards for the
future (Heurikon forever!).  Staying all gcc makes a lot of sense, but
we have no experience with GNAT.
Thanks for any advice,
Dean.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks on Linux Host Survey Results
Date: 15 Nov 1996 14:32:08 -0700
From: bgeer@xmission.xmission.com (bgeer)
Organization: XMission Internet (801 539 0900)
Message-ID: <56ingo$2c9@xmission.xmission.com>
References: <9611141501.ZM3551@bnlku5.phy.bnl.gov>
"Steve Adler" <adler@bnlku5.phy.bnl.gov> writes:
I responded positively to Steve wrt VxWorks support on Linux.  I have
at least 3 work colleagues who use Linux extensively & also would like
the option to develop for VxWorks on Linux; unfortunately I could not
get them to take the time to respond to Steve hence aren't represented
in Steve's numbers.  You'd have to know Utah culture to understand why
these guys couldn't take the time...:-)
 >... The resons are obvious for anyone who runs linux on their home PC.
Actually, I run Linux at both work & home.  It beats the hell out of
Windoze for networking with Unix boxes, is far more reliable, & has a
much more flexible desktop environment.  I only boot Windoze to do my
time card 'cause it's programmed in Visual Basic...:-(
BTW, my 486DX2-66 manages 12.5 Whetstones running Linux, same as a Sun
Sparc IPX.  My AMD5x86-133 at home manages 25-33.333, same as Sun
Sparc 10.
Ok...so Whetstone isn't a particularly good benchmark these days; but
hey, the numbers are impressive, aren't they?  :-)
 >I wanted to use the results of this survey to motivate RWS to port
 >their Tornado package to Linux.
I'd be happy with Linux (intel) gcc to [68k, mips, sparc, powerpc]
cross compiler & object manipulation tools.  I'll bet the scripts &
makefiles would port almost directly (I have been able to make scripts
completely compatible).  Considering how easy it is to build
applications for both SunOS4 & Linux, I'll bet the compilables would
port almost directly as well.
Linux gives one a robust, stable environment for development, & it
runs very well (including X) on much-cheaper-than-Unix laptops.
[Stepping down from soapbox...]  Cheers, Bob
- --
<> Robert Geer & Donna Tomky /              *             <>
<>    bgeer@xmission.com    |    _o      *   o *      o   <>
<>   Salt Lake City, Utah   |   -\<,      * <\      </L   <>
<>          U S A           |   O/ O     __ /__,    />    <>
---------------------------
Newsgroups: comp.os.vxworks
Subject: SCSI and ethernet driver
Date: Sat, 16 Nov 1996 01:27:28 +0000
From: Hung Tran <hung@dynatem.com>
Organization: Dynatem
Message-ID: <328D1880.479D@dynatem.com>
Hi all,
Anyone out there have driver source code available for the DEC21140A
fast ethernet LAN controller and/or the SCSI Adaptec AIC-7880 ? One
for the x86 architecture would be preferable, but anything else
would still be helpful.
Hung
---------------------------
End of New-News digest
**********************
From jford@sadira.gb.nrao.edu  Sat Nov 16 10:56:03 1996
From: jford@sadira.gb.nrao.edu (John Ford)
Date: Sat Nov 16 10:56:06 PST 1996
Subject: Re: Slow VxWorks on Pentium
   Submitted-by froeber@bbn.com  Fri Nov 15 17:10:50 1996
   Submitted-by: Fred Roeber <froeber@bbn.com>
   On Fri, 15 Nov 1996, CJ Fang wrote:
   > I wrote a short routine and used "timexN" to
   > measure the execution speed of my routine. The
   > results were:
   >
   > Pentium: 25656 microsecs
   >
   > 486:     1006 microsecs
   >
   > My routine:
   >
   > int test()
   > {
   >    int i, j;
   >
   >    for (i=0; i< 20000; i++)
   >       j = i+ 1;
   > }
   Your performance difference could very well have nothing to do with the
   processors you are using but everything to do with the compiler and compiler
   options you are using.
...
Agreed,
		But he could also be running into a system management mode
problem.  The system's, bios/chipset could be putting the CPU in some
sort of sleep mode.  This could also happen if the CPU is getting too
hot, or if the BIOS does not see any activity for a while.
--
John Ford
National Radio Astronomy Observatory
Green Bank, WV 24944-0002
jford@nrao.edu
From daemon@csg.lbl.gov  Sun Nov 17 04:00:25 1996
From: daemon@csg.lbl.gov
Date: Sun Nov 17 04:00:27 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Nov 17 04:00:22 PST 1996
        Subject: SCSI Drivers for sequential access?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: SCSI Drivers for sequential access?
Date: Sat, 16 Nov 1996 12:56:22 -0800
From: dhayes49@mail.idt.net (Dean Hayes)
Organization: IDT
Message-ID: <dhayes49-1611961256220001@port10.annex5.nwlink.com>
Has anyone used the scsiIoctl function call to implement a device driver
for sequential access devices?
The VxWorks kernel is extremely lacking in this respect.  There release notes
say to "roll your own", or to higher a third party.
IN particular, I am dealing with an HP DAT tape drive.
---------------------------
End of New-News digest
**********************
From fareed@aloha.nmsu.edu  Mon Nov 18 17:52:16 1996
From: Fareed Masarrat <fareed@aloha.nmsu.edu>
Date: Mon Nov 18 17:52:19 PST 1996
Subject: SCSI drives
I am having a problem with SCSI drives in a VME enclosure. When a file is
created on the drives, it is corrupted by any files which are created
after it. It is corrupted in the sense that after the 1024 byte, the data
in the file is different that what was originally placed in the file.
That might be a jumper problem but it has been checked and verified. I
would appreciate if anybody can give us any direction to go further.
Thanks
----------------------------
Fareed
Research Assistant
New Mexico State University
----------------------------
From YF.Siu@eng.efi.com  Mon Nov 18 18:15:52 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Mon Nov 18 18:15:58 PST 1996
Subject: EIDE/ATA-2 driver
Has anyone got the EIDE/ATA-2 driver package
from WRS ? I would like to gather some comment
and know if CDROM support has been included.
Thanks,
YF
From parikh@ll.mit.edu  Mon Nov 18 19:00:30 1996
From: Salil Parikh <parikh@ll.mit.edu>
Date: Mon Nov 18 19:00:33 PST 1996
Subject: Cold Boot / Warm Boot
Is there a way in VxWorks to distinguish between a warm boot and a cold boot?
I'm using the Motorola MVME147 SBC.
Thanks!
From ensslin@dreisoft.de  Tue Nov 19 01:52:23 1996
From: Friedrich Ensslin <ensslin@dreisoft.de>
Date: Tue Nov 19 01:52:26 PST 1996
Subject: 53C810 SCSI Controller
Hi all,
Does anyone have any info on VxWorks SCSI drivers for the NCR 53C810 SCSI Controller.
Thanks fo the info.
------------------------------------------------
  Friedrich Ensslin
  3SOFT GmbH
  Wetterkreuz 19a , D-91058 Erlangen , Germany
  phone: +49 9131 7701-0 , fax: +49 9131 7701-80
  email: ensslin@dreisoft.de
From ensslin@dreisoft.de  Tue Nov 19 01:56:58 1996
From: Friedrich Ensslin <ensslin@dreisoft.de>
Date: Tue Nov 19 01:57:00 PST 1996
Hi all,
Does anyone have any info on VxWorks PCMCIA drivers.
One of our customers wants to connect a PCMCIA solid state disk to his VxWorks 5.3 target, using a 82365SL PCMCIA controller chip.
Thanks for the info.
------------------------------------------------
  Friedrich Ensslin
  3SOFT GmbH
  Wetterkreuz 19a , D-91058 Erlangen , Germany
  phone: +49 9131 7701-0 , fax: +49 9131 7701-80
  email: ensslin@dreisoft.de
From daemon@csg.lbl.gov  Tue Nov 19 04:00:19 1996
From: daemon@csg.lbl.gov
Date: Tue Nov 19 04:00:22 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Nov 19 04:00:17 PST 1996
        Subject: Re: VxWorks on Linux Host Survey Results
        Subject: VxWorks and x86???
        Subject: VxWorks and x86???
        Subject: Re: Using GNAT Ada with VxWorks
        Subject: multicast & VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks on Linux Host Survey Results
Date: 18 Nov 1996 16:21:42 GMT
From: thor@ymir.atd.ucar.edu (Rich Neitzel)
Organization: National Center for Atmospheric Research
Message-ID: <56q2em$jru@ncar.ucar.edu>
References: <9611141501.ZM3551@bnlku5.phy.bnl.gov> <56ingo$2c9@xmission.xmission.com>
In article <56ingo$2c9@xmission.xmission.com>, bgeer@xmission.xmission.com
(bgeer) writes:
|>
|> I'd be happy with Linux (intel) gcc to [68k, mips, sparc, powerpc]
|> cross compiler & object manipulation tools.  I'll bet the scripts &
|> makefiles would port almost directly (I have been able to make scripts
|> completely compatible).  Considering how easy it is to build
|> applications for both SunOS4 & Linux, I'll bet the compilables would
|> port almost directly as well.
I've compiled the entire GNU tool chain under Linux for 68k
targets. No problems noted to date. Tool compilation was identical to
the build under Solaris 2.x. Makefiles for target programs are
identical as well. Futher, I've got the 68ks booting off the Linux
system via bootp. We could completely replace our Suns as developement
hosts if we didn't have so many of them.
- --
Richard Neitzel thor@atd.ucar.edu               Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjx'i med sitt shinn
303-497-2057                                    jagar borni inn.
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks and x86???
Date: 18 Nov 1996 16:02:47 GMT
From: enzo@u1.abs.net (Jerome Kelly)
Organization: ABSnet Internet Services - sales@abs.net - (410)-361-8160
Message-ID: <56q1b7$c0b@news.abs.net>
- --
- ---------------------------------------------------------------------------
| EnzoH2O    <enzo@abs.net> |"I can picture in my mind a world without	  |
| Jerry Kelly               |war, a world without hate.  And I can picture|
| Alexandria, Virginia, USA |us attacking that world, because they'd never|
|                           |expect it."                                  |
- ---------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks and x86???
Date: 18 Nov 1996 16:13:40 GMT
From: enzo@u1.abs.net (Jerome Kelly)
Organization: ABSnet Internet Services - sales@abs.net - (410)-361-8160
Message-ID: <56q1vk$c0b@news.abs.net>
- --
- ---------------------------------------------------------------------------
| EnzoH2O    <enzo@abs.net> |"I can picture in my mind a world without	  |
| Jerry Kelly               |war, a world without hate.  And I can picture|
| Alexandria, Virginia, USA |us attacking that world, because they'd never|
|                           |expect it."                                  |
- ---------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Using GNAT Ada with VxWorks
Date: 18 Nov 1996 14:23:58 -0500
From: hartwig@hartwig.lfso.loral.com (Michael R. Hartwig)
Organization: Lockheed Martin Federal Systems
Message-ID: <wymhgmn8awh.fsf@hartwig.lfso.loral.com>
References: <328B724E.6033@wrga.saic.com>
	<TADLOCK.96Nov15101212@bosch.dseg.ti.com>
Reply-To: michael.hartwig@lmco.com
Sender: hartwig@hartwig.lfso.loral.com
In article <TADLOCK.96Nov15101212@bosch.dseg.ti.com>
  tadlock@bosch.dseg.ti.com (edward tadlock) writes:
> As far as I know and have been told, VADWorks is the only fully supported Ada
> interface to VxWorks.
Green Hills Ada Multi is supposed to be fully Tornado-aware.  It will generate
code for VxWorks.  I'd give you a better report, but we just got our
evaluation copy of the Green Hills compilers on Friday and haven't had a
chance to get them up and running yet.
Michael
- --
Michael Hartwig					Michael.Hartwig@lmco.com
Lockheed Martin Federal Systems, Owego, NY
---------------------------
Newsgroups: comp.os.vxworks
Subject: multicast & VxWorks
Date: Mon, 18 Nov 1996 17:16:59 -0800
From: Gary Steven Fish <gsfish@ccgate.hac.com>
Organization: Hughes Aircraft Co. WSS/NAMS
Message-ID: <32910A8B.6C@ccgate.hac.com>
References: <199611121456.JAA10880@atlas.gb.nrao.edu> <328AA823.41C67EA6@xmission.com>
Wes Peters wrote:
>
> JOE BRANDT wrote:
> > At least two persons I know have patched and tested the VxWorks networking
> > code to add multicasting, AND SENT the patches back to WRS.
> >
> > Ask WRS about this and they have no knowledge of it. For pretty much zero
> > effort, they could have added this technology.
> >
> > Why is multicasting a big deal in a RT-OS?
> > How many of your RT systems have some sort of monitoring? Multicast allows
> > a single packet sent from a VxWorks system to be delivered to any number
> > of monitoring stations. For efficientcy reasons multicast is the way to go.
>
Can anyone tell me where I can get a copy of this multicast software that has been ported to VxWorks 5.2
and/or 5.3?  If it is not yet available on one of the archives, can someone email me a copy of the
above mentioned patch or tell me who to contact?
Thanks in advance,
- --
Gary S. Fish
Sr. Staff Eng.		Work  - 714-732-7343
Hughes Aircraft Co.	FAX   - 714-732-0149
Fullerton Ca.		Email - gsfish@ccgate.hac.com
---------------------------
End of New-News digest
**********************
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 19 04:16:02 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 19 04:16:04 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Sent: Tue, Nov 19, 1996 3:11 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 19, 1996 4:15 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 19 04:16:04 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 19 04:16:07 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: 53C810 SCSI Controller
Sent: Tue, Nov 19, 1996 3:12 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 19, 1996 4:15 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 19 06:19:54 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 19 06:19:56 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: comp.os.vxworks newsdigest
Sent: Tue, Nov 19, 1996 5:14 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 19, 1996 6:17 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From legoas_marco_a@space.honeywell.com  Tue Nov 19 06:37:23 1996
From: "Legoas Marco A" <legoas_marco_a@space.honeywell.com>
Date: Tue Nov 19 06:37:25 PST 1996
Subject: Thanks:DOS file-IO question
Would like to thanks:
Lasse Kinnunen,
Fred J Roeber,
Yuet Fung Siu,
Alan Nishioka.
for their valuable feedback.
Marco A. Legoas
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 19 06:38:38 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 19 06:38:40 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Undeliverable Mail
Sent: Tue, Nov 19, 1996 5:37 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 19, 1996 6:37 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From AS_Bridge@MSMAIL3.HAC.COM  Tue Nov 19 06:41:41 1996
From: "AS Bridge" <AS_Bridge@MSMAIL3.HAC.COM>
Date: Tue Nov 19 06:41:43 PST 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.
Message: Undeliverable Mail
Sent: Tue, Nov 19, 1996 5:38 AM
To: Carroll, John C; Claudio, Michael A
On Server: 631 Segment5
Date: Tue, Nov 19, 1996 6:39 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.
From intrepid!minidds@uunet.uu.net  Tue Nov 19 08:40:43 1996
From: intrepid!minidds@uunet.uu.net (Lee Kappel)
Date: Tue Nov 19 08:40:45 PST 1996
Subject: tnetTask, Serial I/O, and Ring Buffers
Has anyone had trouble with corruption of ring buffers and
a resulting instruction access exception in tnetTask.
We are using VxWorks 5.3, and our target is the PowerPC 604
(Motorola MVME1604).
The only application running is doing continuous serial
output to comm port 1 (/tyCo/0), and we are not sure why
tnetTask is active at all unless it is maintaining some
periodic communication with our host.
Thanks,
  >>>>>>>>>>>>>>>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >>>> Lee Kappel >>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>>>>>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  ~ Raytheon E-Systems Communications Division ~
                 ~          P.O. Box 12248, M.S. 61             ~
                ~        St. Petersburg, FL 33733-2248           ~
                ~        Phone: 813-381-2000 ext. 7209           ~
                 ~            Fax: 813-347-2890                 ~
                  ~       E-Mail: kappel@eci-cec.com           ~
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From espin@idiom.com  Tue Nov 19 09:12:36 1996
From: Geoffrey Espin <espin@idiom.com>
Date: Tue Nov 19 09:12:42 PST 1996
Subject: Re: Cold Boot / Warm Boot
> Submitted-by: Salil Parikh <parikh@ll.mit.edu>
> Is there a way in VxWorks to distinguish between a warm boot and a cold boot?
> I'm using the Motorola MVME147 SBC.
It's pretty straight-forward to track down on any BSP & Architecture
because you have all the source code required.  With the traditional 68k
bootrom which loads vxWorks, the hand-off is accomplished by the two entry
points "cold:" and "warm:" in romInit.s.  On a power-cycle "romInit:" goes
thru the "cold:" entry point which pushes the startType on the stack which
bootInit.c:romStart() picks up, uses and passes on to bootConfig.c:usrInit().
A warm-start by definition goes thru sysLib.c:sysToMonitor() which knows (via
Makefile ROM_TEXT_ADRS) the "warm:" entry point in romInit.s.  By the time the
actual vxWorks image is loaded the startType is considered "warm" in
sysALib.s:sysInit().  The sequence is simpler for vxWorks_rom and in
fact better because the startType for the new incarnation has not
been lost by going thru sysALib.s:sysInit().
Geoff
--
Geoffrey Espin espin@idiom.com
From sridhar@prc.allied.com  Tue Nov 19 10:30:07 1996
From: sridhar@prc.allied.com (Sridhar Adumusilli)
Date: Tue Nov 19 10:30:14 PST 1996
Subject: GNU Compiler 2.6
Does any one know if 2.6 version can be used to compile
templates?
Thanks for any help.
Sridhar
AlliedSignal Aerospace
From mikemcquade@connect.com  Tue Nov 19 12:07:10 1996
From: mikemcquade@connect.com
Date: Tue Nov 19 12:07:12 PST 1996
Subject: Re: tnetTask, Serial I/O, and Ring Buffers
the vxWorks Users Group Exploder wrote:
>
> Submitted-by intrepid!minidds@uunet.uu.net  Tue Nov 19 08:40:43 1996
> Submitted-by: intrepid!minidds@uunet.uu.net (Lee Kappel)
>
> Has anyone had trouble with corruption of ring buffers and
> a resulting instruction access exception in tnetTask.
>
> We are using VxWorks 5.3, and our target is the PowerPC 604
> (Motorola MVME1604).
>
> The only application running is doing continuous serial
> output to comm port 1 (/tyCo/0), and we are not sure why
> tnetTask is active at all unless it is maintaining some
> periodic communication with our host.
>
Ive seen the same thing on a MVME-1604 (133Mhz), my app is reading data
off the VME bus, and sending it out over the Lan, Ive seen tNetTask
panic: mget, panic: mfree, and more often, the target just crashes
with no clues.
I can compile the same app for 603, and run on a 603e for hours on end.
Mike
From stan@rti.com  Tue Nov 19 12:51:27 1996
From: Stan Schneider <stan@rti.com>
Date: Tue Nov 19 12:51:29 PST 1996
Subject: Re: GNU Compiler 2.6
>>
>> Does any one know if 2.6 version can be used to compile
>> templates?
>>
Sort of.  You can compile *a* template, but if you ever derive two objects from
it & try to use both, it will fail.  2.7.2 fixed this problem.
        -- Stan
           stan@rti.com
From fareed@aloha.nmsu.edu  Tue Nov 19 14:19:02 1996
From: Fareed Masarrat <fareed@aloha.nmsu.edu>
Date: Tue Nov 19 14:19:04 PST 1996
Subject: Re: SCSI drives
We are using VxWorks 5.2 and the target is FORCE 68040.
We are having a problem with SCSI drives in a VME enclosure. When a file is
created on the drives, it is corrupted by any files which are created
after it. It is corrupted in the sense that after the 1024 byte, the data
in the file is different that what was originally placed in the file.
That might be a jumper problem but it has been checked and verified. I
would appreciate if anybody can give us any direction to go further.
Thanks
----------------------------
Fareed
Research Assistant
New Mexico State University
----------------------------
From uchenick@tis4000.com  Tue Nov 19 14:35:37 1996
From: Gordon Uchenick <uchenick@tis4000.com>
Date: Tue Nov 19 14:35:39 PST 1996
Subject: errno = EHOSTDOWN
Does anyone have any words of wisdom about how to
handle errno = EHOSTDOWN after send() on a TCP/IP
socket returns ERROR? I'm looking for a less drastic
solution than closing the socket and reestablishing the
connection.
TIA
Gordon Uchenick
uchenick@tis4000.com
From froeber@bbn.com  Tue Nov 19 18:49:54 1996
From: Fred Roeber <froeber@bbn.com>
Date: Tue Nov 19 18:49:56 PST 1996
Subject: Re: Cold Boot / Warm Boot
On Mon, 18 Nov 1996, Salil Parikh wrote:
> Is there a way in VxWorks to distinguish between a warm boot and a cold boot?
>
> I'm using the Motorola MVME147 SBC.
The variable sysStartType contains flag bits that indicate the type of
start that occured.  There are values that can be used to distinguish a
warm vs a cold start.  Look at the source files in the config/all
directory for uses of sysStartType.  Look at the romInit.s file in the
config/mv147 for the values it sets startType parameter to (the startType
parameter gets stored in sysStartType).  While that answers your question,
I am not sure that it addresses what you really want.  A lot of times, I
consider a cold start to be a "power up" start and a warm start to be a
restart due to a VME reset.  This isn't the meaning of the cold and warm
start flags in sysStartType; the VxWorks flags are based on whether the
processor boots from a reset or from a "reboot" function call (i.e. a
^X console command).  There is a status bit in one of the MV147 peripheral
chips that indicates a power-up vs other restart but the bit is cleared
by the VxWorks startup code (in sysHwInit function in sysLib.c I think).
You could always modify the BSP to save that bit if that is what you really
want.  Hope the info helps.  Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From daemon@csg.lbl.gov  Wed Nov 20 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Wed Nov 20 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Nov 20 04:00:19 PST 1996
        Subject: Recursive Makefiles under NT
        Subject: Re: Cold Boot / Warm Boot
        Subject: Re: Recursive Makefiles under NT
        Subject: STREAMS ioctl error
        Subject: Re: GNU tool chain versus MSVC
        Subject: Porting DLL
        Subject: Date/Time on x86 platform??
        Subject: test
        Subject: test
        Subject: problem if gettimeofday()
        Subject: Re: Delta-Tau PMAC Driver
        Subject: need your HELP!!!
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Recursive Makefiles under NT
Date: Tue, 19 Nov 1996 15:22:03 GMT
From: jasonv@delphi-assoc.com (Jason Velody)
Organization: delphi-assoc.com
Message-ID: <3291d000.20436640@news1.theplanet.co.uk>
Hi there,
Has anyone managed to get recursive makefiles to work properly under
Tornado for Windows? I am suffering from a singular lack of success.
Yours despondently
Jason
- ------------------------------------------------------------------------------
    You are lost in a maze of twisty little standards
        - all conflicting...
Jason Velody                                           jasonv@delphi-assoc.com
Senior Network Consultant
                                                 http://www.angel.co.uk/delphi
Delphi Associates Ltd                                       (+44) 171 357 0303
- ------------------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Cold Boot / Warm Boot
Date: Sun, 17 Nov 96 06:42:21 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56sl6u$3ki@idiom.com>
References: <9611182158.AA21018@LL.MIT.EDU>
In article <9611182158.AA21018@LL.MIT.EDU>, Salil Parikh <parikh@ll.mit.edu> wrote:
>
>
>Is there a way in VxWorks to distinguish between a warm boot and a cold boot?
>
sysToMonitor() gets called with an argument indicating cold/warm boot.
In general, this is distinguishable in low level start up code, and
you can control it as you please.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Recursive Makefiles under NT
Date: Sun, 17 Nov 96 06:40:21 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <56sl36$3ki@idiom.com>
References: <3291d000.20436640@news1.theplanet.co.uk>
In article <3291d000.20436640@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote:
>Hi there,
>
>Has anyone managed to get recursive makefiles to work properly under
>Tornado for Windows? I am suffering from a singular lack of success.
>
Works fine for me.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: STREAMS ioctl error
Date: 19 Nov 1996 17:33:52 GMT
From: markkelly9@aol.com
Organization: America Online, Inc. (1-800-827-6364) (1.13)
Message-ID: <19961119173600.MAA26475@ladder01.news.aol.com>
I am trying to port a STREAMS based package to vxWorks using their WindNet
STREAMS for Tornado x86 release 1.0 dated Sep 20 1996. I get an error on
an ioctl call:
    if ((retStat = ioctl(B->fd, I_STR, (int)&ioctlmsg)) != 0)
    {
        ioctlfailed = TRUE;
        printf("ioctl failed with return status=%d errno=%d\n", retStat,
errno);
    }
retStat is -1 and errno is 74.
errno.h defines ENOSR as 74.
Does anyone know what causes an ENOSR error?  Is there some STREAMS or
system V newsgroup I should be reading?
Thanks,
Mark Kelly
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: GNU tool chain versus MSVC
Date: Tue, 19 Nov 1996 18:44:49 GMT
From: VanCLy@ix.netcom.com (Van Chinh Ly)
Organization: Netcom
Message-ID: <56sv3s$n5n@sjx-ixn8.ix.netcom.com>
References: <199611152123.NAA19052@lassen.rti.com>
Reply-To: VanCLy@ix.netcom.com
Gerardo Pardo-Castellote <pardo@rti.com> wrote:
>I agree with James, it may be easier to bootstrap a project from
>scratch using MSVC but It has a lot of frustraing limitations.  In this
>respect, MSVC's "make" facility comes out to mind, it is incredibly
>primitive and seems to lack the ability to use environment variables,
>or even include other makefiles.  This becomes a real problem if you
If you are referring to the program NMAKE.EXE, I believe you can
use environment variables by referring to them in the makefile
with percent signs surrounding the variable name.  (e.g. %PATH%
would give you the current path).  As for including other makefiles,
that is possible with the command "!INCLUDE," as most make
files from Microsoft start with "!INCLUDE <ntwin32.mak>" which
basically includes that file in the original makefiles.
They may not be the same syntax that the GNU make uses, but I think
the capabilities are there.
Van
---------------------------
Newsgroups: comp.os.vxworks
Subject: Porting DLL
Date: Wed, 20 Nov 1996 10:18:48 +0900
From: "Lee, Soo-Ryong" <zorba@gsen.goldstar.co.kr>
Organization: LGNIC
Message-ID: <32925C78.315F@gsen.goldstar.co.kr>
Hi, everyone
I'm wondering how can I port windows DLL program into vxworks
environment.
Any comment O.K.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Date/Time on x86 platform??
Date: Tue, 19 Nov 1996 21:47:20 -0800
From: eric olsen <eolsen@leland.stanford.edu>
Organization: stanford university
Message-ID: <32929B68.76D6829D@leland.stanford.edu>
Hello,
Does anyone have the appropriate code to get the date/time
from the bios. The 'ansi' time function supplied with vxworks
does not return the actual date, even though there is a clock
on the pc keeping track of it.
Thanks,
- --------------------------------------------------------------
"How can I lose to such an idiot?"
                            Aaron Nimzovich(1886-1935)
 eric olsen
 eolsen@leland.stanford.edu
- --------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: test
Date: Wed, 20 Nov 1996 17:44:31 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <3292D2FF.167EB0E7@ee.ust.hk>
test
---------------------------
Newsgroups: comp.os.vxworks
Subject: test
Date: Wed, 20 Nov 1996 17:52:54 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <3292D4F6.446B9B3D@ee.ust.hk>
test
---------------------------
Newsgroups: comp.os.vxworks
Subject: problem if gettimeofday()
Date: Wed, 20 Nov 1996 17:48:00 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <3292D3D0.2781E494@ee.ust.hk>
when download to MVME166, MC68040CPU, it hints:
- -> ld < try.o
undefined symbol: _gettimeofday
ld error: error reading file (errno = 0x1c0001).
value = 0 = 0x0
anyone know the reson?
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Delta-Tau PMAC Driver
Date: Wed, 20 Nov 1996 18:01:04 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <3292D6E0.794BDF32@ee.ust.hk>
References: <562m1h$1lf@maxwell14.ee>
I have some example files for VME bus Delta-Tau PMAC board, have some
problems when I compile on VxWork. I do not know if it is what you need.
eezhcai@ee.ust.hk
Adam T. Atherton wrote:
>
> I am working on a student project using the PMAC board, and if
> possible I would like a copy of the driver too.
>
> Thanks,
> Adam Atherton
> atathert@mtu.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: need your HELP!!!
Date: Wed, 20 Nov 1996 17:19:32 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <3292CD24.41C67EA6@ee.ust.hk>
Hi, everyone:
	I am using a Bisight system of Helpmate comp, includes a VME PMAC servo
board in MVME166 single board computer. I have gotten some example files
from Helpmate comp. and it is in standard C mode. Now I want to compile
them to MC68040 mode, and I found some error massages include "
undefined symbol: _gettimeofday ". following is the process of compile:
	step 1: cc68k -nostdinc -I/robot/vx/h -I/staff/ee/eerobot/czh/czh
- -DCPU=MC68040 -O -c example.c pmacio.c utilities.c ptv.c
	Step 2: ld68k -o try.o -r example.o pmacio.o ptv.o utilities.o
	Step 3: ld < try.o
result:
- -> ld < try.o
undefined symbol: _gettimeofday
ld error: error reading file (errno = 0x1c0001).
value = 0 = 0x0
And when I did not use the -c option, the sys hinted lots of error
messages. I am not sure if I must mention a standard C library for
cc68k? My VxWork version is 5.1
Waiting for your help.
Cai, Zhihong
eezhcai@ee.ust.hk
---------------------------
End of New-News digest
**********************
From alon@radcom.co.il  Wed Nov 20 06:45:32 1996
From: "Alon Ecker" <alon@radcom.co.il>
Date: Wed Nov 20 06:45:35 PST 1996
Subject: Compilation problem in C++
SYNOPSIS OF PROBLEM         : Compilation problem
AFFECTED MODULE             : <Unknown>
PRODUCT NAME                : Tornado 1.0
DATE                        : Nov 20, '96 - 15:30
REPORTED BY                 : Alon Ecker
    CONTACT                 : Alon Ecker
    COMPANY                 : RADcom
    LICENSE NUMBER          : 3616
    EMAIL                   : alon@radcom.co.il
    ADDRESS                 : 12 Hanechoshet st. 69710, Tel-Aviv Israel.
                            : NA
    PHONE                   : 972-3-6455183
    CUSTOMER REFERENCE#     : <Unknown>
SYSTEM CONFIGURATION        :
    HOST                    : Win NT 3.5
    ARCH                    : I960CA
    BSP                     : EP960CX
    OTHER PERIPHERALS       : <Other Hardware Devices>
DESCRIPTION OF PROBLEM  :
<Demontration>
I have tried to compile  files test.h test.cpp. The comilation problem
appears when I use the '-g' option for the compiler. It shouts that
it can't assemble the temporary assembler file. This is  the
problematic syntaxl:
	((this)->*callme)();
I get the following message:
cc960 -mca -mstrict-align  -O -fvolatile -fno-builtin  -Wall -I/h
-I. -Id:\Tornado\targe t\config\all -Id:\Tornado\target/h
-Id:\Tornado\target/src/config -Id:\Tornado\target/src/ drv -ansi
-nostdinc -DCPU=I960CA -DVX_IGNORE_GNU_LIBS  -g   -c
i:\inter.rtc\test.cpp C:\TMP\cca00131.s:
 Assembler messages:
C:\TMP\cca00131.s:9:
 Error: Rest of line ignored. First ignored
character is `:'. C:\TMP\cca00131.s:13: Error: Rest of line ignored.
First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of
line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38:
Error: Rest of line ignored. First ignored character is `:'. cc960:
Internal compiler error: program as got fatal signal 1 make.exe: ***
[test.o] Error 0x1
/*
 test.h
*
class Object
{
	typedef void (Object::*Callback0)(void);
	public:
	Object(void);
	virtual ~Object(){};
	void funcc0(void);
};
/*
test.cpp
*/
Object::Object()
{
	Callback0 callme = &(Object::funcc0);
	((this)->*callme)();
}
void Object::funcc0(void)
{
}
<Work around>
Without the -g option it has passed compilation.
Does anyone use this C++ Syntax ?
Do you have any short and nice way around for general callbacks ?
Thanks!
.
Alon Ecker.
Software Engineer.
Radcom Ltd.
12, Hanechoshet st.
Tel-Aviv 69710
Israel
Tel:    +972-3-6455183        Fax:    +972-3-6474681
E-Mail: alon@radcom.co.il
Home Page: www.radcom-inc.com
From POSTMASTER@CompuServe.COM  Wed Nov 20 07:17:44 1996
From: Electronic Postmaster <POSTMASTER@CompuServe.COM>
Date: Wed Nov 20 07:18:02 PST 1996
Subject: Undeliverable message
Your message could not be delivered for the following reason:
Mailbox 75120.1767 is currently full.
Please resend your message at a later time.
--- Returned message ---
Sender: root@csg.lbl.gov
Received: from csg.lbl.gov (csg.lbl.gov [128.3.252.184]) by arl-img-1.compuserve.com (8.6.10/5.950515)
	id KAA19606; Wed, 20 Nov 1996 10:09:03 -0500
Received: by csg.lbl.gov (4.1/0.0)
	id AA06848; Wed, 20 Nov 96 06:45:37 PST
Date: Wed, 20 Nov 96 06:45:37 PST
Message-Id: <9611201445.AA06848@csg.lbl.gov>
Errors-To: vxwexplo-errs@lbl.gov
To: vxworks_users@csg.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Compilation problem in C++
Submitted-by alon@radcom.co.il  Wed Nov 20 06:45:32 1996
Submitted-by: "Alon Ecker" <alon@radcom.co.il>
SYNOPSIS OF PROBLEM         : Compilation problem
AFFECTED MODULE             : <Unknown>
PRODUCT NAME                : Tornado 1.0
DATE                        : Nov 20, '96 - 15:30
REPORTED BY                 : Alon Ecker
    CONTACT                 : Alon Ecker
    COMPANY                 : RADcom
    LICENSE NUMBER          : 3616
    EMAIL                   : alon@radcom.co.il
    ADDRESS                 : 12 Hanechoshet st. 69710, Tel-Aviv Israel.
                            : NA
    PHONE                   : 972-3-6455183
    CUSTOMER REFERENCE#     : <Unknown>
SYSTEM CONFIGURATION        :
    HOST                    : Win NT 3.5
    ARCH                    : I960CA
    BSP                     : EP960CX
    OTHER PERIPHERALS       : <Other Hardware Devices>
DESCRIPTION OF PROBLEM  :
<Demontration>
I have tried to compile  files test.h test.cpp. The comilation problem
appears when I use the '-g' option for the compiler. It shouts that
it can't assemble the temporary assembler file. This is  the
problematic syntaxl:
	((this)->*callme)();
I get the following message:
cc960 -mca -mstrict-align  -O -fvolatile -fno-builtin  -Wall -I/h
-I. -Id:\Tornado\targe t\config\all -Id:\Tornado\target/h
-Id:\Tornado\target/src/config -Id:\Tornado\target/src/ drv -ansi
-nostdinc -DCPU=I960CA -DVX_IGNORE_GNU_LIBS  -g   -c
i:\inter.rtc\test.cpp C:\TMP\cca00131.s:
 Assembler messages:
C:\TMP\cca00131.s:9:
 Error: Rest of line ignored. First ignored
character is `:'. C:\TMP\cca00131.s:13: Error: Rest of line ignored.
First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of
line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38:
Error: Rest of line ignored. First ignored character is `:'. cc960:
Internal compiler error: program as got fatal signal 1 make.exe: ***
[test.o] Error 0x1
/*
 test.h
*
class Object
{
	typedef void (Object::*Callback0)(void);
	public:
	Object(void);
	virtual ~Object(){};
	void funcc0(void);
};
/*
test.cpp
*/
Object::Object()
{
	Callback0 callme = &(Object::funcc0);
	((this)->*callme)();
}
void Object::funcc0(void)
{
}
<Work around>
Without the -g option it has passed compilation.
Does anyone use this C++ Syntax ?
Do you have any short and nice way around for general callbacks ?
Thanks!
From anthonyl@atlantis.softeng.lamrc.com  Wed Nov 20 08:56:53 1996
From: Anthony Le <anthonyl@atlantis.softeng.lamrc.com>
Date: Wed Nov 20 08:56:55 PST 1996
Subject: Re: Cold Boot / Warm Boot
Begin forwarded message:
Date: Tue, 19 Nov 96 09:12:44 PST
To: vxworks_users@csg.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Re: Cold Boot / Warm Boot
Submitted-by espin@idiom.com  Tue Nov 19 09:12:36 1996
Submitted-by: Geoffrey Espin <espin@idiom.com>
> Submitted-by: Salil Parikh <parikh@ll.mit.edu>
> Is there a way in VxWorks to distinguish between a warm boot and
a cold boot?
> I'm using the Motorola MVME147 SBC.
To distinguish between cold boot and warm boot, you need a thermometer.
If you boot at 5 degrees or below that is cold boot.
If you boot at 80 degrees or above that is warm boot.
VxWorks ignores hot boot because it can not handle that temparature.
Make sure you record the temparature of your SBC.
Hope this answer helps!!!!
.
From del@rst.com  Wed Nov 20 09:20:33 1996
From: del@rst.com (Mark Del Giorno)
Date: Wed Nov 20 09:20:35 PST 1996
Subject: SLIP as backup network: problem
Heyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy,
If anyone has used SLIP in a "fault-tolerant" mode, perhaps you can
help me.
I am controlling a robotic vehicle using a wireless ethernet link
as follows:
   (A)           (B)       Wireless    Wireless   (C)
     _____________________ Ethernet    Ethernet ___
    |             |                                |
 ___|____      ___|____                         ___|____
|Control |    |"Router"|  Wireless SLIP I/F    |        |
|Station |    |      . |- - - - - - - - - - - -| Robot  |
|________|    |________|(D)                 (E)|________|
The letters A..E represent unique internet addresses.  (A, B, and C
have a different network prefix than D & E).
The SLIP link is to be used as a backup in case we go out of range
of the wireless ethernet (which happens often).
I'd like to keep both links up at the same time - not
switch between them.
Right now I do a routeAdd(E, B) on the Control Station.  This allows
the Control Station to open a stream with the Robot, and the data
is (correctly) routed through the Router to the Robot via the RS232
link.  Unfortunately the return path that the Robot uses for that same
stream is to attempt to use the Wireless Ethernet, rather than go back
across the SLIP link.
In other words: a write() at the Control station to the file descriptor
associated with the Robot's E address takes the following path:
              A-B-D-E-C-A
where the -C-A is the TCP layer's acknowledgement that the packet
was correctly received.
How can I convince the Robot's TCP task to respond to SLIP requests
back along the SLIP, regardless of the source of the message?
All processors are MVME162's, with vxWorks 5.2.
Thanks in advance for any advice.
Mark
    _/_/_/_/  _/_/_/_/ _/_/_/_/_/      Mark Del Giorno   (del@rst.com)
   _/    _/  _/           _/           Robotic Systems Technology
  _/_/_/_/  _/_/_/_/     _/            1110 Business Parkway South
 _/   _/         _/     _/             Westminster, MD 21157
_/    _/  _/_/_/_/     _/              (410) 876-9200  Fax: 876-9470
                                       http://www.rst.com
From POSTMASTER@CompuServe.COM  Wed Nov 20 09:44:33 1996
From: Electronic Postmaster <POSTMASTER@CompuServe.COM>
Date: Wed Nov 20 09:44:35 PST 1996
Subject: Undeliverable message
Your message could not be delivered for the following reason:
Mailbox 75120.1767 is currently full.
Please resend your message at a later time.
--- Returned message ---
Sender: root@csg.lbl.gov
Received: from csg.lbl.gov (csg.lbl.gov [128.3.252.184]) by arl-img-1.compuserve.com (8.6.10/5.950515)
	id MAA06855; Wed, 20 Nov 1996 12:21:12 -0500
Received: by csg.lbl.gov (4.1/0.0)
	id AA08168; Wed, 20 Nov 96 08:56:56 PST
Date: Wed, 20 Nov 96 08:56:56 PST
Message-Id: <9611201656.AA08168@csg.lbl.gov>
Errors-To: vxwexplo-errs@lbl.gov
To: vxworks_users@csg.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Re: Cold Boot / Warm Boot
Submitted-by anthonyl@atlantis.softeng.lamrc.com  Wed Nov 20 08:56:53 1996
Submitted-by: Anthony Le <anthonyl@atlantis.softeng.lamrc.com>
Begin forwarded message:
Date: Tue, 19 Nov 96 09:12:44 PST
To: vxworks_users@csg.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Re: Cold Boot / Warm Boot
Submitted-by espin@idiom.com  Tue Nov 19 09:12:36 1996
Submitted-by: Geoffrey Espin <espin@idiom.com>
> Submitted-by: Salil Parikh <parikh@ll.mit.edu>
> Is there a way in VxWorks to distinguish between a warm boot and
a cold boot?
> I'm using the Motorola MVME147 SBC.
To distinguish between cold boot and warm boot, you need a thermometer.
If you boot at 5 degrees or below that is cold boot.
If you boot at 80 degrees or above that is warm boot.
VxWorks ignores hot boot because it can not handle that temparature.
Make sure you record the temparature of your SBC.
Hope this answer helps!!!!
From mam@pluto.dspt.com  Wed Nov 20 11:42:01 1996
From: "Mark Menge" <mam@pluto.dspt.com>
Date: Wed Nov 20 11:42:07 PST 1996
Subject: vxWorks and RPC
Does anyone know if it is possible to use Visual C's RPC and vxWorks?
We are using Netmanage's RPC SDK which requires special
installation.
I would appreciate mail on anyone's experiences.
Mark A. Menge
DSP Technology Inc.
795 Higland Dr.
Ann Arbor Mi, 48108
Phone: (313) 973-1111
Fax: (313)  973-1103
Email: mmenge@dspt.com
From mam@pluto.dspt.com  Wed Nov 20 11:43:55 1996
From: "Mark Menge" <mam@pluto.dspt.com>
Date: Wed Nov 20 11:43:57 PST 1996
Subject: SCSI Drive Diagnostics
I looking for code that aides in disk diagnostics for scsi drives on
vxWorks.
 Anybody know where I can get some?
Mark A. Menge
DSP Technology Inc.
795 Higland Dr.
Ann Arbor Mi, 48108
Phone: (313) 973-1111
Fax: (313)  973-1103
Email: mmenge@dspt.com
From darryl@isys.com  Wed Nov 20 12:46:27 1996
From: darryl@isys.com (Darryl Troxel)
Date: Wed Nov 20 12:46:29 PST 1996
Subject: Enet locked on bus error?
We are running two MVME-167's (25MHz 68040) under VxWorks 5.1.1 in a
21-slot VME cage with mostly proprietary boards.  On rare occasions,
when one of our tasks attempts to sendmsg on a socket using data from
another VME card, we get a bus error on a perfectly good (responds if
retried) location.  That's bad enough, but when this happens *none* of
the tasks on that CPU can do anything on the ethernet.  The CPU won't
even answer ICMP_PINGs.  If I resume the bus-erroring task the network
starts working again.
We're working on the bus error problem itself with our HW people, but the
network side effects keep the application from recovering very well.
Q1. Is there some semaphore or something that is being held by the
    bus-error-ing task, until it is resumed and comes back out of the
    socket-send (buffer pool, net-chip command area, ...)?
Q2. Anyone have a sample buserr handler that can simply retry the
    access?  (If the fault address is in the range we expect,
    just rerunning the failed fetch will probably succeed.)
Here are some sample stacktraces:
-> tt "gWriter00"
 418b8 _vxTaskEntry   +10 : _grayWriter (2b62f94, eac621, e60c52, 0, 0, 0, eac72e, 0, 0, 2b677b0)
e6038a _grayWriter    +2a2: _processGray (2b62f94, e9adbe)
e60966 _processGray   +6a : _writeGray (2b62f94, e9adbe)
e62ed6 _writeGray     +37c: _multiWriteDW (29, 12, 2b26010, 1d, 8edcc, 0)
dcbb66 _multiWriteDW  +98 : _callDataWriter (29, e9acb0, e9ac88, e9aca0)
dcb836 _callDataWriter+1e : _sendmsg (29, e9ac88, 0)
 2a38c _sendmsg       +da : _sosend (e98d10, 0, e9ac18, 0, 0)
 53404 _sosend        +308: _uiomove (f80834, 400, 1, e9ac18)
 540ec _uiomove       +56 : _bcopy (b9c46700, f80b7c, b8)
-> tt gWriter00
 418b8 _vxTaskEntry   +10 : _grayWriter (2b62fa8, eac5ed, e60c66, 0, 0, 0, eac6fa, 0, 0, 2b677c4)
e6039e _grayWriter    +2a2: _processGray (2b62fa8, e9ad8a)
e6097a _processGray   +6a : _writeGray (2b62fa8, e9ad8a)
e62eea _writeGray     +37c: _multiWriteDW (2c, 12, 2b22db4, 37, d2300, 0)
dcbb7a _multiWriteDW  +98 : _callDataWriter (2c, e9ac7c, e9ac54, e9ac6c)
dcb84a _callDataWriter+1e : _sendmsg (2c, e9ac54, 0)
 2a38c _sendmsg       +da : _sosend (ea4424, 0, e9abe4, 0, 0)
 53404 _sosend        +308: _uiomove (210f44, 400, 1, e9abe4)
 540ec _uiomove       +56 : _bcopy (b8429800, 211088, 100)
Thanks in advance for any help,
Darryl
__________________________________________________________________
Darryl Troxel                                Isys Controls, Inc.
darryl@isys.com                              2060 Challenger Drive
Tel: 510.865.9882, x138                      Alameda, CA 94501 USA
Fax: 510.865.9927
__________________________________________________________________
From tkb@mclean.sparta.com  Wed Nov 20 15:11:21 1996
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Wed Nov 20 15:11:27 PST 1996
Subject: Re: Enet locked on bus error?
>We are running two MVME-167's (25MHz 68040) under VxWorks 5.1.1 in a
>21-slot VME cage with mostly proprietary boards.  On rare occasions,
>when one of our tasks attempts to sendmsg on a socket using data from
>another VME card, we get a bus error on a perfectly good (responds if
>retried) location.  That's bad enough, but when this happens *none* of
>the tasks on that CPU can do anything on the ethernet.  The CPU won't
>even answer ICMP_PINGs.  If I resume the bus-erroring task the network
>starts working again.
It sounds like you're VME setup works under most conditions but has a
failure mode under high traffic conditions.  Check what bus release modes
you are using on the 167 cards and any other bus masters that you have.  A
bus master in RWD mode (release when done) will not release the bus unless
it is done using it.  Sometimes 'done' means a single transfer, a block
cycle, when a register is accessed ( RORA - release on register access) or
after some minimum number of bus transfers ( sometimes called fair RWD). A
bus master in ROR (release on request) will release the bus whenever another
master requests it. A bus master in fair mode will attempt to give equal
access to all bus masters on the same arbitration level.
If there are a lot of bus masters besides the 167s, take a look at using
round robin arbitration rather than the normal priority based scheme.  If
you have any block transfers happening, consider making the block size small
enough that no bus error timers can go off or sycnhronize the block
transfers with the SM network access.  Good luck...
HTH
-----------------------------------------
     /\\     Keith Buchanan
    ///\\
   /////\\   SPARTA, Inc.
  /////  \\  7926 Jones Branch Drive
 / \\\\\  \\ Suite 900
 \  \\\\\ // McLean, VA 22102
  \  //////
   \//////   Voice: 703 448 0210
    \////    FAX:   703 893 5494
     \//     WWW:   www.mclean.sparta.com
From 100656.1507@CompuServe.COM  Thu Nov 21 02:04:29 1996
From: John Shaw <100656.1507@CompuServe.COM>
Date: Thu Nov 21 02:04:47 PST 1996
Subject: Re: gettimeofday
Re:
>>when download to MVME166, MC68040CPU, it hints:
>>- -> ld < try.o
>>undefined symbol: _gettimeofday
>>ld error: error reading file (errno = 0x1c0001).
>>value = 0 = 0x0
Hello,
The function gettimeofday() is not supported in VxWorks 5.1 at all. However
you might try the POSIX clockLib functions below:-
	#include <timers.h>
	int clock_gettime (CLOCK_REALTIME, struct timespec * pt);
	int clock_settime (CLOCK_REALTIME, struct timespec * pf);
You will have to generate a new VxWorks image for your MVME-166 with the
INCLUDE_POSIX_TIMERS or INCLUDE_POSIX_ALL definition added to
to vw/config/mv166/config.h or to the included options section of the file
vw/config/all/configAll.h (thus applied to all VxWorks images).
I have not tried these functions. I have instead written routines to program the
MK48T08 BBRAM, TOD clock directly. This is the real-time clock that stores
BCD seconds, minutes, hours, and Julian date information. Have a look at
the Motorola hardware manual on details of this chip.
Please email me so that I know you have received this mail. I may also be
able to email you the source for the routines to set and get time for the TOD
clock.
John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK.
100656.1507@compuserve.com
From del@rst.com  Thu Nov 21 06:59:38 1996
From: del@rst.com (Mark Del Giorno)
Date: Thu Nov 21 06:59:56 PST 1996
Subject: SLIP as backup network: problem
(apologies for the repost: my exploder email was truncated, and this
message wasn't in it......not sure if it posted to everyone else or not.)
Heyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy,
If anyone has used SLIP in a "fault-tolerant" mode, perhaps you can
help me.
I am controlling a robotic vehicle using a wireless ethernet link
as follows:
   (A)           (B)       Wireless    Wireless   (C)
     _____________________ Ethernet    Ethernet ___
    |             |                                |
 ___|____      ___|____                         ___|____
|Control |    |"Router"|  Wireless SLIP I/F    |        |
|Station |    |      . |- - - - - - - - - - - -| Robot  |
|________|    |________|(D)                 (E)|________|
The letters A..E represent unique internet addresses.  (A, B, and C
have a different network prefix than D & E).
The SLIP link is to be used as a backup in case we go out of range
of the wireless ethernet (which happens often).
I'd like to keep both links up at the same time - not
switch between them.
Right now I do a routeAdd(E, B) on the Control Station.  This allows
the Control Station to open a stream with the Robot, and the data
is (correctly) routed through the Router to the Robot via the RS232
link.  Unfortunately the return path that the Robot uses for that same
stream is to attempt to use the Wireless Ethernet, rather than go back
across the SLIP link.
In other words: a write() at the Control station to the file descriptor
associated with the Robot's E address takes the following path:
              A-B-D-E-C-A
where the -C-A is the TCP layer's acknowledgement that the packet
was correctly received.
How can I convince the Robot's TCP task to respond to SLIP requests
back along the SLIP, regardless of the source of the message?
All processors are MVME162's, with vxWorks 5.2.
Thanks in advance for any advice.
Mark
    _/_/_/_/  _/_/_/_/ _/_/_/_/_/      Mark Del Giorno   (del@rst.com)
   _/    _/  _/           _/           Robotic Systems Technology
  _/_/_/_/  _/_/_/_/     _/            1110 Business Parkway South
 _/   _/         _/     _/             Westminster, MD 21157
_/    _/  _/_/_/_/     _/              (410) 876-9200  Fax: 876-9470
                                       http://www.rst.com
From Susan_J_Henry@ccmail.orl.mmc.com  Thu Nov 21 07:59:22 1996
From: Susan_J_Henry@ccmail.orl.mmc.com
Date: Thu Nov 21 07:59:24 PST 1996
Subject: Ada Tasking/Rendezvous vs. VxWorks Tasking
Hello,
We are developing a real-time embedded application in Ada (and C as well).  Our
target is the PowerPC (MVME 1603) and are using Green Hill's Multi Cross
Compiler and VxWorks 5.3.  We are in the detailed design phase of the project
and looking to use the VxWorks tasking model (tasks, message queues, and
semaphores) versus using the Ada language Task Structure and the Rendezvous.  We
have been told (by WRS) that VxWorks tasking is more efficient and less overhead
then Ada's.  Has anyone out there performed a trade study or have hard
throughput numbers to back this up?  Our customer is familiar with Ada tasking
and not VxWorks and wants justification why we think VxWorks tasks are the way
to go.  I'm posing the question and hoping to receive an answer, otherwise we
are going to have to do this study.
Thanks in advance,
Sue Henry
Lockheed Martin
susan_j_henry@ccmail.orl.lmco.com
From intrepid!minidds@uunet.uu.net  Thu Nov 21 08:58:07 1996
From: intrepid!minidds@uunet.uu.net (Lee Kappel)
Date: Thu Nov 21 08:58:09 PST 1996
Subject: Re: tnetTask, Serial I/O, and Ring Buffers
I am using the built-in serial TTY driver supplied by WRS
with 5.3 for the Motorola MVME1604 board PC87303 Super
I/O chip which supports COM1 and COM2 only.
I have heard from another team on my project that they
are having trouble directly accessing COM1 and COM2 since
VxWorks seems to have hooks into these two ports no matter
what they do.
> From tadlock@bosch.dseg.ti.com Thu Nov 21 08:13:11 1996
> Date: Wed, 20 Nov 1996 17:05:05 -0600
> From: tadlock@bosch.dseg.ti.com (edward tadlock)
> To: intrepid!minidds@uunet.uu.net (Lee Kappel), vwwexplo@lbl.gov
> Subject: tnetTask, Serial I/O, and Ring Buffers
> Reply-To: ed-tadlock@ti.com
> Content-Length: 1046
>
> we have also had problems writing to the serial ports (COM1) via the
> memory mapped addresses. It works for a while and then hangs, but I
> have not gotten deep enough to know why. Perhaps we need to be using
> some drivers for the ports, but as far as I can see there are not any
> built-in drivers for the serial ports of an Ultra603e PowerPC board
> from Motorola so we are just writing to know memory addresses. Did you
> find serial I/O drivers in 5.3, or did you build them yourself? Note
> that we are NOT going out to a TTY, but a device. Routines exist to
> drive TTYs via the COM ports,so I guess they have some code somewhere
> to talk at the device level to shove the bits out the ports on the
> Super I/O chip, but its not accessable to the user. Any input on
> your solutions might help me find one.
>
>                                 Ed Tadlock
>                                 TI Systems Group
>                                 Adv. Airborne Systems
>                                 Open Systems Technology Group
>                                 Plano, TX
>
From stan@rti.com  Thu Nov 21 10:16:12 1996
From: Stan Schneider <stan@rti.com>
Date: Thu Nov 21 10:16:13 PST 1996
Subject: Re: SLIP as backup network: problem
>> From root@csg.lbl.gov Thu Nov 21 07:58 PST 1996
>> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
>> Subject: SLIP as backup network: problem
>> Submitted-by del@rst.com  Thu Nov 21 06:59:38 1996
>> Submitted-by: del@rst.com (Mark Del Giorno)
>>
>>    (A)           (B)       Wireless    Wireless   (C)
>>      _____________________ Ethernet    Ethernet ___
>>     |             |                                |
>>  ___|____      ___|____                         ___|____
>> |Control |    |"Router"|  Wireless SLIP I/F    |        |
>> |Station |    |      . |- - - - - - - - - - - -| Robot  |
>> |________|    |________|(D)                 (E)|________|
>>
>>
>> How can I convince the Robot's TCP task to respond to SLIP requests
>> back along the SLIP, regardless of the source of the message?
>>
You should be able to run routeAdd("0", D) on the Robot, setting D up as the
default gateway.  You can also specify the routes you want individually, e.g.
by running routeAdd(A,D) and routeAdd(B,D) on the Robot.
HTH,
        -- Stan
           stan@rti.com
From dgilleland@sntc.com  Thu Nov 21 10:22:17 1996
From: dgilleland@sntc.com (Dan Gilleland)
Date: Thu Nov 21 10:22:19 PST 1996
Subject: PPP between VxWorks and Windows NT
I'm trying to set up a PPP connection across a serial line
with a null modem between my workstation running Windows
NT 4.0 and a 5.3 VxWorks I960 target.
Has anyone done this and can tell me what PPP parameters
were used on the VxWorks side and what was done on the
Windows side to establish the link?
Thanks for any help,
 -dan
 ---
Dan Gilleland
SNT, Inc
Email : dan@sntc.com
Phone: (612) 404-0070  Ext 211
FAX    : (612) 404-0075
From MikeMcQuade@connect.com  Thu Nov 21 17:06:50 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Nov 21 17:07:07 PST 1996
Subject: Q: printing from Crosswind ?
Does anyone know if its possible to print fromm crooswind ?
or print mixed assembly / C listings from GDB ?
Id like to dump some mixed mode listings.
thanks.
MikeMcQuade@connect.com
From daemon@csg.lbl.gov  Fri Nov 22 04:00:56 1996
From: daemon@csg.lbl.gov
Date: Fri Nov 22 04:03:38 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Nov 22 04:00:32 PST 1996
        Subject: Re: GNU Compiler 2.6
        Subject: Re: RTOS abstraction layer
        Subject: Re: Anyone using ZBufs?
        Subject: Date/Time from Bios on x86 platform-Software interrupts
        Subject: Re: PPP between VxWorks and Windows NT
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: GNU Compiler 2.6
Date: 21 Nov 1996 16:16:48 GMT
From: varlese@tech.ascom.ch (Chris Varlese)
Organization: Ascom Hasler AG, Berne, Switzerland
Message-ID: <571v9g$edk@ascomax.hasler.ascom.ch>
References: <9611191636.AA01377@venus.prc.allied.com>
In article <9611191636.AA01377@venus.prc.allied.com>,
	sridhar@prc.allied.com (Sridhar Adumusilli) writes:
>Does any one know if 2.6 version can be used to compile
>templates?
Yes, with a few restrictions.
The v2.6 compiler cannot automatically detect when identical template
specialisations have been compiled from different source files.  This
gives "foo<blah> multiply defined" errors when linking.
To work around this try the following.  Compile with the
- -fno-implicit-templates parameter.  Then make one additional source
file, compiled without this parameter, which declares one instance
of each template specialisation you use.
regards,
Chris Varlese
---------------------------
Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: 21 Nov 1996 03:48:19 GMT
From: steved@pacifier.com@199.2.117.163  (Steve Doiel)
Organization: Pacifier BBS, Vancouver, Wa.  ((360) 693-0325)
Message-ID: <570je3$95u@news.pacifier.com>
References: <329355D5.237C228A@aud.alcatel.com>
Reply-To: steved@pacifier.com  (Steve Doiel)
Shash Chatterjee writes:
>Is there a vendor-independent abstraction layer for typical RTOS
>functions like messaging, tasking, events/semaphores, timer-services,
>etc?
>
Funny you should ask.  I went to a presentation this morning put on by
Rogue Wave software, and they described one of their class libraries Threads.h++,
which I believe at least partially fits your description.
I don't know about availability for various target OS's.
Their web site is: www.roguewave.com
Personally, I think Ada95 is a much better solution since tasking is a part
of the language.
Hope this helps,
Steve Doiel
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Anyone using ZBufs?
Date: Wed, 20 Nov 1996 09:10:00 GMT
From: pete@imc4.eej.ulst.ac.uk (Pete Brett)
Message-ID: <848481056.2587.0@hathsys.demon.co.uk>
References: <5543lo$jg7@clark.zippo.com>
jay@fallcreek.com (Jay Slupesky) wrote:
>Hello,
>Has anyone tried using ZBufs to improve the performance of
>socket-based programs?  I have a simple routine that reads data from
>one socket and writes it to another.  When I use ZBufs, the program
>actually runs much SLOWER than when  I use read() and write().
>Using ZBufs should make the program faster, not slower, since it
>eliminates two data copies.
>Anyone have any thougnts?
>Jay Slupesky    Fall Creek Systems, Inc.
>Pleasanton, California, USA
>jay@fallcreek.com  http://users.aol.com/jslupesky
>"Professional Internet user on closed circuit.  Do not attempt."
	I tried the same thing with the same result. I came to the conclusion
that the stack cannot release the application layer buffer until an
acknowledgement is received for all packets sent from it.
	Since TCP generally improves its efficiency greatly by sending several
packets before receiving any acknowledgements and thus using a greater
percentage of the available bandwidth, it is probably necessary for
the application layer to make several buffers available, each with its
own callback function parameter.
	In my own case, I solved the problem by switching to UDP with
acknowledgements supplied by the application layer.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Date/Time from Bios on x86 platform-Software interrupts
Date: Thu, 21 Nov 1996 14:05:16 -0800
From: eric olsen <eolsen@leland.stanford.edu>
Organization: stanford university
Message-ID: <3294D21C.6355D5EB@leland.stanford.edu>
Hello, we are trying to get date/time from the bios.
Anyone know how to do that?
Anyone know how to generate software interrupts??
Any help appreciated.
thanks,
- --------------------------------------------------------------
"How can I lose to such an idiot?"
                            Aaron Nimzovich(1886-1935)
 eric olsen
 eolsen@leland.stanford.edu
- --------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: PPP between VxWorks and Windows NT
Date: Fri, 22 Nov 1996 09:43:29 GMT
From: jasonv@delphi-assoc.com (Jason Velody)
Organization: delphi-assoc.com
Message-ID: <329572b3.3123125@news1.theplanet.co.uk>
References: <1996Nov21.122100.1487.27186@eagle.sntc.com>
dgilleland@sntc.com (Dan Gilleland) wrote:
>
>
>I'm trying to set up a PPP connection across a serial line
>with a null modem between my workstation running Windows
>NT 4.0 and a 5.3 VxWorks I960 target.
>
>Has anyone done this and can tell me what PPP parameters
>were used on the VxWorks side and what was done on the
>Windows side to establish the link?
>
Hi Dan,
We have experienced problems attempting to establish a PPP connection
between a VxWorks system equipped with our embedded ISDN T/A and an NT
server running RAS(PPP).
We have found a bug in WindRiver's PPP implementation. During LCP
negotiation, NT sends a ConfigReq asking for CHAP 80 authorisation.
VxWorks doesn't understand CHAP 80 and sends a ConfigRej packet in
response. This is a clear violation of the protocol as it indicates
that VxWorks doesn't understand any kind of authorisation. NT quite
reasonably terminates the session. Instead of sending a ConfigRej,
VxWorks should reply with a ConfigNak suggesting an alternate
authorisation protocol (UPAP or CHAP); NT will accept this reponse and
the session should continue through the authorisation phase.
We are working with WindRiver to try and sort this out. Their version
of PPP is based on the BSD public domain implementation, later
versions of which contain a fix for this problem. If we come up with a
fix in the short term I'll let you know.
Jason Velody
- ------------------------------------------------------------------------------
    You are lost in a maze of twisty little standards
        - all conflicting...
Jason Velody                                           jasonv@delphi-assoc.com
Senior Network Consultant
                                                   http://www.delphi-assoc.com
Delphi Associates Ltd                                       (+44) 171 357 0303
- ------------------------------------------------------------------------------
---------------------------
End of New-News digest
**********************
From kboley@frodo.eng.vmic.com  Fri Nov 22 07:50:19 1996
From: Kirk Boley <Kirk.Boley@vmic.com>
Date: Fri Nov 22 07:53:19 PST 1996
Subject: GNU C++ 2.7.2
I need to get the 2.7.2 version of the GNU C++
compiler to fix some problems I'm having with
templates.
Does anyone know where the sun4 host/68k target
compiler can be found?
================================================================================
Kirk Boley
VME Microsystems International Corporation
12090 S. Memorial Pkwy.
Huntsville, AL 35803-3308
(205)650-8254                                   EMAIL: Kirk.Boley@vmic.com
From froeber@bbn.com  Fri Nov 22 16:38:39 1996
From: Fred Roeber <froeber@bbn.com>
Date: Fri Nov 22 16:38:57 PST 1996
Subject: Re: Q: printing from Crosswind ?
On Thu, 21 Nov 1996, Mike McQuade wrote:
> Does anyone know if its possible to print fromm crooswind ?
>
> or print mixed assembly / C listings from GDB ?
The following worked for me:
Subject: Re: C-Compiler for VxWorks..
Date: 15 Jun 1995 21:38:16 GMT
From: crash@phydeaux.cygnus.com (Jason Molenda)
Organization: Cygnus Support
   It turned out what this person really wanted to do was get an
   assembly-and-C listing; you can do this with
	% gcc -Wa,-ashld -c -g -o foo.o foo.c
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From froeber@bbn.com  Fri Nov 22 16:59:46 1996
From: Fred Roeber <froeber@bbn.com>
Date: Fri Nov 22 16:59:48 PST 1996
Subject: Re: comp.os.vxworks newsdigest
Shash Chatterjee writes:
> >Is there a vendor-independent abstraction layer for typical RTOS
> >functions like messaging, tasking, events/semaphores, timer-services,
> >etc?
Steve Doiel replied:
> Funny you should ask.  I went to a presentation this morning put on by
> Rogue Wave software, and they described one of their class libraries Threads.h++,
> which I believe at least partially fits your description.
>
> I don't know about availability for various target OS's.
>
> Personally, I think Ada95 is a much better solution since tasking is a part
> of the language.
Actually, a couple of years ago the RTOS vendors got together to try to
come up with a standard API.  The spec that they proposed was referred to as
ORKID.  The work was under the auspices of the VME standardization committee
if I remember right.  It seems that after the spec was put together, the
work faded into oblivion.  Seems there wasn't enough impetus for the vendors
to standardize between products.  Of course having software tied to an RTOS
specific API is a powerful marketing edge.  Of course this situation isn't
unique to the embedded system market; the efforts to come up with an ANSI
standard Windows API definition haven't seemed too successful either.  I
think for the moment, that if you are concerned about portability across
different RTOS's you should follow the "recommended" practice of encapsulating
all RTOS functionality in generic iterface subroutines.  Most of the RTOS out
there have largely similar core capabilities.
Steve also mentions that he likes Ada 95 tasking.  I am just wondering if
anybody really has used it much.  Whenever I worked on Ada applications
using VADSWorks under the Ada 83 language definition I always used the
underlying VxWorks tasking constructs.  The problem was that the synchronous
nature of Ada rendezvous didn't seem to fit real time program constraints
very well and resulted in far more tasks than were really required.  I
haven't looked real close but I didn't think that the Ada tasking interface
to VxWorks had changed much under Ada 95.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |  50 Enterprise Place   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From daemon@csg.lbl.gov  Sat Nov 23 04:00:27 1996
From: daemon@csg.lbl.gov
Date: Sat Nov 23 04:00:29 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Nov 23 04:00:24 PST 1996
        Subject: Re: VxWorks and Hitachi SH-2 ???
        Subject: Re: Cold Boot / Warm Boot
        Subject: Re: RTOS abstraction layer
        Subject: Re: Recursive Makefiles under NT
        Subject: Re: RTOS abstraction layer
        Subject: netperf on vxworks available
        Subject: Transparent Translation Registors???
        Subject: Transparent Translation Registers??? more
        Subject: Self Test on an x86 Platform?
        Subject: Re: Recursive Makefiles under NT
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks and Hitachi SH-2 ???
Date: Thu, 21 Nov 1996 12:27:36 +1030
From: Matt Brennan <mattb@vsl.com.au>
Organization: Vision Systems Limited, Adelaide, Australia
Message-ID: <3293B710.550B@vsl.com.au>
References: <32831992.4D5E@ratol.fi>
Jouni Kivirinta wrote:
>
> Hi
>
> Have anyone used VxWorks with Hitachi's SH-2 or SH-1 series
> controllers? I'm in particular interested in models SH7042 (SH-2) and
> SH7034 (SH-1).
We asked the same question of the VxWorks distributor in Australia. The
answer we received was that VxWorks 5.1.1 and WindView on Unix hosts
(standard GNU compiler) were available for the SH1 and SH2.
There is a port of Tornado to the SH3 currently in progress apparently.
Expected completion in first quarter 97 whereupon the port of Tornado to
SH1 and SH2 will be conducted.
> We are going to use PC+winNT host environment.
Looks like you might be sunk.
I'd appreciate any information/confirmation you might receive directly
from WindRiver or other users. Any one out there actually used VxWorks
with the SH2 (SH7043 particularly) ?
 Matt
- --
Matt Brennan || Vision Systems Ltd || +61 8 8300 4686
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Cold Boot / Warm Boot
Date: Fri, 22 Nov 1996 07:27:04 -0500
From: Richard Price <richard.price@lsoc114x.ksc.nasa.gov>
Organization: United Space Alliance
Message-ID: <32959C18.41E1@lsoc114x.ksc.nasa.gov>
References: <9611201654.AA07646@softeng.lamrc.com>
Anthony Le wrote:
>
> Begin forwarded message:
>
> Date: Tue, 19 Nov 96 09:12:44 PST
> To: vxworks_users@csg.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: Re: Cold Boot / Warm Boot
>
> Submitted-by espin@idiom.com  Tue Nov 19 09:12:36 1996
> Submitted-by: Geoffrey Espin <espin@idiom.com>
>
> > Submitted-by: Salil Parikh <parikh@ll.mit.edu>
> > Is there a way in VxWorks to distinguish between a warm boot and
> a cold boot?
> > I'm using the Motorola MVME147 SBC.
>
> To distinguish between cold boot and warm boot, you need a thermometer.
>
> If you boot at 5 degrees or below that is cold boot.
> If you boot at 80 degrees or above that is warm boot.
> VxWorks ignores hot boot because it can not handle that temparature.
>
> Make sure you record the temparature of your SBC.
>
> Hope this answer helps!!!!
>
> .I was once told they don't let jack asses in to college because nobody likes a smart ass.
But a Cal Berkley anthing is possible
---------------------------
Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: 22 Nov 1996 10:39:20 +0100
From: rob@sysgo.de (Robert Kaiser)
Organization: Sysgo Real-Time Solutions GmbH
Message-ID: <573sc8$2d5@phoenix.sysbe.sysgo.de>
References: <329355D5.237C228A@aud.alcatel.com>
Followup-To: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Shash Chatterjee (Shash.Chatterjee@aud.alcatel.com) wrote:
: Is there a vendor-independent abstraction layer for typical RTOS
: functions like messaging, tasking, events/semaphores, timer-services,
: etc?
:
There is such a thing as a POSIX standard specifying real-time
functionality of an OS (sorry, I'm awfully bad at keeping numbers
in mind, must be POSIX 1003.. something like that).
: We use pSOS now. I have extensively used VxWorks in a prior job.  We are
: now moving toward an OO design (C++ implementation) and it seems to me
: that kernel-independence would be a major portability as well as
: maintainability benefit.
I'm afraid pSOS doesn't support POSIX functions (I'm not sure about
VxWorks), but there are several other RTOSes available that claim
POSIX compliance (QNX, LynxOS, OS-9).
:  Also, it would provide a means of some
: (probably limited) forms of emulation on UNIX hosts using light-weight
: process threads.
I happen to know LynxOS pretty well, so I can tell you for that one
that there is no need to emulate anything because LynxOS has both
hard real-time capabilities *and* full-featured UNIX functions
at the same time.
Thus, you can use it as development/debugging platform and as a
target system.
Best Regards
Robert
- ----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Mommsenstr. 19                         phone: (49) 30 3270153-0
D-10629 Berlin / Germany               fax:   (49) 30 3247839
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Recursive Makefiles under NT
Date: Fri, 22 Nov 1996 12:53:39 GMT
From: jasonv@delphi-assoc.com (Jason Velody)
Organization: delphi-assoc.com
Message-ID: <3296761b.3995765@news1.theplanet.co.uk>
References: <3291d000.20436640@news1.theplanet.co.uk> <56sl36$3ki@idiom.com>
hjb@peacefulstar.oakland.ca.us (H.J. Bae) wrote:
>In article <3291d000.20436640@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote:
>>Hi there,
>>
>>Has anyone managed to get recursive makefiles to work properly under
>>Tornado for Windows? I am suffering from a singular lack of success.
>>
>
>Works fine for me.
>
>http://peacefulstar.oakland.ca.us
>mailto:hjb@peacefulstar.oakland.ca.us
Hello there!
Perhaps I should be a little more specific. The problem seems to occur
with exported MAKE variables - they don't seem to be getting exported
to the sub-make. Any handy hints?
Jason
- ------------------------------------------------------------------------------
    You are lost in a maze of twisty little standards
        - all conflicting...
Jason Velody                                           jasonv@delphi-assoc.com
Senior Network Consultant
                                                   http://www.delphi-assoc.com
Delphi Associates Ltd                                       (+44) 171 357 0303
- ------------------------------------------------------------------------------
---------------------------
Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: 20 Nov 1996 20:51:16 -0500
From: danh@qnx.com (Dan Hildebrand)
Organization: QNX Software Systems
Message-ID: <570cik$ga1@qnx.com>
References: <329355D5.237C228A@aud.alcatel.com>
In article <329355D5.237C228A@aud.alcatel.com>,
Shash Chatterjee  <Shash.Chatterjee@aud.alcatel.com> wrote:
>Is there a vendor-independent abstraction layer for typical RTOS
>functions like messaging, tasking, events/semaphores, timer-services,
>etc?
Why does it have to be an abstrtaction layer?  Why not POSIX?  Between the
base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
for threads, and 1003.1d for a few more realtime extensions, everything
you've named is very nicely covered.
>We use pSOS now. I have extensively used VxWorks in a prior job.  We are
>now moving toward an OO design (C++ implementation) and it seems to me
>that kernel-independence would be a major portability as well as
>maintainability benefit.  Also, it would provide a means of some
>(probably limited) forms of emulation on UNIX hosts using light-weight
>process threads.
Most UNIX hosts natively support some degree of POSIX, with some of them
being quite complete.  The result is that your source might simply compile
on the desktop platform for development, and recompile for the target
runtime environment.
>Before I get slammed, I understand that there will be a realtime impact.
There's no reason for there to be a realtime impact - there are a number of
realtime OS's with a POSIX API today.
>I'd like to know (besides the fact if there are such class-libraries
>available) what the impacts to debugging such a system would be?
It need be no more difficult than debugging POSIX code on a desktop
platform.
- --
Dan Hildebrand (danh@qnx.com)               QNX Software Systems, Ltd.
http://www.qnx.com/~danh                    175 Terence Matthews
phone: (613) 591-0931 (voice)               Kanata, Ontario, Canada
       (613) 591-3579 (fax)                 K2M 1W8
---------------------------
Newsgroups: comp.os.vxworks
Subject: netperf on vxworks available
Date: 22 Nov 1996 17:41:55 GMT
From: wiltzius@coral.llnl.gov (David P Wiltzius,LC,21551,)
Organization: Lawrence Livermore Nat'l Lab
Message-ID: <574ol3$g8k@lll-winken.llnl.gov>
Netperf is a network performance measurement tool
available at http://www.cup.hp.com/netperf/NetperfPage.html.
I modified netperf version 2.1 so that the server
and client run on VxWorks.  Well, for my VxWorks
target (Cyclone Microsystems i960 SB08 board)
anyway.
It is at
ftp://www.llnl.gov/siof/netperf/
It is not a robust port, but I've run the TCP
and UDP stream tests and the TCP and UDP
request/response tests.
You can first view the README and 2 of my logs
running nerserver and netperf on the VxWorks
target to help you decide if you want
to venture further.  The compressed tar
file includes everything.
I make no guarantees and assume no responsibility.
I'm not sure if I'll have time to respond to
requests for help wrt to this "port" but I will try.
  Dave Wiltzius
  LLNL
  wiltzius@llnl.gov
---------------------------
Newsgroups: comp.os.vxworks
Subject: Transparent Translation Registors???
Date: Thu, 21 Nov 1996 16:48:22 -0800
From: ggensler@impulse.net (Gary Gensler)
Organization: Creative Computer Resources
Message-ID: <ggensler-2111961648220001@sbdsk1148.sbrc.hac.com>
Does anybody out there know the ins and outs of TTR's.
I have a few Q's about the ramifications of using them.
I would appreciate a call.
Gary Gensler
Santa Barbara Remote Sensing
805-562-7468
If no answer please leave a message I will call you back.
Thanks
Gary
---------------------------
Newsgroups: comp.os.vxworks
Subject: Transparent Translation Registers??? more
Date: Thu, 21 Nov 1996 16:52:38 -0800
From: ggensler@impulse.net (Gary Gensler)
Organization: Creative Computer Resources
Message-ID: <ggensler-2111961652380001@sbdsk1148.sbrc.hac.com>
FORGOT -> I'm using a Motorola mvme167 (68040) CPU.
Does anybody out there know the ins and outs of TTR's.
I have a few Q's about the ramifications of using them.
I would appreciate a call.
Gary Gensler
Santa Barbara Remote Sensing
805-562-7468
If no answer please leave a message I will call you back.
Thanks
Gary
---------------------------
Newsgroups: comp.os.vxworks
Subject: Self Test on an x86 Platform?
Date: Fri, 22 Nov 1996 20:25:05 -0500
From: Jack Birecree <birecree@rpa.net>
Organization: Rochester Public Access, Inc.
Message-ID: <32965271.35D9@rpa.net>
Does anyone know how to get the results of the BIOS self test after
boot-up? Is there anyway to read the results?
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Recursive Makefiles under NT
Date: Sun, 17 Nov 96 22:05:29 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <5761l1$j1s@idiom.com>
References: <3291d000.20436640@news1.theplanet.co.uk> <56sl36$3ki@idiom.com> <3296761b.3995765@news1.theplanet.co.uk>
In article <3296761b.3995765@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote:
>Perhaps I should be a little more specific. The problem seems to occur
>with exported MAKE variables - they don't seem to be getting exported
>to the sub-make. Any handy hints?
I've noticed this problem too.  I work-around this by passing
a command line variable args to sub-make calls.  For example,
within a Makefile, if I want to call a sub-make and want to
pass along variables I call it this way:  make -C subdir XXX="xxxyyyzzz".
The Makefile in subdir can then use XXX as defined by this command line.
It's ugly, but it works.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
End of New-News digest
**********************
From leonid@rst.co.il  Sun Nov 24 00:22:14 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sun Nov 24 00:22:16 PST 1996
Subject: Re: SLIP as backup network: problem
We have struggled with similar problems in the past,
and there are two ways to solve this problem:
1. Port routed RIP routing table manager to VxWorks (I beleive there
is such a port on the archives).
2. Write the application more specifically to this task.
1. - RIP
What RIP does is manage the routing table automatically, adding and deleting
routing entries as they become (un)availbale. This is done be means
of exchanging routing table info between peer RIP daemons.
This poll is usually done once every two minutaes. THis could cause
an unpleasant delay in reconfiguring the routing table, during
Ethernet down time. The RIP is still applicable however
in much more complex situation.
2. Modify application:
The easies way to write your application specifically for this
scenario, is duplicate your connection to the robot, i.e. open
two distinct TCP connections, one to IP address (C), and the other
to address (E). The second connection will come in via SLIP,
and TCP will try to respond via the same path. This is sure to work
if the SLIP was connected DIRECTLY to your Control Station.
It may not work with the router, not sure if TCP uses source route.
This way you got two distinct TCP connections, one over Ethernet another
over SLIP, and you can send iportant requests on both if you feel like it.
Drop me a line if you need more details.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From leonid@rst.co.il  Sun Nov 24 01:14:39 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sun Nov 24 01:14:42 PST 1996
Subject: Re: RTOS abstraction layer
In adtivle <570cik$ga1@qnx.com> <danh@qnx.com> of QNX wrote:
> Why not POSIX?  Between the
> base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
> for threads, and 1003.1d for a few more realtime extensions, everything
> you've named is very nicely covered
Before glorifying POSIX, you should know that VxWorks (since 5.2) has
complete support for the POSIX Real-Time extentions. I went through
all these APIs a couple of times, trying to decicde if a particular
application could use them, and time after time I was dissapointed
by some thing(s) that where simply missing.
For example, a wind mutex semaphore has the Priority Inheritance
option, POSIX semaphore does not.
So if anybody tells you that POSIX covers hard R-T needs "very nicely",
then I suppose he or she understand very little about what hard R-T is.
Besides, when a standards body decides to design a spec for a Horse,
they end up with somethig more resembling a Camel.
Leonid
From daemon@csg.lbl.gov  Sun Nov 24 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Sun Nov 24 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Nov 24 04:00:20 PST 1996
        Subject: SOFTWARE ENGINEERS - Permanent & Contract Positions
        Subject: NFS support
        Subject: Asynchronous sockets
        Subject: SOFTWARE ENGINEERS - Permanent & Consulting Positions
        Subject: Re: Asynchronous sockets
        Subject: Re: Asynchronous sockets
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: SOFTWARE ENGINEERS - Permanent & Contract Positions
Date: Thu, 21 Nov 1996 09:09:07 -0800
From: Ram Balani <iisinc@snet.net>
Organization: Innovative Information Systems
Message-ID: <32948CB3.E0D@snet.net>
Innovative Information Systems, Inc. (IIS, Inc.) is a software
contracting/recruiting company specializing in real time and
pharmaceutical systems consulting/placements.
We have numerous open positions for two of our large client companies:
1) Software Engineers / Project Leaders / Designers/ Managers
Permanent, full time positions ONLY are available with this leading
medical systems manufacturer.
Positions require a minimum BSCS or BSEE and 2 years programming
experience.
Real time or embedded systems experience is a must.
Working experience must include most BUT not ALL:
C
C++
UNIX
X-Windows/Motif
Windows NT
Prior real time programming experience with medical systems is a definite
PLUS.
This fortune 50 company leads in the manufacture of MRIs, XRAYS,
Ultrasound, etc.
Candidates selected will be paid an attractive salary and excellent
benefits. Relocation expenses may be extended subject to company HR
approval.
2) Software Engineers
Real time systems software engineers are also required for contract or
IIS consulting openings in Connecticut.
Candidate must have 2 of the requirement listed below:
2 years C++ programming experience
Real time or embedded systems experience
Unix or Windows NT
GUI
- ------------------------------------------------------------------------------------------------------------------------
Interested candidates may contact Ram Balani after faxing or e-mailing
(ascii text please)CV or resume by:
Phone: 	860-444-7039
E-mail: iisinc@ix.netcom.com
Fax:  	 860-537-4549
---------------------------
Newsgroups: comp.os.vxworks
Subject: NFS support
Date: Sat, 23 Nov 1996 07:54:27 -0500
From: Walt Dixon <dixon@crd.ge.com>
Organization: GE Corporate Research and Development
Message-ID: <3296F403.5412@crd.ge.com>
Reply-To: dixon@crd.ge.com
I am posting this question for a friend.  He is running vxWorks
on an Advantek p5-75 pentium processor, and he has added NFS support.
He can see his vxWorks file system from a Windows NT box running
NetManage NFS, but he is not able to see the same vxWorks file
system from another PC running Windows for Workgroups and
16 bit NetManage NFS.  On this latter system he can mount the vxWorks
based file system, but all the file names appear as toto]]].txt.  The
same 16 bit NetManage can see files on a unix system with no problems.
Does anyone have any suggestions as to what might be going on.
TIA
Walt Dixon
---------------------------
Newsgroups: comp.os.vxworks
Subject: Asynchronous sockets
Date: 23 Nov 1996 16:25:33 GMT
From: "James Lewis" <ljames@okstate.edu>
Organization: Oklahoma State University
Message-ID: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>
I was wondering how to make an ethernet socket asynchronous (non-blocking).
 On the host Sparc station this is done with an ioctl call.  I assume that
VxWorks handles it
the same way.  If so, how is it done?  Any hints would be greatly
appreciated.
Thanks,
James Lewis
ljames@okstate.edu
---------------------------
Newsgroups: comp.os.vxworks
Subject: SOFTWARE ENGINEERS - Permanent & Consulting Positions
Date: Thu, 21 Nov 1996 09:44:29 -0800
From: Ram Balani <iisinc@snet.net>
Organization: Innovative Information Systems
Message-ID: <329494FD.1121@snet.net>
Innovative Information Systems, Inc. (IIS, Inc.) is a software
contracting/recruiting company specializing in real time and
pharmaceutical systems consulting/placements.
We have numerous open positions for two of our large client companies:
1) Software Engineers / Project Leaders / Designers/ Managers
Permanent, full time positions ONLY are available with this leading
medical systems manufacturer.
Positions require a minimum BSCS or BSEE and 2 years programming
experience.
Real time or embedded systems experience is a must.
Working experience must include most BUT not ALL:
C
C++
UNIX
X-Windows/Motif
Windows NT
Prior real time programming experience with medical systems is a definite
PLUS.
This fortune 50 company leads in the manufacture of MRIs, XRAYS,
Ultrasound, etc.
Candidates selected will be paid an attractive salary and excellent
benefits. Relocation expenses may be extended subject to company HR
approval.
2) Software Engineers
Real time systems software engineers are also required for contract or
IIS consulting openings in Connecticut.
Candidate must have 2 of the requirement listed below:
2 years C++ programming experience
Real time or embedded systems experience
Unix or Windows NT
GUI
- ------------------------------------------------------------------------------------------------------------------------
Interested candidates may contact Ram Balani after faxing or e-mailing
(ascii text please) CV or resume by:
Phone: 	860-444-7039
E-mail:  iisinc@ix.netcom.com
Fax:  	 860-537-4549
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Mon, 18 Nov 96 02:36:10 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <577lak$4oh@idiom.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>
In article <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>, "James Lewis" <ljames@okstate.edu> wrote:
>I was wondering how to make an ethernet socket asynchronous (non-blocking).
> On the host Sparc station this is done with an ioctl call.  I assume that
>VxWorks handles it
>the same way.  If so, how is it done?  Any hints would be greatly
>appreciated.
>
VxWorks doesn't really support asynch sockets.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Sun, 24 Nov 1996 06:16:38 GMT
From: brucew@phoenix.net (Bruce)
Organization: BranPaul Systems
Message-ID: <578pdk$d2v$1@gryphon.phoenix.net>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>
In comp.os.vxworks
"James Lewis" <ljames@okstate.edu> wrote:
>I was wondering how to make an ethernet socket
>asynchronous (non-blocking).   On the host Sparc station
>this is done with an ioctl call.  I assume that VxWorks handles
>it the same way.  If so, how is it done?
It is done the same way.  I'm at home so I don't have my
manuals, but look in your socklib documentation or search
your headers for the constant FIONBLK or something similar.
If I remember, it is not in the online manuals.
Bruce
---------------------------
End of New-News digest
**********************
From froeber@bbn.com  Sun Nov 24 17:39:33 1996
From: Fred Roeber <froeber@bbn.com>
Date: Sun Nov 24 17:39:35 PST 1996
Subject: Re: non blocking sockets
James Lewis wrote:
> >I was wondering how to make an ethernet socket asynchronous (non-blocking).
> > On the host Sparc station this is done with an ioctl call.  I assume that
> >VxWorks handles it
> >the same way.  If so, how is it done?  Any hints would be greatly
> >appreciated.
H.J. Bae responded:
> VxWorks doesn't really support asynch sockets.
I am surprised by this.  The sockLib man page talks about the FIONBIO
ioctl option to make a socket non blocking and I have used it before
and thought it worked.  Still, Hae Jin did a lot of the original work
on the VxWorks network code and usually is dead on accurate.  So what
gives?   Fred
--
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From froeber@bbn.com  Sun Nov 24 17:54:30 1996
From: Fred Roeber <froeber@bbn.com>
Date: Sun Nov 24 17:54:32 PST 1996
Subject: Re: RTOS abstraction layer
In article <570cik$ga1@qnx.com> <danh@qnx.com> of QNX wrote:
> > Why not POSIX?  Between the
> > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
> > for threads, and 1003.1d for a few more realtime extensions, everything
> > you've named is very nicely covered
To which Leonid Rosenboim responded:
> Before glorifying POSIX, you should know that VxWorks (since 5.2) has
> complete support for the POSIX Real-Time extentions. I went through
> all these APIs a couple of times, trying to decicde if a particular
> application could use them, and time after time I was dissapointed
> by some thing(s) that where simply missing.
>
> For example, a wind mutex semaphore has the Priority Inheritance
> option, POSIX semaphore does not.
>
> So if anybody tells you that POSIX covers hard R-T needs "very nicely",
> then I suppose he or she understand very little about what hard R-T is.
I agree with Leonid.  First, while Dan is usually at least somewhat
unbiased he does work for QNX which is a competing RTOS vendor.  My
take is that QNX is more UNIX like and therefor more closely matches
the POSIX model of things (but is mainly supported on PC type targets).
While I wasn't directly involved in the POSIX real time work I did have
numerous enlightening discussions with one of my friends from Raytheon
who was quite involved.  My take on things is that POSIX does include
definitions of how to address many things that we care about in the
embedded arena.  However, the notion of POSIX compliance certainly
doesn't guarantee portability.  There are large parts of the POSIX
spec that are optional and few areas where performance must be
specified.  I certainly wouldn't count on the fact that two different
OS vendors claimed POSIX compliance to mean I could port a POSIX
conforming application between them easily.
VxWorks supports some aspects of the POSIX real time interface (they
had some of their staff on the POSIX working groups) but the basic
VxWorks arhictecture is very different from the full blown POSIX
model.  VxWorks has tasks that are somewhat like POSIX threads.  It
doesn't have any notion of the more heavy weight processes that POSIX
has.  I could go on but I think the basic thing I would advise is
to view RTOS vendor claims that portability is ensured because of
POSIX compliance with healthy scepticism.  Then again, I haven't
ever heard WRS people make this portability claim.   Fred
--
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |       froeber@bbn.com     401-849-2543 (X48)       |
From mmigdol@crl.mew.co.jp  Sun Nov 24 18:37:08 1996
From: Michael Migdol <mmigdol@crl.mew.co.jp>
Date: Sun Nov 24 18:37:09 PST 1996
Subject: RT-Win and other VxWorks-Windows hybrids
Hi all,
We are currently evaluating VxWorks/Win95 hybrids.  Does anyone have
experience with RT-Win, LP-VxWin, or any other similar products?  Would love
to hear any comments - good or bad!
Thanks in advance,
Michael Migdol
Matsushita Electric Works
From mea@mclean.sparta.com  Mon Nov 25 07:40:53 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Mon Nov 25 07:41:11 PST 1996
Subject: Re: non blocking sockets
At 05:39 PM 11/24/96 PST, you wrote:
>Submitted-by froeber@bbn.com  Sun Nov 24 17:39:33 1996
>Submitted-by: Fred Roeber <froeber@bbn.com>
>
>James Lewis wrote:
>> >I was wondering how to make an ethernet socket asynchronous
(non-blocking).
>> > On the host Sparc station this is done with an ioctl call.  I assume that
>> >VxWorks handles it
>> >the same way.  If so, how is it done?  Any hints would be greatly
>> >appreciated.
>
>
>H.J. Bae responded:
>
>> VxWorks doesn't really support asynch sockets.
>
>I am surprised by this.  The sockLib man page talks about the FIONBIO
>ioctl option to make a socket non blocking and I have used it before
>and thought it worked.  Still, Hae Jin did a lot of the original work
>on the VxWorks network code and usually is dead on accurate.  So what
>gives?   Fred
>
HwaJin is technically correct.  To support asynchronous sockets, you must
support the SIGIO signal, which VxWorks does not.  This is very different
from non-blocking sockets.  You can, in fact, make a socket non-blocking in
VxWorks by using the FIONBIO ioctl call.  However, for the socket to be
truly "asynchronous", your task would have to get the SIGIO signal anytime
a packet came in that was destined for the port number of the socket you
were monitoring.  This has long been a topic at the user's group meetings
and I know that I personally have asked about SIGIO support for several years,
but to no avail.
However, all is not lost.  You can hook the etherInputHook and look at the
protocol field in the IP header and use that info to look at the destination
port field in the TCP/UDP header to determine whether or not you wish to
send the SIGIO signal to a given task.  This would basically require a table
that contained the port number of interest and the TID of the task to be
signaled.  You would then have to write a setup call to enter that info into
the table.  We've done it here at SPARTA and it works reasonably well.
Unfortunately, your network traffic will suffer a slight performance hit
because of this additional code.
What really needs to happen is for WRS to add the SIGIO capability into the
file system.  If done properly, this facility could then be used for *any*
function that used file descriptors.  This means asynchronous pipes, files,
and sockets.
HTH,
==============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\
   //  \\     Mike Anderson
  // /\ \\    Chief Engineer              Voice : (703) 448-0210 ext. 235
 // /  \ \\   SPARTA, Inc.                FAX   : (703) 893-5494
//   \    \\  7926 Jones Branch Drive     EMAIL : mea@mclean.sparta.com
\\    \   //  Suite 900                   Web   : http://www.mclean.sparta.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
==============================================================================
From navarro@emu.sp.trw.com  Mon Nov 25 13:34:36 1996
From: Efren Navarro <navarro@emu.sp.trw.com>
Date: Mon Nov 25 13:34:55 PST 1996
Subject: unsubscribe
unsubscribe
From royg@semantic.com  Mon Nov 25 14:39:46 1996
From: Roy Gordon <royg@semantic.com>
Date: Mon Nov 25 14:39:55 PST 1996
Subject: signals in 5.3
As a newcomer to the vxWorks world, the recent discussion of SIGIO has
gotten me nervous.
Do signals in 5.3 actually meet the Posix interface?  Are there
any known not to work correctly?
Are there other signals that simply aren't supported?
I notice that SIGIO is defined in sigLib.h
	#define SIGIO           (SIGRTMIN + 0)
Does this mean that although it's listed it's still not supported,
and ditto for the other signals in this file.  Or, can you get it
by means of the real time extensions.
Do the real time extensions work?
We're porting from Solaris to vxWorks (as well as developing vxWorks
specific code), and having some idea of what we can expect would be
most helpful.
					-- roy
> HwaJin is technically correct.  To support asynchronous sockets, you must
> support the SIGIO signal, which VxWorks does not.  This is very different
> from non-blocking sockets.  You can, in fact, make a socket non-blocking in
> VxWorks by using the FIONBIO ioctl call.  However, for the socket to be
> truly "asynchronous", your task would have to get the SIGIO signal anytime
> a packet came in that was destined for the port number of the socket you
> were monitoring.  This has long been a topic at the user's group meetings
> and I know that I personally have asked about SIGIO support for several years,
> but to no avail.
		:
		:
> What really needs to happen is for WRS to add the SIGIO capability into the
> file system.  If done properly, this facility could then be used for *any*
> function that used file descriptors.  This means asynchronous pipes, files,
> and sockets.
From bdupre@world-net.worldnet.net  Tue Nov 26 00:42:14 1996
From: bdupre@world-net.worldnet.net (Bernard DUPRE)
Date: Tue Nov 26 00:42:17 PST 1996
Subject: Re:
Friedrich,
RAMIX provides a RM235 VME/PCMCIA module with a VxWorks driver.
Phone number is 818 349 67 72 (California).
Bernard
 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
< Real Time Skills Center                           >
< 10, Avenue du Quebec - BP 537                     >
< 91946 - Courtaboeuf Cedex - France                >
< Tel: 01 69 82 93 32      Fax: 01 69 82 93 28      >
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From daemon@csg.lbl.gov  Tue Nov 26 04:00:29 1996
From: daemon@csg.lbl.gov
Date: Tue Nov 26 04:02:34 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Nov 26 04:00:27 PST 1996
        Subject: Re: GNU C++ 2.7.2
        Subject: Re: Asynchronous sockets
        Subject: re: SLIP as backup network: problem
        Subject: Re: 53C810 SCSI Controller
        Subject: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
        Subject: Re: Asynchronous sockets
        Subject: Making non-standard serial I/O -driver
        Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
        Subject: Strange iteraction between malloc & posix timers
        Subject: re: non blocking sockets
        Subject: Re: RTOS abstraction layer
        Subject: z8530 synchronous driver
        Subject: Re: RTOS abstraction layer
        Subject: Re: vxWorks and RPC
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: GNU C++ 2.7.2
Date: 24 Nov 1996 16:25:08 GMT
From: bill@qstools.com (Bill Cox)
Organization: Sirius Cybernetics, Sirius City branch
Message-ID: <579st4$lsr@news.scruz.net>
References: <199611221549.JAA13396@frodo.eng.vmic.com>
Kirk Boley (Kirk.Boley@vmic.com) wrote:
: I need to get the 2.7.2 version of the GNU C++
: compiler to fix some problems I'm having with
: templates.
:
: Does anyone know where the sun4 host/68k target
: compiler can be found?
:
Just did this last night (except for the actual build -
I was building for my FreeBSD host machine):
cd MYDIR
ftp gatekeeper.dec.com
cd pub/GNU
binary
get gcc-2.7.2.1.tar.gz
exit
gunzip gcc-2.7.2.1.tar.gz
tar -xvf gcc-2.7.2.1.tar
cd gcc-2.7.2.1
mkdir sun4-x-m68k
cd sun4-x-m68k
# This assumes that you're building on a sun4 host
../configure --target=m68k-wrs-vxworks
make -k all >& make.log
make install
- --
Bill Cox                          Software Janitor
Finger bill@thuvia.qstools.com for PGP public key.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Wed, 20 Nov 96 17:08:52 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57aalu$ocf@idiom.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> <578pdk$d2v$1@gryphon.phoenix.net>
In article <578pdk$d2v$1@gryphon.phoenix.net>, brucew@phoenix.net (Bruce) wrote:
>In comp.os.vxworks
>"James Lewis" <ljames@okstate.edu> wrote:
>
>>I was wondering how to make an ethernet socket
>>asynchronous (non-blocking).   On the host Sparc station
>>this is done with an ioctl call.  I assume that VxWorks handles
>>it the same way.  If so, how is it done?
>
>It is done the same way.  I'm at home so I don't have my
>manuals, but look in your socklib documentation or search
>your headers for the constant FIONBLK or something similar.
>If I remember, it is not in the online manuals.
non blocking sockets are *not* the same as asynch sockets.
VxWorks supports non-blocking sockets, it does not support
asynch sockets.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: re: SLIP as backup network: problem
Date: Wed, 20 Nov 96 17:29:02 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57abro$psp@idiom.com>
References: <9611240754.AA00611@rst.co.il>
In article <9611240754.AA00611@rst.co.il>, leonid@rst.co.il (Leonid Rosenboim)
wrote:
>2. Modify application:
>The easies way to write your application specifically for this
>scenario, is duplicate your connection to the robot, i.e. open
>two distinct TCP connections, one to IP address (C), and the other
>to address (E). The second connection will come in via SLIP,
>and TCP will try to respond via the same path. This is sure to work
>if the SLIP was connected DIRECTLY to your Control Station.
>It may not work with the router, not sure if TCP uses source route.
>This way you got two distinct TCP connections, one over Ethernet another
>over SLIP, and you can send iportant requests on both if you feel like it.
Having two distinct connections (C and E) has nothing to do with
how IP layer routing code will determine which route to take.
This is not how IP works.  The reason it appears to work in a
directly connected point-to-point link in a similar setup is
due to an entirely different reason.
The only way he can do what he wants is using IP source routing (not
TCP source routing, there is no such thing).  This should be done
from the sender's side, using setsockopt.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: 53C810 SCSI Controller
Date: Sun, 24 Nov 1996 21:31:01 -0700
From: Wes Peters <softweyr@xmission.com>
Organization: Softweyr LLC
Message-ID: <32992105.167EB0E7@xmission.com>
References: <01BBD607.78FECBE0@pc0055>
Friedrich Ensslin wrote:
 > Does anyone have any info on VxWorks SCSI drivers for the NCR 53C810
 > SCSI Controller.
If not, FreeBSD has drivers for this NCR part.  It shouldn't be terribly
difficult to hack the UNIX sources to work under VxWorks.  See
	http://WWW.FreeBSD.ORG/
for more details.
- --
          "Where am I, and what am I doing in this handbasket?"
Wes Peters
Softweyr LLC
http://www.xmission.com/~softweyr
softweyr@xmission.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
Date: Mon, 25 Nov 1996 10:30:27 -0500
From: Tim Meagher <tmeagher@tsi-telsys.com>
Organization: TSI TelSys Inc.
Message-ID: <3299BB93.59E2B600@tsi-telsys.com>
Can anyone elaborate on why Wind River is providing Epilogue's SNMP
Agent instead of SNMP Research's agent?
Please provide a comparison of features for embedded systems (size,
multi-threading, ease of use, dynamic extensibility of the agent,
support for SNMP v2, availability of source code and binaries, and
portability) and a comparison of costs (purchase price, maintenance, and
royalties).
Are there any other SNMP agent tools that should be seriously considered
as an alternative?
In addition, what kind of web support for testing and managing these
agents is provided (JAVA-based and http-based management)?
I also understand that ISI (the makers of PSOS+) purchased Epilogue.
Can anyone elaborate what affect this will have on Wind River's ability
or plans to offer the Epilogue SNMP agent with VxWorks?
Thank you.
- --
Tim Meagher			TSI Telsys Inc.
Senior Software Engineer	7100 Columbia Gateway Dr.
tmeagher@tsi-telsys.com		Columbia, MD 21046
410-872-3928 (voice)		http://www.tsi-telsys.com
410-872-3901 (FAX)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Asynchronous sockets
Date: Mon, 25 Nov 1996 09:20:49 -0800
From: Chet Kackman <kackman@GDEsystems.com>
Organization: GDE Systems Inc.
Message-ID: <3299D571.41C67EA6@GDEsystems.com>
References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>
James Lewis wrote:
>
> I was wondering how to make an ethernet socket asynchronous (non-blocking).
>  On the host Sparc station this is done with an ioctl call.  I assume that
> VxWorks handles it
> the same way.  If so, how is it done?  Any hints would be greatly
> appreciated.
>
> Thanks,
> James Lewis
> ljames@okstate.edu
James
   You should use the function call ioctl() with the FIONBIO I/O
control function. This should allow you to perform asynch I/O on a
socket connection. However I would recommend that you read pages 265
through 267 in the VxWorks 5.2 programmers guide, and supplement it
with Stevens' TCP/IP Unix Network Programming book pages 322-323. This
should provide enough information to construct the call you need.
                  Good Luck
                   kackman@gdesystem.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Making non-standard serial I/O -driver
Date: Mon, 25 Nov 1996 21:03:33 -0800
From: E van der Laak <evdlaak@topic.nl>
Organization: Eindhoven University of Technology, The Netherlands
Message-ID: <329A7A25.2ACA@topic.nl>
Reply-To: evdlaak@topic.nl
With respect to the installation and configuration of a VxWorks
development environment, I have the following question:
Currently we are configuring a VxWorks target for use in an embedded
system. We are planning to use a non-standard serial I/O-card of
manufacturer Comtrol, being the Hostess 550. Does anyone of you have
experience in writing your own driver for such a card?
Any suggestions with respect to implementing the standard I/O functions,
device list, driver table, etc OR using customary read and write
operations provided by a self-made driver using for instance two message
queues for I/O from/to the card?
Any suggestions are appreciated.
Eric van der Laak
Topic Automatisering B.V.
Oirschot
Holland
evdlaak@topic.nl
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
Date: Mon, 25 Nov 1996 11:58:36 -0800
From: jbs@quiotix.com (Jeffrey B. Siegal)
Organization: Quiotix Corporation
Message-ID: <jbs-2511961158360001@dial-sf2-27.iway.aimnet.com>
References: <3299BB93.59E2B600@tsi-telsys.com>
In article <3299BB93.59E2B600@tsi-telsys.com>, Tim Meagher
<tmeagher@tsi-telsys.com> wrote:
> In addition, what kind of web support for testing and managing these
> agents is provided (JAVA-based and http-based management)?
Our Embedded WebServer supports an HTTP-based interface to SNMP which does
not require that the user have a SNMP console (just a web browser).  It
works with any agent.  See http://www.quiotix.com for a demonstration.
- --
Jeffrey B. Siegal
Quiotix Corporation
+1 415 782-6012
http://www.quiotix.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Strange iteraction between malloc & posix timers
Date: Mon, 25 Nov 1996 18:32:43 -0800
From: Grant Haidinyak <grant@iwv.com>
Organization: InterNex Information Services 1-800-595-3333
Message-ID: <329A56CB.7B7A@iwv.com>
Hello,
We were wondering if anyone else has seen the following problem.
1) Posix timers are being used, (with a rate of about once every .2
	seconds).
2) malloc() is being call alot (ok, ok, a lot and a house ;)
3) When a task is in the middle of a malloc(), a timer pops.
4) The execution of the timer signal happens on the texcTask, which
   takes over the personality of the tasks that set the timer, ie the
task id.
5) The signal handling code does another malloc().
6) Since malloc() appears to use mutex semaphores, the semGet operation
succeeds because the task had already gotten the malloc semaphore.
7) The malloc() data structures are now effectively hosed.
So, has anyone else seen this behavior?
grant
ps
We actually saw this behavior using an ICE, so this isn't speculation...
---------------------------
Newsgroups: comp.os.vxworks
Subject: re: non blocking sockets
Date: Tue, 26 Nov 96 06:36:48 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57e32v$buh@idiom.com>
References: <3298F82D.167EB0E7@bbn.com>
In article <3298F82D.167EB0E7@bbn.com>, Fred Roeber <froeber@bbn.com> wrote:
>H.J. Bae responded:
>
>> VxWorks doesn't really support asynch sockets.
>
>I am surprised by this.  The sockLib man page talks about the FIONBIO
>ioctl option to make a socket non blocking and I have used it before
>and thought it worked.  Still, Hae Jin did a lot of the original work
>on the VxWorks network code and usually is dead on accurate.  So what
>gives?   Fred
>
Again, non-blocking sockets != asynch sockets.
The non-blocking one is supported in VxWorks, asynch one is *not*!
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: Sat, 23 Nov 1996 19:59:11 -0600
From: "Steven J. Lee" <sjlee@newmonics.com>
Organization: NewMonics Inc.
Message-ID: <3297ABEF.52FE@newmonics.com>
References: <329355D5.237C228A@aud.alcatel.com>
Reply-To: sjlee@newmonics.com
Shash Chatterjee wrote:
>
> Is there a vendor-independent abstraction layer for typical RTOS
> functions like messaging, tasking, events/semaphores, timer-services,
> etc?
>
Have you had a look at PERC, a clean-room implementation of Java
specifically for real-time, embedded systems?
- --
Steve Lee, Software Engineer                      voice: (515) 296-0897
NewMonics Inc.                                      fax: (515) 294-9910
2501 N. Loop Dr., Suite 614-A             internet: sjlee@newmonics.com
Ames, IA  50010                                http://www.newmonics.com
     Supporting PERC(TM):  Portable Executive for Reliable Control
---------------------------
Newsgroups: comp.os.vxworks
Subject: z8530 synchronous driver
Date: Mon, 25 Nov 1996 13:49:32 +0000
From: Doug Owens <owens2@llnl.gov>
Organization: Lawrence Livermore National Lab
Message-ID: <3299A3D0.51F6@llnl.gov>
Reply-To: owens2@llnl.gov
Is there a synchronous driver for the Z8530 chip for vxWorks 5.3?
Thanks,
Doug Owens
owens2@llnl.gov
---------------------------
Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: Tue, 26 Nov 96 07:01:24 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57e4h3$buh@idiom.com>
References: <9611240839.AA00667@rst.co.il> <57dd3r$qpc@qnx.com>
In article <57dd3r$qpc@qnx.com>, mphunter@18.com (Michael Hunter) wrote:
>Leonid Rosenboim (leonid@rst.co.il) wrote:
>: In adtivle <570cik$ga1@qnx.com> <danh@qnx.com> of QNX wrote:
>: > Why not POSIX?  Between the
>: > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
>: > for threads, and 1003.1d for a few more realtime extensions, everything
>: > you've named is very nicely covered
>
>: Before glorifying POSIX, you should know that VxWorks (since 5.2) has
>: complete support for the POSIX Real-Time extentions. I went through
>: all these APIs a couple of times, trying to decicde if a particular
>: application could use them, and time after time I was dissapointed
>: by some thing(s) that where simply missing.
>
>: For example, a wind mutex semaphore has the Priority Inheritance
>: option, POSIX semaphore does not.
>
>Well, I'm not exactly sure what a "windy mutex semaphore" is, but
>I'll describe how POSIX semaphores and mutexes work.
My earlier follow-up to Leonid Rosenboim's article didn't make it
to the net, for some reason...  anyway, here's a rewrite of what I
wrote, just to add more confusion to the issue.
VxWorks supports a type of semaphore that can be used for priority
inversion avoidance.  You can specify an option to the semaphore to
indicate that you want the priority to be inherited while the semaphore
is being held -- a typical solution to priority inversion problem in
a threaded OS.
Unfortunately, VxWorks allows this options only on mutex semaphores,
but not on counting semaphores and binary semaphores.  This is only
one of many inconsistencies in VxWorks API.
As Michael correctly points out above, POSIX threads do have a
priority inheritance option.  The way POSIX defines it is different
though (better), because the option is settable as an attribute
of a given thread.  Thread specific attributes are "hints" to the
kernels that provide threading.  The kernel "implementation" can
choose to implement priority inheritence on mutex or conditions (similar
to VxWorks semaphores).  The API defined in POSIX is generalized
and consistent.
I'm not into blindly following "standards", but blaming POSIX for
something that it does correctly and praising VxWorks for breaking
consistency in API seems a little unfair.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: vxWorks and RPC
Date: Sun, 24 Nov 1996 07:00:09 GMT
From: noblenet@world.std.com (NobleNet Inc.)
Organization: NobleNet, Inc.
Message-ID: <E1D4s9.826@world.std.com>
References: <m0vQIWv-003EzgC@ic.net>
In article <m0vQIWv-003EzgC@ic.net>, Mark Menge <mam@pluto.dspt.com> wrote:
>Does anyone know if it is possible to use Visual C's RPC and vxWorks?
>
>We are using Netmanage's RPC SDK which requires special
>installation.
Please contact NobleNet for ONC/RPC tools and solutions for UNIX,
Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc.
        NobleNet, Inc.
        337 Turnpike Road
        Southboro, MA  01772
        Voice +1 508 460 8222
        Fax +1 508 460 3456
        <sales@noblenet.com>
        <http://www.noblenet.com/>
PRESS RELEASE
For Immediate Release
For Further Information, Please Contact:
David Burns
Vice President of Marketing
NobleNet, Inc.
Voice: (508) 460-8222
FAX: (508) 460-3456
e-mail: david.burns@noblenet.com
"The Client/Server Toolkit for C and C++ Programmers"
New Book From NobleNet Turns Programmers Into Client/Server Experts
New York, October 8, 1996 --  NobleNet, Inc. today announced the availability
of its newly published book that turns C and C++ programmers into
client/server experts.   Co-authored by middleware experts Steven Lemmo and
Rich Grehan, The Client/Server Toolkit for C and C++ Programmers  is a self-
contained instructional tool that teaches programmers how to distribute any
application or Application Programming Interface (API) across a network.
The CD-ROM software included with The Client/Server Toolkit features a unique
Windows-based client/server simulator that lets programmers gain hands-on
experience in client/server partitioning.  Programmers are guided through four
"real-world" client/server projects: distributed ODBC database, scanner
device, image engine, and datafeed.  The authors expertise combined with a
Rapid Application Development (RAD) environment, demystifies the art of
distributing complex applications.
"I learned more about client/server development in the last three days of
reading your book than I learned in the past few years of doing C and C++
programming," said Pascal Specht, Technical Sales Engineer at Precision
Software in Paris, France.
"Our new book will help any C or C++ programmer that wants to learn about
state-of-the-art client/server computing," said Steve Lemmo, co-author and
Chief Technology Officer of NobleNet.  "The techniques taught in the book will
help programmers learn to use the powerful Interface Definition Languages
(IDLs) found in today's most popular distributed computing middleware."
Beginning with a monolithic application, readers learn how to separate
programs into independent parts that communicate with each other.  While other
books on client/server computing include sample code, The Client/Server
Toolkit goes further and delivers a true client/server Software Development
Toolkit (SDK) designed for application partitioning.  Unlike other approaches,
programmers learn to build client/server applications using industry-standard
RPC technology that requires no source code changes.
"The Client/Server Toolkit is ideal for programmers that want to get a quick
immersion into client/server computing with tools that require very little
effort to learn,"  said Vincent Russo, Assistant Professor of Computer Science
at Purdue University.  "I like the fact that the book is totally self-
contained.  It has a wealth of real-world examples that provide the reader
with a thorough understanding of client/server development.  And the simulator
gives programmers hands-on experience with building and running real
client/server applications."
Although The Client/Server Toolkit is written for C and C++ programmers,
examples are given that show "drag and drop" programmers how to create
client/server applications utilizing popular GUI front-ends such as Visual
Basic, PowerBuilder, Delphi, and Developer 2000.  Distributed with the book is
a free version of NobleNet's powerful standards-based RPC product used by
client/server developers world-wide.  Programmers are presented with client
and server Windows connected by a simulated network.  Using NobleNet RPC,
applications developed on the simulator are easily deployed to over 40
platforms including 26 UNIXes, Windows 3.1, 95, and NT, NetWare, Macintosh,
OS/2, and VMS.  More than 20 Windows-based TCP/IP stacks are supported to
ensure operation in existing multi-vendor environments.
Co-author Steven Lemmo founded NobleNet, engineered NobleNet's first software
product, EZ-RPC(R), and led the team that developed the company's NetWare and
Windows-based middleware tools.  With an in-depth understanding of both
communication and application software, he is a sought after consultant on RPC
programming.  Steve has over fifteen years of experience in software
engineering and tools development in companies such as Computervision Corp.,
Sun Microsystems, Inc., and Xerox Imaging Systems, Inc.  He is widely
recognized as an expert on distributed computing and is frequently called upon
to appear at industry forums.
Co-author Rick Grehan has been on the editorial staff of BYTE Magazine for
over 11 years.  He is currently the Technical Director of BYTE Labs and the
author of BYTE's monthly CodeTalk column.  His articles have appeared in BYTE,
Embedded Systems Programming, and Forth Dimensions.  In addition, he was a
contributor to the 1993 edition of The Encyclopedia of Microcomputers,
published by Marcel Dekker, Inc.  Rick is also the designer of BYTE Magazine's
BYTEmark benchmark suite.
The Client/Server Toolkit for C and C++ Programmers is published by NobleNet.
The 350 page book with CD-ROM can be ordered for $49.95 by calling (800)-250-
6427 or (508)-893-0398.
NobleNet offers tools for distributed client/server development for procedural
and object paradigms. Incorporated in 1991, NobleNet is a world leader in
Remote Procedure Call (RPC) technology and has won numerous awards for its RPC
product family.   NobleNet also distributes IONA Technologies' industry-
leading "Orbix" CORBA-compliant Object Request Broker. The company is
headquartered in Southboro, MA, and can be reached at (508) 460-8222 or at
<http://www.noblenet.com/>.
---------------------------
End of New-News digest
**********************
From Lennart.Bie@emw.ericsson.se  Tue Nov 26 06:12:12 1996
From: Lennart.Bie@emw.ericsson.se (FY/DX Lennart Bie)
Date: Tue Nov 26 06:12:15 PST 1996
Subject: Synchronous Drivers for VxWorks
Can anyone give a hint where I can find a synchronous driver for the
serial ports 3 & 4 on the Moto MVME1604 PPC board for VxWorks.
	-- OR --
Does anyone know where I can get hold of *ANY* synchronous Driver for
prefearbly the Z85230 chip or at least the Z8530 chip. If I am lucky
it will also use dma's when reading and writing.
Thanks in advance.
Lennart Bie, Ericsson Microwave Systems AB, Molndal, Sweden
From gverdun@fibertek.com  Tue Nov 26 06:52:17 1996
From: "Gustavo H. Verdun" <gverdun@fibertek.com>
Date: Tue Nov 26 06:52:18 PST 1996
Subject: [Q] Does anyone have a PPC exception to signal mapping?
I'm trying to create a signal handler for a PPC603e to trap VME bus errors.
VMEbus errors produce a machine check exception.
What signal should I intercept to capture this exception?
Thanks,
Gustavo H. Verdun
Senior Systems Engineer
FIBERTEK, INC.           \|/
--------------------------*--
510 Herndon Parkway      /|\
Herndon, Virginia  20170-5225
Voice:   (703) 471-7671
Fax:     (703) 471-5806
http://www.fibertek.com
From tja@radstone.co.uk  Tue Nov 26 09:02:18 1996
From: Tim Allen <tja@radstone.co.uk>
Date: Tue Nov 26 09:02:25 PST 1996
Subject: Re: [Q] Does anyone have a PPC exception to signal mapping?
>I'm trying to create a signal handler for a PPC603e to trap VME bus errors.
>
>VMEbus errors produce a machine check exception.
>
>What signal should I intercept to capture this exception?
VxWorks on the Radstone PPC 60x range of processors reports VMEbus errors in
different ways. During coupled cycles the Universe (VME I/F device) will
indicate master bus errors with a PCI target abort, this is detected by the
MPC105 (EAGLE) processor/PCI bridge and a machine check exception raised.
During decoupled cycles, eg posted writes, a master bus error is logged
using the V_AMERR register and a VERR interrupt generated.  All these events
are reported by VxWorks by default.
Additionally, it is possible to route the machine check to IRQ14, via
jumpers/links on the board.
So you can either use excVecSet() to install a function over the existing
machine check handler (using excVecGet() first allows you to preserve the
original function and call it in your own handler if required) or you can
route machine checks to IRQ14 and install a handler using intConnect (14,...).
If you need any further information, feel free to contact me directly.
+------------------------------------------------------------------+
|  Tim Allen                            phone: +44 (0)1327 359444  |
|  Radstone Technology PLC, UK.         fax:   +44 (0)1327 358112  |
+------------------------------------------------------------------+
From bawilson@llnl.gov  Tue Nov 26 15:34:27 1996
From: "Bruce A. Wilson" <bawilson@llnl.gov>
Date: Tue Nov 26 15:34:29 PST 1996
Subject: SDLC driver for MV-1603
Does anyone know of an SDLC device driver written for the Motorola
MVME-1603 (PowerPC) target?
Bruce Wilson
LLNL  (L-054)
7000 East Ave
Livermore, CA  94550
bawilson@llnl.gov
--
From amolkho@madge.com  Wed Nov 27 02:16:55 1996
From: "Adi Molkho LAN-Tel" <amolkho@madge.com>
Date: Wed Nov 27 02:16:57 PST 1996
Subject: Packed
Hello
I am working with I960CA processor with VxWorks 5.3 (Gnu toolkit 2.6)
when i declare  the ip_eth structure (see the attached file) i see that
it size (using sizeof)
is 64 bytes also the sum of its fields sizes is only 52 bytes and i used
the packed
attribute all the way.
Does anybody know why
Thanks
                Adi
-------------------------------------------------------------
  Uuencoded File Attachment: PACK.C
-------------------------------------------------------------
begin 660 PACK.C
M='EP961E9B!S=')U8W0@25!?151(('L*("!U;G-I9VYE9"!C:&%R("!M86-?
M9&5S=%LV72!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D["B`@=6YS:6=N960@
M8VAA<B`@;6%C7W-R8ULV72!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D["B`@
M=6YS:6=N960@<VAO<G0@='EP95\X,#`@7U]A='1R:6)U=&5?7R`H*'!A8VME
M9"DI.PH@('5N<VEG;F5D(&-H87(@(&-O;G-T7S`T(%]?871T<FEB=71E7U\@
M*"AP86-K960I*3L*("!U;G-I9VYE9"!C:&%R("!T;W`@7U]A='1R:6)U=&5?
M7R`H*'!A8VME9"DI.PH@('5N<VEG;F5D('-H;W)T(&QE;F=T:"!?7V%T=')I
M8G5T95]?("@H<&%C:V5D*2D["B`@=6YS:6=N960@<VAO<G0@:61E;G0@7U]A
M='1R:6)U=&5?7R`H*'!A8VME9"DI.PH@('5N<VEG;F5D('-H;W)T(')E<V5R
M=F5D,B!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D["B`@=6YS:6=N960@8VAA
M<B`@='1L(%]?871T<FEB=71E7U\@*"AP86-K960I*3L*("!U;G-I9VYE9"!C
M:&%R("!P<F]T;V-O;"!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D["B`@=6YS
M:6=N960@<VAO<G0@8VAE8VMS=6T@7U]A='1R:6)U=&5?7R`H*'!A8VME9"DI
M.PH@('5N<VEG;F5D(&-H87(@(&EP7W-R8ULT72!?7V%T=')I8G5T95]?("@H
M<&%C:V5D*2D["B`@=6YS:6=N960@8VAA<B`@:7!?9&5S=%LT72!?7V%T=')I
M8G5T95]?("@H<&%C:V5D*2D["B`@=6YS:6=N960@<VAO<G0@=61P7W-P;W)T
M(%]?871T<FEB=71E7U\@*"AP86-K960I*3L*("!U;G-I9VYE9"!S:&]R="!U
M9'!?9'!O<G0@7U]A='1R:6)U=&5?7R`H*'!A8VME9"DI.PH@('5N<VEG;F5D
M('-H;W)T(')E<V5R=F5D,ULW72!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D[
M"GT@25!?151((%]?871T<FEB=71E7U\@*"AP86-K960I*3L*"@T*#0I)4%]%
M5$@@("`@:7!?971H(%]?871T<FEB=71E7U\@*"AP86-K960I*3L*#0IT:&4@
@8V]M<&QI97(@<VAO=W,@<VEZ96]F*&EP7V5T:"D]-C0*
`
end
From daemon@csg.lbl.gov  Wed Nov 27 04:00:20 1996
From: daemon@csg.lbl.gov
Date: Wed Nov 27 04:00:23 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Nov 27 04:00:17 PST 1996
        Subject: Re: RTOS abstraction layer
        Subject: Re: RTOS abstraction layer
        Subject: Re: RTOS abstraction layer
        Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
        Subject: Is this a new group
        Subject: Hot-swap support in VxWorks?
        Subject: Re: non blocking sockets
        Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
        Subject: Task Deletion
        Subject: How To Turn Off Optimization
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: 25 Nov 1996 23:29:35 GMT
From: findley@bosch.dseg.ti.com (Doug Findley)
Message-ID: <FINDLEY.96Nov25172935@bosch.dseg.ti.com>
References: <9611240839.AA00667@rst.co.il>
Reply-To: wdfindley@ti.com
>>>>> "LR" == Leonid Rosenboim <leonid@rst.co.il> writes:
In article <9611240839.AA00667@rst.co.il> leonid@rst.co.il (Leonid Rosenboim) writes:
    LR> In adtivle <570cik$ga1@qnx.com> <danh@qnx.com> of QNX wrote:
    >> Why not POSIX?  Between the base POSIX
    >> standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
    >> for threads, and 1003.1d for a few more realtime extensions, everything
    >> you've named is very nicely covered
    LR> Before glorifying POSIX, you should know that VxWorks (since 5.2) has
    LR> complete support for the POSIX Real-Time extentions. I went through
    LR> all these APIs a couple of times, trying to decicde if a particular
    LR> application could use them, and time after time I was dissapointed
    LR> by some thing(s) that where simply missing.
    LR> For example, a wind mutex semaphore has the Priority Inheritance
    LR> option, POSIX semaphore does not.
    LR> So if anybody tells you that POSIX covers hard R-T needs "very nicely",
    LR> then I suppose he or she understand very little about what hard R-T is.
You're right, POSIX semaphores do not support these protocols.
However, POSIX does support Priority Inheritance (PI) and the Priority
Ceiling Protocol (PCP) via the POSIX mutexes defined in 1003.1c.
Typically, PI is used when a resource has an owner.  A semaphore
doesn't have an "owner" (an OS can determine the owner
of a binary semaphore).  As a result, the POSIX mutex is a cleaner
mechanism to use for PI and PCP.
    LR> Besides, when a standards body decides to design a spec for a Horse,
    LR> they end up with somethig more resembling a Camel.
IMHO, they end up with something more like a Shetland pony.  That's
because they can only standardize on things that people agree on.
    LR> Leonid
- --
Doug
*************************************************************************
W. Douglas Findley  "There are 2 kinds of people, those who do the work &
wdfindley@ti.com     those who take the credit. Try to be in the 1st group;
(972) 575-5448       there is less competition there." Indira Ghandi
*************************************************************************
---------------------------
Newsgroups: comp.os.realtime,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: 26 Nov 1996 00:20:11 GMT
From: mphunter@18.com (Michael Hunter)
Organization: QNX Software Systems Ltd.
Message-ID: <57dd3r$qpc@qnx.com>
References: <9611240839.AA00667@rst.co.il>
Leonid Rosenboim (leonid@rst.co.il) wrote:
: In adtivle <570cik$ga1@qnx.com> <danh@qnx.com> of QNX wrote:
: > Why not POSIX?  Between the
: > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c
: > for threads, and 1003.1d for a few more realtime extensions, everything
: > you've named is very nicely covered
: Before glorifying POSIX, you should know that VxWorks (since 5.2) has
: complete support for the POSIX Real-Time extentions. I went through
: all these APIs a couple of times, trying to decicde if a particular
: application could use them, and time after time I was dissapointed
: by some thing(s) that where simply missing.
: For example, a wind mutex semaphore has the Priority Inheritance
: option, POSIX semaphore does not.
Well, I'm not exactly sure what a "windy mutex semaphore" is, but
I'll describe how POSIX semaphores and mutexes work.
POSIX semaphores are named objects valid between processes.  They do
not support priority inheritance.  In any case its illogical to
compare the POSIX interprocess synconization primative with a
lighter intertask syncronization primative.
OTOH the POSIX (pthread) mutexs only have to be valid between
threads which, AFAIK, are comparable to VxWorks tasks.  There is an
option to have POSIX (pthread) mutexes valid between processes.
Section 13.6.1.2 of 1003.1, 1996 clearly shows that pthread mutexes
can support 3 schemes: PTHREAD_PRIO_NONE, PTHREAD_PRIO_INHERIT, and
PTHREAD_PRIO_PROTECT.  PTHREAD_PRIO_NONE is uninteresting, but
PTHREAD_PRIO_INHERIT is the typically used priority inheritance
scheme for defeating priority inversion.  The PTHRED_PRIO_PROTECT
allows for the priority ceiling method of preventing priority
inversion.
POSIX also support condition variables as a syncronization
primative.
: So if anybody tells you that POSIX covers hard R-T needs "very nicely",
: then I suppose he or she understand very little about what hard R-T is.
cheap shot.
: Besides, when a standards body decides to design a spec for a Horse,
: they end up with somethig more resembling a Camel.
This is often true, but its also true that a close minded person
that wants to see a Camel will see one even if its a Horse.
Or said another way, each to his own, but I'd rather not prejudge
something before I've been able to make my own engineering
evaulation.
: Leonid
Back to the original question.  In building an abstraction layer for
real time I believe you will want to look at the existing standards.
In the areas that support is common its economically beneficial to
uses the standards.  If you can pick a "solution domain" then you
can probably find a larger set of common features.  By this I mean
that if you realize that you always work with machines that have a
certain amount of horse power and memory then you can assume more
then if you want your abstraction to scale from 8051 projects to
Alpha projects.
After you've pushed the standards as far as you feel comfortable
then its reasonable to define cover functions for functionality that
must always exist for you abstraction but doesn't have a common API.
If you want to support "wind mutex semaphore" and pthread mutexes
then its might be reasonable to pick one or the other API and
emulate it on the other OS or pick your own neutral API. This levys
requirements on all of the OS' that you port to.  Part of this will
include performance and reliability requirements.
Finally, and this is the part where the fun is, good design can
allow you to take advantage of each OS' special capabilities.  Good
partitioning of your (abstraction and application) code can often
mean the difference between being able to port your code in a fairly
short time to having each port become a real nightmare.
                         Michael
- --
* Michael Hunter (mphunter@qnx.com)
---------------------------
Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks
Subject: Re: RTOS abstraction layer
Date: Tue, 26 Nov 1996 17:27:29 +0200
From: Rami Gideoni <rami_gideoni@aisys.co.il>
Organization: AISYS
Message-ID: <329B0C61.70BF@aisys.co.il>
References: <329355D5.237C228A@aud.alcatel.com> <3297ABEF.52FE@newmonics.com>
Hi,
You might want to take a look at VITA (VMEbus International Trade
Association), which is working on establishing operation system standard
interface.
VITA was accredited as an ANSI (American National Standards Institute)
standards development
organization (SDO) in June of 1993. VITA formed the VITA Standards
Organization (VSO) as an
independent body of VITA members to develop open technology standards
that fit within the scope of
VITA's accreditation.
The orgainzation can be accesed at : http://www.vita.com and at
http://www.vita.com/vso/stds.html.
Steven J. Lee wrote:
>
> Shash Chatterjee wrote:
> >
> > Is there a vendor-independent abstraction layer for typical RTOS
> > functions like messaging, tasking, events/semaphores, timer-services,
> > etc?
> >
>
> Have you had a look at PERC, a clean-room implementation of Java
> specifically for real-time, embedded systems?
>
> --
> Steve Lee, Software Engineer                      voice: (515) 296-0897
> NewMonics Inc.                                      fax: (515) 294-9910
> 2501 N. Loop Dr., Suite 614-A             internet: sjlee@newmonics.com
> Ames, IA  50010                                http://www.newmonics.com
>
>      Supporting PERC(TM):  Portable Executive for Reliable Control
- --
Rami Gideoni
Development Projects Manager
AISYS Ltd.
E-mail : rami_gideoni@aisys.co.il
WWW : http//www.aisys-usa.com
- ---------------------------
Address :
16 Basel street,P.O.B 10041
Petach-Tikva 49001
ISRAEL
Phone : 1-800-397-7922, 972-3-9226860
Fax : 1-800-625-5525,972-3-9226863
- ----------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
Date: 26 Nov 1996 09:34:52 -0700
From: bgeer@xmission.xmission.com (bgeer)
Organization: XMission Internet (801 539 0900)
Message-ID: <57f67c$jcn@xmission.xmission.com>
References: <3299BB93.59E2B600@tsi-telsys.com>
Tim Meagher <tmeagher@tsi-telsys.com> writes:
 >Can anyone elaborate on why Wind River is providing Epilogue's SNMP
 >Agent instead of SNMP Research's agent?
Did WRS change agents?  I thought WindNet was based on SNMP Research's
agent...
 >Are there any other SNMP agent tools that should be seriously considered
 >as an alternative?
We ended up using a copy of Peer Networks SNMP agent & sub-agent code
ported to VxWorks.  The port took well less than a week.  (Who knows?
Maybe Peer now sells a VxWorks version...)  This was for a show-
capability project which wasn't delivered, but it worked pretty well.
Peer included SMUX protocol, was independent from the VxWorks kernel
for convenience of multi-board kernel configuration, & was easily
extensible.  OTH, the documentation sucked & Peer's handling of table
data was very convoluted.
I didn't have time to try or even learn much about the CMU SNMP -- the
VxWorks archives include a port of this agent.
- --
<> Robert Geer & Donna Tomky /              *             <>
<>    bgeer@xmission.com    |    _o      *   o *      o   <>
<>   Salt Lake City, Utah   |   -\<,      * <\      </L   <>
<>          U S A           |   O/ O     __ /__,    />    <>
---------------------------
Newsgroups: comp.os.vxworks
Subject: Is this a new group
Date: 26 Nov 96 17:33:36 GMT
From: "Jim O'Brien" <jimo@estc.com>
Organization: Embedded Support Tools Inc.
Message-ID: <01bbdbd8$d0601fc0$8dad8dcf@jimo.estc.com>
I am trying to read messages in this group, but it
it returns 0 messages, 0 read. Other people have
told me that there are lots of messages in this group.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Hot-swap support in VxWorks?
Date: Tue, 26 Nov 1996 13:21:51 -0800
From: Andy Van Pelt <avanpelt@qualcomm.com>
Organization: QUALCOMM, Incorporated; San Diego, CA, USA
Message-ID: <Pine.GSO.3.95.961126131934.19592R-100000@lennon.qualcomm.com>
  Does VxWorks support hot-swapping of boards?  Specifically, if you are
using VxMP, and your board is participating, has anybody found a way to
detach the board from the various structures and then attach it back again?
  This is for a 68K VME setup.
- --
Andy Van Pelt                              Internet: avanpelt@qualcomm.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: non blocking sockets
Date: Tue, 26 Nov 1996 18:42:38 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: A customer of Pacific Bell Internet Services
Message-ID: <329BAA9E.5DA0@pacbell.net>
References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com>
Reply-To: dcaustin@pacbell.net
[snip]
>
> Again, non-blocking sockets != asynch sockets.
> The non-blocking one is supported in VxWorks, asynch one is *not*!
>
> http://peacefulstar.oakland.ca.us
> mailto:hjb@peacefulstar.oakland.ca.us
ok... I thought non-blocking == asynch i/o so....... What is "asynch
sockets"?
thanks
Duane
dcaustin@pacbell.net
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other)
Date: Wed, 27 Nov 96 07:02:50 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57govc$ejl@idiom.com>
References: <3299BB93.59E2B600@tsi-telsys.com> <57f67c$jcn@xmission.xmission.com>
In article <57f67c$jcn@xmission.xmission.com>, bgeer@xmission.xmission.com (bgeer) wrote:
>I didn't have time to try or even learn much about the CMU SNMP -- the
>VxWorks archives include a port of this agent.
>
>
I've used CMU SNMP in real products in the past and it works just fine.
The VxWorks archive port works well, with one minor bug that gets triggered
by snmpwalk (infinite loop), which is easy to fix.  Customizing CMU SNMP
for a small embedded product is a whole different issue -- due to its
way of using text files and parsing routines for MIB construction in
run-time, rather than using compiled binaries in-core using tools before
the run-time.  Other than that, it works great and I highly recommend it.
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Task Deletion
Date: Tue, 26 Nov 1996 11:32:32 -0800
From: Grant Haidinyak <grant@iwv.com>
Organization: InterNex Information Services 1-800-595-3333
Message-ID: <329B45D0.38A@iwv.com>
I was wondering, vxWorks lets you allocate the tcb & stack for a task
(via the taskInit/taskActivate functions). Does anyone know when it is
ok to free these resources. For example, could I just add a
taskDeleteHook and free the resources then, or must I be more clever
than that?
thanks,
grant
---------------------------
Newsgroups: comp.os.vxworks
Subject: How To Turn Off Optimization
Date: Tue, 26 Nov 1996 07:24:04 -0800
From: russell.brill@jpl.nasa.gov (Russ Brill)
Organization: Jet Propulsion Laboratory
Message-ID: <russell.brill-2611960724040001@rmbrill.jpl.nasa.gov>
How do I turn off all optimization on the Green Hills compiler?
---------------------------
End of New-News digest
**********************
From laurin@bisco.kodak.COM  Wed Nov 27 05:33:37 1996
From: djlaurin@kodak.com (Dave Laurin - 66781 - DK)
Date: Wed Nov 27 05:33:39 PST 1996
Subject: Fast Ethernet Drivers
Are there any Fast Ethernet Drivers available for vxWorks that support
the 100mBit rate?
Looking for either a Fast Ethernet PCI bus based board solution for which there
are drivers, or a single board computer solution with on board Fast Ethernet
hardware, drivers support, and a PCI bus interface in the $1K range.
Thanks
From p72950@gmcl.co.uk  Wed Nov 27 08:04:15 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Wed Nov 27 08:04:25 PST 1996
Subject: Finding file descriptors
Hi guys,
I didn't think this would cause a problem but I haven't found a way to
do it yet. The problem is to find the file descriptor (fd) given the name of
a serial channel which is already open:
eg for channel 'tyCo/3' what is the fd representing this channel.
For the record I have tried the following:
1/ Using 'open' returns ERROR if the channel is already open.
2/ Using 'iosDevFind' returns a DEV_HDR* if the device can be found. The info
contained is similar to that returned by 'iosDevShow' and does not mention
fds.
3/ Using an undocumented function 'iosFdDevFind' returns the same DEV_HDR*
given a file descriptor. (So a quick 'for' loop of fds should find the same
DEV_HDR* and hence tie the name to the fd)
4/ The above works for '/tyCo/xx' type channels but not for the '/vio'
virtual consoles since calls to 'iosFdDevFind' for any of the '/vio/xx'
devices returns the same DEV_HDR*.
5/ The routine iosFdShow is not on the target (for Tornado anyway) so I
can't redirect & sort the output of this function.
Anyone any ideas?
Regards
Phil Quiney
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From Ricky.D.Graves@jpl.nasa.gov  Wed Nov 27 11:01:58 1996
From: Ricky D Graves <Ricky.D.Graves@jpl.nasa.gov>
Date: Wed Nov 27 11:02:00 PST 1996
Subject: Heurikon symbol load prob.
All,
Help me please !!!
I have been having a an intermittent problem with Heurikon HK68 V3Fs and Vxworks
5.02B. During bootup when loading   symbols with all lower case letters I see
certain letters get loaded as uppercase.  Letters "d" and  "a"  seem to occur
commonly. After the symbol is loaded improperly I get an undefined symbol error
when a progrma is loaded that refrences the corrupted symbol. I have been
working with Heurikon to determine the cause but so far that can't duplicate the
problem. I have even seen one case where the an uppercase letter is shown being
loaded and then message showing the address and data shows a lower case letter.
 I have tried different tranceivers, chassis, etc to no avail.  The problem
definitely follows particular cards from one chassis to another.  I have about 5
cards out of 20 that have the problem.  The only difference I have been able to
determine is the problem cards have 80ns RAM instead of 70ns which is called out
in the manual.
If anybody can tell em whether an error like this can get passed the Ethernet
error checking that would help narrow the problem down.  I don't think it can.
Heurikon doesn't think that could cause the problem.  Here is a sample of what I
See:
The error is not flagged until a program is loaded that uses the symbol.  The
error generated at that point is:
_assem_iruA     =0xfe000000
new symbol "-assem_iruA" added to symbol table.
_assem_iruA = 0x78e434: value = -33554432 = 0xfe000000
\
undefined symbol:  _assem_irua
ld error: error reading file (errno = 0x1x0001).
or
_assem_iruB     =0xfe010000
new symbol "-assem_irub" added to symbol table.
_assem_irub = 0x78e400: value = -33488896 = 0xfe010000
\
undefined symbol:  _assem_irua
ld error: error reading file (errno = 0x1x0001).
I believe this error is just a sympton of the intial error which is the symbol
being loaded improperly into the symbol table.  I tried booting several of the
problem cards using a 10BT transceiver and still observed the same problem. One
card (SN 142)  seemed to improve after it was on in the chassis for a few
minutes but I didn't try it enough times to verify the problem had went away.  I
also made note of the battery voltges which were around 3.7V but did seem to
increase somewhat after they were in the chassis for a few minutes.
In the past, I  have not been able to correlate the battery condition to the
problem.  So far about the only thing that seems to be common to these boards is
the 80ns RAM.  If we can understand what must be happening to cause the symbol
to get loaded incorrectly  I think that would provide the answer.  I looked up
ASCII character bit definitions and found the difference between uppercase and
lower case letter "a" to be the following:
Octal                       Octal
1 000 001       A           1 100 001       a
1 000 100       D           1 100 100       d
If this translates directly to data bits 0-7 on the VME, that indicates bit 6 is
being incorrectly read as zero instead of one.  Letter "d" and "a" are the
errors I see most often.   I don't understand the symbol loading process well
enough to know what could possibly cause this problem.
Do you know somebody at Vxworks that could help with this problem ?
P.S. I did notice a slight difference on the symbol load expression between your
simulated load and the actual load which I doubt would make any difference but I
will mention it anyway.  Our loads seem to have several spaces between the
symbol name and the "="  like the following:
_assem_irua        = 0xfe000000
whereas yours
_assem_irub=0xfe010001
From wbrown@csg.lbl.gov  Wed Nov 27 12:40:57 1996
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Wed Nov 27 12:40:59 PST 1996
Subject: Re: Heurikon symbol load prob.
> [  ...  ]
>  The only difference I have been able to  determine is the problem cards
> have 80ns RAM instead of 70ns which is called out in the manual.
Well, I don't know anything about the Heurikon boards, but I'd get a logic
analizer and take a _REAL_GOOD_LOOK_ at the _actual_ memory timing vs the
manufacturers' specs on those 80 nS ram chips.
> [  ...  ]
> Octal                       Octal
> 1 000 001       A           1 100 001       a
> 1 000 100       D           1 100 100       d
As some famous person once said, "Circumstantial evadence can be particularly
damning, like when you find trout swimming in the milk."  Or something like
that.  More or less.  Spelling errors ommitted.
One might even spend a few hours writing some read/write/compare memory tests,
if you could ever get them to run on these boards.  It would be interesting
to know if the errors tend to cluster around some addresses.
I better shut up before I _really_ put my foot in my mouth, which I seem to
do far too often.
Happy Turkey Day, everyone!
Disclaimer:  Any opinions are my own and have	    |  -bill
    nothing to do with the official policy or the   |   wlbrown@lbl.gov
    management of L.B.N.L, who probably couldn't    |   Berkeley, CA
    care less about employees who play with trains. |   aka wlbrown@netcom.com
From usd@mee.hwm.com  Thu Nov 28 01:09:58 1996
From: Uwe Scheffold <usd@mee.hwm.com>
Date: Thu Nov 28 01:10:05 PST 1996
Subject: How to set the cursor on vt100-terminal.
Hi vxWorkers,
it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help?
Regards: Uwe Scheffold
-------------------------------------------------------------------------
Uwe Scheffold     _/_/_/_/_/_/_/_/_/  _/_/_/_/   Mail: usd@mee.hwm.com
Tele Robot Engineering _/    _/   _/ _/           Web: http://www.hwm.com
Waelischmiller GmbH   _/    _/_/_/  _/_/_/      Voice: (+49) 7532 4320 41
Klingleweg 8         _/    _/   _/ _/             Fax: (+49) 7532 4320 99
D-88709 Meersburg   _/    _/    _/_/_/_/_/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From daemon@csg.lbl.gov  Thu Nov 28 04:00:17 1996
From: daemon@csg.lbl.gov
Date: Thu Nov 28 04:00:24 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Nov 28 04:00:15 PST 1996
        Subject: "Auto" Routing
        Subject: Re: "Auto" Routing
        Subject: delay functions independent on ticks
        Subject: Re: delay functions independent on ticks
        Subject: Re: delay functions independent on ticks
        Subject: Interrupts
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: "Auto" Routing
Date: 27 Nov 1996 13:12:12 GMT
From: milesm@tif531.ed.ray.com (Michael Miles)
Organization: Raytheon
Message-ID: <57henc$4rj@news.res.ray.com>
Hi--
I was wondering if anyone has any experience with re-routing ip packets
to an alternate LAN when the LAN they were originally sent to is down?  I
am working on a system with 3 LANS.  Each is properly configured in the
Routing table.  It seems to me that if a LAN fails, it is the job of my
application code to detect the failure and update the routing table to
use a different LAN.  A co-worker tells me that he is sure that VxWorks
will detect the failure and re-route automatically.  Is there anyone with
experience in this area who might be able to give me some insight?
Thanks
Mike Miles
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: "Auto" Routing
Date: Wed, 27 Nov 96 19:05:32 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57i3bo$on3@idiom.com>
References: <57henc$4rj@news.res.ray.com>
In article <57henc$4rj@news.res.ray.com>, milesm@tif531.ed.ray.com (Michael Miles) wrote:
>Hi--
>
>I was wondering if anyone has any experience with re-routing ip packets
>to an alternate LAN when the LAN they were originally sent to is down?  I
>am working on a system with 3 LANS.  Each is properly configured in the
>Routing table.  It seems to me that if a LAN fails, it is the job of my
>application code to detect the failure and update the routing table to
>use a different LAN.  A co-worker tells me that he is sure that VxWorks
>will detect the failure and re-route automatically.
Your co-worker is wrong.  VxWorks will not detect the failure and re-route
automatically.  You either have to do this in your application (edit
routing table), or use a routing protocol daemon (port one on your own).
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: delay functions independent on ticks
Date: 27 Nov 1996 21:34:30 GMT
From: chrisver12@aol.com
Organization: AOL, http://www.aol.fr
Message-ID: <19961127213600.QAA04995@ladder01.news.aol.com>
I try to find timer or delay function independent on the clock ticks
to sample data from an I/O VME board with a period less
than the clock ticks (uselly 10 ms) and for a short time 100ms.
I dont want to change the ticks rate for that purpose.
Function like nanosleep(), taskdelay() or timer functions seems to be
dependant
on the the clock tiks and the minimum delay given is equivalent to the
ticks.
Thanks to help me if you know the solution.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: delay functions independent on ticks
Date: Thu, 28 Nov 1996 02:36:25 GMT
From: VanCLy@ix.netcom.com (Van Chinh Ly)
Organization: Netcom
Message-ID: <57ito1$c0f@dfw-ixnews2.ix.netcom.com>
References: <19961127213600.QAA04995@ladder01.news.aol.com>
Reply-To: VanCLy@ix.netcom.com
chrisver12@aol.com wrote:
>I try to find timer or delay function independent on the clock ticks
>to sample data from an I/O VME board with a period less
>than the clock ticks (uselly 10 ms) and for a short time 100ms.
>I dont want to change the ticks rate for that purpose.
>Function like nanosleep(), taskdelay() or timer functions seems to be
>dependant
>on the the clock tiks and the minimum delay given is equivalent to the
>ticks.
I use the sysClkRateGet() to find out how many clicks are in a second.
From there on, I can find a conversion constant to get the number
of clicks I need to get the time period I want.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: delay functions independent on ticks
Date: Thu, 28 Nov 96 05:50:57 GMT
From: hjb@peacefulstar.oakland.ca.us (H.J. Bae)
Organization: Peaceful Star
Message-ID: <57j95s$9ta@idiom.com>
References: <19961127213600.QAA04995@ladder01.news.aol.com> <57ito1$c0f@dfw-ixnews2.ix.netcom.com>
In article <57ito1$c0f@dfw-ixnews2.ix.netcom.com>, VanCLy@ix.netcom.com wrote:
>chrisver12@aol.com wrote:
>
>>I try to find timer or delay function independent on the clock ticks
>>to sample data from an I/O VME board with a period less
>>than the clock ticks (uselly 10 ms) and for a short time 100ms.
>
>>I dont want to change the ticks rate for that purpose.
>
>>Function like nanosleep(), taskdelay() or timer functions seems to be
>>dependant
>>on the the clock tiks and the minimum delay given is equivalent to the
>>ticks.
>
>I use the sysClkRateGet() to find out how many clicks are in a second.
>From there on, I can find a conversion constant to get the number
>of clicks I need to get the time period I want.
>
This is not what original poster is asking for.  The usual clock rate
is set to 60 hz (60 ticks per second), which is a common tick count
for most kernel (historically significant for being the same as current
frequency on power line, which was used in old machines).  This clock
rate is not accurate enough for 10 msec period, and the original
poster does not want to change it to higher frequency either.  The
question is not about how to find clock rates, nor is it about using
faster clock rates, it is how to get 10 msec period without changing
main system clock rates.
One method is using aux clocks, but that will cause extra interrupt
handling overhead, which you probably do not want.
Another method, if hardware allows it, is to run clock/timer HW at
high rates with interrupts turned off (if you have more than one
timer channels) or program it to run at high resolution but interrupt
you slowly (after the counters runs down to some number, say 100 ticks).
Then you can write a delay routine that samples the values of running
timer and poll until desired resolution is achieved.
This is a "common trick."
http://peacefulstar.oakland.ca.us
mailto:hjb@peacefulstar.oakland.ca.us
---------------------------
Newsgroups: comp.os.vxworks
Subject: Interrupts
Date: 28 Nov 1996 05:06:31 GMT
From: x1593135@ecs.fullerton.edu (--Ext Ed 15931--)
Organization: California State University at Fullerton
Message-ID: <57j6kn$kd5@wintermute.ecs.fullerton.edu>
Does anyone have an example of code which sets up an Interrupt Service
Routine in VxWorks which calls a C or C++ routine?
Any example would be useful, but my platform is PowerPC 403.
Thanks
Steve Renate
Please post or mail directly (x1593135@titan.fullerton.edu)
---------------------------
End of New-News digest
**********************
From herve_pellan@grenoble.hp.com  Thu Nov 28 04:42:39 1996
From: Herve Pellan <herve_pellan@grenoble.hp.com>
Date: Thu Nov 28 04:42:41 PST 1996
Subject: Re: How to set the cursor on vt100-terminal.
the vxWorks Users Group Exploder wrote:
>
> Submitted-by usd@mee.hwm.com  Thu Nov 28 01:09:58 1996
> Submitted-by: Uwe Scheffold <usd@mee.hwm.com>
>
> Hi vxWorkers,
>
> it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help?
>
This is done through the use of Escape sequences.
        Cursor Movement Commands
                Cursor up                       ESC [ Pn A
                Cursor down                     ESC [ Pn B
                Cursor forward (right)          ESC [ Pn C
                Cursor backward (left)          ESC [ Pn D
                Direct cursor addressing        ESC [ Pl; Pc H  or
                                                ESC [ Pl; Pc f
Herve
+----------------------------------------------------------------------+
|        /\\/\0 Herve PELLAN     /\/\ Telnet:  779-5107                |
| /\    /  \\                 /\/ /  \ non-TN:  (33) 4 76 14 51 07     |
|/  \/\/    \  ENSD  Lab     /  \/    \ Fax:     (33) 4 76 14 51 86    |
/    \ \     \_GRENOBLE_____/    \ e-mail: Herve_Pellan@grenoble.hp.com|
|              HEWLETT PACKARD                                         |
+----------------------------------------------------------------------+
From leonid@rst.co.il  Thu Nov 28 05:28:11 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Thu Nov 28 05:28:29 PST 1996
Subject: Re: Heurikon symbol load prob.
Ricky D Graves <Ricky.D.Graves@jpl.nasa.gov> writes:
>...
> If anybody can tell em whether an error like this can get passed the Ethernet
> error checking that would help narrow the problem down.  I don't think it can.
> ...
The error you described could very well be as a result of timing
problems with memory or ethernet or between the two.
The error checking that Ethernet applies to all data is very string, CRC-32,
but it is applied to data in transit on the Ethernet wire, serially.
Once data gets past the EThernet controller, which in turn takes
over the memory bus and writes this data in to the board's memory,
it is already stripped off the CRC-32, which is checked and generated
by the Ethernet controller.
In other words, the parallel dat apaths inside a CPU board
do bot have any safeguards against error, (usually).
We had a similar problem with VME boards from Matrix couple fo years
back. Real nasty. A timing problem appeared between the Ethernet
mezzanine board and CPU memory, only when the board was cool,
i.e. on winter mornings before the air condition warmed the lab,
the board did not boot, So we turned off the fans, waited a minute,
and it booted. Turned out later, that after it booted, the problem
would sometimes re-appear on the 10e-3 probability scale, and the folks
thought it was an application bug. Application data arrived with errors
despite all measures.
Hope this helps,
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il
From p72950@gmcl.co.uk  Thu Nov 28 06:09:40 1996
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Thu Nov 28 06:09:59 PST 1996
Subject: Re: How to set the cursor on vt100-terminal.
Hi Uwe,
I found an old VT100 manual. It suggests that the sequences are as follows
(3 charactesr ESC (decimal 27) '[' and the letter A B C or D)
Up	ESC [ A
Down	ESC [ B
Right	ESC [ C
Left	ESC [ D
For direct cursor control to a screen co-ordinate try
ESC [ y ; x H (where y is row x is column - no spaces by the way)
You can try these out by putting the terminal in local mode before
writing lots of code ;)
Regards
Phil Quiney
>Hi vxWorkers,
>
>it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help?
>
>Regards: Uwe Scheffold
>
>-------------------------------------------------------------------------
>Uwe Scheffold     _/_/_/_/_/_/_/_/_/  _/_/_/_/   Mail: usd@mee.hwm.com
>Tele Robot Engineering _/    _/   _/ _/           Web: http://www.hwm.com
>Waelischmiller GmbH   _/    _/_/_/  _/_/_/      Voice: (+49) 7532 4320 41
>Klingleweg 8         _/    _/   _/ _/             Fax: (+49) 7532 4320 99
>D-88709 Meersburg   _/    _/    _/_/_/_/_/
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From selliott@mkc.com.au  Thu Nov 28 20:46:52 1996
From: Steve Elliott <selliott@mkc.com.au>
Date: Thu Nov 28 20:46:54 PST 1996
Subject: CD-ROM & ZIP drives under VxWorks
Does anyone know of implementations of CD-ROM and/or ZIP drive drivers for VxWorks?
Steve Elliott
----------------------------------------------------
Steve Elliott,       | Voice:  +61(2) 9638 4055    |
MAYER KRIEG & CO     | Fax:    +61(2) 9638 6145    |
U2, 8-10 Mary Parade | Mobile: +61(418) 236 820    |
Rydalmere, NSW 2116  | Email:  selliott@mkc.com.au |
Australia            |
From daemon@csg.lbl.gov  Fri Nov 29 04:00:14 1996
From: daemon@csg.lbl.gov
Date: Fri Nov 29 04:00:21 PST 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Nov 29 04:00:12 PST 1996
        Subject: Flash File system
        Subject: Re: Making non-standard serial I/O -driver
        Subject: Re: non blocking sockets
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Flash File system
Date: 28 Nov 1996 13:16:13 GMT
From: "Pekka Tuusjdrvi" <pekka.tuusjarvi@pine.sahako.fi>
Organization: Heinolan Sahakoneet Oy
Message-ID: <01bbdd2e$73706340$2fce9dc2@pt.hla>
Can anyone give a hint where I can find a Flash File system driver for the
on board flash on the MVME162  board for VxWorks.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Making non-standard serial I/O -driver
Date: 28 Nov 1996 16:30:21 -0600
From: irwin@Starbase.NeoSoft.COM (Bob Irwin)
Organization: Realtime Systems / SW Houston
Keywords: Hostess 550 comm driver
Message-ID: <57l3pt$7ms@Starbase.NeoSoft.COM>
References: <329A7A25.2ACA@topic.nl>
In article <329A7A25.2ACA@topic.nl>, E van der Laak  <evdlaak@topic.nl> wrote:
>With respect to the installation and configuration of a VxWorks
>development environment, I have the following question:
>
>Currently we are configuring a VxWorks target for use in an embedded
>system. We are planning to use a non-standard serial I/O-card of
>manufacturer Comtrol, being the Hostess 550. Does anyone of you have
>experience in writing your own driver for such a card?
>
>Any suggestions with respect to implementing the standard I/O functions,
>device list, driver table, etc OR using customary read and write
>operations provided by a self-made driver using for instance two message
>queues for I/O from/to the card?
 . . .
>evdlaak@topic.nl
I assume you're using the x86 bsp and an ISA bus.
A library for this card is available from Systems Interface Software, Inc
In Houston.  commLib supports either the 8 or 16 channel version in
either binary or ascii full duplex transfers. It does not use the
vxWorks tyLib routines in order to minimize system interrupts. In
transmitting, an interrupt on a given channel occurs only when its
16 byte fifo empties, and the ISR also services any other TX fifos
that go empty during that one interrupt service. In receiving, a
reader task periodically empties the fifos for all the open channels
into their respective circular buffers (no interrupts).
Contact John Reed at sis@neosoft.com for more info.
 - Bob
- --
R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
A rut is nothing more than a grave with the ends kicked out.  - ??
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: non blocking sockets
Date: Fri, 29 Nov 1996 08:24:28 GMT
From: valentin@netcom.com (Valentin Pepelea)
Organization: Netcom Communications, Santa Clara, CA
Message-ID: <valentinE1MI0s.4Cs@netcom.com>
References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com> <329BAA9E.5DA0@pacbell.net>
Sender: valentin@netcom23.netcom.com
In article <329BAA9E.5DA0@pacbell.net> dcaustin@pacbell.net writes:
>
>> Again, non-blocking sockets != asynch sockets.
>> The non-blocking one is supported in VxWorks, asynch one is *not*!
>
>ok... I thought non-blocking == asynch i/o so....... What is "asynch
>sockets"?
Actually, asynchronous I/O usually refers to what happens during the trans-
mission of data. If the sender has to block after a send operation, until the
receiver replies to confirm that the data has been received, then the I/O
operation is called synchronous. If the sender returns immediately from the
send(), the operating is called asynchronous.
Non-blocking usually refers to what happens to the receiver. If the receiver
tries to read data and there is no data present, what happens? If he blocks
until some data is present, the call is blocking. If he returns immediately,
with or without and error code, the call is non-blocking.
I'm not sure about VxWorks, but Berkley sockets are by default asynchronous.
A send() call always returns immediately, regardless of whether the data ever
reaches the destination. Oh what fun. The recv() call may block or not, as
optionally set on a per-socket basis by the programmer.
Valentin
- --
"An operating system without virtual memory      Valentin Pepelea
 is an operating system without virtue."         Embedded Systems Consultant
                                                 (415) 346-7105
                     - Ancient Inca Proverb      valentin@netcom.com
---------------------------
End of New-News digest
**********************
From yfan@spar.ca  Fri Nov 29 06:53:12 1996
From: Yibing Fan <yfan@spar.ca>
Date: Fri Nov 29 06:53:15 PST 1996
Subject: socket: synchronous, asynchronous, blocking and non-blocking
Hi Everyone,
I am confused by recent discussion of asynchronous socket.
I've been using TCP and UDP socket in both blocking and non-blocking
way, and never questioned myself about socket is synchronous or
asynchronous. I had no doubt that these (synchronous and blocking) are
two different sets of concept. I can rationalize myself  that the TCP
socket is synchronous,  because message is guaranteed delivery, so
some sort of acknowledgement has to be send back to sender. This
must be done by layers lower than application. I would guess it is done
by TCP/IP layer.
For UDP socket I always think it is asynchronous. Am I  wrong?
Someone please strait me out.
Thanks
=========================
Yibing Fan
yfan@spar.ca
Video et Taceo
=========================
From selliott@mkc.com.au  Fri Nov 29 20:54:51 1996
From: Steve Elliott <selliott@mkc.com.au>
Date: Fri Nov 29 20:55:10 PST 1996
Subject: Code Coverage tools
Does anyone know of any code coverage tools which have been implemented for VxWorks applications?
Also we are looing for any test case generation tools which may be available.
Steve Elliott
----------------------------------------------------
Steve Elliott,       | Voice:  +61(2) 9638 4055    |
MAYER KRIEG & CO     | Fax:    +61(2) 9638 6145    |
U2, 8-10 Mary Parade | Mobile: +61(418) 236 820    |
Rydalmere, NSW 2116  | Email:  selliott@mkc.com.au |
Australia            |