From Thomas.Arand@vs.siemens.de  Tue Jul  1 01:17:14 1997
From: "Arand, Thomas OEN BN EF3" <Thomas.Arand@vs.siemens.de>
Date: Tue Jul  1 01:17:17 PDT 1997
Subject: Setting Tornado Environment Variables within a Makefile
Hi all,
I'm trying to build a Makefile that allows to create applications for
different target architectures. As the WRS sources for these
architectures reside in different directory tries, I have to set the
Environment (WIND_BASE, PATH, etc) depending on the target. I do not (!)
want to set them outside the Makefile (i.e. before the make-call).
What happens if I simply set make-macros, is an error when the compiler
is called (cpp: invalid option '-lang-c++'). the reason seams to be that
the compiler internally calls other programs (cpp), with a wrong
environment.
Does anyone have an idea how I can achieve this?
Thanks and Ciao,
	Thomas Arand
From daemon@csg.lbl.gov  Tue Jul  1 04:00:44 1997
From: daemon@csg.lbl.gov
Date: Tue Jul  1 04:00:46 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jul  1 04:00:39 PDT 1997
        Subject: Re: More PPP and BOOTP
        Subject: Drivers
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: More PPP and BOOTP
Date: Tue, 17 Jun 1997 23:53:37 -0700
From: "h.j. bae" <hjb@pso.com>
Organization: peaceful star @ derome mansion, http://www.pso.com
Message-ID: <33A785F0.1401@pso.com>
References: <33A6BA9C.6A16@aval.com>
Reply-To: hjb@pso.com
Larry Gadallah wrote:
> Yes,  one other person suggested explicitly specifying the BOOTP
> server address too. Unfortunately, the client doesn't know what
> it is, so this approach won't work too well.
>
so what you have is a PPP client that is talking to another PPP
machine that may or may not be the BOOTP server.  in that case, you
will need to implement a BOOTP forwarder process on the other side
machine.   either way, you can specify the other guy's IP address
as your BOOTP server address.  if the other machine is not BOOTP
server, it should forward the BOOTP request to another machine
hopefully over a broadcast network (ethernet), and forward back
the reply.  this scheme is specified in the RFC and is common in
cases where you are booting over BOOTP in a gatewayed network
environment.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Drivers
Date: Thu, 19 Jun 1997 02:19:41 GMT
From: oshaw@cyberus.ca (Patrick Shaw)
Organization: Cyberus Online Inc.
Message-ID: <33a8972c.42264709@news.cyberus.ca>
Hi:
	I was wondering if anybody has a driver for  AMD 53C794 SCSI
controller ?
Thanks,
Patrick Shaw
---------------------------
End of New-News digest
**********************
From Tim.Adams@bailey.com  Tue Jul  1 05:13:51 1997
From: "Adams, Tim" <Tim.Adams@bailey.com>
Date: Tue Jul  1 05:13:59 PDT 1997
Subject: Re:Setting Tornado Environ Vars for a Make
--MimeMultipartBoundary
Content-Type: text/plain
Thomas:
I have included part of our make below.  You need to set CPU,
TARGET_DIR, and TOOL.  You do not need to set WIND_BASE, PATH etc.  Hope
this helps
Tim Adams
########################################################################
BUILD_DIR = TestBuild
VPATH=.\$(BUILD_DIR)
#
# These can be overridden on the make line e.g.
#			make vxWorks CPU=MC68040 TARGET_DIR=mv167
#
CPU		= PPC603
TARGET_DIR 	= ultra603
TOOL		= gnu
########################################################################
#
########################################################################
SERVER_ROOT =  h:\Home\Oboe
MAKEDEFINES_DIR = $(OBOE_ROOT)\config
SYSTEM_DIR		 =$(MAKEDEFINES_DIR)\$(TARGET_DIR)
ALL_DIR             	 =$(MAKEDEFINES_DIR)\all
SYSTEMIMAGE	 =$(SYSTEM_DIR)\vxWorks
WARNINGDEFS = -Wall -Wno-unused -Werror
INC_DIRS    = -I.\ -I$(WIND_BASE)\Target\h -I$(OBOE_ROOT)\h
-I$(SYSTEM_DIR) -I$(ALL_DIR) -I$(WIND_BASE)\Target\config\$(TARGET_DIR)
ARCH_DEFS = -mcpu=603 -fno-builtin -fno-for-scope -nostdinc -DCPU=PPC603
-D_GNU_TOOL
#
#
#
########################################################################
.PHONY : all oboe OBOE Oboe clean CLEAN Clean update Update UPDATE Vlog
vLog vlog VLOG
ErrorCopy:
	xcopy $(OBOE_ROOT)\h\Tornado\ErrorFiles\*.h
$(WIND_BASE)\Target\h\*.h
	xcopy $(OBOE_ROOT)\h\Tornado\Host\Resource\Tcl\*.tcl
$(WIND_BASE)\Host\Resource\Tcl\*.tcl
vxWorks vxworks VXWORKS: ErrorCopy
	if exist $(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.h copy
$(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.h
$(WIND_BASE)\target\config\$(TARGET_DIR)\*.h
	if exist $(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.c copy
$(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.c
$(WIND_BASE)\target\config\$(TARGET_DIR)\*.c
	if exist $(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.s copy
$(MAKEDEFINES_DIR)\$(TARGET_DIR)\*.s
$(WIND_BASE)\target\config\$(TARGET_DIR)\*.s
	if exist $(MAKEDEFINES_DIR)\all\*.h copy
$(MAKEDEFINES_DIR)\all\*.h $(WIND_BASE)\target\config\all\*.h
	if exist $(MAKEDEFINES_DIR)\all\*.c copy
$(MAKEDEFINES_DIR)\all\*.c $(WIND_BASE)\target\config\all\*.c
	if exist $(MAKEDEFINES_DIR)\all\*.s copy
$(MAKEDEFINES_DIR)\all\*.s $(WIND_BASE)\target\config\all\*.s
	'pushd $(WIND_BASE)\target\config\$(TARGET_DIR)' && 'make
vxWorks' && 'popd'
	copy $(WIND_BASE)\target\config\$(TARGET_DIR)\vxWorks
$(SYSTEMIMAGE)
	copy $(WIND_BASE)\target\config\$(TARGET_DIR)\vxWorks.sym
$(SYSTEMIMAGE).sym
	if not exist $(SERVER_ROOT)\config\nul md $(SERVER_ROOT)\Config
	if not exist $(SERVER_ROOT)\config\$(TARGET_DIR)\nul md
$(SERVER_ROOT)\Config\$(TARGET_DIR)
	copy $(SYSTEMIMAGE) $(SERVER_ROOT)\config\$(TARGET_DIR)
	copy $(SYSTEMIMAGE).sym $(SERVER_ROOT)\config\$(TARGET_DIR)
########################################################################
#########
Hi all,
I'm trying to build a Makefile that allows to create applications for
different target architectures. As the WRS sources for these
architectures reside in different directory tries, I have to set the
Environment (WIND_BASE, PATH, etc) depending on the target. I do not (!)
want to set them outside the Makefile (i.e. before the make-call).
What happens if I simply set make-macros, is an error when the compiler
is called (cpp: invalid option '-lang-c++'). the reason seams to be that
the compiler internally calls other programs (cpp), with a wrong
environment.
Does anyone have an idea how I can achieve this?
Thanks and Ciao,
	Thomas Arand
--MimeMultipartBoundary--
From mfischer@qualcomm.com  Tue Jul  1 10:39:34 1997
From: Mark Fischer <mfischer@qualcomm.com>
Date: Tue Jul  1 10:39:37 PDT 1997
Subject: VME References?
All,
Are there any good books on VME programming standards and practices?
Mark Fischer
Qualcomm, Inc.
From baumann@llumc.edu  Tue Jul  1 11:30:49 1997
From: Michael Baumann <baumann@proton.llumc.edu>
Date: Tue Jul  1 11:30:52 PDT 1997
Subject: Re: VME References?
--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 1 Jul 1997, the vxWorks Users Group Exploder wrote:
> Are there any good books on VME programming standards and practices?
Umm.. Are you aware that VME is a hardware spec?
--
Michael Baumann  Optivus Technology Inc.|Loma Linda University Medical Center
San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu
--MimeMultipartBoundary--
From mfischer@qualcomm.com  Tue Jul  1 13:03:24 1997
From: Mark Fischer <mfischer@qualcomm.com>
Date: Tue Jul  1 13:03:27 PDT 1997
Subject: Re: VME References?
According to the vxWorks Users Group Exploder:
> > Are there any good books on VME programming standards and practices?
> Umm.. Are you aware that VME is a hardware spec?
Ahhh, yeah, last I heard. VME may be a hardware specification, but
there is an awful lot of software that uses it.
Part of my question addressed "practices"- ie, there are only about
a million ways to use this "hardware spec", but there may be some
practices that are commonly used in the industry. The same way "C" is
just a language, but the practice of using modules/libraries/makefiles
is commonly used in the industry.
So, once again, are there any books that describe common practices,
"tricks", ways of using VME?
Thanks,
Mark Fischer
Qualcomm, Inc.
From tmorris@ziv.me.umn.edu  Tue Jul  1 16:11:39 1997
From: Ted Morris <tmorris@ziv.me.umn.edu>
Date: Tue Jul  1 16:11:41 PDT 1997
Subject: PC104 Pentiums??
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anyone out there know of a source that sells PC104 Pentium SBCs???  Does
anyone out there at least use PC104 with 80x68 SBCs with Tornado? Has it
been a good dog or a bad dog for you?
*excuse* my ignorance
-- now back to multi-processor support --
Which bus architectures -- besides VME -- have multi-processor
capabilities AND have a decent number of SBC vendors that currently
support this feature??
thanks,
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
---------------------------------------------------------------------------
"You cannot think about thinking without thinking about thinking about
something" -- Seymour A. Papert
--MimeMultipartBoundary--
From froeber@bbn.com  Tue Jul  1 19:58:35 1997
From: Fred Roeber <froeber@bbn.com>
Date: Tue Jul  1 19:58:38 PDT 1997
Subject: Re:Setting Tornado Environ Vars for a Make
--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII
Thomas Arand asked:
> What happens if I simply set make-macros, is an error when the compiler
> is called (cpp: invalid option '-lang-c++'). the reason seams to be that
> the compiler internally calls other programs (cpp), with a wrong
> environment.
The problem you are having here is that you probably haven't set the
GCC_EXEC_PREFIX environment variable correctly.  That is the variable that
tells the GCC compiler where to find the "internal" compiler executables
that it calls.  If you check the VxWorks programmers guide it should tell
you all the environment variables you need to set up.
We went through trying to do get the makefile to set up the correct
environment for compiling a while back.  It was somewhat annoying to get
working due to the fact that different Make programs handle environment
variables differently as well as the way they spawn commands.  Some of the
problems are that:
1) Make macros are different from shell environment variables.  Make macros
   are simply used for text substitution within make files while
   environment variables define settings that are available to the
   commands executed by the shell the make program spawns off.
2) Make programs typically execute each command line in the make file
   as a separate sub shell so that you can't set environment variables
   in one command line of a make script for use by the commands in another
   command line.
3) Most make programs execute commands using the bourne shell by default
   regardless of what your real shell is.  This means you need to use
   the "export" commands when declaring new environment variables.
Unfortunately, I don't have immediate access to the actual make file we
used to get all this working.  I am pretty sure we ended up having to
use Bourne shell "export" commands to declare all the environment
variables needed by the VxWorks tools.  We then tied the export
commands into one big make command line by using ';' between the
commands and '\' at the end of the command lines so they were treated
as one command and executed by a single subshell.  An example would be:
    export GCC_EXEC_PREFIX ; GCC_EXEC_PREFIX=xxx ; make vxWorks
What we did worked for either SUN or GNU make programs.  There may be
some easier way to get this to work with GNU make since it tends to have
a lot of special features.  If anyone has a better method I would be
interested in knowing too.
Hope that helps.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Wed Jul  2 04:00:31 1997
From: daemon@csg.lbl.gov
Date: Wed Jul  2 04:00:34 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jul  2 04:00:27 PDT 1997
        Subject: CAN registers at odd addresses unreadable when network active
        Subject: Re: pci ethernet 100base-t
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: CAN registers at odd addresses unreadable when network active
Date: Tue, 1 Jul 1997 09:51:48 GMT
From: Sjaak Lagewaard <qsla@oce.nl>
Organization: Oci-Technologies B.V.
Message-ID: <33B8D334.39BDD56E@oce.nl>
Reply-To: qsla@oce.nl
Sender: news@oce.nl (The Daily News @ nntp01.oce.nl)
Product: Tornado Version 1.01
OS: Win95
BSP: PC386
Hello,
We encountered a problem with reading board registers at odd byte
addresses.
We are using an I+ME CAN card at address 0xD8000 wich uses IRQ 5
When I boot VxWorks via the network via TCP/IP (using a SMC Elite16
Ultra card at address 0xC8000, IRQ 10), I cannot read the CAN board
registers at odd addresses (a memory dump from the target shell shows FF
at the odd addresses, but the even addresses give correct results).
When we make a bootable floppy disk without the network functionality,
the odd adresses are correct.
I think the problem has to do with the fact that the CAN card is an 8
bit card, so you really have to do 8 bit memory reads to read the CAN
chip's registers. I see that this happens when no network functionality
is included.
Now, I suppose that when I include the network stuff, memory access
suddenly changes into 16 bit memory reads (probably for better
performance). This doesn't work for 8 bit cards. I cannot read the CAN
registers at odd addresses with the shell's 'd' command, nor from a C
program by direct adressing the memory (via a char *).
So I think this is either an error or it is an option which I would like
to turn off.
Does anybody know how I can use the network and still read registers at
odd addresses?
With kind regards,
Sjaak Lagewaard
- --
                                                     ,,,,,
                                                    /     \
                                                   / ^   ^ \
                                                  ( (o) (o) )
                                                   \       /
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~oOOO~~~~(_)~~~~OOOo~~~~~
   | Sjaak Lagewaard  @  Oci-Technologies B.V.,                      |
   | Location 3G20 / PO Box 101 / NL-5900 MA Venlo / The Netherlands |
   | Email       Work : mailto:qsla@oce.nl                           |
   | Voice            : +31 77 3592785                               |
   | URL          Oce : http://www.oce.com                           |
   | URL          ICT : http://www.ict.nl                            |
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Oooo.~~~~~~~~
                                                 .oooO   (   )
                                                 (   )    ) /
                                                  \ (    (_/
                                                   \_)
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: pci ethernet 100base-t
Date: Tue, 01 Jul 1997 19:59:24 -0700
From: John Kevin Fabiani <johnx@wrs.com>
Organization: Wind River Systems
Message-ID: <33B9C40C.C53BF5DD@wrs.com>
References: <33B7FFE2.B21@msbg.med.ge.com>
Reply-To: johnx@wrs.com
GE Employee wrote:
>
> --MimeMultipartBoundary
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Hello World,
>
> I am currently running VxWorks 5.3.1. I am looking for a PCI Ethernet
> card that is compatible with both 10Base-T and 100Base-T and would be
> supported by VxWorks existing ethernet drivers.
VxWorks 5.3.1 x86 has a 82557 driver for the intel etherexpress Pro100B.
John
>
> Thank you,
> Tri Le
> tri.le@med.ge.com
> --MimeMultipartBoundary--
---------------------------
End of New-News digest
**********************
From mcintosh@ccsi.com  Wed Jul  2 04:35:54 1997
From: Gordon McIntosh <mcintosh@ccsi.com>
Date: Wed Jul  2 04:35:57 PDT 1997
Subject: Re: VME References?
A good place to look for VME resources is the VITA homepage.
Gordon McIntosh
From mea@mclean.sparta.com  Wed Jul  2 05:39:42 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed Jul  2 05:39:45 PDT 1997
Subject: Re: PC104 Pentiums??
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 04:11 PM 7/1/97 PDT, you wrote:
>
>Anyone out there know of a source that sells PC104 Pentium SBCs???  Does
>anyone out there at least use PC104 with 80x68 SBCs with Tornado? Has it
>been a good dog or a bad dog for you?
>
Inside Technology (www.inside-usa.com) has a really interesting set of
Pentium-based PC/104 processors available in *half* slot sizes.  We've used
the Teknor products with good success as well.  The ones to avoid at all
possible cost are the Toronto Micro (TME) boards.  We've always have problems
whenever we've given these people a chance.  The last time, the SCSI
controller had the wrong frequency crystal and the board had the
wrong BIOS on it when it was shipped to us!  How can you screw
up an X86 for Pete's sake?  Well, these folks have it down to a fine
science ;-).
>*excuse* my ignorance
>-- now back to multi-processor support --
>Which bus architectures -- besides VME -- have multi-processor
>capabilities AND have a decent number of SBC vendors that currently
>support this feature??
>
The multiprocessor feature of VxWorks (I assume you mean SM) simply requires
a shared memory segment and a means to perform atomic TAS.  Real plusses
are availability of interrupts and/or mailboxes.  We've ported SM to
other bus architectures (like Sun's MBUS) with good success.  I suspect
that PCI bus (although a challenge) would probably be a good candidate.
Bus mastering on the ISA bus is a bit dodgy, but also a possibility.
Did you have any particular architechure in mind?
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."
==============================================================================
--MimeMultipartBoundary--
From mea@mclean.sparta.com  Wed Jul  2 05:45:20 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed Jul  2 05:45:23 PDT 1997
Subject: Re: VME References?
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Greetings!
  Another possibility are SPARTA's two VMEbus courses.  The first is a three
day course for software folks.  We cover the VME architecture, bus
arbitration, the VME interrupt cycle, ways to detect and fix arbitration
problems, why mailboxes are faster than VME interrupts, etc.  All using
VxWorks as the implementation mechanism to demonstrate the issues.
  The second course is a 4.5 day course for hardware folks.  We cover
the design of VMEbus boards, master/slave interfaces, addressing, the
various address/data cycles, etc.  We actually pick a popular interface
chip and flesh out a design based on that interface chip.  Check out our
website for details.
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."
==============================================================================
--MimeMultipartBoundary--
From rrajarajan@yurie.com  Wed Jul  2 06:38:23 1997
From: rrajarajan@yurie.com
Date: Wed Jul  2 06:38:26 PDT 1997
Subject: Timer handling problem
--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
In the code below, TaskA() creates a timer and connects
Tick() fn to the timer expiry and then enters an eternal
loop, blocking on messages.
TaskA() used to crash occasionally inside the eternal loop.
On further testing it was found that whenever the task was
the ready state and the timer expired, the register values
after Tick() returned were changed. It seemed to suggest
that the in the READY state the signal handler did not
restore the values of registers on return of control from
Tick().  This problem did not occur when TaskA was in the
PEND state while Tick processed the timer expiry.
Any clues to help   ?
void TaskA(void)
{
     /* create timer... */
     timer_create(,,)
     /* Specify the tick routine */
     timer_connect(,Tick,);
     /* Start the timer ... */
     timer_settime(,,,) ;
     while (msgQReceive()) {
          do_something ...
     }
}
VOID Tick( timer_t timerId, int arg )
{
     process timer expiry ...
}
--MimeMultipartBoundary--
From rich@immrc.eng.mcmaster.ca  Wed Jul  2 08:12:15 1997
From: rich@immrc.eng.mcmaster.ca (Richard Teltz)
Date: Wed Jul  2 08:12:18 PDT 1997
Subject: VME ref's
Mark,
I have a number of books that I have found.  The easiest to
get - and probably the most practical - is published by the
same group that publishes VMEbus Systems magazine.
The book is called "The VMEbus Systems Engineers Handbook".
It includes articles on C programming VME devices, TCP/
IP imlpementations, disk systems, etc, and includes the
VME and VXI bus standard...all for about $60.
If you get this magazine (its free to eng's) you should be
able to find the order form easily.  If not, email me directly
and I will dig up the info...within a day or so.
Best Regards
Rich
*------------------------------------------------------------------*
|  INTELLIGENT MACHINES AND MANUFACTURING RESEARCH CENTRE (IMMRC)  |
*------------------------------------------------------------------*
|       Richard Teltz,           | Dept. of Mechanical Engineering,|
|  principal research engineer,  | McMaster University,            |
|   tel: (905) 525-9140, x27351  | Hamilton, Ontario,              |
|   fax: (905) 572-7944          | Canada,                         |
| email: rich@immrc.mcmaster.ca  | L8S 4L7                         |
*------------------------------------------------------------------*
From YF.Siu@eng.efi.com  Wed Jul  2 10:11:37 1997
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Wed Jul  2 10:11:40 PDT 1997
Subject: Re:  Timer handling problem
>after Tick() returned were changed. It seemed to suggest
>that the in the READY state the signal handler did not
>restore the values of registers on return of control from
>Tick().  This problem did not occur when TaskA was in the
>PEND state while Tick processed the timer expiry.
>void TaskA(void)
>
>     /* create timer... */
>     timer_create(,,)
>
     /* Specify the tick routine */
>     timer_connect(,Tick,);
>
>     /* Start the timer ... */
>     timer_settime(,,,) ;
>
>     while (msgQReceive()) {
>          do_something ...
>     }
>}
>
>VOID Tick( timer_t timerId, int arg )
>{
>     process timer expiry ...
>}
>
We reported a very similar problem:
 TSR #: 30166
 SYNOPSIS OF PROBLEM     : signal sent to a task will corrupt the task context
       BSP 1: R4000
to WRS about a year ago. This happens to our Mips architecture.
It may happen to other RISCs as well but I'm not sure. CISC is
unlikely to cause this problem.
The cause of the problem is that the Mips ABI, like the ABI of
many other RISCs, defines the usage of the internal cpu registers:
a0-a3, s0-s8, t0-t9, etc. The t0-t9 temporarily registers are
not preserved across procedure calls. WRS's signal handler wrapper
uses sigCtxSave and sigCtxLoad to save and restore the context,
which are also used by setjmp/longjmp. Unfortunately, what they
did is just a 'half' context switch: the t0-t9 registers are
not saved/restored. This is acceptable in the setjmp/longjmp case
because they are synchronous function calls. But for asynchronous
signals, this will corrupt the task context.
To confirm the problem, try to disassemble the code in
'do_something' and see if they actually touch t0-t9 and/or
look at the code at sigCtxSave and see if t0-t9 were saved
properly.
Hope that helps,
YF
From ptp@mclean.sparta.com  Wed Jul  2 13:34:13 1997
From: "Patrick T. Pinkowski" <ptp@mclean.sparta.com>
Date: Wed Jul  2 13:34:15 PDT 1997
Subject: VME64 MBLT code for the MVME 2604
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am looking for some sample code to cause the Motorola MVME 2604 CPU to
perform VME64 MBLT transfers over the VME bus.  I suspect the code would
involve setting up the DMA controller on the Tundra Universe chip.
Thanks in advance.
Regards
Pat
--
--------------------------------------------------
      /\   Patrick T. Pinkowski, Senior Engineer
     /##\        ptp@mclean.sparta.com
    /####\         703.448.1683 x228
   /####/--
  /####/----    SPARTA, Inc.
 -\####\__---   7926 Jones Branch Drive, Suite 900
---\##\  /----  McLean, Virginia  22102
----\##\/\----  (703)448-0210 (Main)
 ----\####\--   (703)893-5494 (Facsimile)
  ----\####/    http://www.mclean.sparta.com
   ---/###/
    -/###/ SPARTA
     \##/  ~~~~~~
      \/   Pride In Performance
--MimeMultipartBoundary--
From mmcquade@aa.net  Wed Jul  2 14:30:40 1997
From: Mike McQuade <mmcquade@aa.net>
Date: Wed Jul  2 14:30:43 PDT 1997
Subject: mvme-2300 debug port
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hello,
Is anyone using the MVME-2301 board ?
We are trying to get the thing working, but cannot seem
to get anything out the serial (Debug) port, we use the 2600 boards
all the time, and have no problems with the serial port.
Just wanting to know if anyone had similar problems, connecting
the 2301 to a Unix box.
Motorola: Why did you change the serial port from the 2600 ?
Thanks.
--MimeMultipartBoundary--
From rtp.co.uk!ihw@rtp.co.uk  Thu Jul  3 00:32:54 1997
From: Ian Willats <ihw@rtp.co.uk>
Date: Thu Jul  3 00:32:57 PDT 1997
Subject: PC104 Pentiums
Ted Morris <tmorris@ziv.me.umn.edu> asked:
> Anyone out there know of a source that sells PC104 Pentium SBCs???
Not sure about Pentiums, but Megatel Corp (Canada) have 486 PC104s.  I
recently wrote a VxWorks (v5.2) BSP for their PCII/+i which should also
work with Tornado.  Worth contacting Megatel as they may be making it
available to the wider world - if not, drop me a line.
> Has it been a good dog or a bad dog for you?
As to its doggy nature, it seems pretty well-behaved.  But don't use it if
you're after the last word in network or SCSI performance - the hardware
for both interfaces comes under the heading of cheap and cheerful.
HTH,
Ian
----------------------------------------------------------------
Ian Willats                          E-mail:       ihw@rtp.co.uk
Real-Time Products Ltd.
Unit 8, Holt Court,                  Telephone: +44 121 333 6955
Aston Science Park,                  Fax:       +44 121 333 5433
Jennens Road,
Birmingham B7 4EJ. England.          Web:          www.rtp.co.uk
----------------------------------------------------------------
From daemon@csg.lbl.gov  Thu Jul  3 04:00:28 1997
From: daemon@csg.lbl.gov
Date: Thu Jul  3 04:00:31 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jul  3 04:00:25 PDT 1997
        Subject: IP modules on Greenspring VIPC616 carrier Board
        Subject: task restoration
-------------------------------------------------------
Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus
Subject: IP modules on Greenspring VIPC616 carrier Board
Date: 2 Jul 1997 19:33:09 GMT
From: "Denis PILLEUX" <dpilleux@worldnet.fr>
Organization: SCT / Worldnet - Internet Provider & Information Exchange - Paris, France
Message-ID: <01bc871e$53feafe0$101203c3@denis>
I'm trying to use an IP module from Ballard Technology : IP 1553-1
plugged on a VME slave carrier board : VIPC616 from GreenSpring.
This configuration don't work correctly, because the IP memory space
can't be accessed correctly if an access to the registers of the 1553
interface (UTMC SUMMIT XT) is performed (exchange memory and
registers of the SUMMIT are mapped into IP memory space).
Greenspring is the manufacturer of the carrier board, and the designer
of the IP modules Standard.
Asking GreenSpring about this problem, they answer that all theirs
Greenspring IP modules (including Greeenspring IP-1553 module which
works with another 1553 interface) are working correctly plugged on
the VIPC616 carrier board.
Asking Ballard Technlogy about this problem, they answer that their
IP 1553-1 module was only tested plugged on a VME 162 board.
I have already succesfully used the IP 1553-1 module from
Ballard Technology plugged on a VME 162 CPU board,
and on a PC104 HV05 carrier board.
I'm interested to know if someone has already used the IP 1553-1
module from Ballard Technology plugged on a VME slave carrier
board like GreenSpring VIPC616,
and if someone has already used others IP modules, using the
IP memory space, plugged on the GreenSpring VIPC616
carrier board.
Thanks for your answers.
---------------------------
Newsgroups: comp.os.vxworks
Subject: task restoration
Date: Wed, 02 Jul 1997 15:57:23 -0800
From: Sriram Sathyamoorthy <sriram@sohar.com>
Organization: SoHaR Incorporated
Message-ID: <33BAEAE3.1AC@sohar.com>
Hi,
	I would to like to know haw to save a task's state and restore the the
task to the saved state afterwards. If I use taskinfoget to get
the state and save the stack, I do not know which part of the stack
must be restored to the old state. I hope that this is a clearly framed
question. Thanks in advance to the person/people helping me out.
guni
---------------------------
End of New-News digest
**********************
From tony.mayes@tecra.it  Thu Jul  3 08:35:10 1997
From: tony.mayes@epid.eurotherm.co.uk
Date: Thu Jul  3 08:35:13 PDT 1997
Subject: Tornado 1.0.1 and WinNT 4.0
--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Hi all,
Is anyone else having problems with Tornado 1.0.1
on Windows NT 4.0?
We have some hang ups in the application whilst using the debugger.
Whilst sometimes this results in us having to kill Tornado and then
restart it, on other occassions it "Blue Screens" (crashes) NT!!!!!
We have tried it on NT 3.5 and crashes are less frequent although it
still hangs the debugger as often.
We have also tried on two different PC hardware platforms, one
crashes more than the other, both still have hang ups.
We have talked to WRS support re this but it seems difficult to pin
down.
BTW we dont get the crashes on V1.0 but the debugger has some
problems which was why it was recommended that we move to 1.0.1
 Any thoughts gratefully looked for.
Tony
Tony Mayes
Email address          tony.mayes@epid.eurotherm.co.uk
Phone 031 975243
Fax   031 977512
Eurotherm SpA,
Via XXIV Maggio, 22070 Guanzate (CO), Italy
(NOTE: The opinions expressed within are my
       own and are not necessarily  those
       of my employer)
--MimeMultipartBoundary--
From lenny@den.mcd.mot.com  Thu Jul  3 13:46:31 1997
From: lenny_bates <lenny@den.mcd.mot.com>
Date: Thu Jul  3 13:46:34 PDT 1997
Subject: RE: mvme-2300 debug port
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi Mike,
Both the 260x and the 230x boards use the National Semi PC16550 UART.
The only differences are that the 260x has two of them and the console is
supplied via a DB25 connector. The 230x is uses a RJ45.
Perhaps the problem is a wireing issue so here is the pin out for the
230x.
	1 - DCD
	2 - RTS
	3 - GND
	4 - TXD
	5 - RXD
	6 - GND
	7 - CTS
	8 - DTR
This is the same pin out that a MVME162LX used for it's Console. A typical cable
would be pined out as follows;
	DB25 DTE		RJ45 Jack
	DTR 20 ----------------------- 1
	CTS 5  ------------------------ 2
				3----|
	RXD 3 ------------------------- 4    |
	TXD 2 -------------------------- 5    | 3 & 6 shorted
	SG  7 -------------------------- 6----|
	RTS 4 -------------------------- 7
	DCD 8 -------------------------- 8
Hope this helps.
Lenny
lenny@den.mcd.mot.com
MCG - Denver
-----Original Message-----
From:	the vxWorks Users Group Exploder [SMTP:vxwexplo@lbl.gov]
Sent:	Wednesday, July 02, 1997 3:31 PM
To:	vxworks_users@csg.lbl.gov
Subject:	mvme-2300 debug port
Submitted-by mmcquade@aa.net  Wed Jul  2 14:30:40 1997
Submitted-by: Mike McQuade <mmcquade@aa.net>
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hello,
Is anyone using the MVME-2301 board ?
We are trying to get the thing working, but cannot seem
to get anything out the serial (Debug) port, we use the 2600 boards
all the time, and have no problems with the serial port.
Just wanting to know if anyone had similar problems, connecting
the 2301 to a Unix box.
Motorola: Why did you change the serial port from the 2600 ?
--MimeMultipartBoundary--
From Thomas.Arand@vs.siemens.de  Fri Jul  4 00:13:17 1997
From: "Arand, Thomas OEN BN EF3" <Thomas.Arand@vs.siemens.de>
Date: Fri Jul  4 00:13:21 PDT 1997
Subject: AW: Setting Tornado Environment Variables within a Makefile
Hi all,
thanks to all who have answered to my question (see below). The ansswers
helped me finding a satisfactory solution. As some of you told me that
they are also interested, I give a short summary of it:
At first, I forget to tell that I'm working with Tornado 1.0.1, where is
no more need to set the environment variable GCC_EXEC_PREFIX.
Second, make treats all macros defined inside a Makefile also as an
environment variable, if they have been in the environment at the time
of the make-call. Especially, make exports them to the environment when
shell commands are called (e.g. compiler calls). So if you set the
Variables WIND_BASE and WIND_HOST_TYPE before the call of make, you can
define new values for these variables (plus PATH) using simple macros.
The initial setting of the macros can be any arbitrary value.
Third, I use a two-step make procedure. The default target in the
Makefile issues a command which sets the environment variables WIND_BASE
and WIND_HOST_TYPE and then calls make again. I use three different
sub-Makefiles (target-dependend), which set the appropriate environment.
Below I show some details of the Makefiles:
########################################################################
##
#	contens of Makefile
########################################################################
##
TARGET_ARCH = none		//will be redefined at second call of
make
include Makefile.${TARGET_ARCH}	//includes Makefile.none at first call
					// includes target specific
makefile at second call
					// e.g. Makefile.PPC
all: ld_sim ld_ppc ld_x86
	@continue
ld_ppc:
	@WIND_BASE="" WIND_HOST_TYPE="" make ld.oPPC TARGET_ARCH=PPC
ld_sim:
	@WIND_BASE="" WIND_HOST_TYPE="" make frs.oSIM TARGET_ARCH=SIM
frs.o${SUFFIX}: $(OBJECTS)
	...	// commands how to build ld.oPPC resp. ld.oSIM
########################################################################
##
#	contens of Makefile.PPC
########################################################################
##
WIND_BASE 	= ...		// host-specific settings for PowerPC
target
WIND_HOST_TYPE	= ...	// host-specific settings for PowerPC target
PATH		= ...		// host-specific settings for PowerPC
target
SUFFIX = PPC
########################################################################
##
#	contens of Makefile.SIM
########################################################################
##
WIND_BASE 	= ...		// host-specific settings for VxSim
target
WIND_HOST_TYPE	= ...	// host-specific settings for VxSim target
PATH		= ...		// host-specific settings for VxSim
target
SUFFIX = SIM
########################################################################
##
#	Makefile.none is an empty file
########################################################################
##
Hope that helps.
Ciao,
	Thomas Arand
> ----------
> Von: 	vxwexplo@lbl.gov[SMTP:vxwexplo@lbl.gov]
> Gesendet: 	Dienstag, 1. Juli 1997 10:17
> An: 	vxworks_users@csg.lbl.gov
> Betreff: 	Setting Tornado Environment Variables within a Makefile
>
> Submitted-by Thomas.Arand@vs.siemens.de  Tue Jul  1 01:17:14 1997
> Submitted-by: "Arand, Thomas OEN BN EF3" <Thomas.Arand@vs.siemens.de>
>
> Hi all,
>
> I'm trying to build a Makefile that allows to create applications for
> different target architectures. As the WRS sources for these
> architectures reside in different directory tries, I have to set the
> Environment (WIND_BASE, PATH, etc) depending on the target. I do not
> (!)
> want to set them outside the Makefile (i.e. before the make-call).
>
> What happens if I simply set make-macros, is an error when the
> compiler
> is called (cpp: invalid option '-lang-c++'). the reason seams to be
> that
> the compiler internally calls other programs (cpp), with a wrong
> environment.
>
> Does anyone have an idea how I can achieve this?
>
> Thanks and Ciao,
>
> 	Thomas Arand
>
>
From daemon@csg.lbl.gov  Fri Jul  4 04:00:44 1997
From: daemon@csg.lbl.gov
Date: Fri Jul  4 04:00:47 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jul  4 04:00:41 PDT 1997
        Subject: Re: MPMC202 Fast Ethernet Adapter
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: MPMC202 Fast Ethernet Adapter
Date: Thu, 03 Jul 1997 22:01:19 GMT
From: mmcquade@aa.net (Mike)
Organization: Alternate Access Inc.
Message-ID: <33bc205d.1277781@news.aa.net>
References: <33BC204E.3B67@postal.essd.northgrum.com>
Firstname Lastname <Lastname.F.M@postal.essd.northgrum.com> wrote:
>Hello fellow VxWorkers:
>
>	I am using a Motorola 1603 VME card with a native ethernet port and
>wish to add a second ethernet port using the MPMC202 card on the PCI
>adapter bus.  Vxworks says they don't support this card or a second
>ethernet port at all.  Does anybody out there support this or have any
>ideas on this ?
>
I believe that the MPMC 202 is just a RMS 2350 PMC cards, we used
these cards with the 1603/4 boards.
We got the cards from Ross Micro Systems, their driver was very good,
performance was excellent, I was able to measure 7.12 Mbytes / Second
from a 1604 (133Mhz) to an HP C110 machine, running the TCP/Blaster
code.
Yuo can reach Ross Micro Systems at:
rmi@qed.net
Mike.
---------------------------
End of New-News digest
**********************
From nts6joli@rhds01.RZ.FHT-Esslingen.DE  Fri Jul  4 04:20:50 1997
From: Jochen Linkohr <nts6joli@rz.fht-esslingen.de>
Date: Fri Jul  4 04:20:53 PDT 1997
Subject: Re: Tornado 1.0.1 and WinNT 4.0
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello ,
the vxWorks Users Group Exploder wrote:
> Is anyone else having problems with Tornado 1.0.1
> on Windows NT 4.0?
Hmm, we've got 1.0 running here but there are problems, too :-(
> We have some hang ups in the application whilst using the debugger.
> Whilst sometimes this results in us having to kill Tornado and then
> restart it, on other occassions it "Blue Screens" (crashes) NT!!!!!
Well, the 1.0 under NT 4.0 WS does not crash the system here, but it
slows it down. On the PPro 200 w/ 64 MB RAM it takes up to one minute to
switch from one to another window, therefore the debugger is useless...
Greets
  Jochen
--
   ____      _____________________________________________________
       / /   LineMelterSystem 71404 Korb-Steinreinach im Remstal
      / /   Jochen Linkohr, Gernet - 21:492/330 FIDO - 2:246/1330
     / /      jl@lms.wn.bawue.de, nts6joli@rz.fht-esslingen.de
    / /            <http://home.pages.de/~linkohr>
/__/ /___  ____________________________________________________
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Mon Jul  7 04:00:30 1997
From: daemon@csg.lbl.gov
Date: Mon Jul  7 04:00:33 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jul  7 04:00:26 PDT 1997
        Subject: MVME-1604 accessing VME A32 slaves in upper 2 Gig
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: MVME-1604 accessing VME A32 slaves in upper 2 Gig
Date: Tue, 24 Jun 1997 13:11:28 -0500
From: John Fusco <john.fusco@med.ge.com>
Organization: GE Medical Systems
Message-ID: <33B00DD0.41C6@med.ge.com>
Does anyone have experience with the 1604 in mapping a VME A32 slave
board into an address above 0x80000000?
WindRiver has a technote on how to do this, but they tell me it is
untested and unsupported.
I was hoping that someone in this group may have done this already and
could pass along their experience.
Thanks in advance.
John Fusco
---------------------------
End of New-News digest
**********************
From Rkane@encanto.com  Mon Jul  7 13:09:06 1997
From: Robert Kane <Rkane@encanto.com>
Date: Mon Jul  7 13:09:09 PDT 1997
Subject: RE: Tornado 1.0.1 and WinNT 4.0
--MimeMultipartBoundary
Content-Type: text/plain
Tony,
We have been experiencing occasional lockups using it with Window95.
Occasionally, and for no reason that we can as yet determine, we find
ourselves rebooting both the target and the host.  This is probably
entirely our fault, it is unimaginable that
WRS code release code with bugs in it.  ;-)
Robb
> -----Original Message-----
> From:	vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov]
> Sent:	Thursday, July 03, 1997 8:35 AM
> To:	vxworks_users@csg.lbl.gov
> Subject:	Tornado 1.0.1 and WinNT 4.0
>
> Submitted-by tony.mayes@tecra.it  Thu Jul  3 08:35:10 1997
> Submitted-by: tony.mayes@epid.eurotherm.co.uk
>
>
> Hi all,
>
> Is anyone else having problems with Tornado 1.0.1
> on Windows NT 4.0?
>
> We have some hang ups in the application whilst using the debugger.
> Whilst sometimes this results in us having to kill Tornado and then
> restart it, on other occassions it "Blue Screens" (crashes) NT!!!!!
>
> We have tried it on NT 3.5 and crashes are less frequent although it
> still hangs the debugger as often.
>
> We have also tried on two different PC hardware platforms, one
> crashes more than the other, both still have hang ups.
>
> We have talked to WRS support re this but it seems difficult to pin
> down.
>
> BTW we dont get the crashes on V1.0 but the debugger has some
> problems which was why it was recommended that we move to 1.0.1
>
>  Any thoughts gratefully looked for.
>
>
>
> Tony
>
>
>
>
> Tony Mayes
>
> Email address          tony.mayes@epid.eurotherm.co.uk
>
> Phone 031 975243
> Fax   031 977512
>
> Eurotherm SpA,
> Via XXIV Maggio, 22070 Guanzate (CO), Italy
>
--MimeMultipartBoundary--
From cruz@xyplex.com  Mon Jul  7 14:21:00 1997
From: Roger Cruz <cruz@xyplex.com>
Date: Mon Jul  7 14:21:03 PDT 1997
Subject: Re: pci ethernet 100base-t
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It was no minor tweaking.  It took me two weeks to finally get it to
work on an Intel based motherboard.  The most important thing was that
the driver was written for a big endian machine, which Intel is not.
You have to go through the code and use the appropriate macros.  Some
areas that I remember are the ethernet address and the frame format type
in the output procedure.  It also has a few bugs.  The most important
one that took me a long time to figure out is that the driver did not
reset the chip after it changed a bit in CSR6 as the spec calls for.
The code worked in some machines but not in others.  It was hell to find
out that this was the problem.  One more thing that you'll need to add
is the PHY interface.  There was no code there.
> You might want to look into NICs based on DEC's DC21140 chip. There
> are plenty of such cards and a Tornado driver is available from WRS.
> I think the driver is unsupported but you can get it to work after
> some minor tweaking.
--
Roger Cruz                           cruz@xyplex.com
Xyplex Networks                      w: 508-952-4783
295 Foster Street                    f: 508-952-4887
Littleton, MA 01460
--MimeMultipartBoundary--
From mfischer@qualcomm.com  Tue Jul  8 15:38:57 1997
From: Mark Fischer <mfischer@qualcomm.com>
Date: Tue Jul  8 15:39:00 PDT 1997
Subject: 24 bit addressing and EABI
In Appendix F (PPC'isms), p.602 of the Programmer's Reference Guide:
"The PowerPC architecture limits its relative addressing to 24-bit
offsets to conform to the EABI (Embedded Application Binary Interface)
standard."
Does anyone know if this restriction can be "turned off" or otherwise
affected somehow in VxWorks?
Cheers,
Mark Fischer
Qualcomm, Inc.
From daemon@csg.lbl.gov  Wed Jul  9 04:00:35 1997
From: daemon@csg.lbl.gov
Date: Wed Jul  9 04:00:38 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jul  9 04:00:30 PDT 1997
        Subject: VxWorks drivers PCMCIA harddrive/interface
        Subject: !!!Hello!!!
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks drivers PCMCIA harddrive/interface
Date: 8 Jul 1997 15:40:51 GMT
From: schuehle@t-online.de (Martin Sauter)
Organization: Telekom Online Internet Gateway
Message-ID: <5ptn23$u9n$1@news00.btx.dtag.de>
Reply-To: sauter@fl-sun00.fbe.fh-weingarten.de
Hi everybody,
I am looking for a PCMCIA hardware interface for the PC-104 bus to
attach a PCMCIA hard drive to a x86 board which is running VxWorks. Does
anyone know a company that offers such hardware and the necessary
VxWorks drivers?
Thanks in advance
Martin
- --
- --------------------------------------------------------------------
My World Wide Web Sites:
The Solar Car project  :  http://ti-voyager.fbe.fh-weingarten.de/set
About studying abroad  :  http://ti-voyager.fbe.fh-weingarten.de/tac
- --------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: !!!Hello!!!
Date: 7 Jul 97 09:32:42 GMT
From: Damn Yankee<damnyankee@yankee.inc>
Organization: Yankee Inc.
Message-ID: <33c0b7ba.2@nntp.kalnet.net>
Are you looking for a great place to find interesting things on the WWW??? Than look no more because you have found the right place!!! The place you are looking for is Yankee Inc.!!! A great Web Site full of interesting links to interesting places!!! Everything from Adult to Xzlyaphone it's here!!! There is something for everyone and then some!!!  So give it a try what do you have to lose except some sleep??? Yankee Inc. http://www.kalnet.net/yank714
Yankee Inc. Your Alternative Web Solution!!!
Yankee Inc.
http://www.kalnet.net/yank714
If you would like to be removed from my mailing list - hit reply and type "REMOVE" and I will promptly remove you from my list!!! Thank You!!!
---------------------------
End of New-News digest
**********************
From eckardt.suzanne@hqgate.orbital.com  Wed Jul  9 05:57:42 1997
From: "Eckardt.Suzanne"<eckardt.suzanne@Orbital.COM>
Date: Wed Jul  9 05:57:44 PDT 1997
Subject: GNU Compiler/Linker Memory Allocation
--MimeMultipartBoundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
     We're building code for an embedded 68302 target, and we've noticed
     some unexpected memory allocations for data items.  The following data
     items were declared at the top of a source file:
     static unsigned char static1[17];
     unsigned char non1[17];
     static unsigned char static2[18];
     unsigned char non2[18];
     unsigned char non3[22];
     After compiling the source file, the nm utility showed the following
     sizes for the data items:
     static1 - 24
     non1    - 18
     static2 - 20
     non2    - 18
     non3    - 22
     After performing a fully resolved link of all our objects, the nm
     utility showed the following sizes for the data items:
     static1 - 24
     non1    - 20
     static2 - 20
     non2    - 20
     non3    - 24
     We don't specify any special alignments in our compile or link
     scripts.  Why are our data items being padded?  Why does the static
     declaration affect the data size?  Why do the sizes change from
     compile to link?  Any insight would be appreciated!
     Thanks,
     Suzie
     -------------------------------------------------------------------
     - Suzie Eckardt, Principal Software Engineer
     - Orbital Sciences Corp.      email: eckardt.suzanne@orbital.com
     - 21700 Atlantic Blvd.        Phone: 703-406-5478
     - Dulles, VA  20166           Fax:   703-406-5553
     -------------------------------------------------------------------
--MimeMultipartBoundary--
From Chris_Nickles@ATK.COM  Wed Jul  9 07:18:36 1997
From: Chris_Nickles@ATK.COM (Chris Nickles)
Date: Wed Jul  9 07:18:43 PDT 1997
Subject: Re: comp.os.vxworks newsdigest
REMOVE
From cgrames@mail.mdc.com  Wed Jul  9 07:43:10 1997
From: Charlie Grames <cgrames@mail.mdc.com>
Date: Wed Jul  9 07:43:13 PDT 1997
Subject: 24 bit addressing and EABI -Reply
Mark,
We have researched this issue to death.  The EABI specifies that all direct routine linkage use the
bl instruction, which has a 24-bit word offset.  This effectively forces all text sections to exist in the
first 32 MB of memory.
We got around this problem with the Green Hills compilers by specifying a "far calls" option which
generates branch-and-link code without restrictive offset limits.  I would be surprised if the GNU
compiler did not provide a similar option, but I have not researched it.  Otherwise, the workaround
is to configure only the first 32 MB of memory with LOCAL_MEM_SIZE and the remaining with
USER_RESERVED_MEM (both in config.h).  After booting, load your objects and use
memAddToPool to add the reserved memory to the memory pool.
Beware that any third-party objects you use will probably conform to the EABI and, therefore, must
be loaded in the first 32 MB of memory.
Hope this helps.
Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com
>>> vxwexplo@lbl.gov@slsmtp 07/08/97 05:39pm >>>
Submitted-by mfischer@qualcomm.com  Tue Jul  8 15:38:57 1997
Submitted-by: Mark Fischer <mfischer@qualcomm.com>
In Appendix F (PPC'isms), p.602 of the Programmer's Reference Guide:
"The PowerPC architecture limits its relative addressing to 24-bit
offsets to conform to the EABI (Embedded Application Binary Interface)
standard."
Does anyone know if this restriction can be "turned off" or otherwise
affected somehow in VxWorks?
Cheers,
Mark Fischer
Qualcomm, Inc.
From Chris_Nickles@ATK.COM  Wed Jul  9 08:54:59 1997
From: Chris_Nickles@ATK.COM (Chris Nickles)
Date: Wed Jul  9 08:55:02 PDT 1997
Subject: Re: comp.os.vxworks newsdigest
Well, I was trying to get off somebody's junk mail list and here
comes my 'REMOVE' request back over the exploder.  Sorry about
that!!
	Chris Nickles
From mmajka@cs5.dasd.honeywell.com  Wed Jul  9 09:30:28 1997
From: Matt Majka <mmajka@cs5.dasd.honeywell.com>
Date: Wed Jul  9 09:30:31 PDT 1997
Subject: Ada-aware GDB from Tornado sources
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I was wondering if anyone has experience with rebuilding GDB from the
sources provided with Tornado/VxWorks.  I need to patch the version of
GDB for powerpc-wrs-vxworks to make it Ada-aware (using the patch(es)
from
ACT) and was wondering if anyone has been successfull in doing this.  If
this is in a FAQ or list archive, please point me in that direction.
Thanx in advance,
--
__________________________________
Matt Majka
Honeywell Defense Avionics Systems
Albuquerque, New Mexico, USA
--MimeMultipartBoundary--
From bawilson@llnl.gov  Wed Jul  9 11:52:01 1997
From: "Bruce A. Wilson" <bawilson@llnl.gov>
Date: Wed Jul  9 11:52:03 PDT 1997
Subject: 400 nsec delay on mv1603
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hello,
	I'm looking for some advice on implementing short delays on a
mv1603 board.   I thought I'd use a simple
__asm__("nop;nop;nop;....nop"::); statement, with 40 nops, to get 400 nsec
delays.  I think each nop takes 10 nsec on a 100 MHz processor.  Is there
something special I need to do to make sure the 40 nops get executed, and
not optimized away, or somehow skipped?
Could anyone suggest a better way to code a short delay ( e.g. 400
nanoseconds ) on a mv1603 processor?
Bruce A. Wilson
U.C. LLNL   ( L-054 )
P.O. Box 808
Livermore, CA  94550
--MimeMultipartBoundary--
From bawilson@llnl.gov  Wed Jul  9 14:26:49 1997
From: "Bruce A. Wilson" <bawilson@llnl.gov>
Date: Wed Jul  9 14:26:52 PDT 1997
Subject: Re: 400 ns delay on mv1603
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hello again,
	It says in the GNU ToolKit User's Guide that "GNU CC does not
delete 'empty' loops..."  Therefore, I can use a simple c-coded empty loop
to obtain my timing delay.  I was planning to use the __asm__ feature to
avoid getting optimized away, but now I see that's not necessary.
	I get my 400 nanosecond delay quite simply, and reliably with the
macro written as "#define DELAY {register int m; for (m=0; m<16; m++); }".
Bruce A. Wilson
U.C. LLNL   ( L-054 )
P.O. Box 808
Livermore, CA  94550
--MimeMultipartBoundary--
From mmcquade@aa.net  Wed Jul  9 15:18:10 1997
From: Mike McQuade <mmcquade@aa.net>
Date: Wed Jul  9 15:18:13 PDT 1997
Subject: Re: 400 nsec delay on mv1603
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 11:52 AM 7/9/97 PDT, you wrote:
>Submitted-by bawilson@llnl.gov  Wed Jul  9 11:52:01 1997
>Submitted-by: "Bruce A. Wilson" <bawilson@llnl.gov>
>
>Could anyone suggest a better way to code a short delay ( e.g. 400
>nanoseconds ) on a mv1603 processor?
>
We have used the microsecond timers on both the 1603 and 2603 boards, for
small delays.
I think to get smaller delays, you might be able to use the PPC decrementer.
Mike.
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Thu Jul 10 04:01:00 1997
From: daemon@csg.lbl.gov
Date: Thu Jul 10 04:01:02 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jul 10 04:00:55 PDT 1997
        Subject: wlmd and Tornado 1.0.1
        Subject: task stack
        Subject: Re: Is VxWorks on Mars?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: wlmd and Tornado 1.0.1
Date: 8 Jul 1997 16:48:45 -0400
From: hodapp@nvl.army.mil (John Hodapp)
Organization: U.S. Army Night Vision & Electronic Sensors
Message-ID: <5pu93d$15d$1@opus.nvl.army.mil>
Greetings fellow vxusers...
Was wondering if anyone out there has discovered a solution to the following
problem:
I am upgrading from Tornado 1.0 to Tornado 1.0.1 (mv2604 BSP), using Solaris
2.5.1 as my host OS. My problem is that I receive the following error message
from wlmd when it is started:
"97-Jun-02 11:30:34: System clock has been set back too far!. WLMD Terminated."
In discussions with WRS, the current fix for this problem is to delete the
file: /usr/adm/wtmp. It seems that wlmd does some checking with this file and if
it does not exist, wlmd goes about its business normally. I did not have this
problem with Tor v1.0, as 1.0 uses flexlm, which was changed to wlmd in 1.0.1
Unfortunately, deleting /usr/adm/wtmp is not an option at my facility,
as various sysadmin things also use that file here.
So, to make a long story short, has anyone else stumbled across this problem and
found a solution *other* than deleting /usr/adm/wtmp ? I'd prefer to keep the
license mgr on the unix side of the house (don't have a NT box handy to run
it on either...)
Thanks in advance,
John
- --
US ARMY CECOM RDEC NVESD			 Comm: (703) 704-3283
AMSEL RD NV S&T                                  DSN:        654-3283
10221 Burbeck Road Suite 430
Ft. Belvoir, VA  22060 5806                      EMail: hodapp@nvl.army.mil
---------------------------
Newsgroups: comp.os.vxworks
Subject: task stack
Date: Mon, 30 Jun 1997 09:21:26 -0800
From: Sriram Sathyamoorthy <sriram@sohar.com>
Organization: SoHaR Incorporated
Message-ID: <33B7EB16.6F9A@sohar.com>
Is there a way to access the stack of a task (stack pointer, stack size,
etc.) from within a program? That is, I want to do the same function
as TaskShow(), but from within a program
thanks  in advance
sriram
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is VxWorks on Mars?
Date: Wed, 09 Jul 1997 22:46:08 -0700
From: John Kevin Fabiani <johnx@wrs.com>
Organization: Wind River Systems
Message-ID: <33C47720.25A8C349@wrs.com>
References: <33c12cc7.10369094@nntp.ix.netcom.com> <33C1D326.3314@worldnet.att.net>
Reply-To: johnx@wrs.com
Demyn Plantenberg wrote:
>
> Robert Smith wrote:
> >
> > Hey, I seem to remember a presentation on something resembling a Mars
> > Rover at the west coast user's group meeting a couple of years ago.
> > Is this the OS on the vehicle that is rolling around up there on Mars?
>
> According to our WRS rep, VxWorks was not used on the rover, but was the
> RTOS of choice for the rest of the mission.  The rover used a custom OS,
> "a simple application" I am told.
The rover does not use a 32bit chip.  8bit, I believe..
>
> Demyn.
---------------------------
End of New-News digest
**********************
From sandip@arraycomm.com  Thu Jul 10 08:47:04 1997
From: Sandip Patel <sandip@arraycomm.com>
Date: Thu Jul 10 08:47:15 PDT 1997
Subject: PPP and VxWorks
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
	I'm trying to get the free version of PPP(v 2.2e) developed by Don
Brooks et. al working on our PowerPC based platform - we're running
VxWorks 5.3. The PPP link establishes without any problems (eg. between
a PC running Windows95 and our platform). However, when I send any IP
packets over the PPP link, the platform just freezes up eg. using the
ping command from windows and pinging the platform.  Any ideas as to
where to look for the problem - i'm sure it's in the PPP code and
wondered if anyone else was using this free version of PPP and if they
had encountered a similar problem.
--MimeMultipartBoundary--
From jshaw_shade@compuserve.com  Thu Jul 10 09:02:34 1997
From: John Shaw <jshaw_shade@compuserve.com>
Date: Thu Jul 10 09:02:37 PDT 1997
Subject: MIL-STD-1553 for MVME-162 and VxWorks 5.2
--MimeMultipartBoundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Between August 96 and July 97 there have been three or so references to
MIL-STD-1553. These are listed below:-
        Bill Bjorkman (DDC 65522 board, MVME-167 and VxWorks 5.2)
        Alan Currie (specific details not known)
        Denis Pilleux (Ballard Technology IP 1553-1, MVME-162,
        PC104 HV05 carrier)
We need MIL-STD-1553 hardware that satisifies the following requirements:=
-
        integration with MVME-167 or MVME-162 running VxWorks 5.2
        (or optionally MVME-1603 PowerPC) with driver or other software
        good technical support from suppliers (in the UK if possible)
        reliable operation, trouble free software
        hardware configurable to be Bus Controller, RT or BM
        test and simulation capabilities
        complete message programmability
        extensive error injection / detection
Any recommendations will be greatly appreciated. If there is a card that
slots
into the VME as a stand-alone (without being tied to a processor card) th=
en
details on such cards would also be appreciated.
Thanks in advance.
John Shaw,
Shade (Computer Services) Ltd., England, UK.
email: jshaw_shade@compuserve.com
--MimeMultipartBoundary--
From jwc@ssd.ray.com  Thu Jul 10 10:09:40 1997
From: Cosgrove <jwc@ssd.ray.com>
Date: Thu Jul 10 10:09:43 PDT 1997
Subject: Re: MIL-STD-1553 for MVME-162 and VxWorks 5.2
John Shaw <jshaw_shade@compuserv.com> writes:
> We need MIL-STD-1553 hardware that satisifies the following requirements:
John,
It's not a UK company (it may even have been bought out) but I used board with
the required functions (I used it under OS-9, but they boasted VxWorks support).
The board was from DTI (Digital Technologies, Inc. [I think]) in Ohio, USA.
I don't remember the model, but I could get it if needed.  We only bought one,
about 1991 timeframe...
Hope this helps,
John Cosgrove
Raytheon
(401)842-4167 (desk)
(401)842-3511 (lab)
jwc@ssd.ray.com
From ABBOTTD@CEBAF.GOV  Thu Jul 10 10:22:14 1997
From: ABBOTTD@CEBAF.GOV
Date: Thu Jul 10 10:22:17 PDT 1997
Subject: MV2604 Network Problem
--MimeMultipartBoundary
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
       I am having a problem with a MVME2604 (w/ 761 transition module)
that prehaps someone out there has seen before, and if I have to wait
for WRS to help me I will be old and grey.
     I am using Tornado 1.0.1 and the BSP 1.1/2 complete with this
"MEGA" patch from WRS. When I attempt to boot over the network. As
soon as the dcattach() routine is called to start up the ethernet
driver its seems to be hanging up the hardware so that no packets
can be sent or received. However, if I unplug the twisted pair cable
from the hub, wait for dcattach to be called, tNetTask to complain
of "No Carrier", then plug the cable back in again, everthing is fine.
Of course I have to go through this process twice every time I boot.
First when the BootKernel calls dcattach to download the Kernel proper,
and second, when the main kernel attaches the network driver.
    At first I suspected that there is a hardware problem with the
board, but the fact that the network interface runs fine once it is
booted makes me wonder whether there is some other flag to set in the
arguments to dcattach().
                                  Thanks in advance for
                                  any suggestions
                                  David Abbott
                                  TJNAF
                                  12000 Jefferson Ave
                                  Newport News, VA, 23606
                                  EMAIL: abbottd@jlab.org
--MimeMultipartBoundary--
From stan@rti.com  Thu Jul 10 11:28:17 1997
From: stan@rti.com (Stan Schneider)
Date: Thu Jul 10 11:28:19 PDT 1997
Subject: Re: Is VxWorks on Mars?
>> Demyn Plantenberg wrote:
>> >
>> > Robert Smith wrote:
>> > >
>> > > Hey, I seem to remember a presentation on something resembling a Mars
>> > > Rover at the west coast user's group meeting a couple of years ago.
>> > > Is this the OS on the vehicle that is rolling around up there on Mars?
>> >
>> > According to our WRS rep, VxWorks was not used on the rover, but was the
>> > RTOS of choice for the rest of the mission.  The rover used a custom OS,
>> > "a simple application" I am told.
>>
>> The rover does not use a 32bit chip.  8bit, I believe..
The presentation was on Marzokhod, a different (Russian) designed rover.  The
rover on Mars is a JPL design.  At JPL, the rover was called "Rocky 4" (I think
the PR department renamed it Sojourner).  Of course, Rocky 4 was built long
ago.  They're now working on Rocky 7; it's not as simple, and it is running
VxWorks (and RTI's ControlShell, if you'll excuse the plug :-) ).
        -- Stan
           stan@rti.com
From randy@opid.littondsd.com  Thu Jul 10 11:59:30 1997
From: randy@opid.littondsd.com (Randy Ryan)
Date: Thu Jul 10 11:59:34 PDT 1997
Subject: Re: MIL-STD-1553 for MVME-162 and VxWorks 5.2
We just got a Radstone 1553 card, VxWorks 5.2, MV-167 support.  It just came in
and I haven't had an opportunity to look at it in detail, but thought I would
at least let you know about it so you can research it.
Check their site at http://www.radstone.com
Randy
From RAtkin@EMAIL.CTA-SPACE.COM  Thu Jul 10 14:25:48 1997
From: RAtkin@EMAIL.CTA-SPACE.COM (Robert Atkin)
Date: Thu Jul 10 14:25:51 PDT 1997
Subject: Re: MIL-STD-1553 for MVME-162 and VxWorks 5.2
--MimeMultipartBoundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
     John,
     I have used an Excalibur vme board (EXC-1553VME/MCHx) which uses the
     UTMC SuMMIT chipset. It can handle up to 8 dual-redundant channels.
     The chipset is very easy to use, and the board is not tied to a
     processor. I wrote a driver for it in very short order.
     I hope this helps. You can contact me directly if you would like more
     information.
     Rob Atkin
     Senior Systems Engineer
     CTA Space Systems
     1521 Westbranch Drive
     McLean, VA 22102
     (703)883-2634
     ratkin@email.cta-space.com
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Fri Jul 11 04:00:24 1997
From: daemon@csg.lbl.gov
Date: Fri Jul 11 04:00:27 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jul 11 04:00:20 PDT 1997
        Subject: VxWorks on NT
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks on NT
Date: 11 Jul 1997 08:03:04 +1200
From: Sarir Khamsi <khamsi@ll.mit.edu>
Organization: MIT Lincoln Laboratory
Message-ID: <uhge2isjr.fsf@kmrmail.kmr.ll.mit.edu>
Sender: khamsi@SYSENGWWW
Yo,
We are looking at replacing some UNIX boxes that hosted VxWorks with
NT boxes. I know almost nothing about VxWorks or this
environment. Does anyone have an evaluation of these two environments
and/or a feature list? Thanks.
Sarir
- --
Sarir "Riri" Khamsi
RAYTHEON Range Systems Engineering
Kwajalein, Marshall Islands
email: khamsis@kmrmail.kmr.ll.mit.edu
w: 805-355-1534
Time Zone: GMT +12 hours
---------------------------
End of New-News digest
**********************
From jwc@ssd.ray.com  Fri Jul 11 04:24:42 1997
From: Cosgrove <jwc@ssd.ray.com>
Date: Fri Jul 11 04:24:45 PDT 1997
Subject: PPC mvme1604/Interrupts Local & VME
Hi, Folks,
Has anyone out read something I haven't about the interrupt structure/processing
of the mvme1604?
I have a system with a mvme1604 (to be replaced with a 2604 soon) and 2 Quad PPC
boards (doing DSP type work).  The vendor of the Quad boards has not given me the
ability to generate a VMEbus interrupt under their operating system.
I was using the GCSR SIG0 to interrupt Vx and the ISR received the VMEbus level
and vector from the Quad Boards in the GCSR GP Registers.  I then would generate
the VMEbus interrupt with sysBusIntGen from within that ISR.
Each Quad Board use of this was preceded by a check of the SIG0 bit to prevent
overwrite of a previously pending "request".
I found that I could "overwrite" requests even though I was checking the SIG0 bit
if the interrupt request were close enough togeter.
Before someone asks, the Quad boards used a semaphore to control one at time access
to the GCSR registers...
Any thoughts or experience is helpful.
Thanks
John Cosgrove
Raytheon
(401)842-4167 (desk)
(401)842-3511 (lab)
jwc@ssd.ray.com
From PopeyeMan@aol.com  Fri Jul 11 05:35:02 1997
From: PopeyeMan@aol.com
Date: Fri Jul 11 05:35:05 PDT 1997
Subject: Re: GNU Compiler/Linker Memory Allocation
remove me from the mailing list.
From laksh@pvdsw.amat.com  Fri Jul 11 23:33:34 1997
From: laksh@pvdsw.amat.com (Laksh Karuppiah x33230)
Date: Fri Jul 11 23:33:38 PDT 1997
Subject: AMD79C970 PCI ethernet chip
Has anyone used the driver if_lnPci.c with x86/PCI based paltform . We are currently trying to use it on a vme pentium board and the driver hangs up - get framming errors , missed packets, etc. Thanks in advance any response.
From daemon@csg.lbl.gov  Sat Jul 12 04:00:25 1997
From: daemon@csg.lbl.gov
Date: Sat Jul 12 04:00:29 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jul 12 04:00:21 PDT 1997
        Subject: Re: VxWorks on NT
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks on NT
Date: Fri, 11 Jul 1997 08:27:06 -0500
From: Doug Lewis <d-lewis3@ti.com>
Organization: Texas Instruments Defense Systems
Message-ID: <33C634AA.2CFA@ti.com>
References: <uhge2isjr.fsf@kmrmail.kmr.ll.mit.edu>
Reply-To: d-lewis3@ti.com
Sarir Khamsi wrote:
> We are looking at replacing some UNIX boxes that hosted VxWorks with
> NT boxes. I know almost nothing about VxWorks or this
> environment. Does anyone have an evaluation of these two environments
> and/or a feature list? Thanks.
>
I don't have first hand experience with the Unix version of Vxworks but
I have been working with Tornado 1.0.1 on NT4.0.  I'm not that impressed
with the tool on NT.  Some of the engineers I work with have used the
Unix version and say that they'd rather have the Unix version of the
tools.  It really seems that the NT version is a clug of the Unix tools.
I realize this isn't hard data, but I don't have any data for that yet,
just going with my impressions.
Doug
---------------------------
End of New-News digest
**********************
From daemon@csg.lbl.gov  Sun Jul 13 04:01:34 1997
From: daemon@csg.lbl.gov
Date: Sun Jul 13 04:01:36 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jul 13 04:01:27 PDT 1997
        Subject: Re: Is VxWorks on Mars?
        Subject: Re: MKS and Tornado
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is VxWorks on Mars?
Date: Mon, 07 Jul 1997 22:42:02 -0700
From: Demyn Plantenberg <demyn@worldnet.att.net>
Organization: AT&T WorldNet Services
Message-ID: <33C1D326.3314@worldnet.att.net>
References: <33c12cc7.10369094@nntp.ix.netcom.com>
Reply-To: demyn@worldnet.att.net
Robert Smith wrote:
>
> Hey, I seem to remember a presentation on something resembling a Mars
> Rover at the west coast user's group meeting a couple of years ago.
> Is this the OS on the vehicle that is rolling around up there on Mars?
According to our WRS rep, VxWorks was not used on the rover, but was the
RTOS of choice for the rest of the mission.  The rover used a custom OS,
"a simple application" I am told.
Demyn.
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: MKS and Tornado
Date: Sun, 13 Jul 1997 02:41:20 -0600
From: davidm@ComponentSoftware.com
Organization: Deja News Usenet Posting Service
Message-ID: <868779300.26006@dejanews.com>
References: <01bc8c74$fe77f2a0$3d6ec4cf@mblack.clark.net>
In article <01bc8c74$fe77f2a0$3d6ec4cf@mblack.clark.net>,
  "Mitchell Black" <mblack@synaptyx.com> wrote:
>
> Hello-
>
> Anyone out there have any experience integrating MKS Source Integrity with
> Wind River's Tornado IDE.  Any info would be appreciated.
>
You might want to have a look at CS-RCS -- a GNU RCS compatible revision
control system that is fully integrated with Windows 95/NT. CS-RCS
supports simple command-line interface for seamless integration with any
IDE.
For more information and to download a free evaluation copy visit:
http://www.ComponentSoftware.com/csrcs/
- ------------
David Matyas			davidm@ComponentSoftware.com
ComponentSoftware		http://www.ComponentSoftware.com
- -------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
---------------------------
End of New-News digest
**********************
From jshaw_shade@compuserve.com  Mon Jul 14 08:08:22 1997
From: John Shaw <jshaw_shade@compuserve.com>
Date: Mon Jul 14 08:08:25 PDT 1997
Subject: MIL-STD-1553 hardware and VxWorks
--MimeMultipartBoundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Regarding my previous message:-
>Subject: MIL-STD-1553 for MVME-162 and VxWorks 5.2
>Between August 96 and July 97 there have been three or so references to
>MIL-STD-1553.
Thanks for the many useful recommendations.
Has anyone used the 1553 products listed below?
        Condor IP-1553 (probably on a non-intelligent VME carrier board).=
        Radstone PMC-1553 (on a PowerPC card, maybe the MVME1600).
        Condor PC-1553 (on PC/AT machines, and BusTools for Windows
software).
If so, what are the vibes? The first product is pretty new. The PC-1553 h=
as
been around a
bit and has many users in the States. The PMC-1553 is about a year old.
How comprehensive is the bundled VxWorks 5.2 software for these products?=
There is
apparently a driver for the PMC-1553 and an API for the Condor IP-1553.
John Shaw,
Shade (Computer Services) Limited, England, UK.
Email to: jshaw_shade@compuserve.com
--MimeMultipartBoundary--
From Jeff.Thompson@Sciatl.COM  Mon Jul 14 08:21:12 1997
From: Jeff.Thompson@Sciatl.COM
Date: Mon Jul 14 08:21:15 PDT 1997
Subject: Propietary Shell
--MimeMultipartBoundary
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
     I have a simple command line interpreter (CLI) I would like to run via
     telnet and rlogin in lieu of the vxWorks shell. My CLI uses istream
     and ostream, and I want to leave stdin, stdout, and stderr available
     for the console. Of course, I could write new telnet and rlogin
     facilities, but I am hoping there is way to simply connect my CLI in
     place of the vxWorks shell. Anyone done this?
--------------------------------------------------------------------------------
   _/_/            _/_/   _/_/                         Jeff Thompson
    _/            _/     _/                       Scientific Atlanta
    _/     _/    _/_/_/ _/_/_/                               MS 40-B
    _/   _/  _/   _/     _/                 4295 International Blvd.
    _/   _/_/     _/     _/                       Norcross GA  30093
_/  _/   _/       _/     _/
  _/      _/_/    _/     _/                 jeff.thompson@sciatl.com
                                            (770) 903-3209 Telephone
_/_/_/  _/                                  (770) 903-6819 Facsimile
  _/    _/
  _/    _/_/      _/_/    _/  _/  _/_/_/    _/_/_/    _/_/    _/_/
  _/    _/  _/  _/    _/  _/_/_/  _/   _/  _/       _/    _/  _/  _/
  _/    _/  _/  _/    _/  _/  _/  _/   _/   _/_/_/  _/    _/  _/  _/
  _/    _/  _/  _/    _/  _/  _/  _/_/_/        _/  _/    _/  _/  _/
  _/    _/  _/    _/_/    _/  _/  _/       _/_/_/     _/_/    _/  _/
                                  _/
--MimeMultipartBoundary--
From hansen@pistilmac1.chinalake.navy.mil  Mon Jul 14 13:43:01 1997
From: hansen@pistilmac1.chinalake.navy.mil
Date: Mon Jul 14 13:43:04 PDT 1997
Subject: Are Industry Pack cards widely used?
--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
All,
In recent months, there has been a growing interest in the Industry Pack
(IP) form factor cards, both being hosted on SBC boards and installed on
VME carrier boards. My group has begun to use them as well, in
anisolated instance. We are now considering expanding our use of them,
but before we do, I wanted to get a feeling for how widely used they are
in industry.
Do people like them? Do they not? I know of one manufacturer that does
not provide their own drivers; is this common for other IP
manufacturers? Has this been a problem for anyone? Are there
manufacturers from which to steer away?
If you have any opinion/input, I would be interested in hearing from
you.
Thanks,
Joseph R Hansen
NAWCWPNS China Lake
Code 471220D
China Lake, CA 93555
(619) 939-6999
hansen@pistilmac1.chinalake.navy.mil
--MimeMultipartBoundary--
From SNIEDZE@homer.ds.boeing.com  Mon Jul 14 14:07:50 1997
From: SNIEDZE@homer.ds.boeing.com
Date: Mon Jul 14 14:07:52 PDT 1997
Subject: Remove Me
Hi!
Please REMOVE me from the VxWorks "exploder" mail
as a receipient.
tx.
John Sniedze @206-773-9424
email:  sniedze@homer.ds.boeing.com
From tony.mayes@tecra.it  Tue Jul 15 00:02:19 1997
From: tony.mayes@tecra.it
Date: Tue Jul 15 00:02:26 PDT 1997
Subject: Re: Vxworks on NT
--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sarir Khamsi wrote :-
> Yo,
>
> We are looking at replacing some UNIX boxes that hosted VxWorks with
> NT boxes. I know almost nothing about VxWorks or this
> environment. Does anyone have an evaluation of these two environments
> and/or a feature list? Thanks.
>
> Sarir
>
>
We are using currently Tornado 1.0 on NT4.0 and Tornado 1.0.1 on NT
3.51 and NT4.0.
1.0 has given us very little trouble, we have been using it for about
6 months, there are some problems with odd lock outs in the debugger
resulting in the need to restart the target server every now and then
(pretty often actually). We have been advised by WRS to move over to
1.0.1".... where a number ot such problems have been resolved".
After some initial, and as yet not
completely solved problems with the license manager in 1.0.1, we got
it up on 1.0.1 using a non locked key from WRS. Our floating license
key, after several attempts and problems, we abandoned.
The real problems we have had with 1.0.1 revolve around NT4.0 crashes
due to lock ups in the tool and the target server. We do not know if
this is Tornado or NT despite various attempts at  and talks with WRS
support.
From EMAIL, provided by WRS, it seems that either every thing on NT
goes well or in odd cases, like ours, it does not and there are
strange problems. We are currently going through and reinstalling NT
on the boxes using 1.0.1 to see it that resolves the problems. We
think its a combination of virus checking software, NT service pack 2
(which you need with Mcafee virus checker & Tornado if you dont want
FTP crashes) and Tornado. So beware of what you have on the NT box.
Aside from all of that, the tool is reasonable although some of our
expectations were not met, system mode debugging on ethernet is a
problem, the books have a note on this saying that the RPC back end
for the Tornado target server does not handle this but that a serial
connection does.
We use ethernet and hence cannot do this at present.
Also we have not been able to attach to multiple tasks
simultaneously. It may be possible running multiple tornado
applications but that is hardly a good way and with our other
problems we have not tried it.
Other debuggers that I know of for Vxworks claim they have this
capabiltiy but I have no experience of them.
The debugger can be difficult to use to set break points with, we
have found that sometimes the target shell is a more
certain place to set them, sometimes the debugger window and
sometimes the source code window. This can make things a little
complex for the user.
We have seen some problems working in our shared code environment and
have found that things work better if the code is on the Tornado
host rather than on our server machine.
We have no experience with the UNIX base so cannot offer an opinion
on that.
Hope it helps,
Tony
Tony Mayes
Email address          tony.mayes@epid.eurotherm.co.uk
Phone 031 975243
Fax   031 977512
Eurotherm SpA,
Via XXIV Maggio, 22070 Guanzate (CO), Italy
(NOTE: The opinions expressed within are my
       own and are not necessarily  those
       of my employer)
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Tue Jul 15 04:01:02 1997
From: daemon@csg.lbl.gov
Date: Tue Jul 15 04:01:05 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jul 15 04:00:57 PDT 1997
        Subject: Re: Alignment Problem with CC386 ..
        Subject: Re: 400 nsec delay on mv1603
        Subject: Re: MIL-STD-1553 hardware and VxWorks
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Alignment Problem with CC386 ..
Date: Wed, 09 Jul 1997 13:23:29 -0700
From: Dennis Chou <dchou4u@hotmail.com>
Organization: Cisco Systems
Message-ID: <33C3F341.DBF@hotmail.com>
References: <01bc8ab6$6e2487a0$3514028e@ESP213.er.bosch.de>
How are declaring the struct PACKED? Does your compiler supports that?
- --
- -------------------------------------------------------
Dennis Chou
Realtime Software Consultant
Innovative Software Design
dchou4u@hotmail.com
- -------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: 400 nsec delay on mv1603
Date: Wed, 09 Jul 1997 13:20:25 -0700
From: Dennis Chou <dchou4u@hotmail.com>
Organization: Cisco Systems
Message-ID: <33C3F289.2CB2@hotmail.com>
References: <v03007822afe925540261@[128.115.49.55]>
Bruce A. Wilson wrote:
>
> --MimeMultipartBoundary
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>         I'm looking for some advice on implementing short delays on a
> mv1603 board.   I thought I'd use a simple
> __asm__("nop;nop;nop;....nop"::); statement, with 40 nops, to get 400 nsec
> delays.  I think each nop takes 10 nsec on a 100 MHz processor.  Is there
> something special I need to do to make sure the 40 nops get executed, and
> not optimized away, or somehow skipped?
>
> Could anyone suggest a better way to code a short delay ( e.g. 400
> nanoseconds ) on a mv1603 processor?
>
> Bruce A. Wilson
> U.C. LLNL   ( L-054 )
> P.O. Box 808
> Livermore, CA  94550
>
> --MimeMultipartBoundary--
Watch for interrupts! Make sure your int masks are fully on.
If you use inline assembly, it shouldnt be optimized out.
- --
- -------------------------------------------------------
Dennis Chou
Realtime Software Consultant
Innovative Software Design
dchou4u@hotmail.com
- -------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: MIL-STD-1553 hardware and VxWorks
Date: Mon, 14 Jul 1997 14:20:38 -0400
From: David.Kuechenmeister@gtri.gatech.edu (David R. Kuechenmeister)
Organization: Georgia Tech Research Institute
Message-ID: <David.Kuechenmeister-ya02408000R1407971420380001@news.gatech.edu>
References: <199707141108_MC2-1AD1-988F@compuserve.com>
In article <199707141108_MC2-1AD1-988F@compuserve.com>, John Shaw
<jshaw_shade@compuserve.com> wrote:
>Has anyone used the 1553 products listed below?
>
>        Condor IP-1553 (probably on a non-intelligent VME carrier board).=
>
>
>        Radstone PMC-1553 (on a PowerPC card, maybe the MVME1600).
>
>        Condor PC-1553 (on PC/AT machines, and BusTools for Windows
>software).
I've got the PMC1553 card from Radstone. There were a few glitches,
initially, but the support from the factory was excellent. We use the card
with the PPC603 and 604 boards. The only fault that I can find with the
hardware or software is that Radstone only delivers a compiled library. I
can't go to the code to find out how a particular function works. The
documentation is a little sparse, too.
As far as the PC/AT computer goes, we have bought SBS 1553 cards and used
them with great success. I recommend them very highly.
Regards,
- --
David R. Kuechenmeister
Georgia Tech Research Institute
Atlanta,GA 30332
mailto:David.Kuechenmeister@gtri.gatech.edu      Voice:(770)528-7738
---------------------------
End of New-News digest
**********************
From hornsbyk@stopwilly.wr.trw.com  Tue Jul 15 10:10:03 1997
From: "Kelly Hornsby" <hornsbyk@stopwilly.wr.trw.com>
Date: Tue Jul 15 10:10:22 PDT 1997
Subject: DNS for VxWorks
--MimeMultipartBoundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hello All.
I've looked in the VxWorks library and on the public FTP site but I can't
find anything on this topic.  Has anyone seen or used a name resolver
library for DNS on VxWorks?  I'm looking for any information or sources for
it.  Otherwise I'll have to hack up the DNS stuff from Linux which will
take me a while.  I'm a very familiar with DNS and IP in general but I've
not ported DNS from machine to machine before.
thanks for any input.
--MimeMultipartBoundary--
From bawilson@llnl.gov  Tue Jul 15 12:47:54 1997
From: "Bruce A. Wilson" <bawilson@llnl.gov>
Date: Tue Jul 15 12:47:57 PDT 1997
Subject: Re: comp.os.vxworks newsdigest
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
>
>Dennis Chou wrote:
>Watch for interrupts! Make sure your int masks are fully on.
>If you use inline assembly, it shouldnt be optimized out.
>
Since I needed at least 400 nanoseconds of delay, but more wouldn't be
harmful, I'm not protecting against being interrupted with int masks.
I found that sometimes my __asm__("nop;nop;...,nop"::) statement with 40
nops gave me less than 60 nanoseconds of delay.  I found this out by
reading the DECREMENTER Register before and after the __asm__ statement.
For my 100 MHz mv1603 board, the DEC Register ticks every 60 ns, and
sometimes, both the before and after readings were the same.  I think my
inline assembly must have been optimized away, or somehow skipped by the
cpu.
However, after reading that the GNU CC compiler doesn't delete empty loops,
my worries were over.  I simply used a "for(m=0;m<17;m++);" statement for
my 400 nsec delay.
Bruce A. Wilson
U.C. LLNL   ( L-054 )
P.O. Box 808
Livermore, CA  94550
--MimeMultipartBoundary--
From achung@mmwave.com  Tue Jul 15 18:23:06 1997
From: Albert Chung <achung@mmwave.com>
Date: Tue Jul 15 18:23:09 PDT 1997
Subject: socket calls thru HDLC link
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to find out if it is possible to make socket calls between =
two VxWorks platforms connected through an HDLC link.  If so, how can I =
go about creating an HDLC driver for it.  Would the HDLC driver be a =
character driver or a network driver?   Or, would it be easier to make =
the HDLC driver look like a serial driver and use it like a SLIP or PPP =
connection over the HDLC link.
Has someone done something similar before?
--MimeMultipartBoundary--
From uchenick@tis4000.com  Tue Jul 15 19:30:02 1997
From: Gordon Uchenick <uchenick@tis4000.com>
Date: Tue Jul 15 19:30:05 PDT 1997
Subject: RE: socket calls thru HDLC link
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
If you want to make socket calls with socket type PF_INET, then you'll =
have to make an HDLC network driver. We're still at 5.1, and the best =
place to find out how to make a network driver was the BSP porting kit =
documentation. I suggest you start there.
HTH,
Gordon Uchenick
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Wed Jul 16 04:00:45 1997
From: daemon@csg.lbl.gov
Date: Wed Jul 16 04:00:49 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jul 16 04:00:39 PDT 1997
        Subject: Re: Which Sun workstation ?
        Subject: Tornado 1.0.1 Debugger
        Subject: Low-Memory VxWorks
        Subject: VxWorks configuration
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Which Sun workstation ?
Date: Tue, 15 Jul 1997 19:16:07 GMT
From: jon@erc.msstate.edu (Jonathan Robinson)
Organization: Mississippi State University
Message-ID: <33cccb77.81969155@nntp.msstate.edu>
References: <5q5m12$a0j$1@mhafc.production.compuserve.com>
On 11 Jul 1997 16:12:18 GMT, Jim Snyder <73077.3147@CompuServe.COM>
wrote:
>Does anyone have a recommendation for a Tornado development host
>with a single user development license. Will be Sun/Solaris.
>Which number SparcStation ? How much memory, disk, etc. ? Any
>suggestions appreciated.
>
>Also looking for sellers of used Sun workstations.
>
>Thanks in advance,
>
>Jim S.
>
>--
>Jim Snyder
>
>e-mail: peko_prescison@compuserve.com
Almost any sparcstation will work fine.  Most of Tornado is TCL/TK and
not very demanding.  If you are patient when it comes to compiling,
you could easily use a Sparc 1+ or 2 with 16Megs.  More would speed
compile, but not much else.
Disk space is a little different.  I don't know about typical, but my
install takes about 350Megs of disk, and I have at least five
different VXWorks kernels compiled.  I would suggest at least 1Gig.
Jon Robinson
---------------------------
Newsgroups: comp.os.vxworks
Subject: Tornado 1.0.1 Debugger
Date: Thu, 10 Jul 1997 09:30:25 -0500
From: Doug Lewis <d-lewis3@ti.com>
Organization: Texas Instruments Defense Systems
Message-ID: <33C4F201.778E@ti.com>
Reply-To: d-lewis3@ti.com
I'm trying to port some C++ code from a sun workstation to a PowerPC
board.  I'm running the debugger to allow me to find the bugs in the
program.
At points in the program, I read in data files and I'm overflowing the
debug stack.  I sent e-mail to Wind River a week ago and still haven't
received an response back.  What I need to do is make the stack for the
debugger larger on the target board.  Does anyone know how to do this?
Thanks,
Doug Lewis
---------------------------
Newsgroups: comp.os.vxworks
Subject: Low-Memory VxWorks
Date: Thu, 10 Jul 1997 10:47:06 -0500
From: Jonathan Robinson <jon@ERC.MsState.Edu>
Organization: Mississippi State University
Message-ID: <Pine.GSO.3.96.970710104424.13569A-100000@wolverine>
I am currently working on a project where vxworks is to be placed on a
custom built single board computer based on the MC68340 processor.  I was
wondering what is the minimum amount of RAM that anyone has gotten VXWorks
to fit in if using PPP to boot the kernel.  The only thing I require is
PPP support and the shell.
Thanks,
****************************************************************
* Jonathan Robinson                email:  jon@erc.msstate.edu *
* NSF Engineering Research Center  phone:  (601) 325-7754      *
* Mississippi State University     office: VAULT               *
****************************************************************
---------------------------
Newsgroups: comp.os.vxworks
Subject: VxWorks configuration
Date: 16 Jul 1997 04:11:43 GMT
From: rip@nautronix.com.au (Richard Puchmayer)
Organization: Nautronix Limited, Fremantle Australia
Message-ID: <5qhhlv$m2t$1@disco.iinet.net.au>
Hi,
The following query is probably in the FAQ.  If so, please point
me to the FAQ.
Is there a list of when you should use specific INCLUDE's in the
VxWork configuration ?  A method other than trial and error seems
preferrable when configuring.
Thanks,
    RiP
- --
- - Richard.Puchmayer@nautronix.com.au      |  NAUTRONIX Ltd.        -
- - Tel: +61 [0]9 430 5900, Fax: 430 5901   |  108 Marine Tce.       -
- - These are ramblings of an insane mind.  |  Fremantle, WA 6160    -
- - "In summary, N is Richardian iff N is not Richardian." - Fortune -
---------------------------
End of New-News digest
**********************
From mea@mclean.sparta.com  Wed Jul 16 06:58:04 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed Jul 16 06:58:07 PDT 1997
Subject: Re: VxWorks Configuration
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 04:00 AM 7/16/97 PDT, you wrote:
>Subject: VxWorks configuration
>From: rip@nautronix.com.au (Richard Puchmayer)
>Hi,
>
>The following query is probably in the FAQ.  If so, please point
>me to the FAQ.
>
The FAQ is woefully out of date (my fault :-( ), but it has very little
info for what you're seeking anyway.
>Is there a list of when you should use specific INCLUDE's in the
>VxWork configuration ?  A method other than trial and error seems
>preferrable when configuring.
>
Well, the Programmer's guide has some of this info.  But, without outlining
precisely what you want to do and what processor you're using, it's
difficult to give you much in the way of pointers.  As we normally run
with targets that have at least 2 MB of RAM, we typically turn everything
except the SNMP (MIB), RT11FS, POSIX and PROXY-related stuff (TFTP,
PROXY_SERVER, etc) on.  Once our development is through, we start turning
more stuff off to trim the O/S down to a ROM/Flashable size.  Other folks
take the opposite track where they only turn stuff on as absolutely needed.
Of course, we also turn off most of the Tornado stuff like the WDB agent
and run with a 5.2-like configuration to avoid the quirks of the
Tornado environment (we're still using Tornado 1.0 because we haven't
gotten around to screwing with the new license mgr for 1.0.1), but
that may change if 1.0.1 fixes as many bugs as WRS claims.
So, if you can be a bit more precise about your application/environment,
perhaps I can be of more help.
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."
==============================================================================
--MimeMultipartBoundary--
From tkb@mclean.sparta.com  Wed Jul 16 06:59:29 1997
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Wed Jul 16 06:59:31 PDT 1997
Subject: Re: socket calls thru HDLC link
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> I am trying to find out if it is possible to make socket calls between =
> two VxWorks platforms connected through an HDLC link.  If so, how can I =
> go about creating an HDLC driver for it.  Would the HDLC driver be a =
> character driver or a network driver?   Or, would it be easier to make =
> the HDLC driver look like a serial driver and use it like a SLIP or PPP =
> connection over the HDLC link.
>
> Has someone done something similar before?
Making your HDLC driver look like a serial driver and using PPP will be
quicker.  The compression techniques used in SLIP and PPP are optimized
for asynch modem data rates.  Take into account that they are not quite
as effective at higher data rates.
--MimeMultipartBoundary--
From hholma@atl.com  Wed Jul 16 07:56:22 1997
From: Howard Holman <hholma@atl.com>
Date: Wed Jul 16 07:56:25 PDT 1997
Subject: Unsubcribe
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please unsubscribe.
Thanks
--MimeMultipartBoundary--
From TOM2910@aol.com  Wed Jul 16 07:57:12 1997
From: TOM2910@aol.com
Date: Wed Jul 16 07:57:15 PDT 1997
Subject: Re: DNS for VxWorks
>
> Has anyone seen or used a name resolver library for DNS on VxWorks ?
>
I am also interested in the same topic.
Does anyone have this info ?
Thanks.
-Tom Wang
3 Tech Partner, Inc.
Email: s.wang@ieee.org
From hornsbyk@stopwilly.wr.trw.com  Wed Jul 16 12:28:18 1997
From: "Kelly Hornsby" <hornsbyk@stopwilly.wr.trw.com>
Date: Wed Jul 16 12:28:50 PDT 1997
Subject: Re: DNS for VxWorks
--MimeMultipartBoundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
> >
> > Has anyone seen or used a name resolver library for DNS on VxWorks ?
> >
>
> I am also interested in the same topic.
> Does anyone have this info ?
>
I received a copyrighted/unsupported/no warranty dns client (source)  from
a guy a WindRiver so I don't know if I can distribute it.  Apparently the
DNS will be available in Tornado 1.0.1 or later.  It will be available as
part of a BSD stack and is part of SENS.  I don't know what SENS is, or any
more about the BSD stack (for VxWorks, anyway) so don't ask 'cause I don't
know.
Thank the folks at WRS for their help.  If you want more information on
this (like I did), then contact
-----------------------------------------------------------------------
Leonid Rosenboim                   | Phone: +972-3-559-8144
Technical Manager                  | Fax:   +972-3-559-8244
Wind River Systems Israel          | Mobile:+972-53-51-6646
P.O.Box 11502, AZUR 58017, Israel  | e-mail: leonid@wrs.co.il
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Thu Jul 17 04:00:21 1997
From: daemon@csg.lbl.gov
Date: Thu Jul 17 04:00:24 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jul 17 04:00:15 PDT 1997
        Subject: mv162 MCchip Tick Timer
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: mv162 MCchip Tick Timer
Date: 10 Jul 1997 17:38:21 GMT
From: chris@raf.atd.ucar.edu (Chris Webster)
Organization: NCAR Research Aviation Facility, Boulder, CO
Message-ID: <5q36md$91g$1@ncar.ucar.edu>
Reply-To: chris@raf.atd.ucar.edu
I'm trying to program the MCchip Tick Timer (#2).  I keep getting
workQPanic overflow, and reboot.  Does anyone who has done this have
a snippet of code I could use to compare with?
- --Chris
TicTimer::TicTimer(void (*ticISR)(int))
{
  int   vector = (*vectorBaseReg + 0x08) << 2;
// Enable interupts for timer, level 6.
  *intControlReg = 0x16;
  *controlReg = 0x06;           /* Set COC & COVF high (clear oflow)    */
  intConnect((VOIDFUNCPTR *)vector, (VOIDFUNCPTR)ticISR, 0);
}       /* END CONSTRUCTOR */
TicTimer::setTimer(int milliSeconds)
{
  *compareReg = milliSeconds * 1000;
  *counterReg = 0;              /* Reset Counter & compare registers    */
  *controlReg = 0x03;           /* Set CEN & COC high           */
}       /* END SETTIMER */
---------------------------
End of New-News digest
**********************
From intrepid!eci-cec.com!minidds@uunet.uu.net  Thu Jul 17 06:11:40 1997
From: minidds@eci-cec.com (Lee Kappel)
Date: Thu Jul 17 06:11:43 PDT 1997
Subject: Unsubcribe
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please unsubscribe.
--MimeMultipartBoundary--
From phil.quiney@gecm.com  Thu Jul 17 06:16:23 1997
From: Philip Quiney <phil.quiney@gecm.com>
Date: Thu Jul 17 06:16:26 PDT 1997
Subject: Re:mv162 MCchip Tick Timer
Hi Chris,
The 'workQPanic' is usually caused by an interrupt routine not clearing the
cause of the interrupt. For a snippet of code, try the timer program used by
the BSP for the mv162 which is found in:
${WIND_BASE}/target/src/drv/timer/mccTimer.c
>I'm trying to program the MCchip Tick Timer (#2).  I keep getting
>workQPanic overflow, and reboot.  Does anyone who has done this have
>a snippet of code I could use to compare with?
Hope this helps
Regards
Phil Q
===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : phil.quiney@gecm.com
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/
===============================================================================
From mfischer@qualcomm.com  Thu Jul 17 17:15:14 1997
From: Mark Fischer <mfischer@qualcomm.com>
Date: Thu Jul 17 17:15:17 PDT 1997
Subject: "traceroute" on VxWorks
All,
Has anyone gotten the utility "traceroute" to compile under VxWorks?
Thanks,
Mark Fischer
Qualcomm, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From stan@rti.com  Thu Jul 17 18:54:40 1997
From: stan@rti.com (Stan Schneider)
Date: Thu Jul 17 18:54:43 PDT 1997
Subject: Re: comp.os.vxworks newsdigest
>> Submitted-by bawilson@llnl.gov  Tue Jul 15 12:47:54 1997
>> However, after reading that the GNU CC compiler doesn't delete empty loops,
>> my worries were over.  I simply used a "for(m=0;m<17;m++);" statement for
>> my 400 nsec delay.
The gcc compiler *will* delete this loop, unless you declare "m" as
"volatile".  It may not have in your case because you used the "-fvolatile"
flag (default in the makefile).  That flag turns off most all optimization.
	-- Stan
From Eric.Buvat@steria.fr  Fri Jul 18 01:52:40 1997
From: Eric BUVAT <Eric.Buvat@steria.fr>
Date: Fri Jul 18 01:52:44 PDT 1997
Subject: File Sytems
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'd like to know if there is an implementation of ntfs (Windows NT file
system) available on VxWorks.
I wanted to used a disk size of 9 Go. The dosFsLib has limitation
because of the 2 Go size partition.
I could use rawFs but I'd prefer use standard file system.
Thanks in advance for any information.
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Fri Jul 18 04:00:24 1997
From: daemon@csg.lbl.gov
Date: Fri Jul 18 04:00:28 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jul 18 04:00:19 PDT 1997
        Subject: lowering sysClkRate()
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: lowering sysClkRate()
Date: 17 Jul 1997 14:36:19 GMT
From: chris@raf.atd.ucar.edu (Chris Webster)
Organization: NCAR Research Aviation Facility, Boulder, CO
Message-ID: <5qlal3$kco$1@ncar.ucar.edu>
Reply-To: chris@raf.atd.ucar.edu
There has been discussion about not bumping the sysClkRate too high.
What about too low, the default is 60hz, can I drop it to say 5hz or
10hz without any problem?
- --Chris
          I don't suffer from insanity, I enjoy every minute of it.
---------------------------
End of New-News digest
**********************
From cjs@cscsgi.larc.nasa.gov  Fri Jul 18 07:23:10 1997
From: "Christopher J. slominski" <cjs@cscsgi.larc.nasa.gov>
Date: Fri Jul 18 07:23:13 PDT 1997
Subject: vxWorks 5.3.1 exceptions
--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII
Group,
	I have recently started using the new release of vxWorks (5.3.1)
on my MVME-1604 PowerPC.  I was surprised to get a floating point
exception that does not occur under 5.3 (underflow).  It looks like Wind
Rivers has enabled some exceptions that were not previously handled.  Does
anybody know of other similar things that may now cause my tasks to stop?
	I modified the PowerPC FPSCR in my software to disable the
floating underflow exception, however I eventually want to handle many
exceptions myself to have the option of not stopping the tasks.  I have
not found much information on doing this.  I see a excConnect() function
supplied by vxWorks which installs exception handlers as long as you know
the vector number for the types you want to trap.  From what I can tell
the 0x0700 vector gets several types of exceptions including floating
point exceptions.  Will I have to handle all types in the 0x700 verctor?
Should I chain to the default handler for the types I don't want to handle
(how do I tell what type happened) ?  Where do I finf information about
exception vector definitions ?
	Please let me know what others have done, and what has worked
well.
   *----------------------------------------*
   |  Christopher J. Slominski              |
   |   Computer Sciences Corporation (CSC)  |
   |   3217 N. Armistead Ave.               |
   |   Hampton, VA 23666                    |
   |   (757) 766-8258                       |
   |   c.j.slominski@larc.nasa.gov          |
   |   NASA Mail Stop 931                   |
   *----------------------------------------*
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Sat Jul 19 04:01:12 1997
From: daemon@csg.lbl.gov
Date: Sat Jul 19 04:01:15 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jul 19 04:01:08 PDT 1997
        Subject: Re: Is VxWorks on Mars?
        Subject: Which Sun workstation ?
        Subject: Re: ColdFire (MCF5206) Development Tools?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is VxWorks on Mars?
Date: 11 Jul 1997 14:45:16 GMT
From: hintze@nubian.NoSubdomain.NoDomain (Geoffrey C. Hintze)
Organization: NASA/MSFC
Message-ID: <5q5gts$1bv$1@hammer.msfc.nasa.gov>
References: <33c12cc7.10369094@nntp.ix.netcom.com> <5pu0l6$dn9@post.gsfc.nasa.gov> <5q17hv$fpu1@cnn.wrs.com>
Sender: hintze@nubian (Geoffrey C. Hintze)
>Yes, the LANDER's one and only computer, that has been controlling the
mission since launch day, is a rad6000 running VxWorks.  JPL Pathfinder
is the one-and-only site that used the AIX "native" compiler (AIX
running on an rs6000 box).
>
The rs6000 box is also being used for Space Station Furnace Facility.  We are
also using VxWorks 5.1 and the Green Hills C Compiler.  The project has slipped
but hopefully we will get to fly it someday.
- --
- -------------------------------------------------------------------------
	Geoffrey Hintze		EMail:	hintze@mohave.msfc.nasa.gov
	NASA/MSFC		Phone:	(205) 544-3792
	EB43			Fax:	(205) 544-8480
	MSFC, AL 35812
- -------------------------------------------------------------------------
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzNCZNgAAAEEALnpRJYT+mKHjVaDDgFvnYeWfjqlMJG9A+c/AHQGA6H9HYBb
aCEL9/tQku0jJAJJsX7wT0Demv1IV/bFiaj93sNhSFBhADV1+iWcyi9LDSfJaJJV
LdwWJRfV2h56t1BM3oowGizEJUBJp4jjTB5jLo5iBjR31NGpPaYcgqk2K6o9AAUR
tDBHZW9mZnJleSBDLiBIaW50emUgPGhpbnR6ZUBtb2hhdmUubXNmYy5uYXNhLmdv
dj4=
=PXuV
- -----END PGP PUBLIC KEY BLOCK-----
---------------------------
Newsgroups: comp.os.vxworks
Subject: Which Sun workstation ?
Date: 11 Jul 1997 16:12:18 GMT
From: Jim Snyder <73077.3147@CompuServe.COM>
Organization: PEKO Presision Products
Message-ID: <5q5m12$a0j$1@mhafc.production.compuserve.com>
Does anyone have a recommendation for a Tornado development host
with a single user development license. Will be Sun/Solaris.
Which number SparcStation ? How much memory, disk, etc. ? Any
suggestions appreciated.
Also looking for sellers of used Sun workstations.
Thanks in advance,
Jim S.
- --
Jim Snyder
e-mail: peko_prescison@compuserve.com
---------------------------
Newsgroups: comp.os.vxworks,comp.arch.embedded,comp.realtime
Subject: Re: ColdFire (MCF5206) Development Tools?
Date: Fri, 18 Jul 1997 10:33:49 -0600
From: Rich Ireland <rireland@nospam.phbtsus.com>
Organization: Philips BTS
Message-ID: <33CF9AED.2C7F@nospam.phbtsus.com>
References: <33CE8211.EEE@nospam.phbtsus.com>
Pieter Kunst wrote:
>
> Rich Ireland wrote:
>
> > Does anyone have any insights/comments about development tools
> > for the latest ColdFire processor?
>
> Hello Rich,
>
> Did you take a peek at the URL below ?
> http://www.mot.com/SPS/HPESD/prod/coldfire/
>
> We ordered a $99 evaluation package (see advert below)
> but I didn't really have time to look at it.
> Maybe you are able to get hold on such a package.
>
Yes I have examined the Coldfire site extensively. Unfortunately
I haven't found and objective asessments of the available tools.
I have used SDS SingleStep for a '340 project and was pleased
with it.  However, I know nothing about Diab Data, Green Hills,
or any of the other tools cited by Motorola.
I do have the eval package on order. But is it the _best_ solution?
Regards,
Rich
- --
- ------------------------------------------------------------
Rich Ireland                            rireland@phbtsus.com
Software Engineer                        Core Products Group
Philips BTS                       http://www.philipsbts.com/
---------------------------
End of New-News digest
**********************
From daemon@csg.lbl.gov  Sun Jul 20 04:00:23 1997
From: daemon@csg.lbl.gov
Date: Sun Jul 20 04:00:29 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jul 20 04:00:16 PDT 1997
        Subject: pipes vs. socket within CPU
        Subject: Tottally FREE SEX SITE
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: pipes vs. socket within CPU
Date: 11 Jul 1997 20:14:03 GMT
From: "David_Kemper" <davidk@voicenet.mask.com>
Organization: Competitive Media Reporting, Inc.
Message-ID: <01bc8e39$109f59d0$697167cf@dkemper>
I'm designing a system to act as a gateway between a VAX and 3 VxWorks
targets. Two of the VxWorks targets will be on separate backplanes, so TCP
sockets are the obvious choice to connect them, but the third will reside
on the same CPU (as the gateway interface).
Does using a socket connection within a processor make sense, or is it
worthless overhead ?
Would using a pipe actually eliminate much overhead (vs. a TCP socket) ?
I'd appreciate any expert advice !
=======================================================
David Kemper			tel: 610-430-6373
Systems Engineer			fax: 610-430-6355
Competitive Media Reporting		email: davidk@voicenet.com
1385 Enterprise Drive
West Chester,  PA  19380
=======================================================
---------------------------
Newsgroups: comp.os.vxworks
Subject: Tottally FREE SEX SITE
Date: 19 Jul 1997 17:06:55 GMT
From: houu88d77@compuserve.com
Organization: Gary Sex Inc
Message-ID: <5qqs7f$au3@news1-alterdial.uu.net>
This is a multi-part message in MIME format.
- --_-=176
Content-type: text/html; name="Sex~1.htm"
Content-transfer-encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9JRVRGLy9EVEQgSFRNTC8vRU4iPg0KDQo8aHRt
bD4NCg0KPGhlYWQ+DQo8dGl0bGU+U0VDUkVUIFBBU1NXT1JEIEZPUiBBRFVMVCBTSUdIVFM8
L3RpdGxlPg0KPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3NvZnQgRnJv
bnRQYWdlIDEuMSI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9IiNDMEMwQzAiIHRleHQ9
IiM4MEZGRkYiIGxpbms9IiMwMDAwRkYiIHZsaW5rPSIjMDAwMEZGIiBhbGluaz0iI0ZGMDAw
MCI+DQo8ZGl2IGFsaWduPWNlbnRlcj48Y2VudGVyPg0KPHRhYmxlIGJvcmRlcj01IGNlbGxw
YWRkaW5nPTI+DQo8dHI+PHRkIGFsaWduPWNlbnRlciB3aWR0aD0xMDAlPjxmb250IGNvbG9y
PSIjRkZGRjAwIj48Zm9udCBzaXplPTc+PGI+RlJFRSEgRlJFRSEgRlJFRSE8YnI+DQo8L2I+
PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT01PjxiPlRI
QVQnUyBSSUdIVC4uLiBDT01QTEVURUxZIDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT02PjxiPkZS
RUUhITwvYj48L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjMDAwMEZGIj48Zm9udCBzaXpl
PTU+PGI+PGk+PGJyPg0KRU5URVIgVEhST1VHSCBBRFVMVFNJR0hUUyAmIzE2OTsgPC9pPjwv
Yj48L2ZvbnQ+PGZvbnQgc2l6ZT02Pjxicj4NCjwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9
IiNGRkZGMDAiPjxmb250IHNpemU9Nz48Yj5JVCdTIEZSRUUhISEhITwvYj48L2ZvbnQ+PC9m
b250PjwvdGQ+PC90cj4NCjwvdGFibGU+DQo8L2NlbnRlcj48L2Rpdj4NCjxwIGFsaWduPWNl
bnRlcj48Zm9udCBGQUNFPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzIyMTY1QSI+
PGZvbnQgc2l6ZT03PiA8L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjRkYwMDAwIj48Zm9u
dCBzaXplPTc+T05FIFBBU1NXT1JEIDxmb250IEZBQ0U9IkNvbWljIFNhbnMgTVMiPjxicj4N
CjwvZm9udD48L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjMjIxNjVBIj48Zm9udCBzaXpl
PTU+IDwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9NT48
c3Ryb25nPkdFVFMgWU9VIFVOTElNSVRFRCBGUkVFIEFDQ0VTUyBUTyBPVkVSIA0KMTgwMCsg
T0YgVEhFIEhPVFRFU1QgQURVTFQgU0lURVMgPC9zdHJvbmc+PC9mb250PjwvZm9udD48L3A+
DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9NT48
c3Ryb25nPklGIFlPVSBBUkUgVElSRUQgT0YgUEFZSU5HIFRPIEdFVCBJTlRPIFNFWCANClNJ
VEVTLi4uPC9zdHJvbmc+PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+PGZv
bnQgc2l6ZT01PjxzdHJvbmc+IDwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9
IiMwMEZGRkYiPjxmb250IHNpemU9NT5PbmUgUGFzc3dvcmQgaXMgYWxsIHlvdSBuZWVkISEh
PGJyPg0KPC9mb250PjwvZm9udD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgRkFDRT0i
Q29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMyMjE2NUEiPjxmb250IHNpemU9Nj4gPC9m
b250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT02PjxzdHJvbmc+
TE9PSyBXSEFUIFlPVSBHRVQhPC9zdHJvbmc+PC9mb250PjwvZm9udD48L3A+DQo8cCBhbGln
bj1jZW50ZXI+PGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMyMjE2
NUEiPjxmb250IHNpemU9NT4gPC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkYwMCI+
PGZvbnQgc2l6ZT01PjxzdHJvbmc+VU5MSU1JVEVEIEZSRUUgQUNDRVNTIFRPIE9WRVIgMTgw
MCsgT0YgDQpUSEUgSE9UVEVTVCBBRFVMVCBTSVRFUzwvc3Ryb25nPiA8Zm9udCBGQUNFPSJD
b21pYyBTYW5zIE1TIj48L2ZvbnQ+PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iIzIyMTY1
QSI+PGZvbnQgc2l6ZT01PiA8L2ZvbnQ+PC9mb250PjwvcD4NCjxoMSBhbGlnbj1jZW50ZXI+
PGZvbnQgY29sb3I9IiNGRjAwMDAiPjxmb250IHNpemU9NT48c3Ryb25nPkp1c3QgQSBGZXcg
T2YgVGhlIE92ZXIgMTgwMCsgWFhYIFJhdGVkIFNpZ2h0cyBUaGF0IA0KWW91IENhbiBFbnRl
ciBDb21wbGV0ZWx5IEZyZWUhPGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PC9mb250Pjwv
c3Ryb25nPjwvZm9udD48L2ZvbnQ+PC9oMT4NCjxoMSBhbGlnbj1jZW50ZXI+PGZvbnQgY29s
b3I9IiM4MEZGMDAiPjxmb250IHNpemU9Nj48c3Ryb25nPlRFRU4gU0lURVM8L3N0cm9uZz48
L2ZvbnQ+PC9mb250PjwvaDE+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiPjxmb250IHNpemU9ND4xMDAwIEhPVCBBTkQgTmFLRUQgLSBDZUxlQlJpVGlFUyBBTkQg
VEVFTlMgLSAxMDAxIE51ZGUgRXJvdGljIA0KVGVlbnMgLSAyMCBBbWFUZWVucyAtIDYyMyBO
dWRlIENlbGVicml0aWVzIEFuZCBUZWVucyAtIEFBQSBTTFVUWSANClRFRU5TIC0gQW1hdGV1
ciBUZWVucyAtIEFtYXRldXIgVGVlbnMgRnJvbSBBcm91bmQgVGhlIFdvcmxkIC0gQW1hdGV1
ciANClRlZW5zISAtIENvY2sgSHVuZ3J5IFRlZW5zIC0gQ3VtIERyaW5raW5nIFRlZW5zIC1G
aXN0IEZ1Y2tpbmcgVGVlbnMgLSBIb3QgDQpOdWRlIFRlZW5zIC0gTm90aGluZyBCdXQgVGVl
bnMgLSBUZWVucyBJbiBUcm91YmxlIC0gVHdhdCBTdWNraW5nIFRlZW5zIDwvZm9udD48L2Zv
bnQ+PC9wPg0KPHAgYWxpZ249Y2VudGVyPjxmb250IGNvbG9yPSIjRkYwMDAwIj48Zm9udCBz
aXplPTY+PHN0cm9uZz5BU0lBTiBTSUdIVFM8L3N0cm9uZz48L2ZvbnQ+PC9mb250PjwvcD4N
CjxwIGFsaWduPWNlbnRlcj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT00PkFs
bCBBc2lhbiBUZWVuIC0gQXNpYW4gQmFiZXMgLSBBc2lhbiBCYWJlcyBzaWFuIEJhYmVzISAt
IEFzaWFuIEJlbGxlcyAtIEFzaWFuIA0KQm9uZGFnZSAtIEFzaWFuIEN1dGUgR2lybHMgLSBB
c2lhbiBEZWxpdGVzIC0gQXNpYW4gRXJvcyAtIEFzaWFuIEZsb3dlcnMgLSANCkFzaWFuIEdv
bGQgLSBZb3VuZyBBc2lhbiBXb21lbiAtIEFzaWFuIEhhcmRDb3JlIEFTSUFOIEhBUkRDT1JF
IC0gDQpUSEUgTEVHRU5EIENPTlRJTlVFUyAtIEFTSUFOIEhvbG9zdWl0ZSAtIEFzaWFuIExv
dmUgRG9sbHMgPC9mb250PjwvZm9udD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29s
b3I9IiNGRjAwRkYiPjxmb250IHNpemU9Nj48c3Ryb25nPkNFTEVCUklUWSBTSUdIVFM8L3N0
cm9uZz48L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGFsaWduPWNlbnRlcj48Zm9udCBjb2xvcj0i
IzAwMDAwMCI+PGZvbnQgc2l6ZT00PiMxIE51ZGUgQ2VsZWJyaXR5IFBhZ2UgISAtIENlbGVi
d29ybGQgQWNlJ3MgLSBYWFggQ2VsZWJyaXR5IFBpY3MgLSBDZWxlYnJpdHkgDQpDZW50cmFs
IC0gQ2VsZWJyaXR5IENoaWNrIFBhdHRpZXMgLSBDZWxlYnJpdHkgQ3VtYm94IC0gQ2VsZWJy
aXR5IFBpY3R1cmVzIA0KQ2VsZWJyaXR5IFBpY3R1cmVzIEdvbGQgU2l0ZSAtIENlbGVicml0
eSBTa2luIC0gQ2VsZWJyaXR5IFNraW4tQUJDIC0gRGEgUm9ja3MgDQpudWRlIGNlbGVicml0
eSBBcmNoaXZlIC0gTWFya3MgQ2VsZWJyaXR5IFBpY3R1cmVzIDIgLSBOdWRlIENlbGVicml0
eSBBcmNoaXZlIC0gDQpTdGFyTG9jYXRvciAtIENlbGVicml0eSBTdXBlclMgLSBUaGUgRGFp
bHkgTnVkZSBDZWxlYnJpdHkgUGFnZSAtIFRoZSBNdXN0IA0KU2VlIE5VREUgQ2VsZWJyaXR5
IFNpdGUgLSBUaGUgVWx0aW1hdGUgQ2VsZWJyaXR5IENvbGxlY3Rpb24gPC9mb250PjwvZm9u
dD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PGZv
bnQgY29sb3I9IiNGRjRGQTciPjxmb250IHNpemU9NT4gPC9mb250PjwvZm9udD48Zm9udCBj
b2xvcj0iIzAwODBGRiI+PGZvbnQgc2l6ZT01PjxzdHJvbmc+VU5MSU1JVEVEIEZSRUUgQUND
RVNTIFRPIE9VUiBYWFggUkFURUQgDQpDSEFUIFJPT008L3N0cm9uZz48L2ZvbnQ+PC9mb250
PjwvcD4NCjxwIGFsaWduPWNlbnRlcj48Zm9udCBGQUNFPSJDb21pYyBTYW5zIE1TIj48Zm9u
dCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT01PjxzdHJvbmc+R2V0IFlvdXIgQURVTFRT
SUdIVFMgQUdFIFZFUklGSUNBVElPTiANCk1FTUJFUlNISVAgRk9SIE9OTFkgJDEyLjk1LiBJ
dHMgR29vZCBGb3IgQW4gDQpFbnRpcmUgWWVhciBBbmQgR2V0cyBZb3UgVU5MSU1JVEVEIEZS
RUUgQWNjZXNzIA0KSW50byAxODAwKyBPZiBUaGUgQmVzdCBBZHVsdCBTaXRlcyBPbiBUaGUg
d2ViIEFsbCBZZWFyIA0KQWxsIEZyZWUuIE5ldmVyIFBheSBBbm90aGVyIERpbWUgVG8gR2V0
IEludG8gQSBTZXggU2l0ZSANCkFnYWluLjwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PGZvbnQg
Y29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9NT48YnI+DQo8L2ZvbnQ+PC9mb250PjwvZm9u
dD48Zm9udCBjb2xvcj0iI0ZGMDA4MCI+PGZvbnQgc2l6ZT03PjxzdHJvbmc+Qk9OVVMhISE8
YnI+DQo8L3N0cm9uZz48L2ZvbnQ+PGZvbnQgc2l6ZT01PjxzdHJvbmc+RlJFRSBYWFggQ2hh
dCBSb29tcyEhITwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249Y2VudGVy
PjxhIGhyZWY9Imh0dHA6Ly8yMDUuMjE2LjI0OS4xOC9jZ2ktc2hsL2RibWwuZXhlP3RlbXBs
YXRlPS9hcy9zaWdudXAuZGJtJmFtcDtzaXRlPXN0MzUzMjUiPjxmb250IGNvbG9yPSIjODAw
MDgwIj48Zm9udCBzaXplPTY+PHN0cm9uZz5JIFdBTlQgVEhFIFBBU1NXT1JEIE5PVzwvc3Ry
b25nPjwvZm9udD48L2ZvbnQ+PC9hPjwvcD4NCjwvYm9keT4NCg0KPC9odG1sPg0K
- --_-=176
---------------------------
End of New-News digest
**********************
From ibrahim.ndoye@ocegr.fr  Mon Jul 21 00:15:46 1997
From: Ibrahima Ndoye <ibrahim.ndoye@ocegr.fr>
Date: Mon Jul 21 00:15:49 PDT 1997
Subject: Remove
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please remove ne from the list
Thanks !
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Mon Jul 21 04:01:08 1997
From: daemon@csg.lbl.gov
Date: Mon Jul 21 04:01:11 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jul 21 04:01:05 PDT 1997
        Subject: Re: MKS and Tornado
        Subject: Re: Is VxWorks on Mars?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: MKS and Tornado
Date: Sun, 20 Jul 1997 13:57:15 -0600
From: davidm@ComponentSoftware.com
Organization: Deja News Usenet Posting Service
Message-ID: <869417750.19452@dejanews.com>
References: <01bc8c74$fe77f2a0$3d6ec4cf@mblack.clark.net> <868779300.26006@dejanews.com> <5qjtb5$lae@idiom.com>
In article <5qjtb5$lae@idiom.com>,
  nigel@idiom.com (Nigel Standing) wrote:
>
> In article <868779300.26006@dejanews.com>,
>  <davidm@ComponentSoftware.com> wrote:
> >In article <01bc8c74$fe77f2a0$3d6ec4cf@mblack.clark.net>,
> >  "Mitchell Black" <mblack@synaptyx.com> wrote:
>
> >> Anyone out there have any experience integrating MKS Source Integrity with
> >> Wind River's Tornado IDE.
>
> > You might want to have a look at CS-RCS -- a GNU RCS compatible revision
> > control system that is fully integrated with Windows 95/NT. CS-RCS
> > supports simple command-line interface for seamless integration with any
> > IDE.
>
> Also any information about using CS-RCS in a mixed PC/Unix environment ?
> Ie. if the files are NFS mounted from (say) a Sun, can they be
> accessed via CS-RCS on the PC's, and regular RCS (or even CVS) on
> the Sun ?
>
> TIA,
>
> Nigel -
>
CS-RCS archive files are 100% GNU RCS compatible. We have many sites
using CS-RCS in conjunction with UNIX RCS or CVS (over NFS or Samba). For
full details, visit http://www.ComponentSoftware.com/csrcsfaq/install.htm
Another benefit of using CS-RCS is transparent handling of the different
UNIX/PC line-break sequence.
- ------------
David Matyas			davidm@ComponentSoftware.com
ComponentSoftware		http://www.ComponentSoftware.com
Makers of CS-RCS -- GNU RCS compatible revision control system
for Windows 95/NT.
- -------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Is VxWorks on Mars?
Date: 20 Jul 1997 22:35:47 -0500
From: kreymer@ea831.fnal.gov (Art Kreymer)
Organization: Fermilab, Batavia IL USA
Message-ID: <5qulej$r56@ea831.fnal.gov>
References: <33c12cc7.10369094@nntp.ix.netcom.com> <5pu2g4$nal@apollo.csd.net> <5qk5al$sh1@ea831.fnal.gov>
To clarify and update my earlier posting which unfairly accused VxWorks 5.1.1
of not merging free'd memory properly:
I've learned that our local problems are due to small memory leaks in the
networking routines, and not any intrinsic VxWorks kernel problem.
For the next few years there will very little network activity on Mars,
so that's not their problem.
---------------------------
End of New-News digest
**********************
From pcrescio@dsrnet.com  Mon Jul 21 11:23:09 1997
From: "Crescioli, Phil" <pcrescio@Dsrnet.Com>
Date: Mon Jul 21 11:23:12 PDT 1997
Subject: subscription request
subscription request
pcrescioli@dsrnet.com
From cruz@xyplex.com  Mon Jul 21 13:57:45 1997
From: Roger Cruz <cruz@xyplex.com>
Date: Mon Jul 21 13:57:48 PDT 1997
Subject: Memory protection for x86
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone found a clever way to write protect memory without having
to buy WRS' VxVMI package?  The hardware is on the chip (x86), could it
be as simple as writing to a few registers to enable page protection?
All suggestions are welcome.
--
Roger Cruz                           cruz@xyplex.com
Xyplex Networks                      w: 508-952-4783
295 Foster Street                    f: 508-952-4887
Littleton, MA 01460
--MimeMultipartBoundary--
From simone@linac.ikp.physik.th-darmstadt.de  Tue Jul 22 00:53:29 1997
From: "Dipl.-Phys. S. Richter, IKP, Tel. 16-5152"
Date: Tue Jul 22 00:53:32 PDT 1997
Subject: VxWorks Drivers
Hi,
I'm using VxWorks 3.2 on am AXPvme (Alpha processor), Digital UNIX V3.2 as
host. Now I've got to develop two kind of drivers. One is for a Q-Bus to
VMEbus
Adapter (On the Q-Bus I got over 200 devices to control) and for various
ADC-Boards.In the demo sources no actual driver is supplied for VME devices.
Wouldn't it be approporiate to write a driver for that?
The docs say that I may inculde my personal drivers - do I have to modify
usrConfig.c to add my new drivers? Are there any demo-codes out there for
VMEbus
devices (any I/O Boards)?
Forgive if all my questions are answered somewhere else, please point me
into
the right direction  - I'm totally new to this kind of computing.
Any help is appreciated!
	Simone
----------------------------------------------------------------------------
Dipl.-Phys. Simone Richter	simone@linac.ikp.physik.th-darmstadt.de
Institut f. Kernphysik
Schlossgartenstr. 9
64289 Darmstadt
Tel: +49 (0) 6151 / 16-5121, 16-3323
Fax: +49 (0) 6151 / 16-4321
From cruz@xyplex.com  Tue Jul 22 06:08:31 1997
From: Roger Cruz <cruz@xyplex.com>
Date: Tue Jul 22 06:08:35 PDT 1997
Subject: Re: Memory protection for x86
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dan Hildebrand wrote:
> I'm surprised Wind River charges for memory protection.
 So are we.  That should be a part of the OS just like a file system
would be.
> Do you know how comprehensive the protection is?  ie: read only code, inter-process address
> space protection, protected kernel space, etc.
 I think it's rather limited.  You can protect code & data sections on a
global basis.  To control it at the task level, the task itself has to
take care of a lot of the details, if I'm not mistaken.  Right now, I
only care for write-protection of the int. vec. table which is at 0 by
default.  A big problem since some programmers don't check pointers
before using them.
--
Roger Cruz                           cruz@xyplex.com
Xyplex Networks                      w: 508-952-4783
295 Foster Street                    f: 508-952-4887
Littleton, MA 01460
--MimeMultipartBoundary--
From Bob.Little@aeronix.com  Tue Jul 22 08:03:35 1997
From: Bob Little <Bob.Little@aeronix.com>
Date: Tue Jul 22 08:03:38 PDT 1997
Subject: snprintf
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hi,
How do I get at the Private functions used by VxWorks?
I need to print to a string of a fixed length.  I don't want to use
some huge temporary buffer and then copy just the data I need to the
target buffer.  I want to use the "snprintf" function, but VxWorks
keeps it Private.  The header file that contains the prototype is
<private/stdioP.h>.
When I load an object that contains a reference to this function, I get
an unresolved external error.
Do I need to search through every library and uncrate the snprintf function
and link it directly with my object?  I can only assume that they
declared the function static, so I'm not sure this approach will work.
The snprintf function isn't protected like this under Unix, and the prototype
appears right in the "stdio.h" header.
-Bob
--
Bob Little                             Bob.Little@aeronix.com
Aeronix, Inc.                          Ph:  (407) 984-1671 (ext 15)
1775 West Hibiscus Blvd, Suite 304     Fax: (407) 984-0366
Melbourne, FL 32901-2628
--MimeMultipartBoundary--
From kb+@andrew.cmu.edu  Tue Jul 22 11:34:52 1997
From: Kevin Bradley <kb+@andrew.cmu.edu>
Date: Tue Jul 22 11:34:54 PDT 1997
Subject: C++ Compiler Seg Fault?
I have Tornado 1.0 for Windows 95/NT.  I recently obtained some
source code in C++ for an MPEG Audio decoder for Linux, which
I'm trying to port to my x86 target.
The problem is this:  the compiler dies, without spitting out
any error messages.  Here's a sample dump (I added -v -t to
the command line switches, which dump out _all_ kinds of info,
except for the useful stuff):
-------------------------------------------------------------------------
make -C mpegsound all
cc386  -IE:\Tornado/target/h   -DCPU=I80486 -fno-builtin -nostdinc
-nostdinc++ -v -t -DVXW
ORKS -DPACKAGE=\"splay\" -DVERSION=\"0.5\" -I.    -c binput.cpp
Reading specs from
E:\Tornado\host\x86-win32\lib\gcc-lib\i386-wrs-vxworks\2.6-95q2\specs
gcc version 2.6-95q2
 E:\Tornado\host\x86-win32\lib\gcc-lib\i386-wrs-vxworks\2.6-95q2\cpp.exe
-lang-c++ -nostdinc -nostdinc++ -v -IE:\Tornado/target/h -I. -iprefix
E:\Tornado\host\x86-win32\lib\gcc-lib
\i386-wrs-vxworks\2.6-95q2\ -undef -D__GNUC__=2 -D__GNUG__=2
-D__cplusplus -D__GNUC_MINOR__=6 -Di386 -D__i386__ -D__i386 -DCPU=I80486
-DVXWORKS -DPACKAGE="splay" -DVERSION="0.5" binput.cpp
c:\tmp\cca50819.ii
-------------------------------------------------------------------------
At this point, the following error message is generated:
CC386 caused an invalid page fault in
module CC386.EXE at 0137:0040ad45.
Registers:
EAX=0066059c CS=0137 EIP=0040ad45 EFLGS=00010216
EBX=00000041 SS=013f ESP=0064fc00 EBP=0064fc2c
ECX=006654d0 DS=013f ESI=00000000 FS=33e7
EDX=006654db ES=013f EDI=815af3ec GS=0000
Bytes at CS:EIP:
8b 4e 04 80 e1 fc 3b c8 74 05 e8 22 1a 00 00 8b
Stack dump:
815aee14 00403392 006605a0 815af3ec 815aee14 00000041 0000000a 00000011
006605a0 006654d0 00000013 0064fc44 004033d3 00665324 815af3ec 815aee14
I've been able to compile other C++ code with no problems.  This
code may be special because it has some inherited classes and
virtual functions, but otherwise seems innocuous.
The following questions spring to mind.
    1) The code compiles with gcc 2.7.2 under Linux (same machine, multi
       boot).  This is gcc 2.6.  Is this a "GCC 2.6.X can't handle C++
       well" problem, or is something deeper going on?
    2) Is this a "Gee, you're running under a Microsoft product,
       so all bets are off" problem?
    3) Is this a "You should upgrade to 1.0.1" (not an option for
       me due to $) problem?
    4) I can't generate an x86-vxworks cross compiler from the
       gcc sources because it's not a listed target.  i960-vxworks,
       m68k-vxworks, others exist, but not x86.  Any ideas on
       how to generate a port?  I took a stab at it, but there's
       complications with x86 -- something about having to define
       an assembler format, lots of undefined symbols, etc.
       Binutils was pretty easy, gcc is the hard one.
       This has come up in other places, so it maybe a general
       problem.  Anybody know who did the orignal port (Cygnus?
       Should I contact them?)
I appreciate anything anybody knows!
                                                        -- Kevin
From jiaqp@nuhepz.phys.nwu.edu  Tue Jul 22 12:01:50 1997
From: "QiuPing Jia" <jiaqp@nuhepz.phys.nwu.edu>
Date: Tue Jul 22 12:01:57 PDT 1997
Subject: transfer data through the socket
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Hi, there,
   I am having problem installing the socket to transfer the data between
SGI Unix and 68k, The SGI use IRIX 5.3, the 68k is MVME 162 with vxWorks
installed. The following is how I install the connection.
   On SGI, I open the socket, set socket option to SO_REUSEADDR and
SO_KEEPALIVE, and connect it to 68k's socket, then write a message to socket.
After these, I use a loop through whatever number of events, and fist read a
structure which has the byte number, then read the all bytes for a event.
   On 68k, I open the socket, set socket option to SO_REUSEADDR and
SO_KEEPALIVE, bind and listen to it. and wait to get the information from
client. After I get connection from client, I go through a loop to write a
structure of bytes number of one event to socket, and then write the whole
event to the socket.
    The strange thing is: When I write events with around 1000 bytes, it works
fine. when the event is larger than that, the client go through the whole
reading loop after the first read without wait for the data from 68k. Of
course, it gets all wrong data after first event. Do you have any idea what
should I do to solve this problem?
Thanks a lot,
Qiuping
Northwestern University
---End of forwarded mail from <jiaqp> ("QiuPing Jia")
--MimeMultipartBoundary--
From TOM2910@aol.com  Tue Jul 22 12:14:52 1997
From: TOM2910@aol.com
Date: Tue Jul 22 12:14:55 PDT 1997
Subject: Question about re-entrant or task-switch safe function ?
Hello,
Where can I find the list of the API that is not re-entrant
or non task-switch safe for the VxWorks ?
( I have functions that uses the string API and socket and DOS-file
operation,
and I have data being changed within these operations randomly.)
Does anyone have this similar problem ?
Thanks.
-Tom
From pardo@rti.com  Tue Jul 22 13:11:25 1997
From: Gerardo Pardo-Castellote <pardo@rti.com>
Date: Tue Jul 22 13:11:28 PDT 1997
Subject: Re: C++ Compiler Seg Fault?
Like you said 2.6 does not handle C++ well. For one thing it does
not support templates... I wouldn't expect this to segfault the
compiler though.
You can always build 2.7.2 yourself from the GNU source. But be warned,
C++ code compiled with gcc 2.6 will not link with source compiled with
2.7 due their use of different conventions in symbol mangling.
	-Gerardo
>> I have Tornado 1.0 for Windows 95/NT.  I recently obtained some
>> source code in C++ for an MPEG Audio decoder for Linux, which
>> I'm trying to port to my x86 target.
>>
>> The problem is this:  the compiler dies, without spitting out
>> any error messages.  Here's a sample dump (I added -v -t to
>> the command line switches, which dump out _all_ kinds of info,
>> except for the useful stuff):
>>
>> -------------------------------------------------------------------------
>> make -C mpegsound all
>> cc386  -IE:\Tornado/target/h   -DCPU=I80486 -fno-builtin -nostdinc
>> -nostdinc++ -v -t -DVXW
>> ORKS -DPACKAGE=\"splay\" -DVERSION=\"0.5\" -I.    -c binput.cpp
>> Reading specs from
>> E:\Tornado\host\x86-win32\lib\gcc-lib\i386-wrs-vxworks\2.6-95q2\specs
>> gcc version 2.6-95q2
>>  E:\Tornado\host\x86-win32\lib\gcc-lib\i386-wrs-vxworks\2.6-95q2\cpp.exe
>> -lang-c++ -nostdinc -nostdinc++ -v -IE:\Tornado/target/h -I. -iprefix
>> E:\Tornado\host\x86-win32\lib\gcc-lib
>> \i386-wrs-vxworks\2.6-95q2\ -undef -D__GNUC__=2 -D__GNUG__=2
>> -D__cplusplus -D__GNUC_MINOR__=6 -Di386 -D__i386__ -D__i386 -DCPU=I80486
>> -DVXWORKS -DPACKAGE="splay" -DVERSION="0.5" binput.cpp
>> c:\tmp\cca50819.ii
>> -------------------------------------------------------------------------
>>
>> At this point, the following error message is generated:
>>
>> CC386 caused an invalid page fault in
>> module CC386.EXE at 0137:0040ad45.
>> Registers:
>> EAX=0066059c CS=0137 EIP=0040ad45 EFLGS=00010216
>> EBX=00000041 SS=013f ESP=0064fc00 EBP=0064fc2c
>> ECX=006654d0 DS=013f ESI=00000000 FS=33e7
>> EDX=006654db ES=013f EDI=815af3ec GS=0000
>> Bytes at CS:EIP:
>> 8b 4e 04 80 e1 fc 3b c8 74 05 e8 22 1a 00 00 8b
>> Stack dump:
>> 815aee14 00403392 006605a0 815af3ec 815aee14 00000041 0000000a 00000011
>> 006605a0 006654d0 00000013 0064fc44 004033d3 00665324 815af3ec 815aee14
>>
>>
>> I've been able to compile other C++ code with no problems.  This
>> code may be special because it has some inherited classes and
>> virtual functions, but otherwise seems innocuous.
>>
>> The following questions spring to mind.
>>
>>     1) The code compiles with gcc 2.7.2 under Linux (same machine, multi
>>        boot).  This is gcc 2.6.  Is this a "GCC 2.6.X can't handle C++
>>        well" problem, or is something deeper going on?
>>
>>     2) Is this a "Gee, you're running under a Microsoft product,
>>        so all bets are off" problem?
>>
>>     3) Is this a "You should upgrade to 1.0.1" (not an option for
>>        me due to $) problem?
>>
>>     4) I can't generate an x86-vxworks cross compiler from the
>>        gcc sources because it's not a listed target.  i960-vxworks,
>>        m68k-vxworks, others exist, but not x86.  Any ideas on
>>        how to generate a port?  I took a stab at it, but there's
>>        complications with x86 -- something about having to define
>>        an assembler format, lots of undefined symbols, etc.
>>        Binutils was pretty easy, gcc is the hard one.
>>
>>        This has come up in other places, so it maybe a general
>>        problem.  Anybody know who did the orignal port (Cygnus?
>>        Should I contact them?)
>>
>>
>> I appreciate anything anybody knows!
>>
>>
>>                                                         -- Kevin
From mea@mclean.sparta.com  Tue Jul 22 13:33:02 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Tue Jul 22 13:33:05 PDT 1997
Subject: Re: transfer data through the socket
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
At 12:01 PM 7/22/97 PDT, you wrote:
>Submitted-by jiaqp@nuhepz.phys.nwu.edu  Tue Jul 22 12:01:50 1997
>Submitted-by: "QiuPing Jia" <jiaqp@nuhepz.phys.nwu.edu>
>
>--MimeMultipartBoundary
>Content-Type: text/plain; charset=3Dus-ascii
>
[snip]
>
>    The strange thing is: When I write events with around 1000 bytes, it
works
>fine. when the event is larger than that, the client go through the whol=
e
>reading loop after the first read without wait for the data from 68k. Of
>course, it gets all wrong data after first event. Do you have any idea w=
hat
>should I do to solve this problem?
>
Greetings!
  The situation that I believe that you're experiencing is as a result of
the protocol stack fragmenting the the inbound PDU because of either
MTU or mbuf limitations.  As a result, your message only comes across
in one piece if it's size is < 1000 bytes.  A bit of defensive programmin=
g
will address the problems that fragmentation can cause as will be shown
in the following code snippet.
Also, your message is a little unclear as to whether you're running the=20
sockets in non-blocking mode or not.  I'll assume not, but if you are,=20
then you'll need additional code to check for the EWOULDBLOCK condition
resulting from the read call.  This snippet is using a 2K char buffer,=20
but structures will work as well.
Try this approach to see if it fixes your problem:
#define HEADER_LENGTH 	2
#define MAX_LENGTH	2050
struct
{
	unsigned short 	length;
	char			buffer[2048];
} msg;
char *msgPtr;
int numleft,nbytes,fd;
(open & bind socket here)
numleft =3D HEADER_LENGTH;
msgPtr =3D (char *)msg;
/* read the "length" field first */
while(numleft)
{
	nbytes =3D read(fd,msgPtr,numleft);
	numleft -=3D nbytes;
	msgPtr +=3D nbytes;
}
/* Now save the length for the next pass */
numleft =3D msg.length;
while(numleft)
{
	nbytes =3D read(fd,msgPtr,numleft);
	numleft -=3D nbytes;
	msgPtr +=3D nbytes;
}
/* null terminate if necessary */
msg.buffer[msg.length] =3D =910=92;
(use msg.buffer)
  In the best case, there would be two separate calls to the read
(one for the length, one for the rest of the message).  However,
the protocol stack may deliver the entire message in one, two or more
pieces depending on the max transfer unit (MTU) and how busy the
stack is at the time.  If you assume that the entire message comes
in one piece, then everything lines up OK.  But, the read/recv call
will return when even 1 byte is ready to be read.  You *MUST* check
the byte count return from the read/recv call and adjust your pointers
accordingly or your message boundaries will be hopelessly lost and data
bytes start getting interpreted as length bytes etc.
HTH,
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
     __       Real-Time System Development, Integration, Training and Ser=
vices
    //\\
   //  \\     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.spart=
a.com
 \\ \  / //   McLean, VA 22102
  \\ \/ //                             "Software development is like maki=
ng
   \\  //                               a baby... You can't make a baby i=
n one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
--MimeMultipartBoundary--
From froeber@bbn.com  Tue Jul 22 18:41:13 1997
From: Fred Roeber <froeber@bbn.com>
Date: Tue Jul 22 18:41:16 PDT 1997
Subject: Re: transfer data through the socket
--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Jul 1997, QiuPing Jia wrote:
>    On SGI, I open the socket, set socket option to SO_REUSEADDR and
> SO_KEEPALIVE, and connect it to 68k's socket, then write a message to socket.
> After these, I use a loop through whatever number of events, and fist read a
> structure which has the byte number, then read the all bytes for a event.
>
>    On 68k, I open the socket, set socket option to SO_REUSEADDR and
> SO_KEEPALIVE, bind and listen to it. and wait to get the information from
> client. After I get connection from client, I go through a loop to write a
> structure of bytes number of one event to socket, and then write the whole
> event to the socket.
I am guessing you are using TCP protocol (vs UDP).  In that case there is
issue that you can't assume that data will be passed in the same size
chunks as you write it.  When using TCP you really should use functions
to read/write data that can process the data in pieces and keep looping
until all the data is processed.  The idea is that if you try to write/read
some number of bytes, only part of the data may be handled and you have
to try again to handle the rest of the data.  Check out a networking book
like "UNIX Network Programming" by W Richard Stevens for details.  He has
functions to do reads and writes that you can copy.  Good luck.  Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
--MimeMultipartBoundary--
From leonid@wrs.co.il  Wed Jul 23 02:57:16 1997
From: leonid@wrs.co.il (Leonid Rosenboim)
Date: Wed Jul 23 02:57:20 PDT 1997
Subject: X.25 on VxWorks
Dear fellow VxWorkers,
Has anyone been succesfully using X.25 as part of a VxWorks application ?
If so, where did you obtain your X.25 software ?
Although X.25 is definitely on its way to oblivion, there still
are some project who need to use it.
Any inout will be welcome.
-----------------------------------------------------------------------
| Leonid Rosenboim                   | Phone: +972-3-559-8144
| Technical Manager                  | Fax:   +972-3-559-8244
| Wind River Systems Israel          | E-Mail: leonid@wrs.co.il
| P.O.Box 11502, AZUR 58017, Israel  | WWW: http://www.wrs.com
| Disclaimer: Opinions expressed herein are my own, and may or
|	    may not agree with Wind River corporate policy or decisions.
-----------------------------------------------------------------------
From daemon@csg.lbl.gov  Wed Jul 23 04:00:53 1997
From: daemon@csg.lbl.gov
Date: Wed Jul 23 04:00:56 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jul 23 04:00:48 PDT 1997
        Subject: Re: TCP/IP-Socket
        Subject: FREE 2000 $ex-WebSites FREE! @?
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: TCP/IP-Socket
Date: Sat, 12 Jul 1997 18:54:10 -0400
From: Mark R Sibenac <sibster+@CMU.EDU>
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA
Message-ID: <Ynm0gG200YUw03j300@andrew.cmu.edu>
References: <33C63D0E.2EC0@mch.scn.de>
Excerpts from netnews.comp.os.vxworks: 11-Jul-97 TCP/IP-Socket by Stefan
Eifert@mch.scn.de
> 1. read doesn`t return EOF, as described in the reference manual, why ?
>
> 2. the physical connection between server and client is lost, but the
>    logical still exists. The client calls some write's. Are these
>    write's stored in a buffer during the connection is lost and send to
>    the server, when the physical connection is repaired ?
>    If there is a write-buffer and this buffer is full, does write
>    return -1 (Error) ?
>
> 3. are there known bugs in the routines: socket, connect, select,
>    read, write and ioctl(....,FIONREAD,....) ?
I had a similiar experience with a socket connection that would die
every once in a while. I expected the read to return EOF when the socket
died, but it never did. Later I learned that it returns 0 when the
connection no longer exists.
Hope that helps,
Mark
---------------------------
Newsgroups: comp.os.vxworks
Subject: FREE 2000 $ex-WebSites FREE! @?
Date: 21 Jul 1997 22:07:03 GMT
From: 18q34757@compuserve.com
Organization: fHdfoljj Ifnc.
Message-ID: <5r0mi7$3f9@news1-alterdial.uu.net>
This is a multi-part message in MIME format.
- --_-=772
Content-type: text/html; name="Sex~1.htm"
Content-transfer-encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9JRVRGLy9EVEQgSFRNTC8vRU4iPg0KDQo8aHRt
bD4NCg0KPGhlYWQ+DQo8dGl0bGU+U0VDUkVUIFBBU1NXT1JEIEZPUiBBRFVMVCBTSUdIVFM8
L3RpdGxlPg0KPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3NvZnQgRnJv
bnRQYWdlIDEuMSI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9IiNDMEMwQzAiIHRleHQ9
IiM4MEZGRkYiIGxpbms9IiMwMDAwRkYiIHZsaW5rPSIjMDAwMEZGIiBhbGluaz0iI0ZGMDAw
MCI+DQo8ZGl2IGFsaWduPWNlbnRlcj48Y2VudGVyPg0KPHRhYmxlIGJvcmRlcj01IGNlbGxw
YWRkaW5nPTI+DQo8dHI+PHRkIGFsaWduPWNlbnRlciB3aWR0aD0xMDAlPjxmb250IGNvbG9y
PSIjRkZGRjAwIj48Zm9udCBzaXplPTc+PGI+RlJFRSEgRlJFRSEgRlJFRSE8YnI+DQo8L2I+
PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT01PjxiPlRI
QVQnUyBSSUdIVC4uLiBDT01QTEVURUxZIDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT02PjxiPkZS
RUUhITwvYj48L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjMDAwMEZGIj48Zm9udCBzaXpl
PTU+PGI+PGk+PGJyPg0KRU5URVIgVEhST1VHSCBBRFVMVFNJR0hUUyAmIzE2OTsgPC9pPjwv
Yj48L2ZvbnQ+PGZvbnQgc2l6ZT02Pjxicj4NCjwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9
IiNGRkZGMDAiPjxmb250IHNpemU9Nz48Yj5JVCdTIEZSRUUhISEhITwvYj48L2ZvbnQ+PC9m
b250PjwvdGQ+PC90cj4NCjwvdGFibGU+DQo8L2NlbnRlcj48L2Rpdj4NCjxwIGFsaWduPWNl
bnRlcj48Zm9udCBGQUNFPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzIyMTY1QSI+
PGZvbnQgc2l6ZT03PiA8L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjRkYwMDAwIj48Zm9u
dCBzaXplPTc+T05FIFBBU1NXT1JEIDxmb250IEZBQ0U9IkNvbWljIFNhbnMgTVMiPjxicj4N
CjwvZm9udD48L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIjMjIxNjVBIj48Zm9udCBzaXpl
PTU+IDwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9NT48
c3Ryb25nPkdFVFMgWU9VIFVOTElNSVRFRCBGUkVFIEFDQ0VTUyBUTyBPVkVSIA0KMTgwMCsg
T0YgVEhFIEhPVFRFU1QgQURVTFQgU0lURVMgPC9zdHJvbmc+PC9mb250PjwvZm9udD48L3A+
DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9NT48
c3Ryb25nPklGIFlPVSBBUkUgVElSRUQgT0YgUEFZSU5HIFRPIEdFVCBJTlRPIFNFWCANClNJ
VEVTLi4uPC9zdHJvbmc+PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+PGZv
bnQgc2l6ZT01PjxzdHJvbmc+IDwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PGZvbnQgY29sb3I9
IiMwMEZGRkYiPjxmb250IHNpemU9NT5PbmUgUGFzc3dvcmQgaXMgYWxsIHlvdSBuZWVkISEh
PGJyPg0KPC9mb250PjwvZm9udD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgRkFDRT0i
Q29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMyMjE2NUEiPjxmb250IHNpemU9Nj4gPC9m
b250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT02PjxzdHJvbmc+
TE9PSyBXSEFUIFlPVSBHRVQhPC9zdHJvbmc+PC9mb250PjwvZm9udD48L3A+DQo8cCBhbGln
bj1jZW50ZXI+PGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMyMjE2
NUEiPjxmb250IHNpemU9NT4gPC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkYwMCI+
PGZvbnQgc2l6ZT01PjxzdHJvbmc+VU5MSU1JVEVEIEZSRUUgQUNDRVNTIFRPIE9WRVIgMTgw
MCsgT0YgDQpUSEUgSE9UVEVTVCBBRFVMVCBTSVRFUzwvc3Ryb25nPiA8Zm9udCBGQUNFPSJD
b21pYyBTYW5zIE1TIj48L2ZvbnQ+PC9mb250PjwvZm9udD48Zm9udCBjb2xvcj0iIzIyMTY1
QSI+PGZvbnQgc2l6ZT01PiA8L2ZvbnQ+PC9mb250PjwvcD4NCjxoMSBhbGlnbj1jZW50ZXI+
PGZvbnQgY29sb3I9IiNGRjAwMDAiPjxmb250IHNpemU9NT48c3Ryb25nPkp1c3QgQSBGZXcg
T2YgVGhlIE92ZXIgMTgwMCsgWFhYIFJhdGVkIFNpZ2h0cyBUaGF0IA0KWW91IENhbiBFbnRl
ciBDb21wbGV0ZWx5IEZyZWUhPGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PC9mb250Pjwv
c3Ryb25nPjwvZm9udD48L2ZvbnQ+PC9oMT4NCjxoMSBhbGlnbj1jZW50ZXI+PGZvbnQgY29s
b3I9IiM4MEZGMDAiPjxmb250IHNpemU9Nj48c3Ryb25nPlRFRU4gU0lURVM8L3N0cm9uZz48
L2ZvbnQ+PC9mb250PjwvaDE+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiPjxmb250IHNpemU9ND4xMDAwIEhPVCBBTkQgTmFLRUQgLSBDZUxlQlJpVGlFUyBBTkQg
VEVFTlMgLSAxMDAxIE51ZGUgRXJvdGljIA0KVGVlbnMgLSAyMCBBbWFUZWVucyAtIDYyMyBO
dWRlIENlbGVicml0aWVzIEFuZCBUZWVucyAtIEFBQSBTTFVUWSANClRFRU5TIC0gQW1hdGV1
ciBUZWVucyAtIEFtYXRldXIgVGVlbnMgRnJvbSBBcm91bmQgVGhlIFdvcmxkIC0gQW1hdGV1
ciANClRlZW5zISAtIENvY2sgSHVuZ3J5IFRlZW5zIC0gQ3VtIERyaW5raW5nIFRlZW5zIC1G
aXN0IEZ1Y2tpbmcgVGVlbnMgLSBIb3QgDQpOdWRlIFRlZW5zIC0gTm90aGluZyBCdXQgVGVl
bnMgLSBUZWVucyBJbiBUcm91YmxlIC0gVHdhdCBTdWNraW5nIFRlZW5zIDwvZm9udD48L2Zv
bnQ+PC9wPg0KPHAgYWxpZ249Y2VudGVyPjxmb250IGNvbG9yPSIjRkYwMDAwIj48Zm9udCBz
aXplPTY+PHN0cm9uZz5BU0lBTiBTSUdIVFM8L3N0cm9uZz48L2ZvbnQ+PC9mb250PjwvcD4N
CjxwIGFsaWduPWNlbnRlcj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT00PkFs
bCBBc2lhbiBUZWVuIC0gQXNpYW4gQmFiZXMgLSBBc2lhbiBCYWJlcyBzaWFuIEJhYmVzISAt
IEFzaWFuIEJlbGxlcyAtIEFzaWFuIA0KQm9uZGFnZSAtIEFzaWFuIEN1dGUgR2lybHMgLSBB
c2lhbiBEZWxpdGVzIC0gQXNpYW4gRXJvcyAtIEFzaWFuIEZsb3dlcnMgLSANCkFzaWFuIEdv
bGQgLSBZb3VuZyBBc2lhbiBXb21lbiAtIEFzaWFuIEhhcmRDb3JlIEFTSUFOIEhBUkRDT1JF
IC0gDQpUSEUgTEVHRU5EIENPTlRJTlVFUyAtIEFTSUFOIEhvbG9zdWl0ZSAtIEFzaWFuIExv
dmUgRG9sbHMgPC9mb250PjwvZm9udD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgY29s
b3I9IiNGRjAwRkYiPjxmb250IHNpemU9Nj48c3Ryb25nPkNFTEVCUklUWSBTSUdIVFM8L3N0
cm9uZz48L2ZvbnQ+PC9mb250PjwvcD4NCjxwIGFsaWduPWNlbnRlcj48Zm9udCBjb2xvcj0i
IzAwMDAwMCI+PGZvbnQgc2l6ZT00PiMxIE51ZGUgQ2VsZWJyaXR5IFBhZ2UgISAtIENlbGVi
d29ybGQgQWNlJ3MgLSBYWFggQ2VsZWJyaXR5IFBpY3MgLSBDZWxlYnJpdHkgDQpDZW50cmFs
IC0gQ2VsZWJyaXR5IENoaWNrIFBhdHRpZXMgLSBDZWxlYnJpdHkgQ3VtYm94IC0gQ2VsZWJy
aXR5IFBpY3R1cmVzIA0KQ2VsZWJyaXR5IFBpY3R1cmVzIEdvbGQgU2l0ZSAtIENlbGVicml0
eSBTa2luIC0gQ2VsZWJyaXR5IFNraW4tQUJDIC0gRGEgUm9ja3MgDQpudWRlIGNlbGVicml0
eSBBcmNoaXZlIC0gTWFya3MgQ2VsZWJyaXR5IFBpY3R1cmVzIDIgLSBOdWRlIENlbGVicml0
eSBBcmNoaXZlIC0gDQpTdGFyTG9jYXRvciAtIENlbGVicml0eSBTdXBlclMgLSBUaGUgRGFp
bHkgTnVkZSBDZWxlYnJpdHkgUGFnZSAtIFRoZSBNdXN0IA0KU2VlIE5VREUgQ2VsZWJyaXR5
IFNpdGUgLSBUaGUgVWx0aW1hdGUgQ2VsZWJyaXR5IENvbGxlY3Rpb24gPC9mb250PjwvZm9u
dD48L3A+DQo8cCBhbGlnbj1jZW50ZXI+PGZvbnQgRkFDRT0iQ29taWMgU2FucyBNUyI+PGZv
bnQgY29sb3I9IiNGRjRGQTciPjxmb250IHNpemU9NT4gPC9mb250PjwvZm9udD48Zm9udCBj
b2xvcj0iIzAwODBGRiI+PGZvbnQgc2l6ZT01PjxzdHJvbmc+VU5MSU1JVEVEIEZSRUUgQUND
RVNTIFRPIE9VUiBYWFggUkFURUQgDQpDSEFUIFJPT008L3N0cm9uZz48L2ZvbnQ+PC9mb250
PjwvcD4NCjxwIGFsaWduPWNlbnRlcj48Zm9udCBGQUNFPSJDb21pYyBTYW5zIE1TIj48Zm9u
dCBjb2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT01PjxzdHJvbmc+R2V0IFlvdXIgQURVTFRT
SUdIVFMgQUdFIFZFUklGSUNBVElPTiANCk1FTUJFUlNISVAgRk9SIE9OTFkgJDEyLjk1LiBJ
dHMgR29vZCBGb3IgQW4gDQpFbnRpcmUgWWVhciBBbmQgR2V0cyBZb3UgVU5MSU1JVEVEIEZS
RUUgQWNjZXNzIA0KSW50byAxODAwKyBPZiBUaGUgQmVzdCBBZHVsdCBTaXRlcyBPbiBUaGUg
d2ViIEFsbCBZZWFyIA0KQWxsIEZyZWUuIE5ldmVyIFBheSBBbm90aGVyIERpbWUgVG8gR2V0
IEludG8gQSBTZXggU2l0ZSANCkFnYWluLjwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PGZvbnQg
Y29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9NT48YnI+DQo8L2ZvbnQ+PC9mb250PjwvZm9u
dD48Zm9udCBjb2xvcj0iI0ZGMDA4MCI+PGZvbnQgc2l6ZT03PjxzdHJvbmc+Qk9OVVMhISE8
YnI+DQo8L3N0cm9uZz48L2ZvbnQ+PGZvbnQgc2l6ZT01PjxzdHJvbmc+RlJFRSBYWFggQ2hh
dCBSb29tcyEhITwvc3Ryb25nPjwvZm9udD48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249Y2VudGVy
PjxhIGhyZWY9Imh0dHA6Ly8yMDUuMjE2LjI0OS4xOC9jZ2ktc2hsL2RibWwuZXhlP3RlbXBs
YXRlPS9hcy9zaWdudXAuZGJtJmFtcDtzaXRlPXN0MzUzMjUiPjxmb250IGNvbG9yPSIjODAw
MDgwIj48Zm9udCBzaXplPTY+PHN0cm9uZz5JIFdBTlQgVEhFIFBBU1NXT1JEIE5PVzwvc3Ry
b25nPjwvZm9udD48L2ZvbnQ+PC9hPjwvcD4NCjwvYm9keT4NCg0KPC9odG1sPg0K
- --_-=772
---------------------------
End of New-News digest
**********************
From jiaqp@nuhepz.phys.nwu.edu  Wed Jul 23 14:50:11 1997
From: jiaqp@nuhepz.phys.nwu.edu (QiuPing Jia)
Date: Wed Jul 23 14:50:14 PDT 1997
Subject: Re: transfer data through the socket
--MimeMultipartBoundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
--MimeMultipartBoundary--
From jiaqp@nuhepz.phys.nwu.edu  Wed Jul 23 14:52:21 1997
From: jiaqp@nuhepz.phys.nwu.edu (QiuPing Jia)
Date: Wed Jul 23 14:52:23 PDT 1997
Subject: job
--MimeMultipartBoundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi, there,
   I am looking for a software developer job with vxWorks, if your company is
hiring, please send me a e-mail at jiaqp@nuhepz.phys.nwu.edu.
Thanks.
--MimeMultipartBoundary--
From jshaw_shade@compuserve.com  Thu Jul 24 02:07:07 1997
From: John Shaw <jshaw_shade@compuserve.com>
Date: Thu Jul 24 02:07:10 PDT 1997
Subject: Re: VxWorks drivers.
--MimeMultipartBoundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Simone, =
Regarding your message on the VxWorks exploder:-
>I'm using VxWorks 3.2 on am AXPvme (Alpha processor), Digital UNIX V3.2 =
as =
>host. Now I've got to develop two kind of drivers. One is for a Q-Bus to=
 =
>VMEbus...
VxWorks 3.2?? Hope you mean VxWorks 5.2, pre-Tornado!
You should look for the Wind River manual that came with VxWorks.
This is the VxWorks Programmer's Guide. You should have a look at
section 4 (I/O System) for info on drivers. If you have written
drivers before, for UNIX perhaps, then the techniques are similar
for VxWorks. There are block and character device drivers with user
entry points and possibly interrupt handlers for the device.
Once the driver is written and compiled, it is loaded as an object
after VxWorks has booted. It can at a later stage be linked into
VxWorks so that it is loaded and initialised at boot-time, but this
is not necessary. A function in the driver must be called to add the
driver to a list maintained by VxWorks. Once added, the usual open,
close, read, write and ioctl calls can then be made.
I might be able to email you a VME device driver if you would find
that helpful.
John Shaw,
Shade (Computer Services) Limited, Calne, Wiltshire, England, UK.
Email to: jshaw_shade@compuserve.com=
--MimeMultipartBoundary--
From ikeda@info.kobelco.co.jp  Thu Jul 24 02:08:13 1997
From: ikeda@info.kobelco.co.jp
Date: Thu Jul 24 02:08:16 PDT 1997
Subject: How to use the vxgdb under GNU Emacs ?
--MimeMultipartBoundary
Content-Type: text/plain; charset="ISO-2022-JP"
HI,
Does anyone know how to use the vxgdb under GNU Emacs (Mule)?
I am trying to use vxgdb under Emacs by these steps.
Step 1 : create "my-gdb" file
        atomic% cat my-gdb
        #!/bin/sh
        crosswind -t 68k -l
Step 2 : crate ".emacs" file
        atomic% cat .emacs
        (setq gdb-command-name "/atomic/ikeda/my-gdb")
Step 3 : run my-gdb under Emacs (M-x gdb)
  The "target", "load", "list", "break", "run" commands are issued to the crosswind from Emacs.  After the "run" command is issued, the display of Emacs is separated and "=>" cursor is displayed when normal gdb, but the display is not separated and "=>" cursor is not displayed when vxgdb.
I think that I must modify the gdb.el file.
Does Anyone know about it ?
------------------------------------------------
Eiji Ikeda.  Kobe Steel Ltd.,
E-mail: ikeda@info.kobelco.co.jp
URL: http://www.kobelco.co.jp/infosys/
------------------------------------------------
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Thu Jul 24 04:01:03 1997
From: daemon@csg.lbl.gov
Date: Thu Jul 24 04:01:07 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jul 24 04:00:58 PDT 1997
        Subject: Re: VxWorks drivers PCMCIA harddrive/interface
        Subject: Re: Graphics functions for 486?
        Subject: Re: VxWorks ROM's on Intel Architecture
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks drivers PCMCIA harddrive/interface
Date: Thu, 10 Jul 1997 18:54:32 -0700
From: Sathyan Iyengar <sathyan@trinc.com>
Organization: Technology Rendezvous Inc.
Message-ID: <33C59258.5BE00E6A@trinc.com>
References: <5ptn23$u9n$1@news00.btx.dtag.de>
Reply-To: sathyan@trinc.com
Martin,
Technology Rendezvous Inc. based in Santa Clara CA, USA has complete
PCMCIA
stack (with card services & socket services) and Client drivers (Flash,
ethernet, Modem,
HardDisk) interface for Tornado. This is available for x86.
Please contact Mr. Bill Densham at 408-566-0280 x:201,
bdensham@trinc.com
for more information.
Thanks,
- -Sathyan
/*********************************************************************
Technology Rendezvous Inc.              Ph  : 408-566-0280 Ext:201
3160, De La Cruz Blvd.                  Fax : 408-566-0284
Suite #101, Santa Clara                 e-mail:  sathyan@trinc.com
CA - 95054,  USA
- -----------------------------------------------------------------------------------------------
We provide Embedded System Solutions for PCMCIA, Flash, Database,
IEEE-1394
********************************************************************/
Martin Sauter wrote:
> Hi everybody,
>
> I am looking for a PCMCIA hardware interface for the PC-104 bus to
> attach a PCMCIA hard drive to a x86 board which is running VxWorks.
> Does
> anyone know a company that offers such hardware and the necessary
> VxWorks drivers?
>
> Thanks in advance
>
> Martin
>
> --
> --------------------------------------------------------------------
> My World Wide Web Sites:
>
> The Solar Car project  :  http://ti-voyager.fbe.fh-weingarten.de/set
> About studying abroad  :  http://ti-voyager.fbe.fh-weingarten.de/tac
>
> --------------------------------------------------------------------
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Graphics functions for 486?
Date: Wed, 23 Jul 1997 23:36:39 -0700
From: John Kevin Fabiani <johnx@wrs.com>
Organization: Wind River Systems
Message-ID: <33D6F7F7.635AAAB4@wrs.com>
References: <jfrancoe-230797121502@jfrancoeur.mitre.org>
Reply-To: johnx@wrs.com
Joseph A. Francoeur wrote:
>
> Hi,
>
> Unless I overlooked something, it seems that there are no graphics
> libraries provided with VxWorks.
> My target is a 486.  I'm looking for
> something similar to the Borland Graphics Interface with functions to plot
> lines, rectangles, do floodfills, etc.  Does anything like this exist for
> VxWorks?
Yes.  3rd party.  I have no recommendation...
> If not, it looks like I can write some routines using the 486
> register functions to write to the VGA card.  I'm assuming *all* the BIOS
> functions are available when VxWorks is downloaded to my target - is this
> true?
No it is not.  The BIOS vectors (int 10h - int 19h) are replaced
by the vxWorks int/exception handlers during initialization.
We do/can NOT use the BIOS at runtime.
> Has anyone used the hook function documented in
> wind/target/src/drv/serial/m6845Vga.c ?  I assume you just add more cases
> to the switch statement to add your own functions, but I don't know what
> that saves you, since you have to remake vxWorks with your newly compiled
> function anyway.
>
> Any help would be appreciated.
>
> Thanks in advance!
> Joe
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: VxWorks ROM's on Intel Architecture
Date: Wed, 23 Jul 1997 23:32:51 -0700
From: John Kevin Fabiani <johnx@wrs.com>
Organization: Wind River Systems
Message-ID: <33D6F713.7C0CDAE7@wrs.com>
References: <01bc9617$c68d6260$e9314c99@tempuser.atlantaga.ncr.com>
Reply-To: johnx@wrs.com
Billy Turchin wrote:
>
> Has anyone ever setup a ROM based VxWorks system on Intel architecture?  If
> so,
> I'm wondering what was involved in setting up such a system.  Even if you
> haven't,
> I'm curious about VxWorks on an X86 machine in general and what problems
> you
> can expect.
>
> Thanks,
>  Billy
The VxWorks pc486 and pc386 BSPs rely on the PC's system
BIOS to initialize the hardware in a PC-AT compatible manner.
(They are PC-AT system BSP's for 80486/80386)
After which, VxWorks bootstraps via the bootstrap mechanisms
offered by the PC-AT BIOS; eg, via an AT-BUS "romCard", a
floppy device, or a hard disk device.  After that the BIOS
is effectively no longer used other than to read ATA information,
etc.  Obviously, since a custom board does not have a BIOS,
one must add the equivalent support for initialization of
peripheral component hardware for the custom board at the
romInit and sysHwInit stages.   Anyway...
The 80x86 will cold boot in REAL (i8086 compatible) mode.
In REAL mode the 80486 may control 20 address lines,
A19-A0 (1MB).
The 80486 CS:EIP pair contains f000:0000fff000 upon
initialization.  This is the linear address of 0xffff0.
This means that upon reset, the processors instruction
pointer points to the last 16 bytes of 1MB.
However, upon reset, the 80486 processor actually holds
the physical address lines, A31 through A20, at a high
level until an intersegment jump instruction is executed.
This is because the base address of the code segment in
the segment descriptor cache register after processor
reset is 0xffff0000) Holding A31-A20 high effectively
logical OR's 0xfff00000 to everything applied to the
local bus until an intersegment jump occurs.
This all means that the reset vector of the processor
is the physical (bus) address of 0xfffffff0.
The processor, after reset, will therefore be using addresses
within the uppermost 64KB of the 32bit (4GB) address space,
from 0xffff0000 to 0xffffffff, until the intersegment jump
is used.
Another point to note is that since the physical reset vector
is 0xfffffff0, the last 16 bytes of physical address space,
the very first instruction needs to be a (short) jump back to
somewhere above 0xffff0000.
So, one needs a bootrom which will jump from the reset vector
(0xfffffff0) to somewhere in the uppermost 64KB (above 0xffff0000),
then make an intersegment jump.
At first glance, I would want to have a text segment at
0xfffffff0 that contains a jump to another text segment
somewhere above 0xffff0000, do some system initialization,
then perform the intersegment jump.
However, this is impossible (as far as I can tell) to accomplish
with a single a.out image and this cannot be done with a linker
script; since the a.out OMF does not support multiple text
or data segments.
One possible approach (which has proven functional) is used
within the /target/unsupported/config/frc386 BSP.
I recommend using this as a template.
This method uses the files romInit0.s, romInit1.s, & romInit.s.
romInit0.s basically contains the (REAL mode/8086) jump
instruction to a lower address in memory still within the
64KB segment.  The CS:EIP address shown is effectively jumping
to the physical address 0xfffffe00 (in rom) since the A31-A20
lines are high after processor reset.  This code appears:
        jmp (0xfe00 - 0xfff0 - 0x3)
Which bring the code execution to the entry point of romInit1.s.
romInit1.s will have 16bit/REAL mode code to clear/mask interrupts,
check the status of the processor, load the IDT and GDT, and switch
the processor into protected mode.   Any special hardware registers
that need to be manipulated may be done here or in romInit.s or in
sysLib.c's sysHwInit() & sysHwInit2().   The code must then jump to
the romInit.s entry point at ROM_BASE_ADRS+8.
For example let's say the ROMs on the custom hardware are
512KB (27040) and begin at 0xfff80000 and end at 0xffffffff
in physical address space.   The rom address map should appear:
object          relative rom adrs     physical adrs
- ---------       -----------------     -------------
romInit0        0x7fff0               0xfffffff0
romInit1        0x7fe00               0xfffffe00
vxWorks_rom 0x0                       0xfff80000 (ROM_BASE_ADRS)
The flow is romInit0 jumps to romInit1,
romInit1 then to vxWorks_rom ROM_BASE_ADRS+8 (0xfff80008).
The first instruction after the reset will be at 0xfffffff0
so that is 0x7fff0 for a 512Kbyte ROM starting at 0xfff80000.
The makefile additions should be similar to:
- ----------------------------
16      $(LD) -o romInit1 -X -N -e _romInit1 -Ttext 0000fe00 romInit1.o
17      $(LD) -o romInit0 -X -N -e _romInit0 -Ttext 0000fff0 romInit0.o
18      $(BINHEX) -a 0 vxWorks_rom | sed -e "/S9/d" > bootrom.hex
19      $(BINHEX) -a 7fe00 romInit1 | sed -e "/S9/d" >> bootrom.hex
20      $(BINHEX) -a 7fff0 romInit0 >> bootrom.hex
Line 16 and 17 will create the romInit0 and romInit1 (a.out OMF)
files linked at the appropriate relative memory addresses and
entry points.
Line 18 creates an Motorola srecord file, addressed at
relative (bootrom) address 0x0 which will be at linear
address 0xfff80000, from vxWorks_rom, and it strips the
Srecord ending character ("/S9/d") from the resulting
Srecord file.
Line 19  creates an Motorola srecord file, addressed
at relative address 0x7fe00 (linear 0xfffffe00), from
romInit1, and it strips the Srecord ending character
("/S9/d") from the resulting Srecord file and appends
it to the bootrom.hex created in line 18.
Line 20  creates an Motorola Srecord file, addressed
at relative address 0x7fff0 (linear 0xfffffff0), from
romInit0, and appends it it to the bootrom.hex from
line 19.  This completes the rom image bootrom.hex.
Again, the resulting bootrom.hex looks like,
        - romInit0 is at 0x7fff0 - 0xfffffff0
        - romInit1 is at 0x7fe00 - 0xfffffe00
        - vxWorks_rom at 0x00000 - 0xfff80000
This will produce an appropriate bootrom image.
Check also: %WIND_BASE%\target\unsupported\config\frc386\*.*
            $WIND_BASE/target/unsupported/config/frc386/*
            Intel 80486 Processors Users Manual.
---------------------------
End of New-News digest
**********************
From WILLIAMK@wpg.lmcda.lmco.com  Thu Jul 24 07:29:41 1997
From: "Williams, Kerry @ WIN" <WILLIAMK@wpg.lmcda.lmco.com>
Date: Thu Jul 24 07:29:44 PDT 1997
Hi,
I have an application that collects data from an VME bus based data
acquisition card. I am *attempting* to log this data to a file on an NFS
drive mounted on my 68k (mvme167) vxWorks target. The problem I am running
into is that the NFS driver does not seem to be writing the data to the
drive when I request it, but instead buffers the data locally in ram. This
buffer does not seem to have a size limit and merrily fills memory until it
finally tromps over some active program space or runs off the end of memory.
During the time the program is running, no data is ever written to the file
opened on the NFS drive.
I am sure it is not the program I am maintaining because if I turn off
storing data to disk, the system will collect data for hours without a
problem. Has anyone found a solution to this quandary?
BTW. "fflush" seems to have no affect on my application, as evidenced by the
following shell snippet.
     -> nfsAuthUnixSet(...)
     -> nfsMount("myHost","/myDir/","/myDir/")
     -> myFile = fopen("/myDir/myFile.txt","w");
     -> fprintf(myFile, "Hello World\n");
     value = 12
     -> fflush(myFile);
     -> #to Unix box:
     ajax% ll /myDir/myFile.txt
     -rw-rw-r-- 1 myUserName 0 Jul 24 08:30 myFile
     -> fclose (myFile);
     ajax% ll /myDir/myFile.txt
     -rw-rw-r-- 1 myUserName  12 Jul 24 08:30 myFile
Aside from constantly opening and closing the file is there anything else I
might try to ensure that my data gets written immediately?
Thank for your help,
Kerry
Kerry Williams
Computer Engineer
Lockheed Martin Canada (Winnipeg)
kerry.williams@lmco.ca
From ztf@one.com  Thu Jul 24 11:22:18 1997
From: Zach Frey <ztf@one.com>
Date: Thu Jul 24 11:22:21 PDT 1997
Subject: Re: X.25 on VxWorks
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 02:57 AM 7/23/97 PDT, you wrote:
>Submitted-by leonid@wrs.co.il  Wed Jul 23 02:57:16 1997
>Submitted-by: leonid@wrs.co.il (Leonid Rosenboim)
>
>Dear fellow VxWorkers,
>
>Has anyone been succesfully using X.25 as part of a VxWorks application ?
>If so, where did you obtain your X.25 software ?
>
>Although X.25 is definitely on its way to oblivion, there still
>are some project who need to use it.
Open Networks Engineering provides X.25 software for VxWorks.   I just
checked our web page (http://www.one.com/), and it doesn't say much more
than "contact Sales for more information", so you should probably start
with email to sales@one.com.
I can't quote you any end-user success stories (I don't even know who all
of our customers are, or which I could talk about), but the sales people
might be able to give you some references.
Hope this helps,
Zach Frey
--
 Zach Frey, Software Engineer           |  Voice:     (313) 996-9900
 Open Networks Engineering, Inc. (ONE)  |  Fax:       (313) 996-9908
 777 E. Eisenhower Parkway, Suite 650   |  Email:     ztf@one.com
 Ann Arbor, MI  48108                   |  Web:       http://www.one.com/
--MimeMultipartBoundary--
From lavery@aimnet.com  Thu Jul 24 12:00:35 1997
From: Jim Lavery <lavery@aimnet.com>
Date: Thu Jul 24 12:00:38 PDT 1997
Subject: Re: comp.os.vxworks newsdigest
--MimeMultipartBoundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Geoff,
Hello world is an astute suggestion.
That is exactly my challange.
When I get that up, I'll have crossed the bridge.
Thanks for the comp. lead,
There is a lot of opportunity in VxWorks land.
Jim
--MimeMultipartBoundary--
From jrm@mclean.sparta.com  Thu Jul 24 14:39:30 1997
From: "John R. Moore III" <jrm@mclean.sparta.com>
Date: Thu Jul 24 14:39:33 PDT 1997
Subject: Re: nfs and fflush question
--------------743D502D6460A098948B5CE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Submitted-by WILLIAMK@wpg.lmcda.lmco.com  Thu Jul 24 07:29:41 1997
> Submitted-by: "Williams, Kerry @ WIN" <WILLIAMK@wpg.lmcda.lmco.com>
>
>  ....
>
>      -> nfsAuthUnixSet(...)
>      -> nfsMount("myHost","/myDir/","/myDir/")
>      -> myFile = fopen("/myDir/myFile.txt","w");
>      -> fprintf(myFile, "Hello World\n");
>      value = 12
>      -> fflush(myFile);
>      -> #to Unix box:
>      ajax% ll /myDir/myFile.txt
>      -rw-rw-r-- 1 myUserName 0 Jul 24 08:30 myFile
>
>      -> fclose (myFile);
>      ajax% ll /myDir/myFile.txt
>      -rw-rw-r-- 1 myUserName  12 Jul 24 08:30 myFile
>
> Aside from constantly opening and closing the file is there anything
> else I
> might try to ensure that my data gets written immediately?
>
Try an  ioctl command and send FIOSYNC.,
ioctl(myfile,FIOSYNC)
 ------------------------------------------------------------
|John R. Moore              | Voice -> 703 448 1683 x229   |
|Principal Engineer         | FAX   -> 703 893 5494        |
|EMAIL:                     | On the WEB!                  |
|jrm@mclean.sparta.com      | http://www.mclean.sparta.com |
|___________________________|______________________________|
|                                     |                    |
|     /\\     SPARTA, Inc.            |                    |
|    ///\\    7926 Jones Branch Drive |                    |
|   /////\\   Suite 900               |                    |
|  /////  \\  McLean, VA 22102        |                    |
| / \\\\\  \\ 703-448-0120            |             |
| \  \\\\\ //                         |                    |
|  \  //////                          |                    |
|   \//////   SPARTA                  |                    |
|    \////    Pride In Performance    |                    |
|     \//     --------------------    |                    |
------------------------------------------------------------
--------------743D502D6460A098948B5CE2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
&nbsp;
<BLOCKQUOTE TYPE=CITE>Submitted-by WILLIAMK@wpg.lmcda.lmco.com&nbsp; Thu
Jul 24 07:29:41 1997
<BR>Submitted-by: "Williams, Kerry @ WIN" &lt;WILLIAMK@wpg.lmcda.lmco.com>
<P>&nbsp;....
<P>&nbsp;&nbsp;&nbsp;&nbsp; -> nfsAuthUnixSet(...)
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -> nfsMount("myHost","/myDir/","/myDir/")
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -> myFile = fopen("/myDir/myFile.txt","w");
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -> fprintf(myFile, "Hello World\n");
<BR>&nbsp;&nbsp;&nbsp;&nbsp; value = 12
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -> fflush(myFile);
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -> #to Unix box:
<BR>&nbsp;&nbsp;&nbsp;&nbsp; ajax% ll /myDir/myFile.txt
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -rw-rw-r-- 1 myUserName 0 Jul 24 08:30 myFile
<P>&nbsp;&nbsp;&nbsp;&nbsp; -> fclose (myFile);
<BR>&nbsp;&nbsp;&nbsp;&nbsp; ajax% ll /myDir/myFile.txt
<BR>&nbsp;&nbsp;&nbsp;&nbsp; -rw-rw-r-- 1 myUserName&nbsp; 12 Jul 24 08:30
myFile
<P>Aside from constantly opening and closing the file is there anything
else I
<BR>might try to ensure that my data gets written immediately?
<BR>&nbsp;</BLOCKQUOTE>
Try an&nbsp; ioctl command and send FIOSYNC.,
<P>ioctl(myfile,FIOSYNC)
<P>&nbsp;<TT>------------------------------------------------------------</TT>
<BR><TT>|John R. Moore&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| Voice -> 703 448 1683 x229&nbsp;&nbsp; |</TT>
<BR><TT>|Principal Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| FAX&nbsp;&nbsp; -> 703 893 5494&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|EMAIL:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| On the WEB!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|jrm@mclean.sparta.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <A HREF="http://www.mclean.sparta.com">http://www.mclean.sparta.com</A>
|</TT>
<BR><TT>|___________________________|______________________________|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; /\\&nbsp;&nbsp;&nbsp;&nbsp; SPARTA, Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp; ///\\&nbsp;&nbsp;&nbsp; 7926 Jones Branch Drive
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp; /////\\&nbsp;&nbsp; Suite 900&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; /////&nbsp; \\&nbsp; McLean, VA 22102&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>| / \\\\\&nbsp; \\ 703-448-0120&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>| \&nbsp; \\\\\ //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp; \&nbsp; //////&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp; \//////&nbsp;&nbsp; SPARTA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp; \////&nbsp;&nbsp;&nbsp; Pride In Performance&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; \//&nbsp;&nbsp;&nbsp;&nbsp; --------------------&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>------------------------------------------------------------</TT>
<BR>&nbsp;</HTML>
--------------743D502D6460A098948B5CE2--
From dleviner@HiWAAY.net  Thu Jul 24 15:13:48 1997
From: David Leviner <dleviner@HiWAAY.net>
Date: Thu Jul 24 15:13:50 PDT 1997
Subject: mv1604 pci memory mapping???
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
VxWorks Gurus,
I am currently writing a VxWorks driver for a General Standards Corp. =
PMC-HPDI (high speed parallel digital interface) card residing in the =
pmc slot on a mv1604 power pc. This hpdi card essentially utilizes PLX =
Technology's PCI 9060 bus interface chip for DMA transfers and PCI =
interfacing. In order to perform a dma transfer, the PLX local dma =
registers must be configured a certain way. I am having trouble filling =
one of those registers (DMA Channel 0 PCI Address Register) with the =
correct information. This register indicates where in PCI memory space =
the dma transfers (reads or writes) will start from. I first tried =
simply mallocing a buffer in DRAM and filling this register with the =
pointer to the start of this buffer - this did not work. Then I tried =
filling the register with a "PCI Memory Space" (refer to mv1604 memory =
map) address - this also did not work (I could not even write to this =
space). Next I tried mallocing memory in DRAM then offsetting the =
starting address with 0x80000000 (this seems to be the PCI to system =
memory offset - refer to programmers guide) - this did not work. I then =
read in the programmers ref guide that DRAM is not forwarded to PCI. My =
question is what system memory space do I use to fill this register and =
how do I get the PCI bus to see it?
Thanks for your help.
Regards,
David Leviner
--------
David Leviner
Systems Engineer
Chandler/May, Inc.
Huntsville, AL
205-722-0175
dleviner@HiWAAY.net
=09
--MimeMultipartBoundary--
From Richard_W_Mattox@ccmail.orl.lmco.com  Thu Jul 24 18:42:02 1997
From: Richard_W_Mattox@ccmail.orl.lmco.com
Date: Thu Jul 24 18:42:05 PDT 1997
Subject: SCSI I/O
--MimeMultipartBoundary
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Hello Fellow VxWorkers,
We are using the MVME1603 SBC in a system that contains 2 SCSI MO devices.  In
our real-time application we want writes to the SCSI MO disks to be preempted
when other higher priority tasks need to run.  However, when using the VxWorks'
SCSI device driver to write data to a SCSI MO disk it appears that no other
tasks are able to run.  Is there a way to configure the driver to solve this
problem?  I am seeing times of 500 ms where the task that is doing the write
will not let other tasks run.  Used WindView to verify how long the task had
control of the processor.  I am using FIOSYNC to ensure the data gets written to
the disk, but I would hope that interrupts would not be locked out at this time
and that timers could go off and release semaphores that would allow higher
priority tasks to get control of the processor.  Also, is there no way to have
file I/O be non-blocking?
TIA,
Rick Mattox
richard.w.mattox@lmco.com
--MimeMultipartBoundary--
From froeber@bbn.com  Thu Jul 24 19:13:11 1997
From: Fred Roeber <froeber@bbn.com>
Date: Thu Jul 24 19:13:14 PDT 1997
Subject: Re: nfs and fflush question
--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 24 Jul 1997, Kerry Williams asked about an NFS file growing too big
and wondered how to flush it:
> >
> >      -> nfsAuthUnixSet(...)
> >      -> nfsMount("myHost","/myDir/","/myDir/")
> >      -> myFile = fopen("/myDir/myFile.txt","w");
> >      -> fprintf(myFile, "Hello World\n");
> >      value = 12
> >      -> fflush(myFile);
> >      -> #to Unix box:
> >      ajax% ll /myDir/myFile.txt
> >      -rw-rw-r-- 1 myUserName 0 Jul 24 08:30 myFile
> >
> >      -> fclose (myFile);
> >      ajax% ll /myDir/myFile.txt
> >      -rw-rw-r-- 1 myUserName  12 Jul 24 08:30 myFile
> >
> > Aside from constantly opening and closing the file is there anything
> > else I
> > might try to ensure that my data gets written immediately?
John R. Moore replied:
>
> Try an  ioctl command and send FIOSYNC.,
>
> ioctl(myfile,FIOSYNC)
I think there is more to the problem here.  If Kerry was just having a
problem with an NFS file not being flushed then the solution for getting
it flushed would be as John mentioned (this is a common issue that is
covered in the VxWorks FAQ).  The fact that continued writing to the
file eventually chews up all memory leads me to believe that Kerry
isn't actually writing the file with the NFS driver but is instead
using the default netDrv driver which keeps files in memory until
they are closed.  You see, even without flushing, the NFS driver writes
out file data as its buffers fill and doesn't allow those buffers to
continue to grow.  The default buffer size is 8KB so writing a bigger
file should allow data to show up if NFS was being used.
The thing to do is make sure the nfsMount suceeds (status not -1) and
then use nfsDevShow, devs, and iosDevShow to check what file systems
are mounted using which drivers.  The file system you pull the VxWorks
kernel off of (as determined by boot line parms) is automatically mounted
using netDrv.  You need to make sure your file isn't using that drive
path.  I think iosFdShow will give you that information.  Anyway, if you
make sure you are using the nfs driver then your file won't continue
chewing up memory but you will still need to do the sync ioctl to flush
your data to disk.  Good luck.   Fred
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |
--MimeMultipartBoundary--
From mmcquade@aa.net  Thu Jul 24 21:20:12 1997
From: Mike McQuade <mmcquade@aa.net>
Date: Thu Jul 24 21:20:15 PDT 1997
Subject: Re: SCSI I/O
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 06:42 PM 7/24/97 PDT, richard.w.mattox@lmco.com wrote:
>We are using the MVME1603 SBC in a system that contains 2 SCSI MO devices.
 In
>our real-time application we want writes to the SCSI MO disks to be
preempted
>when other higher priority tasks need to run.  However, when using the
VxWorks'
>SCSI device driver to write data to a SCSI MO disk it appears that no other
>tasks are able to run.  Is there a way to configure the driver to solve this
>problem?  I am seeing times of 500 ms where the task that is doing the write
>will not let other tasks run.  Used WindView to verify how long the task had
>control of the processor.  I am using FIOSYNC to ensure the data gets
written to
>the disk, but I would hope that interrupts would not be locked out at this
time
>and that timers could go off and release semaphores that would allow higher
>priority tasks to get control of the processor.  Also, is there no way to
have
>file I/O be non-blocking?
>
Rick,
I saw similar things to this (shorter times) with the mv2603, have a look at
my web site for scope plots & code etc...
http://www.aa.net/~mmcquade/rup.html
In the case of the SCSI delays, we had to change a variable, the name of
which I don't have right now, anyhow, this variable (delay) caused the SCSI
writes
to hold off interrupts for long periods of time.
WRS told us the name of this variable to change, and we changed it in our
application on startup.
Feel free to email me tommorow, and I will give you the name of this
variable, and you can see if changing it helps you like it did me.
Which M.O. are you using ?
We are using the Fujitsu 640Mb M.O. disks, and have been quite happy
with them, although the 2048 byte / sector media performance under VxWorks
is way slower than the 512 b/s media.
Mike.
--MimeMultipartBoundary--
From rtp.co.uk!-jfd@rtp.co.uk  Fri Jul 25 02:57:14 1997
From: Julian Day <-jfd@rtp.co.uk>
Date: Fri Jul 25 02:57:17 PDT 1997
Subject: Re: nfs and fflush question
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
the vxWorks Users Group Exploder wrote:
> Submitted-by froeber@bbn.com  Thu Jul 24 19:13:11 1997
> Submitted-by: Fred Roeber <froeber@bbn.com>
>
> --MimeMultipartBoundary
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Thu, 24 Jul 1997, Kerry Williams asked about an NFS file growing
> too big
> and wondered how to flush it:
>
> > >
> > >      -> nfsAuthUnixSet(...)
> > >      -> nfsMount("myHost","/myDir/","/myDir/")
> > >      -> myFile = fopen("/myDir/myFile.txt","w");
> > >      -> fprintf(myFile, "Hello World\n");
> > >      value = 12
> > >      -> fflush(myFile);
> > >      -> #to Unix box:
> > >      ajax% ll /myDir/myFile.txt
> > >      -rw-rw-r-- 1 myUserName 0 Jul 24 08:30 myFile
> > >
> > >      -> fclose (myFile);
> > >      ajax% ll /myDir/myFile.txt
> > >      -rw-rw-r-- 1 myUserName  12 Jul 24 08:30 myFile
> > >
> > > Aside from constantly opening and closing the file is there
> anything
> > > else I
> > > might try to ensure that my data gets written immediately?
>
> John R. Moore replied:
> >
> > Try an  ioctl command and send FIOSYNC.,
> >
> > ioctl(myfile,FIOSYNC)
>
> I think there is more to the problem here.  If Kerry was just having a
>
> problem with an NFS file not being flushed then the solution for
> getting
> it flushed would be as John mentioned (this is a common issue that is
> covered in the VxWorks FAQ).  The fact that continued writing to the
> file eventually chews up all memory leads me to believe that Kerry
> isn't actually writing the file with the NFS driver but is instead
> using the default netDrv driver which keeps files in memory until
> they are closed.  You see, even without flushing, the NFS driver
> writes
> out file data as its buffers fill and doesn't allow those buffers to
> continue to grow.  The default buffer size is 8KB so writing a bigger
> file should allow data to show up if NFS was being used.
>
> The thing to do is make sure the nfsMount suceeds (status not -1) and
> then use nfsDevShow, devs, and iosDevShow to check what file systems
> are mounted using which drivers.  The file system you pull the VxWorks
>
> kernel off of (as determined by boot line parms) is automatically
> mounted
> using netDrv.  You need to make sure your file isn't using that drive
> path.  I think iosFdShow will give you that information.  Anyway, if
> you
> make sure you are using the nfs driver then your file won't continue
> chewing up memory but you will still need to do the sync ioctl to
> flush
> your data to disk.  Good luck.   Fred
>
>    |     Fred J Roeber,  BBN Systems & Technologies     |
>    |   4 John Clarke Road   Middletown, RI  02842-5202  |
>    |         froeber@bbn.com     401-848-3548           |
> --MimeMultipartBoundary--
>
>
  I have seen similar problems, where /<dirname> on a host is mounted as
/<dirname> on VxWorks. Because host:/.../.. is the current directory,
even though the new pathname starts with a /, because it can be found on
host: VxWorks still uses netDrv. I know of two solutions to this:
  1. Use chdir() to change to the nfs mounted directory first.
  2. Mount the directory using a different name to that used on the
host.
HTH,
Julian
--
---------------------------------------------------------------
Julian Day
Real Time Products Ltd.                e-mail:    jfd@rtp.co.uk
Unit 8, Holt Court,                       tel: +44 121 333 6955
Aston Science Park, Jennens Road,         fax: +44 121 333 5433
Birmingham. B7 4EJ. England.              web:    www.rtp.co.uk
---------------------------------------------------------------
--MimeMultipartBoundary--
From jwc@ssd.ray.com  Fri Jul 25 03:55:00 1997
From: Cosgrove <jwc@ssd.ray.com>
Date: Fri Jul 25 03:55:03 PDT 1997
Subject: Re: mv1604 pci memory mapping???
David Leviner <dleviner@HiWAAY.net> writes:
[snip!]
>space). Next I tried mallocing memory in DRAM then offsetting the =
>starting address with 0x80000000 (this seems to be the PCI to system =
>memory offset - refer to programmers guide) - this did not work. I then =
>read in the programmers ref guide that DRAM is not forwarded to PCI. My =
>question is what system memory space do I use to fill this register and =
>how do I get the PCI bus to see it?
David,
I am not a PCI user, however, in setting up VMEbus stuff, I found references to
the following:
config.h#   define DC_RAM_PCI_ADRS (PCI2DRAM_BASE_ADRS)        /* RAM seen from PCI */
mv1600.h#define PCI2DRAM_BASE_ADRS     0x80000000      /* memory seen from PCI bus */
It appears that, like the VME default BSP setup, there is a translation from local
(as seen by the PPC) to PCI bus addressing.  Appearantly, local bus 0 is 0x80000000
on the PCI bus.
Hope This Helps!
John Cosgrove
Raytheon
(401)842-4167 (desk)
(401)842-3511 (lab)
jwc@ssd.ray.com
From daemon@csg.lbl.gov  Fri Jul 25 04:00:55 1997
From: daemon@csg.lbl.gov
Date: Fri Jul 25 04:00:59 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jul 25 04:00:52 PDT 1997
        Subject: Re: Strange Bug
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: Strange Bug
Date: 14 Jul 1997 13:50:53 GMT
From: don@mars.dgrc.doc.ca (Donald McLachlan)
Organization: CRC
Message-ID: <5qdart$dpa@crc-news.doc.ca>
References: <russell.brill-1107971247270001@rmbrill.jpl.nasa.gov>
Reply-To: don@mars.dgrc.doc.ca
Sounds like stack/data corruption to me.  Somehow the stack frame or the constant
"%d\n" is masking a bug in the code for you.  This sort of thing is not easy to
track down.  In the most recent one I found, someone forgot to allow space for the
null when copying a string with strcpy().
Good luck,
Don
- --
Donald McLachlan			e-mail	donald.mclachlan@crc.doc.ca
Communications Research Centre / DRX	office	613-998-2845
3701 Carling Ave.,			fax	613-998-9648
Ottawa, Ontario				labs	613-998-2423 / 613-998-4118
K2H 8S2					home	613-599-6262
Canada
---------------------------
End of New-News digest
**********************
From hao@ct.med.ge.com  Fri Jul 25 08:11:10 1997
From: "L. Hao 5-4267 (Pager)558-6419" <hao@ct.med.ge.com>
Date: Fri Jul 25 08:11:13 PDT 1997
Subject: VxWorks Networking questions
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Hi, all:
    I am developing a VxWorks based network platform for the applications used
by our company's products. It is a library and is called by more than two
applications, so it is also re-entrant. The basic idea is that it is a layer
between applications and OS. It does select(), read(), write(), sock(), and
etc.
   Running reliability test on it, I have run into a problem lately, which only
happens once a while. The test setup is client/server and is pictured below.
The server is a PowerPC running VxWorks while the client is a SGI. They send
messages across back and forth to each other for infinite number of times. The
problem is after thousands of messages, the VxWorks kernel hangs. And of
course, the communication breaks down as well.
-------------|		Ethernet		|----------|
|VxWorks     |----------------------------------|  SGI	   |
|Tasks	     |					|----------|
|------------|
  Does anybody know what could cause the kernel hang? Since the kernel hangs, I
cannot look at any task info from Tornado shell. The monitor with the serial
connection doesn't respond either. Does anybody have any suggestion on how to
debug this kind of problem except for printf? Any suggestion is greatly
appreciated!
  Have a great weekend everybody.
Li Hao
--
Li Hao
G.E. Medical Systems
email:Li.Hao@ct.med.ge.com
Phone:5-4267
--MimeMultipartBoundary--
From shang.ko@das.honeywell.com  Fri Jul 25 15:19:15 1997
From: "Ko, Shang (NM75)" <shang.ko@das.honeywell.com>
Date: Fri Jul 25 15:19:18 PDT 1997
Subject: how to attach handler for mv2603 PCI  interrupt
Greetings:
	We have a PCI device on the PMC of MV2603 board.  I can generate
interrupts from the PCI device, but couldn't figure out how to make to
PPC603 to handle the interrupts.
I noticed that, on MV2603, intConnect() and intEnable() are used to
handle scsi interrupts.  There are also pciInt(), pciIntConnect()
routines available.  But I can't find information on how to use these
routines.  Any advice?
Thanks in advance
Shang Ko
Honeywell Defense Avionics Systems,  Albuquerque, NM
(505) 828-6469
>
From daemon@csg.lbl.gov  Sat Jul 26 04:00:32 1997
From: daemon@csg.lbl.gov
Date: Sat Jul 26 04:00:35 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jul 26 04:00:27 PDT 1997
        Subject: software floatingpoint library
        Subject: set clock (date time) after sysClkRateSet()
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: software floatingpoint library
Date: Wed, 23 Jul 1997 18:49:35 GMT
From: Erhard Schael <eschael@encore.com>
Organization: Encore Computer Corporation
Message-ID: <33D6523F.2D18@encore.com>
Sender: news@encore.com (Usenet News)
.
	Hi everybody
	is there anybody who knows where I can
	download the floating point software for
	MC68LC40 which I can use on vxworks.
	Have a nice time.
	Erhard
- --
***************************************************
Erhard Schael
                      Internet: eschael@encore.com
ENCORE COMPUTER GmbH  Phone: (+49-2103) 2012-27
Itterpark 8-10        Fax:   (+49-2103) 240428
D-40724 Hilden
***************************************************
---------------------------
Newsgroups: comp.os.vxworks
Subject: set clock (date time) after sysClkRateSet()
Date: 14 Jul 1997 13:08:09 GMT
From: schuehle@t-online.de (Martin Sauter)
Organization: Telekom Online Internet Gateway
Message-ID: <5qd8bp$n0n$1@news00.btx.dtag.de>
Reply-To: sauter@fl-sun00.fbe.fh-weingarten.de
Hi everybody,
when I set the system clock tick rate (with sysClkRateSet()) the system
clock (time/date) does not adapt to the new tick rate and either runs
faster or slower. Does anybody know how to tell the system clock to
adapt to a changed tick rate? I tried to use the following functions but
probably made a mistake:
- --------------- pretty bad hack start ------------------
/* set internal clock to 256 ticks a second */
  clock_getres (CLOCK_REALTIME, &curTmSpec);
  logMsg ("timepec %i, %i\n", curTmSpec.tv_sec,
curTmSpec.tv_nsec,0,0,0,0);
  sysClkRateSet (60*4.2666666);  /* O.k. doesnt look very nice... */
  curTmSpec.tv_nsec /= 4.2666666;
  clock_setres (CLOCK_REALTIME, &curTmSpec);
- ----------- pretty bad hack stop -----------------
any ideas?
thanks in advance
Martin
---------------------------
End of New-News digest
**********************
From daemon@csg.lbl.gov  Sun Jul 27 04:01:43 1997
From: daemon@csg.lbl.gov
Date: Sun Jul 27 04:01:46 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jul 27 04:01:40 PDT 1997
        Subject: Re: vxworks on pc hardware (pc104)
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: Re: vxworks on pc hardware (pc104)
Date: 14 Jul 1997 08:54:51 GMT
From: schuehle@t-online.de (Martin Sauter)
Organization: Telekom Online Internet Gateway
Message-ID: <5qcpgr$2th$1@news01.btx.dtag.de>
References: <33C4A0AB.B5A@decrc.abb.de>
Reply-To: sauter@fl-sun00.fbe.fh-weingarten.de
Peter,
> I want to use a PC104 Board with onboard flash.
>
> Can anyone tell me if there is a board-support-package available to boot
> and run the os out of the flash. How big is a kernel with tcp/ip, and
> slip/ppp driver and how many ram do i need for a few tasks (approximate
> figures) ?
I'm using a x86 processor with a PC104 Bus and a Flash disk formated as
a DOS drive. I can boot from that drive using vxload.com a dos program.
This means that the board first boots MS-DOS which then loads my vxworks
object module. The program is supplied by WindRiver with their standard
x86 BSP. The drawback of this scheme is that I can't use the Flash disk
unter VxWorks as there is no driver supplied for it. But LP Elektronik
in Weingarten has developed a driver for the kind of Flashdisk I am
using so we will probably by that one when we need Flashdisk support for
VxWorks.
---------------------------
End of New-News digest
**********************
From eugenel@toledo.condorsys.com  Mon Jul 28 16:26:50 1997
From: eugenel@toledo.condorsys.com (Eugene Leung x714)
Date: Mon Jul 28 16:26:57 PDT 1997
Subject: gpib driver
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone gotten a driver working for National Instruments's NI1014 gpib board
using their supplied routines?  I am having quite a hard time with it.  Any
pointer is apprepricated.
Please reply directly to eugenel@condorsys.com.  Thank you.
Eugene Leung
Condor Systems
--MimeMultipartBoundary--
From eugenel@toledo.condorsys.com  Mon Jul 28 16:33:44 1997
From: eugenel@toledo.condorsys.com (Eugene Leung x714)
Date: Mon Jul 28 16:33:47 PDT 1997
Subject: NI1014 gpib driver
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone gotten a driver working for the National Instruments' NI1014 gpib
board using their supplied routines?  I am having a hard time with it.  Any
pointer is appreciated.
Please reply directly to eugenel@condorsys.com.
Eugene Leung
Condor Systems
--MimeMultipartBoundary--
From Rkane@encanto.com  Mon Jul 28 22:43:37 1997
From: Robert Kane <Rkane@encanto.com>
Date: Mon Jul 28 22:43:40 PDT 1997
Subject: Unix Like File Locking (flock, lockf, fcntl)
--MimeMultipartBoundary
Content-Type: text/plain
Yo Dudes,
Is anyone familiar with a VxWorks equivalent to the Unix flock()?  We
are using the dosFsLib functions to create an extended naming convention
filesystem, and one of the unix applications we would like to port to
our system (a database) relies heavily on the BSD flock() call for
arbitrating access to the records.  I looked through the documentation
for some reference to an equivalent function but did not discover
anything applicable.  Did I miss something obvious?  Is there a third
party solution to this?
Thanks,
Robb Kane
rkane@encanto.com
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Tue Jul 29 04:00:38 1997
From: daemon@csg.lbl.gov
Date: Tue Jul 29 04:00:41 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jul 29 04:00:31 PDT 1997
        Subject: FTP Password
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: FTP Password
Date: 28 Jul 1997 14:55:50 GMT
From: pascal.freiburghaus@stest.ch (Pascal Freiburghaus)
Organization: Switching Test Solutions
Message-ID: <5ribtm$24s@news.alcatel.ch>
Reply-To: pascal.freiburghaus@stest.ch
Hi all,
I have a VxWorks target which runs a FTP-Server and a Telnet Daemon.
Now I want to activate a password to make the access to my target
more restricted. I defined "INCLUDE_SECURITY" and I defined a
LOGIN_USER_NAME and a LOGIN_PASSWORD. This turns on at least the
login security with telnet but I do not know how to turn on
the security of the FTP-Server. The WindRiver books (why do I try to look up
something in the books, it is not there anyway) does not tell anything
about that.
Any hints?
- ---
Pascal Freiburghaus
STS Switching Test Solutions AG, Friesenbergstrasse 75, CH 8055 Zuerich
Phone : +41-1-454-67-27
Fax   : +41-1-454-66-05
mailto: pascal.freiburghaus@stest.ch
- -----------------------------------------------------------------------
- -           Found WinDOS, delete (Y)es, (O)ui, (S)i, (J)a             -
- -----------------------------------------------------------------------
---------------------------
End of New-News digest
**********************
From shang.ko@das.honeywell.com  Tue Jul 29 09:53:00 1997
From: "Ko, Shang (NM75)" <shang.ko@das.honeywell.com>
Date: Tue Jul 29 09:53:03 PDT 1997
Subject: How to attach handler for mv2603 PCI interrupts
Greetings:
	We have a PCI device on the PMC of MV2603 board.  I can generate
interrupts from the PCI device, but couldn't figure out how to make to
PPC603 to handle the interrupts.
I noticed that, on MV2603, intConnect() and intEnable() are used to
handle scsi interrupts.  There are also pciInt(), pciIntConnect()
routines available.  But I can't find information on how to use these
routines.  Any advice?
Thanks in advance
Shang Ko
Honeywell Defense Avionics Systems,  Albuquerque, NM
(505) 828-6469
From hornsbyk@stopwilly.wr.trw.com  Tue Jul 29 13:52:31 1997
From: "Kelly Hornsby" <hornsbyk@stopwilly.wr.trw.com>
Date: Tue Jul 29 13:52:46 PDT 1997
Subject: gcc 2.7.2 for MVME2603/VxWorks
This is a multi-part message in MIME format.
------=_NextPart_000_01BC9C3F.D00B3780
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I'm looking for the configuration files needed to build gcc-2.7 for a MVME
2603 VxWorks configuration.  I'm trying to build a cross compiler on a SGI
machine for the PPC 603.  Any help would be appreciated.  I have seen a few
VxWorks configurations in the distribution (a29k, sparc, i960) but not one
for the PowerPC series.  Any help or comments would be appreciated.
Kelly Hornsby			| hornsbyk@stopwilly.wr.trw.com
TRW				| 912 329 2153 (W)
293 Highway 247 South		| 912 929 7335 (F)
Warner Robins GA 31088		|
These opinions are my own and not those of TRW
"I tried to think and nothing happened!" Curley Howard of "The Three
Stooges"
------=_NextPart_000_01BC9C3F.D00B3780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head></head><BODY bgcolor=3D"#FFFFFF"><p><font size=3D2 =
color=3D"#000000" face=3D"Arial">I'm looking for the configuration files =
needed to build gcc-2.7 for a MVME 2603 VxWorks configuration. &nbsp;I'm =
trying to build a cross compiler on a SGI machine for the PPC 603. =
&nbsp;Any help would be appreciated. &nbsp;I have seen a few VxWorks =
configurations in the distribution (a29k, sparc, i960) but not one for =
the PowerPC series. &nbsp;Any help or comments would be =
appreciated.<br><br>Kelly Hornsby&#009;&#009;&#009;| <font =
color=3D"#0000FF"><u>hornsbyk@stopwilly.wr.trw.com</u><font =
color=3D"#000000"><br>TRW&#009;&#009;&#009;&#009;| 912 329 2153 =
(W)<br>293 Highway 247 South&#009;&#009;| 912 929 7335 (F)<br>Warner =
Robins GA 31088&#009;&#009;| <br>These opinions are my own and not those =
of TRW<br>&quot;I tried to think and nothing happened!&quot; Curley =
Howard of &quot;The Three Stooges&quot;<br><br><br></p>
</font></font></font></body></html>
------=_NextPart_000_01BC9C3F.D00B3780--
From mmcquade@aa.net  Tue Jul 29 14:40:32 1997
From: Mike McQuade <mmcquade@aa.net>
Date: Tue Jul 29 14:40:35 PDT 1997
Subject: Re: How to attach handler for mv2603 PCI interrupts
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
At 09:53 AM 7/29/97 PDT, you wrote:
>Submitted-by shang.ko@das.honeywell.com  Tue Jul 29 09:53:00 1997
>Submitted-by: "Ko, Shang (NM75)" <shang.ko@das.honeywell.com>
>
>
>	We have a PCI device on the PMC of MV2603 board.  I can generate
>interrupts from the PCI device, but couldn't figure out how to make to
>PPC603 to handle the interrupts.
>
A couple of things.
One, be sure to read:
 "MVME-2600 Series Single Board Computer Programmer's Reference Guide"
pages: 2-55  thru  2-87  as well as pages 5-3 thru 5-7.
Motorola Part number V2600A/PG1.
Two, check your "config.h" file, as the PCI/PMC interrupts 9 and 12 are
disabled
by default.
>----------------------- from config.h -----------------------<
#define INIT_EXT_SRC9           ( INT_MASK_BIT | LEVEL_SENSE |\
                                  PRIORITY_LVL0 )
#define INIT_EXT_SRC10          ( INT_MASK_BIT | LEVEL_SENSE |\
                                  PRIORITY_LVL14 )
#define INIT_EXT_SRC11          ( INT_MASK_BIT | LEVEL_SENSE |\
                                  PRIORITY_LVL14 )
#define INIT_EXT_SRC12          ( INT_MASK_BIT | LEVEL_SENSE |\
                                  PRIORITY_LVL0 )
>-------------------------------------------------------------<
Note: the PRIORITY_LVL0 disables interrupts from this source.
I have not done PCI interrupts, but I think this would be a good place
to check, to see if the Raven is enabled for your specific interrupt.
Mike.
--MimeMultipartBoundary--
From daemon@csg.lbl.gov  Wed Jul 30 04:00:39 1997
From: daemon@csg.lbl.gov
Date: Wed Jul 30 04:00:42 PDT 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jul 30 04:00:33 PDT 1997
        Subject: ADS360 bootrom ?
        Subject: Benchmarks for VxWorks
        Subject: Re: FTP Password
-------------------------------------------------------
Newsgroups: comp.os.vxworks
Subject: ADS360 bootrom ?
Date: 29 Jul 1997 10:22:24 -0700
From: nigel@idiom.com (Nigel Standing)
Organization: Idiom Consulting - ISP, http://www.idiom.com
Message-ID: <5rl8sg$8sg@idiom.com>
Host: Sun SunOS
VxWorks: 5.3.1
BSP: 1.1
Just wondered whether anyone else out there has had a problem
rebuilding a working ADS360 bootrom ?
The WRS supplied bootrom which is 5.3/1.0 vintage seems to work
fine, however when I 'make bootrom' and burn a new EPROM it fails
to boot (using the exact same boot parameters which work with the
5.3/1.0 bootrom).
With the rebuilt bootrom, the initial dialogue appears to be OK,
you can 'p' and 'c' OK but when you try to boot, it fails to attach
to the bootdevice 'qu'.
Thank in advance,
Nigel -
E-m : nigel@idiom.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Benchmarks for VxWorks
Date: Tue, 15 Jul 1997 21:17:58 -0700
From: Dan Morgan <morgan-d@ix.netcom.com>
Organization: Netcom
Message-ID: <33CC4B76.8977289E@ix.netcom.com>
I'm trying to determine system performance for a project currently under
development.
Does anyone know of any benchmarks available  for VxWorks running on
Motorola's 68360/MPC821/MPC860 embedded PowerPC microprocessors?
Thanks,
Dan Morgan
morgan-d@ix.netcom.com
---------------------------
Newsgroups: comp.os.vxworks
Subject: Re: FTP Password
Date: Tue, 29 Jul 1997 13:52:13 GMT
From: lyorg@Scorpio.Com (Lyor Goldstein)
Organization: US Robotics Technologies Ltd.
Message-ID: <33ddf52c.92264045@news.usr.com>
References: <5ribtm$24s@news.alcatel.ch>
Reply-To: lyorg@Scorpio.Com
On 28 Jul 1997 14:55:50 GMT, pascal.freiburghaus@stest.ch (Pascal
Freiburghaus) wrote:
>Hi all,
>
>I have a VxWorks target which runs a FTP-Server and a Telnet Daemon.
>Now I want to activate a password to make the access to my target
>more restricted. I defined "INCLUDE_SECURITY" and I defined a
>LOGIN_USER_NAME and a LOGIN_PASSWORD. This turns on at least the
>login security with telnet but I do not know how to turn on
>the security of the FTP-Server. The WindRiver books (why do I try to look up
>something in the books, it is not there anyway) does not tell anything
>about that.
>
>Any hints?
	This is because this security feature is not a standard WRS
feature. You can contact Leonid Rosenboim (leonid@rst.co.il)
He has such a patch and I am sure you can find a way to receive the
patch for the ftpdLib.
Lyor G
---------------------------
End of New-News digest
**********************
From cruz@xyplex.com  Wed Jul 30 13:28:40 1997
From: Roger Cruz <cruz@xyplex.com>
Date: Wed Jul 30 13:28:43 PDT 1997
Subject: Booting VxWorks directly from DOS...
--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone out there written a utility to load Vxworks directly from
DOS?  I have the need to boot DOS first and then based on some input
load VxWorks.  Any help is greatly appreciated.
  Thanks,
  Roger
--
Roger Cruz                           cruz@xyplex.com
Xyplex Networks                      w: 508-952-4783
295 Foster Street                    f: 508-952-4887
Littleton, MA 01460
--MimeMultipartBoundary--
From rtp.co.uk!jge@rtp.co.uk  Thu Jul 31 01:55:45 1997
From: John Efstathiades <jge@rtp.co.uk>
Date: Thu Jul 31 01:55:48 PDT 1997
Subject: RE: Booting VxWorks directly from DOS...
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Roger Cruz wrote:
> Has anyone out there written a utility to load Vxworks directly
> from DOS?  I have the need to boot DOS first and then based on=20
> some input load VxWorks.  Any help is greatly appreciated.
WRS supply a utility, vxload, with the x86 distribution of Tornado, to =
allow you to load VxWorks from an MS-DOS session. The details are in =
Appendix D of the Programmer's Guide.
HTH,
John.
----------------------------------------------------------------
John Efstathiades                  =20
Real-Time Products Ltd.             e-mail:    	   jge@rtp.co.uk
Unit 8, Holt Court,                 web:           www.rtp.co.uk
Aston Science Park, Jennens Road,   tel:        +44 121 333 6955
Birmingham. B7 4EJ. England.        fax:        +44 121 333 5433
----------------------------------------------------------------
--MimeMultipartBoundary--
From blohm@vs.dasa.de  Thu Jul 31 01:57:03 1997
From: "Gundula Blohm" <blohm@vs.dasa.de>
Date: Thu Jul 31 01:57:09 PDT 1997
Subject: Corba
Hi all !
Has anyone information about CORBA Support for VxWorks ?
Any help is greatly appreciated.
TIA,
Gundula
===================================================
Gundula Blohm
Tel. +49 (731) 392-4731
Fax  +49 (731) 392-4958
mailto:blohm@vs.dasa.de
===================================================
From KH@MPS.OHIO-STATE.EDU  Thu Jul 31 05:42:31 1997
From: "KLAUS HONSCHEID, OHIO STATE UNIVERSITY (614) 292-3287"
Date: Thu Jul 31 05:42:34 PDT 1997
Subject: Re: Corba
--MimeMultipartBoundary
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Hi,
CORBA is available for VxWorks/Tornado (currently only for the PowerPC plat
forms)
We are quite happy with Visigenics Visibroker for C++. For further information
contact either Visigenic or Ken Black of Highlander Engineering who is
handling the realtime versions of Visibroker.
His Email address is kblack@highlander.COM.
Regards,
Klaus Honscheid
Ohio State University
--MimeMultipartBoundary--
From bawilson@llnl.gov  Thu Jul 31 12:04:12 1997
From: "Bruce A. Wilson" <bawilson@llnl.gov>
Date: Thu Jul 31 12:04:19 PDT 1997
Subject: logTask priority
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Hello All,
	By default, the logTask priority is zero, which means it will run
before any of our application tasks (usually set to about 150).  Does
anyone know of any harm in setting the logTask to priority 200, so it won't
interfere with our application tasks?
Bruce A. Wilson
U.C. LLNL   ( L-054 )
P.O. Box 808
Livermore, CA  94550
--MimeMultipartBoundary--
From johill@lanl.gov  Thu Jul 31 12:54:59 1997
From: Jeff Hill <johill@lanl.gov>
Date: Thu Jul 31 12:55:01 PDT 1997
Subject: RE: logTask priority
--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
> Hello All,
> 	By default, the logTask priority is zero, which means it will run
> before any of our application tasks (usually set to about 150).  Does
> anyone know of any harm in setting the logTask to priority 200, so it won't
> interfere with our application tasks?
>
If the format string used by the task that calls logMsg() changes
before the log task services the request, then unexpected results
highly probable.
Jeff
______________________________________________________
Jeffrey O. Hill           Internet     johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107
--MimeMultipartBoundary--