From leonid@rst.co.il  Wed Jan  1 17:12:19 1997
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Wed Jan  1 17:12:22 PST 1997
Subject: Re: tyLib questions
> - If a task is pending on a read on the serial port, a second task is pending
>   on a write on the same port, and a third task issues an FIOCANCEL on the
>   port, does it cancel both the read and the write?  Or does it just cancel
>   one of them?

Both tasks are cacelled, but only one per operation, i.e. if you
got two tasks blocked on write, I think only one of them will
get cacelled.

> - What value is returned from a read or write canceled by an FIOCANCEL?  Does
>   it return the number of bytes read/written before the FIOCANCEL was issued?
>   Or does it return ERROR?  Or something else?

It will return 0, with errno set to S_ioLib_CANCELLED

> - If I request a read of 20 bytes from a serial port, and the port has only
>   received 10 bytes, does it return the 10 bytes, or does it block waiting
>   for the remaining 10? 

If you are not ine LINE mode, then the 10 bytes received this far
will be returned immediately, with read(0 returning this count.
If in line mode, then it depends if a CR is one of them bytes
received this far.

>  How about if I'm writing to the port and the transmit
>   buffer is full?

This is exactly when write() blocks, waiting until buffer
space becomes available, unless it is cancelled with FIOCANCEL.

Note that with tyLib, you should not call ioctl( fd, FIOCANCEL,0)
from interrupt context, or a watchdog routine. Instead, you
could do

	excJobAdd( (VOIDFUNCPTR) ioctl,  fd, FIOCANCEL, 0, 0, 0, 0);

and let the tExcTask do it for you.

This is the mechanism to implement a read() timeout, to use a signal
which does FIOCANCEL, or watchdog which does excJobAdd of FIOCANCEL,
or you could use select to wait for input, write buffer space and
atimeout or a combination of at the same time.

Happy New Year, Everybody!
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone:  +972-3-559-8144
R S T  Software Industries Ltd.         Mobile: +972-50-307-142
P.O.Box 11502, AZUR 58017, Israel       Fax:    +972-3-559-8244
WWW: http://www.rst.co.il		E-Mail:	leonid@rst.co.il

From froeber@bbn.com  Wed Jan  1 18:00:08 1997
From: Fred Roeber <froeber@bbn.com>
Date: Wed Jan  1 18:00:10 PST 1997
Subject: Re: workQAdd0 - work queue overflow problem
Tunc Hoscan wrote:
> we load it and started running our system gives a panic message
> and reboots itself. It says something like:
> 
> Work Queue Panic - workQAdd0
> Work Queue Overflow
>  .. and reboots
> 
> We have a number of VME cards in the system, one being a GET
> Engineering NTDS card, and the others are some serial I/O cards.

Stephen L. Egbert replied:

> First place I would look at is the AP Labs aio libraries.  The Async driver
> (or your hook routines if called) is apparently performing at interrupt
> context mode way too many VxWorks function calls that requires 
> deferred kernel processing.
> 
> Some examples of deferred kernel works would be qJobPut, semTake, wdStart,
> msgQSend, msgQBroadcast, wdCancel, taskSuspend, taskPrioritySet, et. al.
> 
> Normally interrupt routines performs simple task without calling any
> deferred kernel functions.

Just to add a little clarification.  The VxWorks work queue can only
contain a maximum of 64 queued entries.  If you get a lot of interrupts
in a row without ever returning to non interrupt state and each of the
interrupt handlers calls a VxWorks function that is deferred then as
soon as this happens 64 times you get the result you see.  Contrary to
what Steve said, many interrupt handlers do result in deferred work
since many do something to signal task level processing that the
interrupt occurred (e.g. they do a semGive).  In most normal systems,
this error doesn't result in work queue panics because interrupts don't
stack up that deeply.  In fact, the "normal" cause of a work queue panic
right off the bat is having an interrupt handler that doesn't correctly
respond to the interrupting hardware to tell it to disable its interrupt
request with the result being infinite interrupts causing a work queue
panic.  If you suspect too many interrupts you could try pulling peripheral
cards until the problem goes away.  Good luck.  Fred

   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |

From dalsup@tinygee.dasd.honeywell.com  Wed Jan  1 19:10:11 1997
From: Dave Alsup <dalsup@tinygee.dasd.honeywell.com>
Date: Wed Jan  1 19:10:13 PST 1997
Subject: GNAT and vxworks
Some time ago I saw a couple of postings asking about the use of GNAT
(GNU Ada Translator) with vxWorks; I don't remember any replies.  Since
then we have switched from the Green Hills Ada83 product on the I960 and
vxWorks to GNAT.  Even though neither the I960 nor vxWorks are currently
supported by AdaCore (the maintainers of GNAT) it was a very small
effort to get the basic Ada language up and running (we are using
vxWorks tasking directly so we haven't dealt with any of the problems
around getting Ada tasking going). (AdaCore has expressed considerable
interrest in supporting vxWorks on some platform, most likely the
PowerPC.) 

I have been very pleased with the quality of the compiler.  We have
accomplished more in porting an existing Ada83 program developed with
the Tartan compiler and runtime with this product in a month than we
were able to in almost a year with the Green Hills compiler.  Finally
having the inter-language features of Ada95 available along with the
common GCC back-end has made interfacing between Ada and C
straightforward and dependable.

Dave Alsup
Honeywell Defense Avionics
Albuquerque, NM

dalsup@dasd.honeywell.com

From daemon@csg.lbl.gov  Thu Jan  2 04:00:15 1997
From: daemon@csg.lbl.gov
Date: Thu Jan  2 04:00:21 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan  2 04:00:12 PST 1997

        Subject: undefined reference to `_ctors' in C++

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

Newsgroups: comp.os.vxworks
Subject: undefined reference to `_ctors' in C++
Date: Thu, 02 Jan 1997 10:29:04 +0200
From: Manie Steyn <msteyn@ccii.co.za>
Organization: CCII Systems
Message-ID: <32CB71D0.5D13@ccii.co.za>
Reply-To: msteyn@ccii.co.za

- ------------6CBC54F571090
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hi All

We run VxWorks 5.3 on a Sparc host for an i486 target. I tried to
include the C++ capability into the kernel but got errors with undefined
reference to `_ctors'. We use the default bsp config for i486 and then
add "INCLUDE_CPLUS". When we make the following error occurs.

ld386 -X -N -e _sysInit -Ttext 00108000 \
    -o vxWorks dataSegPad.o sysALib.o sysLib.o   usrConfig.o version.o
/usr/wind/target/lib/libI80486gnuvx.a
cplusGlob.o(.text+0x4): undefined reference to `_ctors'
cplusGlob.o(.text+0x24): undefined reference to `_dtors'
*** Error code 1
make: Fatal error: Command failed for target `vxWorks'

Is there some other defines that we need to include?
Regards Manie Steyn

- ------------6CBC54F571090
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii

<HTML><BODY>

<DT>Hi All</DT>

<DT>&nbsp;</DT>

<DT>We run VxWorks 5.3 on a Sparc host for an i486 target. I tried to include
the C++ capability into the kernel but got errors with undefined reference
to `_ctors'. We use the default bsp config for i486 and then add &quot;INCLUDE_CPLUS&quot;.
When we make the following error occurs.</DT>

<DT>&nbsp;</DT>

<DT>ld386 -X -N -e _sysInit -Ttext 00108000 \</DT>

<DT>&nbsp;&nbsp;&nbsp; -o vxWorks dataSegPad.o sysALib.o sysLib.o&nbsp;&nbsp;
usrConfig.o version.o&nbsp;&nbsp;</DT>

<DT>/usr/wind/target/lib/libI80486gnuvx.a&nbsp;</DT>

<DT>cplusGlob.o(.text+0x4): undefined reference to `_ctors'&nbsp;</DT>

<DT>cplusGlob.o(.text+0x24): undefined reference to `_dtors'&nbsp;</DT>

<DT>*** Error code 1&nbsp;</DT>

<DT>make: Fatal error: Command failed for target `vxWorks'</DT>

<DT>&nbsp;</DT>

<DT>Is there some other defines that we need to include?</DT>

<DT>Regards Manie Steyn&nbsp;<BR>
<BR></DT>

</BODY>
</HTML>
- ------------6CBC54F571090--

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

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

From daemon@csg.lbl.gov  Fri Jan  3 04:00:16 1997
From: daemon@csg.lbl.gov
Date: Fri Jan  3 04:00:19 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan  3 04:00:14 PST 1997

        Subject: Experience porting a BSP to a custom 68K board
        Subject: VxWorks for the turboSPARC

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

Newsgroups: comp.os.vxworks
Subject: Experience porting a BSP to a custom 68K board
Date: Thu, 02 Jan 1997 18:45:58 +0000
From: Aurobindo Tripathy <auro@kinecomm.com>
Organization: Kinecomm Systems
Message-ID: <32CC0266.FE3@kinecomm.com>
Reply-To: auro@kinecomm.com

I am looking for you to narrate your experiences is generating a BSP for
a custom Motorola 60302-based board with the VxWorks BSP porting Kit.
Needless to say, I am a VxWorks novice. 

Best regard

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

Newsgroups: comp.os.vxworks
Subject: VxWorks for the turboSPARC
Date: 2 Jan 1997 21:20:47 GMT
From: pww@cray.com (Paul Wells)
Organization: Cray Research, a subsidiary of Silicon Graphics, Inc.
Message-ID: <5ah8rf$bno@walter.cray.com>

I'm in the process of porting our existing microSPARC II BSP to the
new Fujitsu turboSPARC (aka sr71, MB86907) processor.  If anyone else
is doing work along these lines, I'd be interested in sharing experiences, 
code, etc..

Paul Wells
pww@cray.com

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

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

From fbh@vlsi9.gsfc.nasa.gov  Fri Jan  3 07:26:41 1997
From: fbh@vlsi9.gsfc.nasa.gov (Francis Hallahan)
Date: Fri Jan  3 07:26:43 PST 1997
Subject: MultiCasting and Promiscuous modes
We are using an MVME167 and have a couple of projects that
need to capture data off of dedicated lans.  Does anyone have
software for either multicasting and/or promiscuous mode on
the 167.

PS: I'd also be interested in hearing of any successes or failures.
I'll summarize the results and post back to the group

Thanks,
Frank Hallahan

/-------------------------------------------------------------------------\
| Frank Hallahan                            |  Hallahan@gsfc.nasa.gov     |
|   Software Environment Leader - Code 521  |  fbh@vlsi.gsfc.nasa.gov     |
| Computer Sciences Corporation             |                             |
| at Nasa Goddard Space Flight Center       |  Phone (301) 286 7064       |
\-------------------------------------------------------------------------/

From mstimp@dvg.com  Fri Jan  3 14:00:20 1997
From: "Mike Stimpson" <mstimp@stokes.dvg.com>
Date: Fri Jan  3 14:00:25 PST 1997
Subject: FIOCANCEL and Wind River tech support
Thanks for the answers on FIOCANCEL.

By the way, I was unfair to Wind River's tech support.  They had replied to my
question - their answer was buried in a co-worker's E-mail queue.  But their
answer didn't tell me nearly as much as I heard here.

-- 
Mike Stimpson (mstimp@utsci.com)

Opinions expressed are not necessarily those of the management...

Microsoft Windows:  Just say "Oink!"

From tmorris@me.umn.edu  Fri Jan  3 16:17:24 1997
From: Ted Morris <tmorris@me.umn.edu>
Date: Fri Jan  3 16:17:30 PST 1997
Subject: GNU compiler config.

Does anyone know if the GNU compiler built for 68K targets generates
floating point instructions for the 68881 by default?

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

From crispen@hiwaay.net  Fri Jan  3 19:52:42 1997
From: Bob Crispen <crispen@hiwaay.net>
Date: Fri Jan  3 19:52:44 PST 1997
Subject: Re: System reliability (was: VxVMI stuff)
leonid@rst.co.il (Leonid Rosenboim) sez:

> Software has never been easy or trivial, it's a hard trade.
> Nevertheless, there exist a lot of knowledge accumulated
> over more then 20 years of experience, which is called SOftware
> Engineering.

And in case no one has mentioned this yet, a critical element
(I almost said *the* critical element, but that's the stuff
of which flame wars are made) of software engineering is to
have a defined, repeatable, improvable process which is
grounded in a common system architecture.

Although everybody and his uncle is clamoring to sell you a
methodology (and a set of expensive tools that automate that
methodology) pay them no mind.  A methodology may eventually
become part of your process, but unless that methodology is
part of a process you will end up doing some profoundly
stupid things.

Example one (responsible for the utter failure of two
projects I know of): forgetting that the ultimate goal is
not to adhere to a fundamentalist interpretation of the
methodological gospel, but rather to produce high quality
software.

Remember too that an automated methodology, because it
offers at most one way to incorporate it in a process,
often mitigates against improvability of the process.

And it's worth mentioning that automated methodologies
often have profound architectural implications.  That is,
the methodology (e.g., early ADARTS) may require you to
create an instance of a control-systems architecture for
every small part of your domain (actually early ADARTS
was even worse than that, requiring you to invent a new
architecture from scratch for every subsystem, but
everybody I know figured out pretty early how stupid an
idea that was).

Finally, I should at least mention in passing that the use
of a high-level programming language that has been proven
in safety-critical applications (Ada comes to mind) can
also have a significant impact on a development process.
--
Rev. Bob "Bob" Crispen
crispen@hiwaay.net
"A polar bear is just another way of expressing a rectangular bear."

From daemon@csg.lbl.gov  Sat Jan  4 04:00:14 1997
From: daemon@csg.lbl.gov
Date: Sat Jan  4 04:00:19 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan  4 04:00:12 PST 1997

        Subject: Re: Experience porting a BSP to a custom 68K board

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

Newsgroups: comp.os.vxworks
Subject: Re: Experience porting a BSP to a custom 68K board
Date: Fri, 03 Jan 1997 15:49:26 -0800
From: dfigueroa@tst.com (David Figueroa)
Organization: Torrey Science Corp
Message-ID: <dfigueroa-0301971549260001@news2.cts.com>
References: <32CC0266.FE3@kinecomm.com>

In article <32CC0266.FE3@kinecomm.com>, auro@kinecomm.com wrote:

> I am looking for you to narrate your experiences is generating a BSP for
> a custom Motorola 60302-based board with the VxWorks BSP porting Kit.
> Needless to say, I am a VxWorks novice. 
> 
> Best regard

The best thing to do is to buy Wind River's ADS302 BSP, then modify it to
suit your custom board.  With the 302 the tricky part is boot up, so study
the code in romInit.s.  It should be pretty straight forward.

Good Luck.

dave

- -- 
 |  David Figueroa
- -+----------------------------------
 |  Torrey Science Corporation
 |  10065 Barnes Canyon Rd
 |  San Diego, CA  92121
 |
 |  (619) 552-1052
 |  (619) 552-1056 (fax)

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

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

From adler@bnlku5.phy.bnl.gov  Sun Jan  5 12:01:58 1997
From: "Steve Adler" <adler@bnlku5.phy.bnl.gov>
Date: Sun Jan  5 12:02:03 PST 1997
--
--PART-BOUNDARY=.19701051501.ZM14716.phy.bnl.gov
Content-Type: text/plain; charset=us-ascii

Attached is a readme file located at

ftp://ftp.phy.bn.gov/pub/vxworks/tcpBlaster/tcpBlasting.README

It contains some info on software I used to measure socket throughputs
between an MVME1305 and a PPro running linux over fast ethernet
and between an SGI and Alpha over FDDI.

Enjoy.

--PART-BOUNDARY=.19701051501.ZM14716.phy.bnl.gov
X-Zm-Content-Name: tcpBlasting.README
Content-Description: Text
Content-Type: text/plain ; name="tcpBlasting.README" ; charset=us-ascii

		TCP Blasting. Tools to measure tcp and udp
		socket performance under VxWorks and Unix.

	by: Dr. Stephen Adler.
	Brookhaven National Laboratory, Upton NY.
	Physics Department
	AGS Experiment E787.
	ftp://ftp.phy.bnl.gov/pub/vxworks/tcpBlaster
	stephen.adler@bnl.gov

The 4 routines which are located in this directory are used to
measure the tcp and udp socket transfer rates between two "internet
endpoints". The code was originally written by someone at
Wind River System and I have spent some time fixing it up so
that it works properly on Linux, Irix and Digital Unix machines.
I have also added a switch so that one can transfer data using
udp sockets as well. At the end of this file I have a matrix of
some transfer rates which I have measured on some of our unix
and vxworks machines at my disposal.

Files:

 uxBlaster.c
 uxBlastee.c

 Client and server programs which run under Unix.

 vxBlaster.c
 vxBlastee.c

 Client and server programs which run under vxworks.

Building:

  Unix:

    make uxBlaster
    make uxBlastee

  vxWorks:

    create your own vxworks Makefile and build the two routines like
    you would any other vxworks routine.

Running:

  Unix:

     usage: uxBlaster targetname port udp|tcp size bufLen
     usage: uxBlastee port udp|tcp size bufLen

	note: size is the size of the buffer, in bytes, being written
              or read through the socket. bufLen is the socket
              buffer length. To get high through put you need to
              make these two as large are possible.
              (e.g. size = bufLen = 32768)

  vxWorks:

    To run this blaster task from the VxWorks shell do as follows: 
    -> sp (blaster, "192.2.200.42", 7000, 1, 1000, 16000); tcp blastering...
    -> sp (blaster, "192.2.200.42", 7000, 0, 1000, 16000); udp blastering...

    To stop blaster task from the VxWorks shell do as follows: 
    -> blasterStop = 1 
     
    To run this blastee task from the VxWorks shell do as follows: 
    -> sp (blastee, 7000, 1, 1000, 16000); for tcp blasteeing...
    -> sp (blastee, 7000, 0, 1000, 16000); for udp blasteeing...

    To stop blastee task from the VxWorks shell do as follows: 
    -> blasteeStop = 1 

	Matrix of transfer rates measured at BNL.

    From                   To                    Socket  Transfer    % Missed  size/bufLen
                                                 type     Rage       buffers

   200Mhz PPro            MVME1305 60 Mhz PPC     tcp    2.6 MBytes/s    0.0    from: 32768/65536
   PCI 100BaseT           MPMC202  PMC 100BaseT                                 to:   32768/32768
   Linux                  VxWorks                 udp    (no data available)

   MVME1305 60 Mhz PPC    200Mhz PPro             tcp    4.1 MBytes/s    0.0    from: 32768/32768
   MPMC202  PMC 100BastT  PCI 100BaseT                                          to:   32768/65536
   VxWorks                Linux                   udp    5.7 MBytes/s    0.6    from: 32000/32768
                                                                                to:   32768/32768

   SGI Challenge L        Alpha 250/266           tcp    6.8 MBytes/s    0.0    from: 65536/65536
   250Mhz R4400           EV4 alpha 266Mhz                                      to:   65536/65536
   VME FDDI (fiber)       PCI FDDI (fiber)        udp    8.0 MBytes/s    1.5    from: 1000/16000
   Irix 5.3               Digitial Unix 4.0                                     to:   1000/16000
   (note: udp ran on 150Mhz R4400, otherwise I could not transfer properly due to
          "blaster write error: No buffer space available" generated on the SGI end.)

   Alpha 250/266          SGI Challenge L         tcp    5.8 MBytes/s    0.0    from: 65536/65536
   EV4 alpha 266Mhz       250Mhz R4400                                          to:   65536/65536
   PCI FDDI (fiber)       VME FDDI (fiber)        udp    .05 MBytes/s    9.6    from: 1000/16000
   Digitial Unix 4.0      Irix 5.3                                              to:   1000/16000

  (note: The udp transfers have no effective handshake so lost transfers are possible. This
   is opposed to tcp transfers where no data loss is guerateed by the protocol. Another
   effect with udp transfers is that it works best when the sending machine (blaster) is
   slower than the recieeving machine (blastee). I assume this is why I could not
   get good udp transfer rates when the 200Mhz PPro was sending to the 60 Mhz PPC and
   the 266Mhz Alpha was sending to the 250Mhz R4400 SGI machine.)

--PART-BOUNDARY=.19701051501.ZM14716.phy.bnl.gov--

From harry@ellips.nl  Mon Jan  6 05:36:28 1997
From: Harry Stox <harry@ellips.nl>
Date: Mon Jan  6 05:36:30 PST 1997
Subject: Off-the-shelf 100Base-Tx PCI Ethernet cards with VxWorks driver for PC486 target?
Hello,

For which of the "popular" 100Base-Tx PCI Ethernet cards is a VxWorks dri=
ver for the PC486 BSP available (either from WRS or 3rd party)?

We are looking for widely available cards < $150, like the Intel EtherExp=
ress PRO/100 or the 3Com Fast Etherlink XL, that are (or will soon be) su=
pported under VxWorks.

Thanks in advance,

Harry Stox - Ellips B.V.
Hard- and Software- Engineer
harry@ellips.nl (http://www.ellips.nl)

From SJohnson@systran.com  Mon Jan  6 07:05:09 1997
From: Steve Johnson <SJohnson@systran.com>
Date: Mon Jan  6 07:05:11 PST 1997
Subject: dosFs under 5.2 and 5.3

 ----------
From:  Steve Johnson
Sent:  Tuesday, December 31, 1996 4:34 PM
To:  'vxWorks e-mail Exploder'
Subject:  dosFs under 5.2 and 5.3

We've been developing device drivers for Fibre Channel disk drives.   
 Currently we support the dosFs under vxWorks 5.2 on various PowerPC and   
MIPS platforms.  On a single thread read or write to a Seagate Barracuda   
9, I can get from 9-10 MB/sec throughput.  Making multiple requests   
across multiple drives concurrently we can see aggregate throughputs   
anywhere from 16-37 MB/sec depending on the platform and the drive   
interface. The problem is when I run the same driver under 5.3 all of the   
throughput figures are cut in half or worse. It's so slow that when I   
make a request to a drive I can see a delay of 5-10 seconds before the   
activity LED on the drive even begins to flash.

 As I am not real familiar with how Wind River implements the dosFs I/O   
internally, does anyone know of any major redesigns or overhauls to this   
interface that has caused such a drastic change in performance ?

Can dosFs recognize anything larger than 500 MB ? I thought the bugs in   
the dosFsConfigShow were fixed.  I initialize a drive to be 9 GB and it   
won't see anything over 500 MB but it will let me write to the entire 9   
GB.  Sometimes I even get negative values for available space.

 We are not using the Tornado interface.  The kernel is configured to   
operate like the 5.2 interface. Would this be creating the problem in any   
way ?  Are there any tunable parameters that effect the file I/O, that   
have been drastically changed since 5.2 ?

Thanks,
"Bewildered by 5.3"

sjohnson@systran.com

Steven L. Johnson
Systran Corp.
Dayton, Ohio USA

From jiaqp@nuhepz.phys.nwu.edu  Mon Jan  6 14:22:46 1997
From: "QiuPing Jia" <jiaqp@nuhepz.phys.nwu.edu>
Date: Mon Jan  6 14:22:52 PST 1997
Subject: vxwexplo@lbl.gov
HI, everybody,

   We are using vxworks 5.1 on mvme162, our host mechine is SGI. Recently we
want to use a customer made board connecting to Industry-Pack connector on the
MVME162, the function of our package likes the function of TI's 1394 firewire.
But I did not see any documentation in vxWorks 5.1 programmer guide. Do any
Wind River's products support the IndustrPack on MVME 162? Or do I need to
write sth. by myself? Any informations will be appreciate.

Have a happy new year,

Qiuping Jia,
Northwestern University

From stan@rti.com  Mon Jan  6 19:39:23 1997
From: stan@rti.com (Stan Schneider)
Date: Mon Jan  6 19:39:25 PST 1997
Subject: ScopeProfile beta sites

Hi all,

We're looking for a few sites to beta test our new Java GUI for ScopeProfile.
ScopeProfile is the dynamic execution profiler for VxWorks; it shows you where
your code is burning CPU cycles.  It's supported on virtually all host & target
combinations.  Send mail to info@rti.com if you're interested.

Thanks,

	-- Stan
	   stan@rti.com

From p72950@gmcl.co.uk  Tue Jan  7 06:54:47 1997
From: Phil Quiney <p72950@gmcl.co.uk>
Date: Tue Jan  7 06:54:49 PST 1997
Subject: Bypassing 'intConnect'
Hi folks,

I thought the following was worth sharing.

The project I am working on is based on some home grown hardware which
has a high speed 'tick' (500usec period) which is used for some internal
timing requirement. The problem is that the 'intConnect' function adds
too much overhead in addition to the 680x0 exception handling so I began
looking into bypassing this function to cut the overhead to a minimum while
still being able to attach a C routine.

The following code has a routine 'test' which basically has embedded
__asm__ statements which save/restore registers used by the compiler
and also replace the return statement with an 'rte'. (Obviously this
technique is specific to a processor family and/or compiler.)

Additionally the routine replaces its own vector with that of another 
handler created in the normal way by intHandlerCreate (called by intConnect
indirectly). I was simulating a hardware timer in software for the example
handler. When this other handler runs (a real timer would generate an interrupt
when it overflows) it increments a count and then swaps the routine back again.

Whilst testing this I noticed that repeated calling of 'intHandlerCreate'
is not being balanced against a complementary 'intHandlerDelete' (which
dosen't exist!) and therfore we have a memory leak situation. By disassembling
'intHandlerCreate' I found that the 'handle' returned is the output of a 
'malloc' so the 'intHandlerDelete' can be implemented by a call to 'free'. You
have to make sure that the handler is not active (ie in the vector table)
before calling 'free'. The system will probably go on working until this block
of memory is reused giving rather bizarre operation.

The code below has been tested on an MV162 board with the GNU Compiler and uses
the default Auxilary Clock (Tick Timer 2). It replaces the BSP attached routine
with the routines as described above. Calling 'auxunsetup' restores things back
as they were.

Callable functions (from shell)

auxsetup   - sets up interrupt handlers - sets AuxClock rate to 50Hz
auxstart   - starts aux clock
auxstop    - stops aux clock
auxprobe   - returns 2 counts, 'runcount' - number of times 'gash_handler' has
             executed and 'count' - number of current run of 'test' (this is
             reset when 'gash_handler' runs.
auxunsetup - deletes handlers & resets Aux clock handler to BSP supplied one
             and resets original aux clock rate.

Regards

Phil Quiney

*-----------------------( Cut Here )-----------------------------------------*

#include <vxWorks.h>
#include <taskLib.h>
#include <iv.h>
#include <intLib.h>
#include <stdio.h>
#include <stdlib.h>
#include <sysLib.h>

int runcount;

int count = 0;
FUNCPTR handler = (FUNCPTR)0;
FUNCPTR old_vector, new_vector;
int old_rate;

/* Some stuff for clock timer chip */
#define CAST (char *)
#define	MCC_REG_INTERVAL	1
#define AUX_CLK_INT 0x48
#define MCC_BASE_ADRS	(0xfff42000)
#define T2_IRQ_CR_ICLR	0x08	/* Clear IRQ */
#define MCC_ADRS(reg)   (CAST (MCC_BASE_ADRS + (reg * MCC_REG_INTERVAL)))
#define	MCC_T2_IRQ_CR	MCC_ADRS(0x1a)	/* Tick Timer 2 Inter CR      */

/* Local functions */

void auxstart(void);
void auxstop(void);
void intHandlerDelete(FUNCPTR handler);

static void test(void)
{
    /* This routine is directly connected using intVecSet */

    /* The GNU compiler inserts a link instruction to reserve stack space
     * for local variables (even if there aren't any!). 
     * The register affected is a6 and this will be corrected by an unlk
     * instruction before the function exits.
     */

    /* Save registers used by the C code which follows. Isolating this function
     * into a separate file & compiling with -S to produce an assembler
     * listing is recommended if the system dies when this routine runs. Check
     * for any other used registers as the 'movem' below saves as few as
     * possible.
     */
    __asm__("movem.l d0/d1/a0/a1, -(a7)");
    (count)++;
    if(count>100)
    {
        if(handler)
            intVecSet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT), handler);
    }

    /* Keep timer chip happy */
    *MCC_T2_IRQ_CR |=  T2_IRQ_CR_ICLR;

    /* Restore registers & tidy stack before returning via 'rte' */
    __asm__("movem.l (a7)+, d0/d1/a0/a1");
    __asm__("unlk a6;rte");
}

static void gash_handler(int param)
{
    /* This routine is connected via the VxWorks normal method using
     * 'intHandlerCreate'
     */
    runcount++;
    /* Deal with timer interrupt */
    *MCC_T2_IRQ_CR |=  T2_IRQ_CR_ICLR;

    /* Clear count */
    count = (int)0;

    /* Reset the vector */
    intVecSet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT), (FUNCPTR)param);

}

void auxsetup(void)
{

    printf("\n\nMV162 Auxiliary Clock Test Program\n\n");
    old_vector = intVecGet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT));
    printf("Old vector is %x\n", (int)old_vector);
    intVecSet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT), (FUNCPTR)test);

    runcount = 0;

    count = (int)0;
    handler = intHandlerCreate((FUNCPTR)gash_handler,(int)test);
    printf("Handler is %x\n", (int)handler);

    new_vector = intVecGet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT));
    printf("New vector is %x\n", (int)new_vector);

    old_rate = sysAuxClkRateGet();
    sysAuxClkRateSet(50);

}

void auxstart(void)
{
    printf("Starting Aux clock\n");
    sysAuxClkEnable();
}

void auxstop(void)
{
    printf("Stopping Aux clock\n");
    sysAuxClkDisable();
}

void auxprobe(void)
{
    printf("runcount is %d\n",  runcount);
    printf("count is %d\n",  count);
}

void auxunsetup(void)
{
    printf("Unsetting up Aux clock\n");
    sysAuxClkDisable();
    printf("Resetting vector\n");
    intVecSet((FUNCPTR *)INUM_TO_IVEC(AUX_CLK_INT), old_vector);

    printf("Deleting handler\n");
    intHandlerDelete(handler);
    handler = (FUNCPTR)0;
    sysAuxClkRateSet(old_rate);

}

void intHandlerDelete(FUNCPTR handler)
{
    /* This function assumes that the handler was created via 'intConnect'
     * or via 'intHandlerCreate'. Care must be taken that the handler
     * is not in the vector table. A proper version of this could
     * check first before releasing the associated memory!
     */

    free((void *)handler);
}

*-----------------------( Cut Here )-----------------------------------------*

===============================================================================
Phil Quiney          _/_/_/_/        _/  _/_/_/_/  email : quiney@gmcl.co.uk   
GEC Marconi         _/    _/        _/  _/    _/     tel : +44 1245 353221x3914
Communications Ltd _/_/_/_/  _/    _/  _/  _/_/      fax : +44 1245 275448
Chelmsford        _/        _/_/_/_/  _/_/_/_/
England CM1 1PL                              _/                             
===============================================================================

From rstelzer%ims.fhg.de%sonja.ims.fhg.de@ims.fhg.de  Wed Jan  8 08:31:30 1997
From: Rainer Stelzer <rstelzer@ims.fhg.de>
Date: Wed Jan  8 08:31:33 PST 1997
Subject: cascaded includefiles 
hi all,

until now I wasn't able to teach the maketool to handle cascaded
headerfiles.
The problem is, that a change in a headerfile which is included by an
other headerfile is not recognized by the maketool. So that the
corresponding C-code file is not recompiled.

Can someone give me a suggestion or maybe an makefile-example to
solve the problem ?

greetings by Kai
 

--

**********************************************************************
Fraunhofer Institut f|r Mikroelektronische Schaltungen und Systeme
Abteilung SAT
Rainer Stelzer 
Finkenstra_e 61
47057 Duisburg
Tel.  0203/3783-238 
email rstelzer@ims.fhg.de
**********************************************************************

From adler@bnlku5.phy.bnl.gov  Wed Jan  8 20:24:40 1997
From: Stephen Adler <adler@bnlku5.phy.bnl.gov>
Date: Wed Jan  8 20:24:42 PST 1997
Subject: Talking to VME from my mvme1305, license number 11021

Any one out there know how to talk to A24/D32 vme address
space on an MVME1305 or MVME1600 (I believe the two boards
should use the same method.) I have a VME board which has
its registers at address $E00000 and they talk A24/D32. I have
a feeling I need to modify something in sysLib.c but don't know
what. I have no documentation which explains how I can address
vme space. If the mmu's or memory mapping chips are setup
correctly I just address the VME space directly? Like this:

  int *a24 = (int *)0xe00000;
  *a24 = 0xf;

  will load 0xf into address 0xe00000 of my VME board? I have a feeling
that the vme address space is remapped into another address space
visible from the PPC cpu. I believe the a24/D32 address space is
mapped into PPC memory space of 0xe0000000 and

  int *a24 = (int*)0xe0e00000;
  *a24 = 0xf;

  would load 0xf into my register located on my VME board. I tried this
but did not work. Do I have to initialize the memory mapping units myself?
Or call some memory mapping unit intialization routines provided by
usrConfig.c or whatever?

Thanks in advance for any info you can supply to this poor sole
trying to talk to his VME board from his MVME1305 using vxWorks......

Steve.

From phil@themis.com  Thu Jan  9 03:02:43 1997
From: Philippe Weber <phil@themis.com>
Date: Thu Jan  9 03:02:45 PST 1997
Subject: NTP
Is anybody aware of a VxWorks implementation of NTP (Network Time Protocol) ?

Thanks in advance.
Philippe Weber - Themis Computer

From daemon@csg.lbl.gov  Thu Jan  9 04:00:17 1997
From: daemon@csg.lbl.gov
Date: Thu Jan  9 04:00:19 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan  9 04:00:14 PST 1997

        Subject: Port For TMS320C30

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

Newsgroups: comp.os.vxworks
Subject: Port For TMS320C30
Date: 9 Jan 1997 01:11:28 GMT
From: peterc@neopath.com (Peter Chu)
Organization: NeoPath, Inc.
Message-ID: <5b1gk0$3ch@neopath.com>

Does anyone know of a VxWorks port for
the DSP/CPU Texas Instruments TMS320C30?

Thank you.

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

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

From jthompson@cabm.sciatl.com  Thu Jan  9 07:42:57 1997
From: jthompson@cabm.sciatl.com (Jeff.Thompson)
Date: Thu Jan  9 07:42:58 PST 1997
Subject: Flash Memory Driver and File System
I am developing firmware for the headend equipment used in our cable modem
product line. The target is a Motorols MVME-2603 "Slim-Gen" board. I am
looking for a flash memory driver and file system.

From punamia@falcon.kla.com  Thu Jan  9 07:51:20 1997
From: punamia@falcon.kla.com (Manoj Punamia)
Date: Thu Jan  9 07:51:22 PST 1997
Subject: Re: NTP

> From root@csg.lbl.gov Thu Jan  9 07:35:33 1997
> Date: Thu, 9 Jan 97 03:02:46 PST
> To: vxworks_users@csg.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: NTP
> Content-Length: 440
> 
> Submitted-by phil@themis.com  Thu Jan  9 03:02:43 1997
> Submitted-by: Philippe Weber <phil@themis.com>
>  
> Is anybody aware of a VxWorks implementation of NTP (Network Time Protocol) ?
> 
> Thanks in advance.
> Philippe Weber - Themis Computer
 
You can ftp public domain VxWorks implementation of NTP from:

        ftp: //ftp.atd.ucar.edu/pub/vxworks/vx/README

-- Manoj Punamia
   KLA Instruments Corp.

From joeco@dy4.com  Thu Jan  9 08:17:04 1997
From: joeco@dy4.com (Joe Coballe)
Date: Thu Jan  9 08:17:06 PST 1997
Subject: Re: comp.os.vxworks newsdigest
Hi Shaun,

The changes regarding the ROM address looks right.  But how about the RAM size? I believe the 171-133 has 8 Meg instead of the standard 12M.  You may need to change A32_MEM_SIZE_TOTAL to 0x800000.

Also, are you programming the VxWorks image with your application linked in?  If the above changes are made and your application/vxWorks doesn't come up, I suggest you try to program the bootrom.hex.  This is what I used to test the cards with.  If this works, we know the BSP configuration is right, and we start looking at a possible conflicts with your application.

Joe C.

From cdunn@nswc.navy.mil  Thu Jan  9 09:41:26 1997
From: cdunn@nswc.navy.mil
Date: Thu Jan  9 09:41:36 PST 1997
Subject: cacheDisable() 

I want to thank those that responded to my original post about our
problems with cacheDisable() locking up our PowerPc 603 (locking
the host-based shell and causing us to have to reboot), and say
that we are still trying to track down the problem, and are
communicating with Motorola and WRS.  However, I would like to 
try to clarify if it is a local problem or something that affects 
more than just us.  One of the respondents coded a similar test 
for their systems that contained several configurations and 
experienced no problem.  So I would like to enclose the code that
was used to see if anyone would notice some problem with it, or,
ultimately, if you are in the position to do so, and you are
running Tornado (FCS version) on a PowerPC 603 to load this 
function to see if you encounter a similar problem of the system
hanging up with no discernible pattern (could occur after 20 loops,
or after 300,000), or if it will successfully complete.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

#include "vxWorks.h"
#include "stdio.h"

int cacheTest (void)
 {
   int i,j;

   for (i=j=0; i < 0x100000; i++, j++)
    {
      printf("%d, ", i);
      if (j > 8)
       {
         j = 0;
         printf("\n");
       }
      cacheDisable(1);
      cacheEnable(1);

    } /* end for */

   return (0);
 } /* end cacheTest */

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thanks,
Curtis Dunn

From bemills@sandia.gov  Thu Jan  9 13:58:56 1997
From: bemills@sandia.gov (Barbara Mills)
Date: Thu Jan  9 13:58:58 PST 1997
Subject: CPU self-test routines
Hi.  Does anyone have a self-test (checking ROM, RAM, etc.) for
any of the following processors which runs under vxWorks?

68k
ppc603
ppc604

Thanks in advance.
Barbara Mills
_______________________________________________________
|                                                     |
| Barbara E. Mills          Voice (505) 845-9826      |
| bemills@sandia.gov        Fax   (505) 844-2925      |
|_____________________________________________________|
|                                                     |
|            Sandia National Laboratories             |
|            M.S. 0503                                |
|            P.O. Box 5800                            |
|            Albuquerque, NM  87185                   |
|_____________________________________________________| 

From mjones@vines.littondsd.com  Thu Jan  9 15:07:22 1997
From: "Matthew Jones" <mjones@vines.littondsd.com>
Date: Thu Jan  9 15:07:24 PST 1997
Subject: Fibre Channel Driver

I'm running Vxworks 5.2 on a Themis Sparc CPU 5/64.  I need a driver for a 
Fibre Channel network card, the card
is an Ancor FCS 266 SBus Adapter.  The network protocol is TCP/IP so the 
card will be accessed from the socket API.

I would appreciate pointers/code/documentation to assist me in writing the 
driver.  We would also be open to purchasing
the driver.

Matthew Jones
mjones@vines.littondsd.com

From MikeMcQuade@connect.com  Thu Jan  9 17:03:30 1997
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Jan  9 17:03:32 PST 1997
Subject: Re: CPU self-test routines
At 01:59 PM 1/9/97 PST, you wrote:
>Submitted-by bemills@sandia.gov  Thu Jan  9 13:58:56 1997
>Submitted-by: bemills@sandia.gov (Barbara Mills)
> 
>Hi.  Does anyone have a self-test (checking ROM, RAM, etc.) for
>any of the following processors which runs under vxWorks?
>
>68k
>ppc603
>ppc604
>

I seem to recall that the MVME-260x boards from Motorla have
extensive self testing built into the Open Boot FORTH.

MikeMcQuade@connect.com

From RHOWELLS@racalrec.co.uk  Fri Jan 10 01:34:18 1997
From: RICHARD HOWELLS <RHOWELLS@racalrec.co.uk>
Date: Fri Jan 10 01:34:21 PST 1997
Subject: Re: cacheDisable()
Hi,

We are using Tornado 1.0 under Windows NT.  I've tried
running your code on our MVME1603 board a couple of
times and it does lock the system up - once after 43106
loops, second time after 109451 loops.

Hope this is of assistance,
Richard

Racal Recorders Ltd.,
Southampton, UK.
rhowells@racalrec.co.uk

From daemon@csg.lbl.gov  Fri Jan 10 04:00:14 1997
From: daemon@csg.lbl.gov
Date: Fri Jan 10 04:00:16 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 10 04:00:11 PST 1997

        Subject: Re: ELF to COFF?
        Subject: would you be my friend?

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

Newsgroups: comp.os.vxworks
Subject: Re: ELF to COFF?
Date: Thu, 09 Jan 1997 09:36:04 +0100
From: Philippe Le Foll <phillf@fridu.com>
Organization: Fridu a Free Software Company
Message-ID: <32D4ADF4.24912342@fridu.com>
References: <5aj41p$4gj$1@newsreader.jvnc.net>

Just look for GNU standard LD, you may add emulation [object format]
at compilation time, then using a command like:

ld -r coff1.o coff2.o -o elf.o 

should work. Note that for doing this you need elf to be your default
emulation and coff to be avaliable, LD should detect automaticaly
that input object are in coff and not in elf format.

If automatic detection does not work you will have to set
format/emulation options: -m inpu emulation -oformat outputFormat.

In order to know avaliable format/emulation use

You can check avaliable emulation with:

ld -V
ld version cygnus-2.6 (with BFD 2.6.0.14)
  Supported emulations:
   elf_i386
   i386linux
   i386coff
   m68kelf
   m68klinux
   sun4
   elf32_sparc

Philippe Le Foll

phillf@fridu.com

Rich DeMarinis wrote:
> 
> Does anyone know of any tools to convert the ELF object files generated[-m emulation] [-n|-N] [-noinhibit-exec]
              [-no-keep-memory] [-oformat output-format]
[-m emulation] [-n|-N] [-noinhibit-exec]
              [-no-keep-memory] [-oformat output-format]

> by the Tornado Toolset into Intel COFF object file format? I'm also
> wondering how difficult it would be to convert an existing COFF file
> reader to read ELF files?
> 
> Any help is greatly appreciated!
> 
> Thanks,
> Rich
> --
> --------------------------------------------------------------------
> Rich DeMarinis                   I put instant coffee in a microwave,
> Dialogic Corporation             and almost went back in time.
> R.DeMarinis@dialogic.com         -- Steven Wright

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

Newsgroups: comp.os.vxworks
Subject: would you be my friend?
Date: Fri, 10 Jan 1997 00:58:05
From: dozer@netwizards.net
Message-ID: <5b50ab$kmr@news1-alterdial.uu.net>

Hello,

I'm 14 years old and I think I may be a gay.  I'm looking for some support and friendship 
with a older male age 18-40.  Please email if you can help.

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

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

From Chris_Nickles@ATK.COM  Fri Jan 10 08:33:20 1997
From: Chris_Nickles@ATK.COM (Chris Nickles)
Date: Fri Jan 10 08:33:26 PST 1997
Subject: Booting from flash

There have been several postings recently asking about experiences
booting from flash.  We have been able to boot from a GreenSpring
IP-Flash card mounted on an MVME-162.  A few years ago Mark del
Giorno (del@rst.com) posted that he had added a RAM boot facility
to enable booting from a ramDrv/dosFs image in a battery-backed
RAM.  It works fine with flash as well.

We've partitioned the 8 Meg IP-Flash into four 2 Meg disk images.
This allows you to create a modified image while keeping the
current one intact.  Initially, you create a 2 Meg drive in ram,
and copy the kernel, symbol table, application objects and startup
file into it.  I've used both the copy() and ftp.  Next, write the
image of the drive into the flash.  Finally, set the boot device
to ram:<flash address>.

To change an object module, you again create a drive in ram.
Copy the old flash image to the ram, make the replacements, make
a new flash image, and change the address in the boot paremeters.

Hope this helps.

	Chris Nickles
	Alliant Techsystems
	Marine Systems San Diego

From stan@rti.com  Fri Jan 10 14:28:42 1997
From: stan@rti.com (Stan Schneider)
Date: Fri Jan 10 14:28:43 PST 1997
Subject: Speaker for Monday night

User's group meeting update:

The speaker Monday night is Dr. Jim Mitchell, Sun Fellow and VP of Technology
and Architecture at JavaSoft!  It should be *real* interesting.  

Be there: 4pm Monday at Techmart!

	-- Stan

From ppk@dancris.com  Sat Jan 11 02:51:37 1997
From: "ppk@dancris.com" <ppk@dancris.com>
Date: Sat Jan 11 02:51:39 PST 1997
Subject: Please excuse the intrusion
Dear Internet User,

Please excuse the intrusion but I thought you might be interested in
the following information.

I am the marketing director for Computer Parts USA.
Our current prices are: 8meg 72pin Simm $30.00,  16meg 72pin $69.00.

I invite you to visit our website at www.computerpartsusa.com

If you are not interested, please accept my apology.
If you wish to not receive any more information just type "Remove" in
the body of the message and click reply.

Thank you for your time and consideration,
KimberlyAnn

From daemon@csg.lbl.gov  Sat Jan 11 04:00:12 1997
From: daemon@csg.lbl.gov
Date: Sat Jan 11 04:00:15 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 11 04:00:11 PST 1997

        Subject: RPC - VxWorks and Solaris

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

Newsgroups: comp.os.vxworks,comp.unix.solaris
Subject: RPC - VxWorks and Solaris
Date: 11 Jan 1997 02:34:26 GMT
From: andrew@andrew.triumf.ca (Andrew Daviel)
Organization: TRIUMF
Message-ID: <5b6u7i$l51$1@nntp.ucs.ubc.ca>
Reply-To: advax@triumf.ca

We have a PowerPC running VxWorks, with Solaris as the host system.
When running rpcgen to generate the server code for a client-server
application, there are a lot of unresolved header files and symbols in
xxx_svc.c.

We have previously compiled this application for VxWorks on a 68030
under SunOS, and the client also under Linux and Irix. 
The Solaris rpcgen generates more #include statements
in both native and back-compatible ("-b" switch) than the SunOS and
other  ones, including code calling syslog which (I believe) doesn't
exist on VxWorks.

How can one do this? Is it necessary to build a VxWorks version of rpcgen
somehow ?

- --
Andrew Daviel         mailto:advax@triumf.ca 
TRIUMF                voice: 604-222-7376 
4004 Wesbrook Mall    fax:   604-222-7307 
Vancouver BC          http://andrew.triumf.ca/~andrew 
Canada   V6T 2A3      49D14.7N 123D13.6W

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

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

From cpd@one.com  Sun Jan 12 17:32:35 1997
From: cpd@one.com (Chris P. Domin)
Date: Sun Jan 12 17:32:37 PST 1997
Subject: Re: Please excuse the intrusion
remove

From 72614.660@compuserve.com  Sun Jan 12 23:22:43 1997
From: "Jose' Roberto Alvarez" <72614.660@compuserve.com>
Date: Sun Jan 12 23:22:45 PST 1997
Subject: Please excuse the intrusion
remove

From avlasblo@best.ms.philips.com  Mon Jan 13 01:33:18 1997
From: Arjon Vlasblom <avlasblo@best.ms.philips.com>
Date: Mon Jan 13 01:33:19 PST 1997
Subject: Re: Please excuse the intrusion
At 23:22 12-01-97 PST, you wrote:
> 
> Submitted-by 72614.660@compuserve.com  Sun Jan 12 23:22:43 1997
> Submitted-by: "Jose' Roberto Alvarez" <72614.660@compuserve.com>
>  
> remove
> 
> **********

Please, don't send a 'remove' replies back to the VxWorks exploder.

This will still let the VxWorks exploder on the mailing list of this company.
I think the exploder administrator has to 'remove' us from that list.

Regards,
Arjon

--
 ____________________________________________________________________
/                                                                    \
| Arjon Vlasblom                        | Philips Medical Systems    |
| Software Project Leader               | Building QJ2310            |
| Voice : +31-40-2763126                | P.O. Box 10000             |
| Fax   : +31-40-2765657                | 5680 DA Best               |
| E-mail: avlasblo@best.ms.philips.com  | The Netherlands            |
|--------------------------------------------------------------------|
|  You cannot achieve the impossible without attempting the absurd.  |
\____________________________________________________________________/

From daemon@csg.lbl.gov  Mon Jan 13 04:00:14 1997
From: daemon@csg.lbl.gov
Date: Mon Jan 13 04:00:16 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 13 04:00:11 PST 1997

        Subject: Internet Fax Service

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

Newsgroups: comp.os.vxworks
Subject: Internet Fax Service
Date: 12 Jan 1997 22:10:02 GMT
From: info@mage.com
Message-ID: <5bbnfq$3h0@nntp1.best.com>

- --------------------- Internet Fax Service --------------------------
- ------------------ Save Your Long distance charges ------------------
- ------------ HT-Net Internet International Fax Network --------------

For the mobile workers, accessing and managing your faxes from a remote
location. Long distance or international telecommunications can be very
expensive and until now there has been no simple way to manage faxes
from a distance.

Check HT-Net at http://www.twsp.com

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

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

From Chris_Nickles@ATK.COM  Mon Jan 13 08:22:41 1997
From: Chris_Nickles@ATK.COM (Chris Nickles)
Date: Mon Jan 13 08:22:43 PST 1997
Subject: Booting from flash - CORRECTION

I submitted a posting last week attributing a ram boot facitily
to Mark del Giorno.  This was wrong.  He provided a driver for the
Greenspring IP-Octal drive, which I used at about the same time.
The ram boot code came from Bret Goodrich (goodrich@noao.edu).
My apologies to both of them.

	Chris Nickles
	Alliant Techsystems
	Marine Systems San Diego

From ddavies@worf.utsci.com  Mon Jan 13 08:25:21 1997
From: ddavies@worf.utsci.com (Douglas Davies)
Date: Mon Jan 13 08:25:23 PST 1997
Subject: Remove

From ddavies@worf.utsci.com  Mon Jan 13 09:09:15 1997
From: ddavies@worf.utsci.com (Douglas Davies)
Date: Mon Jan 13 09:09:25 PST 1997
Subject: Re: Remove
Sorry folks,

As soon as I replied, I realized that this had come in on the
VxWorks exploder.

I truely detest being spammed!  Electronic junk mail is truely
bad form IMHO.

-Doug

From fenj@cm-tts.com  Mon Jan 13 10:01:00 1997
From: Fen Jain <fenj@cm-tts.com>
Date: Mon Jan 13 10:01:01 PST 1997
Subject: Re:  Please excuse the intrusion
Remove. This user group is only for technical information exchange on VxWorks.
You should not have put your ad in this group.

From rgordon@net.com  Mon Jan 13 14:29:03 1997
From: rgordon@net.com (Roy Gordon)
Date: Mon Jan 13 14:29:05 PST 1997
Subject: symFindbyName() problem

We are working using C++ and vxSim 5.3.

symFindbyName() isn't returning the address of functions whether or not
we pass in the mangled or demangled name (we've tried all combinations).

The vxWorks shell recognizes the name (mangled) and we can in fact
breakpoint there.

Here's are call:

	rv = symFindByName(sysSymTbl, name, (char **)&entryPt, &pType);
        if (rv == ERROR) {
                
                
The name in question is:

	ifnsSvr

and the mangled name, according to nm, is:

	ifnsSvr__FiPPc
	
But, we tried setting 'name' to:

	ifnsSvr
	_ifnsSvr
	ifnsSvr__FiPPc
	_ifnsSvr__FiPPc
	
and none work.  (We tried prepending an '_' because we were told that
internally all symbols begin with an underbar.

The symbol is clearly there (as can be seen in the shell, and gdb) but we
can't seem to find it using symFindByName().  We load all our executables
prior to running any tasks.

Any ideas, advice, etc.?

TIA.

					-- roy
					

Someone told us that there are C++->C name conversion functions and we
should use those before calling symFindByName().  But we haven't been
able to find them?  Have we just been blind to it?

91: nm ifnsSvr | egrep ifnsSvr
ifnsSvr:
[15]    |         0|       0|FILE |LOCL |0    |ABS    |ifnsSvr.cc
[3047]  |         0|     664|FUNC |GLOB |0    |1      |ifnsSvr__FiPPc

From daemon@csg.lbl.gov  Tue Jan 14 04:00:18 1997
From: daemon@csg.lbl.gov
Date: Tue Jan 14 04:00:20 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 14 04:00:16 PST 1997

        Subject: Opinions on pSOS and Other Operating Systems
        Subject: Re: Startup scripts
        Subject: Re: Flash Memory Driver and File System
        Subject: VxVMI amendment to defective posting!

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

Newsgroups: comp.os.os9,comp.os.vxworks,comp.os.lynx
Subject: Opinions on pSOS and Other Operating Systems
Date: Tue, 14 Jan 1997 00:26:00 GMT
From: mitch@manta.nosc.mil (Ray Mitchell)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1997Jan14.002600.3350@nosc.mil>
Sender: news@nosc.mil

Greetings Everyone,

I know this is a loaded question but here goes anyway.  I would appreciate
it if OS sales representatives would refrain from responding, however,
since I've probably already talked to you or seen your product.
I am looking for the opinions of those who actually have used
the products in various real projects and don't have an axe to grind.

I am planning to purchase a real-time OS for an upcoming project for
the military.  I have considered the latest OS9, VXWORKS, pSOS, and LYNX
operating systems and any salesperson will tell you exactly what is
wrong with the competitor's product and why theirs is the best.

Since my application cannot be considered exactly cutting edge with
respect to the demands it puts on the OS, my main concern is product
maturity, stability, ease of use (including good documentation), and
support.  Although price is a consideration, I would rather pay more
to buy a product than to spend my time later trying to figure out
how to use it or trying to get bugs fixed.

Since I assume many readers of the newsgroups to which I have posted
probably have experience with more than one real-time OS, I would
greatly appreciate any appropriate comments.  I am tending toward
VxWorks (Tornado) primarily because of its widespread use and resulting
support base already in the military.

Horror stories are welcome!

Thanks,
Ray Mitchell

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

Newsgroups: comp.os.vxworks
Subject: Re: Startup scripts
Date: Fri, 10 Jan 1997 09:22:42 GMT
From: 100567.1652@compuserve.com (Rolf Grzibek)
Organization: Philips BTS
Message-ID: <5b51ns$376@news.Dortmund.Germany.EU.net>
References: <01bbfe29$67c99900$973482c2@irvine.csl.co.uk>

"Robert Humphris" <rhumphris@csl.co.uk> wrote:

>Hi,

>I am using a startup script, and I want to add comments to it so that a 3rd
>party can edit it.
>Anyone know how this simple thing is done? Also are there any extra
>features that the
>startup script offers that are not in the shell?

>Your comments/advice please

>Rob Humphris

The target shell uses /* comment */ and 
# comment 
(like unix shell) for comments.

Hope that helps
Rolf

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

Newsgroups: comp.os.vxworks
Subject: Re: Flash Memory Driver and File System
Date: Fri, 10 Jan 1997 09:22:43 GMT
From: 100567.1652@compuserve.com (Rolf Grzibek)
Organization: Customer of EUnet Germany; Info: info@Germany.EU.net
Message-ID: <5b51nt$376@news.Dortmund.Germany.EU.net>
References: <199701091542.KAA09423@wednesday.sciatl.com> <5b3he0$a01@news.sdd.hp.com>

wmartin@sdd.hp.com (William Martin (Temp)) wrote:

>In article <199701091542.KAA09423@wednesday.sciatl.com>, jthompson@cabm.sciatl.com (Jeff.Thompson) writes:
>|> I am developing firmware for the headend equipment used in our cable modem
>|> product line. The target is a Motorols MVME-2603 "Slim-Gen" board. I am
>|> looking for a flash memory driver and file system.

>Take a look at the vxworks user group files at UCAR. I know knothing about it,
>but I saw a file there which claims to be a flash memory filesystem...

>Bill

Yes, there is something, but you need the source code of dosFsLib from
VxWorks 5.1 (i think).

But you can check out the FlashLib software from RST. Leonid Rosenboim
(leonid@rst.co.il) is very active in this group.

Hope that helps

- --
Rolf Grzibek   100567.1652@compuserve.com

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

Newsgroups: comp.os.vxworks
Subject: VxVMI amendment to defective posting!
Date: Tue, 14 Jan 1997 10:25:46 GMT
From: i.kerr@dra.hmg.gb (Ian Kerr)
Organization: DRA
Message-ID: <5bfkv5$bf2$1@trog.dra.hmg.gb>
Reply-To: I.KERR@DRA.HMG.GB

VxVMI package query.

This was  the garbled, at least to me, attachment to yesterdays
posting. Will try to do better next time.

Q: Does anyone have any experience with VxVMI specifically
on MC68030 cards? What things have people been able to do
successfully? We were hoping to use it for protecting tasks
mutually write protecting them and all their associated data areas,
trap errors and continue to run all the other tasks which are
not the one which is trying to mess them around.

Any help would be welcome.

P.S. Does anyone know why my previous attempt to send an attachment
when using Agent ver 0.55beta was unreadable (a bug?)

Ian Kerr
Ian Kerr (i.kerr@dra.hmg.gb)
DRA Farnborough
Hampshire
United Kingdom
GU14 0LX
Tel: + (44)1252 397081
FAX: + (44)1252 395021

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

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

From jcarissi@BBN.COM  Tue Jan 14 07:23:09 1997
From: Joe Carissimi <jcarissi@BBN.COM>
Date: Tue Jan 14 07:23:11 PST 1997
Subject: Zip configuration proble
We are having trouble configuring an Iomega Zip 
	drive.  Our target processor is a DY4 SVME-163E with the 
	MAX220 daughter card and is running vxWorks 5.2.Communication
	with the drive is via the SCSI connection on the 220. At 
	boot, the drive is recognized and configured as a DOS
	device, but the results of the dosFsConfigShow indicate
	0 bytes available. Attempts to read or write to the 
	disk have all failed.  We have a formatted disk in
	the drive (formatted via diskFormat) and know that the
	drive is accessed (green light flashes during format).

	Has anyone had any success with a Zip, or hints as to what
	this problem may be related to.

	Joe Carissimi 
	BBN Corporation
   	4 John Clarke Road   Middletown, RI  02842
	jcarissi@bbn.com     401-849-2543 (X25)

From jlm01@mhs.sperry-marine.com  Tue Jan 14 08:18:07 1997
From: John Mouring <jlm01@mhs.sperry-marine.com>
Date: Tue Jan 14 08:18:09 PST 1997
Subject: ROM Execution

Has anybody successfully implemented an imbedded x86 design that uses   
VxWorks and executes the application out of ROM with only enough RAM for   
the stack and heap?

jlm01@mhs.sperry-marine.com  

From jlm01@mhs.sperry-marine.com  Tue Jan 14 08:24:04 1997
From: John Mouring <jlm01@mhs.sperry-marine.com>
Date: Tue Jan 14 08:24:06 PST 1997
Subject: ATM Networks

Has anybody successfully implemented (or do you have underway) an   
imbedded product that uses VxWorks and connects to an Asynchronous   
Transfer Mode (ATM) Network?

Have you integrated VxWorks, ATM Stack (from Trillium, Harris-Jeffries,   
etc.) and drivers?

From hansen@pistilmac1.chinalake.navy.mil  Tue Jan 14 14:48:44 1997
From: hansen@pistilmac1.chinalake.navy.mil (Joe Hansen)
Date: Tue Jan 14 14:48:45 PST 1997
Subject: Re: ROM Execution
>John Mouring wrote:
>
>
>Has anybody successfully implemented an imbedded x86 design that uses
>VxWorks and executes the application out of ROM with only enough RAM for
>the stack and heap?
>
>jlm01@mhs.sperry-marine.com
>

I assume you are talking about executing an application that has been burnt
into the BOOT ROM.  I have not written applications with this approach, but
I have modified the boot configuration and burnt new BOOT ROMs.

I don't see why you could not run an application from ROM, although you may
run out of memory if your application is too big.  When I modified our BOOT
ROM, I needed to add support for booting off of a SCSI device.  This was
straightforward, but it would not fit, so I had to remove some of the other
support libraries (in particular, the debugger and floating-point support
(and, no, this application didn't need fp support)).  This did not matter,
as I booted off of the SCSI drive, and then loaded the debugger into RAM.

I would be very interested in hearing more about your application.  Could
you e-mail me an abstract?

Thanks --

Joseph Hansen
hansen@pistilmac1.chinalake.navy.mil

From cgrames@mdc.com  Tue Jan 14 15:39:23 1997
From: Charlie Grames <cgrames@mdc.com>
Date: Tue Jan 14 15:39:29 PST 1997
Subject:  Driver for Serial Ports 3 and 4 on MVME160x/260x/360x
Hello, All!

Does anyone have a simple driver for serial ports 3 and 4 on a Motorola MVME160x, 260x, 360x
board?  The serial hardware is the Zilog Z85230 chip.  All I am really looking for is asynchronous
support at the normal range of baud rates (50 - 38400).

Thanks in advance.

Charlie Grames
McDonnell Douglas Training & Support Systems
(314) 233-1956
CGrames@mdc.com

From daemon@csg.lbl.gov  Wed Jan 15 04:00:17 1997
From: daemon@csg.lbl.gov
Date: Wed Jan 15 04:00:20 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 15 04:00:15 PST 1997

        Subject: Re: symFindbyName() problem
        Subject: Shared memory network
        Subject: RST's chkdsk

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

Newsgroups: comp.os.vxworks
Subject: Re: symFindbyName() problem
Date: Tue, 14 Jan 1997 17:30:27 -0500
From: Jeremy Frank <jfrank@teklogix.com>
Organization: Teklogix Incorporated
Message-ID: <32DC0903.641F@teklogix.com>
References: <199701132228.OAA08745@tahiti.net.com>
Reply-To: jfrank@teklogix.com

hi,

Roy Gordon wrote:
> 
> We are working using C++ and vxSim 5.3.
> 
> symFindbyName() isn't returning the address of functions whether or not
> we pass in the mangled or demangled name (we've tried all combinations).
> 
> The vxWorks shell recognizes the name (mangled) and we can in fact
> breakpoint there.

I must ask:
- -- Does your target have a symbol table?  Often with vxworks 5.3, the
target does not have a symbol table, since Tornado can take care of
symbol lookups.  (I have not used vxsim5.3, so I have no experience
about how they configured it.)  The options are:  no symbol table, load
symbol table at startup, or standalone symbol table.
- -- Is the "vxWorks shell" you mention part of Tornado?  Target-resident
shells rely on a target-resident symbols table, whereas Tornado shells
rely on the Tornado host-resident symbols table.

I am guessing that perhaps you have no target-resident symbol table
(which saves you many MB of ram!), so any target-based calls to
symFindByName will fail, and that you are using the Tornado shell, which
is using its own host-based symbol lookup.  I really wish Tornado had
been designed to make it clear what commands run on the host and what
commands run on the target.

> Someone told us that there are C++->C name conversion functions and we
> should use those before calling symFindByName().  But we haven't been
> able to find them?  Have we just been blind to it?

Yes, there is such a beast.  No, you are not blind.  It is simply one of
the many "private" features of vxworks (WRS: Why oh why is this
private?)!  It is called cplusDemangle().  Check out
/tornado/target/h/private/cplusLibP.h.  I do not know whether the symbol
table would contain the mangled or unmangled name.

- --jsf

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

Newsgroups: comp.os.vxworks
Subject: Shared memory network
Date: Wed, 15 Jan 1997 13:22:02 +0800
From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
Organization: Hong Kong University of Science and Technology
Message-ID: <32DC697A.41C67EA6@ee.ust.hk>

Hello,

  We have an urgent problem getting the shared memory network running.
We can boot up the shared memory network master processor, Motorola
 MVME166, and have access to the on-board shared memory pool, but the
second MVME166 cannot be booted up with the following prompt message.
*******************************************************************
boot device          : sm=0x2000600
processor number     : 1 
host name            : eesu64
file name            : /robot/vx/config/mv166a/vxWorks
inet on backplane (b): 173.16.12.2:fffffc00
host inet (h)        : 143.89.44.64
gateway inet (g)     : 173.16.12.1
user (u)             : eerobot
ftp password (pw)    : multirobot
flags (f)            : 0x0 
target name (tn)     : vxwork1

Backplane anchor at 0x2000600... Attaching network interface sm0...
done.
smIsAlive:  readyValue = 0x0, heartbeat = 0x0
smIsAlive:  readyValue = 0x87654321, heartbeat = 0x0
Attaching network interface lo0... done.
Loading... 
Error loading file: errno = 0x3c.
Can't load boot file!!
********************************************************************

When loading boot file to the second MVME166, we use the command
smNetShow to display the state of the shared memory network and get
the following result.

*********************************************************************
- -> smNetShow
Anchor Local Addr: 0x600
Sequential addressing enabled.  Master address: 173.16.12.1

heartbeat = 14, header at 0xf36fac, free pkts = 235.

cpu int type    arg1       arg2       arg3    queued pkts
- --- -------- ---------- ---------- ---------- -----------
 0  mbox-1         0x2d     0xcc02        0x8       0
 1  poll              0          0          0       0

input packets =   2  output packets =   2
input errors  =   0  output errors =   0  
collisions    =   0
value = 0 = 0x0
*********************************************************************

I hesitate the problem results from the interrupt type of the second 
CPU. But in the confiugre head file of  the second CPU, we have defined
the interrup type as follows

#define SM_INT_TYPE SM_INT_MAILBOX_1

Why is it poll type? I don't see!

Zhiqiang Qin

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

Newsgroups: comp.os.vxworks
Subject: RST's chkdsk
Date: 14 Jan 1997 16:23:25 GMT
From: getz@fs.lmco.com
Organization: Lockheed Martin Federal Systems
Message-ID: <5bgbtt$ekv@inetserv2.fs.lmco.com>
Reply-To: fred.getz@lmco.com

On a Force 5CE processor running vxWorks 5.2, we are seeing NFS problems when we run chkdsk() to check the
DOS filesystem on our scsi hard disk.  After running chkdsk, any attempt to access files on that machine via
NFS result in a "Stale NFS Handle" message.  This problem occurs even when chkdsk() is run with no parameters
(i.e. no fixes are performed, just a check).  In order to regain NFS access, the target system has to be rebooted
and an umount/mount of the NFS on the host system is required.  

Thanks,
Fred Getz	

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

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

From pdave@telco.com  Wed Jan 15 05:37:22 1997
From: pdave@telco.com (Pratyush Dave)
Date: Wed Jan 15 05:37:24 PST 1997
Subject: Re: ATM Networks
We currently have an embedded project under development.  We are using 
VxWorks (ver 5.3) and our product will connect to ATM network.  We are 
currently integrating VxWorks.

Pratyush Dave				Telco Systems, Inc.
Email: pdave@telco.com			Website: www.telco.com

From SECKA@hqgate.orbital.com  Wed Jan 15 07:09:31 1997
From: SECKA@hqgate.orbital.com
Date: Wed Jan 15 07:09:37 PST 1997
Subject: Code Segments: COMMON, common, and bss
     
     Can anyone shed some light on common, COMMON, and bss:  what's the 
     difference between them; when does common turn into COMMON; when does 
     COMMON get combined with bss; what does the GNU "size" utility show; 
     what can we expect to see after a compile, an incremental link, a 
     full link; etc.
     
     We're working on an embedded 68302 target, and we're using the GNU 
     toolset and Tornado on a Sun/Solaris host.  Our target systems have 
     limited RAM and we're trying to keep a close watch on our RAM usage 
     every step of the way!
     
     
     -------------------------------------------------------------------
     -                                                                 -
     - Suzie Eckardt, Principal Software Engineer                      -
     - Orbital Sciences Corp.          email: secka@hqgate.orbital.com -
     - 21700 Atlantic Blvd.            Phone: 703-406-5478             -
     - Dulles, VA  20166               Fax:   703-406-5553             -
     -
     ------------------------------------------------------------------- 

From mea@mclean.sparta.com  Wed Jan 15 07:28:41 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed Jan 15 07:28:43 PST 1997
Subject: Re: Shared memory network
At 04:00 AM 1/15/97 PST, you wrote:
>From: "Dr. Zexiang Li's Robotic Project" <eerobot@ee.ust.hk>
>
[ ...snip...]
>Attaching network interface lo0... done.
>Loading... 
>Error loading file: errno = 0x3c.
>Can't load boot file!!

This message typically results from the boot host at
143.89.44.64 not having a return route to the 
173.16.0.0 network (of course, you have to adjust the
address to account for your subnet mask).  Try and ping 
CPU 0's 173.16.12.1 address from the boot host.  If you
can't ping the backplane Inet address from the boot host,
then the boot host can't route packets to the second
CPU either, hence the error code of 0x3c (S_errno_ETIMEDOUT).

Simply add a route to your boot host (assuming you're using
Unix) like this:

route add net 172.16.0.0 <CPU 0's 143.89 address> 1

Then retry the ping.  If it works, then your CPU 1 should
then be able to reboot.  If you want this to be a more
permanent situation, then add the "route add" command given
above to your /etc/rc.local.

>********************************************************************
>
>When loading boot file to the second MVME166, we use the command
>smNetShow to display the state of the shared memory network and get
>the following result.
>
>heartbeat = 14, header at 0xf36fac, free pkts = 235.
>
>cpu int type    arg1       arg2       arg3    queued pkts
>- --- -------- ---------- ---------- ---------- -----------
> 0  mbox-1         0x2d     0xcc02        0x8       0
> 1  poll              0          0          0       0
>

[...snip...]

>
>Why is it poll type? I don't see!

It's poll type because the SM network is running out of the
boot rom image in RAM.  As soon as you get VxWorks to boot
properly, then it will change to "mbox-1".

HTH,

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

From leonid@rst.co.il  Wed Jan 15 09:40:16 1997
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Wed Jan 15 09:40:18 PST 1997
Subject: Re: RST's chkdsk
On 14 Jan 1997, getz@fs.lmco.com (Fred Getz) wrote:
> On a Force 5CE processor running vxWorks 5.2, 
> we are seeing NFS problems when we run chkdsk() 

Dear Fred, your email address getz@fs.lmco.com does not work,
as I tried to reply on this to you directly.

However, to answer your question, the reason for the NFS server
sympthom you describe is the usage of dosFsVulUnmount() function
in chkdsk().

Contact me directly if you need further clarifications on this.

From harry@ellips.nl  Wed Jan 15 12:37:45 1997
From: Harry Stox <harry@ellips.nl>
Date: Wed Jan 15 12:37:47 PST 1997
Subject: changing ftpd output format to /bin/ls style?
Hello,

For remote disk management of the
dosFs disk in the VxWorks target system
by our customers I'm looking for a way to 
use a "user-friendly" win-32 based FTP client 
(like WS_FTP32) to connect to the standard 
VxWorks ftpd.

Although "manual" tree traversal using a traditional
command-line based ftp client and "human" directory
listing interpretation can be used with the standard
ftpd, its directory listing format is very different from
standard /bin/ls style output, so most explorer-style
Win95/NT clients cannot interpret it correctly.

How can I change the output format of ftpd so that
it resembles /bin/ls output enough so that those
clients can interpret it?

Alternatively, does anyone have e.g. ncftp or 
WS_FTP patches available so that they can be
used with the standard ftpd directory output style?

Thanks in advance for keeping me from reinventing
the wheel (i.e. writing yet another ftp client).

Best regards,
Harry Stox.

From ymj@inel.gov  Wed Jan 15 14:26:47 1997
From: Jeffrey Young <ymj@inel.gov>
Date: Wed Jan 15 14:26:49 PST 1997
Subject: help me

help

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
* Jeffrey M. Young 			Voice:	(208) 526-5416	    *
* Lockheed Martin Idaho Technologies	Fax:	(208) 526-7688	    *
* Idaho National Engineering Laboratory	Email:	ymj@inel.gov	    *
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

From sng@eng.kns.com  Wed Jan 15 14:28:11 1997
From: sng@eng.kns.com (Susan Ng)
Date: Wed Jan 15 14:28:13 PST 1997
Subject: unsubscribe

unsubscribe

From stan@rti.com  Wed Jan 15 19:34:26 1997
From: stan@rti.com (Stan Schneider)
Date: Wed Jan 15 19:34:28 PST 1997
Subject: Re: symFindbyName() problem

>> Submitted-by rgordon@net.com  Mon Jan 13 14:29:03 1997

>> We are working using C++ and vxSim 5.3.
>> 
>> symFindbyName() isn't returning the address of functions whether or not
>> we pass in the mangled or demangled name (we've tried all combinations).

Are you using the target-resident symbol table?  If not, then winsh & crosswind
will find the symbol just fine, but symFindByName doesn't really exist; it's a
stub to a routine that returns an error.  Tornado does this to save target
memory---symbol tables get big.  There are many workarounds to this, including
a free syncronization script that Leonid posted some time back (so both host &
target symbol tables match), and a host-based "target-server server" included
with our RTILib product (so the target can use the host-based table).

Hope this helps,

	-- Stan

From gilibert@scn.de  Thu Jan 16 00:21:30 1997
From: Giuseppe Giliberto <gilibert@sbs.de>
Date: Thu Jan 16 00:21:33 PST 1997
Subject: Writing a serial driver
--=====================_853435244==_
Content-Type: text/plain; charset="us-ascii"

--=====================_853435244==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="HELP.TXT"

I have successfully ported a BSP to a 68XXX board but I must face 
a trickier problem now, that's writing a serial driver with the 
following characteristics: it has to be used by TCP/IP in the upper
layers while talking with a HDLC protocol over the line. I'm afraid I
haven't got a clue about how to start...
I've been reading the relevant documentation  but it does
not seem to be very clear. What can I do? Is there anybody willing
to help me crack this?
Thanks in advance

Claudio Nardi

--=====================_853435244==_--

From avlasblo@best.ms.philips.com  Thu Jan 16 02:41:29 1997
From: Arjon Vlasblom <avlasblo@best.ms.philips.com>
Date: Thu Jan 16 02:41:31 PST 1997
Subject: Re: Writing a serial driver
At 00:21 16-01-97 PST, you wrote:
> 
> Submitted-by gilibert@scn.de  Thu Jan 16 00:21:30 1997
> Submitted-by: Giuseppe Giliberto <gilibert@sbs.de>
>  
[snip]
> 
> I have successfully ported a BSP to a 68XXX board but I must face 
> a trickier problem now, that's writing a serial driver with the 
> following characteristics: it has to be used by TCP/IP in the upper
> layers while talking with a HDLC protocol over the line. I'm afraid I
> haven't got a clue about how to start...
> I've been reading the relevant documentation  but it does
> not seem to be very clear. What can I do? Is there anybody willing
> to help me crack this?
> Thanks in advance
> 
> Claudio Nardi
> 

What you're looking for is IMHO a PPP or SLIP driver.

Hope this will point you in some direction.

Arjon

--
 ____________________________________________________________________
/                                                                    \
| Arjon Vlasblom                        | Philips Medical Systems    |
| Software Project Leader               | Building QJ2310            |
| Voice : +31-40-2763126                | P.O. Box 10000             |
| Fax   : +31-40-2765657                | 5680 DA Best               |
| E-mail: avlasblo@best.ms.philips.com  | The Netherlands            |
|--------------------------------------------------------------------|
|  You cannot achieve the impossible without attempting the absurd.  |
\____________________________________________________________________/

From jonathan.hillman@wrs.com  Thu Jan 16 06:27:19 1997
From: Jon Hillman <jonathan.hillman@wrs.com>
Date: Thu Jan 16 06:27:22 PST 1997
Subject: Re: Writing a serial driver
At 12:21 AM 1/16/97 PST, Claudio Nardi wrote:
>I have successfully ported a BSP to a 68XXX board but I must face 
>a trickier problem now, that's writing a serial driver with the 
>following characteristics: it has to be used by TCP/IP in the upper
>layers while talking with a HDLC protocol over the line. I'm afraid I
>haven't got a clue about how to start...
>I've been reading the relevant documentation  but it does
>not seem to be very clear. What can I do? Is there anybody willing
>to help me crack this?

Claudio,

Use slip/ppp as the TCP/IP and implement it on top of a serial driver
written for HDLC.  slip/ppp merely wants a serial device to talk to;
use one of the drivers in target/src/drv/serial as a template.

        _________________________
       | Jon Hillman, FAE        |       
       | Wind River Systems      |       
      /) (407) 273-4646          (\      
     / ) Email:jhillman@wrs.com  ( \    
   _( (|_________________________) )  />  
  (((\ \)  /,)             / )  / //))/  
  (\\\\ \_/ /              \ \_/ /////    
   \       /                \       /      
    \    _/                  \_    /          
----/   /----------------------\   \----
   /   /                        \   \

From ddavies@worf.utsci.com  Thu Jan 16 08:46:21 1997
From: ddavies@worf.utsci.com (Douglas Davies)
Date: Thu Jan 16 08:46:23 PST 1997
Subject: Re: Writing a serial driver
> Submitted-by: Giuseppe Giliberto <gilibert@sbs.de>
>  
> I have successfully ported a BSP to a 68XXX board but I must face 
> a trickier problem now, that's writing a serial driver with the 
> following characteristics: it has to be used by TCP/IP in the upper
> layers while talking with a HDLC protocol over the line. I'm afraid I
> haven't got a clue about how to start...
> I've been reading the relevant documentation  but it does
> not seem to be very clear. What can I do? Is there anybody willing
> to help me crack this?
> Thanks in advance
> 
> Claudio Nardi

Claudio,

VxWorks supports SLIP (Serial Line Internet Protocol).  Read up on
it.  Once you have your serial driver working, you should be able
to enable and configure SLIP to do the job for you.  Read the section
on SLIP and CSLIP in your VxWorks Programmer's guide.

Good luck,

-Doug

From calley@dlcc.com  Thu Jan 16 09:05:06 1997
From: calley <calley@dlcc.com>
Date: Thu Jan 16 09:05:08 PST 1997
Subject: RE: Writing a serial driver
We did this for the MC68360.  We modified the ethernet driver supplied
by WRS to do HDLC.  The
structure of the driver remained very similar to the ethernet, but the
driver talks HDLC.  This allows
the driver to "attach" in the standard vxWorks way, interfacing to the
OS for higher level supported
protocols such as TCP/IP.  

Unfortunatedly WRS has absolutely no support for HDLC, so you're on your
own for drivers. 
-Chris

>
>I have successfully ported a BSP to a 68XXX board but I must face 
>a trickier problem now, that's writing a serial driver with the 
>following characteristics: it has to be used by TCP/IP in the upper
>layers while talking with a HDLC protocol over the line. I'm afraid I
>haven't got a clue about how to start...
>I've been reading the relevant documentation  but it does
>not seem to be very clear. What can I do? Is there anybody willing
>to help me crack this?
>Thanks in advance
>
>Claudio Nardi
>
>

From ddavies@worf.utsci.com  Thu Jan 16 13:24:57 1997
From: ddavies@worf.utsci.com (Douglas Davies)
Date: Thu Jan 16 13:24:58 PST 1997
Subject: Delay in posts
My last message to the exploder was submitted at approximately 9-10 AM
and took 4-5 hours before I received the post.  Has anyone else been
noticing this delay?

-Doug

From tmorris@me.umn.edu  Thu Jan 16 16:39:03 1997
From: Ted Morris <tmorris@me.umn.edu>
Date: Thu Jan 16 16:39:05 PST 1997
Subject: VxSIM 5.1

Howdy.

We have a couple of VxSIM 5.1 licenses and I am trying to configure one to the
default ip addr range of 127.0.1.0 - 127.0.1.15 on one host and 
.16 - .31. on the other host.

I modified NN=16 and MAX_ULIPS=31 in  installUlip, eg:

tool=`basename $0`
hn=`hostname`

# actually 0-15 devices (IP addresses ip.NN to ip.MAX_ULIPS)
NN=16
MAX_ULIPS=31
ip="127.0.1"

Then, for example assuming I wish to launch VxSIm #17, I created the
following NVRAM boot param file for 17:

simbox% more vxWorks.nvram17
ul(0,17)trucker.me.umn.edu:/data/home/morris/bin/vxWorks e=127.0.1.17
h=134.84.213.70 u=morris
simbox% 

This caused file synch problems on the host and caused a reboot.  So I
tried this instead with vxWorks.nvram1:

ul(0,1)trucker.me.umn.edu:/data/home/morris/bin/vxWorks e=127.0.1.17
h=134.84.213.70 u=morris

which DID load CPU1 but the IP address didn't match correctly.  I
noticed something a bit strange in installUlip.  If I set the limits
to NN=16 to MAX_ULIPS=31, installUlip creates ulip0 through ulip31 !!
Indeed, it did create all these in /dev Is this correct?  It also
configures the net if ul0 to ul31.  Should the ip addresses all be
mapped to Ulip0 through Ulip15?  Would I be better advised to use
127.0.2.xx sub-net instead?  Below is the portion of the installUlip
script.

Thanks to anyone in advance!!

Ted

.
.
.
echo "$tool : setting ULIP interface addresses to $ip.<$NN-$MAX_ULIPS>"

N=0
while [ $N -le $MAX_ULIPS ]; do
    /usr/etc/ifconfig ul$N $hn $ip.$NN
    N=`expr $N + 1`
    NN=`expr $NN + 1`
done
.
.
.

dev="/dev/ulip"
echo "$tool : creating ULIP entries $dev <0-$MAX_ULIPS>"

N=0
while [ $N -le $MAX_ULIPS ]; do
    rm -f $dev$N
    /usr/etc/mknod $dev$N c $CMAJOR $N
    chmod 666 $dev$N
    N=`expr $N + 1`
done

.
.
.

-- 
Ted Morris
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884

From ensslin@dreisoft.de  Fri Jan 17 02:03:55 1997
From: Friedrich Ensslin <ensslin@dreisoft.de>
Date: Fri Jan 17 02:03:58 PST 1997
Subject: AW: Writing a serial driver
Exploder[SMTP:vxwexplo@lbl.gov] wrote:
> Submitted-by gilibert@scn.de  Thu Jan 16 00:21:30 1997
> Submitted-by: Giuseppe Giliberto <gilibert@sbs.de>
> =20
> I have successfully ported a BSP to a 68XXX board but I must face=20
> a trickier problem now, that's writing a serial driver with the=20
> following characteristics: it has to be used by TCP/IP in the upper
> layers while talking with a HDLC protocol over the line. I'm afraid I
> haven't got a clue about how to start...
> I've been reading the relevant documentation  but it does
> not seem to be very clear. What can I do? Is there anybody willing
> to help me crack this?
> Thanks in advance
>=20
> Claudio Nardi
>=20

Hi Claudio,

maybe, a look at the freely available PPP-sources for VxWorks will help =
you. PPP itself uses HDLC-like framing and it is used by the VxWorks =
TCP/IP stack. You can find the sources at =
ftp://ftp.netcom.com/pub/da/dab.

Hope this helps,

------------------------------------------------
  Friedrich Ensslin
  3SOFT GmbH
  Wetterkreuz 19a , D-91058 Erlangen , Germany
  phone: +49 9131 7701-0 , fax: +49 9131 7701-80
  email: ensslin@dreisoft.de =20

From tmorris@me.umn.edu  Fri Jan 17 12:30:30 1997
From: Ted Morris <tmorris@me.umn.edu>
Date: Fri Jan 17 12:30:32 PST 1997
Subject: VxSIM 5.1 on 2 hosts

RE: previous post.

I figured out a fix that seems to work fine.  I set the sub-net parameter
to 127.0.2 in installUlip for the second host.  If this is not recommended,
or is known to cause problems for inet communication routed to another
VxSIM target at the default sub-net, 127.0.1, please let me (us) know.

thanks again,
Ted

-- 
Ted Morris
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884

From rheald@aoc.nrao.edu  Sat Jan 18 17:23:49 1997
From: Ron Heald <rheald@aoc.nrao.edu>
Date: Sat Jan 18 17:23:51 PST 1997
Subject: Transferring data to host
We have the requirement to constantly transfer data from the vxWorks
target to the host.  It is not a particularly large data set and it
does not have to shipped particularly fast (1-4 Mb per day).  The big
requirement is nothing can be lost over reboot of both target and
host, as well as brief (hours) network outages.

We've come up with a solution involving multiple tasks, ring buffers,
and writing the local disk on the target.  It uses a socket connection
and some special code to process acknowledgements.  A daemon on the
host reads the data and sents acknowledgements.  The result is not very
good as some data is lost almost daily.

I'm wondering if anyone out there has faced a similar problem and the
solution you used?  This problem seems mundane enough that there'd be
a utility/package available?  Ideas welcome.  Thanks.

Ron Heald
National Radio Astronomy Observatory
rheald@nrao.edu

From daemon@csg.lbl.gov  Sun Jan 19 04:00:17 1997
From: daemon@csg.lbl.gov
Date: Sun Jan 19 04:00:19 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 19 04:00:15 PST 1997

        Subject: Who has experiences with C++ and VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Who has experiences with C++ and VxWorks
Date: Sun, 19 Jan 1997 07:32:11 GMT
From: q3931234@bonsai.fernuni-hagen.de
Organization: FernUni Hagen
Message-ID: <5bsiob$j0d@ilex.FernUni-Hagen.de>

At the moment I'm using VxWorks with C for a 68040 board. I like to
develop with C++. Are there any problems with C++?

Thanks in advance

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

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

From wbrown@csg.lbl.gov  Tue Jan 21 09:49:20 1997
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Tue Jan 21 09:49:23 PST 1997
Subject: Exploder problems

Our server, or DNS, or some other vital link in the exploders' workin's
caught the epizootic sometime Sunday.  Incomming mail has gone into the
complex plain and may or may not ever get back.

Even as I write this (and I'm not even sure that this will even get out
of LBL!) our network guru(s) is(are) trying to fix the problem.

Sorry for the inconvenience; hopefully things will get back to normal soon.

Disclaimer:  Any opinions are my own and have	    |  -bill
    nothing to do with the official policy or the   |   wlbrown@lbl.gov
    management of L.B.N.L, who probably couldn't    |   Berkeley, CA
    care less about employees who play with trains. |   "Keeper of the List"
							

From davida@laplace.idec.sdl.usu.edu  Tue Jan 21 09:52:53 1997
From: davida@laplace.idec.sdl.usu.edu (David Anderson)
Date: Tue Jan 21 09:52:59 PST 1997
Subject: SGI host support
I heard a rumor that Wind River was no longer going to support SGI host. Meaning 
no upcoming GNU or Tornado support for IRIX 6.X or higher. Has anyone else heard 
this?

From daemon@csg.lbl.gov  Tue Jan 21 10:08:39 1997
From: daemon@csg.lbl.gov
Date: Tue Jan 21 10:08:41 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 21 06:49:34 PST 1997

        Subject: fcntl

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

Newsgroups: comp.os.vxworks
Subject: fcntl
Date: Tue, 21 Jan 1997 09:42:28 -0200
From: Conrad Vermeulen <conrad@ccii.co.za>
Organization: CCII Systems (Pty) Ltd
Message-ID: <32E4ABA4.27C1@ccii.co.za>

Hi

I was wondering how I would go about calling fcntl calls under
vxWorks. I noticed that there are a few header files (fcntl.h,
fcntlom.h) which contain many of the constants used, but the fcntl
function itself is not defined for my target. I need to
use the F_SETFL, and F_GETFL fcntl commands. I saw that in ioLib.h
FIOGETFL was defined for ioctl, but I need a replacement for
F_SETFL. 

I would appreciate it if anyone could help.

Thanks
Conrad

Conrad Vermeulen                     conrad@ccii.co.za
CCII Systems (Pty) Ltd

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

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

From has@info.kobelco.co.jp  Tue Jan 21 10:33:50 1997
From: has@info.kobelco.co.jp (Hasegawa Shigeo)
Date: Tue Jan 21 10:33:51 PST 1997
Subject: Dial Up PPP
Hi,

Does anyone have program to execute Auto Dial-Up PPP on VxWorks/Tornado?
I'd like to know if it is possible or not to modify from PPP released from WRS.

Best Regards,

----------------------------------------
Shigeo Hasegawa
*Electronics & Information Division
*Kobe Steel, Ltd.
TEL: 81-78-261-6461
FAX: 81-78-261-6499
E-mail: has@info.kobelco.co.jp
URL: http://www.kobelco.co.jp/infosys/
----------------------------------------

From cjones@DIGSYS1.md.essd.northgrum.com  Tue Jan 21 10:42:50 1997
From: "CHRIS JONES" <cjones@DIGSYS1.md.essd.northgrum.com>
Date: Tue Jan 21 10:42:53 PST 1997
Subject: Debugger Does Not Work Properly
Problem:

I cannot get the debugger to locate the source code and set 
breakpoints properly. The following message appears when I try to set
a breakpoint.

"Unable to set breakpoint. The associated object file may not contain
debugging information or may not be loaded on the target"

I have the source paths entered correctly in the 
Debug->SourceSearchPath dialog.

I have loaded the object file to the target.

I have compiled the code with the -g option.

Any ideas on a cause and solution?

I have run the debugger sucessfully in the past. 
This problem arose recently for no apparent reason.

Thank You,

Chris Jones
cjones@digsys1.md.essd.northgrum.com

(410) 765-2404
(410) 993-8822 FAX

Northrop Grumman
Electronic Sensors & Systems Division

From bdupre@world-net.worldnet.net  Tue Jan 21 10:43:00 1997
From: bdupre@world-net.worldnet.net (Bernard DUPRE)
Date: Tue Jan 21 10:43:08 PST 1997
Subject: unsubscribe
unsubscribe
 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
< Real Time Skills Center                           >
< 10, Avenue du Quebec - BP 537                     >
< 91946 - Courtaboeuf Cedex - France                >
< Tel: 01 69 82 93 32      Fax: 01 69 82 93 28      >          
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

From daemon@csg.lbl.gov  Tue Jan 21 10:43:59 1997
From: daemon@csg.lbl.gov
Date: Tue Jan 21 10:44:02 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 20 04:00:12 PST 1997

        Subject: VxMemProbe: How does it work ?
        Subject: Re: VxMemProbe: How does it work ?

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

Newsgroups: comp.os.vxworks
Subject: VxMemProbe: How does it work ?
Date: Mon, 20 Jan 1997 01:59:13 GMT
From: dheitz@magicnet.net
Organization: MagicNet, Inc.
Message-ID: <32e2d0f6.2384245@news>

I am writing an application that uses bcopy to move data across VME.
How do I trap bus errors ?   This is done in VxMemProbe, but what is
the technique ?   Or should I use VxMemProbe instead of bcopy ?

Dan Heitz

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

Newsgroups: comp.os.vxworks
Subject: Re: VxMemProbe: How does it work ?
Date: 20 Jan 1997 11:31:49 GMT
From: kadionik@aramis (Patrice KADIONIK (IXL - CNRS URA 846 - FRANCE))
Organization: CRIBX1 , Universite de Bordeaux I , France
Message-ID: <5bvl35$2p2@news.u-bordeaux.fr>
References: <32e2d0f6.2384245@news>

dheitz@magicnet.net wrote:
: I am writing an application that uses bcopy to move data across VME.
: How do I trap bus errors ?   This is done in VxMemProbe, but what is
: the technique ?   Or should I use VxMemProbe instead of bcopy ?

: Dan Heitz

Hi Dan;
VxMemProbe() permits to access to all VME Accesses by software :
Short IO A16.
Standard access A24.
Extended access A32.
Remember That you must driver address lines and AM code lines at the same
time in order to to a VME access.
VxMemProbe() does it for you.
If you use a pointer variable, you just do one of these 3 VME mapping according
to the programmation of the VME chip on your board (done by the BSP).

Another advantage of VxMemProbe() routine is that the VME bus error on timeout
in automaticaly treated. (your board doesn't crash by default). You have just
to test the return code of the routine to know if the VME access was correctly
treated.
bcopy() permits a copy of a block of memory but you can't choose the VME mapping (by default this programmed at the boot sequence) and I don't believe that 
the VME bus error on timeout is treated by this routine : do a test to verify it.
The choice between these two routines depends on your VME hardware configuration.
If the VME mapping is fixed : all transfert in A32 and the A32 mapping is
allowed by all VME chip of your board, use bcopy() (homogen environment).

If you must do a particular VME access (heterogenous environment) or if you
want to do an access but you don't know if you have a VME slave, use
VxMemProbe().

May this help you

cheers;

- --
Pat.
- -----------

                                \^ ^/
                                )@ @(
                  +---------oOO--(_)-------------+
                  |      Patrice Kadionik        |
                  |  kadionik@ixl.u-bordeaux.fr  |
                  +-----------------Oooo--oOO----+
                              oooO (   )
                             (   )  ) /
                              \ (  (_/
                               \_)

=========================================================================
| "Tout doit etre aussi simple que possible, pas seulement plus simple" |
=========================================================================
| Patrice Kadionik                                                      |
|    IXL                           Fax   : +33 5.56.37.15.45            |
| Laboratory of Microelectronics   Voice : +33 5.56.84.65.40            |
| 351, Cours de la liberation      http  : http://www.ixl.u-bordeaux.fr |
| 33405 TALENCE cedex              mail  : kadionik@ixl.u-bordeaux.fr   |
| FRANCE                                                                |
=========================================================================

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

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

From burt@xylan.com  Tue Jan 21 10:48:30 1997
From: burt@xylan.com (Burt Cyr)
Date: Tue Jan 21 10:48:33 PST 1997
Subject: Re:  Transferring data to host
Hi Ron,

you wrote...

>Submitted-by rheald@aoc.nrao.edu  Sat Jan 18 17:23:49 1997
>Submitted-by: Ron Heald <rheald@aoc.nrao.edu>
>
>We have the requirement to constantly transfer data from the vxWorks
>target to the host.  It is not a particularly large data set and it
>does not have to shipped particularly fast (1-4 Mb per day).  The big
>requirement is nothing can be lost over reboot of both target and
>host, as well as brief (hours) network outages.
>
>We've come up with a solution involving multiple tasks, ring buffers,
>and writing the local disk on the target.  It uses a socket connection
>and some special code to process acknowledgements.  A daemon on the
>host reads the data and sents acknowledgements.  The result is not very
>good as some data is lost almost daily.
>
>I'm wondering if anyone out there has faced a similar problem and the
>solution you used?  This problem seems mundane enough that there'd be
>a utility/package available?  Ideas welcome.  Thanks.
>

If I understand your problem correctly, a simple TCP session with
KEEPALIVE is not a practical solution oweing to potentially long
periods of network outage which will time out the sessions. 

In your store and forward scenario, have you considered using any of 
the public domain mail packages? Eg Bekeley's uucp or smtp? Linux?
It seems that they might be of some help since the basic models of
your app and theirs appear similar.

If nothing else, they might provide some strawmen ideas. There are
Nutshell books available for them as well.

HTH.

Burt
==================================================================
    v  _                                 Xylan, Inc.
  ____(_)___    Burt Cyr                 26679 Agoura Rd. Suite 100
  _-_-__-_-_-_    burt@xylan.com         Calabasas, CA 91302
  --_-_--_-_-                            (818) 878-4533
==================================================================

From jhillman@wrs.com  Tue Jan 21 12:56:07 1997
From: Jon Hillman <jhillman@wrs.com>
Date: Tue Jan 21 12:56:09 PST 1997
Subject: Re: Dial Up PPP
At 10:33 AM 1/21/97 PST, Shigeo Hasegawa wrote:
>
>Does anyone have program to execute Auto Dial-Up PPP on VxWorks/Tornado?
>I'd like to know if it is possible or not to modify from PPP released from
WRS.
>

Shigeo,   I think using PPP connect/disconnect hooks will do what you want;
they
are application routines which are called when pppInit is called.  The
connect hook
for example would be called on initialization before the ppp protocol is
established,
thus allowing you to open the appropriate serial line, dial the modem, and
recognize
the connection.  Your routine would then return SUCCESS, enabling ppp to
establish; or
return ERROR, causing your disconnect hook to be called.

        _________________________
       | Jon Hillman, FAE        |       
       | Wind River Systems      |       
      /) (407) 273-4646          (\      
     / ) Email:jhillman@wrs.com  ( \    
   _( (|_________________________) )  />  
  (((\ \)  /,)             / )  / //))/  
  (\\\\ \_/ /              \ \_/ /////    
   \       /                \       /      
    \    _/                  \_    /          
----/   /----------------------\   \----
   /   /                        \   \

From Phil_Watson@ns1.masirv.com  Tue Jan 21 14:08:54 1997
From: Phil_Watson@ns1.masirv.com (Phil Watson)
Date: Tue Jan 21 14:09:04 PST 1997
Subject: Re: Debugger Does Not Work Properly
I sometimes had similar problems. I found it best if I loaded using
the debugger itself (i.e., attach to target, load object). Then in its
status window it printed whether or not it found symbols in the loaded
object. This status should be printed as well when you connect to the
target and it scans the currently loaded objects.

Pre-Tornado, the file in the bootline was also used to find kernel
symbols. 

Caveat: I have not yet used the CrossWind debugger from Tornado.

   Submitted-by cjones@DIGSYS1.md.essd.northgrum.com  Tue Jan 21 10:42:50 1997
   Submitted-by: "CHRIS JONES" <cjones@DIGSYS1.md.essd.northgrum.com>

   Problem:

   I cannot get the debugger to locate the source code and set 
   breakpoints properly. The following message appears when I try to set
   a breakpoint.

   "Unable to set breakpoint. The associated object file may not contain
   debugging information or may not be loaded on the target"

   I have the source paths entered correctly in the 
   Debug->SourceSearchPath dialog.

   I have loaded the object file to the target.

   I have compiled the code with the -g option.

   Any ideas on a cause and solution?

   I have run the debugger sucessfully in the past. 
   This problem arose recently for no apparent reason.

----
Philip Watson
Phil_Watson@masirv.com
Matsushita Avionics Systems Corporation
15253 Bake Parkway
Irvine, California, 92618  U.S.A.

From sridhar@prc.allied.com  Tue Jan 21 16:55:54 1997
From: sridhar@prc.allied.com (Sridhar Adumusilli)
Date: Tue Jan 21 16:55:56 PST 1997
Subject: intLockMask & actual mask

Does anyone know how the value stored in intLockMask variable
during intLockLevelSet calls, is related to interrupt  priroty
mask bits in status registers? (on 68K proc. family)

Any help appreciated.

Sridhar

From dorlic@gte.net  Tue Jan 21 20:47:12 1997
From: "Dan H. Orlic" <dorlic@gte.net>
Date: Tue Jan 21 20:47:14 PST 1997
Subject: unsubscribe
unsubscribe to switch email destination

From gnh@adv.sbc.sony.co.jp  Wed Jan 22 01:04:46 1997
From: Graham Harvey <gnh@adv.sbc.sony.co.jp>
Date: Wed Jan 22 01:04:48 PST 1997
Subject: Blowing VxWorks Code into EPROM

VxWorks People,

                I worked with OS-9 for many years and blowing the
operating system and code modules into EPROM couldn't have been
simpler. I understand, however, that the same operation is a little
more of a black art under VxWorks.

        Does anyone have any pointers for a pain-free method of
creating an embedded VxWorks system ? 

        Thanks in advance.

        Graham

*****************************************************************
* Graham Harvey                     Jays Close
*                                   Basingstoke
* Principal Engineer                Hampshire
* Advanced Technology Division      England
* Sony B.P.E. Ltd.                  RG22 4SB
* 
* Tel: +44 1256 483792 / 483403     Email: gnh@adv.sbc.sony.co.jp
* Fax: +44 1256 483591 / 811430
*****************************************************************

From froeber@bbn.com  Wed Jan 22 05:02:59 1997
From: Fred Roeber <froeber@bbn.com>
Date: Wed Jan 22 05:03:01 PST 1997
Subject: Re: intLockMask & actual mask
Sridhar Adumusilli wrote:

> Does anyone know how the value stored in intLockMask variable
> during intLockLevelSet calls, is related to interrupt  priroty
> mask bits in status registers? (on 68K proc. family)

The value you set via intLockLevelSet is the value that gets stored
in the priority level field of the status register when the intLock
function is called.  The intLock function is the core function
used in VxWorks to protect critical sections.  Normally the lock
level is set to 7 on 68K so that all interrupts (other than level
7 NMI ones) are masked in critical sections.  If you have a very
critical function you want to handle in response to an interrupt
then you could put it at a high level (e.g. level 6) and set the
lock level to 5 so that VxWorks wouldn't ever block receipt of your
interrupt.  If you do this however then your interrupt handler can't
use any VxWorks routines that affect kernel state (not even things
like semGive that are normally safe to use in interrupt handlers).
Also, I am fairly sure that you can't use intConnect to set up
an interrupt handler that will not be masked by intLock.  There has
only been one time I have needed to use intLockLevelSet and I set
up a custom interrupt handler for the corresponding interrupt. Hope
this helps.   Fred

-- 
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |

From dryder@aplexus.jhuapl.edu  Wed Jan 22 05:58:14 1997
From: Dan Ryder F2C <dryder@player.jhuapl.edu>
Date: Wed Jan 22 05:58:16 PST 1997
Subject: unsubscribe

From tkb@mclean.sparta.com  Wed Jan 22 07:13:54 1997
From: "Thomas K. Buchanan" <tkb@mclean.sparta.com>
Date: Wed Jan 22 07:13:56 PST 1997
Subject: Re: Blowing VxWorks Code into EPROM
>                I worked with OS-9 for many years and blowing the
>operating system and code modules into EPROM couldn't have been
>simpler. I understand, however, that the same operation is a little
>more of a black art under VxWorks.
>
>        Does anyone have any pointers for a pain-free method of
>creating an embedded VxWorks system ? 

If a BSP supports an embedded version of the OS, it's just as simple as OS-9.
Type 'make vxWorks.res_rom.hex', download the file to a programmer and burn
the EPROM.  There are a couple of variations: compressed or not compressed,
with or w/o the application, text segment in ROM or RAM, etc.  Most of the
posts to the explorer concern problems including the application or using
BSPs that were not properly written or tested.  Wind River does include the
basic functionality though and it's as easy to use as OS-9.  Read the
configuration chapter in the Programmer's Guide, check the BSP specific
manual pages and take a peek at the BSP Makefiles.  It's not a black art,
it's pretty straightforward.

adios

From steele@tracer.jpl.nasa.gov  Wed Jan 22 08:46:15 1997
From: Rob Steele <steele@tracer.jpl.nasa.gov>
Date: Wed Jan 22 08:46:17 PST 1997
Subject: mv177 and mv167
I have in one chassis the following CPUs:

	slot 1 MV177 (68060) with 8 meg of memory
	slot 2 MV167 (68040) with 8 meg of memory
	slot 3 MV167 (68040) with 4 meg of memory
	
I want to set of the memory on the 177 so that it is visible from
the other two processors. I have so far not been very successful at
this. Does anyone have any suggestions?

Rob Steele
phone: 818 354 4847
fax:   818 393 5007
e-mail: steele@telerobotics.jpl.nasa.gov

From bhlloyd@polaris.orl.mmc.com  Wed Jan 22 10:09:35 1997
From: Barbara Lloyd <bhlloyd@polaris.orl.mmc.com>
Date: Wed Jan 22 10:09:44 PST 1997
Subject: Subscribe to vxworks exploder

From cjs@cscsgi.larc.nasa.gov  Wed Jan 22 10:14:00 1997
From: "Christopher J. slominski" <cjs@cscsgi.larc.nasa.gov>
Date: Wed Jan 22 10:14:02 PST 1997
Subject: PowerPc 604 lockups
Hello,
	I am a fairly new user of Vxworks.  I have a VME chassis with a
PowerPC 604 processor is slot #0 and a number of I/O boards populating the
chassis.  Other boards include:

	Systran SCRAMNet+
	Condor Engineering ARINC-429
	VMIVME-2128 Discrete output
	VMIVME-1129 Discrete input
	Datum bc635VME Time processor
	VMIVME-3122 Analog-to-Digital

The only card configured to interrupt the PowerPC CPU is the SCRAMNet+.  I
am running Vxworks 5.3.  My application runs continuously servicing the
I/O cards and performing internal calculations.  A Console diagnostic
display is also active, continuously updating the display with status via
the built in serial port.
	The application performs as expected, however occasional lock-ups
occur.  It can run for hours without a problem, however the problem can
reoccur, it appears, at any time.  I have not been able to correlate any
events to match occurence of the error.  When it locks, my console
display will freeze and servicing of the I/O cards stops.  Sometimes the
PowerPC reboots itself.
	I have no experience debugging system/interrupt level problems
with Vxworks and would like some suggestions on how I can proceed with
this problem.  My only debugging experience with Vxworks has included
"printf()" and a VME bus analyzer card (this application fell together
will few problems).  Therefore I am not even familiar with the Tornado
tool set.

   *----------------------------------------*
   |  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                   |
   *----------------------------------------*

From MikeMcQuade@connect.com  Wed Jan 22 12:44:15 1997
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Wed Jan 22 12:44:17 PST 1997
Subject: Re: PowerPc 604 lockups
At 10:14 AM 1/22/97 PST, you wrote:
>Submitted-by cjs@cscsgi.larc.nasa.gov  Wed Jan 22 10:14:00 1997
>Submitted-by: "Christopher J. slominski" <cjs@cscsgi.larc.nasa.gov>
> 

>	The application performs as expected, however occasional lock-ups
>occur.  It can run for hours without a problem, however the problem can
>reoccur, it appears, at any time.  I have not been able to correlate any
>events to match occurence of the error.  When it locks, my console
>display will freeze and servicing of the I/O cards stops.  Sometimes the
>PowerPC reboots itself.

I had a similar problem on a 1604 board, WRS has a patch on their WEB site.

I don't remember the #, but their Web site has some text explaining lockups 
on 604 under haevy interrupt loads.

Get this patch.

MikeMcQuade@connect.com

From sridhar@prc.allied.com  Wed Jan 22 13:07:52 1997
From: sridhar@prc.allied.com (Sridhar Adumusilli)
Date: Wed Jan 22 13:07:54 PST 1997
Subject: Re: intLockMask & actual mask
> From root@csg.lbl.gov Wed Jan 22 09:24 CST 1997
> Date: Wed, 22 Jan 97 05:03:03 PST
> To: vxworks_users@csg.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: Re: intLockMask & actual mask
> 
> Submitted-by froeber@bbn.com  Wed Jan 22 05:02:59 1997
> Submitted-by: Fred Roeber <froeber@bbn.com>
>  
> Sridhar Adumusilli wrote:
> 
> > Does anyone know how the value stored in intLockMask variable
> > during intLockLevelSet calls, is related to interrupt  priroty
> > mask bits in status registers? (on 68K proc. family)
> 
> The value you set via intLockLevelSet is the value that gets stored
> in the priority level field of the status register when the intLock
> function is called.  The intLock function is the core function
> used in VxWorks to protect critical sections.  Normally the lock
> level is set to 7 on 68K so that all interrupts (other than level
> 7 NMI ones) are masked in critical sections.  If you have a very
> critical function you want to handle in response to an interrupt
> then you could put it at a high level (e.g. level 6) and set the
> lock level to 5 so that VxWorks wouldn't ever block receipt of your
> interrupt.  If you do this however then your interrupt handler can't
> use any VxWorks routines that affect kernel state (not even things
> like semGive that are normally safe to use in interrupt handlers).
> Also, I am fairly sure that you can't use intConnect to set up
> an interrupt handler that will not be masked by intLock.  There has
> only been one time I have needed to use intLockLevelSet and I set
> up a custom interrupt handler for the corresponding interrupt. Hope
> this helps.   Fred
> 
> -- 
>    |     Fred J Roeber,  BBN Systems & Technologies     |
>    |   4 John Clarke Road   Middletown, RI  02842-5202  |
>    |         froeber@bbn.com     401-848-3548           |
> 

Thanks Fred.  Looking at the value returned from intLockLevelGet(),
I thought that was the reason why I am not getting interrupts.
Value in SR indicated no mask.  I wasn't sure whats happening,
until I foundout about intLock().  As it turns out, the reason for
not getting interrupts is misconfiguration of the microcontroller
IO ports. (Interrupt Line was config. as discrete IO line).

Thanks again.

Sridhar

From fbh@vlsi9.gsfc.nasa.gov  Wed Jan 22 13:32:01 1997
From: Francis Hallahan <Francis.Hallahan@gsfc.nasa.gov>
Date: Wed Jan 22 13:32:03 PST 1997
Subject: Re: mv177 and mv167 (Slave Addressing)
--============_-1358153785==_============
Content-Type: text/plain; charset="us-ascii"

>Submitted-by steele@tracer.jpl.nasa.gov  Wed Jan 22 08:46:15 1997
>
>I have in one chassis the following CPUs:
>
>	slot 1 MV177 (68060) with 8 meg of memory
>	slot 2 MV167 (68040) with 8 meg of memory
>	slot 3 MV167 (68040) with 4 meg of memory
>
>I want to set of the memory on the 177 so that it is visible from
>the other two processors. I have so far not been very successful at
>this. Does anyone have any suggestions?
>
>Rob Steele
>.....

I use the following routine in a number of MV167s.  Since the
MV177 is very similar to the MV167, I tested the object on the
MV177 and it seems to work fine (caveat emptor --> user beware :-)
This routine is based on sysProcNumSet() in syslib.c in the MV167 BSP,
but modified almost beyond recognition.

To use:

On Workstation
    -  place dram.c in your mv167 and/or mv177 directory.
    make -f Makefile.MC68040  dram.o

On Target

    ld <dram.o
    dramSetAdrs  0xVVV00000

The code has 2 functions, dramSet() and dramSetAdrs(unsigned int adrs).
dramSet() determines the slave address based on processor number, and
predefined constants(#defines).  For almost all applications, we use
dramSetAdrs() because we can set the address explicitly.

I hope this helps,
Frank Hallahan

--============_-1358153785==_============
Content-Type: text/plain; name="dram.c"; charset="us-ascii"
Content-Disposition: attachment; filename="dram.c"

/* dram.c - assign MV167  DRAM by processor number */

/* sysLib.c - Motorola MVME167 system-dependent library */

/* Copyright 1996 F. Hallahan (Computer Sciences Corp.) for
                  NASA/Goddard Space Flight Center, Code 521. */
/* Copyright 1984-1993 Wind River Systems, Inc. */

/*
modification history
--------------------
fbh 8/7/94
02d,27feb93,ccc  added check for valid NV_CPU_SPEED, use 25MHz if not valid.
01a,20jun91,ccc  created by modifying version 01m of mv147/sysLib.c.
*/

/*
DESCRIPTION
This library provides board-specific routines.  The chip drivers included are:
    pcc2Timer.c - PCC2 Timer library
    pcc2Vme.c - Peripheral Channel Controller 2 (PCC2) library
    nvRam.c - non-volatile RAM library

INCLUDE FILES: sysLib.h

SEE ALSO:
.pG "Configuration"
*/

#include "vxWorks.h"
#if	FALSE
#include "vme.h"
#include "memLib.h"
#include "cacheLib.h"
#include "sysLib.h"
#include "config.h"
#include "string.h"
#include "intLib.h"
#include "logLib.h"
#include "taskLib.h"
#include "vxLib.h"
#include "tyLib.h"
#include "private/vmLibP.h"
#endif
#include "config.h"

/* Globals */

void dramSetAdrs    (    unsigned int adrs    );
void dramSet    (    void    );
int sysProcNumGet (void);

/******************************************************************************
*
* dramSet - set the processor number
*
* This routine sets the processor number for the CPU board.  Processor numbers
* should be unique on a single backplane.
*
* NOTE
* This routine enables access from the VMEbus to the MVME167's local
* memory only for processor 0.  (VxWorks only requires mapping for
* processor 0, and then only for backplane networks.)  If the processor
* number is not 0, but the user wants to allow VMEbus access to local memory,
* change the "if (procNum == 0)" condition below.
*
* This routine also sets the VMEchip GCSR address based on processor
* number.  This address can be specified anywhere from 0x00 to 0xe0 in
* increments of 0x10 in the short I/O space.  This can allow up to 15 CPUs
* in the same cage to form a backplane network using signal interrupts to
* coordinate their activities.
*
* RETURNS: N/A
*
* SEE ALSO: sysProcNumSet(), sysProcNumGet()
*/

#define  DRAM_BASE    0X6000000
#define  DRAM_SIZE    0X2000000

void dramSet
    (
    void
    )
{
    unsigned int dramAdrs;

	dramAdrs = DRAM_BASE + DRAM_SIZE * sysProcNumGet();

    dramSetAdrs( dramAdrs );

}

void dramSetAdrs
    (
    unsigned int adrs		/* processor number */
    )
{
    unsigned int dramAdrs;
    unsigned int memsize;

	memsize = (4 << (*MEMC_MCR & 0x07));

    /* Set memory base address, as seen from VME bus */

	dramAdrs = adrs & 0xffff0000;

	*VMECHIP2_VSAR1   = (((memsize << 4) - 1) << 16)	|
		dramAdrs |
		((dramAdrs >> 16) & 0x0000ffff);
			     /* map all DRAM to VMEbus access */

	*VMECHIP2_VSATR1  = ((dramAdrs >> 16) & 0x0000ffff);

	*VMECHIP2_VSAMSR |= (VSAMSR1_SNP_WSD 	|
			     VSAMSR1_WP		|
			     VSAMSR1_SUP	|
			     VSAMSR1_USR	|
			     VSAMSR1_A32	|
			     VSAMSR1_D64	|
			     VSAMSR1_BLK	|
			     VSAMSR1_PGM	|
			     VSAMSR1_DAT);	/* all but A24 */

}

--============_-1358153785==_============
Content-Type: text/plain; charset="us-ascii"

---------------------------------------------------------------------------
| Frank Hallahan                            |  Hallahan@gsfc.nasa.gov     |
|   Software Environment Leader - Code 521  |  fbh@vlsi.gsfc.nasa.gov     |
| Computer Sciences Corporation             |                             |
| at Nasa Goddard Space Flight Center       |  Phone (301) 286 7064       |
---------------------------------------------------------------------------

--============_-1358153785==_============--

From has@info.kobelco.co.jp  Wed Jan 22 20:59:51 1997
From: has@info.kobelco.co.jp (Hasegawa Shigeo)
Date: Wed Jan 22 20:59:54 PST 1997
Subject: Re: Dial Up PPP
At 0:05 PM 97.1.22, <Jon Hillman> wrote:
> Shigeo,   I think using PPP connect/disconnect hooks will do what you want;
> they are application routines which are called when pppInit is called.  The
> connect hook for example would be called on initialization before the ppp
>protocol is
> established, thus allowing you to open the appropriate serial line, dial
>the modem, and
> recognize the connection.  Your routine would then return SUCCESS,
>enabling ppp to
> establish; or return ERROR, causing your disconnect hook to be called.
Thank you for your comment.

It is too short for me to explaine my needs.

Is it possible to execute On-Demand Dial-up PPP with PPP of WRS?
We would like to dial-up when IP layer request to send Packet.

Regards,

----------------------------------------
Shigeo Hasegawa
*Electronics & Information Division
*Kobe Steel, Ltd.
TEL: 81-78-261-6461
FAX: 81-78-261-6499
E-mail: has@info.kobelco.co.jp
URL: http://www.kobelco.co.jp/infosys/
----------------------------------------

From eweikkl@rb.memo.bosch.de  Thu Jan 23 00:43:02 1997
From: eweikkl@rb.memo.bosch.de
Date: Thu Jan 23 00:43:04 PST 1997
Subject: RE: Debugger
From:	FUNC: AT/ESE2
	NAME: KLEPSCH, DR., THORSTEN
	TEL: 07192/22-254
	ADDR: MT 118/0 <RB.EWEIKKL@MEMOVMS@SI0104>
To:	"VXWEXPLO@LBL.GOV"@SMTP

--- Erhalten von  RB.ATESE2KL  07192/22-254         23-01-97 09.09
  -> GMVFESI."""VXWEXPLO..LBL.GOV""".SMTP
  -: - - - - - - - - - - > .

The CrossWind debugger of Tornado (Win95) has some problems, if
the name of the object-file is different form the source-file name
(uppercase /  lowercase letters) ! This differences in the names
are caused by the compiler. For example the compiler generates
from the sourcefile "TestFile.c" an objectfile with the
name "testFile.o".

Thorsten Klepsch

=================================================================
ROBERT BOSCH GMBH                Phone        : +49 (0)7192 22
Dr.-Ing. Th. Klepsch             Fax          : +49 (0)7192 22
AT/ESE2                          Email :
ATESE2KL&RB.MEMO.BOSCH.DEAutomation Division I
Development Tightening                           I-> Please re-
  and Press-Fit Systems                              place the
                                                     '&' by the
Fornsbacherstrasse 92                                Atsign !
D-71540 Murrhardt

Germany

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

From daemon@csg.lbl.gov  Thu Jan 23 04:00:14 1997
From: daemon@csg.lbl.gov
Date: Thu Jan 23 04:00:16 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 23 04:00:12 PST 1997

        Subject: VxWorks/C++ users
        Subject: VxWorks/C++ users
        Subject: Problem with gcc 2.7.2.1. Cross compiler host HP UX 9.07 target VXWORKS

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

Newsgroups: comp.os.vxworks
Subject: VxWorks/C++ users
Date: Sat, 18 Jan 1997 01:48:50 GMT
From: njt@worlds-edge.u-net.com (Neil Turner)
Organization: U-NET Ltd
Message-ID: <5bpa1i$a65$3@despair.u-net.net>
Reply-To: njt@worlds-edge.u-net.com

If anyone is using the VxWorks RTOS (C++ libraries) with C++?
What development methods and tools are you using?, e.g OMT, Tornado
etc. Has anyone delivered and os anyone supporting products inthe
field developed using Tornado?

Although I have read a considerable amount about combining objects and
concurrent processes(language extensions, new languages, use of
libraries or classes that support concurrency issues), I have little
idea how to design for real-time using objects based on the use of a
library such as VxWorks.  My experience is based on the use of OCCAM.
Does anyone know of any useful articles(preferably available on the
net) that  I can refer to, to get started?

The one useful book I do have is:

Title:        Object-Oriented Technology for Real-Time Systems
               - A Practical Approach Using OMT and Fusion(1996)
Authors :  Maher Awad, Juha Kuusela, Jurgen Ziegler
Publisher: Prentice-Hall
ISBN:       0-13-227943-6

Price UK Sterling36-95(It's hardback - 276 pages)

Its written by engineers, is very applied and technically 
detailed(particularly about parallel processing) and contains a 
couple of farly well documented case studies.  Some C++ code is
included in the book to show you what the implemenation looks like but
the book isn't littered with unneccessary code listings.

BTW Bill McCombie of:

>ENEA OSE SYSTEMS AB		E-mail: bill@enea.se
>Box 232				WWW   : http://www.enea.se/ose
>S-183 23 TABY			Phone : +46-8-638-5000
>Sweden				Fax   : +46-8-638-5050

tells me that the case studies in the book were implemented with the
OSE RTOS from Enea OSE Systems.

Thanks in advance...

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

Newsgroups: comp.os.vxworks
Subject: VxWorks/C++ users
Date: Sat, 18 Jan 1997 01:48:47 GMT
From: njt@worlds-edge.u-net.com (Neil Turner)
Organization: U-NET Ltd
Message-ID: <5bpa1f$a65$1@despair.u-net.net>
Reply-To: njt@worlds-edge.u-net.com

If anyone is using the VxWorks RTOS (C++ libraries) with C++?
What development methods and tools are you using?, e.g OMT, Tornado
etc. Has anyone delivered and is anyone supporting products in the
field developed using Tornado?

Although I've read much about combining objects and C++ I have little
idea how to design for real-time using objects with an off-the shelf
library.  My real-time experience to date is with OCCAM.  Does
anyone know of any useful articles(preferably available on the .net)
that  I can refer to, to get started?

The one useful book I do have is:

Title:        Object-Oriented Technology for Real-Time Systems
               - A Practical Approach Using OMT and Fusion(1996)
Authors :  Maher Awad, Juha Kuusela, Jurgen Ziegler
Publisher: Prentice-Hall
ISBN:       0-13-227943-6

Price UK Sterling36-95(It's hardback - 276 pages)

Its written by engineers, is very applied and technically 
detailed(particularly about parallel processing) and contains a 
couple of farly well documented case studies.  Some C++ code is
included in the book to show you what the implemenation looks like but
the book isn't littered with unneccessary code listings.

BTW Bill McCombie of: 

> ENEA OSE SYSTEMS AB		E-mail: bill@enea.se 
> Box 232				WWW   : http://www.enea.se/ose
> S-183 23 TABY			Phone : +46-8-638-5000
> Sweden				Fax   : +46-8-638-5050 

tells me that the case studies in the book were implemented with the
OSE RTOS from Enea OSE Systems.

Thanks for any help or information in advance...

Neil

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

Newsgroups: gnu.gcc.help,comp.os.vxworks,gnu.g++.help
Subject: Problem with gcc 2.7.2.1. Cross compiler host HP UX 9.07 target VXWORKS
Date: Sat, 18 Jan 1997 00:22:32 -0700
From: Aseem Bakshi <baksh@ix.netcom.com>
Organization: Netcom
Message-ID: <32E07A37.46D8@ix.netcom.com>

i 

I am trying to create a cross compiler. 
I have successfully created and installed on my HP
a gcc for compiling on the HP version 2.7.2.1
installed in /usr/local

I have also generated the bin_utils package with
../configure --target=m68k-vxworks
- --prefix=/tmp_mnt/home/fas1/pedersen/gnu/local 

I installed them in the prefix directory

For the cross compiler gcc I used
../configure --target=m68k-vxworks
- --prefix=/tmp_mnt/home/fas1/pedersen/gnu/local --with-gn
u-as --with-gnu-ld

Now I tried to generate gcc, starting with  a make from the
toplevel . (This worked for th HP gcc)
The compile fails with the following error :
        cd objc; \
        make -f ${srcdir1}/objc/Makefile libobjc.a \
          srcdir=${srcdir1}
tooldir=/tmp_mnt/home/fas1/pedersen/gnu/local/m68k-vxworks
AR="/tmp_mnt/home/fas1/pedersen/gnu/local/m68k-vxworks/bin/ar"
AR_FLAGS="rc" \
          GCC_FOR_TARGET="${thisdir1}/xgcc -B${thisdir1}/" \
          GCC_CFLAGS="-DCROSS_COMPILE -DIN_GCC   -g -I./include"
        /tmp_mnt/home/fas1/pedersen/gnu/gcc-2.7.2.1/xgcc
- -B/tmp_mnt/home/fas1/pedersen/gnu/gcc-2.7.2.1/ -O \
                -c -DCROSS_COMPILE -DIN_GCC   -g -I./include -I. -I..
- -I/tmp_mnt/home/fas1/pedersen/gnu/gcc-2.7.2.1
- -I/tmp_mnt/home/fas1/pedersen/gnu/gcc-2.7.2.1/config hash.c
In file included from hash.c:32:
runtime.h:31: stdio.h: No such file or directory
runtime.h:32: ctype.h: No such file or directory
In file included from runtime.h:38,
                 from hash.c:32:
.../objc/objc-api.h:32: stdio.h: No such file or directory
*** Error code 1

I changed the Makefile for objc to include:
1. /usr/vxworks/h Didnt work cos there was a clash between OldTypesxxx.h
and objc.h for BOOL
2. tried /usr/include didnt work
3. tried to use the include area of the HP gnu compile area that 
had a stdio.h. Didnt work cos it wanted stdtypes.h

Any help, comments suggestions would be welcom. Iam out of ideas....
Thanks in avance
Aseem Bakshi

P.S. I read in the gcc install manual that you are supposed to make
the first stage compiler first and then build the final compiler.
Build first stage by cd cp
make LANGUAGES=c

I never got that to work. Both for gcc on the HP that appears to work
(I succeeded by running the overall make) Nor for the cross compiler.
Both die in the same place looking for insn-xxxx.h where xxxx is the
rest of the filename that I dont remember. Is the install different or
am
I doing something wrong?????

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

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

From esi-dallas!DORLIC@re-ro.com  Thu Jan 23 07:14:24 1997
From: "ORLIC, DAN" <esi-dallas!DORLIC@re-ro.com>
Date: Thu Jan 23 07:14:27 PST 1997
Subject: subscribe

From egbert@ra.timeplex.com  Thu Jan 23 08:11:06 1997
From: egbert@ra.timeplex.com (Stephen L. Egbert)
Date: Thu Jan 23 08:11:08 PST 1997
Subject: Re: Dial Up PPP
Shigeo,

The ppp 2.1.2 has been ported to VxWorks and resides on ftp.netcom.com:/pub/da/dab.

To incorporate dial up capability into the ppp 2.1.2, one may take the dp-4.0 and "merge" into the ppp 2.1.2.

I believe the integration effort should be relatively simple.

Regards,

Steve

From MikeMcQuade@connect.com  Thu Jan 23 11:01:12 1997
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu Jan 23 11:01:14 PST 1997
Subject: Radstone PowerPC VME boards  ?

Does anyone have any experience with Radstone's PowerPC VME boards, that
they would be willing to share ?

Are you running Tornado with these boards ?

How do you like the boards ? How is the support ? How is the BSP ?

Thanks in advance.

MikeMcQuade@connect.com

From dkocinsk@mail04.mitre.org  Thu Jan 23 12:55:10 1997
From: dkocinsk@mail04.mitre.org (David L. Kocinski)
Date: Thu Jan 23 12:55:13 PST 1997
Subject: GateD
Does anyone have any experience porting GateD to VxWorks.  

David Kocinski          dkocinsk@mitre.org

From rstelzer%ims.fhg.de%sonja.ims.fhg.de@ims.fhg.de  Thu Jan 23 22:31:28 1997
From: Rainer Stelzer <rstelzer@ims.fhg.de>
Date: Thu Jan 23 22:31:30 PST 1997
Subject: building control / WindView Problem
Hi there !

Because the WindView tool on Win NT-platform is not 
supported (it is in beta-state) a question to all the 
guy's out there :

the background:
We are developing a development tool for distributed 
applications in hetorogenous systems based on VxWorks. 
(This job is embedded in a project for home automation
 and building control systems (IHS-ReWo)). 
Heart of the system is a very compact modular network 
node based on the mc68332 CPU with PCMCIA-Ethernet 
Interface for debugging, development and performance 
metering.  In it's modular structure it is extendable 
with interface-cards for communication networks like
ISDN,LON,EIB,CAN,PROFIBUS,IrDA and others. Applications 
for this system are: rapid prototyping of applications 
with gateway-functionality between devices with 
propriety communication interfaces and standard 
communication systems, 

the problem:
The porting of VxWorks was done by ourself, so that I
also had to wrote the necessary TIMESTAMP DRIVER for 
our computer. (The free running counter was implemented by 
programming the TPU). The first data acquisition starts fine,
but unfortunality it doesn't continues running. In my mind the
structure of the TIMESTAMP DRIVER is quite simple so I can't 
believe that I have made any mistake ;-)))
Is there anybody out there who can change my mind ?

Is it a problem of the beta version of WindView or do I have to 
look at my code again ???

Thank's for any hint !

rainer 

--

**********************************************************************
Fraunhofer Institut f|r Mikroelektronische Schaltungen und Systeme
Abteilung SAT
Rainer Stelzer 
Finkenstra_e 61
47057 Duisburg
Tel.  0203/3783-238 
email rstelzer@ims.fhg.de
**********************************************************************

From ndoye@ocegr.fr  Thu Jan 23 23:47:35 1997
From: Ibrahima Ndoye <ndoye@ocegr.fr>
Date: Thu Jan 23 23:47:37 PST 1997
Subject: VXworks malloc behaviour
Hi,

Does anyone know how malloc operates inside vxWorks i.e when vxWorks
does the garbage collection ?

Regards
Ibrahima

From mcintosh@infinity.ccsi.com  Fri Jan 24 03:24:00 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Fri Jan 24 03:24:02 PST 1997
Subject: SUSCRIBE

From Mailer-Daemon@lbl.gov  Fri Jan 24 03:24:58 1997
From: gmcintos@polaris (Gordon D. McIntosh)
Date: Fri Jan 24 03:24:59 PST 1997
Subject: SUBSCRIBE

From mcintosh@infinity.ccsi.com  Fri Jan 24 03:25:24 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Fri Jan 24 03:25:26 PST 1997
Subject: SUBSCRIBE

From M.Paterson@roe.ac.uk  Fri Jan 24 03:28:50 1997
From: M.Paterson@roe.ac.uk
Date: Fri Jan 24 03:28:52 PST 1997
Subject: Problems with recursive code & logMsg
All,

We're having some problems with logMsg, using VxWorks under EPICS.

In our system we channel all log messages through a central function
which is structured something like this:

   void cicsLogMessage( const long debug, const char* message )
   {
     char histMsg[40];

     if ( debug <= debugLevel )
     {

       if ( databaseLogging == TRUE )
       {
         strncpy( histMsg, message, 40 );

         (Write the string "histMsg" to the 40 character history log record 
         in my database).
       }

       if ( consoleLogging == TRUE )
       {
         logMsg( "%s\n", message );
       }
     }
   }

When we call this function we construct the string using sprintf(). For 
example:

  sprintf( message, "The current value is %ld", longValue );
  cicsLogMessage( debug, message );

The point of having this central logging function is that we can control
where to direct the messages to and which messages to display. However, we
have noticed that if two processes (say A and B) running in parallel try
to issue a message at the same time, we sometimes get two copies of the
process B message and the process A message is lost. The following comes
from the VxWorks manual:

>      Because  logMsg()  does  not  actually  perform  the  output
>      directly to the logging streams, but instead queues the mes-
>      sage to the logging task, logMsg() can be called from inter-
>      rupt service routines.
>  
>      However,  since  the  arguments  are  interpreted   by   the
>      logTask()  at  the time of actual logging, instead of at the
>      moment when logMsg() is called, arguments to logMsg() should
>      not  be pointers to volatile entities (e.g., dynamic strings
>      on the caller stack).

So it seems that our use of a dynamic string "message" is unreliable, but we
cannot think of a way of having a central logging function like the above
without passing a dynamic string to it.

Can anyone think of a way of structuring this central logging function
which doesn't involve giving logMsg() a dynamic string, or is there a
work-around or an alternative to logMsg() which can be used reliably with
a dynamic string?

Cheers,
Magnus

****  Magnus J Paterson           email  mjp@roe.ac.uk   
****  Royal Observatory           ph     +44 (0)131 668 8247
****  Edinburgh EH9 3HJ           fax    +44 (0)131 668 1130
****  SCOTLAND                    web    http://www.roe.ac.uk/mjpwww/ 

From daemon@csg.lbl.gov  Fri Jan 24 04:00:22 1997
From: daemon@csg.lbl.gov
Date: Fri Jan 24 04:00:24 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 24 04:00:19 PST 1997

        Subject: Re: Serial Ports to Ethernet?
        Subject: Re: Compiling and linking
        Subject: medley of questions

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

Newsgroups: comp.os.vxworks
Subject: Re: Serial Ports to Ethernet?
Date: Thu, 23 Jan 1997 18:36:40 -0600
From: "Stephen (Steve) L. Egbert" <egbert@ra.timeplex.com>
Organization: ascom Timplex, Inc.
Message-ID: <32E80418.3F54BC7E@ra.timeplex.com>
References: <32DCFB8C.2811@dspt.com>

Mark Menge wrote:
> 
> Does anyone know of a product that allows you to communicate through
> tcp/ip on thin net to a box that has at least 4 serial ports on it?

Try using PPP on both ends. (ppp-2.3b3).

- -- 

Stephen (Steve) L. Egbert              Work: (214) 340-3300
ascom Timeplex                          Fax: (214) 341-3654
Dallas, Texas 75243-7095                Net: egbert_steve@timeplex.com

	"Try moving off NT easily. You can move from Solaris to HP/UX
	to AIX or DEC easily-- relative to moving off of NT, which is
	like a Roach Motel. Once you check in, you never check out.
	-Scott McNealy, Sun Microsystems, Inc.

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

Newsgroups: comp.os.vxworks
Subject: Re: Compiling and linking
Date: Fri, 24 Jan 1997 06:40:41 GMT
From: wb6w@netcom.com (Glenn Thomas)
Organization: Netcom On-Line Services
Message-ID: <wb6wE4I2Jt.Jt8@netcom.com>
References: <32E5DE76.C20@oce.nl>
Sender: wb6w@netcom15.netcom.com

My newsreader claims that W.M. van den Brink (brin@oce.nl) wrote:
: Hello,

: I'm trying to make one file from mulitple C files. I've made a make file
: which compiles every c file to an o file. Next I try to link all the o
: files to one file with the linker.
: The link instruction responds with a couple of reactions like

: J:\test\finisher\maketest/finpuls.c:153: undefined reference to 'printf'

: How can I let the linker now where it can find these objects ?

What you need to do is have the linker make a single object file rather than
an absolute. The GNU linker being supplied by WRS has a switch for this 
(I thinnk it's -r, but look it up - I might be wrong). 
The linker will build an object
file according to your link command, call it all.o for example, which will
contain all of your object files. You can then load this object file onto
your target vxWorks system via the ld command. vxWorks will resolve all of
the remaining references to things like "printf" and allow you to run on your
target. Note that you still need to include header files line vxWorks.h
and stdio.h from the appropriate vxWorks header directory and NOT for your
normal system default directory.

Hope this helps a bit. - Glenn Thomas
:
: Thanks

: Wilco van den Brink

You're welcome!
- --
*********************************************************************
* "Two wrongs don't make a right, but three lefts do."              *
*                                                                   *
*  wb6w@netcom.com  - Glenn Thomas                                  *
*********************************************************************

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

Newsgroups: comp.os.vxworks
Subject: medley of questions
Date: Fri, 24 Jan 1997 07:53:14 +0100
From: Jean-Luc Fleureau PERS <fleureje@ensieta.fr>
Organization: ensieta
Message-ID: <32E85C5A.1EAE@ensieta.fr>

Hi all,

I work with vxWorks and 68030 on VME board and I have many questions
about it :

I would like to use the graphical debugger on Unix called "vxgdb68k"
but when I run it, it makes nothing and the unix process stops
immediatly. so my question is : is there a special configuration to use
this interface, or more of this, may not have to re-install all my
vxworks software, and in this last case, where can I find information to
do such thing???

Second question, I would like to use the third and fourth serial ports
on my mvme162 board. Must I do a driver for those ports. And in this
case does someone could help me or give me an example.

If you want to see the monster that I'm driving with vxWorks see my
WWW....(sorry only in french, but videos and camera speak any
languages!!!)

oh, last thing could you reply by email.

Thinks in advance.

Best regards.

Jean-Luc FLEUREAU.
****************************************************************
Dpt Electronique Informatique Automatique
Ecole Nationale Superieure des Ingenieurs des Etudes et 
Techniques d'Armement
2 Rue Francois VERNY 29806 BREST cedex 9 FRANCE

Everything you ever wanted to know about me, 
but were afraid to ask ----> http://www.ensieta.fr/~fleureje/

TEL : 02 98 34 88 45 FAX : 02 98 34 87 50
Email : Jean-Luc.Fleureau@ensieta.fr
***************************************************************

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

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

From mcintosh@infinity.ccsi.com  Fri Jan 24 04:33:38 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Fri Jan 24 04:33:40 PST 1997
Subject: VxWorks interfacing to MCOS (Mercury OS)
Has anyone out there got experience in the interface between VxWorks 5.3
and the Mercury MCOS kernel running on PowerPC ?
Thanks
Gordon McIntosh
mcintosh@rtsd.com

From @positron.CTI-PET.COM:wittner%pcmail.cti-pet.com@cti-pet.com  Fri Jan 24 04:49:26 1997
From: wittner%pcmail.cti-pet.com@cti-pet.com
Date: Fri Jan 24 04:49:28 PST 1997
Subject: Request for Socket information
     To all:
     
     We are considering using sockets to transfer information between a 
     target running vxWorks and a PC.  We have established the sockets with 
     Berkeley Sockets/Winsock.  We would appreciate any 
     information/shareware on application protocols.  Questions we have 
     include:  1) 1 socket or multiple sockets?  2) Asynchronous or 
     synchronous communication (i.e. error checking).  3) Maximum througput 
     using the ethernet and potential problems we might encounter with 
     bandwidth.  4) Task priority suggestions.
     
     Thanks in advance.
     
     Eli Wittner
     CTI Cyclotron Systems
     423-966-0072 x411
     wittner@cti-pet.com

From froeber@bbn.com  Fri Jan 24 05:10:36 1997
From: Fred Roeber <froeber@bbn.com>
Date: Fri Jan 24 05:10:38 PST 1997
Subject: Re: VXworks malloc behaviour
Ibrahima Ndoye writes:

> Does anyone know how malloc operates inside vxWorks i.e when vxWorks
> does the garbage collection ?

The second question is easy to answer.  There is no garbage collection
in the VxWorks allocator.  

The first question is a bit tougher. The standard allocator used in
VxWorks is pretty basic.  It is a single threaded, free list based,
first-fit type allocator.  It is single threaded through the use of a
semaphore so that only one task messes with the heap at a time.  The
heap is a huge linked list of free and occupied memory areas. Allocation
scans the free list until a big enough block is found.  That block is
split into a piece to give back to the task and a piece that remains
on the free list (unless the remainder is too small in which case
the task gets the whole chunk).  When a block of memory is freed,
it is linked back into the free list. A slight form of garbage
collection is performed when a block is freed in that the block
being released is "coallesced" with any adjacent free blocks.

The scheme is pretty simple, works well enough to be usable but isn't
that efficient if you do a lot of dynamic allocation during operation.
Hope the info helps.   Fred

-- 
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |

From froeber@bbn.com  Fri Jan 24 05:44:01 1997
From: Fred Roeber <froeber@bbn.com>
Date: Fri Jan 24 05:44:03 PST 1997
Subject: Re: Problems with recursive code & logMsg
M.Paterson wrote:

> We're having some problems with logMsg, using VxWorks under EPICS.
> 
> In our system we channel all log messages through a central function
> which is structured something like this:

<<CUT>>

> The point of having this central logging function is that we can control
> where to direct the messages to and which messages to display. However, we
> have noticed that if two processes (say A and B) running in parallel try
> to issue a message at the same time, we sometimes get two copies of the
> process B message and the process A message is lost. The following comes
> from the VxWorks manual:
> 
> >      Because  logMsg()  does  not  actually  perform  the  output
> >      directly to the logging streams, but instead queues the mes-
> >      sage to the logging task, logMsg() can be called from inter-
> >      rupt service routines.
> >
> >      However,  since  the  arguments  are  interpreted   by   the
> >      logTask()  at  the time of actual logging, instead of at the
> >      moment when logMsg() is called, arguments to logMsg() should
> >      not  be pointers to volatile entities (e.g., dynamic strings
> >      on the caller stack).

> Can anyone think of a way of structuring this central logging function
> which doesn't involve giving logMsg() a dynamic string, or is there a
> work-around or an alternative to logMsg() which can be used reliably with
> a dynamic string?

The fact that logMsg queues up the data you pass it and sends it to
a logging task which actually outputs the data can cause a number of
problems such as the one you are seeing.  The problem is that you
can't really tell when the logging task finishes with the message
buffer and it is free to reuse.  An approach that we have used in
this situation is to set up a static array of message buffers that we
treat as a circular list.  Each call to your cicsLogMessage function
would store the input string in the next entry in this array and call
logMsg to output the message from that array entry.  The two problems
with this approach are that your array has to have fixed limits on
the number of strings in it and the size of each string when you
declare it.  If you queue up too many calls to logMsg and they don't
get worked off, you can overrun the number of strings you put in the
array.  This isn't fatal, it just means you get the same behaviour you
have now of seeing some messages getting lost and others getting
repeated. Also, each message you store in the array has to be truncated
to fit the space it provides.  This second shouldn't be a problem for
you since it seemed each entry had a fixed 40 character size.

Good luck.   Fred
-- 
   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |

From mcintosh@infinity.ccsi.com  Fri Jan 24 05:55:30 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Fri Jan 24 05:55:32 PST 1997
Subject: SUBSCRIBE
I would like to subscribe to the VxWorks mail services. 
Thanks
Gordon McIntosh
mcintosh@rtsd.com

From jwc@ssd.ray.com  Fri Jan 24 06:31:43 1997
From: Cosgrove <jwc@ssd.ray.com>
Date: Fri Jan 24 06:31:45 PST 1997
Subject: Re: VxWorks interfacing to MCOS (Mercury OS)
Gordon,

I am doing (as we speak) exactly what you ask...
No significant experience, yet, however I can talk
as we go along...

I am working on a Signal processing job that receives input over a custom RACEWay
I/F into a 12 node Mercury PPC environment (VME) which then interrupts the HP
Console for display.  The Mercury environment is booted via VxWorks, as well as 
other control and monitoring functions running under VxWorks.  VxWorks developement
environment is Tornado 1.0, VxWorks 5.3....Hosted by a Solaris 2.4 Sparc-10.

John Cosgrove
Raytheon
(401)842-4167
jwc@ssd.ray.com, cosgrove@wsii.com

From sergi@bpo.hp.com  Fri Jan 24 06:41:44 1997
From: Sergi Casas <sergi@bpo.hp.com>
Date: Fri Jan 24 06:41:45 PST 1997
Subject: Re: VXworks malloc behaviour
Ibrahima Ndoye wrote:
> Hi,
> 
> Does anyone know how malloc operates inside vxWorks i.e when vxWorks
> does the garbage collection ?

I think "Garbage Collection" applies only to the process used by Lisp
or Java (among others) to recover non-referenced blocks of memory
(which in C would result in memory leaks). VxWorks does nothing like
that,
even to deallocate blocks that "belong" to a task when it is destroyed.
There is no "task ownership" concept in vxWorks memory model, because it
is more a "multi-threading" model ("lightweight processes") than
a "multitasking" model.

Probably what you mean is "free-block coalescence", the mecanism to
merge
fragmented, contiguous free blocks into a single bigger one. This is
done
in vxWorks at every call to free(). Memory blocks in vxWorks, as in many
other general purpose implementations (not the most efficient, but very
generic), are managed as nodes in a linked list; when you add a free
block
into the free-list, vxWorks not only adds the node to the list, but
rather
looks into adjacent nodes and "coalesces" the new one with the
contiguous
blocks it may find, even including two previously separated blocks into
a single node if the incoming block happens to fill the gap between
them.

Hope this helps.

-- 
Sergi Casas  
Software Engineer  (R&D)
Hewlett-Packard Company
|===========================================================================|
| "The question of whether a computer can think is no more interesting
than |
|  the question of whether a submarine can swim."  E. W.
Dijkstra           |
|===========================================================================|

From h05693@abbchvek.CH  Fri Jan 24 06:52:29 1997
From: Rene Siegenthaler <h05693@abbchvek.CH>
Date: Fri Jan 24 06:52:31 PST 1997
Subject: a.out to IEEE object format converter
Hello everybody,

we're using Tornado on WinNT including the GNU 2.6 Toolkit.
The target is a CPU32 based board. To debug low level stuff, 
we use an HP 64700 emulator plus the corresponding debugger.
This debugger needs IEEE object files.
With the cc86k 2.2.3.1, there was a converter available
from the a.out to IEEE object format.

Unfortunately, this converter does not work with
cc68k 2.6.

Does anybody know something about such a converter or is
it possible to bring cc68k 2.6 to genereted IEEE obj files ?

Thanks in advance.
  ___________________________________________________ 
 | Rene Siegenthaler                                 |       
 | ABB Daimler-Benz Transportation (Switzerland) Ltd |
 | ++41 56 299 21 26                                 |
 | Email:h05693@abbchvek                             |
 |___________________________________________________|

From jwc@ssd.ray.com  Fri Jan 24 06:57:42 1997
From: Cosgrove <jwc@ssd.ray.com>
Date: Fri Jan 24 06:57:44 PST 1997
Subject: Re: Request for Socket information
Eli,
General Opservations about sockets:
    1) Error checking is a good thing,  Remember "Murphy was an Optimist".
    2) UDP has higher throughput and can be broadcast to multiple receivers
       by a single send call.
    3) If you only have 2 stations on the network, your thruput can approach 70%
       of theoretical max (10 Mbps is 10baseT, 10Base2...).  Increasing the number 
       of stations can greatly reduce this.
    4) Overhead of std implimentation (approx 1600 byte / packet max) is approx 
       64/128 bytes in each packet for UDP/TCP, but TCP makes packets for you,
       UDP is one send/one packet.
    5) UDP allows socket overrun, TCP has flow control...  UDP requires higher
       priority task.
As for the one/multiple sockets question, that is application specific.

P.S.  I have not used sockets on VxWorks much (but it is coming, again),  I have
      used sockets from various Unix flavors (HP-UX, SunOS BSD, SunOS Solaris, Moto
      SYSV/R7V3, IRIX 4.x thru IRIX 5.3) as well as Unison 3.2 and OS-9 2.x.

John Cosgrove 
Raytheon
(401)842-4167
jwc@ssd.ray.com or cosgrove@wsii.com

From mea@mclean.sparta.com  Fri Jan 24 07:03:35 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri Jan 24 07:03:37 PST 1997
Subject: Re: VXworks malloc behaviour
At 11:47 PM 1/23/97 PST, you wrote:
>Submitted-by ndoye@ocegr.fr  Thu Jan 23 23:47:35 1997
>Submitted-by: Ibrahima Ndoye <ndoye@ocegr.fr>
> 
>Hi,
>
>Does anyone know how malloc operates inside vxWorks i.e when vxWorks
>does the garbage collection ?
>

VxWorks doesn't *do* garbage collection.  However, it does coalesce
adjacent free partitions into larger partitions upon a "free" call.
Also, by default, when a task in VxWorks exits, it's TCB is automatically
freed, but its stack is not.  To free the stack automagically on 
task exit, you must set the task flag VX_DEALLOC_STACK either when
you spawned the task or using taskOptionsSet during task runtime.

Of course, this garbage collection issue brings up an interesting question
in my mind.  How does the Java virtual machine (which is garbage collection
from Hell as an applett runs) behave in the VxWorks environment?  I assume
that the Java VM mallocs a large block of RAM and then does GC internally
as needed, but is this actually the case?  And, what impact does the Java
VM have on real-time performance?  If I design something using the Java
VM, should I dedicate a CPU to that function to avoid compromising my 
real-time apps?  Inquiring minds want to know...

HTH,

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

From BARONK@HUB01.TDS-GN.LMCO.com  Fri Jan 24 07:12:24 1997
From: "Baron, Kenneth @ GRNK (LI-JUPITER DIRSYNC)" <BARONK@HUB01.TDS-GN.LMCO.com>
Date: Fri Jan 24 07:12:26 PST 1997
Subject: RE: Problems with recursive code & logMsg
If you don't want process B's message to clobber process A's message you
should have separate static character arrays for message_from_A and
message_from_B. These could be 2 separate arrays that are in the
name-space available to all processes or they could be global and in the
name-space of each process or they could be static locals in their
respective functions.

The other issue that you didn't mention is how to prevent process A's
(n+1)th message from clobbering process A's nth message. To do this, you
must buffer your messages. Implement a circular message queue in either
>each process and pass the appropriate pointer to cicsLogMessage or in
cicsLogMessage copy the message into a circular message queue before
calling logMsg. If you use the latter approach, you have to worry about
>process A's call to cicsLogMessage interrupting process B's call to
cicsLogMessage. (Critical region protection type stuff.) The circular
buffers have to be large enough too ensure that logMsg actually outputs
a message before its slot in the circular buffer is overwritten.

>Submitted-by M.Paterson@roe.ac.uk  Fri Jan 24 03:28:50 1997
>Submitted-by: M.Paterson@roe.ac.uk
> 
>All,
>
>We're having some problems with logMsg, using VxWorks under EPICS.
>
>In our system we channel all log messages through a central function
>which is structured something like this:
>
>   void cicsLogMessage( const long debug, const char* message )
>   {
>     char histMsg[40];
>
>     if ( debug <= debugLevel )
>     {
>
>       if ( databaseLogging == TRUE )
>       {
>         strncpy( histMsg, message, 40 );
>
>         (Write the string "histMsg" to the 40 character history log record 
>         in my database).
>       }
>
>       if ( consoleLogging == TRUE )
>       {
>         logMsg( "%s\n", message );
>       }
>     }
>   }
>
>When we call this function we construct the string using sprintf(). For 
>example:
>
>  sprintf( message, "The current value is %ld", longValue );
>  cicsLogMessage( debug, message );
>
>The point of having this central logging function is that we can control
>where to direct the messages to and which messages to display. However, we
>have noticed that if two processes (say A and B) running in parallel try
>to issue a message at the same time, we sometimes get two copies of the
>process B message and the process A message is lost. The following comes
>from the VxWorks manual:
>
>>      Because  logMsg()  does  not  actually  perform  the  output
>>      directly to the logging streams, but instead queues the mes-
>>      sage to the logging task, logMsg() can be called from inter-
>>      rupt service routines.
>>  
>>      However,  since  the  arguments  are  interpreted   by   the
>>      logTask()  at  the time of actual logging, instead of at the
>>      moment when logMsg() is called, arguments to logMsg() should
>>      not  be pointers to volatile entities (e.g., dynamic strings
>>      on the caller stack).
>
>So it seems that our use of a dynamic string "message" is unreliable, but we
>cannot think of a way of having a central logging function like the above
>without passing a dynamic string to it.
>
>Can anyone think of a way of structuring this central logging function
>which doesn't involve giving logMsg() a dynamic string, or is there a
>work-around or an alternative to logMsg() which can be used reliably with
>a dynamic string?
>
>Cheers,
>Magnus
>
>****  Magnus J Paterson           email  mjp@roe.ac.uk   
>****  Royal Observatory           ph     +44 (0)131 668 8247
>****  Edinburgh EH9 3HJ           fax    +44 (0)131 668 1130
>****  SCOTLAND                    web    http://www.roe.ac.uk/mjpwww/ 
>

From gnh@adv.sbc.sony.co.jp  Fri Jan 24 07:13:30 1997
From: Graham Harvey <gnh@adv.sbc.sony.co.jp>
Date: Fri Jan 24 07:13:32 PST 1997
Subject: Re: Problems with recursive code & logMsg

Magnus,

>We're having some problems with logMsg, using VxWorks under EPICS.
>
>In our system we channel all log messages through a central function
>which is structured something like this:
>
>   void cicsLogMessage( const long debug, const char* message )
>   {
>     char histMsg[40];
>
>     if ( debug <= debugLevel )
>     {
>
>       if ( databaseLogging == TRUE )
>       {
>         strncpy( histMsg, message, 40 );
>
>         (Write the string "histMsg" to the 40 character history log record 
>         in my database).
>       }
>
>       if ( consoleLogging == TRUE )
>       {
>         logMsg( "%s\n", message );
>       }
>     }
>   }
>
>When we call this function we construct the string using sprintf(). For 
>example:
>
>  sprintf( message, "The current value is %ld", longValue );
>  cicsLogMessage( debug, message );
>
>The point of having this central logging function is that we can control
>where to direct the messages to and which messages to display. However, we
>have noticed that if two processes (say A and B) running in parallel try
>to issue a message at the same time, we sometimes get two copies of the
>process B message and the process A message is lost. The following comes
>from the VxWorks manual:
>
>>      Because  logMsg()  does  not  actually  perform  the  output
>>      directly to the logging streams, but instead queues the mes-
>>      sage to the logging task, logMsg() can be called from inter-
>>      rupt service routines.
>>  
>>      However,  since  the  arguments  are  interpreted   by   the
>>      logTask()  at  the time of actual logging, instead of at the
>>      moment when logMsg() is called, arguments to logMsg() should
>>      not  be pointers to volatile entities (e.g., dynamic strings
>>      on the caller stack).
>
>So it seems that our use of a dynamic string "message" is unreliable, but we
>cannot think of a way of having a central logging function like the above
>without passing a dynamic string to it.
>
>Can anyone think of a way of structuring this central logging function
>which doesn't involve giving logMsg() a dynamic string, or is there a
>work-around or an alternative to logMsg() which can be used reliably with
>a dynamic string?

We have had exactly the same problem and came up with a solution which suits
us:

Create yourself a debug message queue:

        debugQID=msgQCreate(<number of messages>,<size of messages>,MSG_Q_FIFO);

If you need to preserve the task name of the caller put this in your function:

        char nameofthistask[30];
        ......
        strcpy(nameofthistask,taskName(taskIdSelf());
        ......

If you need to timestamp the arrival of the messages use clock_gettime().

Replace the logMsg call with a msgQSend to write your message to a 
previously initialised message queue:

        msgQSend(debugQID,message,strlen(message),NO_WAIT,MSG_PRI_NORMAL);

Then write another noddy process to read the queue you are writing to
and redirect the output wherever you want it to go:

        while(TRUE)
        {
                msgQReceive(debugQID,debugmessage,100,WAIT_FOREVER);
                fdprintf(debugpath,"%s",debugmessage);
        }

Set debugpath to the virtual I/O path, the path to a serial port, whatever.

Run the above task at a low priority to avoid taking too much CPU away from
the reporting processes. 

This setup will avoid the variable clashing you describe. We wanted to print
out every element of a byte array in a tight for loop. This isn't possible
with logMsg.

Hope this helps.

Graham

*****************************************************************
* Graham Harvey                     Jays Close
*                                   Basingstoke
* Principal Engineer                Hampshire
* Advanced Technology Division      England
* Sony B.P.E. Ltd.                  RG22 4SB
* 
* Tel: +44 1256 483792 / 483403     Email: gnh@adv.sbc.sony.co.jp
* Fax: +44 1256 483591 / 811430
*****************************************************************

From mea@mclean.sparta.com  Fri Jan 24 07:29:36 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri Jan 24 07:29:38 PST 1997
Subject: Re: Request for Socket information
At 04:49 AM 1/24/97 PST, you wrote:
>Submitted-by @positron.CTI-PET.COM:wittner%pcmail.cti-pet.com@cti-pet.com
Fri Jan 24 04:49:26 1997
>Submitted-by: wittner%pcmail.cti-pet.com@cti-pet.com
> 
>     To all:
>     
>     We are considering using sockets to transfer information between a 
>     target running vxWorks and a PC.  We have established the sockets with 
>     Berkeley Sockets/Winsock.  We would appreciate any 
>     information/shareware on application protocols.  Questions we have 
>     include:  1) 1 socket or multiple sockets?  2) Asynchronous or 
>     synchronous communication (i.e. error checking).  3) Maximum througput 
>     using the ethernet and potential problems we might encounter with 
>     bandwidth.  4) Task priority suggestions.
>     

As with all things in real-time stuff, the answer is... it depends ;-).
The use of multiple sockets can help you simplify you Windoze application
code because you can segregate the traffic.  If you split it up using
separate threads for each connection, then you're throwing yourself
to the mercy of the Windoze scheduler.  In theory, in Win 95 and NT,
it's supposed to be a preemptive, priority based scheduler which should
work as you want it (i.e., each thread will block until a message comes
in to be processed).  However, I don't have enough experience with the
Winsock stuff to give you a definative answer.  However, trying to do 
multiple sockets in a single thread requires the Winsock "select" equivalent
or running the sockets in non-blocking mode.  I don't think that I would 
recommend this approach unless you can sacrifice system responsiveness
to things like mouse clicks, window changes, etc. because the single
thread will tend to monopolize the system.

As far as 2) is concerned, your question is a non sequitor.  Async vs. Sync
has nothing to do with error-checking (which you should be doing regardless).
If by Async you *really* mean non-blocking, then I'd suggest against it
because of the single thread issue I talked about in the previous paragraph.
In general, use muliple threads with blocking sockets (provided your
O/S scheduler is quick enough).

I've seen sustainable 980 KBytes/sec FTPs using VxWorks, Intel 82596 Ethernet
controllers and i960s.  Most 68030s, max out at about 600 KBytes/sec.
Your PC's performance will vary wildly depending on whose hardware you're
using and whose Windoze driver/TCP stack you're using.  If 600 KBytes/sec
is insufficient, then think 100 Base T (Fast-Ethernet).

Task priority on which side?  On VxWorks, if the application is network-
centric, I wouldn't set my priority any higher than the tNetTask.  As
far as Windoze is concerned, you haven't given enough info to answer that
question.

HTH,

    

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

From wbrown@csg.lbl.gov  Fri Jan 24 07:38:51 1997
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Fri Jan 24 07:38:54 PST 1997
Subject: Re: Problems with recursive code & logMsg

I think that in order to do what you want to do, you will need to have your
central loggging function maintain a queue of messages which it in turn
passes to logMsg.  Actually, I guess I'd be tempted to write a new logMsg()
that did this for you, ie the queueing.  This would need to be a task that
ran in place of logTask.

Another approach might be to replace logMsg() with something that wrote the
desired message into a message queue (this can be done from interrupt level)
and then write a new logTask that picked messages out of the queue.

We've been bit by a similar problem more than once.  Someday Real_Soon_Now(tm)
we're gonna solve the problem.  But I wouldn't hold my breath......

Disclaimer:  Any opinions are my own and have	    |  -bill
    nothing to do with the official policy or the   |   wlbrown@lbl.gov
    management of L.B.N.L, who probably couldn't    |   Berkeley, CA
    care less about employees who play with trains. |   aka wlbrown@netcom.com

From tmorris@me.umn.edu  Fri Jan 24 09:25:45 1997
From: Ted Morris <tmorris@me.umn.edu>
Date: Fri Jan 24 09:25:47 PST 1997

Does anyone know if using the function, bcopy, memcpy, or even strcpy
can actually be pre-empted during the copying operation internal to
these functions?

At least in VxSIM 5.1 (sparc), doing something like strcat(buff, "bla
bla bla") within a task that is pre-empted will always finish the
operation of moving the data into buff.

Any comments/edification/clarrification would be greatly appreciated,

thanks in advance!

Ted

TGIF

-- 
Ted Morris
tmorris@me.umn.edu                                             612-625-3520
Center For Advanced Manufacturing Design And Control           612-625-9881
Institute of Technology, U of Minnesota                   FAX: 612-625-8884

From sergi@bpo.hp.com  Fri Jan 24 10:10:57 1997
From: Sergi Casas <sergi@bpo.hp.com>
Date: Fri Jan 24 10:11:03 PST 1997
Subject: Re: VXworks malloc behaviour
Mike Anderson wrote:
> Of course, this garbage collection issue brings up an interesting question
> in my mind.  How does the Java virtual machine (which is garbage collection
> from Hell as an applett runs) behave in the VxWorks environment?  I assume
> that the Java VM mallocs a large block of RAM and then does GC internally
> as needed, but is this actually the case?  And, what impact does the Java
> VM have on real-time performance?  If I design something using the Java
> VM, should I dedicate a CPU to that function to avoid compromising my
> real-time apps?  Inquiring minds want to know...

Check http://www.softplc.com/machj/

They claim they have a real-time garbage collector.

In fact, given the clever approach of Java to Garbage Collection, I don't 
really see the need for a special "real-time" thing: let me explain.
In Java, the Garbage Collector runs as the lowest priority thread, which means
that while there is nothing to be done it will run, otherwise it waits till
all the memory has been used and some thread still needs more; in that case
the thread blocks and the garbage collector starts working till there is
enough free space for the task to go on.

As I see it, real time applications are typically reactive, event-driven
systems or periodic processes (this is, time-event driven), and they don't 
usually take all the CPU (in fact, one usually allows for some CPU margin 
just in case things go too tight). What real time applications need is that 
when some external or timing event happens the response to it must be
deterministically within certain time limits, right?

Then, the only thing one has to take into account when designing real-time
systems with Java is to make sure that the ratio of busy vs. idle time for 
application tasks in a given CPU leaves enough room for the Garbage 
Collector to keep memory free enough so that no application task has to
sit waiting for free memory.

The only pathological application is the one that has one or more low
priority background tasks (accounting, monitoring, reporting) which never
block but yield the CPU only due to their low priority in a priority-driven
preemptive environment such as vxWorks (much like the Garbage Collector 
itself!!). In those cases one must make sure that those continuous tasks
periodically yield the CPU and leave it idle enough for the Garbage
Collector to do its work.

In summary, the only problem with Java-style Garbage Collectors in real
time is guaranteeing that the system will NEVER reach the extreme memory
situation so as to force any task to sit waiting for any undeterministic
garbage collection process. The engineer has to chose a powerful enough
CPU that is able to run enough of the Garbage Collector during
application idle time. No need to dedicate a whole CPU to that process
as far as the system's CPU is powerful enough, because response times are
not compromised by the GC.

Is that right ?

PD: LISP is different 'cause common implementations are not multithreaded
and always wait to the extreme out-of-memory situation to start a non-
deterministic Garbage Collection process while the requesting program
waits.
-- 

Sergi Casas
Software Engineer  (R&D) 
Hewlett-Packard Company

From mea@mclean.sparta.com  Fri Jan 24 11:06:30 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri Jan 24 11:06:36 PST 1997
Subject: Re: VXworks malloc behaviour
At 10:11 AM 1/24/97 PST, you wrote:
>Submitted-by sergi@bpo.hp.com  Fri Jan 24 10:10:57 1997
>Submitted-by: Sergi Casas <sergi@bpo.hp.com>
> 
>
>
>Check http://www.softplc.com/machj/
>

Thanks for the info, Sergi.  Now, I wonder if WRS really implemented it
that way?

Regards,

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

From pardo@rti.com  Fri Jan 24 11:27:33 1997
From: Gerardo Pardo-Castellote <pardo@rti.com>
Date: Fri Jan 24 11:27:35 PST 1997
Subject: Re: VXworks malloc behaviour

>> Submitted-by sergi@bpo.hp.com  Fri Jan 24 10:10:57 1997
>> Submitted-by: Sergi Casas <sergi@bpo.hp.com>
 

>> In fact, given the clever approach of Java to Garbage Collection, I don't 
>> really see the need for a special "real-time" thing: let me explain.
>> In Java, the Garbage Collector runs as the lowest priority thread, which means
>> that while there is nothing to be done it will run, otherwise it waits till
>> all the memory has been used and some thread still needs more; in that case
>> the thread blocks and the garbage collector starts working till there is
>> enough free space for the task to go on.

 ... details ommitted ...

>> In summary, the only problem with Java-style Garbage Collectors in real
>> time is guaranteeing that the system will NEVER reach the extreme memory
>> situation so as to force any task to sit waiting for any undeterministic
>> garbage collection process. The engineer has to chose a powerful enough
>> CPU that is able to run enough of the Garbage Collector during
>> application idle time. No need to dedicate a whole CPU to that process
>> as far as the system's CPU is powerful enough, because response times are
>> not compromised by the GC.

>> Is that right ?

>> PD: LISP is different 'cause common implementations are not multithreaded
>> and always wait to the extreme out-of-memory situation to start a non-
>> deterministic Garbage Collection process while the requesting program
>> waits.

The problem with the Java garbage collector is that although it runs as
the lowest priority task, as soon as it starts running, it promotes itself to
the highest priority, and then runs to completion. I.e. it is not
capable of doing "incremental" garbage collection. This makes it really
unusable for real-time IMHO because even if you never exhaust the memory,
every now and then, whenever the GC starts running it will lock up the
system for an un-specified and un-controllable ammount of time. This
yields the same behavior as the LISP GC that Sergi describes.

My understanding is that the next release of Java will support incremental
garbage collection... then, depending on the granularity of the "increments"
it may stop being a problem as Sergi describes.

		-Gerardo

===========================================================================
=                                           =                             =
=   Gerardo Pardo-Castellote                =   email: pardo@rti.com      =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312     =
=   155A Moffett Park Drive, Suite 111      =   Fax:   (408) 734-5009     =
=   Sunnyvale, CA 94089                     =   http://www.rti.com        =
=                                           =                             =
===========================================================================

From Phil_Watson@ns1.masirv.com  Fri Jan 24 11:34:10 1997
From: Phil_Watson@ns1.masirv.com (Phil Watson)
Date: Fri Jan 24 11:34:12 PST 1997
Subject: Re: a.out to IEEE object format converter
On Jan 24,  6:52am, the vxWorks Users Group Exploder wrote:
> Subject: a.out to IEEE object format converter
> Submitted-by h05693@abbchvek.CH  Fri Jan 24 06:52:29 1997
> Submitted-by: Rene Siegenthaler <h05693@abbchvek.CH>
>
> Hello everybody,
>
> we're using Tornado on WinNT including the GNU 2.6 Toolkit.
> The target is a CPU32 based board. To debug low level stuff,
> we use an HP 64700 emulator plus the corresponding debugger.
> This debugger needs IEEE object files.
> With the cc86k 2.2.3.1, there was a converter available
> from the a.out to IEEE object format.
>
> Unfortunately, this converter does not work with
> cc68k 2.6.
>-- End of excerpt from the vxWorks Users Group Exploder

I have used a converter from Applied Microsystems Corp [(714) 852-9446] with
cc68k 2.2.3. I don't know if this is the one you have been using, nor if it
works with the latest GNU objects. Perhaps you should contact them.

The purchase fee was very reasonable three years(!) ago.

-- 
----
Philip Watson
Telecommunications Lead

Phil_Watson@masirv.com
Matsushita Avionics Systems Corporation
15253 Bake Parkway
Irvine, California, 92618  U.S.A.
Ph: (714) 461-7300 (direct -7570)
Fx: (714) 462-7103

From lwatson@arcserv.dasd.honeywell.com  Fri Jan 24 12:42:35 1997
From: lwatson@arcserv.dasd.honeywell.com
Date: Fri Jan 24 12:43:01 PST 1997
Subject: Problem with launch logging the user out

I have been encountering a problem trying to run launch and am wondering
if any other users have seen it and/or possibly know the cause or solution.

Target:  custom i960MC running vxWorks 5.3; rom resident
	 (this probably doesn't affect the problem)
Host:  Sun Sparc5 running SunOS 4.1.4, using Tornado
Host-Target interface:  SLIP only

This morning, (and for the last couple of weeks), launch appeared to run ok.
While debugging a problem, all the windows on the sun froze.
I rebooted and tried to re-launch.
5 times in a row - I tried to run "launch".  It never came up - it just
	logged me completely off the sun.  I rebooted again, but it didn't help.
I went to another sun and had no problems running launch.
I came back to the original sun, and launch came up just fine.
???
We have suspected some problems with the Sun window manager because of problems
with other windows applications.  Those problems are usually limited to freezing
all the Sun windows, but as soon as the current window is killed, the others
are fine.  
Only "launch" will log out the user completely when the user tries to run it.
This is probably not a Wind River issue, but maybe "launch" is causing 
something.

Silicon Graphics machines don't appear to ever have this "freeze" problem.
Any system resources that need to be modified to run launch reliably?
Any advice?

Thanks,

Linda
lwatson@dasd.honeywell.com

From cpinkard@kla.com  Fri Jan 24 13:51:42 1997
From: Christopher Pinkard <cpinkard@kla.com>
Date: Fri Jan 24 13:51:44 PST 1997
Subject: Ethernet Chipsets 
Hail good fellows, full of mirth and cheer -

We are about to design and build a processor board
which will be running vxworks some day.  What 
ethernet chipset(s) should we be looking at that
have good vxworks support.  What kind of questions
should I even be asking when I decide on an 
ethernet chipset?

many thanks,
chris p.

From greg.brissey@nmr.varian.com  Fri Jan 24 14:02:10 1997
From: greg.brissey@nmr.varian.com (Greg Brissey x6951)
Date: Fri Jan 24 14:02:11 PST 1997
Subject: Re: VXworks malloc behaviour
> 
> Submitted-by pardo@rti.com  Fri Jan 24 11:27:33 1997
> Submitted-by: Gerardo Pardo-Castellote <pardo@rti.com>
>  
> 
> >> Submitted-by sergi@bpo.hp.com  Fri Jan 24 10:10:57 1997
> >> Submitted-by: Sergi Casas <sergi@bpo.hp.com>
>  
> 
> >> In fact, given the clever approach of Java to Garbage Collection, I don't 
> >> really see the need for a special "real-time" thing: let me explain.
> >> In Java, the Garbage Collector runs as the lowest priority thread, which means
> >> that while there is nothing to be done it will run, otherwise it waits till
> >> all the memory has been used and some thread still needs more; in that case
> >> the thread blocks and the garbage collector starts working till there is
> >> enough free space for the task to go on.
> 
>  ... details ommitted ...
> 
> The problem with the Java garbage collector is that although it runs as
> the lowest priority task, as soon as it starts running, it promotes itself to
> the highest priority, and then runs to completion. I.e. it is not
> capable of doing "incremental" garbage collection. This makes it really
> unusable for real-time IMHO because even if you never exhaust the memory,
> every now and then, whenever the GC starts running it will lock up the
> system for an un-specified and un-controllable ammount of time. This
> yields the same behavior as the LISP GC that Sergi describes.
> 
> My understanding is that the next release of Java will support incremental
> garbage collection... then, depending on the granularity of the "increments"
> it may stop being a problem as Sergi describes.
> 
> 		-Gerardo

Yes the Java garbage collector does promotes itself to a higher priority but only
as high or 1 higher as the Java VM vxWorks task. Thus if you have a hard 
real-time requirement you can use a vxWorks task of higher priority than the Java VM
task and not worry about the garbage collector.  This technique of course can't help
any Java thread, meaning the hard real-time code can not be Java.

Greg Brissey
Varian NMR
greg.brissey@nmr.varian.com

From rgordon@net.com  Fri Jan 24 15:36:06 1997
From: rgordon@net.com (Roy Gordon)
Date: Fri Jan 24 15:36:08 PST 1997
Subject: Re: Problem with launch logging the user out
We have had somewhat similar problems using vxSim on Solaris, though
not as out-and-out as you describe, e.g., being unceremoniously logged off.

For us it appears a Solaris resource problem, since, before it gets out of
hand, if I remove some windows, it goes away.

So, it looks as if either memory or swap is overburdened.  swap -s shows
swap to have about 60MB free and the system has 64MB of physical memory,
so that didn't seem like too good a candidate either.

But the behavior--free up windows and the system improves dramatically--
has proven consistent.

						-- roy
						
						
> This morning, (and for the last couple of weeks), launch appeared to run ok.
> While debugging a problem, all the windows on the sun froze.
> I rebooted and tried to re-launch.
> 5 times in a row - I tried to run "launch".  It never came up - it just
> 	logged me completely off the sun.  I rebooted again, but it didn't help.
> I went to another sun and had no problems running launch.
> I came back to the original sun, and launch came up just fine.

From egbert@ra.timeplex.com  Fri Jan 24 16:06:03 1997
From: egbert@ra.timeplex.com (Stephen L. Egbert)
Date: Fri Jan 24 16:06:05 PST 1997
Subject: Re: Problem with launch logging the user out
Linda,

> 
> I have been encountering a problem trying to run launch and am wondering
> if any other users have seen it and/or possibly know the cause or solution.
> 
> Target:  custom i960MC running vxWorks 5.3; rom resident
> 	 (this probably doesn't affect the problem)
> Host:  Sun Sparc5 running SunOS 4.1.4, using Tornado
> Host-Target interface:  SLIP only
> 
> This morning, (and for the last couple of weeks), launch appeared to run ok.
> While debugging a problem, all the windows on the sun froze.
> I rebooted and tried to re-launch.
> 5 times in a row - I tried to run "launch".  It never came up - it just
> 	logged me completely off the sun.  I rebooted again, but it didn't help.
> I went to another sun and had no problems running launch.
> I came back to the original sun, and launch came up just fine.
> ???

Most likely this is a SunOS serial driver problem that is locking up your windows, not the window server.  Confirm this first by disconnecting the SLIP serial cable to the Sun and see if your window unlocks after a few seconds.

If and only if this makes the problem go away, then the explanation for this would be that the ZS device is stuck in perpetual interrupt mode.  Rebooting the i960MC's serial driver usually solves the problem.

> We have suspected some problems with the Sun window manager because of problems
> with other windows applications.  Those problems are usually limited to freezing
> all the Sun windows, but as soon as the current window is killed, the others
> are fine.  
> Only "launch" will log out the user completely when the user tries to run it.
> This is probably not a Wind River issue, but maybe "launch" is causing 
> something.
> 

Steve

Stephen (Steve) L. Egbert              Work: (214) 340-3300
ascom Timeplex                          Fax: (214) 341-3654
Dallas, Texas 75243-7095                Net: egbert_steve@timeplex.com

	"Try moving off NT easily. You can move from Solaris to HP/UX
	to AIX or DEC easily-- relative to moving off of NT, which is
	like a Roach Motel. Once you check in, you never check out.
	-Scott McNealy, Sun Microsystems, Inc.

From stan@rti.com  Fri Jan 24 20:34:41 1997
From: stan@rti.com (Stan Schneider)
Date: Fri Jan 24 20:34:43 PST 1997
Subject: Re: Problem with launch logging the user out

>> Submitted-by lwatson@arcserv.dasd.honeywell.com  Fri Jan 24 12:42:35 1997

>> This morning, (and for the last couple of weeks), launch appeared to run ok.
>> While debugging a problem, all the windows on the sun froze.
>> I rebooted and tried to re-launch.
>> 5 times in a row - I tried to run "launch".  It never came up - it just
>> 	logged me completely off the sun.  I rebooted again, but it didn't help.
>> I went to another sun and had no problems running launch.
>> I came back to the original sun, and launch came up just fine.

This sounds like the infamous Motif bug in OpenWindows.  Are you running an
older version of OpenWindows?  If so, you need a patch.  Here's the info:

  3) On Sun workstations running the news X-server prior to release Solaris
     2.3, patches are required to run Motif version 1.2 or later clients.  In
     particular, OpenWindows version 2 requires patch 100176-19, OpenWindows 3
     on SunOS 4.1.x requires 100444-37, and Solaris 2.2 requires patch
     101084-01.  Most systems will already have these patches installed (since
     they are required by every Motif 1.2 client.  Even with the patches,
     the X11R4 server available under SunOS 4.x doesn't always refresh the
     screen when menus are taken down (a minor annoyance).

	-- Stan
	stan@rti.com

From daemon@csg.lbl.gov  Sat Jan 25 04:00:22 1997
From: daemon@csg.lbl.gov
Date: Sat Jan 25 04:00:29 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 25 04:00:20 PST 1997

        Subject: Re: VXworks malloc behaviour
        Subject: How do I redirect the virtual console?
        Subject: Re: SGI host support
        Subject: VxWorks 5.3 kernel size ?
        Subject: Re: Problems with recursive code & logMsg
        Subject: Re: Problems with recursive code & logMsg

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks malloc behaviour
Date: Fri, 24 Jan 1997 15:30:11 -0800
From: "h.j. bae" <hjb@pso.com>
Organization: the derome mansion, oakland california
Message-ID: <32E94603.6FD8@pso.com>
References: <199701241932.LAA24217@lassen.rti.com>
Reply-To: hjb@pso.com

i've been playing around with Boehm-Demers-Weiser conservative garbage
collector  which allows incremental and generational garbage
collection.  it requires MMU support though.  many java virtual
machine -> C  compilers use this garbage collector.  available free:
ftp://parcftp.xerox.com/pub/gc/gc.html

i have been looking at the java stuff for some time now for embedded
and realtime usage.  i've come to the conclusion that a JVM -> C
compilation is the only way to go.

- -- 
http://www.pso.com
mailto:hjb@pso.com

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

Newsgroups: comp.os.vxworks
Subject: How do I redirect the virtual console?
Date: 24 Jan 1997 22:51:53 GMT
From: markham@bnr.ca (Andrew Markham)
Organization: markham@nortel.ca
Message-ID: <5cbee9$k82@nrtphba6.bnr.ca>

Is there a fairly straightforward way to redirect the
virtual console to a file?  We're running VxSim 5.3
on HPUX.

Thanks.

- --
Andy Markham
markham@nortel.ca
Signaling Server Group
Nortel Inc.

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

Newsgroups: comp.os.vxworks
Subject: Re: SGI host support
Date: Fri, 24 Jan 1997 15:47:27 -0800
From: "h.j. bae" <hjb@pso.com>
Organization: the derome mansion, oakland california
Message-ID: <32E94A0F.3B84@pso.com>
References: <199701211601.JAA07784@laplace.idec.sdl.usu.edu>
Reply-To: hjb@pso.com

i don't know if wrs is dropping sgi support.  however, you can
always build your own gnu toolchain, copy the binaries (libraries)
and source code to irix box, and build your own cross development
environment.

i do this and i'm happy.

- -- 
http://www.pso.com
mailto:hjb@pso.com

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

Newsgroups: comp.os.vxworks
Subject: VxWorks 5.3 kernel size ?
Date: Fri, 24 Jan 1997 17:59:06 -0800
From: George Pontis <geo@z9.com>
Organization: InterNex Information Services 1-800-595-3333
Message-ID: <32E968EA.8A0@z9.com>
Reply-To: geo@z9.com

For a 68332 target, can someone tell me approx how big the kernel is ?
For this application, networking support is not required.

Also, it was suggested to me that a build for debugging would require
much more target memory than one without debugging information. I can
see that perhaps -g turns off some code optimization, but other than
that why should the target care about debug info ? Is the debug info
actually downloaded to the target ?

Thanks for any pointers or insight into the above.

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

Newsgroups: comp.os.vxworks
Subject: Re: Problems with recursive code & logMsg
Date: Fri, 24 Jan 1997 13:51:53 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: Pacific Bell Internet Services
Message-ID: <32E92EF9.7D93@pacbell.net>
References: <8711.199701241127@fetlar.roe.ac.uk>
Reply-To: dcaustin@pacbell.net

M.Paterson@roe.ac.uk wrote:
> 
> All,
> 
> We're having some problems with logMsg, using VxWorks under EPICS.
> 

[snip...]

> Magnus
> 
> ****  Magnus J Paterson           email  mjp@roe.ac.uk
> ****  Royal Observatory           ph     +44 (0)131 668 8247
> ****  Edinburgh EH9 3HJ           fax    +44 (0)131 668 1130
> ****  SCOTLAND                    web    http://www.roe.ac.uk/mjpwww/

logMsg() is not fail safe... because it provides no means of notifying
you when it has displayed your message... so you never know when you can
re-use the buffer... For example if you had a high priority interrrupt
routine that was continually calling logMsg() it would never catch up...
but generally...

The important thing to remember is that what "message" points to cannot
change value until the logging system has had time to display the
message.

Based on your discription... It appears that you have 2 processes
sharing a global buffer (pointed to by message) hence your problem
because if process B writes the buffer before the message has been
logged it will log the message from B twice because logMsg() has only a
ptr to the message.

One solution is to have cicsLogMessage() copy the messages into a fifo
of messages and send the address of the message in the fifo to logMsg()
say...

cicsLogMessage(char* msg)
{
static char* fifo[10][40];
static int next=0;

strncpy(fifo[next],msg,40);
logMsg(fifo[next]);

if(++next>=10)next=0;	/* next location in fifo */
}

Good Luck

Duane Austin

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

Newsgroups: comp.os.vxworks
Subject: Re: Problems with recursive code & logMsg
Date: Fri, 24 Jan 1997 13:54:28 -0800
From: Duane C Austin <dcaustin@pacbell.net>
Organization: Pacific Bell Internet Services
Message-ID: <32E92F94.3692@pacbell.net>
References: <8711.199701241127@fetlar.roe.ac.uk>
Reply-To: dcaustin@pacbell.net

oops  my declaration was incorrect... should have been

char fifo[10][40];

Duane

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

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

From mcintosh@infinity.ccsi.com  Sat Jan 25 04:36:04 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Sat Jan 25 04:36:06 PST 1997
Subject: RE:bcopy, memcpy, or even strcpy pre-emption

Ted,
Unless VxWorks has added some code to disable context switching, the only
restriction would normally be finishing the executing instruction.  This
is not normally done because when the tasks starts to execute again, it 
will finish.  If your application has restrictions on finishing an operation
prior to a context switch, the application will normally handle it.
Gordon McIntosh
mcintosh@rtsd.com
http://www.rtsd.com

From mcintosh@infinity.ccsi.com  Sat Jan 25 04:42:48 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Sat Jan 25 04:42:50 PST 1997
Subject: Re: Ethernet Chipsets
Chris,
Look at the present implementations that companies like Motorola are using 
on the latest board designs like MVME2604, MVME3604.  Both support VxWorks,
drivers have been written, etc.  I believe they are using the DEC21140.
The obvious questions that come to mind quickly are:
1. What is your local bus ?
2. What processor family are you using ?
3. Are you doing 10Mbit or 100Mbit ?
4. Driver availability.

Gordon McIntosh
mcintosh@rtsd.com
http://www.rtsd.com

From leonid@rst.co.il  Sun Jan 26 01:35:19 1997
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sun Jan 26 01:35:21 PST 1997
Subject: Re: Problem with launch logging the user out
> From: lwatson@arcserv.dasd.honeywell.com
> Date: Fri Jan 24 12:43:01 PST 1997
> ...
> Only "launch" will log out the user completely when the user tries to run it.
> ...

This sounds exactly like the problems that the patch 100444-XX is supposed
to fix. This is a jumbo patch from Sun for OpenWindows, and it is mentioned
in the Tornado 1.0 Installation Guide. Note that although Tornado
itself needs to be installed only once - on the file server,
the OW patch must be installed on each and every workstation
to use Tornado. The patch is not Tornado-specific but is Motif-friendly.

"XX" stands for revision of the patch, general rule is to get the latest.
We use Rev 68, and Tornado works just fine.
-----------------------------------------------------------------------
Leonid Rosenboim                        Phone: +972-3-559-8144
Wind River Systems Israel               Fax:   +972-3-559-8244
3 Hashikma st. Industrial Zone,         E-Mail: leonid@wrs.co.il
P.O.Box 11502, AZUR 58017, Israel    	WWW: http://www.wrs.com

From daemon@csg.lbl.gov  Sun Jan 26 04:01:03 1997
From: daemon@csg.lbl.gov
Date: Sun Jan 26 04:01:06 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 26 04:01:00 PST 1997

        Subject: Re: Request for Socket information
        Subject: Re: Problems with recursive code & logMsg
        Subject: Memory protection (was Re: VxVMI stuff)

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

Newsgroups: comp.os.vxworks
Subject: Re: Request for Socket information
Date: Fri, 24 Jan 1997 15:33:37 -0800
From: "h.j. bae" <hjb@pso.com>
Organization: the derome mansion, oakland california
Message-ID: <32E946D1.3F02@pso.com>
References: <3.0.32.19970124102807.006f0750@mailhost.mclean.sparta.com>
Reply-To: hjb@pso.com

i've seen (and measured!) throughput on a 16mhz 68020 with amd lance
ethernet chip: over 1.1 mbytes per sec -- circa vxworks 5.0

- -- 
http://www.pso.com
mailto:hjb@pso.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Problems with recursive code & logMsg
Date: 25 Jan 1997 20:24:22 GMT
From: garyjohn@spk.hp.com (Gary Johnson)
Organization: Hewlett-Packard, Spokane Division
Message-ID: <5cdq5m$l7l@hpcvsnz.cv.hp.com>
References: <8711.199701241127@fetlar.roe.ac.uk>

The problem here is not with your use of a central logging function but
with your use of sprintf() to create 'message' in the first place.  It
is the subsequent calls to that particular sprintf() that overwrite the
'message' string before logMsg() has had time to print the first one
that cause you problems.

That being said, I think the solution may be in your central logging
function already.  You don't elaborate on what it means to "Write the
string "histMsg" to the 40 character history log record in my database,"
but if your database is in RAM, you could pass logMsg() a pointer to the
string in this database instead of 'message'.

If you don't have such access to this database, then I would follow the
suggestions of some of the other respondents and maintain a circular
buffer in your central logging function of the last N messages and pass
pointers to elements of this buffer to logMsg().  I certainly wouldn't
try to write a new version of logMsg()--that's a more difficult solution
than the problem warrants.

Gary

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

Newsgroups: comp.os.vxworks
Subject: Memory protection (was Re: VxVMI stuff)
Date: Thu, 23 Jan 1997 16:51:04 -0600
From: cyclone@netcom.com
Organization: Deja News Usenet Posting Service
Message-ID: <854057728.20611@dejanews.com>

"Thomas K. Buchanan" <tkb@mclean.sparta.com> writes:

>Although I argue against it, it is possible to implement task-based
>protection...

>I prepared an estimate for accomplishing this work for a customer, it 
>could take over 4 man-years of effort by senior software engineers to 
>implement task based VM on a single architecture.

>You'll end up with a much larger, more sophisticated kernel.  The volume 
>of code needed to manipulate the VM contexts may exceed that of your 
>application.

Maybe trying to hack the VxWorks kernel, but there are real-time operating 
systems with true task-level memory protection throughout the OS 
(including I/O space) with similar performance and code size to VxWorks.  
OS-9 and QNX would be two of these.  Enabling MMU support will add a few % 
to kernel overhead (due to need to restore additional MMU context), but 
the benefits are often well worth this small penalty.  In addition, MMU 
support can be removed for the deployed product once the code stability 
has been ascertained.

>The moral of the story:  if you can afford the affects on determinism and
>you're in love with VM task protection, switch to Unix or a "real-time
>Unix" kernel.  MMUs, caches and the capabilities that come with them are
>handy, but not tailored for use in hard real-time applications.

Maybe true for Lynx or Venix (Unix-derived "real-time" operating systems), 
but it is absolutely possible to obtain the benefits of MMUs and caches 
tailored for real-time use without significant performance penalty.  
Indeed, I would suggest the true OS-like architecture of an OS-9 or QNX 
(versus the kernel/executive architecture of a VxWorks or pSOS) yields 
increasing overall system benefits as the sophistication of a product 
(I/O, GUI, etc.) increases, but that's a topic for another thread.

- -------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

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

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

From gkronent@madge.com  Sun Jan 26 07:24:09 1997
From: "Guy Kronental Ops-Tel" <gkronent@madge.com>
Date: Sun Jan 26 07:24:11 PST 1997
Subject: 82557 driver
Hi.
I am  working with vxWorks 5.3 and i960CA CPU.
I am in search of a driver for intel's 82557 chip (10/100M Ethernet 
Cntrl).
If anyone knows of a reliable driver I will be happy to hear about it.

Thanks GUY.

From froeber@bbn.com  Sun Jan 26 07:56:28 1997
From: Fred Roeber <froeber@bbn.com>
Date: Sun Jan 26 07:56:30 PST 1997
Subject: Re: non-interruptable bcopy
On Fri, 24 Jan 1997, Ted Morris wrote:

> Does anyone know if using the function, bcopy, memcpy, or even strcpy
> can actually be pre-empted during the copying operation internal to
> these functions?

There is no code in VxWorks to make these functions non-interruptable
as far as I know (version 5.2) and I can't imagine that any would be
added.  They are like any normal task code; they can be interrupted at
any point but will complete when the task resumes.

> At least in VxSIM 5.1 (sparc), doing something like strcat(buff, "bla
> bla bla") within a task that is pre-empted will always finish the
> operation of moving the data into buff.

Normal VxWorks running on a target processor doesn't work like this but
I guess I could imagine that certain critical functions would be
implemented as host function calls within the simulator causing them to
exhibit this behaviour.  Fred

   |     Fred J Roeber,  BBN Systems & Technologies     |
   |   4 John Clarke Road   Middletown, RI  02842-5202  |
   |         froeber@bbn.com     401-848-3548           |

From mcintosh@infinity.ccsi.com  Sun Jan 26 10:40:11 1997
From: Gordon McIntosh <mcintosh@infinity.ccsi.com>
Date: Sun Jan 26 10:40:13 PST 1997
Subject: Information on MCOS / VxWorks Interprocessor Communications timings
We are working on a project using Motorola MVME2604/200Mhx running a VxWorks
5.3 kernel and some Mercury Quad MPC603e/200MHz boards running MCOS.  

1. Are there timing numbers available for the interprocessor communications 
    between these two OS's ? 

2. Does anyone have timings on MCOS system calls and interprocessor 
    communications for a single quad board and multiple boards ?

3. Has anyone used the MCOS in a true multitasking implementation , and if
    so, how did it work out ?

4. Has anyone used MCOS MMU support, in particular the ability to have one
    tawk set protected pages up that are not mapped to all tasks ?

Any information on VxWorks interaction with MCOS would be appreciated.

Thanks in advance,

Gordon McIntosh
mcintosh@rtsd.com
http://www.rtsd.com

From adler@bnlku5.phy.bnl.gov  Sun Jan 26 22:19:37 1997
From: Stephen Adler <adler@bnlku5.phy.bnl.gov>
Date: Sun Jan 26 22:19:40 PST 1997
Subject: General discussion on Intrupts
Hi,

Im rather new at writing code in VxWorks and I find the documentation
on interupts rather sparce. I have an MVME1305, a 603 PPC. This
board had 3 buses, a local bus where the CPU and memory reside
(I can't remember its name), a PCI bus and a VME bus. I have
started writing software which deals with interupts and was
successful in actually getting the board to respond to an interupt
caused by the completion of a DMA transfer. So I've got the mechanics
of how to connect my Interupt Service Routine (ISR) to a vector
which is called when my interupt occurs. Now what I have no clue
is what vector and Interupt level I should use. It seems that I have
255 vectors to choose from to connect my ISR to and 7 interupt levels
to choose from. How do I find out which vectors are already taken
by other interupt routines? Does VxWorks reserve a range of interupt
vectors and levels which the developer, like me, should not use?
I chose vector number 16 off the top
of my head which does not seem to cause a conflict. (at least
on the little testing that I have done.) Choosing Interupt
level 1 or 7 doesn't seem to make a difference either. Since
this DMA transfer is the only real activity this board is
going to see, (beside the network activity which occures on a
PMC 100BaseT card) it shouldn't matter what IRQ level I choose.
Is there some unofficial or official way of chosing one's interupt
vector other than just take which ever one is not used? Do I have
to worry about interupts from my Network card which sits on the
PCI bus? Are the 255 interupt vectors also used by the PCI devices?
Do PCI devices share the same 7 Interupt levels too?

Another peculiarty I noiced. intConnect seems to add to a list
of ISR. If I call intConnect more than once, my ISR is called
the same number of times I called intConnect. This suggests
that multiple ISR's can be attached to the same vector. Is this
a feature or just a bug?

I would appriciate anyone's comments on these questions or any
suggestions on where I can find information which would address
the above questions.

Thanks in advance.

Steve Adler.

From conrad@ccii.co.za  Mon Jan 27 01:28:52 1997
From: Conrad Vermeulen <conrad@ccii.co.za>
Date: Mon Jan 27 01:28:54 PST 1997
Subject: IP Multicast
Hi

I was wondering if vxWorks supports the IP Multicast features?
I've been looking throught the header files, but have not found
anything...Any help would be appreciated.

Thanks
Conrad

-- 
Conrad Vermeulen                      email:conrad@ccii.co.za
CCII Systems (Pty) Ltd                http://www.ccii.co.za

From czvik@ocag.ch  Mon Jan 27 03:24:07 1997
From: czvik@ocag.ch (Michael Vikene )
Date: Mon Jan 27 03:24:09 PST 1997
Subject: Re: IP Multicast

please unsubscribe me

From daemon@csg.lbl.gov  Mon Jan 27 04:00:37 1997
From: daemon@csg.lbl.gov
Date: Mon Jan 27 04:00:40 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 27 04:00:34 PST 1997

        Subject: Re: Problem with dosFsLib in VxWorks 5.3?

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

Newsgroups: comp.os.vxworks
Subject: Re: Problem with dosFsLib in VxWorks 5.3?
Date: Fri, 24 Jan 1997 11:05:14 +0000
From: Gabriel Rouzaut <gabmrou@iies.es>
Organization: Engineering Institute of Spain
Message-ID: <32E8976A.1C2B@iies.es>
References: <Pine.GSO.3.95.970122093908.23454S-100000@lennon.qualcomm.com>

Andy Van Pelt wrote:
> 
>   We are having problems with the DOS filesystem after moving to VxWorks 5.3
> from 5.2.  The problems are *very* similar to problems we had initially
> with 5.2.  The fix for 5.2 was a patch from WindRiver for the dosFsLib.o.
> Does such a problem/patch exist in 5.3?  I have not been able to get a
> satisfactory answer from WRS.
> 
> The problem shows up as follows:
> 
>   We have an ftp script to transfer application files onto the 68k target from
> Solaris.  It runs just fine when the target is running 5.2.  Once we bring
> up a 5.3 kernel, we see the following:
> 
>   After we run the script once, if we run it again, it hangs.  After the
> script has hung, I can not use various commands on the target to access the
> disk (ls, rm).  The directory structure seems to be corrupted permanently at
> this point.  The only fix is to reinitialize (FIODISKINIT, dosFsMkfs) the
> disk.  If I remove some of the files from the ftp script, this doesn't
> happen.
> 
>   Also, when the slave cards boot up, they mount the disk using NFS.
> Subsequently, I get various problems reading/accessing the disk from the
> slaves.  When this happens, the master is hung.
> 

We had a similar problem when reloading to disk the vxWorks executable
and 
symbol table of the slave boards. As in your situation, the slave boads
boot
from disk of the master.

I don't know exactly the cause of this problem, but it has something to
do
with file descriptors open from the slave board over the vxWorks
executable 
on the master.

The way we have found to solve this problem was to stop vxWorks in the
slave
boards, before downloading to disk. It could be achieved reseting these
boards
and stoping the boot process.

Gabriel Rouzaut.

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

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

From czvik@ocag.ch  Mon Jan 27 05:31:20 1997
From: czvik@ocag.ch (Michael Vikene )
Date: Mon Jan 27 05:31:22 PST 1997
Subject: unsubscribe
please unsubscribe me

From tmorris@me.umn.edu  Mon Jan 27 08:08:16 1997
From: Ted Morris <tmorris@me.umn.edu>
Date: Mon Jan 27 08:08:18 PST 1997
Subject: RE:bcopy, memcpy, or even strcpy pre-emption

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

From bdswim@earth.usa.net  Mon Jan 27 08:40:06 1997
From: Bryce Swimley <bdswim@access.usa.net>
Date: Mon Jan 27 08:40:08 PST 1997
Subject: vxWorks Mouse Driver
Does anyone know of or have source code for a vxWorks serial mouse
driver?  We are using vxWorks 5.2 on a Motorola MV167.

Any insight or answers would be greatly appreciated!

TIA

-- 
Bryce D. Swimley
bdswim@usa.net

From rterry@cacihsv.com  Mon Jan 27 09:26:24 1997
From: "Russell M. Terry Jr." <rterry@cacihsv.com>
Date: Mon Jan 27 09:26:26 PST 1997
Subject: unsubscribe
unsubscribe
----------------------------------------------------
Russell M. Terry Jr.
CACI-ASG              Senior Systems Engineer
1555 The Boardwalk    InfraRed Sensor Systems
Huntsville, AL 35816  Embedded Systems
205.830.4782 x133,    Custom Hardware/Software
205.837.2086, fax     VME, VxWorks, SCSI

From greg.brissey@nmr.varian.com  Mon Jan 27 09:41:43 1997
From: greg.brissey@nmr.varian.com (Greg Brissey x6951)
Date: Mon Jan 27 09:41:45 PST 1997
Subject: Re: IP Multicast
> Subject: IP Multicast
> 
> Submitted-by conrad@ccii.co.za  Mon Jan 27 01:28:52 1997
> Submitted-by: Conrad Vermeulen <conrad@ccii.co.za>
>  
> Hi
> 
> I was wondering if vxWorks supports the IP Multicast features?
> I've been looking throught the header files, but have not found
> anything...Any help would be appreciated.
> 
> Thanks
> Conrad

 If memory serve me correctly, at the Wind River Users Conference it was said
that IP Multicast is scheduled to be supported in the April release of
Tornado 1.0.1

Greg Brissey
Varian NMR
greg.brissey@nmr.varian.com

From BARONK@HUB01.TDS-GN.LMCO.com  Mon Jan 27 13:36:59 1997
From: "Baron, Kenneth @ GRNK (LI-JUPITER DIRSYNC)" <BARONK@HUB01.TDS-GN.LMCO.com>
Date: Mon Jan 27 13:37:05 PST 1997
Subject: Problems with recursive code & logMsg
Duane,

Your solution to the logMsg problem has a problem.

The function that Magnus wants to use, cicsLogMessage() is a function
that will be called by more than one process. Therefore, if process A
calls this function and a task switch happens before completion of the
string copy and index increment, the interrupting task may then try to
call cicsLogMessage() and there will be a message collision. If you're
not to concerned about this possibility, you should at least increment
the index before calling logMsg().

Ken

Duane C Austin <dcaustin@pacbell.net> wrote the following:

M.Paterson@roe.ac.uk wrote:
> 
> All,
> 
> We're having some problems with logMsg, using VxWorks under EPICS.
> 

[snip...]

> Magnus
> 
> ****  Magnus J Paterson           email  mjp@roe.ac.uk
> ****  Royal Observatory           ph     +44 (0)131 668 8247
> ****  Edinburgh EH9 3HJ           fax    +44 (0)131 668 1130
> ****  SCOTLAND                    web    http://www.roe.ac.uk/mjpwww/

logMsg() is not fail safe... because it provides no means of notifying
you when it has displayed your message... so you never know when you can
re-use the buffer... For example if you had a high priority interrrupt
routine that was continually calling logMsg() it would never catch up...
but generally...

The important thing to remember is that what "message" points to cannot
change value until the logging system has had time to display the
message.

Based on your discription... It appears that you have 2 processes
sharing a global buffer (pointed to by message) hence your problem
because if process B writes the buffer before the message has been
logged it will log the message from B twice because logMsg() has only a
ptr to the message.

One solution is to have cicsLogMessage() copy the messages into a fifo
of messages and send the address of the message in the fifo to logMsg()
say...

cicsLogMessage(char* msg)
{
static char* fifo[10][40];
static int next=0;

strncpy(fifo[next],msg,40);
logMsg(fifo[next]);

if(++next>=10)next=0;	/* next location in fifo */
}

Good Luck

Duane Austin

From Scott.Peters@agai.com  Mon Jan 27 14:22:49 1997
From: Scott Peters <Scott.Peters@agai.com>
Date: Mon Jan 27 14:22:55 PST 1997
Subject: Is there a VxWorks for STD bus ?
Hello:
	Has anyone every seen an implementation of VxWorks for a STD bus? Does
one exist ?

Scott Peters
AG Associates
scott.peters@agai.com

From daemon@csg.lbl.gov  Tue Jan 28 04:00:58 1997
From: daemon@csg.lbl.gov
Date: Tue Jan 28 04:01:01 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 28 04:00:55 PST 1997

        Subject: Re: Application debugging with VxWorks ?

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

Newsgroups: comp.os.vxworks
Subject: Re: Application debugging with VxWorks ?
Date: 28 Jan 1997 03:32:24 GMT
From: steved@pacifier.com (Steve Doiel)
Organization: Pacifier BBS, Vancouver, Wa.  ((360) 693-0325)
Message-ID: <5cjs08$dra@news.pacifier.com>
References: <01bc0a0f$a6d64a20$f40348c1@s6415-l>

In article <01bc0a0f$a6d64a20$f40348c1@s6415-l>, agie@dial.eunet.ch says...
>
[snip]
>For what  has to do with debugging we 've found, as also clearly stated in
>the docs, that application or task mode debugging using CrossWind is
>possible only one task at a time.
>We feel this very limiting.
>
>Is this a limitation of the Tornado development environment, or of its
>Windows version ?
>
>Is it the same for the Unix version of Tornado ?
>
When I questioned WRS on this many months ago they said that debugging
multiple tasks was working on their UNIX version of Tornado.  There was
some indication that the ability to debug multiple tasks on NT might be
in the works, but I haven't talked to them since.

At the time they thought you could bring up two sessions of Tornado to
debug the separate task, but no one there had tried it.  Neither have I.

SteveD

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

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

From sergi@bpo.hp.com  Tue Jan 28 05:32:52 1997
From: Sergi Casas <sergi@bpo.hp.com>
Date: Tue Jan 28 05:33:02 PST 1997
Subject: Re: VXworks malloc behaviour
Gerardo Pardo-Castellote wrote:
> The problem with the Java garbage collector is that although it runs as
> the lowest priority task, as soon as it starts running, it promotes itself to
> the highest priority, and then runs to completion. I.e. it is not
> capable of doing "incremental" garbage collection. This makes it really
> unusable for real-time IMHO because even if you never exhaust the memory,
> every now and then, whenever the GC starts running it will lock up the
> system for an un-specified and un-controllable ammount of time. This
> yields the same behavior as the LISP GC that Sergi describes.

Yes, I completely agree. However, this is not a inherent failure of
Java to fulfil real-time requirements: the JVM Spec clearly leaves
the Garbage Collector implementation open to satisfy different needs
in different applications. What happens is that current Sun's implementation
is a typical mark-sweep algorithm that needs absolute control of the heap
during the process. As a consequence, current WindRiver's supplied 
implementation has the same flaw and, as they say in their Tornado for Java
literature, it is not suitable for hard real time. I'm pretty sure that
not only for real-time, but also for user interface responsiveness, Sun's
implementation is likely to change.

> My understanding is that the next release of Java will support incremental
> garbage collection... then, depending on the granularity of the "increments"
> it may stop being a problem as Sergi describes.

I think that in an interpreted JVM it should be very easy to split
the mark-sweep algorithm updating the "mark" traces at every object 
creation, reference, or assignment and then leaving to a background
process the "sweep" part of the algorithm. Hence the granularity of the
Garbage Collector would be *almost* that of each single free().

I guess it's something like this the reason for MachJ guys to claim they have
a real-time Garbage Collector.

h.j. bae wrote:
> i've been playing around with Boehm-Demers-Weiser conservative garbage
> collector  which allows incremental and generational garbage
> collection.  it requires MMU support though.  many java virtual
> machine -> C  compilers use this garbage collector.  available free:
> ftp://parcftp.xerox.com/pub/gc/gc.html

> i have been looking at the java stuff for some time now for embedded
> and realtime usage.  i've come to the conclusion that a JVM -> C
> compilation is the only way to go.

Thanks a lot for the pointer, it's a very interesting source about the topic.

On the other hand, while I agree on that  Java-byte-code-to-C static
(non JIT) compilation seems a very good way to go for embedded realtime, 
I don't really see the need to use such a complex Garbage Collector in
Java. It's being used 'cause it compiles to C and then they use a Garbage
Collector for C, but would be easier and much more efficient to take 
advantage of the byte-code-to-C compilation step to generate C code 
for "marking" during application execution time, and then doing the
"sweep" phase in background. No need for MMU. It is "incremental" instead
of "generational", with very high "granularity". The compiler has to be
a bit smarter, though.

All this becomes more difficult in native Java environments such as the
"nanoJava" cores from Sun, because there is no Virtual Machine interpreter
nor intermediate byte-code-to-C compiler, right ?

Cheers.
-- 

Sergi Casas 
Software Engineer  (R&D)
Hewlett-Packard Company

From RANDY@spock.amc.ualberta.ca  Tue Jan 28 07:24:36 1997
From: "Randy White" <randy@amc.ab.ca>
Date: Tue Jan 28 07:24:40 PST 1997
Subject: Re: Is there a VxWorks for STD bus ?
> Date:          Mon, 27 Jan 97 14:22:58 PST
> To:            vxworks_users@csg.lbl.gov
> From:          vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject:       Is there a VxWorks for STD bus ?

> Submitted-by Scott.Peters@agai.com  Mon Jan 27 14:22:49 1997
> Submitted-by: Scott Peters <Scott.Peters@agai.com>
>  
> Hello:
> 	Has anyone every seen an implementation of VxWorks for a STD bus? Does
> one exist ?
> 
> Scott Peters
> AG Associates
> scott.peters@agai.com
> 
If you use one of the PC compatible processor boards that are 
available for the STD bus, you can use the pc386 or pc486 BSPs.
They will run on anything that generally conforms to the PC I/O 
architecture.

Good luck

Randy White
Alberta Microelectronic Centre
#318, 11315 - 87 Ave.
Edmonton, AB
T6G 2T9
(403)492-3914
(403)492-1643 fax
randy@amc.ab.ca

From Phil_Watson@ns1.masirv.com  Tue Jan 28 09:41:37 1997
From: Phil_Watson@ns1.masirv.com (Phil Watson)
Date: Tue Jan 28 09:41:39 PST 1997
Subject: Re: comp.os.vxworks newsdigest
   Submitted-by daemon@csg.lbl.gov  Tue Jan 28 04:00:58 1997
   Submitted-by: daemon@csg.lbl.gov

   Comp.Os.Vxworks Daily Digest    Tue Jan 28 04:00:55 PST 1997

	   Subject: Re: Application debugging with VxWorks ?

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

   From: steved@pacifier.com (Steve Doiel)
   Organization: Pacifier BBS, Vancouver, Wa.  ((360) 693-0325)
   Message-ID: <5cjs08$dra@news.pacifier.com>
   References: <01bc0a0f$a6d64a20$f40348c1@s6415-l>

   In article <01bc0a0f$a6d64a20$f40348c1@s6415-l>, agie@dial.eunet.ch says...
   >
   [snip]
   >For what  has to do with debugging we 've found, as also clearly stated in
   >the docs, that application or task mode debugging using CrossWind is
   >possible only one task at a time.
   >We feel this very limiting.
   >
   >Is this a limitation of the Tornado development environment, or of its
   >Windows version ?
   >
   >Is it the same for the Unix version of Tornado ?
   >
   When I questioned WRS on this many months ago they said that debugging
   multiple tasks was working on their UNIX version of Tornado.  There was
   some indication that the ability to debug multiple tasks on NT might be
   in the works, but I haven't talked to them since.

   At the time they thought you could bring up two sessions of Tornado to
   debug the separate task, but no one there had tried it.  Neither have I.

At the WR User Group Conf last earlier this month, WRS folks (again)
said it is possible with Windows Tornado, using multiple sessions of
Tornado. (For UNIX only multiple Crosswind windows are necessary. I
have done this.) Some people claimed they have done it, but that it
was clumsy. WRS agreed, and added that item to the Wish List for
Tornado. 

----
Philip Watson
Telecommunications Lead

Phil_Watson@masirv.com
Matsushita Avionics Systems Corporation
15253 Bake Parkway
Irvine, California, 92618  U.S.A.
Ph: (714) 461-7300 (direct -7570)
Fx: (714) 462-7103

From cruz@xyplex.com  Tue Jan 28 10:40:33 1997
From: Roger Cruz <cruz@xyplex.com>
Date: Tue Jan 28 10:40:52 PST 1997
Subject: ROM Expansion card for PCs
I'm researching the use of VxWorks on a regular IBM-compatible PC for
an embedded application.  I understand that if I like to have VxWorks on
a ROM, I will need to get an expansion ROM card.  I'm wondering if
anyone has done something similar to this.  If so, can you give me
references to ROM card manufacturers (WRS mentions Blunk Microsystems)? 
Can they be Flash ROMs or only EPROMs?  What's the maximum size
allowed?  I assume these cards plug in to an ISA slot.  Correct?

 Another thought I had was to use the boot-rom sockets provided with NIC
cards.  Has anyone used this approach?  Is there enough space to hold
the boot code?  a VxWorks image?  The PCI spec also allows for expansion
roms, is there a card that has just a EPROM or flash ROM?

  Thanks in advance.

-- 
Roger Cruz         cruz@xyplex.com, rcruz@xyplex.com, rrc@xyplex.com
Whittaker Xyplex                                    w: 508-952-4783
295 Foster Street                                    f: 508-952-5772
Littleton, MA 01460

From chengg@mcgowan.ssd.loral.com  Tue Jan 28 14:39:26 1997
From: chengg@mcgowan.ssd.loral.com (Gary Cheng)
Date: Tue Jan 28 14:39:28 PST 1997

Hello:
 	Has anyone ever seen a device driver for Force Computer's 
SIO-2 (Serial I/O Board) under VxWorks5.3? Does one exist ?

Gary Cheng
Space System/Loral
chengg@mcgowan.ssd.loral.com

From bawilson@llnl.gov  Tue Jan 28 17:01:09 1997
From: Bruce Wilson <bawilson@llnl.gov>
Date: Tue Jan 28 17:01:11 PST 1997
Subject: mv160x IBC DMA
Is there someone who could help me with setting up DMA on the Motorola
MV1603 using the IBC DMA controller (Intel 82378ZB chip) ?  I'd like to DMA
synchronous SDLC packet input from serial port 4 into onboard RAM, and the
Programmer's Reference Guide from Motorola doesn't offer much advice.

--Bruce Wilson          (bawilson@llnl.gov)
University of California LLNL
Livermore, Calif.

From MikeMcQuade@connect.com  Tue Jan 28 21:47:29 1997
From: MikeMcQuade@connect.com
Date: Tue Jan 28 21:47:31 PST 1997
Subject: Re: mv160x IBC DMA
At 05:01 PM 1/28/97 PST, you wrote:
>Submitted-by bawilson@llnl.gov  Tue Jan 28 17:01:09 1997
>Submitted-by: Bruce Wilson <bawilson@llnl.gov>
> 
>Is there someone who could help me with setting up DMA on the Motorola
>MV1603 using the IBC DMA controller (Intel 82378ZB chip) ?  I'd like to DMA
>synchronous SDLC packet input from serial port 4 into onboard RAM, and the
>Programmer's Reference Guide from Motorola doesn't offer much advice.
>

Bruce,

Have your Motorola Rep get you a copy of the Intel 82378 data book, this book,
although not the best data book, describes the DMA functions of the chip.

I can email you the Intel part number from the book if you like.

From daemon@csg.lbl.gov  Wed Jan 29 04:00:12 1997
From: daemon@csg.lbl.gov
Date: Wed Jan 29 04:00:14 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 29 04:00:10 PST 1997

        Subject: Fast TCP for 5.2

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

Newsgroups: comp.os.vxworks
Subject: Fast TCP for 5.2
Date: 28 Jan 1997 19:59:31 GMT
From: alexmi@ash.tv.tek.com (Alex Mitaru)
Organization: Tektronix Video / Networking Products
Message-ID: <5cllr3$cqp@bvadm.tek.com>

  Hello, I have a vxWorks 5.2 networking question. The networking code in 5.2
  is BSD code from '91-'92. Since then, the BSD code has evolved  quite a lot,
  adding things like IP multicast and performance improvements defined in
  RFC 1323 (32 bits TCP window size, etc...). Has anyone tried to port 
  current BSD code (with all the goodies) to vxWorks 5.2? We are very 
  interested, 'cause we need a fast TCP, and 16 bits window size limits
  performance quite significantly.
  
  I would appreciate any words of wisdom...

  thanks, alex

- --
 Alexandru Mitaru
 Principal Engineer       alexmi@vnd.tek.com
 Tektronix, Inc.          (503) 627-6094

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

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

From leonid@wrs.co.il  Wed Jan 29 04:20:15 1997
From: leonid@wrs.co.il (Leonid Rosenboim)
Date: Wed Jan 29 04:20:19 PST 1997
Subject: FYI - RST Software Industries Ltd.
Dear VxWorkers,

The company I have been working for previously - RST, has been recently
acquired by Wind River Systems. For more details see the press release
at http://www.businesswire.com/cnn/wind.htm

For products previously offered by RST, please contact your local WRS
sales rep. Note also the change ofour e-mail address.
-----------------------------------------------------------------------
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

From jromine@phbtsus.com  Wed Jan 29 14:21:51 1997
From: JEFF ROMINE <jromine@phbtsus.com>
Date: Wed Jan 29 14:21:57 PST 1997
Subject: Re: comp.os.vxworks newsdigest
the vxWorks Users Group Exploder wrote:
> 
> Submitted-by daemon@csg.lbl.gov  Wed Jan 29 04:00:12 1997
> Submitted-by: daemon@csg.lbl.gov
> 
> Comp.Os.Vxworks Daily Digest    Wed Jan 29 04:00:10 PST 1997
> 
>         Subject: Fast TCP for 5.2
> 
> -------------------------------------------------------
> 
> Newsgroups: comp.os.vxworks
> Subject: Fast TCP for 5.2
> Date: 28 Jan 1997 19:59:31 GMT
> From: alexmi@ash.tv.tek.com (Alex Mitaru)
> Organization: Tektronix Video / Networking Products
> Message-ID: <5cllr3$cqp@bvadm.tek.com>
> 
>   Hello, I have a vxWorks 5.2 networking question. The networking code in 5.2
>   is BSD code from '91-'92. Since then, the BSD code has evolved  quite a lot,
>   adding things like IP multicast and performance improvements defined in
>   RFC 1323 (32 bits TCP window size, etc...). Has anyone tried to port
>   current BSD code (with all the goodies) to vxWorks 5.2? We are very
>   interested, 'cause we need a fast TCP, and 16 bits window size limits
>   performance quite significantly.
> 
>   I would appreciate any words of wisdom...
> 
>   thanks, alex
> 
> - --

Alex,

We just had Wind River out here hawking Tornado and they indicated that
they
would have a more up to date TCP/IP stack when Tornado 1.01 is released
(March?).  It sounded like they are planning to do just what you are
requesting, i.e. update to a more current version of the BSD code, and
multicasting was
one of the features on the list.  However, I would guess that they have
no 
plans to retro-fit it to 5.2.  You might also look into FUSION from
Pacific
Softworks (www.pacificsw.com, (805) 484-2128).  I would be interested to
know
if anyone has done a port of the Pacific Softworks stuff to VxWorks,
noone had
last time I checked.  Good Luck.

-Jeff Romine

From mea@mclean.sparta.com  Wed Jan 29 16:13:30 1997
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed Jan 29 16:13:33 PST 1997
Subject: VMetro Midas Experience
Greetings!

  Has anyone in netland used the VMetro Midas PMC carrier board (like
the Midas-20) in a VxWorks environmnet?  I'd be interested in hearing
and praise/horror stories.

Regards,

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

From daemon@csg.lbl.gov  Thu Jan 30 04:00:30 1997
From: daemon@csg.lbl.gov
Date: Thu Jan 30 04:08:56 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 30 04:00:28 PST 1997

        Subject: Re: serial port with vx
        Subject: Proxy Arp Server
        Subject: Survey: Sound Support for VxWorks
        Subject: Text on software development for PPC 604
        Subject: Newbie: Basic Sample Code
        Subject: suscribe
        Subject: Re: vxWorks Mouse Driver
        Subject: Re: Real Time Trace on embedded PowerPC
        Subject: Re: ICE vs Target Monirtors for PPC
        Subject: Re: Problem with dosFsLib in VxWorks 5.3?

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

Newsgroups: comp.os.vxworks
Subject: Re: serial port with vx
Date: Wed, 29 Jan 1997 12:19:04 -0800
From: Graham Waters <waters@triumf.ca>
Organization: TRIUMF
Message-ID: <32EFB0B8.3403@triumf.ca>
References: <32EF0925.2749@ensieta.fr>

Jean-Luc Fleureau PERS wrote:
> 
> 
> I have found in the target directory a file file named mv162.h, where a
> define defines (of course) the number of serial channels.
>	in file mv162.h "#define N_SIO_CHANNELS 4" should be all you need do. It
	worked for me.

> 
> I have supposed, and I have tried to recompile the application
> with the command "make" in the target directory and the result is :
> 
> cpp: Invalid option `-lang-c' <===WHAT IS THAT ERROR ?????

	You don't need this and I don't think it is a valid
	gcc option ( -xc works )

> as: error: unknown option 'm' <== ANd these others ?????
> as: error: unknown option '6'
> as: error: unknown option '8'
> as: error: unknown option '0'
> as: error: unknown option '4'
> as: error: unknown option '0'

	cc68k should use the cross-assemble version of 'as' located
	somewhere like ...../gcc-lib/m68k-wrs-vxworks/cygnus-2.2.3

	I think you will find the native assemble is being called.
	Try running cc68k with the verbose flag '-v' and take a look.
	Also check the GCC_EXEC_PREFIX environment variable

+-----------------------------------------------------------------------+
| Graham Waters, Control System Eng          Internet: waters@triumf.ca |
| TRIUMF --- University of British Columbia,	phone: (604)-222-1047   |
| Vancouver, BC, Canada                           Fax: (604)-222-7307   |
|                                                http://www.triumf.ca   |
+-----------------------------------------------------------------------+

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

Newsgroups: comp.os.vxworks
Subject: Proxy Arp Server
Date: 28 Jan 1997 06:11:56 GMT
From: ashrafis@nt.com (Siamak Razzaghe-Ashrafi)
Organization: Northern Telecom Inc., Mission Park
Message-ID: <5ck5bc$i0n@nrchh52.rich.nt.com>

Is there a way to run a proxy arp server without having the shared memory
in the same address space as the main network.

Thankx

ashrafis@nt.com

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

Newsgroups: comp.os.vxworks
Subject: Survey: Sound Support for VxWorks
Date: 28 Jan 1997 03:07:16 GMT
From: front@nntp.best.com (4Front Technologies)
Message-ID: <5cjqh4$gh6@nntp1.best.com>

This is just a survey to find out what are the market requirements for
digital audio and MIDI support in VxWorks. 4Front Technologies has
developed a cross-platform audio architecture called Open Sound System.
OSS runs on Linux, AIX, Solaris x86, SCO UNIX, UnixWare, Solaris Sparc and
BSD. OSS provides device drivers for over a hundred different brandname
soundcards and audio chipsets like Sound Blaster, Ensoniq, Turtle Beach
OPTi, Crystal Semiconductor and ESS Technology.

We are planning to develop Open Sound System for VxWorks and wanted to
know if there is a demand or not.

For more information on Open Sound System please visit
http://www.4front-tech.com.

Best regards,
Dev Mazumdar
4Front Technologies
dev@4front-tech.com

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

Newsgroups: comp.sys.powerpc.tech,comp.sys.powerpc.misc,comp.os.vxworks
Subject: Text on software development for PPC 604
Date: Tue, 28 Jan 1997 15:47:12 -0500
From: David Rourke <dar@swl.msd.ray.com>
Organization: Raytheon Electronic Systems
Message-ID: <32EE65D0.41C67EA6@swl.msd.ray.com>

Hi all,

I need a recommendation for a good text on code development for the
PowerPC 604.  I am particularly interested in optimization for speed. 
My target is a Motorola MVME2604 running Tornado 1.0 using the GNU C
compiler.

Thanks in advance,
dave

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

Newsgroups: comp.os.vxworks
Subject: Newbie: Basic Sample Code
Date: Tue, 28 Jan 1997 17:04:53 -0500
From: Felix Duong <f_duong@ece.concordia.ca>
Organization: ECE - Concordia University
Message-ID: <32EE7805.41C67EA6@ece.concordia.ca>

Hello all.  I there is anyone who knows or posses code that
can give me a explanation on how to set up tasks, run task and
such (the basic stuff), send it to me or email me the location of
 the ftp site.

You see, I'm a university student and have access to VxWorks (new!
this year! in Real time sys course), but... unfortunately
the only manuals are the one's the prof has.  He's trying to see
if the class can photocopy the programmer's guide.  'til then 
I either have to wade through the online manuals or do my assignments in
Ada (joy joy joy....;)

I checked out the FAQ and check the ftp site that is listed there
but the code located here is way to advance for my tastes...
I just need some simple examples of how to set up tasks, send 
messages etc... basic stuff. BTW the ftp site is wrong.  If
you ftp to that site it'll tell you where to ftp to for the 
files (see, I don't remember what the addr was).

Right enough of my babbling... thanks.

felix

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

Newsgroups: comp.os.vxworks
Subject: suscribe
Date: Wed, 29 Jan 1997 14:54:08 +0200
From: Eli Eliezer <elie@vsoft.co.il>
Organization: Vsoft Ltd.
Message-ID: <32EF4870.576F@vsoft.co.il>

subscribe

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

Newsgroups: comp.os.vxworks
Subject: Re: vxWorks Mouse Driver
Date: 29 Jan 1997 02:57:02 -0800
From: mcs@goblin.caltech.edu (Martin Shepherd)
Organization: California Institute of Technology.
Message-ID: <yc9u3o0lpfl.fsf@goblin.caltech.edu>
References: <199701271640.JAA12597@earth.usa.net>

In article <199701271640.JAA12597@earth.usa.net> Bryce Swimley <bdswim@access.usa.net> writes:
>Does anyone know of or have source code for a vxWorks serial mouse
>driver?  We are using vxWorks 5.2 on a Motorola MV167.
>
>Any insight or answers would be greatly appreciated!

The following outline of how to communicate with a mouse assumes
that you are using a Microsoft-format 2-button serial mouse that is
plugged into one of the serial ports of a MVME167 P2-adapter.

- -----------------------------------------------------------------------
#include <stdio.h>
#include <errno.h>
#include <vxWorks.h>
#include <ioLib.h>

#define MOUSE_SERIAL_PORT "/tyCo/3"
#define MOUSE_MESSAGE_LEN 3     /* Each mouse message is 3-bytes long */

/*
 * I haven't actually tested the following example function, but it
 * is derived from well tested code that I do use, so it ought to be ok.
 * All the function does is open a connection to the mouse and
 * thereafter report the details of every mouse message that it
 * receives. I don't currently have a VME crate set up to test it, but
 * if it doesn't work, tell me and I'll try to find time to set up
 * a test.
 */
int mouse_reader(void)
{
  unsigned char message[MOUSE_MESSAGE_LEN]; /* The read buffer */
  int nbyte = 0;        /* The number of bytes currently in message[] */
  int fd;               /* The mouse serial port fd */
  unsigned char byte;   /* The latest mouse byte read */
  int nread;            /* The latest number of bytes read */
/*
 * Open a connection to the mouse.
 */
  fd = open(MOUSE_SERIAL_PORT, O_RDWR, 0644);
  if(fd < 0) {
    perror("Error opening " MOUSE_SERIAL_PORT);
    return 1;
  };
/*
 * Set the serial port up for raw terminal-I/O at 1200 baud.
 * Also reduce the read buffer size to prevent the mouse reader
 * function from being kept behind by too many historical mouse events.
 * It doesn't matter if we miss a few events and the mouse reader has
 * enough information to discard truncated messages.
 */
  if(ioctl(fd, FIOSETOPTIONS, OPT_RAW) ||
     ioctl(fd, FIOBAUDRATE, 1200) ||
     ioctl(fd, FIOFLUSH, 0) ||
     ioctl(fd, FIORBUFSET, 30)) {
    perror("Mouse serial-port ioctl()");
    return 1;
  };
/*
 * Read and interpret bytes as they become available on the
 * mouse serial port.
 */
  while((nread=read(fd, &byte, 1)) == 1) {
/*
 * The Microsoft mouse format specifies that only the first byte of each
 * three-byte event will have its 7th msb set. Use this to synchronize.
 * This is how truncated messages are discarded.
 */
    if(byte & 1<<6)
      nbyte = 0;
    message[nbyte++] = byte;
/*
 * Once MOUSE_MESSAGE_LEN contiguous bytes have been received,
 * decompose and interpret the event.
 */
    if(nbyte >= MOUSE_MESSAGE_LEN) {
      unsigned char dx;   /* The horizontal distance that the mouse moved */
      unsigned char dy;   /* The vertical distance that the mouse moved */
/*
 * Decode and report the state of the mouse buttons.
 */
      printf("The left and right buttons are %s and %s respectively.\n",
	     (message[0] & 1<<5) ? "down":"up",
	     (message[0] & 1<<4) ? "down":"up");
/*
 * Decode and report the distance that the mouse has moved
 * since the last event was received. Distances are measured
 * in "mouse pixels". I don't remember what physical distance
 * one mouse pixel corresponds to.
 */
      dx = ((message[0] & 03) << 06) | (message[1] & 077);
      dy = ((message[0] & 014) << 04) | (message[2] & 077);

      printf("The mouse moved by x=%d and y=%d pixels.\n",
	     *((signed char *)&dx), *((signed char *)&dy));
/*
 * Prepare the read buffer for the next mouse message.
 */
      nbyte = 0;
    };
  };
/*
 * Close the serial port.
 */
  close(fd);
/*
 * Report read errors.
 */
  if(nread < 0) {
    perror("Mouse read error");
    return 1;
  } else {
    fprintf(stderr, "Mouse serial port closed.\n");
    return 1;
  }
  return 0;
}

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

Newsgroups: comp.realtime,comp.sys.powerpc.tech,comp.os.vxworks
Subject: Re: Real Time Trace on embedded PowerPC
Date: Tue, 28 Jan 1997 06:08:48 -0500
From: Rich Wells <rjwells@vnet.ibm.com>
Organization: IBM Microelectronics Division
Message-ID: <32EDDE40.15FB@vnet.ibm.com>
References: <32EC0A55.449D@ozemail.com.au>

Andrew Kelly wrote:
> 
> I understand the IBM 403 mpu provides a secondary debug port that
> provides enough info about the instruction progression through the
> instruction cache to provide real-tim-trace functionality via a probe
> and some external decoding software.  Is this facility available on
> the Motorola 800 series?

Andrew,
   The real-time trace facility you mentioned is only available on
certain processors within the IBM 400 Series PowerPC chips. The
software used for obtaining trace data is called RISCTrace and
is part of the RISCWatch debugger for PowerPC.

- -- 
Rich Wells
IBM Microelectronics Division
PowerPC Embedded Development
rjwells@vnet.ibm.com

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

Newsgroups: comp.arch.embedded,comp.os.vxworks,comp.realtime
Subject: Re: ICE vs Target Monirtors for PPC
Date: Wed, 29 Jan 1997 10:03:59 -0500
From: "Daniel T. Conklin" <dconklin@atl.lmco.com>
Organization: Lockheed Martin Advanced Technology Laboratories
Message-ID: <32EF66DF.78A4@atl.lmco.com>
References: <32DF83E4.6CC6@ozemail.com.au> <32DFF408.41C67EA6@wrs.com>

Lew,
	A discussion about BDM from newsgroup comp.realtime...

Benjamin Skrainka wrote:
> 
> Comrades:
> 
> Andrew Kelly wrote:
> 
> > Biggest issue in the decision at the moment is that of In Circuit
> > Emulators and Real-Time-Trace functionality.  Apex provides debugging
> > support via the Tornado API to a software monitor running in the target
> > with VxWorks.  As far as I can discern, Tornado has no ICE capability,
> > it is purely a host-monitor/target-monitor debugging capability.  MULTI,
> > on the other hand, has integrated support for some In Circuit Emulator
> > hardware (I am awaiting a response from sales people about which ones
> > in particular) in addition to JTAG, OnCE and the Host/Remote Software
> > Monitor.
> 
> One of the design aims of Tornado was to make it very easy to support
> hardware debug tools.  This support is easy to provide
> by writing or obtain the appropriate back end for Torando.
> The back end is a DLL (or shared object) that allows the
> target server, and thus all tools which are integrated
> with Tornado, to provide debug services via an emulator.
> Several vendors, like EST, Abatron, Lauterbach, and etc.
> have developed back ends for Tornado.
> 
> If you need to develop a back end, you should obtain
> the Back End Developer's Kit by sending email to
> bedk@wrs.com.  The BEDK is a C++ class
> library which eliminates alot of the work involved in
> writing a back end.
> 
> There is a growing trend toward "scalable" debug
> hardware, separating the trace and run-control functionality.
> This makes debug hardware much less expensive.  E.g.,
> it is now possible to purchase simple debug boxes, which
> provide run-control via BDM/JTAG, for a few $k.  If you
> need other functionality, you can then purchase the
> extra modules separately, only paying for what you need.
> Or, get several boxes with run-control and only a few
> with trace capability.  The allows more engineers to have
> access to better tools.
> 
> > Unfortunately, we come at this project as newcomers to the PowerPC
> > market and are unsure of the importance of the close access to the
> > hardware that ICEs provide, versus Remote Monitor debugging.  Given that
> > it *may* be important for us to start twiddling instruction and
> > data cache constraints to produce deterministic performance for
> > selected code segments and such-like, what sort of functionality
> > are we likely to get from the software monitor alone?  And is the
> > Monitor capability going to be enough for our needs?
> 
> It depends on your needs.  To develop an application,
> you will probably find the WDB agent sufficient for most tasks.
> The agent also allows you to debug ISRs.  However, if you
> need to write a BSP, you will find the extra power of
> an emulator will save you a lot of time.  (By "emulator",
> I mean an ICE or a BDM/JTAG style debug box.  With PPC,
> you should consider the BDM route because BDM boxes are
> much less expensive than ICEs.)
> 
> Several vendors (EST, Applied, Abatron, etc.) have or
> have almost completed PPC 8xx emulator back ends.
> 
> Best Wishes,
> 
> --
> Ben
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Benjamin S. Skrainka                   Wind River Systems
> Development Engineer                   1010 Atlantic Avenue
> benjamin.skrainka@wrs.com              Alameda, CA 94501-1147
>                                        voice     510.814.2147
> http://www.wrs.com/                    facsimile 510.814.2560
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	
- -- 
Daniel Conklin           | Lockheed Martin
dconklin@atl.lmco.com    | Advanced Technology Labs
609-338-3894 (Fax: 4144) | 1 Federal St. A&E-3W
                         | Camden, NJ 08102

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

Newsgroups: comp.os.vxworks
Subject: Re: Problem with dosFsLib in VxWorks 5.3?
Date: Wed, 29 Jan 1997 23:52:39 -0800
From: John Kevin Fabiani <johnx@wrs.com>
Organization: Wind River Systems
Message-ID: <32F05347.123@wrs.com>
References: <Pine.GSO.3.95.970122093908.23454S-100000@lennon.qualcomm.com> <Pine.GSO.3.95.970129094433.12653g-100000@lennon.qualcomm.com>
Reply-To: johnx@wrs.com

Andy Van Pelt wrote:
> 
>   I just received a patch for 5.3 from a helpful Mr. Fabiani from Wind River
> Systems.  I was also able to work around this by using the 5.2 patch.

Thanks Andy.  This patch _will_ be in the next release.

John

> 
>   Thanks John!
> 
> On Thu, 23 Jan 1997, Andy Van Pelt wrote:
> 
> >   We are having problems with the DOS filesystem after moving to VxWorks 5.3
> > from 5.2.  The problems are *very* similar to problems we had initially
> > with 5.2.  The fix for 5.2 was a patch from WindRiver for the dosFsLib.o.
> > Does such a problem/patch exist in 5.3?  I have not been able to get a
> > satisfactory answer from WRS.
> >
> > The problem shows up as follows:
> >
> >   We have an ftp script to transfer application files onto the 68k target from
> > Solaris.  It runs just fine when the target is running 5.2.  Once we bring
> > up a 5.3 kernel, we see the following:
> >
> >   After we run the script once, if we run it again, it hangs.  After the
> > script has hung, I can not use various commands on the target to access the
> > disk (ls, rm).  The directory structure seems to be corrupted permanently at
> > this point.  The only fix is to reinitialize (FIODISKINIT, dosFsMkfs) the
> > disk.  If I remove some of the files from the ftp script, this doesn't
> > happen.
> >
> >   Also, when the slave cards boot up, they mount the disk using NFS.
> > Subsequently, I get various problems reading/accessing the disk from the
> > slaves.  When this happens, the master is hung.
> >
> >   In both cases, after the ftp/slave hangs, an 'ls' on the master will hang,
> > and breaking out of it will display the following traceback:
> >
> >  56642 _vxTaskEntry   +10 : _shell (&TRUE, 0, 0, 0, 0, 0, 0, 0, 0, 0)
> >  16c1a _shell         +12e: 16c38 ([&TRUE, 0, 3, 7f, 0])
> >  16db6 _shell         +2ca: _execute ([5ea67e2, &TRUE, 0, &_ioGlobalStdGet, 6c6c])
> >  16ed2 _execute       +a4 : _yyparse ([5ea67e2, 0, &TRUE, 0, 5ea67e2])
> >  607f8 _yyparse       +542: 5f1bc (5ea8474, 5ea8494)
> >  5f2c6 _yystart       +72e: _ll (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
> >  4538e _ll            +c  : _ls ([0, &TRUE, 5ea6750, 5f2c8, 0])
> >  451fc _ls            +4a : _opendir ([44d64, &_yyval, 3, 3, &TRUE])
> >  12aae _opendir       +e  : _open ([44d64, 0, 0, &_yyval, 5fd56c4])
> >  14866 _open          +7e : _iosOpen ([5fc7db8, 5ea6398, 0, 0, &_yyval])
> >  3969c _iosOpen       +30 : _semMTake ([5fc7db8, 5ea6398, 0, 0, 5ea6498])
> >
> >
> > Configuration: MV177-004 (68060), Motorola SCSI disk, Solaris 2.5 running on
> > Sparc
> >
> >   Has anybody seen anything like this?  Any suggestions for how to track this
> > down, or, better yet, fix it?  Can the fixed dosFsLib.o from 5.2 be used when
> > linking the 5.3 kernel?
> >
> > --
> > Andy Van Pelt                              Internet: avanpelt@qualcomm.com
> 
> --
> Andy Van Pelt                              Internet: avanpelt@qualcomm.com
> QUALCOMM Inc.                              Work    : 619) 658-3214

- -- 
Respectfully,

John Kevin Fabiani
Technical Support Engineer
Wind River Systems

(510) 814-2167 
(510) 814-2010 Fax
(800) 872-4977

johnx@wrs.com
support@wrs.com
I2O_Support@wrs.com (I2O only)
http://www.wrs.com

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

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

From conrad@ccii.co.za  Thu Jan 30 06:56:41 1997
From: Conrad Vermeulen <conrad@ccii.co.za>
Date: Thu Jan 30 06:56:43 PST 1997
Subject: STREAMS put
Hi

I'm busy porting a STREAMS driver to vxWorks. There is a reference to
the STREAMS 'put' command. Under vxWorks, this is unresolved...
According to the Solaris man pages this should call the driver's or
module's put procedure... Is there a graceful way of doing this using
the streamtab structure maybe? or should I explicitly replace put
with xxx_put? any help would be appreciated.

Thanks
Conrad

-- 
Conrad Vermeulen                      email:conrad@ccii.co.za
CCII Systems (Pty) Ltd                http://www.ccii.co.za

From chuckvb@juno.com  Thu Jan 30 10:32:24 1997
From: chuckvb@juno.com (Chuck J Van Blaricom)
Date: Thu Jan 30 10:32:26 PST 1997
Subject: Disappearing Text
Has anybody else experienced this problem?

We recently installed Tornado 1.0 on Windows NT 4.0.  While editing a
Source File, inserting "Tabs" and "Spaces" in various combinations within
the middle of a line causes text to disappear at the end of the line. 
The text is still there, it just doesn't show in the editor.  If I delete
the "Tabs", the text comes back.

I have talked with Wind River about this and they wrote a TSR for it.  I
find it hard to believe that something as basic as a text editor has
problems.  Could this be a Windows NT problem?  Has anyone else
expreienced these problems?

Thanks in Advanced!

Chuck Van Blaricom
Communication Network System
2525 Walsh Ave, Santa Clara, CA 95051
(408) 235-7039    FAX: (408) 235-7085
EMail: chuckvb@juno.com

From sng@eng.kns.com  Thu Jan 30 12:04:08 1997
From: sng@eng.kns.com (Susan Ng)
Date: Thu Jan 30 12:04:11 PST 1997
Subject: unsubscribe
unsubscribe

-------------------------------------------------------------------------------
						Susan Ng
E-mail:      sng@kns.com			Senior Software Engineer
Phone:	     (215) 784-6733			Kulicke & Soffa Industries Inc
Fax:	     (215) 659-7588			2101 Blair Mill Road,
						Willow Grove, PA 19090
-------------------------------------------------------------------------------

From adamakis@sundevil.nosc.mil  Thu Jan 30 13:54:08 1997
From: "Michael Adamakis" <adamakis@sundevil.nosc.mil>
Date: Thu Jan 30 13:54:10 PST 1997
Subject: Re: Disappearing Text
I use Tornado 1.0 under Windows95 and occasionally have a similar problem.  I
have not noticed if it's a tabs/spaces thing or not but it's likely because it
usually happens when I go through a file and change comments and alignments.  I
usually get garbage on the screen.  EX: If I change from a C "/**/" comment to
a "//" comment, I'd end up with "/*" down the left side of the screen or "*/"
down the right side of the screen.  As this has only happened a couple of times
in the 3 or 4 months I've been using Tornado I did not really think much of it
(assuming it was just another of Microsoft's "undocumented features" of
Windows95).

> Has anybody else experienced this problem?
>
> We recently installed Tornado 1.0 on Windows NT 4.0.  While editing a
> Source File, inserting "Tabs" and "Spaces" in various combinations within
> the middle of a line causes text to disappear at the end of the line.
> The text is still there, it just doesn't show in the editor.  If I delete
> the "Tabs", the text comes back.
>
> I have talked with Wind River about this and they wrote a TSR for it.  I
> find it hard to believe that something as basic as a text editor has
> problems.  Could this be a Windows NT problem?  Has anyone else
> expreienced these problems?
>
> Thanks in Advanced!
>
> Chuck Van Blaricom
> Communication Network System
> 2525 Walsh Ave, Santa Clara, CA 95051
> (408) 235-7039    FAX: (408) 235-7085
> EMail: chuckvb@juno.com

-- 
Mike Adamakis
KOAM Engineering Systems
3725 Talbot St. Suite 1
San Diego, CA 92106
(619)224-9794 (office)
(619)224-9795 (FAX)
adamakis@nosc.mil

From espin@idiom.com  Thu Jan 30 14:56:18 1997
From: Geoffrey Espin <espin@idiom.com>
Date: Thu Jan 30 14:56:19 PST 1997
Subject: Re: Disappearing Text
Chuck,

> Source File, inserting "Tabs" and "Spaces" in various combinations within
> the middle of a line causes text to disappear at the end of the line. 
> The text is still there, it just doesn't show in the editor.  If I delete
> the "Tabs", the text comes back.

It does scroll the text to the right.  If you move your cursor or
mouse-pointer to the right edge the text will start appearing.  Likewise
you can end up with the editor be essentially "right justified" so that you
wonder what happened to the code at the beginning of the line.

If you're used to a 'vi' type editor, I highly recommend
Lemmy's at www.windows95.com.  You can get Emacs and
many other shareware editors too... you just can't have them
automatically fired up by Tornado.  At least, accordint to one WRS
person.

Fixed in the next release?????   :-)

Geoff
-- 
Geoffrey Espin espin@idiom.com

From radha@india.ti.com  Thu Jan 30 19:25:49 1997
From: RadhaKrishna <radha@india.ti.com>
Date: Thu Jan 30 19:25:51 PST 1997
Subject: unsubscribe
unsubscribe

From Ricky.D.Graves@jpl.nasa.gov  Thu Jan 30 20:20:15 1997
From: Ricky D Graves <Ricky.D.Graves@jpl.nasa.gov>
Date: Thu Jan 30 20:20:17 PST 1997
Subject: Heurikon V3F load Errors

I am running Vxworks 5.0.2B on Heurikon HK68 V3Fs.  The cards are setup to boot 
over thinet from a Sparc 20 (OS 4.14) workstation.   I have three Heurikons 
executing very similar startup scripts.  I am seeing the same load error on both  
Heurikons when the timing lines up just right and the cards are  attempting to 
load the same file simultaneously. If I change the power up sequence to skew the 
timing or boot one chassis at a time I don't get the error.  The usr is set as 
root on this particular system if that makes any difference.

If anybody can help please let me know ASAP

Thanks,

Rick Graves 

From conrad@ccii.co.za  Fri Jan 31 03:37:14 1997
From: Conrad Vermeulen <conrad@ccii.co.za>
Date: Fri Jan 31 03:37:17 PST 1997
Subject: ethernet drivers
Hi there

Under Solaris one can access drivers by opening a device, like:
  fp = open("/dev/le0",..)

By calling "devs" under vxWorks, I did not see any suitable drivers
available, but I know that the ene interface is active upon startup.
Can I open them as under Solaris? Do the ethernet drivers under
vxWorks support the DLPI 2.0 interface?

thanks
Conrad

-- 
Conrad Vermeulen                      email:conrad@ccii.co.za
CCII Systems (Pty) Ltd                http://www.ccii.co.za

From daemon@csg.lbl.gov  Fri Jan 31 04:00:15 1997
From: daemon@csg.lbl.gov
Date: Fri Jan 31 04:00:21 PST 1997
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 31 04:00:13 PST 1997

        Subject: Re: Is there a VxWorks for STD bus ?
        Subject: Re: OSI TRANSPORT layer
        Subject: invisible static variables
        Subject: Re: Help : How to incorporate Rogue Wave Class Library into VxWork Load
        Subject: Re: invisible static variables: never mind
        Subject: Complete Canon P133 Computer System
        Subject: Console on COM3 on MVME1603??
        Subject: Device Driver's Class
        Subject: serial port with vx
        Subject: Re: Text on software development for PPC 604
        Subject: MV1603 SCSI and VME RAM
        Subject: EtherExpress Pro 100
        Subject: How to debug: Operation Fault 0x2

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

Newsgroups: comp.os.vxworks
Subject: Re: Is there a VxWorks for STD bus ?
Date: Wed, 29 Jan 1997 12:44:04 -0600
From: Bob Tadlock <btadlock@ti.com>
Organization: Texas Instruments
Message-ID: <32EF9A74.ABD322C@ti.com>
References: <c=US%a=_%p=AG_Associates%l=AGASSOCIAT/HQ/0000C72F@raptor.agai.com> <32EE68EA.5B3@falcon.kla.com>

Christopher Pinkard wrote:
> 
> Scott Peters wrote:
> >
> > Hello:
> >         Has anyone every seen an implementation of VxWorks for a STD bus? Does
> > one exist ?
> >
> 
> Try Ziatech down in San Luis Obispo.  They've got x86 vxworks on
> std32 boards.
> 
> c__

yes , Ive written alot of extensions for vxWorks on the Ziatech STD32
platform.  
I load the vxworks bootrom in the onboard flash and boot
from it and a few other custom mods and device drivers.

- -- 
Bob Tadlock                    btadlock@ti.com
Texas Instruments              MSGID BST2
8390 LBJ Freeway, MS 3659      Voice: (972) 927-5624
Dallas, TX 75243               Fax:   (972) 927-6564
Disclaimer - I do not speak for TI.

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

Newsgroups: comp.os.vxworks
Subject: Re: OSI TRANSPORT layer
Date: Wed, 29 Jan 1997 22:47:13 GMT
From: ralph@sisconet.com (Ralph M)
Organization: SISCO, Inc.
Message-ID: <5cok29$qui@krypto.zippo.com>
References: <5bgeev$3ai@ilex.FernUni-Hagen.de>

q3931234@bonsai.fernuni-hagen.de wrote:

>How do I get an implementation of the OSI transport layer for VxWorks?

>Tanks in advance

Check out Marben Products. They are headquartered in France.
I think their web address is: http://www.marben.com

Best Regards,
Ralph M.
SISCO, Inc.
Providers of Real-time Communications for MMS, Profibus,
Fieldbus and UCA.

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

Newsgroups: comp.os.vxworks
Subject: invisible static variables
Date: 30 Jan 1997 16:57:54 GMT
From: lees@cts.com (Lee Slaughter)
Organization: CTS Network Services (CTSNET), San Diego, CA
Message-ID: <5cqjui$5a8@bogus.cts.com>
Reply-To: lees@nosc.mil

Why are static variables invisible symbols to vxWorks?
Impossible to debug.

for example, a .c file:
......
#include ...
#define ...

int x;

foo()
{
...
}
...

in this case x is visible.
if i qualify it with 'static' it is unknown.

thanks....

lee

- ---
  Lee Slaughter - network management development: submarine stuff   
  Navy R & D, Point Loma, San Diego, CA             lees@nosc.mil
  "Giving credence to his ramblings indicates a cognitive disorder..."
  				- Lee's psychiatrist, circa 1952

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

Newsgroups: comp.os.vxworks
Subject: Re: Help : How to incorporate Rogue Wave Class Library into VxWork Load
Date: 30 Jan 1997 12:30:00 GMT
From: varlese@tech.ascom.ch (Chris Varlese)
Organization: Ascom Hasler AG, Berne, Switzerland
Message-ID: <5cq488$noa@ascomax.hasler.ascom.ch>
References: <5cb81b$i2e@bcarh8ab.bnr.ca>

In article <5cb81b$i2e@bcarh8ab.bnr.ca>,
	diec@bnr.ca (michael diec) writes:
>I am having problem incorporate Rogue Wave Class Library into a 
>VxWork Load. Compiling and linking was done on an UNIX host with 
>gnumake. During the load build process, no error and warning were 
>flagged. But when I put the load onto a Power PC, errors were 
>detected : undefined symbols ( mainly all Rogue Wave Template 
>class were undefined ). 
>I would appreciate if someone can shed some light on how to 
>fix the problem i.e. what are missing during the compiling 
>and linking process ? etc.. 

Hello Michael,

you didn't give details, but I'll assume the symbols you are missing
are the template specialisation code.  Eg. if you made a RW list of
XYZ then your missing symbols are something like RWTPtrSlist<XYZ>.

some suggestions:

- - use the 'nm' tool to inspect the contents of compiled object files.
Since you are cross-compiling for PowerPC, the tool maybe called 'nmppc'
or something like that.  Look at the object files where you expect the
template object code to be.

- - check how you have compiled the templates.  Do you rely on implicit
template code instantiation, or do you do it manually?  Check if/how
you have used the -fno-implicit-templates.  When you instantiate implicitly,
you get template code created where you happen to use them.  When you
disable implicit instantiation, you have to define them yourself, e.g.
with a seperate .cc file.  I posted an explanation of this to
comp.os.vxworks last year.

regards

Chris Varlese
Ascom Tech AG

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

Newsgroups: comp.os.vxworks
Subject: Re: invisible static variables: never mind
Date: 30 Jan 1997 18:03:43 GMT
From: lees@cts.com (Lee Slaughter)
Organization: CTS Network Services (CTSNET), San Diego, CA
Message-ID: <5cqnpv$7kq@bogus.cts.com>
References: <5cqjui$5a8@bogus.cts.com>
Reply-To: lees@cts.com

In article <5cqjui$5a8@bogus.cts.com>, Lee Slaughter <lees@nosc.mil> wrote:
>Why are static variables invisible symbols to vxWorks?
>Impossible to debug.
>
>for example, a .c file:
>......
>#include ...
>#define ...
>
>int x;
>
>foo()
>{
>...
>}
>...
>
>in this case x is visible.
>if i qualify it with 'static' it is unknown.
>
>thanks....
>
>lee
>
>---
>  Lee Slaughter - network management development: submarine stuff   
>  Navy R & D, Point Loma, San Diego, CA             lees@nosc.mil
>  "Giving credence to his ramblings indicates a cognitive disorder..."
>  				- Lee's psychiatrist, circa 1952

thanks to Andy at qualcom, rtfm....

- -> ld 1,0,"foo.o"

duhhhhh...

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

Newsgroups: comp.os.vxworks
Subject: Complete Canon P133 Computer System
Date: 30 Jan 1997 21:27:42 GMT
From: allision@shop.com
Organization: Copy Cat Shop
Message-ID: <5cr3oe$5f@mtinsc04.worldnet.att.net>

We have the following Pentium Computer for sale.

Manufactuer: Canon

Specification:  

		
		Pentium 133 CPU
		1.6 Gig Hard Drive
		1.44 Floppy Drive
		8X CD-Rom
		28.8 Bps Modem
		16MB of EDO Ram 72 Pin
		Mid Tower with open 3 open 5.25 bays and 1 3.5 open bay
		Case also has RF Connector
		Intel Chipset Motherboard
		16 bit Sound Card
		1 MB PCI VGA Exp. to 2 MB
		256k Pipeline Cache
		PS/2 Keyboad and PS/2 Mouse
		Windows 95 
	

All computers are brand new from Manufactuer.	

Price: $ 1,099 USD

Optional:

		2 X 4 CD Recorder (Internal)
		w/SCSI Card, EZ CD Pro Software
		Price: 399.95  USD

		Expand to 2MB of VGA Graphics
		Price: $ 49  USD

		Monitors Avilable Upon Request

If you have any questions feel free to call,
Please leave a message and your call will be returned promptly.

				The Copy Cat Shop
				213-650-1680
				213-650-9110 Fax

		
		

		

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

Newsgroups: comp.os.vxworks
Subject: Console on COM3 on MVME1603??
Date: Thu, 30 Jan 1997 09:45:50 -0600
From: chaplin_roger@keithley.com
Organization: Deja News Usenet Posting Service
Message-ID: <854637389.31679@dejanews.com>
Reply-To: chaplin_roger@keithley.com

Has anyone been successful at getting serial ports 3 and 4 working
on the MVME1603?  We have the -011 baseboard, which has COM3 on the
front panel.  We would like COM3 to be the console at power-on, but
have discovered there is more to it than modifying a couple of
#defines in config.h.  We've asked Wind River if they have a driver
for the chip that connects to COM3 and COM4, but I don't think they
know for sure just what they have in that BSP, much less how to
configure and use it.

(Don't anybody at WRS take offense at this; I know from personal
experience what it feels like to be an overworked tech support person.)

Any help would be greatly appreciated.

- -------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

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

Newsgroups: comp.os.vxworks
Subject: Device Driver's Class
Date: Thu, 30 Jan 1997 14:18:48 -0600
From: "Steven J. Powell" <a0207584@dskp3.itg.ti.com>
Organization: Texas Instruments
Message-ID: <32F10228.136@dskp3.itg.ti.com>
Reply-To: localhost

What are people's true opinions about the Device Driver class taught
by Wind River?  Is it good class with "lab" time.

                                               Steve Powell
                                             Software Engineer
                                             Texas Instruments
                                             steve-powell@ti.com

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

Newsgroups: comp.os.vxworks
Subject: serial port with vx
Date: Wed, 29 Jan 1997 09:24:05 +0100
From: Jean-Luc Fleureau PERS <fleureje@ensieta.fr>
Organization: ensieta
Message-ID: <32EF0925.2749@ensieta.fr>

Hi all, I come again with my neophyte's questions....

After checking the hardware documentation af my mvme card (162-223)
I really have 4 serial ports on it, but only 2 ports are initialized 
by the actual kernel.

I have found in the target directory a file file named mv162.h, where a
define defines (of course) the number of serial channels. Immediatly I
replaced the number 2 by 4. But my QUESTION is : is it enough to do that
and to recompile the kernel ??

I have supposed, and I have tried to recompile the application 
with the command "make" in the target directory and the result is :

[1]: Entering directory `/usr/export/local/vxWorks/vxWorks/config/mv162'
cc68k -c -O -fvolatile -fno-builtin -m68040 -m68040-only -Wall -I/h  -I.
- -I/home/groix3/vxWorks/vxWorks/config/all/
- -I/home/groix3/vxWorks/vxWorks/h -I/home/groix3/vxWorks/vxWorks/h/
- -I/home/groix3/vxWorks/vxWorks/src/config/
- -I/home/groix3/vxWorks/vxWorks/src/drv/ -ansi -pedantic -pipe -nostdinc
- -DCPU=MC68040    /home/groix3/vxWorks/vxWorks/config/all/usrConfig.c

cpp: Invalid option `-lang-c' <===WHAT IS THAT ERROR ?????
as: error: unknown option 'm' <== ANd these others ?????
as: error: unknown option '6'
as: error: unknown option '8'
as: error: unknown option '0'
as: error: unknown option '4'
as: error: unknown option '0'
as: error: unknown option 'm'
as: error: unknown option '6'
as: error: unknown option '8'
as: error: unknown option '0'
as: error: unknown option '4'
as: error: unknown option '0'
as: error: no input filename given
usage: as [-F[O][if]#] [-O[#]] [-S[C]] [-o objfile] [-L] [-R] [-Q]
                [-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
file.s...
stdin:1: warning: ANSI C forbids an empty source file
stdin:1: output pipe has been closed
make[1]: *** [usrConfig.o] Error 1
make[1]: Leaving directory
`/usr/export/local/vxWorks/vxWorks/config/mv162'
make: *** [vxWorks] Error 2

Does anyone could help me again.

Thanks to all the previous ones and to the next ones...
- -- 

Jean-Luc FLEUREAU.
****************************************************************
Dpt Electronique Informatique Automatique
Ecole Nationale Superieure des Ingenieurs des Etudes et 
Techniques d'Armement
2 Rue Francois VERNY 29806 BREST cedex 9 FRANCE

Everything you ever wanted to know about me, 
but were afraid to ask ----> http://www.ensieta.fr/~fleureje/

TEL : 02 98 34 88 45 FAX : 02 98 34 87 50
Email : Jean-Luc.Fleureau@ensieta.fr
***************************************************************

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

Newsgroups: comp.sys.powerpc.tech,comp.sys.powerpc.misc,comp.os.vxworks
Subject: Re: Text on software development for PPC 604
Date: Thu, 30 Jan 1997 15:18:23 -0600
From: rang@trillium.adaptec.com (Anton Rang)
Organization: Trillium Research, an Adaptec company
Message-ID: <rang-3001971518230001@margaret.trillium.adaptec.com>
References: <32EE65D0.41C67EA6@swl.msd.ray.com>

In article <32EE65D0.41C67EA6@swl.msd.ray.com>, David Rourke
<dar@swl.msd.ray.com> wrote:
> I need a recommendation for a good text on code development for the
> PowerPC 604.  I am particularly interested in optimization for speed. 
> My target is a Motorola MVME2604 running Tornado 1.0 using the GNU C
> compiler.

  "The PowerPC(tm) Compiler Writer's Guide".

  IBM part number MPRPPCOMP-01, ISBN 0-9649654-0-2.

  I got a printed copy for $1 from IBM's order department, and there's
also a copy available on the web (in HTML I think, don't remember if
there's a PDF).

  It covers a goodly number of compiler optimization tricks, some of which
might also help you in writing assembly code or examining compiler
output.  

  Hope this helps,

  -- Anton

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

Newsgroups: comp.os.vxworks
Subject: MV1603 SCSI and VME RAM
Date: Thu, 30 Jan 1997 09:58:46 +0000
From: Doug Owens <owens2@llnl.gov>
Organization: Lawrence Livermore National Lab
Message-ID: <32F07083.1391@llnl.gov>
Reply-To: owens2@llnl.gov

Has anyone used the WRS MV160x SCSI driver to transfer between VME RAM
and SCSI?  It works OK for the onboard RAM, but when I try a VME bus ram
board the call (scsiRdSecs) returns fine but I don't see the data - at
least where I think it should be.  Does the SCSI driver do any address
translation for offboard addresses?

Thanks,
Doug Owens (owens2@llnl.gov)

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

Newsgroups: comp.os.vxworks
Subject: EtherExpress Pro 100
Date: 30 Jan 1997 19:30:50 GMT
From: "Benoit Robert" <brobert@teknor.com>
Organization: Teknor Microsysteme Inc.
Message-ID: <01bc0ee4$551800a0$0b5ecdcd@brobert.teknor.com>

Does everyone know if VxWorks drivers exist for 100 BaseT INTEL PCI Card
(EtherExpress Pro 100) ?

Thanks

Benoit Robert
Software Architect
brobert@teknor.com
  

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

Newsgroups: comp.os.vxworks
Subject: How to debug: Operation Fault 0x2
Date: 28 Jan 97 06:22:35 GMT
From: "Charles Zheng" <czheng@gi.com>
Message-ID: <01bc0ce3$c23fc580$b06454a8@czheng_95.gi.com>

I have new to vxWorks. I see the following error message when I try to run
my application.

Operation fault: 0x02.

I have no clue where to start to find the problem. Can anyone shed me some
light on debuggin with this type of problem ?

Thanks,

Charles		czheng@gi.com

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

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

From hansen@pistilmac1.chinalake.navy.mil  Fri Jan 31 07:18:42 1997
From: hansen@pistilmac1.chinalake.navy.mil (Joe Hansen)
Date: Fri Jan 31 07:18:45 PST 1997
Subject: Re: Heurikon V3F load Errors
>I am running Vxworks 5.0.2B on Heurikon HK68 V3Fs.  The cards are setup to
>boot
>over thinet from a Sparc 20 (OS 4.14) workstation.   I have three Heurikons
>executing very similar startup scripts.  I am seeing the same load error
>on both
>Heurikons when the timing lines up just right and the cards are  attempting to
>load the same file simultaneously. If I change the power up sequence to
>skew the
>timing or boot one chassis at a time I don't get the error.  The usr is set as
>root on this particular system if that makes any difference.
>

Rick;

We have experienced the same thing with 5.0.2b on Force Sparc 1e boards.
We assumed it was a result of network overload, as we had eight boards
booting up at once via an ethernet connecton to the host.  I don't know if
the unbooting boards were accessing the same file or not.  Our "solution"
was to reboot the boards that didn't boot.  An unglorious solution at best,
and not one that can be done in all situations!

It also did not seem to matter what the usr parameter was set to.  Sorry I
can't help more than this, but yes, there are others out here who have seen
this.

Joseph Hansen
(619) 939-6999
hansen@pistilmac1.chinalake.navy.mil

From nutek@pipeline.com  Fri Jan 31 07:27:05 1997
From: "NuTek 2000, Inc." <nutek@pipeline.com>
Date: Fri Jan 31 07:27:07 PST 1997
Subject: unsubscribe
unsubscribe

From andred@westvalley.com  Fri Jan 31 10:36:01 1997
From: ANDRED <andred@westvalley.com>
Date: Fri Jan 31 10:36:08 PST 1997
Subject: Two Job Opportunities @ a Networking Giant in San Jose
The Company is looking for someone to work on an ATM interface Card for a 
WAN Multiservice ATM switch. They are developing/integrating/testing 
relatively low-level(close to HW} Real-Time embedded software . The 
target is based on a MIPS class processor (4650) and uses Vxworks as 
there O/S. 
The contract should last from 3-9 mo. and pay is open for now. 
Contact me for more details and  if you are interested
Thanks , Andre 

Andre DePiano
West Valley Engineering
andred@westvalley.com

1183 Bordeaux Drive Suite #10
Sunnyvale Ca. 95123
Phone 408-744-1420 Fax 408-734-9681

From stan@rti.com  Fri Jan 31 12:14:03 1997
From: stan@rti.com (Stan Schneider)
Date: Fri Jan 31 12:14:05 PST 1997
Subject: Re: Text on software development for PPC 604

>> Date: Tue, 28 Jan 1997 15:47:12 -0500
>> From: David Rourke <dar@swl.msd.ray.com>

>> I need a recommendation for a good text on code development for the
>> PowerPC 604.  I am particularly interested in optimization for speed. 
>> My target is a Motorola MVME2604 running Tornado 1.0 using the GNU C
>> compiler.

There's a book called "Optimizing PowerPC Code" by Gary Kacmarcik that's pretty
good.  At least it takes the more modern view that optimization is something
you do by coaxing better output from a good compiler.  To be honest, I haven't
read it myself (I don't get to play in that sandbox much), but we have it here
& it has helped.

	-- Stan