From daemon@csg.lbl.gov Wed May 1 04:00:55 1996
From: daemon@csg.lbl.gov
Date: Wed May 1 04:01:00 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Wed May 1 04:00:50 PDT 1996

 Subject: HELP: File System/Disk mirroring
 Subject: Re: VXWORKS on the HP ????
 Subject: Changing default NFS perms. on create
 Subject: Re: TCP-IP Accelerator ???
 Subject: Re: Forcing Cold Boot from Vxworks
 Subject: Re: TCP-IP Accelerator ???
 Subject: Re: Forcing Cold Boot from Vxworks

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

Newsgroups: nortel.magellan.*,comp.os.vxworks
Subject: HELP: File System/Disk mirroring
Date: 18 Apr 1996 18:51:06 GMT
From: Ashwin Kumar <kumar@nt.com>
Organization: Nortel
Message-ID: <4l62uq$q2n@nrchh52.rich.nt.com>

Hi,

Any ideas on disk mirroring software on top of vxworks ?

Any info will be appreciated,

Thanks.

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

Newsgroups: comp.os.vxworks
Subject: Re: VXWORKS on the HP ????
Date: 30 Apr 1996 13:06:55 GMT
From: partin@heman.jsc.nasa.gov (Charles Partin)
Organization: Lockheed Engineering & Sciences Co.
Message-ID: <partin-300496065951@l14ee.jsc.nasa.gov>
References: <31815875.2BB7@phbtsus.com>
Followup-To: comp.os.vxworks,comp.sys.hp.hpux

In article <31815875.2BB7@phbtsus.com>, Aseem Bakshi <Abakshi@phbtsus.com>
wrote:

> Hi,
>
> Under Sun Solaris it is possible to run Vxworks. Is it possible to do
> the
> same with HP/UX ?????
>

We run VxWorks 5.2 under HPUX 9.05 on a 9000/755 with no problems.

> Are there any other options available to run real time under Hp/UX ???
> Thanks Aseem

I am sure there are other real-time systems (pSOS, VTRX, etc) running on
HP's. I have never had the need to look for them.

Charlie

- --
Charlie Partin email: partin@heman.jsc.nasa.gov
Lockheed Engineering voice: 713-333-6803
 & Sciences Co. fax: 713-333-6908

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

Newsgroups: comp.os.vxworks
Subject: Changing default NFS perms. on create
Date: 30 Apr 96 10:09:00 EST
From: m1w@icf.hrb.com (Michael E. Warren)
Organization: HRB Systems, Inc.
Message-ID: <1996Apr30.100900.24586@hrbicf>

Is there a convenient was to change the default permissions used when
a file is created on an NFS file system? When using the copy command,
new files are created on the file server using the 644 permissions.
Is there anything like the csh umask?

Mike Warren
HRB Systems
State College, PA

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

Newsgroups: comp.realtime,comp.os.qnx,comp.os.vxworks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.multinet,de.comm.protocols.tcp-ip,comp.arch.embedded
Subject: Re: TCP-IP Accelerator ???
Date: 26 Apr 1996 17:18:46 GMT
From: raj@cup.hp.com (Rick Jones)
Organization: the Unofficial Hewlett-Packard
Message-ID: <4lr0hm$5is@hpindda.cup.hp.com>
References: <peedsDqCKBD.2nD@netcom.com> <NELSON.96Apr25092810@ns.crynwr.com>
Followup-To: comp.realtime,comp.os.qnx,comp.os.vxworks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.multinet,de.comm.protocols.tcp-ip,comp.arch.embedded
Reply-To: raj@cup.hp.com

Russell Nelson (nelson@ns.crynwr.com) wrote:
: In article <peedsDqCKBD.2nD@netcom.com> peeds@netcom.com (LataAndPd) writes:
: > 	Does anyone know of any add-on accelerator cards for
: > 	TCP/IP which will offload the system's TCP/IP load ? If so,
: Problems with this idea:
: o TCP has a pretty low overhead for a clean link (Van Jacobsen's 30
: ...
: o Very often the "accellerator" cards run a processor MUCH slower
: than the main processor.
: o The interface between the system and the card often becomes the
: bottleneck.

"Smart" interfaces can indeed be too smare for their own good.
However, "idiot-savant" cards can be helpful - those that can provide
internet checksum offload in each direction, and then perhaps also
determine the split between protocol headers and data on inbound and
do the DMA accordingly.

At least some OSes have support for such things today - Irix and
HP-UX to name two, there may be others. Now if we could just get all
the third-party card developers on board :)

rick jones

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

Newsgroups: comp.os.vxworks
Subject: Re: Forcing Cold Boot from Vxworks
Date: 26 Apr 1996 13:46:14 -0700
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <4lrcmm$bn4@elaine25.Stanford.EDU>
References: <4lpa5f$o4e@netline-fddi.jpl.nasa.gov> <4lpcmd$sq3@elaine25.Stanford.EDU> <4lqma5$8tn@hppadbk.waterloo.hp.com>

In article <4lqma5$8tn@hppadbk.waterloo.hp.com>,
Don Bowman <bowman@waterloo.hp.com> wrote:
>Earl Mitchell (kla@leland.Stanford.EDU) wrote:
>: In article <4lpa5f$o4e@netline-fddi.jpl.nasa.gov>,
>: Gerard Benenyan <gerard@uccs.jpl.nasa.gov> wrote:
>: >
>: >Does anyone have experience on forcing a system reboot
>: >in a vxworks environment. All attempts to jump to
>: >location 0xffffff0, which is the cold boot rom location have failed.
>: >
>: The stack is typically used to store a return instruction
>: pointer (RIP) which is stuffed in the IP register when
>: stack frame is popped. By modifying this you can trick the
>: system into jumping to 0xffffff0 when returning from a call.
>: You just need to figure out where RIP is located.
>
>: coldBoot()
>: {
>: rip_addr = (U32) 0xffffff0 ;
>: return
>: }
>
>
>That's awfully error prone.
>Why not just call the reboot() function?
>
>If that's no good for some reason, then insert an __asm__ thing there.
>
>coldBoot()
>{
> __asm__("bx 0xfffffff0");
>}
>
>I don't know which processor you're using, but the opcode should be
>something like that.

From his description of the problem (i.e. all attempts to jump to
... have failed) I assumed he had tried this already.

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

Newsgroups: comp.realtime,comp.os.qnx,comp.os.vxworks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.multinet,de.comm.protocols.tcp-ip,comp.arch.embedded
Subject: Re: TCP-IP Accelerator ???
Date: 25 Apr 1996 22:10:55 -0400
From: mo@uunet.uu.net (Mike O'Dell)
Organization: Centre for Chaotic Repeatabilty
Message-ID: <4lpbbf$7nv@rodan.UU.NET>
References: <peedsDqCKBD.2nD@netcom.com> <NELSON.96Apr25092810@ns.crynwr.com>
Reply-To: mo@uunet.uu.net

usually the key to good TCP performance is not a front-end processor
but getting a good Ethernet card which doesn't require much
processor intervention.

having built front-end processors before, I've never seen one where
the protocol to talk to the front-end wasn't as complex as TCP
itself, so there was no real gain at the end of the day.

good TCP code + good network card = good performance.

enjoy.

	-mo

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

Newsgroups: comp.os.vxworks
Subject: Re: Forcing Cold Boot from Vxworks
Date: 26 Apr 1996 14:24:05 GMT
From: bowman@waterloo.hp.com (Don Bowman)
Organization: H-P Panacom Div, Waterloo, ON Canada
Message-ID: <4lqma5$8tn@hppadbk.waterloo.hp.com>
References: <4lpa5f$o4e@netline-fddi.jpl.nasa.gov> <4lpcmd$sq3@elaine25.Stanford.EDU>

Earl Mitchell (kla@leland.Stanford.EDU) wrote:
: In article <4lpa5f$o4e@netline-fddi.jpl.nasa.gov>,
: Gerard Benenyan <gerard@uccs.jpl.nasa.gov> wrote:
: >
: >Does anyone have experience on forcing a system reboot
: >in a vxworks environment. All attempts to jump to
: >location 0xffffff0, which is the cold boot rom location have failed.
: >
: >Vxworks does not allow jumping into another task space.
: >Someone at Wind River suggested forcing a "triple" exception.
: >Too contrived. There must be a more elegant solution.
: >
: >Any help will be much appreciated.

: The stack is typically used to store a return instruction
: pointer (RIP) which is stuffed in the IP register when
: stack frame is popped. By modifying this you can trick the
: system into jumping to 0xffffff0 when returning from a call.
: You just need to figure out where RIP is located.

: coldBoot()
: {
: rip_addr = (U32) 0xffffff0 ;
: return
: }

That's awfully error prone.
Why not just call the reboot() function?

If that's no good for some reason, then insert an __asm__ thing there.

coldBoot()
{
 __asm__("bx 0xfffffff0");
}

I don't know which processor you're using, but the opcode should be
something like that.

- --
bowman@waterloo.hp.com ** 519-883-3019 ** http://www.waterloo.hp.com/~bowman

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

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

From rbair@astro.ge.com Wed May 1 06:32:40 1996
From: "Robert E. Bair" <rbair@astro.ge.com>
Date: Wed May 1 06:32:43 PDT 1996
Subject: unsubscribe
unsubscribe

From edk@wrs.com Wed May 1 08:20:04 1996
From: Ed Klein <edk@wrs.com>
Date: Wed May 1 08:20:07 PDT 1996
Subject: Re: How long to semGive()?
did you get what you wanted?? I have a set of benchmarks that I could
fax or email to you ??

Ed Klein		 1901 N. Roselle Rd # 800
Wind River Systems 		 Schaumburg, Il 60195

phone: (847)490-6062
fax: (847)490-6511
email: edk@wrs.com
WWW: http://www.wrs.com

From YF.Siu@eng.efi.com Wed May 1 10:15:45 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Wed May 1 10:15:48 PDT 1996
Subject: Re: dosFs troubles...
The problem you described is very similar to the one I discovered last
year with vxWorks 5.2. To confirm this, instead of using the shell,
try to spawn a task, i.e., 'sp copy,"srcfile","desfile"', to do the
copy and observe what is happening. If you discovered that the new
task never exits and is always ready, that's it. If you do a 'tt' or
so, you should find that the task is doing some hashLib or sllLib
stuff.

Since we have the source code to 5.2, I did find the bug in the dosFsLib.
The problem was due to a hashList corruption inside the dosFsLib. I've
reported the bug to WRS: SPR 4418. I don't think there's a work around
without the source code. You may want to contact WRS and ask for a fix
or patch.

I'm just surprised that it takes so long before anyone else discover this.
Probably noone else is using dosFsLib with 5.2 ??

Good Luck,

YF

From mea@mclean.sparta.com Wed May 1 16:05:34 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Wed May 1 16:05:36 PDT 1996
Subject: PRI-48XP Dual T1
Greetings!

 We're interested in terminating a T1 (1.544 MBPs) line into a VME crate
for VxWorks. We're not interested in ISDN (*I*t *S*till *D*oes *N*othing ;-).
We purchased a PRI-48XP dual T1 board, but all the documentation talks about
is ISDN. We've been trying for almost a week now to get someone on the
phone at PRI in tech support to no avail. So, the question is, has anyone
out there in netland interfaced the PRI-48XP to a T1 interface for
full T1 throughput? If so, what software did you use and is it available?

Regards,

===============================================================================
 __ Real-Time System Development, Integration, Training and Services
 //\\
 // \\ Mike Anderson
 // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235
 // / \ \\ SPARTA, Inc. FAX : (703) 734-3323
// \ \\ 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 May 2 04:00:34 1996
From: daemon@csg.lbl.gov
Date: Thu May 2 04:00:37 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Thu May 2 04:00:28 PDT 1996

 Subject: Re: Socket Reuse Problems
 Subject: Re: Socket Reuse Problems
 Subject: Q: Producing boot proms for MVME167
 Subject: vxMp with Reflective Memory
 Subject: Re: Forcing Cold Boot from Vxworks
 Subject: Custom application under telnet

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

Newsgroups: comp.os.vxworks
Subject: Re: Socket Reuse Problems
Date: Tue, 30 Apr 1996 14:15:07 -0400
From: Kevin Rice <kevin@vlsi.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-ID: <318658AB.2A2F@vlsi.gsfc.nasa.gov>
References: <TADLOCK.96Apr29150958@bosch.dseg.ti.com>

I don't have very many suggestions but I did notice in one
of my TCP/IP books that REUSEADDR basically allows the port
# to be re-used so if you are trying to bind to the same
address, this wouldn't work properly.

If that's in order make sure the setsockopt is being called
before each bind in *EACH* app! (i should add that i've
never actually tried this myself -- just playing back
the 'tape.')

It wasn't clear if that's what you trying to do this
or not.

Too bad you aren't running 4.4bsd apparently there is an
option called REUSEPORT that would allow multiply open
both a port & address!

Kevin Rice

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

Newsgroups: comp.os.vxworks
Subject: Re: Socket Reuse Problems
Date: 1 May 1996 19:49:25 GMT
From: j.gordon@dial.pipex.com (John Gordon)
Organization: N/A
Message-ID: <4m8f85$iib@soap.news.pipex.net>
References: <TADLOCK.96Apr29150958@bosch.dseg.ti.com> <318658AB.2A2F@vlsi.gsfc.nasa.gov>

I have a piece of code written for SunOS 4.1.3 on a Sparc that makes use
of SO_REUSEADDR and functions correctly, but I did notice the other day
when trying to get it to run on our VxWorks 5.2/PowerPC combination that
the code was getting address in use errors. At the time I ignored it as I
had other problems with the code too - I will investigate a bit further
tomorrow!

John...

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

Newsgroups: comp.os.vxworks
Subject: Q: Producing boot proms for MVME167
Date: 1 May 1996 15:41:58 GMT
From: jschamba@physics.utexas.edu (Jo Schambach)
Organization: Physics Department, University of Texas at Austin
Message-ID: <4m80o6$5cg@geraldo.cc.utexas.edu>
Reply-To: JSchamba@utpapa.ph.utexas.edu

Forgive my ignorance in this matter, but: how does one produce bootrom code for
VxWorks from the BSP in 5.2 that can be used by a PROM burner for MVME167 proms?

I found several targets relating to this subject in the Makefile. However, they
all seem to produce one file only, while the manual states that there are 2 boot
proms needed for VxWorks, arranged in 32 bits, one for even, and one for odd
words. I don't see a target that can split the resulting file in such a manner.
Am I missing something fundamental here?
I would really appreciate if someone could mail me a step-by-step procedure to
create boot proms, beginning with a pair of empty proms and the (non-compiled)
BSP, that is understandable by a layman like myself ...

Thanks in advance,		Jo
*****************************************************************
Joachim Schambach			Research Associate
Physics Department, RLM 5.208
The University of Texas at Austin
Austin, TX 78712
USA

email:	JSchamba@physics.utexas.edu
Tel:	x1 (512) 471-1303 		FAX:	x1 (512) 471-9637
*****************************************************************

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

Newsgroups: comp.os.vxworks
Subject: vxMp with Reflective Memory
Date: 1 May 1996 16:17:07 GMT
From: john.weir@msfc.nasa.gov (John Weir)
Organization: NASA MSFC
Message-ID: <4m82q3$m3t@hammer.msfc.nasa.gov>

We have three VME-based vxWorks systems interconnected with a VMIC RMS
system which replicates all data writes to an address range to the
corresponding address in each system. We are considering using the vxMp
product with this system to implement shared memory among our VME
chassis. Has anyone tried this? How did it work? Thanks in advance for
all replies?

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

Newsgroups: comp.os.vxworks
Subject: Re: Forcing Cold Boot from Vxworks
Date: Fri, 26 Apr 1996 20:51:21 GMT
From: mfisher@dyn.com (Mark Fisher)
Organization: The World @ Software Tool & Die
Message-ID: <DqHLrE.9rB@world.std.com>
References: <4lpa5f$o4e@netline-fddi.jpl.nasa.gov>
Reply-To: mfisher@dyn.com
Sender: news@world.std.com (Mr Usenet Himself)

gerard@uccs.jpl.nasa.gov (Gerard Benenyan) wrote:

>Does anyone have experience on forcing a system reboot
>in a vxworks environment. All attempts to jump to
>location 0xffffff0, which is the cold boot rom location have failed.

>Vxworks does not allow jumping into another task space.
>Someone at Wind River suggested forcing a "triple" exception.
>Too contrived. There must be a more elegant solution.

>Any help will be much appreciated.

>		Gerard B.

If, and this is a big if, your hardware has a hardware watchdog on
the board then enable it and LET IT timeout, then this will usually
cause the board to reset itself as if from a cold reboot.

Unfortunately, one cannot rely on the vxWorks reboot() function to
work in all cases -- it is really nothing more than a jump to
re-start the code and as such is really a warm restart. reboot() can
fail in cases where an exception is caused by a function that was
registered to be called on reboot() -- see rebootHookAdd(). I think
vxWorks code calls in quite a few places themselves. reboot() will
nearly always work if nothing has gone wrong in the application. But
when you need it most, to reset the board after some bad behavior is
detected, then it less likely that it will work! I have even seen
reboot() cause a double bus error -- which on a Moto CPU makes the CPU
go into the halt state. The only thing that will get you out of that
is manually re-setting the board or a hardware run watchdog.

HTH,

Mark.

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

Newsgroups: comp.os.vxworks
Subject: Custom application under telnet
Date: Thu, 25 Apr 1996 18:02:13 -0400
From: "Jeffrey D. Prem" <jdp@fore.com>
Organization: FORE Systems, Inc.
Message-ID: <317FF665.41C67EA6@fore.com>

I'd like to run a custom application, not the VxWorks shell, when a
user telnets to my device. Unfortunately, there doesn't seem to be an
API that provides this capability. Has anyone succeeded in doing this
without having to modify the VxWorks source?

Thanks,
Jeff

- ----------
Jeff Prem
jdp@fore.com
FORE Systems, Inc.

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

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

From Mike.Milde.at.SRC-Home_Office@scires.com Thu May 2 04:24:53 1996
From: Mike Milde at SRC-Home_Office <Mike.Milde.at.SRC-Home_Office@scires.com>
Date: Thu May 2 04:24:56 PDT 1996
Subject: ENETUNREACH?

 I have a system where the shell occasionally spits out these
messages that say "ENETUNREACH". Surprisingly, everything appears to
work as it should.

 Any idea where these are created? I'm doing some IP socket
stuff, so I assume that this means something like: Ethernet
Unreachable. Any ideas? Anyone know if this is caused by an ICMP
message coming back from the system I am communicating with?

 Any help/hints/clues are greatly appreciated!

 Mike Milde
 Scientific Research Corporation
 mmilde@scires.com

From P.H.A.Mutsaers@cycl.phys.tue.nl Thu May 2 07:38:34 1996
From: Peter Mutsaers <P.H.A.Mutsaers@cycl.phys.tue.nl>
Date: Thu May 2 07:38:37 PDT 1996

 We are using Tornado/VxWorks5.3 on a x86 target. Does
 anyone know how to access, in an application, a device
 on the PCI-bus since WRS does not provide a PCI-driver
 for this target.

 Does anyone know if there is a PCI-driver for an x86
 target available from another source?

 Is it possible to access a PCI compatible BIOS and if
 yes, how?

 Greetings,

 Peter Mutsaers
	Eindhoven University of Technology
 tnndmuts@cycl.phys.tue.nl

From P.H.A.Mutsaers@cycl.phys.tue.nl Thu May 2 07:39:58 1996
From: Peter Mutsaers <P.H.A.Mutsaers@cycl.phys.tue.nl>
Date: Thu May 2 07:40:01 PDT 1996
Subject: pci on x86 support

 We are using Tornado/VxWorks5.3 on a x86 target. Does
 anyone know how to access, in an application, a device
 on the PCI-bus since WRS does not provide a PCI-driver
 for this target.

 Does anyone know if there is a PCI-driver for an x86
 target available from another source?

 Is it possible to access a PCI compatible BIOS and if
 yes, how?

 Greetings,

 Peter Mutsaers
	Eindhoven University of Technology
 tnndmuts@cycl.phys.tue.nl

From bqv@eng102.eng.i-o.com Thu May 2 08:15:41 1996
From: "Bang Q. Vu" <bqv@eng102.eng.i-o.com>
Date: Thu May 2 08:15:44 PDT 1996
Subject: Re: comp.os.vxworks newsdigest
Joachim Schambach penned:
>
>Forgive my ignorance in this matter, but: how does one produce bootrom code
for
>VxWorks from the BSP in 5.2 that can be used by a PROM burner for MVME167 >
proms?
>
>I found several targets relating to this subject in the Makefile. However,
they
>all seem to produce one file only, while the manual states that there are 2 >
boot proms needed for VxWorks, arranged in 32 bits, one for even, and one for
>odd words. I don't see a target that can split the resulting file in such a >
manner.
>Am I missing something fundamental here?
>I would really appreciate if someone could mail me a step-by-step procedure to
create boot proms, beginning with a pair of empty proms and the (non-compiled)
>BSP, that is understandable by a layman like myself ...
>
>Thanks in advance,		Jo
>*****************************************************************
>Joachim Schambach			Research Associate
>Physics Department, RLM 5.208
>The University of Texas at Austin
>Austin, TX 78712
>USA
>
>email:	JSchamba@physics.utexas.edu
>Tel:	x1 (512) 471-1303 		FAX:	x1 (512) 471-9637
>*****************************************************************
>

Once, i got tired of waiting for vxWorks to boot with the compressed boot ROMS
so i built new boot ROMS with uncompressed codes. Go to where the BSP is, for
example, vw/config/mv147, run "make bootrom_hex|bootrom_uncmp.hex". There are
2 PROMS. All of this is mentioned in the Programmer's Guide. The splitting of
the boot file (i.e. bootrom_hex|bootrom_uncmp.hex) into even/odd bytes will
have to be done by another piece of software not provided by WRS. The PROM
burner (Unisite), that i used, is interfaced to a PC which does the splitting
for me. Look at your PROM burner documentation to see if it provides the byte
splitting for you. Sorry, can't help you here.
--
Bang Vu | I/O, Inc.
bvu@eng.i-o.com | 12300 Parc Crest Dr.
Voice 713-879-2087 | Stafford, Texas 77477
Fax 713-879-2096 |

From don@carts.com Thu May 2 15:31:57 1996
From: Don Bingman <don@carts.com>
Date: Thu May 2 15:31:59 PDT 1996
Subject: consultants
I have an imediate need for several vxworks consultants in the San diego area.

Contact Don Bingman Voice: 619-587-0888
 Fax: 619-587-0444
 Email: don@carts.com

From fchen@mpl.ucsd.edu Thu May 2 15:57:16 1996
From: fchen@mpl.ucsd.edu (Hsiufang Chen)
Date: Thu May 2 15:57:20 PDT 1996
Subject: Re: Returned mail: Cannot send message for 3 days
Hi:

Your mail bounced because barnacle has been down or disconnected from
network for several days. If you are trying to reach Bob Lawhead, his
address is rml@mpl.ucsd.edu. Please resend your mail to this address.
Otherwise, if you need my assistance to figure out a correct address,
please let me know.

Fang

> From Mailer-Daemon Thu May 2 14:03:47 1996
> Date: Thu, 2 May 1996 14:03:47 -0700
> From: Mailer-Daemon (Mail Delivery Subsystem)
> Subject: Returned mail: Cannot send message for 3 days
> To: Postmaster
>
> ----- Transcript of session follows -----
> 421 barnacle: Host barnacle is down
>
> ----- Message header follows -----
> Return-Path: <root@csg.lbl.gov>
> Received: from csg.lbl.gov by chiton.ucsd.edu (5.x/SMI-SVR4-UCSD.1)
> 	id AA16489; Mon, 29 Apr 1996 13:28:56 -0700
> Errors-To: vxwexplo-errs@lbl.gov
> Received: by csg.lbl.gov (4.1/1.39)
> 	id AA02825; Mon, 29 Apr 96 13:01:45 PDT
> Date: Mon, 29 Apr 96 13:01:45 PDT
> Message-Id: <9604292001.AA02825@csg.lbl.gov>
> Errors-To: vxwexplo-errs@lbl.gov
> To: vxworks_users@csg.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: Re: once more plz: How do you time a piece of code?
>

From daemon@csg.lbl.gov Fri May 3 04:00:32 1996
From: daemon@csg.lbl.gov
Date: Fri May 3 04:00:36 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Fri May 3 04:00:25 PDT 1996

 Subject: New Development Tools and Embedded Database
 Subject: Equivalence to inittab needed for VxWorks
 Subject: Re: 162 flash memory
 Subject: Re: Rpc 4.0 and Microsoft Rpc

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

Newsgroups: comp.os.vxworks
Subject: New Development Tools and Embedded Database
Date: Fri, 19 Apr 96 14:14:35
From: Phillip Thoren <pthoren@synervision.com>
Organization: Web Professionals' Network
Message-ID: <NEWTNews.829948499.1981.pthoren@eagle>

VisionSoft Corporation Welcomes You - to the http://www.synervision.com web site

VisionSoft Development Products

Cross-Platform Software Runtime Error Checking :& Coverage Analysis Tools

- --- Automatically Detect: Variable Reference Errors, Array Boundary Condition Errors, Memory Leaks ---

- --- Perform Integrated Single-Pass SoftLab(tm) Analysis for Runtime Error Checking & Coverage Analysis ---

- --- Automatically Retrofit Your Application and Include Remote Software Monitoring and Runtime Diagnostics ---

VisionSoft Embedded Realtime Database Products

Fast, Efficient Portable Embedded C & JAVA Database API Toolkit

- ------------------------------------------------------------------------------------------------------------------------------------------------
Please visit our web site http://www.synervision.com, browse our site and freely Roam!!!!

Datasheets, White Papers, Manuals and Software in (HTML Format), (Acrobat Format) and
(Self-Extracting Executable Trial Software)
- ------------------------------------------------------------------------------------------------------------------------------------------------

- --- Cross-Platform Software Quality Tools, Internet Search, Find, Store and Replace Tools ---

- --- HOST Platforms Supported Include:-- Windows 3.1, Windows 95, Windows/NT, HP-UX, VxWorks, Solaris,
Macintosh, OS/2, SCO (Locus) ---

- --- TARGET Platforms Supported Include:-- All Platforms Above, VMS, Ultrix,
Tandem Guardian, MVS, XINU,
etc. (Virtually ALL platforms)

- --- Realtime TARGET Platforms Supported Include:-- VxWorks (All Processors),
Will modify products as required
to support other RTOS's and Non-OS type embedded environments

VisionSoft Corporation
Pruneyard Towers
1999 S. Bascom Ave, Suite 700
Campbell, CA 95008-9872, USA
(408) 879-2672
sales@synervision.com
http://www.synervision.com
(c) copyright 1995-1996 VisionSoft Inc. All rights reserved.

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

Newsgroups: comp.os.vxworks
Subject: Equivalence to inittab needed for VxWorks
Date: 2 May 1996 21:04:29 GMT
From: townley@nortel.com (Jeanette Chickles)
Organization: Bell-Northern Research Ltd.
Message-ID: <4mb80t$3uk@crchh327.rich.bnr.ca>

Hi,

I was wondering if anyone out there has developed any
software that's equivalent to inittab on HPUX for VxWorks?
I'm interested in writing a process that monitors particular
tasks running on VxWorks and restarts them if they shut
down. I have some ideas on how to implement this myself,
but before I do, I wanted to check to see if anyone knew if
something like this is already available.

Thanks in advance!
Jeanette
(townley@nortel.com)

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

Newsgroups: comp.os.vxworks
Subject: Re: 162 flash memory
Date: 19 Apr 1996 17:16:57 GMT
From: witts@PROBLEM_WITH_INEWS_GATEWAY_FILE (Steve Witt)
Organization: Hughes Aircraft Company
Message-ID: <4l8hq9$7ce@venice.sedd.trw.com>
References: <199604151822.AA24425@darya.wrs.com>
Reply-To: sawitt@hac2arpa.hac.com

> Pete writes:

> >
> > I'm trying to program the MVME162's flash ram. The vxWorks documentation
> > wimps out by refering the user to the Motorola's debug command 'pflash'.
> > Anybody have any example code that they could share?
> >
> > Thanks,
> >
> > Pete
> >
> > faill@eng.insol.com

An alternate method for downloading a FLASH image over Ethernet,
which is much faster than the serial method - both are useful however.
This may look pretty complicated, but it really isn't once you understand
what is going on.

1) make your image (e.g. vxWorks.st_rom)

2) convert your image to binary format with aoutToBin
	% aoutToBin < vxWorks.st_rom > vxWorks.st_rom.bin

3) make sure you have the Motorola 'BUG' ROM in the PROM socket and
 boot from the ROM (pull jumper J22)

4) use NIOT command to specify IP addresses of target and host for image
 transfer
	162-BUG> niot
	162-BUG> ... {Read Motorola docs, only thing you have to enter
			 are the IP address of your host and IP address
			 of your target board}

5) use NIOP command to actually download the image over the Ethernet
	162-BUG> niop
	162-BUG> ...	{Again, read the docs, you must enter the file name
			 (vxWorks.st_rom.bin) and the start address in RAM
			 that you want the load to begin at. We use 0x10008.}

	There is something a little tricky about this if you don't understand
	the TFTP protocol. This is true of SunOS and Solaris, I don't know
	about other OSs. TFTP is used to download the image from your host
	to the target. TFTP has no security mechanisms, like the password
	protect in FTP. So Sun (and probably others) have set up the TFTP
	daemon to only allow file access from a designated directory. This
	directory is designated by the 'inetd' config file, '/etc/inetd.conf'.
	Edit the line in /etc/inetd.conf for TFTP and replace the directory
	that is there with the one in which your image resides. Then you must
	restart 'inetd' (which controls the TFTP daemon) by sending it the
	hangup signal (kill -HUP pid, where pid is inetd's process ID retrieved
	using 'ps'). Read the man pages about all of these things if it isn't
	clear and my apologies for the seminar if this is old hat to you.

6) Ok, the image is in RAM, you must edit the first 8 bytes of the image to
 be programmed for some stuff needed at boot
	162-BUG> mm 0x10000
	00010000 0000?	0000
	00010002 0000? 1000
	00010004 0000? ff80
	00010006 0000? 0008
	00010008 46fc? . {beginning of your image, '.' stops the edit}

7) Now program flash
	162-BUG> pflash 0x10000:<image size> 0xffa00000

	... prints a bunch of status, and when its done, you've got your
	image into FLASH, replace J22 to boot from FLASH and go for it.

	This image size parameter is the size of the chunk of RAM you want
	to program into FLASH. I use 0x80000 for bootrom images and 0x100000
	for our application images, but this is of course dependent upon your
	image.

Credits: 90% of the above was given to me by Jerry Pendleton of WRS Tech Support
	 when we asked the same question several years ago.

Hope this helps. What I've done now is to write an expect script (the TCL
'expect' utility) to do all of this almost automatically. After you've done
it 5 or 10 times (not to mention hundreds of times), it loses its excitement.

- ---------------------------------------------------------------------
Steve Witt Hughes Aircraft Company
sawitt@hac2arpa.hac.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Rpc 4.0 and Microsoft Rpc
Date: Sat, 20 Apr 1996 08:09:54 GMT
From: noblenet@world.std.com (NobleNet Inc.)
Organization: NobleNet, Inc.
Keywords: RPC, XDR, Client/Server, NobleNet, ONC, VxWorks
Message-ID: <Dq5IoJ.5ys@world.std.com>
References: <829821431.11023@hathsys.demon.co.uk> <829822771.12586@hathsys.demon.co.uk>
Followup-To: poster

In article <829822771.12586@hathsys.demon.co.uk>,
Nicholas Doyle <nic@imc4.eej.ulst.ac.uk> wrote:
>I know there is an ONC implemention available, but it seems that good
>old Microsofts MSVC 4.0 Rpc will not talk to it.

Please contact NobleNet for ONC RPC tools and solutions for UNIX,
Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc.

 NobleNet, Inc.
 337 Turnpike Road
 Southboro, MA 01772
 Voice +1 508 460 8222
 Fax +1 508 460 3456
 sales@noblenet.com
 <http://www.noblenet.com/>

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

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

From senthil@ssi.navtech.com Fri May 3 07:39:12 1996
From: "Senthil Natesan" <senthil@ssi.navtech.com>
Date: Fri May 3 07:39:15 PDT 1996
Subject: Multibyte wide char support
Hi
Does any body know about multibyte or wide char support for vxworks.
Have you used it? Do you know about any third party support for it?
I heard vxworks does not support this.

Any information is appreciated.

Senthil Natesan
e-mail: senthil@ssi.navtech.com

From seaweed!seaweed.com!bob@netcom.com Sat May 4 19:19:43 1996
From: bob schulman <bob@seaweed.com>
Date: Sat May 4 19:19:45 PDT 1996
Subject: Re: Multibyte wide char support
> Does any body know about multibyte or wide char support for vxworks.
> Have you used it? Do you know about any third party support for it?
> I heard vxworks does not support this.
vxWorks does and doesn't support it. Some wide char functions (e.g.
wcslen and wcstombs) are not supported. Some functions
have entry points in the distributed vxWorks libraries (e.g. mblen
and mbstowcs) but are documented us unimplemented.

How a function can have been written by Wind River, distributed by
Wind River, but then said to be unimplemented is bit beyond my meager
mental facilities.

The crowning glory of Wind River's mblen implementation (just to pick
one gem of this thread) is that it returns a value of -1. The SunOS definition
of mblen does not include -1 as a legal return value. I don't know, but I guess
that no Unix vendor's implementation of mblen includes -1 as a legal return
value. So, if you attempt to port a piece of software from, e.g. SunOS,
to vxWorks, you don't have any problems resolving references to mblen,
but your code may die in mysterious ways because your code did not anticipate
the zen-like quality of Wind River's
there-but-not-there-and-doesn't-return-legal-value mblen.

By the way, did I tell you guys and gals that I've been burned by this?

So what you heard is correct: Wind River does not support this.

bob

From ceselsa@coastalnet.com Mon May 6 06:19:18 1996
From: ceselsa@coastalnet.com (Carlos Martinez)
Date: Mon May 6 06:19:21 PDT 1996
Subject: vxworks parallel driver
I am looking for a VxWorks parallel driver (e.g. to use with a Laser
printer). We are currently using target VMEbus Motorola PowerPC boards
and host SUN SPARC Stations. Is there any merciful person on the net
who could help ?

Thank you.

Carlos Martinez
INDRA DTD Cherry Point, NC.
ceselsa@coastalnet.com
(919) 466-9133
(919) 466-9134 Fax

From Mike.Milde.at.SRC-Home_Office@scires.com Mon May 6 07:37:01 1996
From: Mike Milde at SRC-Home_Office <Mike.Milde.at.SRC-Home_Office@scires.com>
Date: Mon May 6 07:37:05 PDT 1996
Subject: Ruggedized VME boards?

 Can someone point me to a collection of information on ruggedized
VME single board computers?

 We are currently in need of a ruggedized Motorola MVME-162 card
or something as similar as possible. A WRS board support package
must be available for it. There is no need for military standard
components; commercial boards will be adequate.

 Anyone have any favorites?

 Thanks!
 Mike Milde
 Scientific Research Corporation
 (770) 989-9550

From 75104.3460@compuserve.com Mon May 6 21:38:04 1996
From: David Parkerson <75104.3460@compuserve.com>
Date: Mon May 6 21:38:07 PDT 1996
Subject: Re: Ruggedized VME boards?
Mike,

A well supported architecture with VxWorks that is used in many Mil apps is
SPARC. SPARC 5, 10 and 20's are available all with Vx. The 10/20 will run it
on ea of four processors!!

Also PowerPC is available with 100 Mhz, secondary cache and the Universe VME
chip with Vx Support too! Call Themis at 510-252-0870.

Regards
David Parkerson

From daemon@csg.lbl.gov Tue May 7 04:00:39 1996
From: daemon@csg.lbl.gov
Date: Tue May 7 04:00:44 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Tue May 7 04:00:31 PDT 1996

 Subject: Re: How to determine current memory usage
 Subject: Re: How to determine current memory usage
 Subject: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: Any HTTP servers available on VxWorks?

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

Newsgroups: comp.os.vxworks
Subject: Re: How to determine current memory usage
Date: 4 May 1996 08:12:26 GMT
From: romsky@x4u2.desy.de (Vladimir Romanovski)
Organization: DESY
Message-ID: <4mf3ha$n60@dscomsa.desy.de>
References: <Pine.SOL.3.91.960503155240.10217E-100000@lennon.qualcomm.com>

Andy Van Pelt (avanpelt@qualcomm.com) wrote:
: I would like to track memory usage from within a program, and have not
: been able to find a routine to call to tell me this. memShow will display
: the information I want, but I don't want the data displayed, I want to
: store it and analyze it.

Look this
ftp://epics.aps.anl.gov:pub/epics/extensions/devAiStats.c

I use long way(redirect output of memShow to socket and after _scanf_)..

Vladimir

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

Newsgroups: comp.os.vxworks
Subject: Re: How to determine current memory usage
Date: 6 May 1996 19:03:49 GMT
From: Don Small <dmsmall@sandia.gov>
Organization: Sandia National Laboratories
Message-ID: <4mliel$79b@news.sandia.gov>
References: <Pine.SOL.3.91.960503155240.10217E-100000@lennon.qualcomm.com>

Andy Van Pelt <avanpelt@qualcomm.com> wrote:
> I would like to track memory usage from within a program, and have not
>been able to find a routine to call to tell me this. memShow will display
>the information I want, but I don't want the data displayed, I want to
>store it and analyze it.
>
> How do I find out how much memory is currently allocated and how much is
>free? I know how to find out the largest block that can be allocated
>(memFindMax), but that's not quite the same.
>
> I hope the answer doesn't involve calling memShow and parsing
>the output. That's gross!
>
The number of currently allocated "words" may be found by indexing into the
system memory partition. To determine the number of bytes use:

2*memSysPartId->curWordsAllocated

You must include <private/memPartLibP.h> to use this method. I would also
assume that this method (since it is under the private directory) is not
guaranteed by Wind River to work under any other version. I know it works with
version 5.2 & 5.3.

For other info about this structure view memPartLibP.h and look for the
structure definition for PARTITION.

Don

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Mon, 06 May 1996 14:29:32 -0700
From: Shaun Case <shaunc@gpsys.com>
Organization: Graham-Patten Systems, Inc.
Message-ID: <318E6F3C.17F4@gpsys.com>

I have been hunting around for several days for
a Java development environment suitable for a
realtime embedded system, preferably a 68k or i960-based
platform with a well-supported realtime operating system.
For performance reasons we'd like something that compiles
java bytecode into native instructions.

After extensive searching I have come up completely empty-handed.
Can anyone provide me with pointers to something along these
lines, or point me in the direction of someone who is working on
something like this?

Maybe I'm barking up the wrong tree, but this seems like a very
reasonable thing to want to do.

Thanks,

Shaun

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

Newsgroups: comp.os.vxworks
Subject: Any HTTP servers available on VxWorks?
Date: 29 Apr 1996 12:31:51 GMT
From: markham@bnr.ca (Andrew Markham)
Organization: Bell Northern Research
Message-ID: <4m2crn$41c@nrtphba6.bnr.ca>

My group has some interesting ideas for using HTTP in
our RT system and are wondering if anyone has ported
an HTTP server (preferably NCSA httpd) to VxWorks.

Any help will be greatly appreciated!

- --
Andy Markham
Nortel, Inc.

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

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

From jlao@istnet.com Tue May 7 05:58:21 1996
From: jlao@istnet.com
Date: Tue May 7 05:58:23 PDT 1996
Subject: Development Tools

I am looking for development tool for VxWorks which the target board is MIPS.
So far I have two candidates the StethoScope from Real-Time Innovations, Inc.
and the Insight from the Parasoft. Is there anybody use these tools.
Or is there other tools that provides better error catching capabilities.

Thanks,

James

From aitech@rugged.com Tue May 7 10:05:19 1996
From: aitech@rugged.com (Aitech )
Date: Tue May 7 10:05:22 PDT 1996
Subject: Re: Ruggedized VME boards?
>
>
> Can someone point me to a collection of information on ruggedized
> VME single board computers?
>
> We are currently in need of a ruggedized Motorola MVME-162 card
> or something as similar as possible. A WRS board support package
> must be available for it. There is no need for military standard
> components; commercial boards will be adequate.
>

I suggest that you take a look at the Aitech line of rugged VME boards.
You can llok them up in

 http://www.rugged.com

The C140 model is quite similar to the 162 you mentioned, and there is a
VxWorks BSP available.

Daniel Kord
Aitech

From fchen@mpl.ucsd.edu Tue May 7 19:29:08 1996
From: fchen@mpl.ucsd.edu (Hsiufang Chen)
Date: Tue May 7 19:29:11 PDT 1996
Subject: Re: Returned mail: Cannot send message for 3 days
Hi,

Barnacle is back to the network now. Please resend your mail to him.

Fang

> From Mailer-Daemon Thu May 2 18:00:24 1996
> Received: by chiton.ucsd.edu (5.x/SMI-SVR4-UCSD.1)
> 	id AA13331; Thu, 2 May 1996 18:00:24 -0700
> Date: Thu, 2 May 1996 18:00:24 -0700
> From: Mailer-Daemon (Mail Delivery Subsystem)
> Subject: Returned mail: Cannot send message for 3 days
> To: Postmaster
>
> ----- Transcript of session follows -----
> 421 barnacle: Host barnacle is down
>
> ----- Message header follows -----
> Return-Path: <root@csg.lbl.gov>
> Received: from csg.lbl.gov by chiton.ucsd.edu (5.x/SMI-SVR4-UCSD.1)
> 	id AA21526; Mon, 29 Apr 1996 17:19:08 -0700
> Errors-To: vxwexplo-errs@lbl.gov
> Received: by csg.lbl.gov (4.1/1.39)
> 	id AA04312; Mon, 29 Apr 96 16:56:01 PDT
> Date: Mon, 29 Apr 96 16:56:01 PDT
> Message-Id: <9604292356.AA04312@csg.lbl.gov>
> Errors-To: vxwexplo-errs@lbl.gov
> To: vxworks_users@csg.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: Re: once more plz: How do you time a piece of code?
>

From daemon@csg.lbl.gov Wed May 8 04:00:23 1996
From: daemon@csg.lbl.gov
Date: Wed May 8 04:00:32 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Wed May 8 04:00:19 PDT 1996

 Subject: VxMP Shared Memory Objects - Performance
 Subject: Re: Multibyte wide char support
 Subject: Minimum VxWorks Size?

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

Newsgroups: comp.os.vxworks
Subject: VxMP Shared Memory Objects - Performance
Date: 29 Apr 1996 22:33:15 GMT
From: Jorge Rodriguez <jorge@bnr.ca>
Organization: stp
Message-ID: <4m3g3b$nb0@nrtphba6.bnr.ca>

Good Day,

Has anyone out there had any experience with the optional package
VxMP -- Shared Memory Objects.

I am interested in using it on a PPC architecture & am looking
for some performance information on the package.

Also any comments about the product are also appreciated.

Thanks in advance,

 _________________________
 | Jorge Rodriguez |
 | Bell Northern Research |
 /) (919) 991-4638 (\
 / ) Email:Jorge@bnr.ca ( \
 _( (|_________________________) ) />
 (((\ \) /,) / ) / //))/
 (\\\\ \_/ / \ \_/ /////
 \ / \ /
 \ _/ \_ /
- ----/ /----------------------\ \----
 / / \ \

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

Newsgroups: comp.os.vxworks
Subject: Re: Multibyte wide char support
Date: 6 May 1996 22:15:58 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4mmmae$r9r@idiom.com>
References: <9605050206.AA29130@seaweed.com>

In article <9605050206.AA29130@seaweed.com>,
bob schulman <bob@seaweed.com> wrote:
> I don't know, but I guess
>that no Unix vendor's implementation of mblen includes -1 as a legal return
>value.

The -1 is one of the correct return values for mblen().
It is an error indication when illegal character is passed.
Whether WRS implements this correctly or not, I don't know.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Minimum VxWorks Size?
Date: Tue, 07 May 1996 06:57:25 -0700
From: Todd Hoff <tmh@possibility.com>
Organization: Possibility Outpost
Message-ID: <318F56C5.3FCB@possibility.com>

What is the smallest size you have gotten
a VxWorks image? There seems to be much confusion
on this issue :-) We don't need IP, BOOTP, etc.,
keeping core services, and 100K seems to be the
smallest it will go. This seems too large.

- -------------------------------------------------------------
tmh@possibility.com | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
 | pride. - Michael Kube-McDowell

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

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

From ztf@one.one.com Wed May 8 05:12:20 1996
From: ztf@one.com (Zachary T. Frey)
Date: Wed May 8 05:12:24 PDT 1996
Subject: Re: Development Tools

>I am looking for development tool for VxWorks which the target board is MIPS.
>So far I have two candidates the StethoScope from Real-Time Innovations, Inc.
>and the Insight from the Parasoft. Is there anybody use these tools.
>Or is there other tools that provides better error catching capabilities.

Does Insight now support VxWorks? I looked at them earlier this year,
and the only real-time OS they said they supported was LynxOS.

Could you post or email a contact for Real-Time Innovations about
StethoScope? I'd be interested in learing more about them.

Another test tool for VxWorks is C-Cover from Bullseye Testing Technology
(info@bullseye.com, (800)-278-4268). C-Cover provides coverage analysis
of code, just like the TCA (Total Coverage Analysis) module of Insight.

Thanks,

Zach

--
 Zach Frey
 Open Networks Engineering, Inc. (ONE) Voice: (313) 996-9900 x 1227
 777 E. Eisenhower Parkway, Suite 650 Fax: (313) 996-9908
 Ann Arbor, MI 48108 Internet: ztf@one.com

From andyg@emass.com Wed May 8 06:49:33 1996
From: Andy Gross <andyg@emass.com>
Date: Wed May 8 06:49:36 PDT 1996
Subject: Re: comp.os.vxworks newsdigest
Todd Hoff wrote:
> Subject: Minimum VxWorks Size?
>
> What is the smallest size you have gotten
> a VxWorks image? There seems to be much confusion
> on this issue :-) We don't need IP, BOOTP, etc.,
> keeping core services, and 100K seems to be the
> smallest it will go. This seems too large.
>

I couldn't even get it that small. I think the smallest
I got was 160K, and I tried to strip it all out. I'm
sure my problem has to do with being on an i960 and
having the gnu libraries linked in. If you have any
call into the library it seems to cascade into a huge
linking. Oh, I'm using Tornado (VxWorks 5.3).

I figure when we move out of debug into production I'll
be able to reduce it some: I'd be happy (and surprised)
if I could get it under 100K.

BTW, Wind River quotes a minimum size of 40K. I'm wondering
what processor that was on and if there's any debug support
in it (target agent?).

Andy

--
Andy Gross EMASS
Senior Software Engineer 10949 E. Peakview Ave.
E-Mail: andyg@emass.com Englewood, CO 80111
 (303) 705-3762

From seaweed!seaweed.com!bob@netcom.com Wed May 8 07:44:01 1996
From: bob schulman <bob@seaweed.com>
Date: Wed May 8 07:44:04 PDT 1996
Subject: Re: Multibyte wide char support
> The -1 is one of the correct return values for mblen().
> It is an error indication when illegal character is passed.
> Whether WRS implements this correctly or not, I don't know.
My SunOS man page for mblen says that -1 is returned "if they [the
passed characters of the string] do not form a valid multi-byte character".
A string of a simple ASCII character, especially in the "C" locale,
*does* constitute a sequence of valid multi-byte characters.

So I am still befuddled how simply returning -1 can be a reasonable
implementation of mblen().

In any event, calling mblen() with a NULL string should never return
-1 (which is what Wind River's implementation illegally does).

bob

From jlao@istnet.com Wed May 8 11:27:22 1996
From: jlao@istnet.com
Date: Wed May 8 11:27:26 PDT 1996
Subject: Re[2]: Development Tools

Zach,

>Could you post or email a contact for Real-Time Innovations about
>StethoScope? I'd be interested in learing more about them.

The Real-Time Innovations address is 954 Aster, Sunnyvale CA 94086
 tel (408)720-8312 Fax (408)720-8419.
The stethoScope is a collection of utilities and tools that it
easier to use and debug you VxWorks application. This is what
it says on the brochure. This is similar
to windview basically-I think.

Thanks for the info on Bullseve.

Best regards,
James

From stan@rti.com Wed May 8 11:45:08 1996
From: Stan Schneider <stan@rti.com>
Date: Wed May 8 11:45:12 PDT 1996
Subject: Re: Development Tools

Hi,

>> Submitted-by ztf@one.one.com Wed May 8 05:12:20 1996
>> Submitted-by: ztf@one.com (Zachary T. Frey)
>>
>> Could you post or email a contact for Real-Time Innovations about
>> StethoScope? I'd be interested in learing more about them.
>>

That would be us! We market many tools for VxWorks, including:

 StethoScope: Real-time graphical monitoring and data acquisition
	Use StethoScope to watch any of your program variables evolve in real
	time; any value in memory can be monitored. StethoScope opens a window
	into your application and shows you what's really happening. It
	collects and saves data, exports to analysis tools (e.g. Matlab), etc.

 ScopeProfile: Real-time dynamic execution profiler
	ScopeProfile shows you exactly where you're spending your CPU cycles.
	It gives you an in-depth hierarchical analysis of each subroutine's CPU
	utilization.

 RTILib: A collection of focused utilities and debugging tools
	RTILib tools include memory analysis and leak detection, a re-entrant
	shell, execution tracing, fast buffer management, and more. New for
	tornado (available soon) is a "networking" package that works through
	the net or the target server, target-based remote symbol-table access
	and dynamic loading, etc.

 [ScopeProfile & RTILib are included free with StethoScope.]

 ControlShell: The component-based real-time programming system
	ControlShell is a graphical software composition environment for
	complex real-time applications, the result of years of joint research
	with Stanford University. ControlShell users build system from small
	reusable objects called "components." It especially targets the
	electro-mechanical systems market.

 NDDS: The Network Data Delivery Service; an advanced dissemination
 	 architecture for real-time networking.
	NDDS lets many diverse nodes communicate easily with no network
	programming. NDDS makes it easy to develop complex communication and
	data interactions. And NDDS implements a true real-time model, so it
	won't impact real-time performance of its client nodes. It delivers
	the needed information, on time, with minimal programmer effort.

For more information, contact "info@rti.com," check out our web page at
"http://www.rti.com," or call (408) 720-8312.

 -- Stan

=============================================================================
= = =
= Stan Schneider = email: stan@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 ceselsa@coastalnet.com Wed May 8 12:27:56 1996
From: ceselsa@coastalnet.com (Carlos Martinez)
Date: Wed May 8 12:27:59 PDT 1996
Subject: VxWorks V5.3Beta & FORTRAN

Is anybody out there using VxWorks V5.3 Beta with a Fortran
compiler in a VME PowerPC Board? I would like to swap info
about that.

Carlos Martinez,
ceselsa@coastalnet.com
(919) 466-9133
Cherry Point, NC.

From stan@rti.com Wed May 8 12:34:35 1996
From: Stan Schneider <stan@rti.com>
Date: Wed May 8 12:34:39 PDT 1996
Subject: Re: Re[2]: Development Tools

>> Submitted-by jlao@istnet.com Wed May 8 11:27:22 1996
>> Submitted-by: jlao@istnet.com
>>
>>
>> Zach,
>>
>> >Could you post or email a contact for Real-Time Innovations about
>> >StethoScope? I'd be interested in learing more about them.
>>
>> The Real-Time Innovations address is 954 Aster, Sunnyvale CA 94086
>> tel (408)720-8312 Fax (408)720-8419.

This is an old address, see below...

>> The stethoScope is a collection of utilities and tools that it
>> easier to use and debug you VxWorks application. This is what
>> it says on the brochure. This is similar
>> to windview basically-I think.

Argggh... StethoScope is not "similar" to WindView. We get this a lot; I've
appended our standard comparison...

 -- Stan

=============================================================================
= = =
= Stan Schneider = email: stan@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 =
= = =
=============================================================================

>> What is the difference between StethoScope and WindView?
>>
There is a superficial similarity---both graphically represent information
gathered from an executing VxWorks target---but there's very little real
functional overlap.

There are three "types" of visualization/analysis tools for VxWorks: a
source-level debugger (vxgdb/CrossWind), a real-time data monitor
(StethoScope), and a operating system visualization tool (WindView).

A debugger can be thought of as similar to a voltmeter. It measures static
values. It's nearly useless for finding peak values, occasional "glitches", or
time-dependent quantities like durations of events or noise characteristics.
StethoScope is like a digital oscilloscope; it displays all these with ease.
WindView is like a logic analyzer. It doesn't show analog values (program
variables), but it excels at displaying events, such as task switches,
semaphore activity, interrupts, etc.

In particular, StethoScope is a window into your *application*. You can view
any variable or memory location in your system. For example, you can see how
much overshoot your controller has, measure how long it took a door to close,
analyze noise in a sensor, or see how long a data queue is getting.
StethoScope will graphically display your data, collect it for analysis, and
save it to disk. StethoScope helps you understand what your program is doing.

WindView, on the other hand, allows you to visualize the relationships and
timing between operating system events. For example, you can measure how long
it took for an interrupt to execute, how much later that interrupt was
serviced, etc. It's also useful for watching and understanding task switching
activity: which tasks are running, why tasks are preempted, how long the task
switch took, etc. Issues like semaphore priority inversion, lock-outs, and
interrupt latency are easily revealed.

So, StethoScope shows you what your VxWorks application is doing, and WindView
shows you how VxWorks is running your application. There's a big difference.
There's almost nothing WindView can show that could be viewed with StethoScope
and vice-versa.

On another note, StethoScope also includes a dynamic execution profiler known
as ScopeProfile. ScopeProfile displays which routines in your system are using
the CPU, as a percentage of total CPU time. It's very useful for tuning your
application code for maximum performance. WindView is also useful for this
purpose, but it shows entirely different information. The tools are quite
complementary.

For example, if your problem is that your application is thrashing (spending
most of its time context switching), ScopeProfile will simply report that some
large percentage of the CPU is being spent in the kernel. It can show you
which kernel routines are active, but that may not be of much help. WindView
will show you which tasks are switching, and display the events (e.g.
interrupts) that are causing the switches.

On the other hand, if the problem is that you have one task with inefficient
code, WindView will only tell you that one task is running most of the time.
ScopeProfile will break down the individual routines within the task that are
burning the CPU in great detail. It will give you a direct map of what that
task is doing, what routines are being called, what routines they call, and
point out exactly where the inefficiencies are. ScopeProfile provides a
detailed function-by-function analysis.

So, both WindView and ScopeProfile will help tune the performance of your
code. However, they provide different perspectives: WindView offers precise
measurements of event timing, ScopeProfile provides a detailed analysis of
where your CPU time is being used.

From hjb@peacefulstar.oakland.ca.us Wed May 8 13:18:01 1996
From: "H.J. Bae" <hjb@peacefulstar.oakland.ca.us>
Date: Wed May 8 13:18:04 PDT 1996
Subject: Re: Multibyte wide char support
>
> > The -1 is one of the correct return values for mblen().
> > It is an error indication when illegal character is passed.
> > Whether WRS implements this correctly or not, I don't know.
> My SunOS man page for mblen says that -1 is returned "if they [the
> passed characters of the string] do not form a valid multi-byte character".

Exactly. I'm just pointing out that -1 is a possible and valid
return code for this function. Your original message implied it isn't.
Maybe it's just misunderstanding.

> So I am still befuddled how simply returning -1 can be a reasonable
> implementation of mblen().

All the newer library stuff, like SVID->ANSI multibyte stuff, is
probably from GNU or BSD libc. I don't know exactly which version
of mblen() (or mbtowc() which is really what's doing the work)
WRS has ported. However, WRS would not have written it from scratch,
so it's not entirely their fault. If anything, they can be accused
of not testing it thoroughly.

Also, WRS implementation (at least in 5.3 I have here) of mblen()
does not simply return -1. If you disassemble the code you will see
that it actually does something, and have other return values than
the -1. However, it certainly looks buggy to me.

> In any event, calling mblen() with a NULL string should never return
> -1 (which is what Wind River's implementation illegally does).

Agreed. GNU version (1.09 libc) correctly returns 0, as per ANSI 4.10.7.2.
Perhaps time to upgrade the library.

--
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

From grd@telco-nac.com Wed May 8 17:51:29 1996
From: "Gautam R. Desai" <grd@nad.telco.com>
Date: Wed May 8 17:51:32 PDT 1996
Subject: i960 coff to binary
I am trying to convert i960 coff file to binary. Does anyone know how
to. I tried objcopy but it complains about invalid bfd.

----------------------------------------------------------------------
	Gautam R. Desai				(510) 624-5676
	TELCO Systems, Inc.			email: grd@nad.telco.com
----------------------------------------------------------------------

From getker@cellstream.com Thu May 9 02:21:27 1996
From: getker@cellstream.com (Jim Getker)
Date: Thu May 9 02:21:30 PDT 1996
Subject: Re: i960 coff to binary

> I am trying to convert i960 coff file to binary. Does anyone know how
> to. I tried objcopy but it complains about invalid bfd.
>
Have you tried $(VX_HSP_BASE)/bin/$(VX_HOST_TYPE)/coffToBin? I'm using
vxWorks 5.2 under sun4 for the i960 and it seems to work OK.

Jim Getker
CellStream Networks Inc.
getker@cellstream.com

From daemon@csg.lbl.gov Thu May 9 04:00:41 1996
From: daemon@csg.lbl.gov
Date: Thu May 9 04:00:45 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Thu May 9 04:00:34 PDT 1996

 Subject: Re: TCP-IP Accelerator ???
 Subject: Suggestions for R6000 dev environment
 Subject: Re: Shared memory driver to HP-UX card interface
 Subject: Problems with fopen and NFS
 Subject: How many tasks have you run with?
 Subject: Re: Custom application under telnet
 Subject: Re: [Q]: fopen problem
 Subject: Re: exception messages
 Subject: Re: Changing default NFS perms. on create

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

Newsgroups: comp.realtime,comp.os.qnx,comp.os.vxworks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,vmsnet.networks.tcp-ip.misc,vmsnet.networks.tcp-ip.multinet,de.comm.protocols.tcp-ip,comp.arch.embedded
Subject: Re: TCP-IP Accelerator ???
Date: Wed, 1 May 1996 14:15:38 GMT
From: hmo@sep.hamburg.com (Helge Oldach)
Organization: Somebody Else's Problem
Keywords: TCP-IP Accelerator Card
Message-ID: <DqqCy2.En1@sep.hamburg.com>
References: <peedsDqCKBD.2nD@netcom.com>
Sender: hmo@sep.hamburg.com (Helge Oldach)

peeds@netcom.com (LataAndPd) writes:
| 	Does anyone know of any add-on accelerator cards for
| 	TCP/IP which will offload the system's TCP/IP load ?

Sure. There is a channel adapter board available from Cisco which
connects a high-end router directly to the mainframe's channel. With
newer software releases, this allows to offload TCP/IP protocol from NCP
but runs that on the CIP board.

| 	 - what are the typical issues in using such a card in your system ?

The main issue typically is that TCP/IP on the mainframe is pretty expensive
(both in term of CPU cycles and software costs) compared to Cisco's solution.

(To add another slightly off-topic interpretation of the question... :-))

Regards,
Helge
- --
Bumper sticker seen on the Data SuperHighway:
 Welcome to the Internet, now go home!
 <carrel@cisco.com>

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

Newsgroups: comp.arch.embedded,comp.realtime,comp.os.vxworks
Subject: Suggestions for R6000 dev environment
Date: Tue, 07 May 1996 19:19:24 GMT
From: bonnett@sunland.gsfc.nasa.gov (Joe Vitale)
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-ID: <4mo7ns$l94@post.gsfc.nasa.gov>
Reply-To: bonnett@sunland.gsfc.nasa.gov

Hello,

In the very near future we are going to be starting a new development
effort for an embedded system using an R6000 processor. We are
currently in the process of setting up our development lab and I would
like to try and get some advice and insight from others who have done
similar work. Here we go...

Our target hardware is an R6000 with a PCI bus interface. Since it
will be some time before the target hardware is available, we are
planning to purchase an Ultra PowerPC 603 (or 604) motherboard (with
PCI connectors) to allow us to being software development while
waiting for the target hardware to arrive.

We are planning on using VxWorks from Wind River for our operating
system. Since the new Tornado environment will not support our
hardware in time to meet our schedule, we are planning on using
Version 5.2 of VxWorks. We will buy VxWorks for the Ultra PowerPC
board and also purchase an upgrade to the R6000 for use when our
target hardware becomes available.

We are planning on using the Green Hills software development tools
hosted on a unix workstation (probably a sun solaris or dec alpha
machine). The interface between the GH host and the Ultra PowerPC
will be over an ethernet network while the interface to the target
hardware will be over a serial interface.

Can anybody highlight any potential gotchas with this proposed
environment? It appears that at the "high level" this approach will
work as intended. The problem is that at this stage it is hard to see
all the details that may come up to bite us.

Is anybody familiar with the RISCWatch interface supported by the
R6000 and PowerPC architectures? According to the Green Hills people,
their tools are a superset of the features available with just
RISCWatch. Can anyone confirm or deny this? Exactly what type of
capability is provided by this interface for performing
hardware/software debug?

I have about a hundred more questions slowly coming to the surface,
but I think I'll stop here and see what kind of responses I get. :)

Thanks for any help/advice/suggestions.

Joe

=================================================================
Joe Vitale, NASA Goddard Space Flight Center, the Hammers Company
 Check out "OOG, The Object Orientation Game" by MCM Productions
 A Windows polyform puzzle player - http://www.mcmprod.com/

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

Newsgroups: comp.os.vxworks
Subject: Re: Shared memory driver to HP-UX card interface
Date: 30 Apr 1996 23:14:31 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4m6vg7$46b@idiom.com>
References: <3186ABE3.3ED3@btg.com>

In article <3186ABE3.3ED3@btg.com>, Mike Campbell <campbell@btg.com> wrote:
>Got a 743i card running HP-UX 9.05 that needs to talk to a
>vxWorks (5.2?) card over VME. Has anyone implemented an interface
>to vxWorks backplane driver for this setup? does vxWorks even
>publish any docs on how to do this? all help much appreciated....

Usually this requires bp driver source code. Long ago, at WRS, I
wrote a version of bp driver for STREAMS TCP/IP in SVR3.2 Unix
running on MVME147. It was a complete rewrite.

For a BSD-derived networking kernel, such as HPUX, porting
existing bp driver is easier. Last time I ported the "tunnel"
driver to HPUX kernel for WRS, it took a couple of days
work. You just have to be careful about subtle differences
in mbuf and IP interface.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Problems with fopen and NFS
Date: Wed, 8 May 1996 16:04:06 GMT
From: Tom Fuda <fuda@norden.com>
Organization: Northrop Grumman Norden Systems
Message-ID: <Dr3GMv.Kv0@tron.bwi.wec.com>
Sender: usenet@tron.bwi.wec.com (USEnet News Poster)

I am developing a system which uses multiple 486 single board
computers. The processors communicate via Ethernet. One board posseses an
IDE drive on which the DOS filesystem has been mounted and exported via a
call to nfsExport. The other board does an nfsMount to obtain access to the
filesystem. I am attempting to open a file remotely from the second board
using fopen(filename, "a") and write a text string to the file. I am finding
that the "a" (append) access modifier does not appear to work, i.e. the
existing file is overwritten, rather than appended to. I am also seeing that
if an invalid path/file name is specified fopen does not return a null file
pointer as it should. Has anybody else seen these problems? WRS tech support
has not given me a satisfactory answer yet. Thanks in advance.

Thomas Fuda
Northrop Grumman Norden Systems
fuda@norden.com

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

Newsgroups: comp.os.vxworks
Subject: How many tasks have you run with?
Date: 8 May 1996 17:37:26 GMT
From: otteson@b4pph10b.bnr.ca (John Otteson)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <4mqm4m$fl6@nrtphba6.bnr.ca>

Has anybody experience with running over a thousand tasks
on VxWorks? Have you run into a practical upper limit?
2000? 3000? 4000? Obviously you'll run out of memory and
real time at some point. I am wondering if there are other
more subtle problems you encounter... Or does VxWorks just
keep humming right along?

Thank you,

- ---John
otteson@nortel.ca

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

Newsgroups: comp.os.vxworks
Subject: Re: Custom application under telnet
Date: 30 Apr 1996 23:46:04 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4m71bc$514@idiom.com>
References: <317FF665.41C67EA6@fore.com>

In article <317FF665.41C67EA6@fore.com>, Jeffrey D. Prem <jdp@fore.com> wrote:
>I'd like to run a custom application, not the VxWorks shell, when a
>user telnets to my device. Unfortunately, there doesn't seem to be an
>API that provides this capability. Has anyone succeeded in doing this
>without having to modify the VxWorks source?
>

VxWorks telnet doesn't provide API that provides such capability.
It's sort of hard-coded in the daemon to start the VxWorks shell.

What you can do, as an alternative, is to write a custom socket
program that listens/accepts on a different port. When someone
connects to you, you can then run your program of choice.
Remember, most telnet clients take extra argument (port #).
You can, for example, telnet to SMTP port and talk to sendmail
daemon directly to send email to someone, if you don't have
a Mail program.

Just an idea.
- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Re: [Q]: fopen problem
Date: 1 May 1996 12:20:30 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4m8dhu$qf5@idiom.com>
References: <johnx.830745866@wrs.com>

In my opinion, this is a bug.

It is a matter of consistency in the interface. Lacking that,
a detailed documentation that informs the users must be provided.
It's not entirely fair to characterize this as "pilot error."

I suspect that the right interface, consistent with how
FTP netDrv works, as well as how other file I/O (dos, rt11, etc.)
works is to implement rsh dependent part of netDrv to use
"cat >!" rather than "cat >". There is no compelling reason not
to, and it would have prevented inconsistent behavior (rsh file
I/O vs. all others). Not to mention confusion among users.

It is an unexpected side-effect of using rsh in netDrv that was
originally not anticipated. If the original implementor was
aware of this, "cat >!" would have been used. Ask Bob Cohen
if he knew this when he wrote it. I doubt he did.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Re: exception messages
Date: 1 May 1996 12:49:56 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4m8f94$rdv@idiom.com>
References: <199604261615.JAA05318@dvs18.hdvs.com>

In article <199604261615.JAA05318@dvs18.hdvs.com>,
Wim Dewilder <wdewilde@hdvs.com> wrote:
>
>on 68K type boards, the kernel can store exception messages starting at
>address 0x800 upto address 0x900
>Like once we got a "Kernel Panic" message in this location.
>It seems the kernel writes an ASCII string in these memory locations.

In configAll.h (in config/all directory), is definition for this
offset 0x800 called EXC_MSG_OFFSET. It is located after
the bootline storage area at offset 0x700.
Kernel will write critical error messages in that area when
serious errors (i.e. work Q overflow) happens.

>
>Is there any information available on which messages could be stored there,
>and how they are stored.

You can just sprintf() into the memory.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Re: Changing default NFS perms. on create
Date: 1 May 1996 12:57:23 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4m8fn3$rl1@idiom.com>
References: <1996Apr30.100900.24586@hrbicf>

In article <1996Apr30.100900.24586@hrbicf>,
Michael E. Warren <m1w@icf.hrb.com> wrote:
>
>Is there a convenient was to change the default permissions used when
>a file is created on an NFS file system? When using the copy command,
>new files are created on the file server using the 644 permissions.
>Is there anything like the csh umask?
>

The default mask was a hard-coded value in old VxWorks.
This might have changed since 5.0 but I doubt it. No umask support
as far as I know.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

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

From gordon@tdf01.gsfc.nasa.gov Thu May 9 05:17:06 1996
From: Gordon Miller <gordon@tdf01.gsfc.nasa.gov>
Date: Thu May 9 05:17:09 PDT 1996
Subject: Re: Shared memory driver to HP-UX card interface

Mike Campbell <campbell@btg.com> wrote:

>Got a 743i card running HP-UX 9.05 that needs to talk to a
>vxWorks (5.2?) card over VME. Has anyone implemented an interface
>to vxWorks backplane driver for this setup? does vxWorks even
>publish any docs on how to do this? all help much appreciated....

You might want to talk with HP on this. They have a product for
the HP 700's called VME Backplane Networking. While it is meant
to be used HP-UX or HP-RT (derived from Lynx OS, a real time UNIX)
backplane master and HP-RT slaves, there is a possiblity that it
could be used in your setup. The latest manual I have on it (10/95,
software release 2.02) has (in addition to many others) a Wind River
Systems copyright.

I have not tried a VxWorks slave in my HP 748's. I have used multiple
HP 747's running HP-UX and communicating across the backplane without
too many problems. If you have any questions let me know.

--
Gordon Miller Integral Systems, Inc.
gordon@integ.com 1100 West Street, CSC/LR
(301) 497-2416 Laurel, MD 20707

Don't be afraid to take a big step. You can't cross a chasm
in two small jumps. -David Lloyd George

From goodrich@noao.edu Thu May 9 10:34:55 1996
From: goodrich@noao.edu (Bret Goodrich)
Date: Thu May 9 10:34:58 PDT 1996
Subject: POSIX threads
Hi All...

I am looking for a port of POSIX thread functions to VxWorks 5.2.
Does anyone have a reference for such a library?

Thanks,
bret
--------------------
Bret Goodrich, Gemini 8 Meter Telescopes Project, Tucson, Arizona, USA
Internet: goodrich@gemini.edu SPAN/HEPNET: noao::goodrich
Phonenet: 1.520.318.8522 Snailnet: PO Box 26732, Tucson, AZ 85726

From banta@cebaf.gov Thu May 9 11:50:02 1996
From: Paul Banta <banta@cebaf.gov>
Date: Thu May 9 11:50:07 PDT 1996
Subject: this may be crazy, but...
I have a colleague who wants to ingore bus errors. He has a couple of cards
out of a bunch that get too hot and stop responding to bus accesses. He's
attempted to cool the crate enough to operate, but, nevertheless, wants the
software to be able to recover from a bus error should one occur. Being the
resident VxWorks person he asked me to help him out.

Hence, the hack below. This is a little bit of code I put together to
test catching SIGSEGV and SIGBUS signals. The signal catching part works, but
the task that generates the bus error still gets suspended. I've browsed
through the online docs (VxWorks 5.2) looking at sigLib. I've tried using
setjmp & longjmp, but I think I'm misusing them. From the sigLib docs I
got the impression that I could prevent the task that generates the exception
from being suspended. Perhaps I just misunderstood?

Any insights?

Thanks,

Paul

/***********************************************
 * File: sigtest.c
 * Blame: Paul Banta banta@cebaf.gov
 * Date: 05-09-96
 * Note:
 *
 * Modification History:
 * 05-09-96 -- original version
 *
 *
 ***********************************************/

#include <vxWorks.h>
#include <sigLib.h>
#include <taskLib.h>
#include <setjmp.h>

/* external functions */
extern sysClkRateGet();

/* global variables */
static int bus_error_denial_count;
static int segv_denial_count;
static jmp_buf task_environment;

/* function to catch signals */
mySigHandler(signo, code, pSigContext)
 int signo;
 int code;
 struct sigcontext *pSigContext;
{
 /* recognizing denial is the first step toward recovery */
 switch(signo)
 {
 case SIGSEGV:
 segv_denial_count++;
 if (!(segv_denial_count % 5)) /* print warning every 5 signals */
	{
	 logMsg("denying %d segmentation faults is dangerous\n",segv_denial_count);
	}
 break;

 case SIGBUS:
 bus_error_denial_count;
 if (!(bus_error_denial_count % 5)) /* print warning every 5 signals */
	{
	 logMsg("denying %d bus errors is dangerous\n",bus_error_denial_count);
	}
 break;

 default:
 logMsg("this should never print\n");
 break;
 }

 longjmp(task_environment, 0);

}

/* lets make some bus errors */
void
myBusErrorGenerator()
{
 unsigned int *ptr;
 int data;
 int status;

 ptr = (unsigned int *)0xffff5000; /* use this address in short i/o */

 signal(SIGSEGV, (void *)mySigHandler);
 signal(SIGBUS, (void *)mySigHandler);

 FOREVER
 {
 taskDelay(sysClkRateGet());
 data = *ptr; /* this is going to crash */
 setjmp(task_environment); /* I don't think this is correct */

 }

}

/* initialize this system */
int
mySigTestInit()
{
 int status;

 status = taskSpawn("tBusErrorGen",
 100,
 VX_STDIO,
 1024,
 (void *)myBusErrorGenerator,
 0,0,0,0,0,0,0,0,0,0);

}

/* shutdown bus error generator */
mySigTestShutdown()
{
 int status;

 status = taskDelete (taskNameToId("tBusErrorGen"));
}

From lepage@ftms.com Thu May 9 12:31:30 1996
From: Rob Lepage <lepage@ftms.com>
Date: Thu May 9 12:31:33 PDT 1996
Subject: VME device access

I am having difficulty accessing a set of VME devices from an MVME1603 running
VxWorks 5.2. These devices are mapped in the VME 32 bit address space,
at a starting address of either 0x20000000 or 0x24000000. The actual number
of addresses used can range from 2 Meg up to 64 Meg.

To access these devices, I would like to map the A32 VME address range
0x20000000-0x27ffffff into the 1603 address range 0xd0000000-0xd7ffffff.

From looking at information in mv1600.h, I determined that by default,
64 Meg of the A32 VME space can be accessed by the 1603, starting at an
address of 0xd0000000. I tried increasing the amount of accessible
A32 VME space from 64 Meg to 128 Meg by redefining VME_WINDOW_A32_SIZE,
but could not get the modified kernel to boot. I also tried using two
64 Meg entries instead of one 128 Meg entry in the sysPhysMemDesc table,
but still could not get the kernel to boot. What else needs to be done
to increase the accessible address space?

Second, how can I change the accessible VME address range from the default
offset of 0x0 to the desired offset of 0x20000000?

Any help, including pointers to what sections of the FM to R, will be
greatly appreciated.

Rob Lepage
lepage@ftms.com

From pata@aisg.com Thu May 9 12:58:33 1996
From: pata@aisg.com (Pat Abruzzise)
Date: Thu May 9 12:59:16 PDT 1996
Subject: SW Engineering Openings
I have an urgent need for SW Engineers using Vx Works for a 5 month contract on
the west coast of Florida. Please contact

Pat Abruzzise
AISG
1 800 780-2598 or personal pager 1 800 570-0054

From YF.Siu@eng.efi.com Thu May 9 14:56:49 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Thu May 9 14:56:51 PDT 1996
Subject: Re: this may be crazy, but...
I think setjmp was misused, it should be something like:

	if (setjmp (task_environment) == 0)
	{
		/* do your stuff here */

	}
	else
	{
		/* from longjmp() in exception handler */
	}

You should not give longjmp a return value of 0, however,
longjmp will convert it to a 1 in this case.

See the man on setjmp and longjmp.

Good Luck,

YF

From jromine@phbtsus.com Thu May 9 16:22:27 1996
From: JEFF ROMINE <jromine@ns.phbtsus.com>
Date: Thu May 9 16:22:30 PDT 1996
Subject: Re: POSIX threads

> I am looking for a port of POSIX thread functions to VxWorks 5.2.
> Does anyone have a reference for such a library?

I am working w/ a company which has recently done a port of POSIX threads to
VxWorks. They may be able to help you out. They are:

Avalon Consulting
Denver, CO
(303) 293-9331

Talk to or send email to either:

Joy Foglesong (joy@ava.com)

or

Carole Hogan (carole@ava.com)

-Jeff Romine (Philips Broadcast Television Systems)

From emwlbi@mo.emw.ericsson.se Fri May 10 01:36:01 1996
From: emwlbi@emw.ericsson.se (FY/DX Lennart Bie)
Date: Fri May 10 01:36:06 PDT 1996
Subject: Re: VME device access

On Thu, 9 May 96 12:31 Rob Lepage wrote:

>I am having difficulty accessing a set of VME devices from an MVME1603 running
>VxWorks 5.2.
<snip>
>>From looking at information in mv1600.h, I determined that by default,
>64 Meg of the A32 VME space can be accessed by the 1603, starting at an
>address of 0xd0000000. I tried increasing the amount of accessible
>A32 VME space from 64 Meg to 128 Meg by redefining VME_WINDOW_A32_SIZE,
>but could not get the modified kernel to boot. I also tried using two
>64 Meg entries instead of one 128 Meg entry in the sysPhysMemDesc table,
>but still could not get the kernel to boot. What else needs to be done
>to increase the accessible address space?

I myself haven't had any problems getting the kernel to boot after I changed
the sysPhysMemDesc table. You get problems if you open a too big window
(256M or so) that will collide with other sysPhysMemDesc table entries.

>Second, how can I change the accessible VME address range from the default
>offset of 0x0 to the desired offset of 0x20000000?

Se below.

>Any help, including pointers to what sections of the FM to R, will be
>greatly appreciated.
>
>Rob Lepage
>lepage@ftms.com
>

I have had severe problems with VME addressing with MVME1604 in 5.2 FCS.
Note that the A32 window changes between 5.2 beta and the FCS.

Some of the address space became corrupted, especially when a bigger
VME window was opened in the sysPhysMemDesc table.
The problem showed up on addresses 16M above where I opened my window.
With the original code (FCS) the A32 space starts at 0xd8000000 (but
sysBusToLocalAdrs returns 0xd0000000!).

 - The processor adrs 0xd8000000 yields the VME adrs of 0x08000000

and it looks as you get monotonic increasing addresses as you increase
you processor address for 16M. But..

 - The processor adrs 0xd9000000 yields the VME adrs of 0x091ff000

up to 0xd9f00000 where it starts to be o.k. again (I think, haven't tested all
addresses). At 0xda000000 it starts to fail again and so on. The corrupt
addresses have 0x001ff000 or'ed into the VME address.

Such a faulty behaviour can also be found with the other addressing modes.

The problem seems to lay not within the vxWorks kernel but rather inside
the romInit.s routine in the bootrom! 5.3 solves the problem but only if
booted with a 5.3 boot routine (bootrom or boot.bin). Note that the
vxWorks kernel isn't setting up all related chips from scratch even if it
looks that way (the MMU, the BATS, the MPC 105, the Vme2PCI and the VMEChip2
chips), rather it is dependent on the banks being properly set up by either
romInit.s or the PPC-Bug (which probably does a better job at the time).

> Second, how can I change the accessible VME address range from the default
> offset of 0x0 to the desired offset of 0x20000000?

This is the way addresses gets translated (I think)

The processor address 0xd0000000 corresponds to the PCI address 0x10000000
which corresponds to the 040 bus address (between Vme2PCI and the VMEChip2) of
0x00000000 and the VME address of 0x00000000. Normally the Vme2PCI applies
an offset (0xffffffff - 0x10000000) which decreases the address by 0x1000000.
By manipulating this offset, PCI2VME_SLV2_OFFSE in mv1600.h, you could get
the desired VME starting address provided you stay within the window opened
by the VMEChip2 chip (0..0x7ffffff if I remember right)

Lennart Bie
emwlbi@emw.ericsson.se

From kindl@dreisoft.de Fri May 10 05:05:12 1996
From: Wolfgang Kindl <kindl@dreisoft.de>
Date: Fri May 10 05:05:22 PDT 1996
Subject: CAN driver
I am looking for a driver for intel 82527.
Does anyone have a (basic) CAN driver?

Thanks in advance.

 ------------------------------------------------------------
 | Wolfgang Kindl | phone +49-9131-7701-0 |
 | 3SOFT GmbH | fax +49-9131-7701-80 |
 | Wetterkreuz 19a | |
 | D-91058 Erlangen | e-mail kindl@DreiSoft.de |
 | Germany | |
 ------------------------------------------------------------

From jhillman@wrs.com Fri May 10 08:37:37 1996
From: Jon Hillman <jhillman@wrs.com>
Date: Fri May 10 08:37:40 PDT 1996
Subject: Any VxWorks module that supports RFC1305 (NTP) ?

>
>There is a need to synchronize the time of day for our VxWorks-based products
>which are interconnected in a subnetwork.
>
>Is there an implementation of the Network Time Protocol (NTP)
>that has been ported to VxWorks ?
>
>Version 2 or Version 3 NTP are OK.
>

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

From wbrown@csg.lbl.gov Fri May 10 09:02:50 1996
From: wbrown@csg.lbl.gov (Bill Brown)
Date: Fri May 10 09:02:53 PDT 1996
Subject: Re: Any VxWorks module that supports RFC1305 (NTP) ?

I think there is such a thing in the archives.

Information on the vxWorks archive is available by sending e-mail to
	vxworks_archive@ncar.ucar.edu
with the text
	send index
as the body of the message.

The VxWorks exploder archives is located at 'csg.lbl.gov' in '/pub/vxwexplo'.
nonymous login is permitted.

-bill
"duty mailing-list-grunt of the day"

From gquiroz@msmail3.hac.com Fri May 10 09:33:23 1996
From: "Quiroz, Gabriel" <gquiroz@msmail3.hac.com>
Date: Fri May 10 09:33:25 PDT 1996
Subject: socket buffer

I am trying to perform some non-blocking writes from a vxworks board to a
socket where the reader (highes priority application task) on another vxworks
board is suspended for a short period of time (This only happens on occasional
CPU spikes in the system). My writer task gets an EWOULDBLOCK error as
expected. My question is how I can increase the socket buffer size in vxWorks
5.2? I can't afford to have the writer block or try over and over again to
send the data.

In ../vw/h/net/socketvar.h I see a #define SB_MAX (64*1024) which indicates
the max chars in sockbuf. Is this where vxWorks gets its socket buffer sizes?
 Also, there is a socket structure called "socket" which I assume is used by
vxWorks to maintain the socket information. Does anyone know if I can access
this socket structure via some vxWorks pointer?

Any insight would be appreciated.

Gabriel Quiroz
Hughes Aircraft Co.
(619)543-4173
gquiroz@msmail3.hac.com

From espin@serval.kla.com Fri May 10 09:38:51 1996
From: espin@serval.kla.com (Geoffrey Espin x2496)
Date: Fri May 10 09:39:34 PDT 1996
Subject: RE: Suggestions for R6000 dev environment (really about PPC)
Joe,

> Subject: Suggestions for R6000 dev environment
> From: bonnett@sunland.gsfc.nasa.gov (Joe Vitale)
> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
>
> Our target hardware is an R6000 with a PCI bus interface. Since it
> will be some time before the target hardware is available, we are
> planning to purchase an Ultra PowerPC 603 (or 604) motherboard (with
> PCI connectors) to allow us to being software development while

I've been working with the VxWorks on the Ultra PPC604 for the last few months.
Migrating legacy s/w from VxWorks 5.2/68k to VxWorks 5.2/PPC went well.
Then upgrading to VxWorks 5.3/PPC-beta has been equally painless.
The BSP and drivers are better but still lack polish.

VxWorks has truly minimal support for PCIbus (mostly some header file
defines). A library to write to configuration space, find devices,
setup bridge(s), assign IRQs and memory, is needed (e.g. VxBIOS :-)).
There may be something happening on the VxWorks/x86 front at WRS (or
rather, a subcontractor of theirs) but it is not on the PPC.
I've written enough to support drivers for a couple of off-the-shelf boards
and a custom board -- but admittedly you end up hard-coding a certain amount.
Not exactly Plug 'n' Play. :-)

> system. Since the new Tornado environment will not support our
> hardware in time to meet our schedule, we are planning on using
> Version 5.2 of VxWorks. We will buy VxWorks for the Ultra PowerPC
>...
> We are planning on using the Green Hills software development tools
> hosted on a unix workstation (probably a sun solaris or dec alpha
> machine). The interface between the GH host and the Ultra PowerPC

WRS is only supporting GNU toolset in 5.3 (beta at least) which seems to
have its own set of problems for PPC. The DIAB Data worked fine in 5.2.
Always heard dubious reports about GH. Moving code back and forth
between 5.3 and 5.2 shouldn't be a big deal, so go with the latest
and greatest.

Using the PPC as an interim solution will be of only minor benefit to learn
about PCIbus configuration without BIOS. I would give VxWorks/x86 a try.

Geoff
--
Geoffrey Espin espin@idiom.com

From @lazarus.nrtc.northrop.com:wong@csd.nad.northrop.com Fri May 10 10:08:26 1996
From: "J. Pierre Wong" <wong@csd.nad.northrop.com>
Date: Fri May 10 10:08:40 PDT 1996
Subject: Z85C30 driver
I am looking for a driver for a Z85C30 Enhanced Serial Communications
Controller. Does anyone have or know of a simple driver that they
would be willing to share?

Thanks in advance.

Pierre Wong
Northrop Grumman
wong@csd.nad.northrop.com
tel: 310.332.6840
fax: 310.644.3652

From uchenick@bud.tate.com Fri May 10 10:30:01 1996
From: Gordon Uchenick <uchenick@bud.tate.com>
Date: Fri May 10 10:30:08 PDT 1996
Subject: Re: NTP support
>
>Is there an implementation of the Network Time Protocol (NTP)
>that has been ported to VxWorks ?
>
>Version 2 or Version 3 NTP are OK.
>

Try ftp.atd.ucar.edu
File is /pub/vxworks/ntp3.tar.gz

HTH,

Gordon
uchenick@tate.com

From johill@lanl.gov Fri May 10 10:32:04 1996
From: Jeff Hill <johill@lanl.gov>
Date: Fri May 10 10:32:13 PDT 1996
Subject: Re: socket buffer
This is a multi-part message in MIME format.

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

>
> Submitted-by gquiroz@msmail3.hac.com Fri May 10 09:33:23 1996
> Submitted-by: "Quiroz, Gabriel" <gquiroz@msmail3.hac.com>
>
> My question is how I can increase the socket buffer size in vxWorks
> 5.2?

try setsockopt() on parameters SO_SNDBUF and SO_RCVBUF

Jeff

--------------446B9B3D794BDF3215FB7483
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="signature"

______________________________________________________________________
Jeffrey O. Hill Internet johill@lanl.gov
LANL MS H820 Voice 505 665 1831
Los Alamos, NM 87545 USA FAX 505 665 5107

--------------446B9B3D794BDF3215FB7483--

From uchenick@bud.tate.com Fri May 10 11:28:40 1996
From: Gordon Uchenick <uchenick@bud.tate.com>
Date: Fri May 10 11:28:46 PDT 1996
Subject: Re: socket buffer
You can expand the socket buffer "on the fly" by using setsockopt(). I've
done this successfully many times. The following code chunks will give
you the basic idea. This code will not block the sending task. It's very
useful where one task is writing to many different sockets and can't
afford to block for any one of them.

int	buffSize;
int	intSize;
int	true = 1;
int	fd;
{
	.
	.
	.
	fd = socket(PF_INET, SOCK_STREAM, 0);
	ioctl(fd, FIONBIO, &true);
	intSize = sizeof(buffSize);
	getsockopt(fd, SOL_SOCKET, SO_SNDBUF, &buffSize, &intSize);
	.
	.
	.
	sendStuff(buff, nbytes)
	.
	.
	.
}

sendStuff(char *buff, int nbytes)
{
	int	bytesSent;

	if ((bytesSent = send(fd, buff, nbytes, 0)) == ERROR) {
		bytesSent = 0;
		if (errno == EWOULDBLOCK) {
			buffSize += nbytes;
			if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &buffSize,
					sizeof(buffSize)) == ERROR) {
				close(fd);
				return (ERROR);
			}
		}
		else {
			close(fd);
			return (ERROR);
		}
	else if (bytesSent == nbytes)
		return (!ERROR);

	return (sendStuff(buff + bytesSent, nbytes - bytesSent));
}

HTH,

Gordon

From smorgan@yurie.com Fri May 10 13:56:51 1996
From: smorgan@yurie.com
Date: Fri May 10 13:56:57 PDT 1996
Subject: Re: socket buffer

Take a look at setsockopt() SO_SNDBUF option. I think you will want to use
this. Also look at SO_RCVBUF and the TCP receive window implication.

Steve Morgan
smorgan@yurie.com

>I am trying to perform some non-blocking writes from a vxworks board to a
>socket where the reader (highes priority application task) on another vxworks
>board is suspended for a short period of time (This only happens on occasional
>CPU spikes in the system). My writer task gets an EWOULDBLOCK error as
>expected. My question is how I can increase the socket buffer size in vxWorks
>5.2? I can't afford to have the writer block or try over and over again to
>send the data.

>In ../vw/h/net/socketvar.h I see a #define SB_MAX (64*1024) which indicates
>the max chars in sockbuf. Is this where vxWorks gets its socket buffer
sizes?
>Also, there is a socket structure called "socket" which I assume is used by
>vxWorks to maintain the socket information. Does anyone know if I can access
>this socket structure via some vxWorks pointer?

From daemon@csg.lbl.gov Sat May 11 04:00:38 1996
From: daemon@csg.lbl.gov
Date: Sat May 11 04:00:43 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sat May 11 04:00:31 PDT 1996

 Subject: trackball for a 68k
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: Re: VxWorks v5.1.1 (tNetTask)
 Subject: Re: dosFs troubles...
 Subject: Re: vxMp with Reflective Memory
 Subject: Re: How do you make your code "faster"?

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

Newsgroups: comp.os.vxworks
Subject: trackball for a 68k
Date: 1 May 1996 20:57:18 GMT
From: isr@ix.netcom.com(Robert C. Smith)
Organization: Netcom
Message-ID: <4m8j7e$cce@dfw-ixnews3.ix.netcom.com>

We're running VxWorks 5.3 on a MVME162 (68040) with a MVIP302 octal
serial industry pack. Does anyone know of a source for a trackball
and drivers?

Thanks,

Bob Smith
ETEC Polyscan
520-806-3482
isr@ix.netcom.com

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Fri, 10 May 1996 21:50:56 GMT
From: tlewis@iadfw.net (Ted Lewis)
Organization: customer of Internet America
Message-ID: <4n06sj$v2f@news-f.iadfw.net>
References: <318E6F3C.17F4@gpsys.com>

You might want to check out www.isi.com
Look for the Java press release.
Integrated Systems has a Java/Embedded system solution.

Ted Lewis

Shaun Case <shaunc@gpsys.com> wrote:

>I have been hunting around for several days for
>a Java development environment suitable for a
>realtime embedded system, preferably a 68k or i960-based
>platform with a well-supported realtime operating system.
>For performance reasons we'd like something that compiles
>java bytecode into native instructions.

>After extensive searching I have come up completely empty-handed.
>Can anyone provide me with pointers to something along these
>lines, or point me in the direction of someone who is working on
>something like this?

>Maybe I'm barking up the wrong tree, but this seems like a very
>reasonable thing to want to do.

>Thanks,

>Shaun

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

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks v5.1.1 (tNetTask)
Date: 9 May 1996 22:44:37 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4mul45$2ca@idiom.com>
References: <31922B6A.160E@jpl.nasa.gov>

In article <31922B6A.160E@jpl.nasa.gov>,
Henry Valtier <Henry.Valtier@jpl.nasa.gov> wrote:
>(tNetTask): duplicate IP address!! sent from ethernet address: <..addr..>

This pretty much means what it says. When a network interface
is initialized (SIOCSIFADDR, setting its IP address), one of the
first things that happens is an "announcement" ARP. This is
to see if anyone else is using the same IP address on the same
network. If it receives an ARP reply, then it is due to another
host on the net having the same IP address. This is clearly
not desirable.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Re: dosFs troubles...
Date: Fri, 03 May 1996 01:30:25 GMT
From: mfisher@shore.net (Mark Fisher)
Organization: Shore.Net/Eco Software, Inc; (info@shore.net)
Message-ID: <4mbd3v$nje@shore.shore.net>
References: <199605011715.KAA10007@paris.efi.com>

"Yuet Fung Siu" <YF.Siu@eng.efi.com> wrote:

>The problem you described is very similar to the one I discovered last
>year with vxWorks 5.2. To confirm this, instead of using the shell,
>try to spawn a task, i.e., 'sp copy,"srcfile","desfile"', to do the
>copy and observe what is happening. If you discovered that the new
>task never exits and is always ready, that's it. If you do a 'tt' or
>so, you should find that the task is doing some hashLib or sllLib
>stuff.

>Since we have the source code to 5.2, I did find the bug in the dosFsLib.
>The problem was due to a hashList corruption inside the dosFsLib. I've
>reported the bug to WRS: SPR 4418. I don't think there's a work around
>without the source code. You may want to contact WRS and ask for a fix
>or patch.

>I'm just surprised that it takes so long before anyone else discover this.
>Probably noone else is using dosFsLib with 5.2 ??

I have found, and reported a number of problems to WRS concerning the
dosFsLib. As a result I have had more than a few updates sent to me.
As one tech support person said to me "dosFsLib is the only code we
are continually updating and pathcing in 5.2". Thus if anyone EVER
even suspects trouble with the dosFsLib then don't waste a lot of time
trying to debug it; instead get the latest version of dosFsLib from
WRS. If the problem persists after this, then you may need to do some
investigation. We use the disk a LOT in our system and I have found
the version I have now is quite stable.

The original poster had problems with IDE, I have only ever used SCSI,
so there could also be problems in the IDE drivers.

Mark Fisher

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

Newsgroups: comp.os.vxworks
Subject: Re: vxMp with Reflective Memory
Date: Thu, 02 May 1996 10:19:40 -0400
From: Fred Roeber <froeber@bbn.com>
Organization: BBN Systems and Technologies
Message-ID: <3188C47C.11524120@bbn.com>
References: <4m82q3$m3t@hammer.msfc.nasa.gov>

John Weir wrote:
>
> We have three VME-based vxWorks systems interconnected with a VMIC RMS
> system which replicates all data writes to an address range to the
> corresponding address in each system. We are considering using the vxMp
> product with this system to implement shared memory among our VME
> chassis. Has anyone tried this? How did it work? Thanks in advance for
> all replies?

I have used VxMP and VMIC reflective memories but never tried both
together. I would, expect, however that you would run into serious
problems in the area of synchronization and notification. At the
lowest levels, VxMP uses spin locks to synchronize access to critical
information in the shared VxMP memory areas and uses interrupts between
processors to signal when actions should be taken (eg semGive from one
processor to another). Further, VxMP normally places the shared
memory structures in local memory on the VME backplane master (ie
processor 0). To get what you want to work you would (at a minimum)
need to:
- - set it up so that the VxMP structures were all stored in the VMIC
 reflective memory.
- - Since you would have multiple VME chassis with their own backplane
 masters sharing the same VxMP structures, one of them would need
 to assume overall control of the area and set it up. The other
 processors in the system would end up waiting for first one to
 complete setup of area which would introduce some bad cross chassis
 dependency conditions
- - you would need to set up VxMP code to use VMIC cross chassis
 interrupts
- - you would need to replace the test-and-set logic used in the VxMP
 spin locks with something that would work over reflective memory.
 Since atomic operations are not supported on VMIC card locations
 as far as I remember, you would have to switch to some SW sync
 mechanism. From what I remember when I used to be able to look
 at the VxMP source, there was some way of using a SW synchronization
 scheme but it had terrible performance.

So my answer to the question is that with a lot of work and a source
license one could probably get VxMP to work over reflective memory.
Performance wouldn't be too good though. While this is an interesting
concept, I would suggest trying to use the reflective memory with other
mechanisms. The mechanism we normally use in managing our use of
reflective memories is the concept of ring buffers. These work
especially well if you have a consumer/producer situation with only a
single writer/single reader. BTW, one of the better books I have seen
on these issues is "Concurrent Programming, Fundamental Techniques
for Real-Time and Parallel Software Design" by Tom Axford (Wiley
publishers). Fred
- --
 | Fred J Roeber, BBN Systems & Technologies |
 | 50 Enterprise Place Middletown, RI 02842-5202 |
 | froeber@bbn.com 401-849-2543 (X48) |
 | See http://www.bbn.com/tv for TraceMaker info |

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

Newsgroups: comp.os.vxworks
Subject: Re: How do you make your code "faster"?
Date: Thu, 02 May 1996 10:25:14 -0400
From: Fred Roeber <froeber@bbn.com>
Organization: BBN Systems and Technologies
Message-ID: <3188C5CA.6E9DAAD9@bbn.com>
References: <johncoby-0105961511010001@ekm085.jsc.nasa.gov>

JOHN R. COBARRUVIAS wrote:

> My task required a rather high data collection rate, which after some
> trial and error I was able to accomodate. The analog boards were taking
> about 70u seconds to complete the data collection. I found the data
> transfer from the board to RAM was about 140u sec. I used the bcopy
> routine instead and the data transfer is now about 70u seconds. So.....now
> comes the question.......
>
> Is there any other generally known time savering hints, techiques,
> do's/don'ts, etc I can use?

There are lots of ways to get faster data transfer but they usually
depend on the board and CPU you are using. One simple thing is to
make sure data areas are aligned on good boundaries (ie 16 byte)
and you are moving large data blocks. bcopy will run faster (on
68K CPUs at least) under these conditions. To get more speed you
need to look at using DMA engines on your CPU and block transfers
if you are working with VME boards. Fred

- --
 | Fred J Roeber, BBN Systems & Technologies |
 | 50 Enterprise Place Middletown, RI 02842-5202 |
 | froeber@bbn.com 401-849-2543 (X48) |
 | See http://www.bbn.com/tv for TraceMaker info |

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

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

From daemon@csg.lbl.gov Sun May 12 04:00:43 1996
From: daemon@csg.lbl.gov
Date: Sun May 12 04:00:49 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sun May 12 04:00:35 PDT 1996

 Subject: Re: Any HTTP servers available on VxWorks?
 Subject: Re: Bit-fields and byte/word access on 68K
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: Re: VXWORKS on the HP ????
 Subject: Re: Q: Producing boot proms for MVME167
 Subject: Re: i960 RP board with high speed serial
 Subject: Unaligned data in MIPS bootrom
 Subject: Looking for a Synchronous z8530 Driver?
 Subject: MVME167/162 DMA question.
 Subject: How to determine current memory usage

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

Newsgroups: comp.os.vxworks
Subject: Re: Any HTTP servers available on VxWorks?
Date: 2 May 1996 18:53:08 GMT
From: alexm@vlsi19.gsfc.nasa.gov (Alex Measday)
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-ID: <slrn4oi14l.8qu.alexm@vlsi19.gsfc.nasa.gov>
References: <4m2crn$41c@nrtphba6.bnr.ca> <3185165F.41C2@ucar.edu>

Joe Van Andel wrote:
 >
 > [Bob Van Andel] has an HTTP server specifically designed
 > for small, real-time systems.
 >

Sounds like nepotism to me! :)

You also might try writing your own HTTP server; the HTTP protocol is
fairly simple. I run a Tcl-based HTTP server on our VxWorks system.
In addition to supporting normal file transfers, the server can also
access information in global memory regions and dynamically generate
HTML status pages for our various subystems. You can see this server
in action at:

 http://vlsi19.gsfc.nasa.gov:8224/software/gentle/hope.html

========================================================================
| Alex Measday Code 521 - Microelectronic Systems Branch |
| Integral Systems, Inc. NASA Goddard Space Flight Center |
| alexm@vlsi.gsfc.nasa.gov Greenbelt, MD |
========================================================================
) http://vlsi22.gsfc.nasa.gov/~alexm/ (
========================================================================

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

Newsgroups: comp.os.vxworks
Subject: Re: Bit-fields and byte/word access on 68K
Date: Fri, 10 May 1996 14:41:34 -0400
From: Kevin Rice <kevin@vlsi.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Message-ID: <31938DDE.2DB6@vlsi.gsfc.nasa.gov>
References: <31922C57.5224@cliffy.lmtas.lmco.com> <31934B07.6E6D@bnl.gov>

Gonzalo Maldonado wrote:
>
> Shash Chatterjee wrote:
> >
> > Hi!
> >
> > I'm trying to use bit-fields to access registers on a
> > VMIC VMIVME-3123 A/D board.
>

Don't use bit-fields. They aren't portable. Every
compiler does them differently.

It's fine to use them if you are doing some high-level
abstract data type but when talking to hardware
skip 'em.

Just go with ptrs & masks. Use macros to make things
look nice & structures to map to a devices memory map
to keep things relatively abstract.

Also you could out & grab linux/netbsd/freebsd source
and look at a few drivers to see how the masters
do it.

Kevin Rice

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Fri, 10 May 1996 12:12:31 -0700
From: gumby@cygnus.com (D.V. Henkel-Wallace)
Organization: Cygnus Support
Message-ID: <gumby-1005961212310001@gumbymac.cygnus.com>
References: <318E6F3C.17F4@gpsys.com> <318F1DE5.A8@lmtas.lmco.com> <319127A1.3F03@oro.net>

> I have been hunting around for several days for
> a Java development environment suitable for a
> realtime embedded system, preferably a 68k or i960-based
> platform with a well-supported realtime operating system.
> For performance reasons we'd like something that compiles
> java bytecode into native instructions.

Cygnus Support has started work on a new Java front-end
for Gcc. This will be a portable optimizing compiler for
Java byte-code files (initially) as well as Java source
files. We also intend to enhance gdb (the GNU debugger)
to fully support Java.

As I'm sure you know, the GNU development tools already support
cross-compilation for 68k and i960 running in many embedded
systems, to a large part due to the work we've put into this
area, as well as the work of volunteers around the net.

Of course a Java compiler needs to target a Java run-time system,
even if the compiler is generating machine code. There is no
 portable Java run-time system yet. Sun's JDK is difficult to
port, and its license is also a problem. It's alsowell-known
to be inappropriate for deeply embedded systems. The Kaffe
run-time system for Java looks promising. However,it is
currently limited to x86-based systems (though that will
change soon).

> Maybe I'm barking up the wrong tree, but this seems like a very
> reasonable thing to want to do.

We agree, that is why we are doing it.

Regards,
David Henkel-Wallace
Cygnus Support

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

Newsgroups: comp.os.vxworks,comp.sys.hp.hpux
Subject: Re: VXWORKS on the HP ????
Date: 03 May 1996 07:20:35 -0400
From: dave@sanders.com (Dave Uhrenholdt)
Organization: Sanders SSD
Message-ID: <m1ybnahukc.fsf@cushing.nowhere.com>
References: <31815875.2BB7@phbtsus.com>
	<partin-300496065951@l14ee.jsc.nasa.gov>
Sender: dave@cushing.nowhere.com

In article <partin-300496065951@l14ee.jsc.nasa.gov> partin@heman.jsc.nasa.gov (Charles Partin) writes:

 In article <31815875.2BB7@phbtsus.com>, Aseem Bakshi <Abakshi@phbtsus.com>
 wrote:

 > Hi,
 >
 > Under Sun Solaris it is possible to run Vxworks. Is it possible to do
 > the
 > same with HP/UX ?????
 >

 We run VxWorks 5.2 under HPUX 9.05 on a 9000/755 with no problems.

 > Are there any other options available to run real time under Hp/UX ???
 > Thanks Aseem

 I am sure there are other real-time systems (pSOS, VTRX, etc) running on
 HP's. I have never had the need to look for them.

HP has a product called HP-RT which is a repackaging of LynxOS.

Dave

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

Newsgroups: comp.os.vxworks
Subject: Re: Q: Producing boot proms for MVME167
Date: 4 May 1996 00:01:57 -0400
From: thesharps@aol.com (THE SHARPS)
Organization: America Online, Inc. (1-800-827-6364)
Message-ID: <4mekrl$pvm@newsbf02.news.aol.com>
References: <4m80o6$5cg@geraldo.cc.utexas.edu>
Reply-To: thesharps@aol.com (THE SHARPS)
Sender: root@newsbf02.news.aol.com

When you recreate the bootrom image in motorola s record format, you will
get a single file called bootrom.hex. This single file must then be
uploaded into a prom burner memory which is properly configured to write
the even addresses to one prom and the odd to the other. Hope this helps.

Tim Sharp
Cambridge Parallel Processing
tsharp@cppus.com

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

Newsgroups: comp.os.vxworks
Subject: Re: i960 RP board with high speed serial
Date: 4 May 1996 00:02:05 -0400
From: thesharps@aol.com (THE SHARPS)
Organization: America Online, Inc. (1-800-827-6364)
Message-ID: <4mekrt$pvo@newsbf02.news.aol.com>
References: <9604301349.AA22785@denoon.positron.med.ge.com>
Reply-To: thesharps@aol.com (THE SHARPS)
Sender: root@newsbf02.news.aol.com

Mike,

Check with VMETRO. They are now in the board business in addition to
logic analyzers, and are currently developing MIDAS boards using the
i960RP chip with a at least two PMC slots. They are also working on a
version to connect to the RaceWay if that interests you. Do not expect
these boards until July-August time frame. Hope this helps.

Tim Sharp
Cambridge Parallel Processing
tsharp@cppus.com

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

Newsgroups: comp.os.vxworks
Subject: Unaligned data in MIPS bootrom
Date: Fri, 10 May 1996 17:19:59 -0400
From: Jeff Daly <jjdaly@rapnet.sanders.lockheed.com>
Organization: Sanders, A Lockheed Martin Co.
Message-ID: <3193B2FF.C28@rapnet.sanders.lockheed.com>

hi all,
	i'm attempting to compile a bootrom for an R4X00 board.
	i'm using vxWorks 5.2b, and the sde-mips toolset for
	solaris 2.x

	my first attempt to run the boot code resulted in an
	exception which i decoded as an address error (load).
	after jumping to romStart(), the data section is
	copied from _etext to DRAM. dumping the symbol table
	for the bootrom, i saw where my problem was:

	bfc40c80 r __ctype_tab
	bfc421c5 r strayString
	bfc42942 r cacheMsg
	bfc435b9 A _etext
	bfc435b9 A etext

	the end of text is at an unaligned address, so the first
	read causes an error.

	i couldn't find any information for the tools that said
	anything about alignment of read-only data sections.
	attempting to hack in some dummy variables didn't work,
	it just put them before __ctype_tab and the _etext symbol
	was unaligned at a different address. i'd rather not
	muck with the vxWorks source code itself, just fix the
	bootrom build. does anyone have any suggestions??
- --
************************************************************************
*arrh, thar be disclaimers ahead! \daly@rancid.sanders.lockheed.com*
*opinions expressed here are entirely | *
*mine and do not represent those of the|"Me on the cover of a mag?, *
*largest defense contractor on earth. / *
************************************************************************

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

Newsgroups: comp.os.vxworks
Subject: Looking for a Synchronous z8530 Driver?
Date: 2 May 1996 17:20:27 GMT
From: mtj@space.mit.edu (Tim Jones)
Organization: MIT Center for Space Research
Message-ID: <4maqsr$80m@senator-bedfellow.MIT.EDU>
Reply-To: mtj@space.mit.edu

Has anyone updated the WRS supplied z8530 SCC driver for synchronous
communication (as supplied it supports only async), and if so would they
mind sharing tips (or source)?

I'm running Ver5.2-beta on a PowerPC MVME1603.

Thanks,

M. Tim Jones
AeroAstro Corp.

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

Newsgroups: comp.os.vxworks
Subject: MVME167/162 DMA question.
Date: 3 May 1996 21:16:40 GMT
From: srejto@ll.mit.edu (Stephen Rejto)
Organization: MIT Lincoln Lab
Message-ID: <4mdt3o$287@llnews.ll.mit.edu>

We are using MVME167s and 162 to DMA local moto memory into into a
VME slave memory.

We are doing D64 MBLT transfers and are seeing very poor rates.
~28 MB/S. It appears that every 8 transfers (64 bits) the motorola board
is getting off teh BUS and then back on. The manual says that the DMAC
will get off teh bus if its FIFO goes dry.

Can this really be happening and how do I prevent it. Does anyone know teh
speed at which teh DMAC is proudcing data. (i.e. reading from local moto
memory).

It appears that our VME slave is faster then the DMA which causes
the DMA to release the BUS. YUCK! Every time it releases the bus it
causes a 1 usec latency.

DTACK times are about 140-150 ns.

ANY help appreciated.

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

Newsgroups: comp.os.vxworks
Subject: How to determine current memory usage
Date: Fri, 3 May 1996 15:53:08 -0700
From: Andy Van Pelt <avanpelt@qualcomm.com>
Organization: QUALCOMM, Incorporated; San Diego, CA, USA
Message-ID: <Pine.SOL.3.91.960503155240.10217E-100000@lennon.qualcomm.com>

 I would like to track memory usage from within a program, and have not
been able to find a routine to call to tell me this. memShow will display
the information I want, but I don't want the data displayed, I want to
store it and analyze it.

 How do I find out how much memory is currently allocated and how much is
free? I know how to find out the largest block that can be allocated
(memFindMax), but that's not quite the same.

 I hope the answer doesn't involve calling memShow and parsing
the output. That's gross!

- --
Andy Van Pelt Internet: avanpelt@qualcomm.com
QUALCOMM Inc. Work : 619) 658-3214

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

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

From phil@nevis.naic.edu Sun May 12 09:05:05 1996
From: phil@nevis.naic.edu
Date: Sun May 12 09:05:10 PDT 1996
Subject: RE:MVME167/162 DMA question.
Stephen Rejto writes:> From root@csg.lbl.gov Sun May 12 07:48:47 1996
>
> We are using MVME167s and 162 to DMA local moto memory into into a
> VME slave memory.
>
> We are doing D64 MBLT transfers and are seeing very poor rates.
> ~28 MB/S. It appears that every 8 transfers (64 bits) the motorola board
> is getting off teh BUS and then back on. The manual says that the DMAC
> will get off teh bus if its FIFO goes dry.
>
> Can this really be happening and how do I prevent it. Does anyone know teh
> speed at which teh DMAC is proudcing data. (i.e. reading from local moto
> memory).
>
> It appears that our VME slave is faster then the DMA which causes
> the DMA to release the BUS. YUCK! Every time it releases the bus it
> causes a 1 usec latency.
>
> DTACK times are about 140-150 ns.

When i tried D64 dma transfers between a mv167 and a mv162 I got about
28 mb/sec too. The dtack times were also around 100+ns. I talked to motorola
 about the dtack times and they said that is normal for a 25 Mhz vmechip2. A
33mhz mv167 should give about 80ns for dtack.

I went through the mv167/mv162,mv162fx manauls that i have and found the
following local bus i/o rates for burst transfers.

162fx: page 1-29 of the installation guide...

clocks		memory max i/o rate local bus
3,2,2,2		write 25mhz			44mb/sec
4,2,2,2		rd non-interleaved 25mhz 40mb/sec
4,1,1,1		rd interleaved 25mhz 57mb/sec

4,2,2,2 write 32mhz			52mb/sec
5,3,3,3		rd non-interleaved 32Mhz 36mb/sec
5,2,2,2		rd interleaved 32mhz 46mb/sec

mv167 programmers ref guide pg 4-1

clocks		memory			 max i/o rate local bus
2,1,1,1		 writes 25mhz 80mb/sec
4,1,1,1	 rd 25mhz 57mb/sec
5,1,1,1		rd 25mhz,with parity 25mhz 50mb/sec
(i'm not sure what the mv167 33mhz values are...)

mv162 prog. ref guide pg 3.5
clocks		memory			 max i/o rate local bus
3,2,2,2		write,25mhz			44mb/sec
4,2,2,2		rd,25mhz,non-intlv,no tea on pe 40mb/sec
4,1,1,1		rd,25mhz,intlv,no tea on pe. 57mb/sec
5,3,3,3		rd,25mhz,non-intlv, tea on pe 28mb/sec
5,2,2,2		read,intlv,tea on pe.		36mb/sec

4,2,2,2		write,33mhz			53mb/sec
5,3,3,3		rd,33mhz,non-intlv,no tea on pe 38mb/sec
5,2,2,2		rd,33mhz,intlv,no tea on pe	48mb/sec
6,4,4,4		rd,33mhz,non-intlv,tea on pe	29mb/sec
6,3,3,3		rd,33mhz,intlv,tea on pe	35mb/sec

As you can see, they vary a lot. Some memory configurations don't allow
interleaving. 28mb/sec would be a very respectable throughput for some of these
memory configurations. What caught me was that the mv162fx 33mhz board reads
 the memory slower than the 25mhz board!!!!

You are guaranteed that the i/o transfers out of the memory will not be
larger than these values. These times also assume a burst xfer (i'm not sure
if the vmechip2 does that for dma xfers).

So when you read all the nifty advertisements about 80mb/sec with D64 over the
vmebus, take it with a grain of salt....

phil perillat
arecibo observatory
phil@naic.edu

ps.
Another thing to be careful with is the local bus priorities which are hard
wired. We are using a mv162fx to xfer into the local memory
through the ip interface and eventually read the data out of memory over the
vmebus using D64 xfers. We are also getting an interrupt from the ip device at
the end of each block xfer. Things would work fine until the cpu tried to do
an iack cycle to the ip device. Since the cpu has the lowest priority on the
local bus, it would sometimes not get the iack cycle done in time if a
D64 xfer was active.

From aorad@netvision.net.il Sun May 12 12:38:22 1996
From: Amir Orad <aorad@netvision.net.il>
Date: Sun May 12 12:38:25 PDT 1996
Subject: Loading an object and calling its functions ...
Hi.

I'm trying to find an elegant way of solving the following problem :

I need to load at run-time an object and call one of its functions.

The problem is that I know the function's name only when I load the code.

My program is already running and knows the function's name after reading a
definition file (where the object name is also written)

Any ideas of how can I do it in an elegant way.

Right now, the only way to solve this (As I see it) is to use lkup in some
way and find the function's pointer according to its name (What will happen
if I have more than one function with that name ?).

BTW: The function's format is pre-defined, and should be of no problem.

------------------------------------------------------------------
			 Amir Orad
		E-Mail : aorad@netvision.net.il
------------------------------------------------------------------

From stan@rti.com Sun May 12 13:51:39 1996
From: Stan Schneider <stan@rti.com>
Date: Sun May 12 13:51:42 PDT 1996
Subject: Re: Loading an object and calling its functions ...

>>
>> I'm trying to find an elegant way of solving the following problem :
>>
>> I need to load at run-time an object and call one of its functions.

This is what symLib is for. Are you running a target-resident symbol table
(the default before 5.3)?

	-- Stan

From tja@radstone.co.uk Mon May 13 02:20:40 1996
From: Tim Allen <tja@radstone.co.uk>
Date: Mon May 13 02:20:55 PDT 1996
Subject: RE: Suggestions for R6000 dev environment (really about PPC)
Hi,

I missed the original mailing so I hope my comments won't be out of context.

>VxWorks has truly minimal support for PCIbus (mostly some header file
>defines). A library to write to configuration space, find devices,
>setup bridge(s), assign IRQs and memory, is needed (e.g. VxBIOS :-)).
>There may be something happening on the VxWorks/x86 front at WRS (or
>rather, a subcontractor of theirs) but it is not on the PPC.
>I've written enough to support drivers for a couple of off-the-shelf boards
>and a custom board -- but admittedly you end up hard-coding a certain amount.
>Not exactly Plug 'n' Play. :-)

I agree the PCI bus support is minimal and, for the code I looked at,
actually in contravention of the PCI spec. for some boards (SPR# 6490).
I've ported PowerPC 5.2 and 5.3/Tornado to the Radstone PPC603 & PPC604
PowerPC boards and included our own PCI configuration and access routines as
part of the BSP. These routines include probing and initialising all PCI
devices found on any bus as well as dumping/updating configuration space
etc. I have offered this source code to WRS for incorporation into VxWorks
as it complies with the PCI spec. and offers extra features.

>> system. Since the new Tornado environment will not support our
>> hardware in time to meet our schedule, we are planning on using
>> Version 5.2 of VxWorks. We will buy VxWorks for the Ultra PowerPC
>>...

The Radstone Tornado BSP is available now for use with the PowerPC beta test
release, and as I understand it the full Tornado release from WRS is not far
away (weeks?).

>> We are planning on using the Green Hills software development tools
>> hosted on a unix workstation (probably a sun solaris or dec alpha
>> machine). The interface between the GH host and the Ultra PowerPC
>
>WRS is only supporting GNU toolset in 5.3 (beta at least) which seems to
>have its own set of problems for PPC. The DIAB Data worked fine in 5.2.
>Always heard dubious reports about GH. Moving code back and forth
>between 5.3 and 5.2 shouldn't be a big deal, so go with the latest
>and greatest.

I used the Green Hills tools in 5.2 without much trouble and switched to GNU
in 5.3 also. There were a few compiler/assembler differences to sort out
but now real problems.

If you're interested in the Radstone PowerPC product please contact Radstone
Technology Corp. Montvale, NJ. email radstone@radstone.com or phone (800)
368 2738.

Regards,
Tim.

+------------------------------------------------------------------+
| Tim Allen phone: +44 (0)1327 359444 |
| Radstone Technology PLC, UK. fax: +44 (0)1327 358112 |
+------------------------------------------------------------------+

From mslifcak@hitel.com Mon May 13 05:16:41 1996
From: mike slifcak <mslifcak@hitel.com>
Date: Mon May 13 05:16:45 PDT 1996
Subject: Subscribe
subscribe

From froeber@bbn.com Mon May 13 06:43:50 1996
From: Fred Roeber <froeber@bbn.com>
Date: Mon May 13 06:43:52 PDT 1996
Subject: Re: Z85C30 driver
J. Pierre Wong wrote:
>
> I am looking for a driver for a Z85C30 Enhanced Serial Communications
> Controller. Does anyone have or know of a simple driver that they
> would be willing to share?

The Z8530 chip is a standard serial chip WRS supports. You should be
able to get a driver from them. The source for the driver comes with
at least some BSPs. Check the src/drv/serial directory in your VxWorks
distribution for the file z8530Serial.c (even object licenses to VxWorks
contain some source code in the src area). Fred

--
 | Fred J Roeber, BBN Systems & Technologies |
 | 50 Enterprise Place Middletown, RI 02842-5202 |
 | froeber@bbn.com 401-849-2543 (X48) |
 | See http://www.bbn.com/tv for TraceMaker info |

From aisie.aisinc.com!aisinc.com!tam@msen.com Mon May 13 07:54:22 1996
From: tam@aisinc.com (Tod More)
Date: Mon May 13 07:54:25 PDT 1996
Subject: Re: SW Engineering Openings
>
> Submitted-by pata@aisg.com Thu May 9 12:58:33 1996
> Submitted-by: pata@aisg.com (Pat Abruzzise)
>
> I have an urgent need for SW Engineers using Vx Works for a 5 month contract on
> the west coast of Florida. Please contact
>
> Pat Abruzzise
> AISG
> 1 800 780-2598 or personal pager 1 800 570-0054
>
Do you want people on site, or can the work be done remotly ?

Tod More.

From andyg@emass.com Mon May 13 09:50:38 1996
From: Andy Gross <andyg@emass.com>
Date: Mon May 13 09:50:41 PDT 1996
Subject: Re: Z85C30 driver
the vxWorks Users Group Exploder wrote:
>
> Submitted-by froeber@bbn.com Mon May 13 06:43:50 1996
> Submitted-by: Fred Roeber <froeber@bbn.com>
>
> J. Pierre Wong wrote:
> >
> > I am looking for a driver for a Z85C30 Enhanced Serial Communications
> > Controller. Does anyone have or know of a simple driver that they
> > would be willing to share?
>
> The Z8530 chip is a standard serial chip WRS supports. You should be
> able to get a driver from them. The source for the driver comes with
> at least some BSPs. Check the src/drv/serial directory in your VxWorks
> distribution for the file z8530Serial.c (even object licenses to VxWorks
> contain some source code in the src area). Fred
>

If you're using Tornado, then the driver is in src/drv/sio/z8530Sio.c. The
Upgrading BSP to Tornado uses that driver as a reference. It didn't come
with my BSP, but WRS sent it to me.

Andy

--
Andy Gross EMASS
Senior Software Engineer 10949 E. Peakview Ave.
E-Mail: andyg@emass.com Englewood, CO 80111
 (303) 705-3762

From bpsattler@anet.rockwell.com Mon May 13 10:58:12 1996
From: "Bradley P. Sattler" <bpsattler@anet.rockwell.com>
Date: Mon May 13 10:58:16 PDT 1996
Subject: Problems producing IEEE695 files from GNU ld linker

 Using the GNU "ld" linker (version number 1.97.1) to produce "ieee"
 output format files, error code 134 is output. The resultant file has
 symbol data in it, but no code.

 The linker seems to produce a.out, COFF, and srec output format files
 with no errors.

 The ld68k command line, and script file used are as follows:

 /app/green/ld68k -Ur -T script obj/ADC_ADC.o obj/ADC_Run_BIT.o ....
 -o coreofp -M >./coreofp/map

 contents of the script file:

 SECTIONS {
 .text : { *(.text) }
 .data : { *(.data) }
 .bss : { *(.bss) }
 }
 OUTPUT_FORMAT(ieee)

 Any ideas/similar experiences? Thanks.

 bpsattler@anet.rockwell.com

From ferrara@adissw.enet.dec.com Mon May 13 11:17:11 1996
From: "Bob Ferrara DTN:264-3094" <ferrara@adissw.enet.dec.com>
Date: Mon May 13 11:17:14 PDT 1996
Subject: RAM Disk questions...

Has anyone used a RAM Disk under VxWorks that supports
VMS style files?

I need to create a VxWorks RAM disk in my local memory
space in order to copy (probably via ftp) files from a
OpenVMS system (RMS file format).

I understand native VxWorks supports Dos, RT-11 and a Raw
file system.

Thanks for any comments,
Bob Ferrara
Digital Equipment Corporation

From ceselsa@coastalnet.com Mon May 13 14:27:26 1996
From: ceselsa@coastalnet.com (Carlos Martinez)
Date: Mon May 13 14:27:29 PDT 1996
Subject: VxWorks and FORTRAN
Is anybody out there using WSR VxWorks with a Fortran
compiler? I would like to exchange info. about that.

Carlos Martinez,
ceselsa@coastalnet.com
(919) 466-9133
Cherry Point, NC.

From erxatech@inrete.it Tue May 14 00:52:42 1996
From: erxatech@inrete.it (Paolo Magistris)
Date: Tue May 14 00:52:45 PDT 1996
Subject: 802.3 protocol
Hello,
I need to know is someone has information about 802.3 protocol on vxWorks.
Normally vxWorks is unable to manage 802.3 frame. There is a solution for
this lacks?
 Thank You
 Paolo Magistris
=================================================================
 _______
|E______| Engineering
|__R____| Robotics
|____X__| Control Systems
|______A| Applications

 Field Application Engineer Voice: +39-11-7412749
 Erxa S.r.l. Fax: +39-11-7412044
 via Morghen 22, 10143 Torino (ITALY)
 E-Mail: erxatech@inrete.alpcom.it

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

From AS_Bridge@msmail3.hac.com Tue May 14 03:31:25 1996
From: "AS Bridge" <AS_Bridge@msmail3.hac.com>
Date: Tue May 14 03:31:30 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: 802.3 protocol
Sent: Tue, May 14, 1996 2:28 AM
To: Haberman, Robert C
On Server: 631 Segment3
Date: Tue, May 14, 1996 3:31 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From daemon@csg.lbl.gov Tue May 14 04:02:04 1996
From: daemon@csg.lbl.gov
Date: Tue May 14 04:02:09 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Tue May 14 04:00:36 PDT 1996

 Subject: SCSI size configuration
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: DMA controller: L64853 & L64854
 Subject: gnu compiler native on vxWorks 68k?
 Subject: Re: trackball for a 68k

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

Newsgroups: comp.os.vxworks
Subject: SCSI size configuration
Date: Mon, 13 May 1996 10:56:33 -0500
From: Alan Currie <currie@ghgcorp.com>
Organization: NASA/Johnson Space Center
Message-ID: <31975BB1.4A57@ghgcorp.com>
Reply-To: currie@ghgcorp.com

I am switching from a 128Meg SCSI electronic recorder to a 500 Meg
SCSI hard disk. I changed the number of blocks to relect change in
config.h and rebuilt VxWorks. Number of blocks change shows up in
scsiShow as expected. However, I can only put the same amount of
stuff out on the disk that I did before. It still thinks I only
have 128 Meg of space. Any suggestions?

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Sun, 12 May 1996 20:12:10 GMT
From: markj@netaccess.co.nz (Mark Jordan)
Message-ID: <5d7cc$9d2c.363@mac.co.nz>
References: <318E6F3C.17F4@gpsys.com>

Shaun Case <shaunc@gpsys.com> wrote:

>I have been hunting around for several days for
>a Java development environment suitable for a
>realtime embedded system, preferably a 68k or i960-based
>platform with a well-supported realtime operating system.
>For performance reasons we'd like something that compiles
>java bytecode into native instructions.

>After extensive searching I have come up completely empty-handed.
>Can anyone provide me with pointers to something along these
>lines, or point me in the direction of someone who is working on
>something like this?

Do you realise that interpreted Java is about 20 times slower
in it's execution than standard C code?

Having said that, I think that SUN have developed a chip which
runs Java byte code directly. Not sure about it's performance
though.

Cheers,
Mark Jordan.

+----------------------------------------------------------------------+
| Mark Jordan | Never put off anything you can do today |
| Engineer | until tomorrow, because if you liked it, |
| markj@netaccess.co.nz | you can do it again tomorrow! |
+----------------------------------------------------------------------+

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

Newsgroups: comp.os.vxworks
Subject: DMA controller: L64853 & L64854
Date: 6 May 1996 02:13:01 GMT
From: ybpark@dokeby.sst.co.kr (Yun-Bo Park)
Organization: Samsung Advanced Institute of Technology
Keywords: DMA
Message-ID: <4mjn7d$bkq@noc.sait.samsung.co.kr>

I use L64854 as S-Bus DMA controller.
But I found there is a library for L64853, L64853Dma.c, in VxWorks 5.1.
Is there no problem to use the library ?

Thanks,

Yun-Bo Park

================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================
 SAMSUNG Electronics Co.,Ltd.		Fax: (02) 559-4314
 Daehwa Bldg, 169, Samsung-Dong,	Voice: (02) 559-4358
 Kangnam-Ku Seoul, Korea 135-090	Internet: ybpark@dokeby.sst.co.kr
================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================

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

Newsgroups: comp.os.vxworks
Subject: gnu compiler native on vxWorks 68k?
Date: 13 May 1996 17:32:20 GMT
From: Daniel Brodsky <danb@wrs.com>
Organization: Wind River Systems
Message-ID: <4n7rn4$ho9@darya.wrs.com>

Hello All,

 Has anyone ported the gnu compilers and other tools to run native in a
vxWorks system? Preferably on a 68k? I would appreciate any pointers
to info. Thanks in advance

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

Newsgroups: comp.os.vxworks
Subject: Re: trackball for a 68k
Date: 13 May 1996 17:36:15 GMT
From: Daniel Brodsky <danb@wrs.com>
Organization: Wind River Systems
Message-ID: <4n7ruf$ho9@darya.wrs.com>
References: <4m8j7e$cce@dfw-ixnews3.ix.netcom.com>

I am pretty sure that Visicom laboratories, the people who make RTGL and
VX-Windows, have this driver. http://www.vigra.com

isr@ix.netcom.com(Robert C. Smith) wrote:
>We're running VxWorks 5.3 on a MVME162 (68040) with a MVIP302 octal
>serial industry pack. Does anyone know of a source for a trackball
>and drivers?
>
>Thanks,
>
>Bob Smith
>ETEC Polyscan
>520-806-3482
>isr@ix.netcom.com
>
>

- --
Daniel Brodsky				|Phone:	(303)486-0850
Field Application Engineer		|Fax:	(303)486-0853
Wind River Systems			|Pager:	(800)722-1601
4600 South Ulster Street, Suite 700	|Email:	danb@wrs.com
Denver, CO 80237			|WWW:	http://www.wrs.com

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

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

From leonid@rst.co.il Tue May 14 05:57:15 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Tue May 14 05:57:19 PDT 1996
Subject: Re: RAM Disk questions
> From: "Bob Ferrara DTN:264-3094" <ferrara@adissw.enet.dec.com>
> Date: Mon May 13 11:17:14 PDT 1996
> Subject: RAM Disk questions...
>
> Has anyone used a RAM Disk under VxWorks that supports
> VMS style files?
>
> I need to create a VxWorks RAM disk in my local memory
> space in order to copy (probably via ftp) files from a
> OpenVMS system (RMS file format).
>
> I understand native VxWorks supports Dos, RT-11 and a Raw
> file system.
>
> Thanks for any comments,
> Bob Ferrara
> Digital Equipment Corporation

As you probably know, most operating systems these days do not
intervene in the file's contents, i.e. there is no more fixed or
variable records in a file, just plain byte-strem, and the application
in turn needs to treat the file contents as needed.

However, if you are transferring them files with FTP, then your VMS
implementation of FTP will translate the files to the common bytestream
format in accordance with file type. You need to make sure you instruct
FTP to transfer the file as TEXT or BINARY, and they will be converted
as follows: for TEXT files, every record will be appended with CR+LF,
and VxWorks FTP will strip the CR and leave LF at the end of each record.
I.e. for TEXT files every record is a Line.
For BINARY files, FTP will just send the records as they come, loosing
any boundaries between the records, and keeping only the bytes in their
order. This is quite appropriate for object files. Once upon a time
I have succesfully made VxWorks boot its image file off a VAX/VMS system.

In a word: use your VMS FTP implementation for translating file contents
correctly, hence it would be recommended to use the FTP client side
on VMS, and server on VxWorks.

Good Luck,
-----------------------------------------------------------------------
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
http://knight.trendline.co.il/~leonid/	E-Mail:	leonid@rst.co.il

From AS_Bridge@msmail3.hac.com Tue May 14 06:09:13 1996
From: "AS Bridge" <AS_Bridge@msmail3.hac.com>
Date: Tue May 14 06:09:16 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: Undeliverable Mail
Sent: Tue, May 14, 1996 4:54 AM
To: Haberman, Robert C
On Server: 631 Segment3
Date: Tue, May 14, 1996 6:06 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From LEONID@vsl.mhs.compuserve.com Tue May 14 06:10:23 1996
From: Leonid Keller <LEONID@vsl.mhs.compuserve.com>
Date: Tue May 14 06:10:26 PDT 1996
Subject: Re: Unsubscribe leonid@vsl.mhs.comp
 Please, unsubscribe leonid@vsl.mhs.comp
Thank you

--------------------------------------------------------------------------
---
Leonid Keller Gilat Satellite Networks Ltd.
Fax: (972)4-9894539 P.O.B. 205, Industrial Park
Tel: (972)4-9894543 (ext.015) Yokneam 20692,
E-mail: leonid@vsl.mhs.compuserve.com Israel
--------------------------------------------------------------------------
---

From AS_Bridge@msmail3.hac.com Tue May 14 06:39:13 1996
From: "AS Bridge" <AS_Bridge@msmail3.hac.com>
Date: Tue May 14 06:39:16 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: comp.os.vxworks newsdigest
Sent: Tue, May 14, 1996 5:32 AM
To: Haberman, Robert C
On Server: 631 Segment3
Date: Tue, May 14, 1996 6:38 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From AS_Bridge@msmail3.hac.com Tue May 14 08:52:43 1996
From: "AS Bridge" <AS_Bridge@msmail3.hac.com>
Date: Tue May 14 08:52:49 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: Undeliverable Mail
Sent: Tue, May 14, 1996 7:47 AM
To: Haberman, Robert C
On Server: 631 Segment3
Date: Tue, May 14, 1996 8:51 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From AS_Bridge@msmail3.hac.com Tue May 14 08:52:43 1996
From: "AS Bridge" <AS_Bridge@msmail3.hac.com>
Date: Tue May 14 08:52:49 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: Re: RAM Disk questions
Sent: Tue, May 14, 1996 7:47 AM
To: Haberman, Robert C
On Server: 631 Segment3
Date: Tue, May 14, 1996 8:51 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From FREGEAU@digsys1.bwi.wec.com Tue May 14 09:22:55 1996
From: "JEAN FREGEAU" <fregeau@digsys1.bwi.wec.com>
Date: Tue May 14 09:22:58 PDT 1996
Subject: shared memory heartbeat
I am trying to set up a shared memory region on CPU0 (MVME-162, 4M)
by allowing VxWorks to select the shared memory region when it boots.
I have set up \target\config\mv162\config.h as follows:

#define	SM_OFF_BOARD	FALSE

#if	SM_OFF_BOARD
#undef	SM_ANCHOR_ADRS
#define SM_ANCHOR_ADRS	((char *)0xf0800000)	/* off-board anchor
#address */ define SM_MEM_ADRS	SM_ANCHOR_ADRS	/* off-board shared
#memory address */ define SM_MEM_SIZE	0x00080000	/* 512K */ define
#SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)/* sh. mem Objects pool adrs
#*/ define SM_OBJ_MEM_SIZE 0x80000 /* sh. mem Objects pool
#size 512K */ else

/* shared memory pool address define NONE = allocate from memory */ //
#define SM_MEM_ADRS	(RAM_LOW_ADRS - (SM_MEM_SIZE + SM_OBJ_MEM_SIZE))
#define SM_MEM_ADRS	NONE

/* sh. mem Objects pool address define NONE to allocate from memory
*/ // #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)

#define SM_OBJ_MEM_ADRS NONE

#define SM_MEM_SIZE	0x000e000	/* 64K - 8k */
#define SM_OBJ_MEM_SIZE 0x10000 /* sh. mem Objects pool size
#64K */ endif	/* SM_OFF_BOARD */

The message I get on boot up is as follows:

 VxWorks System Boot

Copyright 1984-1995 Wind River Systems, Inc.

CPU: Motorola MVME162
Version: 5.3
BSP version: 1.1/2
Creation date: Nov 15 1995

Press any key to stop auto-boot...
 0
auto-booting...

boot device : ei
processor number : 0
host name : digsys2
file name : c:\tornado\target\config\mv162\vxWorks
inet on ethernet (e) : 100.0.0.50:ff000000
host inet (h) : 100.0.0.10
gateway inet (g) : 0
user (u) : snoopy
ftp password (pw) : valid
flags (f) : 0x8
target name (tn) : snoopy

Attaching network interface ei0... done.
Attaching network interface lo0... done.
Loading... 337644 + 28820 + 34622
Starting at 0x20000...

Attaching network interface ei0... done.
Attaching network interface lo0... done.
NFS client support not included.
Attaching shared memory objects at 0x600... done

I was then expecting to see the Shared Memory Anchor at address 0x600
with the offset of the shared memory packet header which would contain
the shared memory heartbeat. This is what I see (i.e. offset of 0).

-> d 0x600
 00000600: 8765 4321 0000 0001 0000 0000 003a 9e18 *.eC!.........:..*
 00000610: 0000 0000 003a 9f5c 0000 0000 0000 0000 *.....:.\........*
 00000620: 0000 0000 0000 0000 0000 0000 0000 0000 *................*

I have another board in the system (CPU1, mv167) that does not seen
to see the sm heartbeat. I am assuming that this board is not
issuing one. Any ideas or examples of how you got the on board sm to
work?

Thanks,

Jean Fregeau
Northrup Grumman
410-765-8797
FREGEAU@digsys1.bwi.wec.com

From ceselsa@coastalnet.com Tue May 14 11:39:46 1996
From: ceselsa@coastalnet.com (Carlos Martinez)
Date: Tue May 14 11:39:49 PDT 1996
Subject: Parallel driver
I am trying to find a VxWorks parallel interface driver. We are
currently using target VMEbus PowerPC boards and host SUN SPARC
stations. Is there any merciful person out there who could help ?

Thank you.

Carlos Martinez
ceselsa@coastalnet.com
(919) 466-9133
(919) 466-9134 Fax

From daemon@csg.lbl.gov Wed May 15 04:00:51 1996
From: daemon@csg.lbl.gov
Date: Wed May 15 04:00:54 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Wed May 15 04:00:45 PDT 1996

 Subject: BSP for M68340EVS
 Subject: Re: Ruggedized VME boards?
 Subject: Problem debugging PPC Tornado Beta
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: Anyone used vxWorks with closely coupled RT processes
 Subject: Software Engineers Needed

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

Newsgroups: comp.os.vxworks
Subject: BSP for M68340EVS
Date: Mon, 06 May 1996 09:38:51 +0000
From: Florian Bittner <bf@kayser-threde.de>
Organization: Kayser-Threde GmbH
Message-ID: <318DC8AB.5F28@kayser-threde.de>

Hi there,

does anybody know if there is already a Board Support Package for the
Motorola M68340 EVS Evaluation System. Please mail an answer if
possible.

TNX,
Florian

- --
Florian Bittner Software Engineer
Kayser-Threde GmbH Tel +49 89 78720 83
Perchtingerstr.3	 Fax +49 89 78720 98
81379 Munich Germany

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

Newsgroups: comp.os.vxworks
Subject: Re: Ruggedized VME boards?
Date: Sat, 11 May 1996 13:38:36 +0100
From: John Gordon <ac483@dial.pipex.com>
Organization: UnipalmPIPEX server (post doesn't reflect views of UnipalmPIPEX)
Message-ID: <31948A4C.EF2@dial.pipex.com>
References: <318F8385.3BE8@rugged.com> <linnig-0805962127220001@pppsb23.itg.ti.com>

Radstone Technology also offer a range of PowerPC boards in various
levels of ruggedisation. See their home page at
http://www.radstone.co.uk for more details

John Gordon

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

Newsgroups: comp.os.vxworks
Subject: Problem debugging PPC Tornado Beta
Date: Tue, 14 May 1996 22:23:47 GMT
From: Philip.Wiebe@newnes.com (Philip J. Wiebe)
Organization: MIND LINK! - British Columbia, Canada
Message-ID: <4nb17p$j4@fountain.mindlink.net>

I've been having difficulty debugging PowerPC code on a MVME1604. The
problem is when attaching to a task and looking at the call stack
(Backtrace option). The call stack sometimes only displays the last
called routine, normally some type of VxWorks system call. In fact,
the only time I've gotten the call stack to be even remotely close to
what is actually the true call stack is for the demo under
target/src/demo/color/vxColor.o. Even then, sometimes it does not
work.

I've tried both the -g and -gdwarf compiler options for generating
debug information.

Has anyone else had similar problems?

Phil.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Philip J. Wiebe "It has yet to be proven that intelligence
Software Engineer has any survival value."
Newnes Machine Ltd. - Arthur C. Clarke
P.O.Box 8, 3550-45th Street S.E.
Salmon Arm, BC Canada
email: Philip.Wiebe@newnes.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Tue, 07 May 1996 09:54:45 +0000
From: Ken Garlington <garlingtonke@lmtas.lmco.com>
Organization: Lockheed Martin Tactical Aircraft Systems
Message-ID: <318F1DE5.A8@lmtas.lmco.com>
References: <318E6F3C.17F4@gpsys.com>

Shaun Case wrote:
>
> I have been hunting around for several days for
> a Java development environment suitable for a
> realtime embedded system, preferably a 68k or i960-based
> platform with a well-supported realtime operating system.

How about an alternative: a language that can used to create
both Java Bytecodes (executables) _and_ executables for
realtime embedded systems, such as 68k or i960?

See: http://www.inmet.com/ada.html
 http://sw-eng.falls-church.va.us/AdaIC/
 http://lglwww.epfl.ch/Ada/

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

Newsgroups: comp.os.vxworks
Subject: Anyone used vxWorks with closely coupled RT processes
Date: 7 May 1996 15:07:16 GMT
From: abg@ast.cam.ac.uk (Bruce Gentles)
Organization: Royal Greenwich Observatory, Cambridge (UK)
Keywords: vxworks DSP multiprocessing
Message-ID: <4mnov4$rg2@lyra.csx.cam.ac.uk>
Reply-To: abg@ast.cam.ac.uk

We are developing a RT system which is somewhat latency critical. we have some maths to do. The input arrives in 400 microsecs, the result to be ready 100 microsecs later.
we can pipeline the process to get 500 usec to do it in. This takes 3000 usec on a
MIPS R4700 or a powerPC603, running vxWorks single processor.

We are looking at the trade between several (ie 12) C40 DSP's complete with nightmare spaghetti and a 6-10 processor card vme based system using vxWorks for each processor.

does anyone have experience of building this kind of tightly coupled system with
vxWorks as the RTOS. We have vxWorks in the layer above this sub-system and I am
trying to avoid the embedded DSP array approach with another RTOS as well as vxWorks.

Also, any experience or kowedge of vxWorks for DSP's or vxWorks/SPOX interaction would help a lot.

Bruce

- ---------------------------------------------------
Bruce Gentles, Royal Greenwich Observatory
 Madingley Road, Cambridge, CB3 0EZ
 Tel +44 (0)1223 374839 Fax 374700
 WWW http://www.ast.cam.ac.uk/~abg/

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

Newsgroups: comp.os.vxworks
Subject: Software Engineers Needed
Date: 14 May 1996 18:09:34 GMT
From: Patty Madry <psmadry@space.honeywell.com>
Organization: Honeywell SSD, Clearwater
Message-ID: <4nai8u$hm3@spacenns.space.honeywell.com>

Honeywell Space and Strategic Systems Operation in Clearwater Florida has a
wide variety of openings for Software Engineers, ranging from entry level to
senior staff positions. All candidates must possess a BS or MS in Computer
Engineering, Computer Science or Electrical Engineering along with expertise in
several of the following:

C language
1750A experience including assembly language
Development of real time operating systems and I/O drivers
UNIX
VxWorks
R3000 experience including assembly language
Real time test software (Inertial Systems and electronics)
Built in test software
Redundancy management software

We offer competitive salaries, excellent benefits and professional challenge.
For consideration mail or FAX your resume to Ann Sherman, Honeywell Inc., 13350
U.S. Hwy. 19 North, Clearwater FL 34624. FAX (813) 539-5299. Or e-mail resume
to mkert@space.honeywell.com. Some positions require U.S. citizenship. An equal
opportunity employer.

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

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

From froeber@bbn.com Wed May 15 05:01:51 1996
From: Fred Roeber <froeber@bbn.com>
Date: Wed May 15 05:01:53 PDT 1996
Subject: Re: shared memory heartbeat
JEAN FREGEAU says:
>
> I am trying to set up a shared memory region on CPU0 (MVME-162, 4M)
> by allowing VxWorks to select the shared memory region when it boots.
> I have set up \target\config\mv162\config.h as follows:
>
> #define SM_OFF_BOARD FALSE
>
> #if SM_OFF_BOARD
> #undef SM_ANCHOR_ADRS
> #define SM_ANCHOR_ADRS ((char *)0xf0800000) /* off-board anchor
> #address */ define SM_MEM_ADRS SM_ANCHOR_ADRS /* off-board shared
> #memory address */ define SM_MEM_SIZE 0x00080000 /* 512K */ define
> #SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)/* sh. mem Objects pool adrs
> #*/ define SM_OBJ_MEM_SIZE 0x80000 /* sh. mem Objects pool
> #size 512K */ else
>
> /* shared memory pool address define NONE = allocate from memory */ //
> #define SM_MEM_ADRS (RAM_LOW_ADRS - (SM_MEM_SIZE + SM_OBJ_MEM_SIZE))
> #define SM_MEM_ADRS NONE
>
> /* sh. mem Objects pool address define NONE to allocate from memory
> */ // #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE)
>
> #define SM_OBJ_MEM_ADRS NONE
>
> #define SM_MEM_SIZE 0x000e000 /* 64K - 8k */
> #define SM_OBJ_MEM_SIZE 0x10000 /* sh. mem Objects pool size
> #64K */ endif /* SM_OFF_BOARD */

The code you show above has been completely munged by something but
I think what you are doing is setting the SM_MEM_ADRS and
SM_OBJ_MEM_ADRS to none. As you guess, this will get VxWorks to malloc
the memory area from memory rather than use the fixed address that is
normally in config.h for the 162. It doesn't change the address of the
"backplane anchor" area which still remains at address 0x600 (hence the
address you saw below). Problem is that trying to run this way won't
work on the MVME162. There is a HW problem with bus snooping that is
explained in the 162 target.nr file. The backplane memory area is put
at a specific location and then the MMU is set to specifically not
cache that area of memory. Since you moved the backplane area to
normal memory, it is in an area that is set for copyback caching. This
means that when the 162 code updates the backplane heartbeat, until
the cache gets flushed, no other system will see the heartbeat. I
suggest not doing what you are doing with a 162LX. Fred

--
 | Fred J Roeber, BBN Systems & Technologies |
 | 50 Enterprise Place Middletown, RI 02842-5202 |
 | froeber@bbn.com 401-849-2543 (X48) |
 | See http://www.bbn.com/tv for TraceMaker info |

From francis@aaec.com Wed May 15 05:49:17 1996
From: francis@aaec.com (Kris Francis)
Date: Wed May 15 05:49:19 PDT 1996
Subject: Request for technical assistance
Can someone please tell me how to perform a burst read from a VME memory
board to a Motorola MVME167 board? Thank you for your assistance.

Kris Francis
francis@aaec.com

From ztf@one.one.com Wed May 15 10:17:19 1996
From: ztf@one.com (Zachary T. Frey)
Date: Wed May 15 10:17:22 PDT 1996
Subject: File globbing in vxTcl7.4

Has anyone out there using vxTcl7.4 had trouble getting the "glob" command
to work? I get the following behavior --

 % pwd
 gnat:/store/ztf/vxtcl
 % exec ls
 tclsh
 tcltest
 tests
 % glob *
 vxtcl: not a plain file.
 no files matched glob pattern "*"
 % ls
 invalid command name "ls"
 %

I'm using VxWorks 5.2 on a MVME167.

Are there known problems with 5.2 with using dirLib on an NFS filesystem?
That could cause this symptom ...

Thanks in advance,

Zach Frey

--
 Zach Frey
 Open Networks Engineering, Inc. (ONE) Voice: (313) 996-9900 x 1227
 777 E. Eisenhower Parkway, Suite 650 Fax: (313) 996-9908
 Ann Arbor, MI 48108 Internet: ztf@one.com

From greg@eng.nmr.varian.com Wed May 15 10:20:27 1996
From: greg@eng.nmr.varian.com (Greg Brissey x6951)
Date: Wed May 15 10:20:30 PDT 1996
Subject: RE:MVME167/162 DMA question.

> Stephen Rejto writes:> From root@csg.lbl.gov Sun May 12 07:48:47 1996
> >
> > We are using MVME167s and 162 to DMA local moto memory into into a
> > VME slave memory.
> >
> > We are doing D64 MBLT transfers and are seeing very poor rates.
> > ~28 MB/S. It appears that every 8 transfers (64 bits) the motorola board
> > is getting off teh BUS and then back on. The manual says that the DMAC
> > will get off teh bus if its FIFO goes dry.
> >
> > Can this really be happening and how do I prevent it. Does anyone know teh
> > speed at which teh DMAC is proudcing data. (i.e. reading from local moto
> > memory).
> >
> > It appears that our VME slave is faster then the DMA which causes
> > the DMA to release the BUS. YUCK! Every time it releases the bus it
> > causes a 1 usec latency.
> >
> > DTACK times are about 140-150 ns.
>

I ran into a problem with with our proprietary hardware when using D64 DMA with
a MVME162LX that probably has nothing to do with your bandwidth problem
but I thought I might mention it.
It came down to the "time off the bus" and the "time on the bus" parameters
on the vmechip2 I had not set.
This resulted in a throttled down bandwidth and an on/off Address transaction
during the D64 that our hardware wasn't expecting. I then program the
vmechip2 stay on the bus till it was completed with the D64 transfer.
( E.G.
 *((long *)VMECHIP2_TIMEOUTCR) &= ~(TIMEOUTCR_OFF_1024US); /* TIMEOUTCR_OFF_0US */
 *((long *)VMECHIP2_TIMEOUTCR) |= TIMEOUTCR_ON_DONE; )

This solve our problem with our hardware and increased our bandwidth.
Just be careful not to starve everybody else trying to get the bus.

greg brissey
varian
greg.brissey@nmr.varian.com

From SECKA@hqgate.orbital.com Wed May 15 11:27:39 1996
From: SECKA@hqgate.orbital.com
Date: Wed May 15 11:27:42 PDT 1996
Subject: CrossWind Task Debugging

 I have an application in which all my OS resources (semaphores,
 watchdogs, queues) are created/initialized and all my tasks are
 spawned by one function. I'd like to use CrossWind to debug one of my
 tasks while the others are running, and I'd like to be able to get
 control of the task right after its spawned. But I can't "attach" it
 until it exists. How can I do this ??? I tried having the task
 suspend itself upon startup, attaching to the suspended task, and then
 setting a breakpoint. But I could never get control in CrossWind once
 I resumed the task (via the shell). Any ideas ???

 Thanks in advance!
 Suzie

 =================================================================
 = Suzie Eckardt = email: secka@hqgate.orbital.com =
 = Orbital Sciences Corp. = Phone: (703) 406-5478 =
 = 21700 Atlantic Boulevard = Fax: (703) 406-5553 =
 = Dulles, VA 20166 =
 =================================================================

From mwbrown@sass1318.sandia.gov Wed May 15 12:27:19 1996
From: mwbrown@sass1318.sandia.gov (Matthew W. K. Brown)
Date: Wed May 15 12:27:21 PDT 1996
Subject: niVXIcpu030 BSP gotcha

FYI

I have found a gotcha in National Instruments BSP for the niVXIcpu030
board. The problem is actually being caused by a C&H VX431c fiber optic
module; but, National's BSP makes recovery *very* difficult.

The situation goes like this ...

We have C&H VX431c fiber optic modules in multiple crates sending digital
I/O back and forth. The boards are setup to generate an interrupt when
the input changes. When one crate is powered down, the VX431c sends a tiny
glitch--this is not the problem. The other crate (still powered up) detects
this glitch and generates an interrupt. Now, here comes the problem ...
apparently, because the amplitude of the glitch is so small, the module
appears to "change it's mind" and decides that it wasn't an change of state
afterall and during the subsequent IACK cycle it doesn't respond. So, the
niVXIcpu030 thinks that there is a problem w/ the IACK* daisy chain and
disables all interrupts. The niVXIcpu030 reports that it did this--over the
console port via logMsg. Naturally, we hardly every watch the output on the
console so we totally missed it for a long time. All we knew was that
suddenly none of our interrupts were working. Oh Yeah, this only happens
some of the time (naturally)--more often in some crates and hardly at all
in others ... swaping board didn't help either.

Our fix was to put a hook in sysLib.c that allows the user to install a
handler for an IACK BERR.

If anyone using this board is interested, email me and I'll be happy to
send you specific details.

Just a warning!

Matthew Brown
mwbrown@sandia.gov
mwbrown@sandia.gov

From ihw@rtp.co.uk Thu May 16 01:16:31 1996
From: ihw@rtp.co.uk (Ian Willats)
Date: Thu May 16 01:16:34 PDT 1996
Subject: Anyone used vxWorks with closely coupled RT processes

In response to Bruce Gentles' (abg@ast.cam.ac.uk) query:

> We are looking at the trade between several (ie 12) C40 DSP's complete with nightmare spaghetti and a 6-10 processor card vme based system using vxWorks for each processor.

I'd say the pros and cons of using DSPs vs the other processors you
mentioned will depend as much on how much data you have to move around
between processors, and where it has to live in memory, as on the nature of
the maths you have to do.

By "nightmare spaghetti" I take it you mean C40 comm port cables all over the
place! Nightmarish or not, comm ports can be a very effective way of getting
lots of data down a pipeline and directly into the "private" memory of a DSP.
Whereas I guess with most RISC VME boards you would have to transfer data via
VMEbus into some dual-ported RAM, which might prove to be a bottle-neck.
Having said that, if you need that kind of architecture, there are some VME
DSP boards with pretty respectable VME/VSB interfaces and lots of dual-ported
RAM.

> Also, any experience or kowedge of vxWorks for DSP's or vxWorks/SPOX interaction would help a lot.

To the best of my knowledge, VxWorks does not run on any "traditional" DSPs
(C3x, C4x, etc.). I don't see any fundamental reason why it shouldn't, maybe
it's just a question of market demand.

Using VxWorks and SPOX (a real-time OS designed for DSPs) together can be
quite effective. There is a thing called SPOX-LINK which can be used to
allow tasks on VxWorks and SPOX to synchronise and communicate using nice,
high-level facilities. It also supports services like remote file access,
standard i/o, sockets, etc on the DSPs, which is great for prototyping and
debugging.

Feel free to call or e-mail me directly if you'd like to talk about it in
more detail.

Ian

----------------------------------------------------------------
Ian Willats Real-Time Products Ltd.

Unit 8, Holt Court, e-mail: ihw@rtp.co.uk
Aston Science Park, Jennens Road, tel: +44 121 333 6955
Birmingham. B7 4EJ. England. fax: +44 121 333 5433
----------------------------------------------------------------

From mey@wzl-wm1.wzl.rwth-aachen.de Thu May 16 01:24:59 1996
From: Andreas Meylahn <mey@wzl-wm1.wzl.rwth-aachen.de>
Date: Thu May 16 01:25:03 PDT 1996
Subject: Re: CrossWind Task Debugging
> Date: Wed, 15 May 96 11:27:44 PDT

> I have an application in which all my OS resources (semaphores,
> watchdogs, queues) are created/initialized and all my tasks are
> spawned by one function. I'd like to use CrossWind to debug one of my
> tasks while the others are running, and I'd like to be able to get
> control of the task right after its spawned. But I can't "attach" it
> until it exists. How can I do this ??? I tried having the task
> suspend itself upon startup, attaching to the suspended task, and then
> setting a breakpoint. But I could never get control in CrossWind once
> I resumed the task (via the shell). Any ideas ???
>
We are still using vxWorks 5.2 with the Centerline C++ Frontend and
the gdb, and we solve the problem as follows:
1.) Load your application to the target
2.) start gdb and connect it to the target
3.) list your source code in the gdb
	list sourcefilename.extension:linenumber
4.) set a (local) breakpoint just behind the beginning of your task entry
 point. Then gdb tells you the address 0xhexaddress of this breakpoint
 This breakpoint is in a task scope but while you are not
	attached to a task, it has no further meaning. it's just an easy way
 to get the right address.
5.) use this address to set a (global) breakpoint in the target shell
	b 0xhexaddress
6.) run your application from the shell until it hits the (global) breakpoint.
 Then the shell tells you a task ID 0xhextaskID
7.) use this task ID in gdb to attach
 attach 0xhextaskID
	and you should then have control under gdb
8.) delete the (global) breakpoint in the targets shell.
9.) go on with gdb

I think there could be a nicer way in Tornado, I've heard there you can set
a global breakpoint in the debugger and therefore you don't need a
shell for debugging but the procedure is just the same.

Andreas
=========================================================================
RWTH-AACHEN WZL
Werkzeugmaschinenlabor
Dipl.-Ing. Andreas Meylahn
Steinbachstr. 53b
D-52074 Aachen
Tel: +49-241-80 7451
FAX: +49-241-8888 293
e-mail: mey@wzl-wm1.wzl.rwth-aachen.de
=========================================================================

From daemon@csg.lbl.gov Thu May 16 04:00:41 1996
From: daemon@csg.lbl.gov
Date: Thu May 16 04:00:44 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Thu May 16 04:00:34 PDT 1996

 Subject: Re: ENETUNREACH?
 Subject: Re: Development Tools

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

Newsgroups: comp.os.vxworks
Subject: Re: ENETUNREACH?
Date: 3 May 1996 23:07:56 -0700
From: chaos@idiom.com (H.J. Bae)
Organization: Peaceful Star, Oakland, CA
Message-ID: <4mes7s$8np@idiom.com>
References: <s1886414.077@mailhost.scires.com>

In article <s1886414.077@mailhost.scires.com>,
Mike Milde at SRC-Home_Office <Mike.Milde.at.SRC-Home_Office@scires.com> wrote:
>
> I have a system where the shell occasionally spits out these
>messages that say "ENETUNREACH". Surprisingly, everything appears to
>work as it should.
> Any idea where these are created? I'm doing some IP socket
>stuff, so I assume that this means something like: Ethernet
>Unreachable. Any ideas? Anyone know if this is caused by an ICMP
>message coming back from the system I am communicating with?

ENETUNREACH is an indication that you are trying to send IP
packets but routing table does not have corresponding entry
for the destination. IP layer is unable to resolve the route,
therefore unable to send the packet out. It is possible that
a gateway is involved in returning ICMP network unreachable message
back to the sender. However, VxWorks won't report that back
as an error message. It's more likely that your routing table
is incorrect.

- --
H.J. Bae 	http://www.peacefulstar.oakland.ca.us

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

Newsgroups: comp.os.vxworks
Subject: Re: Development Tools
Date: 8 May 1996 15:42:10 GMT
From: bowman@waterloo.hp.com (Don Bowman)
Organization: H-P Panacom Div, Waterloo, ON Canada
Message-ID: <4mqfci$g82@hppadbk.waterloo.hp.com>
References: <9604078314.AA831484111@ist1.istnet.com>

jlao@istnet.com wrote:

: I am looking for development tool for VxWorks which the target board is MIPS.
: So far I have two candidates the StethoScope from Real-Time Innovations, Inc.
: and the Insight from the Parasoft. Is there anybody use these tools.
: Or is there other tools that provides better error catching capabilities.

You can also use (for those on a cheap budget :) gcc with the gct
(coverage testing) and bounds checking extensions.

Another one we've used is dbmalloc (which since became the commercial
product sentinel).

We also purchased Hindsight (now owned by integrisoft). info@integrisoft.com
It does coverage analysis and some CASE stuff for visualisation.

A company called synervision makes some products that do memory
checking and stuff for vxworks: http://www.synervision.com

- --
bowman@waterloo.hp.com ** 519-883-3019 ** http://www.waterloo.hp.com/~bowman

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

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

From daemon@csg.lbl.gov Fri May 17 04:00:54 1996
From: daemon@csg.lbl.gov
Date: Fri May 17 04:00:59 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Fri May 17 04:00:44 PDT 1996

 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
 Subject: VxWorks 5.2 and C++
 Subject: Re: VxWorks v5.1.1 (tNetTask)
 Subject: 100 Mbit/s Ethernet with Motorola VME 167 or 177 card?
 Subject: VxWorks v5.1.1 (tNetTask)
 Subject: Shared memory layout problem
 Subject: Re: VxWorks v5.1.1 (tNetTask)

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: 9 May 1996 03:53:41 GMT
From: rlk@rational.com (Bob Kitzberger)
Organization: Rational Software Corporation
Message-ID: <4mrq85$m7j@rational.rational.com>
References: <318E6F3C.17F4@gpsys.com> <318F1DE5.A8@lmtas.lmco.com> <319127A1.3F03@oro.net>
Followup-To: comp.lang.java,comp.os.vxworks,comp.realtime

gozer (gozer@oro.net) wrote:
: Java is our language of choice (for religious reasons).
 ^^^^^^^^^^^^^^^^^^^^^

 :-)

- --
Bob Kitzberger	 Rational Software Corporation rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

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

Newsgroups: comp.os.vxworks
Subject: VxWorks 5.2 and C++
Date: 16 May 1996 18:16:15 GMT
From: Michael Roesler <miker@lamrc.com>
Organization: Lam Research Corporation - (510) 659-0200
Message-ID: <4nfrdf$7v@internal.lamrc.com>

Using VxWorks 5.2, I would like to write a driver in C++ for a XYCOM240 digital
I/O board. Can one use C++ with VxWorks 5.2? I do not see any references
regarding C++ in the VxWorks programmers guide.

Where can I get more information regarding using C++ and VxWorks?

Thanks,

Mike Roesler
Lam Research
miker@lamrc.com

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

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks v5.1.1 (tNetTask)
Date: 16 May 1996 22:41:22 GMT
From: Michael Levasseur <levass@gdesystems.com>
Organization: GDE Systems Inc.
Message-ID: <4ngaui$rhb@gde.GDEsystems.COM>
References: <31922B6A.160E@jpl.nasa.gov> <DrHx3s.D2v@hynet.co.il>

We saw this problem too. This might not be a dupticate IP address
though. We saw this when we had two (or more) boards that were
in a VME rack that were both attempting to download the VxWorks
Kernel at the same time. Both of the Boards had different IP
addresses but were located on the same Subnet. Both of the boards
were booting from the front panel Ethernet connector and had
a Desta Repeater connected to each. The error wasn't seen if only
one of the boards was booted and allowed to complete the VxWorks
kernel download.

For our current download structure we are downloading the VME
System Controller First and then downloading each of the other
processors in the VME Rack. Each of the Processors has an IP
address and the VME Backplane has a separate Subnet Address.

Then again this could just be that you do have two devices with
the same IP addresses....

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

Newsgroups: comp.os.vxworks
Subject: 100 Mbit/s Ethernet with Motorola VME 167 or 177 card?
Date: Fri, 17 May 1996 00:56:48 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Message-ID: <georg.832294608@sgl.ists.ca>
Sender: news@newshub.ists.ca

Hi,

Has anybody out there used 100 Mbit/s Ethernet on VME?

We have a system that currently uses Motorola MVME 167 CPU cards
and regular 10 Mbit/s ethernet. We would like to find a 100 Mbit/s
Ethernet interface with VxWorks support that could be added to this
system.

I understand that we can't expect miraculous data rates from this,
we just need the ability to connect to a fast Ethernet network.
Wind River has suggested that we switch to a Power PC card with
PMC slots such as MVME1600 so that we can use a PMC 100 Mbit network
card, but I would like to do it without the hassle of changing
architectures, maybe just move to the MVME177 for a little extra
crunch.

Any suggestions are appreciated,

Thanks...

Georg Feil
Space Geodynamics Laboratory | Email: georg@sgl.ists.ca
Institute for Space and Terrestrial Science | Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815
- --
Georg Feil
Space Geodynamics Laboratory | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science | Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 | Fax: (416) 665-1815

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

Newsgroups: comp.os.vxworks
Subject: VxWorks v5.1.1 (tNetTask)
Date: Thu, 09 May 1996 10:29:14 -0700
From: Henry Valtier <Henry.Valtier@jpl.nasa.gov>
Organization: Jet Propulsion Laboratory - Pasadena CA
Message-ID: <31922B6A.160E@jpl.nasa.gov>

I am currently using VxWorks 5.1.1, KERNEL: WIND v2.4, running
on a combination of 1 master and several slave MVME167-02A,-02B boards
in a common backplane in a VME chassis. At most, 2-3 user application
tasks run on each board, besides the VxWorks tasks. The master
MVME167 serves as the gateway on a local LAN, while the slave boards
communicate over a shared memory network. A SUN Sparc20 functions
as the UNIX Host and the VME chassis is the Target H/W.

Has anyone ever come across the following message (viewed in
a VxWorks shell window):

(tNetTask): duplicate IP address!! sent from ethernet address: <..addr..>

What does it mean? How critical is this condition and what problem(s)
does it cause?

Thanks in advance.

Henry Valtier
Jet Propulsion Laboratory
Pasadena, California 91109
Henry.Valtier@jpl.nasa.gov

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

Newsgroups: comp.os.vxworks
Subject: Shared memory layout problem
Date: 9 May 1996 17:55:48 GMT
From: David Perkinson <perkinsond@boris.msfc.nasa.gov>
Organization: TRW, Inc.
Message-ID: <31923235.41C6@boris.msfc.nasa.gov>

I have a problem with shared memory semaphores. When I try an example
containing just a few shared queue's and semaphores, everything works fine.
When I have large blocks of shared memory as well as about a dozen shared
queue's and a dozen shared semaphores, I get problems. SemTake calls on
the second CPU board cause the first board to go crazy. It looks like the
second CPU is causing the first CPU to jump to some strange place in its code
which causes access faults.

Has anyone seen this kind of behavior before?

The second CPU continues to run but runs out of memory after enough attempts
to get the semaphore.

===============================================================================
David Perkinson, TRW
perkinsond@boris.msfc.nasa.gov
===============================================================================

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

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks v5.1.1 (tNetTask)
Date: Thu, 16 May 1996 11:26:16 GMT
From: gadi@hynet.co.il (Gadi Friedman)
Organization: TeleOp Communication Industries, Ltd.
Message-ID: <DrHx3s.D2v@hynet.co.il>
References: <31922B6A.160E@jpl.nasa.gov>

In article <31922B6A.160E@jpl.nasa.gov> Henry Valtier <Henry.Valtier@jpl.nasa.gov> writes:
>
>(tNetTask): duplicate IP address!! sent from ethernet address: <..addr..>
>
>
>What does it mean? How critical is this condition and what problem(s)
>does it cause?
>

Two ethernet ports have the same IP addresses. Check out your
arp tables.

Gadi

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

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

From tnh@terma.dk Fri May 17 04:29:38 1996
From: tnh@terma.dk (Thorsten Nordmark Hansen)
Date: Fri May 17 04:29:41 PDT 1996
Subject: POSIX named semaphores
Have anyone of you tried to use the POSIX named semaphores in VxWorks 5.3?

When I try to use them I get a -1 returned from sem_open() and errno is set
to EINVAL.

I tried to copy example 2.7 from 'Programmers Guide: VxWorks 5.3' directly
but with the same result.

I have no problems using POSIX unnamed semaphores and POSIX message queues.

Thanks for any help,

Thorsten Hansen
TERMA Elektronik A/S

tnh@terma.dk

From greg@eng.nmr.varian.com Fri May 17 09:31:49 1996
From: greg@eng.nmr.varian.com (Greg Brissey x6951)
Date: Fri May 17 09:32:17 PDT 1996
Subject: Re: 100 Mbit/s Ethernet
 Georg Feil writes:
>
> Hi,
>
> Has anybody out there used 100 Mbit/s Ethernet on VME?
>
> We have a system that currently uses Motorola MVME 167 CPU cards
> and regular 10 Mbit/s ethernet. We would like to find a 100 Mbit/s
> Ethernet interface with VxWorks support that could be added to this
> system.
>
> I understand that we can't expect miraculous data rates from this,
> we just need the ability to connect to a fast Ethernet network.
> Wind River has suggested that we switch to a Power PC card with
> PMC slots such as MVME1600 so that we can use a PMC 100 Mbit network
> card, but I would like to do it without the hassle of changing
> architectures, maybe just move to the MVME177 for a little extra
> crunch.
>
> Any suggestions are appreciated,

 We use a Motorola MVME162LX, and would also like to try 100 Mbit/s Ethernet
 without changing architectures.

 I would also be interested in any suggestions.

 Greg Brissey
 Varian, Palo Alto, CA
 greg.brissey@nmr.varian.com

From sniedze%homer.dnet.boeing.com@atc.boeing.com Fri May 17 13:24:06 1996
From: sniedze%homer.dnet.boeing.com@atc.boeing.com
Date: Fri May 17 13:24:08 PDT 1996
Subject: 3d0002/3d0001 errno's
Question on errno 3d0002/3d0001 ?

Anyone know why errno 3d0002 appears for tShell on doing an
"i" command on first starting WindShell under Tornado? I
have a Sun Ultra running Solaris connected to an VME
chassis that has a M68030 single board computer. The
monitor crt shows no such error.

Also, doing a semTake of a binary semaphore created
by a different task results in errno= 3d0001.

Thanks.
js

From vzait@xxcal.com Fri May 17 13:24:24 1996
From: vzait@xxcal.com (Veronika Zaitseva)
Date: Fri May 17 13:24:28 PDT 1996
Subject: positions avail
XXCAL, INC.

XXCAL, INC. is a $25MM Technical Contract Recruiting company, providing
contract professionals for the past 20 years. We have offices in Los
Angeles, Silicon Valley, and Austin, TX. We recruit and provide contract
computer professionals to the DP organizations, and high-technology
companies. Currently we are looking for the following assignment:

Job Description: Need Software Developers with strong 'C' programming
experience in a systems, or embedded environment. Must have some sort of
real-time OS experience, ie. VxWorks, or VRTX, or 486 Kernal. Development
environment is Sun Sparc, and will cross compile to embedded 486 custom
controller. Using Wind River C based on GNU C. Debugging with VxGDB.

Duration: 12-18 months

Location: Los Angeles, CA

Contact: Veronika Zaitseva @XXCAL Los Angeles at 800 879-9225, ext.34, or
fax to 310 478-6226, or e-mail to vzait@xxcal.com

From daemon@csg.lbl.gov Sat May 18 04:02:51 1996
From: daemon@csg.lbl.gov
Date: Sat May 18 04:05:02 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sat May 18 04:01:02 PDT 1996

 Subject: Re: Bit-fields and byte/word access on 68K
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system

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

Newsgroups: comp.os.vxworks
Subject: Re: Bit-fields and byte/word access on 68K
Date: Fri, 10 May 1996 09:56:23 -0400
From: Gonzalo Maldonado <zal@bnl.gov>
Organization: Brookhaven National Laboratory
Message-ID: <31934B07.6E6D@bnl.gov>
References: <31922C57.5224@cliffy.lmtas.lmco.com>

Shash Chatterjee wrote:
>
> Hi!
>
> I'm trying to use bit-fields to access registers on a
> VMIC VMIVME-3123 A/D board. This board has what it calls "firmware
> registers" (essentially, pseudo-registers in the DSP's SRAM), that
> are 16-bit registers. The registers can be accessed as 8-bit (ie,
> no bus errors) but the data is invalid.
>
> The problem is that the cc68k compiler uses the 68030 bit-field
> instructions (BFINS, BFCLR, etc), but these seem to work with
> byte accesses to the registers. So is there a way to force the compiler
> to use 16-bit accesses (still using C bit-fields) and do logical
> ANDs/ORs as necessary (I understand that this will be less efficient
> than the bit-field instructions, but WORKING is more efficient than
> NOT-WORKING ;-)
>
> Thanks for any help,
> Shash
> --

Well, why not try declaring a pointer of type short to
access these registers and do your logical operations right
on the read values.

{
	INT16 *pWhassup;
 INT16 value;

 *pWhassup = (INT16 *)0xFFFF0000;
 value = *pWhassup;
 value = value & SOME_MASK;
 *pWhassup = value;
}

If you compare the assembly instructions generated you
will see that this is definitely more efficient than
using bit fields.

__________
| _ ____\ * * * * *
| |\ \\\\\ * * * * *
| |\\ \ * * * * *
| |__\ \
| ____\ \ zal@bnl.gov Gonzalo Maldonado
| |\\\\\ \ Brookhaven National Laboratory
|_________\\ Bldg. 911-C Upton, NY 11973-5000
 \\\\\\\\\\\ http://www.rhichome.bnl.gov/People/zal/

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Thu, 09 May 1996 17:44:55 -0600
From: "Adam T. McClure" <mcclurea@colorado.edu>
Organization: Colorado Space Grant College
Message-ID: <31928377.24A5@colorado.edu>
References: <318E6F3C.17F4@gpsys.com> <4mqi0v$s15@venice.dh.trw.com>

Steve Witt wrote:
>
> > I have been hunting around for several days for
> > a Java development environment suitable for a
> > realtime embedded system, preferably a 68k or i960-based
> > platform with a well-supported realtime operating system.
> > For performance reasons we'd like something that compiles
> > java bytecode into native instructions.
>
> > After extensive searching I have come up completely empty-handed.
> > Can anyone provide me with pointers to something along these
> > lines, or point me in the direction of someone who is working on
> > something like this?
>
> > Maybe I'm barking up the wrong tree, but this seems like a very
> > reasonable thing to want to do.
>

You're right! It's extremely reasonable.
I may even know the right people to get it done.

I could make a better argument if folks who are interested in
this could give solid reasons why the Java language is so great
for embedded systems. Email please.

Adam McClure
mcclurea@colorado.edu

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

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

From daemon@csg.lbl.gov Sun May 19 04:01:15 1996
From: daemon@csg.lbl.gov
Date: Sun May 19 04:01:20 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sun May 19 04:01:10 PDT 1996

 Subject: A couple of questions about Windview
 Subject: Re: Literature on preemptive, multitasking design?
 Subject: Re: Problem debugging PPC Tornado Beta
 Subject: Re: Error message from tExcTask

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

Newsgroups: comp.os.vxworks
Subject: A couple of questions about Windview
Date: Fri, 10 May 1996 08:20:46 GMT
From: Michael Migdol <mmigdol@crl.mew.co.jp>
Organization: Matsushita El. Works, Ltd., Central Research Lab
Message-ID: <3192FC5E.793A@crl.mew.co.jp>
Sender: news@isc.mew.co.jp (USENET News System)

Hi all,

We recently started using WindView, and are finding it
fairly useful. Does anyone know the answer to the
following questions?

1) Is there any way to remove particular tasks from the
graph display? How about removing them from the graph
display altogether?

2) Is the data format of the WindView files open? I would
like to be able to create spreadsheet-type files containing
portions of the event data. Or is this a way to force us
to buy Stethoscope?

Thanks in advance,
Michael
- --
===================================================================
Michael A. Migdol $B%^%$%1%k!&%_%0%I%k(J
Matsushita Electric Works, Ltd. Tel. (06) 906 -
8075
Central Research Laboratory Fax (06) 904 -
7104
1048 Kadoma, Osaka 571 Japan e-mail
mmigdol@crl.mew.co.jp
$B!!!!>>2<EE9)3t<02q<RCf1{8&5f=j?.9f=hM}!&%=%U%H%&%'%"8&5f<<(J
 http://nesc.me.utexas.edu/~mmigdol/

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

Newsgroups: comp.os.vxworks
Subject: Re: Literature on preemptive, multitasking design?
Date: 9 May 1996 03:04:14 GMT
From: aggi@ix.netcom.com(Istvan Agg )
Organization: Netcom
Message-ID: <4mrnbe$k20@dfw-ixnews10.ix.netcom.com>
References: <4mdrcm$2s5@maverick.tad.eds.com>

In <4mdrcm$2s5@maverick.tad.eds.com> Dave Mack <lnustoc.jzgmwk@eds.com>
writes:
>
>Hi everyone,
>
>I have 2+ years experience in C programming, but I am
>a new VxWorks user and have not done any real-time,
>multitasking, priority based programming before. I have
>read and understand the concepts presented in the VxWorks
>Programmers Guide, but was hoping someone out there could
>suggest some material that does more than just define
>functionality. I am looking for good sources that talk about
>program design concepts, structure charts, etc., when dealing
>with multitasking programs.
>
>Your suggestion is greatly appreciated!
>
>David Mack
>lnustoc.jzgmwk@eds.com
>810-524-8807
>810-528-4264(FAX)
>
>
You may look at this book, I think it gives a good
overview, it is not an in depth tutorial on the subject
though. It addresses real-time issues:

Phillip A. Laplante, "Real-Time Systems Design And Analysis",
IEEE Press, ISBN 0-7803-0402-0.

Istvan
http://www.mcs.com/~agg/

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

Newsgroups: comp.os.vxworks
Subject: Re: Problem debugging PPC Tornado Beta
Date: 17 May 1996 21:57:10 GMT
From: nigels@synoptics.com (Nigel Standing)
Organization: Bay Networks, Inc.
Message-ID: <4nisnm$5fg@inn.corpwest.baynetworks.com>
References: <4nb17p$j4@fountain.mindlink.net>

Philip.Wiebe@newnes.com (Philip J. Wiebe) writes:

> I've been having difficulty debugging PowerPC code on a MVME1604

> I've tried both the -g and -gdwarf compiler options for generating
> debug information.

A couple of points. Firstly, I believe that although the WRS
documentation does say to use "-gdwarf" it is broken in the beta
release (it produces *very* large images).

Secondly, if I recall correctly, one major difference between a PPC
stack dump and (say) the traditional 68k one is that the PPC stack
frame may not show any arguments. This is because they are being
passed in volatile registers (r3 thru r12). Once a function starts
executing it is free to trash any of the regs. In addition, the same
regs are used to pass arguments to subsequent function calls.

All this means that at each stack level the arguments might very well
not exist anymore. So you might be getting some weirdness with your
stack trace because of this.

Nigels -
- --
****************************************************************************
Nigel Standing Vox: +1 408 764 7542
Platforms Group 	 Fax: +1 408 988 6653
Bay Networks (SynOptics) Inc. E-m: nigels@BayNetworks.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Error message from tExcTask
Date: 10 May 96 17:43:46 GMT
From: bss@wrs.com (Benjamin Skrainka)
Organization: Wind River Systems, Inc.
Message-ID: <bss.831750226@wrs.com>
References: <AGIL.96May9172941@shita.news.qualcomm.com>

Greetings!

agil@shita.news.qualcomm.com (Amit Gil) writes:

>We are getting the following error message:

>-> 0xfde244 (tExcTask): 1 messages from interrupt level lost.
>0xfde244 (tExcTask): 1 messages from interrupt level lost.

[snip]

This error message means that excJobAdd() is failing because
the message queue, read by tExcTask, is full. excJobAdd()
is used by ISRs to perform task level work by sending
a request to tExcTask. excJobAdd() is implemented as a
wrapper around msgQSend(). If msgQSend() fails, then
excJobAdd() bumps the count of messages lost. When tExcTask
next runs it will print out the error messages you see.

Consequently, you are either queuing up too much work from
interrupt time or tExcTask is not running often enough to
drain the message queue.

>We don't know what is the cause to the error or if it has any influence on the stsem. We don't see any lost messages or any strange behavior exepct this message.

>What we do is use send a message from an ISR through a pipe to a task that sends a messages thruogh a UDP socket. The ISR is called from a watch-dog. The pipe is not full when the ISR writes to it.

The pipe write method is probably responsible for the calls to
excJobAdd(): the pipeWrite() function calls selWakeupAll() to
provide support for select(), and selWakeupAll() performs an
excJobAdd() if it is at interrupt time. Try making your
watch dog slower: if the problem goes away, you know that
pipeWrite() is the culprit. A longer term solution would
be to use message queues instead of pipes: message queues will
always be faster, because pipes are built on message queues.

Good luck,

Ben

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Benjamin S. Skrainka Wind River Systems
Development Engineer 1010 Atlantic Avenue
bss@wrs.com Alameda, CA 94501-1147
 voice 510.814.2147
http://www.wrs.com/ facsimile 510.814.2164
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

From daemon@csg.lbl.gov Mon May 20 04:00:27 1996
From: daemon@csg.lbl.gov
Date: Mon May 20 04:00:31 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Mon May 20 04:00:21 PDT 1996

 Subject: FORCE10 DOS FILE SYSTEM PROBLEMS
 Subject: Problems migrating from VxWorks 5.1 -> 5.2
 Subject: 3U CPU suggestions
 Subject: SCSI device size

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

Newsgroups: comp.os.vxworks
Subject: FORCE10 DOS FILE SYSTEM PROBLEMS
Date: Sat, 11 May 1996 16:01:42 GMT
From: DuaneAustin@worldnet.att.net (Duane C. Austin)
Organization: AT&T WorldNet Services
Message-ID: <4n3o4v$l58@mtinsc01-mgt.ops.worldnet.att.net>

I am developing an application that runs on a FORCE10 using VxWorks
5.2 using a DOS file system. Occasionally I'm experiencing
occassional disk file corruptions. If you have experienced and solved
such a problem I would appreicate hearing from you.

THANKS!!!

DuaneAustin@worldnet.att.net

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

Newsgroups: comp.os.vxworks
Subject: Problems migrating from VxWorks 5.1 -> 5.2
Date: Fri, 17 May 1996 00:08:35 GMT
From: pgonza@atl.com (Pablo Gonzalez-Gandolfi)
Organization: Advanced Technology Laboratories, Bothell, WA
Message-ID: <qsg290kvp8.fsf@ironmt.atl.com>
Sender: pgonza@ironmt.atl.com

I am having trouble migrating one of our applications from vxworks 5.1 to
vxworks 5.2. The application makes heavy use of the vxworks directory structure
and FAT table. Under vxworks 5.1, the application runs fine (at least does not
display any abnormal behavior). Under 5.2, it dies, sometimes currupting the
FAT table. I can get it to die every time.

Without getting into the guts of the application, I was wondering if anybody
out there is aware of any known porting issues between 5.1 and 5.2 that
are not in the release notes. In particular, changes in the FAT table, file
manipulation (copy, rename, etc). If you've had any interesting problems
porting 5.1->5.2, I would be interested in that as well.

Any help will be greatly appreciated.

- -pgg

- --
**************************************************************
 Pablo Gonzalez-Gandolfi Email: pgonza@atl.com
 Principal Software Engineer
 Advanced Technology Lab. Voice: (206)487-8139
 22100 Bothell-Everett Hwy. Fax: (206)486-5220
 Bothell, WA 98041-3003
*************************************************************

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

Newsgroups: comp.os.vxworks
Subject: 3U CPU suggestions
Date: 16 May 1996 18:15:45 GMT
From: msinger@griffon.oe.fau.edu (Matthew Singer)
Organization: Florida Atlantic University
Message-ID: <4nfrch$t75@cybernet.cse.fau.edu>
Reply-To: msinger@griffon.oe.fau.edu (Matthew Singer)
Sender: msinger@griffon (Matthew Singer)

Anyone know of a 3U 68030 or better card that has on card or
daughter card fast scsi with dma?

- --
- -------------------------------------------------------------------------------
Matthew R. Singer msinger@oe.fau.edu
Systems Engineer Voice: 407-367-2947
Florida Atlantic University Fax : 407-367-3885
Dept of Ocean Engineering
- -------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: SCSI device size
Date: Thu, 16 May 1996 13:21:28 -0500
From: Alan Currie <currie@ghgcorp.com>
Organization: NASA/Johnson Space Center
Message-ID: <319B7228.77CB@ghgcorp.com>
Reply-To: currie@ghgcorp.com

I had a problem taking a larger SCSI drive (500meg) and getting the
OS to recognize that it was bigger than the original (128meg) SCSI
drive. Turns out the problem was that I was writing all my files to
the root directory. The root directory has a limitation of 112
files that I was not aware of until I found the dosFsConfigShow
command. Solution create subdirectories and write files to these
subdirectories. My open was creating an error return of -1, not
because disk was full, but because number of files was exceeded.
Does anyone know how to get a more verbose indication of what the
problem is when the only return is a -1? Thanks.

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

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

From SMTP_Bridge_Server@msmail3.hac.com Mon May 20 05:42:48 1996
From: "SMTP Bridge Server" <SMTP_Bridge_Server@msmail3.hac.com>
Date: Mon May 20 05:42:50 PDT 1996
Subject: Undeliverable Mail
Unknown Microsoft mail form. Approximate representation follows.

Message: comp.os.vxworks newsdigest
Sent: Sun, May 19, 1996 5:40 AM
To: Quiroz, Gabriel
On Server: 631 Segment2
Date: Mon, May 20, 1996 5:42 AM
Reason: Could not be delivered because the destination Microsoft Mail server
could not be found.

From YF.Siu@eng.efi.com Mon May 20 15:01:26 1996
From: "Yuet Fung Siu" <YF.Siu@eng.efi.com>
Date: Mon May 20 15:01:29 PDT 1996
Subject: Re: comp.os.vxworks newsdigest
>5.2 using a DOS file system. Occasionally I'm experiencing
>occassional disk file corruptions. If you have experienced and solved

>and FAT table. Under vxworks 5.1, the application runs fine (at least does not
>display any abnormal behavior). Under 5.2, it dies, sometimes currupting the
>FAT table. I can get it to die every time.

I think this is not my first time replying to the same problem.
5.2 introduced a new bug to the dosFsLib that will corrupt the
file system and hang the task occasionally. I've reported this

WRS will probably be able to give you a patch for this since
this is no workaround. Please talk to your sale person or a
more technical WRS person.

YF

From haifang@dtc.hp.com Mon May 20 17:36:55 1996
From: Hai-Fang Yun <haifang@dtc.hp.com>
Date: Mon May 20 17:36:58 PDT 1996
Subject: running PSIM in Tornado environment

Has anyone tried PSIM (a Power PC simulator) or
other Power PC simulator in Tornado environment?
Need some pointers on how to set up the simulator and run it.

Thanks in advance,
hyun@dtc.hp.com

From daemon@csg.lbl.gov Tue May 21 04:00:26 1996
From: daemon@csg.lbl.gov
Date: Tue May 21 04:00:33 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Tue May 21 04:00:24 PDT 1996

 Subject: 68360 and Tornado
 Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system

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

Newsgroups: comp.os.vxworks
Subject: 68360 and Tornado
Date: 21 May 1996 03:03:45 GMT
From: martyii@ix.netcom.com(Martin Sigona )
Organization: Netcom
Message-ID: <4nrbqh$9b1@dfw-ixnews9.ix.netcom.com>

 Has any one used the 68360 in companian mode with the 68360 ?

 If you have-have you ever tried to use the serial driver that comes
with the BSP and use it for SCC3 and 4. In the device driver I am
having problems when m68360ResetChannel trys to enable the transmit and
receive for SCC3 at the end of the fucntion. It dies. Know this is the
same driver I am use on SCC2. I have modified the m68360_CHAN for
initialazition.

Please email me back at martin_sigona@globalvillage.

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

Newsgroups: comp.lang.java,comp.os.vxworks,comp.realtime
Subject: Re: Native Java VM or bytecode to 68k/i960 etc for embedded system
Date: Mon, 20 May 1996 18:18:03 -0500
From: Steve Lee <sjlee@iastate.edu>
Organization: Iowa State University
Message-ID: <31A0FDAB.205D@iastate.edu>
References: <318E6F3C.17F4@gpsys.com> <4mqi0v$s15@venice.dh.trw.com> <31928377.24A5@colorado.edu> <4nqn73$9b9@sjx-ixn2.ix.netcom.com>
Reply-To: sjlee@iastate.edu

G. David Atkins II wrote:
>
> I know people that want to do a similar thing for
> embedded PC based real-time control. So if you could
> please add me to your discussions.
>

You can subscribe to the mailing list

real-time-java@iastate.edu

Also, check out

http://www.newmonics.com

- --
Steve Lee
Computer Engineering/Computer Science Undergraduate Student
Iowa State University
email -> sjlee@iastate.edu
WWW -> http://www.cs.iastate.edu/~sjlee/homepage.html

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

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

From daemon@csg.lbl.gov Wed May 22 04:00:20 1996
From: daemon@csg.lbl.gov
Date: Wed May 22 04:00:23 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Wed May 22 04:00:17 PDT 1996

 Subject: httpd for vxWorks?
 Subject: VXworks works, really?
 Subject: Sun 1E boards
 Subject: Debugger Problems with Tornado 1.0

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

Newsgroups: comp.os.vxworks
Subject: httpd for vxWorks?
Date: Thu, 16 May 1996 10:39:28 -0700
From: Shaun Case <shaunc@gpsys.com>
Organization: Graham-Patten Systems, Inc.
Message-ID: <319B6850.56F1@gpsys.com>

Has anyone ported or implemented an httpd to vxWorks?

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

Newsgroups: comp.os.vxworks
Subject: VXworks works, really?
Date: 21 May 1996 16:51:23 GMT
From: consign@ix.netcom.com(Consign, Inc. )
Organization: Netcom
Message-ID: <4nssab$dpb@sjx-ixn5.ix.netcom.com>

Why choose VXworks if a 486 running the QNX OS or kernel equals or
outperforms VXworks on a 266Mhx Dec Alpha?

Inquiring minds want to know.

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

Newsgroups: comp.os.vxworks
Subject: Sun 1E boards
Date: Thu, 16 May 96 22:06:19 PDT
From: hwest@csc.com
Organization: Computer Sciences Corporation
Message-ID: <4ngnej$c8e@explorer.csc.com>

Greetings

	We are using sun 1e boards from Force running VxWorks 5.2 .
We would like to expand the board memory using an S bus expansion
board. Has anyone had any success doing this? Has anyone had any
experience using this board in this way? Thanks in advance for
any help you can give.

Regards

Harold West

Computer Sciences Corporation

Hanover MD

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

Newsgroups: comp.os.vxworks
Subject: Debugger Problems with Tornado 1.0
Date: 21 May 1996 14:03:59 GMT
From: Rick Evans <rick@scimisys.com>
Organization: NeoSoft Internet Services +1 713 968 5800
Message-ID: <4nsigf$7e8@uuneo.neosoft.com>

I am using Tornado version 1.0 on Windows 95. We are having
following problems with the debugger.

1. When we attach to a task that is loaded with symbols we
can only get an assembly listing.

2. We can not control the source search path for the debugger
through the IDE. We have to set it with the gcc commands.

Is their someone else out their using Tornado on Windows 95?
If so, are you having these types of problems?

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

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

From Mike.Milde.at.SRC-Home_Office@scires.com Wed May 22 06:07:19 1996
From: Mike Milde at SRC-Home_Office <Mike.Milde.at.SRC-Home_Office@scires.com>
Date: Wed May 22 06:07:21 PDT 1996
Subject: Re: VXworks works, really?

 Because your application may very well require something other
than a 80486 or a 266 Mhz Dec Alpha.

 Mike Milde
 Scientific Research Corporation
 mike@pegasus.scires.com

--------------------------------------------------------------------
Newsgroups: comp.os.vxworks
 Subject: VXworks works, really?
 Date: 21 May 1996 16:51:23 GMT
 From: consign@ix.netcom.com(Consign, Inc. ) Organization: Netcom
Message-ID: <4nssab$dpb@sjx-ixn5.ix.netcom.com>

 Why choose VXworks if a 486 running the QNX OS or kernel equals
or outperforms VXworks on a 266Mhx Dec Alpha?

 Inquiring minds want to know.

From sblachma@aoc.nrao.edu Wed May 22 09:14:48 1996
From: Steve Blachman <sblachma@aoc.nrao.edu>
Date: Wed May 22 09:14:50 PDT 1996
Subject: Re: VXworks works, really?

> Why choose VXworks if a 486 running the QNX OS or kernel equals or
> outperforms VXworks on a 266Mhx Dec Alpha?

> Inquiring minds want to know.

At best, this is an poor question - it begs itself. There is no
information here with which to make a decision and the answer is
contained therin. If these are the only two conteders and "ourperforms"
covers all considerations the answer is obvious.

At worst, it is rude.

Steve Blachman

From luke@wrs.com Wed May 22 11:48:59 1996
From: Luke Teyssier <luke@wrs.com>
Date: Wed May 22 11:49:01 PDT 1996
Subject: i960 and Loader Format Classes?
Hello,

Does anyone know of good clases in the San Francisco Bay Area for
the i960 Architecture family? I'm looking for a fairly intensive
class on assembly language details and idioms, comparison of the Cx,
Jx, Hx, Sx, Kx, Details of interrupt and Fault handling, register allocation
and similar topics, all from a low-level, intensive software perspective.

Also, does anyone have a pointer to good classes on loader formats such
as elf, coff, ecoff, and related formats?

Thanks for your help,
Luke
--
------------------------------------------------------------------------------
| Luke Teyssier email: luke@wrs.com |
| Wind River Systems http://www.wrs.com |
| 1010 Atlantic Avenue |
| Alameda, CA 94501 |
|-----------------------------------------------------------------------------

From MikeMcQuade@prometheus.connectsoft.net Wed May 22 16:39:18 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Wed May 22 16:39:24 PDT 1996
Subject: how do you allow a TCP socket to re-connect ?

In my application, my VxWorks box is the TCP socket server, Everything works
good the first time the Client connects. But if my client crashes, then Im
at a loss as to how I can re-establish the socket without rebooting the
VxWorks target.

Id like to be able to re-establish the socket fairly quick, ie < one minute.

Does anyone know how to make TCP re-connect ?

or have any sample code ?

Thanks.

MikeMcQuade@connect.com

From ng@netstal.ch Wed May 22 23:26:15 1996
From: ng@netstal.ch (Niklaus Giger)
Date: Wed May 22 23:26:17 PDT 1996
Subject: Re: how do you allow a TCP socket to re-connect ?
>Submitted-by: Mike McQuade <MikeMcQuade@connect.com>
>
>
>In my application, my VxWorks box is the TCP socket server, Everything works
>good the first time the Client connects. But if my client crashes, then Im
>at a loss as to how I can re-establish the socket without rebooting the
>VxWorks target.
>
>Id like to be able to re-establish the socket fairly quick, ie < one minute.
>
>Does anyone know how to make TCP re-connect ?
>or have any sample code ?
>

Here is our sample code:

acceptSockFd = socket (AF_INET, SOCK_STREAM, 0);
if (acceptSockFd == ERROR)
{
printf("\ncouldn't create socket for accepting");
}

 /* allow bind to socket, which is associated with a "zombie"
protocol control block */
optval = 1;
rc = setsockopt (acceptSockFd, SOL_SOCKET, SO_REUSEADDR, (char
*)&optval, sizeof (optval));

You find the answer also in the FAQ of the vxWorks Users Group.

Regards

Niklaus Giger
Abteilung TEI
Netstal Maschinen AG
CH-8752 Naefels (Switzerland)
Tel: +41 (0) 55/ 618 64 68
Fax: +41 (0) 55/ 612 42 41
Email: ng@netstal.ch

From daemon@csg.lbl.gov Thu May 23 04:00:24 1996
From: daemon@csg.lbl.gov
Date: Thu May 23 04:00:27 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Thu May 23 04:00:20 PDT 1996

 Subject: FDDI for custom 386 board

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

Newsgroups: comp.os.vxworks
Subject: FDDI for custom 386 board
Date: Wed, 22 May 1996 15:00:04 GMT
From: pete@imc4.eej.ulst.ac.uk (Pete Brett)
Message-ID: <832777280.23132.0@hathsys.demon.co.uk>

	I am developing a distributed data aquisition system using a 386EX
running vxWorks in each node. The system will be expected to operate
in a noisy environment and so several custommers will demand fibre for
LAN communications.

	The LAN will have two distinct types of traffic:-

	1) File transfer: file sizes up to a few MB soft real time
constraints.
	2) Short command packets with firm real time constraints (8 - 16 ms
for a message to be sent, processed and a reply returned) and timing
information.

	Any system using CSMA / CD is by nature not deterministic, but is very
available and fairly cheap.
	Has anyone used a chipset for a token passing LAN (preferably FDDI)?

	If so could you reply by posting or E-mail (pete@imc4.eej.ulst.ac.uk)

	I need to know manufacturers and distributers of chipsets, ball-park
prices and availability of vxWorks drivers.

Many thanks in advance,

		Pete

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

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

From leonid@rst.co.il Thu May 23 05:04:11 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Thu May 23 05:04:15 PDT 1996
Subject: Re: VXworks works, really?
> Why choose VXworks if a 486 running the QNX OS or kernel equals
> or outperforms VXworks on a 266Mhx Dec Alpha?

I do not know how well VxWorks on Alpha performs, but VxWorks surely
outperforms QNX on a i486. When comaring two OS's, compare them
on the same hardware.

From another prespective, it is probably true that VxWorks on Alpha is
a lot slower then on i486 in terms of interrupt response and context
switch. This is true for all RISC vs. CISC processors. RISC provide
much more computing power, with slower R-T response times.

Also, according to a study by Venture Development Corp. which covers
OS shipped on VMEbus based systems in 1994:
 VxWorks was the most popular with 15.8%,
 second came UNIX System V with 14.9%, third OS9 with 13.9%, ... and
 QNX appears last in the chart with only 1.1%.

Of course, the VMEbus is not the entire market, and QNX is a lot more
popular on embedded PCs, but this may after all change the mind
of some skeptics.

-----------------------------------------------------------------------
Leonid Rosenboim Phone: +972-3-559-8144
R S T Software Industries Ltd. Fax: +972-3-559-8244
3 Hashikma st. Industrial Zone, E-Mail: leonid@rst.co.il
P.O.Box 11502, AZUR 58017, Israel WindRiver Distributor
WWW: http://knight.trendline.co.il/~leonid/

From naivar@telomere.lanl.gov Thu May 23 07:14:29 1996
From: Mark Naivar <naivar@telomere.lanl.gov>
Date: Thu May 23 07:14:31 PDT 1996
Subject: Re: how do you allow a TCP socket to re-connect ?
Mike,

Here's some code I use to reconnect automatically when the socket
connection goes down. Hope this is what you're after.

It's a code fragment I ripped out of some code we're using so hopefully
all the important details are there. Let me know.

-Mark

/***************************************************************************
 *
 *
 */
#include <vxWorks.h>
#include <ioLib.h>
#include <stdlib.h>
#include <stdioLib.h>
#include <sysLib.h>
#include <socket.h>

/*********************************************************************
 * NAME
 * sysSockCreate
 *
 * DESCRIPTION
 * This routine creates a socket, waits for it to be
 * established, then returns the server and client
 * socket handles.
 *
 * RETURNS
 * OK or ERROR
 */
STATUS
sysSockCreate(u_short Port, int *serverSocket, int *clientSocket)
 {
 struct sockaddr serverSockAddr;
 struct sockaddr clientSockAddr;
 int addrLen=sizeof(serverSockAddr);
 u_short port;

 port = Port;

 /********************************************
 * Create the socket.
 */
 if( (*serverSocket=socket(AF_INET, SOCK_STREAM, 0)) == -1)
 {
 logMsg("ERROR: socket unsuccessful (0x%x)\n", errnoGet());
 return(ERROR);
 }

 /********************************************
 * Clear out the structure.
 */
 bzero(&serverSockAddr, addrLen);

 /********************************************
 * Specify the address family and the
 * port number.
 */
 serverSockAddr.sa_family=AF_INET;
 bcopy(&port, serverSockAddr.sa_data, sizeof(port));

 /********************************************
 * Associate the socket with the address.
 */
 if(bind(*serverSocket, &serverSockAddr, addrLen) == -1)
 {
 logMsg( "ERROR: bind unsuccessful (0x%x)\n", errnoGet());
 close(*serverSocket);
 return(ERROR);
 }

 /********************************************
 * Allow the socket to take connections.
 */
 if(listen(*serverSocket, 1) == -1)
 {
 logMsg( "ERROR: listen unsuccessful (0x%x)\n", errnoGet());
 close(*serverSocket);
 return(ERROR);
 }
 logMsg("Port %d(SYS) available.\n", port);

 /********************************************
 * Accept the connection request when
 * one is received.
 */
 return(*clientSocket=accept(*serverSocket, &clientSockAddr, &addrLen));
 }

/****************************************************************
 *
 * NAME
 * sysTask
 *
 * SYNOPSIS
 * status = sysTask();
 *
 * DESCRIPTION
 * This program opens a socket for communication to a host
 * computer. It listens for commands to arrive over the
 * socket and processes the commands.
 *
 * Commands are defined in the ntbcyproto.h file.
 *
 *
 */
STATUS
sysTask(void)
 {
 int serverSocket;
 int clientSocket;
 int numsend, numrcv, totrcv;
 int SysPort = 4000;

 sysCmd *cp;
 char cBuf[sizeof(sysCmd)];
 sysStat *sp;
 char sBuf[sizeof(sysStat)];

 /*************************************************************
 * Create the socket, wait for a connection to be made.
 */
 if(sysSockCreate(SysPort, &serverSocket, &clientSocket) != ERROR)
 logMsg("SYS connection established.\n");
 else return(ERROR);

 cp = (sysCmd *)cBuf;
 sp = (sysStat *)sBuf;

 /*******************************************************
 * MAIN LOOP
 *******************************************************
 * Wait for a command, then process it.
 *******************************************************
 * MAIN LOOP
 *******************************************************
 */
 while(1)
 {
 totrcv = 0;
 do
 {
 numrcv=recv(clientSocket, &cBuf[totrcv], sizeof(sysCmd)-totrcv, 0);
 if(numrcv <= 0)
 {
 /******************************************
 * Connection temporarily disconnected,
 * attempt to re-establish.
 */
 logMsg("CMD connection terminated(%d).\n", numrcv);

 if(shutdown(clientSocket, 2) != OK)
 logMsg("Shutdown client: 0x%x\n", errnoGet());
 if(close(clientSocket) != OK)
 logMsg("**ERROR closing client! (0x%x)\n", errnoGet());
 if(shutdown(serverSocket, 2) != OK)
 logMsg("Shutdown server: 0x%x\n", errnoGet());
 if(close(serverSocket) != OK)
 logMsg("**ERROR closing server! (0x%x)\n", errnoGet());

	do taskDelay(50);
 while(sysSockCreate(SysPort, &serverSocket, &clientSocket) == ERROR);

 logMsg("SYS connection established.\n");

	totrcv = 0;
 }
 else totrcv += numrcv;
 } while(totrcv < sizeof(sysCmd));

 /**************************************************
 * NOTE: We should use the network order
 * conversion routines, but VxWorks
 * does not have any, and 68K CPUs
 * are in network byte order.
 **************************************************
 */

 /*********************************
 * Process the command.
 */
 switch(cp->opcode)
	{
	default:
	 sp->result = ERROR;
 	 numsend=send(clientSocket, sBuf, sizeof(sysStat), 0);
	 break;
	}
 } /* while(1) */
 }

-----------------------------------------------------------------
| Mark Naivar | |
| Los Alamos National Lab | (505) 665-2034 (office) |
| LS-5, MS M888 | (505) 665-4254 (lab1) |
| P.O. Box 1663 | (505) 665-6738 (lab2) |
| Los Alamos, NM 87545 | (505) 667-1321 (FAX) |
-----------------------------------------------------------------

From del@rst.com Thu May 23 11:22:51 1996
From: del@rst.com (Mark Del Giorno)
Date: Thu May 23 11:22:54 PDT 1996
Subject: Redirecting printf()'s
Heyyyyyyyyyyyyyyyyyyyy,

I'm using MVME162's in an embedded application. I'm looking for
a simple way of redirecting all printf()'s so I can save all
output text in a battery-backed buffer until I can retrieve the
robotic vehicle and get to the information - rather than having the
printf()'s go to the serial port and have all those bits spilling
out the 25-pin D-sub.

Thanks in advance for any advice.

 _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com)
 _/ _/ _/ _/ (410) 876-9200 Fax: 876-9470
 _/_/_/_/ _/_/_/_/ _/ Robotic Systems Technology
 _/ _/ _/ _/ 1110 Business Parkway South
_/ _/ _/_/_/_/ _/ Westminster, MD 21157

From stan@rti.com Thu May 23 12:20:18 1996
From: Stan Schneider <stan@rti.com>
Date: Thu May 23 12:20:20 PDT 1996
Subject: Re: Redirecting printf()'s

>> Heyyyyyyyyyyyyyyyyyyyy,
>>
>> I'm using MVME162's in an embedded application. I'm looking for
>> a simple way of redirecting all printf()'s so I can save all
>> output text in a battery-backed buffer until I can retrieve the
>> robotic vehicle and get to the information - rather than having the
>> printf()'s go to the serial port and have all those bits spilling
>> out the 25-pin D-sub.
>>

I think you can just use open a file, and then use ioTaskStdSet on fd 1
(&2)...

 -- Stan
 stan@rti.com

From gverdun@fibertek.com Thu May 23 14:09:54 1996
From: "Gustavo H. Verdun" <gverdun@fibertek.com>
Date: Thu May 23 14:09:56 PDT 1996
Subject: Has anyone use Radstone's VME PPC603?

If you have any advice on this CPU I would appreciate it.

Software will be written in C and Ada (Green Hills) but not together...

Are there any gotcha's or other quirks that anyone may have encountered?

Thanks,

Gus

From uchenick@bud.tate.com Thu May 23 14:11:18 1996
From: Gordon Uchenick <uchenick@bud.tate.com>
Date: Thu May 23 14:11:20 PDT 1996
Subject: Re: Redirecting printf()'s
> I'm using MVME162's in an embedded application. I'm looking for
> a simple way of redirecting all printf()'s so I can save all
> output text in a battery-backed buffer until I can retrieve the
> robotic vehicle and get to the information - rather than having the
> printf()'s go to the serial port and have all those bits spilling
> out the 25-pin D-sub.

I've designed something like this. The battery backed ram is generated
as a DOS file system. If it's just one task doing the prints, you can
use ioTaskStdSet(). A dirtier trick might be to close fd 1 for stdout
or 2 for stderr and then reopen them to files in your battery backed buffer.

HTH,

Gordon
uchenick@tate.com

From 75104.3460@compuserve.com Thu May 23 20:21:01 1996
From: David Parkerson <75104.3460@compuserve.com>
Date: Thu May 23 20:21:03 PDT 1996
Subject: Re: 100 Mbit/s Ethernet
Hi Guys,
The natural replacment for a 162 is to go to PowerPC!. The VI Computer now a
part of THEMIS COMPUTER has a 604 with 100B-T standard.

Call 510-252-0870 for more info.

David Parkerson
Themis Regional Manager

From Scott.Peters@agai.com Fri May 24 11:56:28 1996
From: Scott Peters <Scott.Peters@agai.com>
Date: Fri May 24 11:56:30 PDT 1996
Subject: subscribe
subscribe

scott.peters@agai.com

begin 600 WINMAIL.DAT
M>)\^(@$2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0F `0`)````.#9$,$4P
M.#,`P@$!(( #``X```#,!P4`& `+`#H`.@`%`'0!`06 `P`.````S <%`!@`
M"P`Z`#H`!0!T`0$-@ 0``@````(``@`!!( !``H```!S=6)S8W)I8F4`P@,!
M`Y &`(P!```2````0 `Y`/ )=!"C2;L!'@`($ $````=````4U5"4T-224)%
M4T-/5%10151%4E- 04=!24-/30`````#`"8```````L`(P``````"P`I````
M```#`#8``````!X`< `!````"@```'-U8G-C<FEB90````(!<0`!````%@``
M``&[2:,0;R+3$)ZUEA'/E@P`@-B `AD```,`!A 2@?7M`P`'$!P````#`! 0
M``````,`$1 ``````@$)$ $```!Y````=0```-D```!,6D9UU*JP-/\`"@$/
M`A4"I /D!>L"@P!0-P+S!K0"@S(#Q0(`8VC!"L!S970P( <3`H#^?0J ",\)
MV0* "H0+-Q(R(0'0('-U8@3R8F4O"J,*A0J !/!O`D N<$,3( 20<T!A9PMP
M+A4%H&T7U7T:@ ```$ `!S!@=&\0HTF[`4 `"#!@=&\0HTF[`0,`#33]/P``
M`@$4- $````0````5)2AP"E_$!NEAP@`*RHE%QX`/0`!`````0````````"0
!40$4
`
end

From ZINGLEBJ@ocd231.bwi.wec.com Fri May 24 13:37:28 1996
From: "Zingler, Bill J." <ZINGLEBJ@ocd231.bwi.wec.com>
Date: Fri May 24 13:37:29 PDT 1996
Subject: X Windows for VxWorks

Greetings,

Does anyone know of any third party products that support X Windows on
VxWorks? Does anyone have any experiences they would like to share on
these products?

Thanks in advance,

Bill
_________________________________________________________________

Bill Zingler
Senior Software Engineer

Northrup Grumman Corp.
Oceanic Division/D.W. Complex
P.O. Box1488/MS-9RDW
Annapolis, MD 21404

Email: zinglebj@ocd231.bwi.wec.com
Phone: 410-260-5965
Fax: 410-260-5916

"The road of excess leads to the palace of wisdom." - William Blake
_________________________________________________________________

From craig@hicom.hitachi.com Fri May 24 16:25:58 1996
From: craig@spd.hitachi.com (Craig Humfrey)
Date: Fri May 24 16:26:00 PDT 1996
Subject: DOS File System public-ware?

I'm seeking public domain versions of a DOS file system to integrate
into a Flash memory application under VxWorks version 5.2

The ucar site depends on the dosFsLib.[ch] files, and the dosFsLib.c
file is not part of the standard distribution. Does anyone know
where such software might be available?

Craig Humphreys
Pacific Design Engineering
craig@pacengr.com

From guthrie@power.amasd.anatcp.rockwell.com Fri May 24 16:59:02 1996
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Fri May 24 16:59:04 PDT 1996
Subject: VxWorks boot EPROMS MVME167
One of my co-workers is having troubles with the VxWorks boot EPROMs
he received from Wind River on his MVME167.

	EPROMs 120ns
	MVME167 33Mhz

Using an emulator he can see that there are bit errors when the CPU
reads the EPROM. It does not appear to be a simple big endian/little endian
byte order type problem. The Motorola debugger program proms work
fine.

Anybody seen this?

	Robert Guthrie
	e-mail: guthrie@amasd.anatcp.rockwell.com

From seaweed!seaweed.com!bob@netcom.com Fri May 24 17:20:27 1996
From: bob schulman <bob@seaweed.com>
Date: Fri May 24 17:20:30 PDT 1996
Subject: Re: X Windows for VxWorks
> Does anyone know of any third party products that support X Windows on
> VxWorks? Does anyone have any experiences they would like to share on
> these products?
Seaweed Systems has been shipping X11R6 and Motif 2.0 products for
the vxWorks environment for over 2 years now. We supply both
client-side and server-side solutions in either object and source form.

Please contact me for more information.

Bob Schulman
bob@seaweed.com
+1 510.482-3575

From jhillman@wrs.com Fri May 24 19:07:38 1996
From: Jon Hillman <jhillman@wrs.com>
Date: Fri May 24 19:07:40 PDT 1996
Subject: Re: X Windows for VxWorks
At 01:37 PM 5/24/96 PDT, you wrote:
>Submitted-by ZINGLEBJ@ocd231.bwi.wec.com Fri May 24 13:37:28 1996
>Submitted-by: "Zingler, Bill J." <ZINGLEBJ@ocd231.bwi.wec.com>
>
>
>Greetings,
>
>Does anyone know of any third party products that support X Windows on
>VxWorks? Does anyone have any experiences they would like to share on
>these products?
>
>Thanks in advance,
>
>Bill
>_________________________________________________________________
>
>Bill Zingler
>Senior Software Engineer
>
>Northrup Grumman Corp.
>Oceanic Division/D.W. Complex
>P.O. Box1488/MS-9RDW
>Annapolis, MD 21404
>
>Email: zinglebj@ocd231.bwi.wec.com
>Phone: 410-260-5965
>Fax: 410-260-5916
>

Bill, contact your local Wind River Systems sales rep for information
on Visicom VX-Windows products. WRS resells these products.

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

From daemon@csg.lbl.gov Sat May 25 04:01:11 1996
From: daemon@csg.lbl.gov
Date: Sat May 25 04:01:14 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sat May 25 04:01:06 PDT 1996

 Subject: Re: Debugger Problems with Tornado 1.0
 Subject: Re: how do you allow a TCP socket to re-connect ?
 Subject: How to get ifIndex from WindNet SNMP
 Subject: 64MB and 128MB board availabe for MVME167
 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: Redirecting printf()'s
 Subject: Motorola MVME147 available
 Subject: ATM cards with VxWorks support?
 Subject: JOB: VA Real-time Embedded Engineer with VxWorks exp.
 Subject: Re: Has anyone use Radstone's VME PPC603?
 Subject: Re: Debugger Problems with Tornado 1.0
 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: Has anyone use Radstone's VME PPC603?

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

Newsgroups: comp.os.vxworks
Subject: Re: Debugger Problems with Tornado 1.0
Date: 23 May 1996 11:44:11 GMT
From: leif@tsl.uu.se (Leif Thuresson)
Organization: The Svedberg Lab
Message-ID: <4o1j2b$37cc@columba.udac.uu.se>
References: <4nsigf$7e8@uuneo.neosoft.com>

In article <4nsigf$7e8@uuneo.neosoft.com>, rick@scimisys.com says...
>
>I am using Tornado version 1.0 on Windows 95. We are having
>following problems with the debugger.
>
>1. When we attach to a task that is loaded with symbols we
>can only get an assembly listing.
>
>2. We can not control the source search path for the debugger
>through the IDE. We have to set it with the gcc commands.
>
>Is their someone else out their using Tornado on Windows 95?
>If so, are you having these types of problems?
>
>
>

I'm using Tornado with Sun Solaris and I have a similar problem.
I have the kernel compiled with the target resident shell. If I load
a module from the target shell (in a startup script) I can't make
CrossWind see the symbols from that module. I thought the CrossWind
command "add-symbol-file" (Tornado users guide p 236) was suppose
to fix this but I only get an error message.

Cannot find object module on target: LOADER_OBJ_MODULE_NOT_FOUND

I have been in contact with WRS support about this but so far they
have only suggested that I should use windsh -s <script-file> <target>
to load the startup script. This isn't a very attractive solution in
my case, since it means I then have to have the windsh running all the
time for the vxWorks system to boot up and initialise correctly.
I don't know if it's possible to run CrossWind over RDB the way it
was done before Tornado ? I've noticed the INCLUDE_RDB option in the
configuration tool but I haven't tried it yet. Any one have a solution
to this ?

/Leif

- ------------------------------------------------------------------------
Leif Thuresson, The Svedberg Laboratory, Uppsala University, Sweden
leif.thuresson@tsl.uu.se

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

Newsgroups: comp.os.vxworks
Subject: Re: how do you allow a TCP socket to re-connect ?
Date: 23 May 96 16:11:03 -0500
From: "Stephen Tether" <tether@lns.mit.edu>
Organization: FERMILAB, Batavia, IL
Message-ID: <ADCA3E9C-EE8BA9@131.225.103.76>
References: <199605222339.QAA18985@prometheus.connectsoft.net>

- --Cyberdog-AltBoundary-00EE8A8C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>In my application, my VxWorks box is the TCP socket server,
Everything works
>good the first time the Client connects. But if my client crashes,
then Im
>at a loss as to how I can re-establish the socket without rebooting
the
>VxWorks target.
>
>Id like to be able to re-establish the socket fairly quick, ie < one
minute.
>
>
>Does anyone know how to make TCP re-connect ?
>
>or have any sample code ?
>
>
>Thanks.
>
>
>MikeMcQuade@connect.com
>
In brief, if you've organized the server code properly you don't need
to do a thing.

At the start, the server task should have been blocked in accept(),
waiting for a connection. The first argument to accept() is the file
descriptor of the original, or parent, socket. When a client makes a
connection, accept() creates a brand new socket, transfers the
connection to it, and returns its file descriptor. You can then spawn
a new task to handle the connection (or allocate a pre-spawned task
from a pool for real speed) and pass it the new fd. The original
server task can now go back to accept(), still using the parent
socket, which is now back in the same state as it was before the
client connected.

If the client crashes, the task handling the connection should close
the the socket, using the fd returned by accept(), NOT THE ORIGINAL.
Even if this task bombs and gets suspended, or is unable to detect the
client crash, the original server task and its socket are unaffected.
If graceful termination is impossible, you will have to reboot the
server once in a while due to the accumulation of dead tasks and/or
sockets.

- - Steve Tether

- ---------------------------------------------------
This message was created and sent using the Cyberdog Mail System
- ---------------------------------------------------

- --Cyberdog-AltBoundary-00EE8A8C
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00EE8A8C"
Content-Transfer-Encoding: 7bit

- --Cyberdog-MixedBoundary-00EE8A8C
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<SMALLER><SMALLER><X-FONTSIZE><PARAM>9</PARAM><FIXED><X-FONTNAME><PARAM=
>Monaco</PARAM>>In my application, my VxWorks box is the TCP socket
server, Everything works

>good the first time the Client connects. But if my client crashes,
then Im

>at a loss as to how I can re-establish the socket without rebooting
the

>VxWorks target.

>

>Id like to be able to re-establish the socket fairly quick, ie << one
minute.

>

>

>Does anyone know how to make TCP re-connect ?

>

>or have any sample code ?

>

>

>Thanks.

>

>

</X-FONTNAME></FIXED></X-FONTSIZE></SMALLER></SMALLER><SMALLER><X-FONTS=
IZE><PARAM>10</PARAM><X-FONTNAME><PARAM>Geneva</PARAM>></X-FONTNAME></X=
- -FONTSIZE></SMALLER><SMALLER><SMALLER><X-FONTSIZE><PARAM>9</PARAM><FIXE=
D><X-FONTNAME><PARAM>Monaco</PARAM>MikeMcQuade@connect.com

</X-FONTNAME></FIXED></X-FONTSIZE></SMALLER></SMALLER><SMALLER><X-FONTS=
IZE><PARAM>10</PARAM><X-FONTNAME><PARAM>Geneva</PARAM>>

In brief, if you've organized the server code properly you don't need
to do a thing.

At the start, the server task should have been blocked in accept(),
waiting for a connection. The first argument to accept() is the file
descriptor of the original, or parent, socket. When a client makes a
connection, accept() creates a brand new socket, transfers the
connection to it, and returns its file descriptor. You can then spawn
a new task to handle the connection (or allocate a pre-spawned task
from a pool for real speed) and pass it the new fd. The original
server task can now go back to accept(), still using the parent
socket, which is now back in the same state as it was before the
client connected.

If the client crashes, the task handling the connection should close
the the socket, using the fd returned by accept(), NOT THE ORIGINAL.
Even if this task bombs and gets suspended, or is unable to detect the
client crash, the original server task and its socket are unaffected.
If graceful termination is impossible, you will have to reboot the
server once in a while due to the accumulation of dead tasks and/or
sockets.

- - Steve Tether

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

This message was created and sent using the Cyberdog Mail System

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

</X-FONTNAME></X-FONTSIZE></SMALLER>
- --Cyberdog-MixedBoundary-00EE8A8C--

- --Cyberdog-AltBoundary-00EE8A8C--

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

Newsgroups: comp.os.vxworks
Subject: How to get ifIndex from WindNet SNMP
Date: Thu, 23 May 1996 16:36:50 -0700
From: Nick Gandin <ngandin@gi.com>
Organization: Genral Instrument
Message-ID: <31A4F692.5C5F@gi.com>

I am constructing my private WindNet SNMP MIB table
that I would like to have a key as ifIndex from
the standard SNMP MIBII.

The question is how do I get ifIndex values in my
code? Do they have any API function for this?

Any hints are appreciated.

Nick Gandin
General Instrument
(619)455 1500 x.3511
ngandin@gi.com

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

Newsgroups: comp.os.vxworks
Subject: 64MB and 128MB board availabe for MVME167
Date: 24 May 1996 01:16:23 GMT
From: innov8@ix.netcom.com(M.W.)
Organization: Netcom
Message-ID: <4o32l7$359@sjx-ixn2.ix.netcom.com>

I have a 64MB and 128MB board available for the Motorola
MVME167 card. I also have a set of VXworks proms
available. E-mail if interested.
- --

E-mail: innov8@ix.netcom.com

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Thu, 23 May 96 14:36:10 GMT
From: danh@qnx.com (Dan Hildebrand)
Organization: QNX Software Systems
Message-ID: <4jtr23g6@qnx.com>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com> <elrDrtsLy.J2F@netcom.com>

In article <elrDrtsLy.J2F@netcom.com>, Eric Rabinowitz <elr@netcom.com> wrote:
>Consign, Inc. (consign@ix.netcom.com) wrote:
>: Why choose VXworks if a 486 running the QNX OS or kernel equals or
>: outperforms VXworks on a 266Mhx Dec Alpha?
>
>: Inquiring minds want to know.
>
>Interesting that you didn't sign you message.
>Apparently QNX is starting to feel some pressure from Tornado.

To the best of our knowledge, this message did not originate from QNX
Software Systems. We would agree that this sort of posting isn't
appropriate.

>Well there are a few reasons.
>I'm not sure where you got your information but according to the numbers
>published by QNX, VxWorks performs significantly better then QNX on that same
>66MHz 486 DX2.
>
>Other differences are many but include:
>VxWorks is a cross-development environment, QNX is native.
>There are certainly arguments for each so I won't go into it.

Actually, you can develop for QNX from Windows, OS/2 or NT as well.

>However this among other things makes it much easier to port VxWorks to an
>entirely different processor architecture since most of the development tools
>don't need to be ported to the real-time target. This is why VxWorks is
>available on the most popular processor for embedded designs (68k being the
>most popular, then PowerPC, Intel 80960, and 80x86 not nec. in that order)
>and other more specialized chips like CPU32, Mips, SPARC, Hitachi, Siemens,
>and others.

Our emphasis on x86 runtime targets is deliberate, and allows us to focus
on supporting virtually every device associated with x86 machines (embedded
or otherwise), rather than putting our efforts into supporting more CPU
families. Cross vs native development tool suites are not the reason for
our x86 emphasis.

>VxWorks minimum executable size is much smaller than QNX.
>QNX claims to be able to scale down to as little as 256K,
>VxWorks minimum is on the order of 20K (CISC).

Our next generation product is in beta. :-)

>Anyway for your reference:
>
>QNX 486 DX2 66MHz published results (QNX 4.21 Specifications)
>
>interrupt latency: 7 microseconds
>average context switching: 6 microseconds (user-level only)
>
>VxWorks 486 DX2 66MHz measured results (VxWorks 5.2)
>
>maximum interrupt latency: < 1.0 microseconds
>average context-switch: 1.9 microseconds (kernel and user-level)
>
>In any case the two environments are very different.

True - a noteworthy difference is that QNX is a POSIX-compliant OS and runs
user processes in separate, MMU-protected address spaces.
- --
Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: (613) 591-0931 (voice) Kanata, Ontario, Canada
 (613) 591-3579 (fax) K2M 1W8

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Fri, 24 May 1996 03:38:14 GMT
From: elr@netcom.com (Eric Rabinowitz)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <elrDrw4rq.16I@netcom.com>
Sender: elr@netcom.netcom.com

you wrote:
> Why choose VXworks if a 486 running the QNX OS or kernel equals or
> outperforms VXworks on a 266Mhx Dec Alpha?
>
> Inquiring minds want to know.

Hmmmmmmmmmm.

Well there are a few reasons.
I'm not sure where you got your information but according to the numbers
published by QNX, VxWorks performs significantly better then QNX on that same
66MHz 486 DX2.

Other differences are many but include:
VxWorks is a cross-development environment, QNX is native.
There are certainly arguments for each so I won't go into it.

However this among other things makes it much easier to port VxWorks to an
entirely different architecture since most of the development tools don't
need to be ported to the real-time target. This is why VxWorks is available
on the most popular processor for embedded designs (68k being the most popular,
then PowerPC, Intel 80960, and 80x86 not nec. in that order) and other more
specialized chips like CPU32, Mips, SPARC, Hitachi, Siemens, and some others
that I can't recall.

VxWorks' minimum executable size is much smaller than QNX.
QNX claims to be able to scale down to as little as 256K,
VxWorks minimum is on the order of 20K (CISC).

QNX has no visualization tools equivalent to WindView or Stethoscope.

QNX seems to have more PC-typical devices drivers, whereas VxWorks
has more embedded-type device drivers.

If fact VxWorks and QNX don't seem to compete too much.
Although I know of one VxWorks developer who liked both VxWorks and QNX, but
chose VxWorks simply because they wanted to be able to use the Intel 80960
on future designs, although at the time they were leaning toward using
the 80386/80486.

QNX has many happy customers who are doing native development on Intel 80x86
and don't ever intend to change to another processor architecture or O/S.

VxWorks has die-hard fans as well.

Anyway for your reference:

QNX 486 DX2 66MHz published results (QNX 4.21 Specifications)

interrupt latency: 7 microseconds
average context switching: 6 microseconds (user-level only)
average task response time: not published
maximum task response time: not published

VxWorks 486 DX2 66MHz measured results (VxWorks 5.2)

maximum interrupt latency: < 1.0 microseconds
average context-switch: 1.9 microseconds (kernel and user-level)
average task response time: 15 microseconds
maximum task response time: 25 usec

In any case the two environments are very different.

- -e

P.S. It's curious that you didn't sign your post, I wonder if that means that
 QNX is feeling some pressure from Tornado??
- --

Eric Linn Rabinowitz
Panoramic Systems
CA 408-289-7757 elr@netcom.com
WA 206-689-1707

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: 24 May 1996 01:23:52 GMT
From: marc@wrs.com (Marc Shepard)
Organization: Wind River Systems, Inc.
Message-ID: <4o3338$ft5@darya.wrs.com>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com>

Dude,

> Why choose VXworks if a 486 running the QNX OS or kernel equals or
> outperforms VXworks on a 266Mhx Dec Alpha?

This statement makes no sense at all.
The real question is the performance of VxWorks vs QNX when both
run on the 486.
If you switch OS's and platforms, then the result is likely to
depend only on the bechmark code and not on the OS's.
For example, context switch time on the 486 is probably faster
because the register set is smaller, regardless of which OS is running
on the 486.

VxWorks has several huge advantages over QNX:
 1) The development tools are much better, so you finish
 writing and debugging your application faster.
 2) It runs on a lot of different CPU's, so if your next project
 is better suited to a different processor, you can reuse
 your previous VxWorks code.

- -Marc

- --
 ```
marc@wrs.com (o o) (510)814-2142
- -----------------oOO--(_)--OOo--------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: Redirecting printf()'s
Date: 24 May 1996 12:24:00 GMT
From: johncoby@ghgcorp.com (JOHN R. COBARRUVIAS)
Organization: Personal Account
Message-ID: <johncoby-2405960718260001@ekm085.jsc.nasa.gov>
References: <199605232112.RAA05066@bud.tate.com>

In article <199605232112.RAA05066@bud.tate.com>, Gordon Uchenick
<uchenick@bud.tate.com> wrote:

> > I'm using MVME162's in an embedded application. I'm looking for
> > a simple way of redirecting all printf()'s so I can save all
> > output text in a battery-backed buffer until I can retrieve the
> > robotic vehicle and get to the information - rather than having the
> > printf()'s go to the serial port and have all those bits spilling
> > out the 25-pin D-sub.
>
> I've designed something like this. The battery backed ram is generated
> as a DOS file system. If it's just one task doing the prints, you can
> use ioTaskStdSet(). A dirtier trick might be to close fd 1 for stdout
> or 2 for stderr and then reopen them to files in your battery backed buffer.
>

Or try using ioGlobalStdSet(). this will reset your standard in/out to a
different device. Which could be your dos file system in nvram.

> HTH,
>
> Gordon
> uchenick@tate.com

- --

,-_/ . .-,--. ,---. .
' | ,-. |-. ,-. `|__/ | -' ,-. |-. ,-. ,-. ,-. . . . , . ,-. ,-.
 | | | | | | | | \ ,. | -. | | | | ,-| | | | | | / | ,-| `-.
 | `-' ' ' ' ' `-' ` `' `---' `-' `-' `-^ ' ' `-' `' ' `-^ `-'
/ | John R. Cobarruvias johncoby@ghgcorp.com Houston, Tx
`--'

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

Newsgroups: comp.os.vxworks
Subject: Motorola MVME147 available
Date: 21 May 1996 16:33:59 GMT
From: innov8@ix.netcom.com(M.W.)
Organization: Netcom
Message-ID: <4nsr9n$9ko@dfw-ixnews9.ix.netcom.com>

I have some Motorola MVME147 VME cards available.
E-mail if interested.
- --

E-mail: innov8@ix.netcom.com

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

Newsgroups: comp.os.vxworks
Subject: ATM cards with VxWorks support?
Date: 24 May 1996 14:08:42 GMT
From: newell@rd.bbc.co.uk (Chris Newell)
Organization: British Broadcasting Corporation, UK
Message-ID: <4o4fta$t5@bbcnews.rd.bbc.co.uk>

Does anyone know of an ATM Network Interface Card with VwWorks support?
I would be very interested to hear from anyone who has experience of ATM (at
any speed and with any host running VxWorks)

Chris Newell				 chris.newell@rd.bbc.co.uk
- ---------------------------------------------------------------------------
The opinions expressed here are my own and not necessarily those of the BBC

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

Newsgroups: comp.os.vxworks
Subject: JOB: VA Real-time Embedded Engineer with VxWorks exp.
Date: 24 May 1996 18:09:08 GMT
From: The Consortium <Consortium@internetMCI.com>
Organization: InternetMCI
Message-ID: <4o4u04$lq4@news.internetmci.com>

We are looking for several BSEE's with a real-time software engineering
background for both permanent and consulting opportunities in Northern VA.
Ideal candidate will have experience with Motorolla's 68040 chip, C, and
the Vxworks operating system.

If you would like to make a career change or want more information about
this position contact Mike Thron at:

			THE CONSORTIUM
			FAX (301) 652-2330
			PH (301) 986-1412 x3018
			E-Mail Consortium@internetmci.com
			http://www.consortiuminc.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Has anyone use Radstone's VME PPC603?
Date: 24 May 96 14:09:21 -0500
From: "Stephen Tether" <tether@lns.mit.edu>
Organization: FERMILAB, Batavia, IL
Message-ID: <ADCB7396-C6875@131.225.103.76>
References: <ADCB6BA5-A8ACD@131.225.103.76>

One thing I forgot: you should apply the Grande patch to your VxWorks
system library (ignore the parts for other BSPs). This fixes a lot of
annoying problems common to all boards, such as a tendency to hang during
loading of the symbol table and unreliable interrupt handling. Send a
message to support@wrs.com to find out how to get and apply the patch.

- - Steve

- ---------------------------------------------------
This message was created and sent using the Cyberdog Mail System
- ---------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: Debugger Problems with Tornado 1.0
Date: Fri, 24 May 1996 12:26:44 +0200
From: John Neumoege <John.Neumoege@ipk.fhg.de>
Organization: IPK-Berlin, Dep. of Control Engineering
Message-ID: <31A58EE4.7A46@ipk.fhg.de>
References: <4nsigf$7e8@uuneo.neosoft.com>

Rick Evans wrote:
>
> I am using Tornado version 1.0 on Windows 95. We are having
> following problems with the debugger.
>
> 1. When we attach to a task that is loaded with symbols we
> can only get an assembly listing.
>
> 2. We can not control the source search path for the debugger
> through the IDE. We have to set it with the gcc commands.
>
> Is their someone else out their using Tornado on Windows 95?
> If so, are you having these types of problems?
>
>

Hi Rick!

We are using Tornado 1.0 with vxWorks 5.3 and we are also having
similiar problems.

Greetings.
- --John

- --
- -------------------John Neumoege------------------------
Fraunhofer-IPK		e-mail:	John.Neumoege@ipk.fhg.de
Pascalstr. 8-9		Voice:	++49/(0)30/390 06-127
D-10587 Berlin		FAX:	++49/(0)30/391 10 37

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: 24 May 1996 09:05:15 -0700
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <4o4mnr$4ei@mr-ed.jpl.nasa.gov>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com> <elrDrtsLy.J2F@netcom.com> <4jtr23g6@qnx.com>

In article <4jtr23g6@qnx.com>, Dan Hildebrand <danh@qnx.com> wrote:
>In article <elrDrtsLy.J2F@netcom.com>, Eric Rabinowitz <elr@netcom.com> wrote:
>>Anyway for your reference:
>>
>>QNX 486 DX2 66MHz published results (QNX 4.21 Specifications)
>>
>>interrupt latency: 7 microseconds
>>average context switching: 6 microseconds (user-level only)
>>
>>VxWorks 486 DX2 66MHz measured results (VxWorks 5.2)
>>
>>maximum interrupt latency: < 1.0 microseconds
>>average context-switch: 1.9 microseconds (kernel and user-level)
>>
>>In any case the two environments are very different.
>
>True - a noteworthy difference is that QNX is a POSIX-compliant OS and runs
>user processes in separate, MMU-protected address spaces.

The QNX web site (www.qnx.com) now advertises that QNX 4.23 Proc32
does a context switch in, can you believe it, 2.6 milliseconds!

Matt

- --
matthew.r.wette@jpl.nasa.gov

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Fri, 24 May 96 20:42:46 GMT
From: danh@qnx.com (Dan Hildebrand)
Organization: QNX Software Systems
Message-ID: <k9wr2qca@qnx.com>
References: <9605231151.AA04387@rst.co.il>

In article <9605231151.AA04387@rst.co.il>,
Leonid Rosenboim <leonid@rst.co.il> wrote:
>> Why choose VXworks if a 486 running the QNX OS or kernel equals
>> or outperforms VXworks on a 266Mhx Dec Alpha?
>
>I do not know how well VxWorks on Alpha performs, but VxWorks surely
>outperforms QNX on a i486. When comaring two OS's, compare them
>on the same hardware.

Since VxWorks is not a protected-mode OS, it does not need to manipulate
the MMU on a context switch, so it has less work to do. The question is
whether or not MMU protection is valuable to the realtime system, and if it
is, how much overhead is worth incurring to have it.

>Also, according to a study by Venture Development Corp. which covers
>OS shipped on VMEbus based systems in 1994:
> VxWorks was the most popular with 15.8%,
> second came UNIX System V with 14.9%, third OS9 with 13.9%, ... and
> QNX appears last in the chart with only 1.1%.

Since QNX is an x86-only OS, and VME is a predominately non-x86 bus
architecture, the fact that QNX has a 1.1% market share on VME is quite
surprising. On x86 platforms (embedded or otherwise) Emerging Technologies
Group ranked QNX as the leading realtime OS.
- --
Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: (613) 591-0931 (voice) Kanata, Ontario, Canada
 (613) 591-3579 (fax) K2M 1W8

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: 24 May 1996 12:26:05 GMT
From: johncoby@ghgcorp.com (JOHN R. COBARRUVIAS)
Organization: Personal Account
Message-ID: <johncoby-2405960720310001@ekm085.jsc.nasa.gov>
References: <elrDrw4rq.16I@netcom.com>

In article <elrDrw4rq.16I@netcom.com>, elr@netcom.com (Eric Rabinowitz) wrote:

> you wrote:
> > Why choose VXworks if a 486 running the QNX OS or kernel equals or
> > outperforms VXworks on a 266Mhx Dec Alpha?
> >
> > Inquiring minds want to know.

Why buy an car when a bike will get you anywhere you need to go?

Hmmmmmm. This is not as easy to answer as it is to ask.

>
> Hmmmmmmmmmm.
>
> Well there are a few reasons.
> I'm not sure where you got your information but according to the numbers
> published by QNX, VxWorks performs significantly better then QNX on that same
> 66MHz 486 DX2.
>
> Other differences are many but include:
> VxWorks is a cross-development environment, QNX is native.
> There are certainly arguments for each so I won't go into it.
>
> However this among other things makes it much easier to port VxWorks to an
> entirely different architecture since most of the development tools don't
> need to be ported to the real-time target. This is why VxWorks is available
> on the most popular processor for embedded designs (68k being the most
popular,
> then PowerPC, Intel 80960, and 80x86 not nec. in that order) and other more
> specialized chips like CPU32, Mips, SPARC, Hitachi, Siemens, and some others
> that I can't recall.
>
> VxWorks' minimum executable size is much smaller than QNX.
> QNX claims to be able to scale down to as little as 256K,
> VxWorks minimum is on the order of 20K (CISC).
>
> QNX has no visualization tools equivalent to WindView or Stethoscope.
>
> QNX seems to have more PC-typical devices drivers, whereas VxWorks
> has more embedded-type device drivers.
>
> If fact VxWorks and QNX don't seem to compete too much.
> Although I know of one VxWorks developer who liked both VxWorks and QNX, but
> chose VxWorks simply because they wanted to be able to use the Intel 80960
> on future designs, although at the time they were leaning toward using
> the 80386/80486.
>
> QNX has many happy customers who are doing native development on Intel 80x86
> and don't ever intend to change to another processor architecture or O/S.
>
> VxWorks has die-hard fans as well.
>
>
> Anyway for your reference:
>
> QNX 486 DX2 66MHz published results (QNX 4.21 Specifications)
>
> interrupt latency: 7 microseconds
> average context switching: 6 microseconds (user-level only)
> average task response time: not published
> maximum task response time: not published
>
> VxWorks 486 DX2 66MHz measured results (VxWorks 5.2)
>
> maximum interrupt latency: < 1.0 microseconds
> average context-switch: 1.9 microseconds (kernel and user-level)
> average task response time: 15 microseconds
> maximum task response time: 25 usec
>
> In any case the two environments are very different.
>
> -e
>
> P.S. It's curious that you didn't sign your post, I wonder if that means that
> QNX is feeling some pressure from Tornado??
> --
>
> Eric Linn Rabinowitz
> Panoramic Systems
> CA 408-289-7757 elr@netcom.com
> WA 206-689-1707

- --

,-_/ . .-,--. ,---. .
' | ,-. |-. ,-. `|__/ | -' ,-. |-. ,-. ,-. ,-. . . . , . ,-. ,-.
 | | | | | | | | \ ,. | -. | | | | ,-| | | | | | / | ,-| `-.
 | `-' ' ' ' ' `-' ` `' `---' `-' `-' `-^ ' ' `-' `' ' `-^ `-'
/ | John R. Cobarruvias johncoby@ghgcorp.com Houston, Tx
`--'

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

Newsgroups: comp.os.vxworks
Subject: Re: Has anyone use Radstone's VME PPC603?
Date: 24 May 96 13:35:29 -0500
From: "Stephen Tether" <tether@lns.mit.edu>
Organization: FERMILAB, Batavia, IL
Message-ID: <ADCB6BA5-A8ACD@131.225.103.76>
References: <Pine.LNX.3.91.960523170351.15377B-100000@gw1>

- --Cyberdog-AltBoundary-000A89CB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>If you have any advice on this CPU I would appreciate it.
>
>Software will be written in C and Ada (Green Hills) but not
together...
>
>Are there any gotcha's or other quirks that anyone may have
encountered?
>

My group installed five of those about six weeks ago. The first board
support package from Radstone was missing all the man pages, so we had
to discover by trial and error that the correct network interface for
the boot parameters was lnPci; they came preset for ln. Radstone
immediately shipped us a correct BSP when we told them about this.

Our PPC603's didn't know their own Ethernet addresses. These were
supposed to be contained in the non-volatile RAM but there was garbage
there instead. We had to make a new boot EEPROM image (bootrom_uncmp)
after making sure the preprocessor symbol ETHERNET_ADR_SET
was defined in config.h. This enabled a new command "N" (not "n")
taking no arguments; it walks you through the process of setting the
Ethernet addresses. The lower order bits of the address are on a
teeny-tiny sticker on one of the VME connectors. If you're luckier
than we were, your boards will have the Ethernet addresses in EEPROM
on the network interface; try "n lnPci" at the VxWorks boot prompt and
see if it returns a valid address.

In vmeUniverse.c, sysVmeIntHandler() calls sysMailboxInt() and
sysVmeIntDispatch() before they have been defined or declared.This
gives both functions the default return type of int, and our compiler
(Diab) objects when it discovers that they return void. I moved
sysMailboxInt() in front of sysVmeIntHandler() and added a prototype
declaration for sysVmeIntDispatch(). The Green Hills compiler might
not detect this error.

WRS SPR #6319 states that register p0 is not set properly in sysALib.s
before calling usrInit(); it should be set to BOOT_NORMAL (=3D
BOOT_WARM_AUTOBOOT). The rs603 BSP also has this problem.

The maximum auxiliary clock rate is 2 KHz, as opposed to 5 KHz for the
system clock.

The BSP doesn't support the time-of-day clock.

Make sure that HALF_BUS_SPEED is either defined or undefined in
config.h. Check with Radstone to see which you need to do.
- ---
Steve Tether
Research Scientist, MIT Lab. for Nuclear Science
tether@lns.mit.edu

- ---------------------------------------------------
This message was created and sent using the Cyberdog Mail System
- ---------------------------------------------------

- --Cyberdog-AltBoundary-000A89CB
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000A89CB"
Content-Transfer-Encoding: 7bit

- --Cyberdog-MixedBoundary-000A89CB
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<SMALLER><SMALLER><X-FONTSIZE><PARAM>9</PARAM><FIXED><X-FONTNAME><PARAM=
>Monaco</PARAM>>If you have any advice on this CPU I would appreciate
it.

>

>Software will be written in C and Ada (Green Hills) but not
together...

>

</X-FONTNAME></FIXED></X-FONTSIZE></SMALLER></SMALLER><SMALLER><X-FONTS=
IZE><PARAM>10</PARAM><X-FONTNAME><PARAM>Geneva</PARAM>></X-FONTNAME></X=
- -FONTSIZE></SMALLER><SMALLER><SMALLER><X-FONTSIZE><PARAM>9</PARAM><FIXE=
D><X-FONTNAME><PARAM>Monaco</PARAM>Are there any gotcha's or other
quirks that anyone may have encountered?

</X-FONTNAME></FIXED></X-FONTSIZE></SMALLER></SMALLER><SMALLER><X-FONTS=
IZE><PARAM>10</PARAM><X-FONTNAME><PARAM>Geneva</PARAM>>

My group installed five of those about six weeks ago. The first board
support package from Radstone was missing all the man pages, so we had
to discover by trial and error that the correct network interface for
the boot parameters was lnPci; they came preset for ln. Radstone
immediately shipped us a correct BSP when we told them about this.

Our PPC603's didn't know their own Ethernet addresses. These were
supposed to be contained in the non-volatile RAM but there was garbage
there instead. We had to make a new boot EEPROM image (bootrom_uncmp)
after making sure the preprocessor symbol ETHERNET_ADR_SET

was defined in config.h. This enabled a new command "N" (not "n")
taking no arguments; it walks you through the process of setting the
Ethernet addresses. The lower order bits of the address are on a
teeny-tiny sticker on one of the VME connectors. If you're luckier
than we were, your boards will have the Ethernet addresses in EEPROM
on the network interface; try "n lnPci" at the VxWorks boot prompt and
see if it returns a valid address.

In vmeUniverse.c, sysVmeIntHandler() calls sysMailboxInt() and
sysVmeIntDispatch() before they have been defined or declared.This
gives both functions the default return type of int, and our compiler
(Diab) objects when it discovers that they return void. I moved
sysMailboxInt() in front of sysVmeIntHandler() and added a prototype
declaration for sysVmeIntDispatch(). The Green Hills compiler might
not detect this error.

WRS SPR #6319 states that register p0 is not set properly in sysALib.s
before calling usrInit(); it should be set to BOOT_NORMAL (=3D
BOOT_WARM_AUTOBOOT). The rs603 BSP also has this problem.

The maximum auxiliary clock rate is 2 KHz, as opposed to 5 KHz for the
system clock.

The BSP doesn't support the time-of-day clock.

Make sure that HALF_BUS_SPEED is either defined or undefined in
config.h. Check with Radstone to see which you need to do.

- ---

Steve Tether

Research Scientist, MIT Lab. for Nuclear Science

tether@lns.mit.edu

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

This message was created and sent using the Cyberdog Mail System

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

</X-FONTNAME></X-FONTSIZE></SMALLER>
- --Cyberdog-MixedBoundary-000A89CB--

- --Cyberdog-AltBoundary-000A89CB--

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

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

From leonid@rst.co.il Sat May 25 23:57:01 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Sat May 25 23:58:00 PDT 1996
Subject: Flash File System
> From: craig@spd.hitachi.com (Craig Humfrey)
> Date: Fri May 24 16:26:00 PDT 1996
> I'm seeking public domain versions of a DOS file system to integrate
> into a Flash memory application under VxWorks version 5.2

Implementation of DOS file systems on top of Flash memories is a common
method, and is called FTL - Flash Translation Layer. It is a relatively
simple thing to do, but the result is rather poor in terms of Flash
edurance and wear leveling. In other words, if a lot of updates
arte expected, the Flash memory will be worn out very quickly.

Also, the public sources on UCAR require modifications to dosFsLib,
which in turn require you to purxhase dosFsLib source code from Wind River.

On the other hand, you may consider purchasing FlashLib(tm) -
our implementation of the Microsoft Flash File System, which is a
LFS (Linear File System), and is
a lot more effecient in its use of the Flash memory life span, and
it can save a lot of space with it's included compression mechanism.

The cost of our Flash File System is roughly equal to one man month
worth of engineering, and provides full source code. Also, it costs
less then dosFsLib source from Wind River, it's a fully supported product,
and usually requires just a day's work to integrate it with your hardware.

For more detaisl about Flash Memory technologies see:

	http://www.systemsoft.com/wpapers/flash.htm

For details about our Flash File System, see the URL below.
-----------------------------------------------------------------------
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
http://knight.trendline.co.il/~leonid/	E-Mail:	leonid@rst.co.il

From daemon@csg.lbl.gov Sun May 26 04:00:39 1996
From: daemon@csg.lbl.gov
Date: Sun May 26 04:00:41 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Sun May 26 04:00:35 PDT 1996

 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: VXworks works, really?
 Subject: Re: Problems migrating from VxWorks 5.1 -> 5.2
 Subject: Re: VXworks works, really?
 Subject: Re: How to get ifIndex from WindNet SNMP

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Fri, 24 May 96 17:34:53 GMT
From: danh@qnx.com (Dan Hildebrand)
Organization: QNX Software Systems
Message-ID: <p3wr2vbd@qnx.com>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com> <elrDrtsLy.J2F@netcom.com> <4jtr23g6@qnx.com> <4o4mdh$4cs@mr-ed.jpl.nasa.gov>

In article <4o4mdh$4cs@mr-ed.jpl.nasa.gov>,
Matt Wette <mwette@mr-ed.jpl.nasa.gov> wrote:
>In article <4jtr23g6@qnx.com>, Dan Hildebrand <danh@qnx.com> wrote:
>>True - a noteworthy difference is that QNX is a POSIX-compliant OS and runs
>>user processes in separate, MMU-protected address spaces.
>
>OK, but is QNX multithreaded, providing users the ability to run
>multiple threads in the same address space? I didn't get the impression
>that this capability exists from gleening over the QNX net literature.
>Where's your 1003.1c stuff?

The existing product support non-POSIX threads, POSIX threads are in beta.
- --
Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: (613) 591-0931 (voice) Kanata, Ontario, Canada
 (613) 591-3579 (fax) K2M 1W8

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Tue, 21 May 1996 23:01:54 GMT
From: brucew@phoenix.net (Bruce Wedding)
Organization: BranPaul Systems
Message-ID: <4nti67$1qj@uhura.phoenix.net>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com>

In comp.os.vxworks
consign@ix.netcom.com(Consign, Inc. ) wrote:

>Why choose VXworks if a 486 running the QNX OS or kernel equals or
>outperforms VXworks on a 266Mhx Dec Alpha?
>
>Inquiring minds want to know.

Did you come here for a reason?

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Fri, 24 May 96 18:49:27 GMT
From: danh@qnx.com (Dan Hildebrand)
Organization: QNX Software Systems
Message-ID: <16wr2fan@qnx.com>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com> <elrDrtsLy.J2F@netcom.com> <4jtr23g6@qnx.com> <4o4mnr$4ei@mr-ed.jpl.nasa.gov>

In article <4o4mnr$4ei@mr-ed.jpl.nasa.gov>,
Matt Wette <mwette@mr-ed.jpl.nasa.gov> wrote:
>
>The QNX web site (www.qnx.com) now advertises that QNX 4.23 Proc32
>does a context switch in, can you believe it, 2.6 milliseconds!

Hey now - you found that on the beta section of our web site! Apparently
that web page itself hadn't quite finished beta testing. :-)

It now more correctly reads 2.6 microseconds.
- --
Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: (613) 591-0931 (voice) Kanata, Ontario, Canada
 (613) 591-3579 (fax) K2M 1W8

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

Newsgroups: comp.os.vxworks
Subject: Re: Problems migrating from VxWorks 5.1 -> 5.2
Date: 25 May 1996 02:35:11 GMT
From: dog@sunspot.noao.edu (Fritz Stauffer)
Organization: National Solar Observatory/SP
Message-ID: <4o5rkv$n5o@noao.edu>
References: <qsg290kvp8.fsf@ironmt.atl.com>

In article <qsg290kvp8.fsf@ironmt.atl.com> pgonza@atl.com (Pablo Gonzalez-Gandolfi) writes:
>
>I am having trouble migrating one of our applications from vxworks 5.1 to
>vxworks 5.2. The application makes heavy use of the vxworks directory structure
> ...
>Without getting into the guts of the application, I was wondering if anybody
>out there is aware of any known porting issues between 5.1 and 5.2 that
>are not in the release notes. In particular, changes in the FAT table, file
> ...

	I have intermittant trouble with writing to files using
	the SCSI library. I can hang in sbicProgBytesIn(). This
	was found by task tracing the hung task. This started after
	5.1.0.

	fritz stauffer

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: 24 May 1996 08:59:45 -0700
From: mwette@mr-ed.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <4o4mdh$4cs@mr-ed.jpl.nasa.gov>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com> <elrDrtsLy.J2F@netcom.com> <4jtr23g6@qnx.com>

In article <4jtr23g6@qnx.com>, Dan Hildebrand <danh@qnx.com> wrote:
>True - a noteworthy difference is that QNX is a POSIX-compliant OS and runs
>user processes in separate, MMU-protected address spaces.

OK, but is QNX multithreaded, providing users the ability to run
multiple threads in the same address space? I didn't get the impression
that this capability exists from gleening over the QNX net literature.
Where's your 1003.1c stuff?

Matt
- --
matthew.r.wette@jpl.nasa.gov

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

Newsgroups: comp.os.vxworks
Subject: Re: How to get ifIndex from WindNet SNMP
Date: Sun, 26 May 1996 11:29:12 +0300
From: Ron Keidar <rkeidar@qualcomm.com>
Organization: Qualcomm
Message-ID: <31A81658.6EA@qualcomm.com>
References: <31A4F692.5C5F@gi.com>

Nick Gandin wrote:
>
> I am constructing my private WindNet SNMP MIB table
> that I would like to have a key as ifIndex from
> the standard SNMP MIBII.
>
> The question is how do I get ifIndex values in my
> code? Do they have any API function for this?
>
> Any hints are appreciated.
>
> Nick Gandin
> General Instrument
> (619)455 1500 x.3511
> ngandin@gi.com

You may access the 'ifTable' from your code using 'm2IfTblEntryGet()'.
Look in WindNet man pages for this function as well as for m2SysLib,
m2IfLib, m2IpLib, etc....

		Ron Keidar

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

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

From daemon@csg.lbl.gov Mon May 27 04:00:17 1996
From: daemon@csg.lbl.gov
Date: Mon May 27 04:00:19 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Mon May 27 04:00:14 PDT 1996

 Subject: Measuring idle & interrupt time using Spy?

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

Newsgroups: comp.os.vxworks
Subject: Measuring idle & interrupt time using Spy?
Date: Mon, 27 May 1996 07:20:54 GMT
From: Michael Migdol <mmigdol@crl.mew.co.jp>
Organization: Matsushita El. Works, Ltd., Central Research Lab
Message-ID: <31A957D6.37DD@crl.mew.co.jp>
Sender: news@isc.mew.co.jp (USENET News System)

Hi all,

I know that Spy basically measures 3 things: # of ticks spent in each
task, # of ticks spent in ISR's, and # of ticks spent in idle time. The
time spent in each task is actually stored in the tasks' TCB in the
taskTicks field and can thus be retrieved externally from Spy. Where
are the idle time and ISR time information stored? Has anyone written
functions to retrieve that information? I've gone just about crazy
looking for it. :-)

Thanks in advance,
Michael
- --
Michael A. Migdol Research Engineer
Matsushita Electric Works, Ltd. Tel. 81-6-906-8075
Central Research Laboratory Fax 81-6-904-7104
1048 Kadoma, Osaka 571 Japan e-mail mmigdol@crl.mew.co.jp
 http://nesc.me.utexas.edu/~mmigdol/

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

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

From JAMES@lss-chq.mhs.compuserve.com Mon May 27 07:28:07 1996
From: "Hayes, James" <JAMES@lss-chq.mhs.compuserve.com>
Date: Mon May 27 07:28:09 PDT 1996
Subject: Re: VxWorks boot EPROMS MVME167

>One of my co-workers is having troubles with the VxWorks boot EPROMs
>he received from Wind River on his MVME167.
>
>	EPROMs 120ns
>	MVME167 33Mhz
>
>Using an emulator he can see that there are bit errors when the CPU
>reads the EPROM. It does not appear to be a simple big endian/little
endian
>byte order type problem. The Motorola debugger program proms work
>fine.
>
>Anybody seen this?

>	Robert Guthrie
>	e-mail: guthrie@amasd.anatcp.rockwell.com

We experienced the same trouble with an Atmel part.

	120ns versions did not work...
	100ns DO WORK !!!

James
Legacy Storage Systems Inc.

From MikeMcQuade@prometheus.connectsoft.net Mon May 27 10:28:51 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Mon May 27 10:28:52 PDT 1996
Subject: Passing Structs from Unix to PPC target.

Im having some difficulty passing a struct from my HP-UX host to my PowerPC
target.

The struct gets down to the target, but in order to read everything out on
the PPC side, I had to put in some padding variables (on the PPC).

Then once I pad the struct to get everything out, when I try to send it back
to the HP, elements are out of place.

Can anyone explain whats going on here ?

There must be a better way, ?

Thanks.
Mike McQuade
MikeMcQuade@connect.com

From daemon@csg.lbl.gov Tue May 28 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Tue May 28 04:00:24 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Tue May 28 04:00:18 PDT 1996

 Subject: Re: Debugger Problems with Tornado 1.0
 Subject: Re: VXworks works, really?
 Subject: Sweden
 Subject: Compatibility problem with dos and vxworks file system
 Subject: Re: routed for VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Re: Debugger Problems with Tornado 1.0
Date: 27 May 1996 19:24:13 GMT
From: steved@pacifier.com@199.2.117.163 (Steve Doiel)
Organization: Pacifier BBS, Vancouver, Wa. ((360) 693-0325)
Message-ID: <4ocvgu$oo2@news.pacifier.com>
References: <4nsigf$7e8@uuneo.neosoft.com>
Reply-To: steved@pacifier.com (Steve Doiel)

In <4nsigf$7e8@uuneo.neosoft.com>, Rick Evans <rick@scimisys.com> writes:
>I am using Tornado version 1.0 on Windows 95. We are having
>following problems with the debugger.
>
>1. When we attach to a task that is loaded with symbols we
>can only get an assembly listing.
>
>2. We can not control the source search path for the debugger
>through the IDE. We have to set it with the gcc commands.
>
>Is their someone else out their using Tornado on Windows 95?
>If so, are you having these types of problems?
>
>

Yes, we did encounter these problems. After a visit from a WRS FAE we
learned that most of our problems were due to case sensitivity. Tornado and
the GNU tools are rooted in the UNIX world which is case sensitive.

It was a co-worker that encoutered this problem on W95 (I'm using NT.) She
learned that apparently all of her problems were due to the inconsistant use
of case in file naming.

The folks at support@wrs.com should be up on this.
steved@pacififer.com

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: Wed, 22 May 1996 21:20:22 GMT
From: elr@netcom.com (Eric Rabinowitz)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <elrDrtsLy.J2F@netcom.com>
References: <4nssab$dpb@sjx-ixn5.ix.netcom.com>
Sender: elr@netcom.netcom.com

Consign, Inc. (consign@ix.netcom.com) wrote:
: Why choose VXworks if a 486 running the QNX OS or kernel equals or
: outperforms VXworks on a 266Mhx Dec Alpha?

: Inquiring minds want to know.

Interesting that you didn't sign you message.
Apparently QNX is starting to feel some pressure from Tornado.

Well there are a few reasons.
I'm not sure where you got your information but according to the numbers
published by QNX, VxWorks performs significantly better then QNX on that same
66MHz 486 DX2.

Other differences are many but include:
VxWorks is a cross-development environment, QNX is native.
There are certainly arguments for each so I won't go into it.

However this among other things makes it much easier to port VxWorks to an
entirely different processor architecture since most of the development tools
don't need to be ported to the real-time target. This is why VxWorks is
available on the most popular processor for embedded designs (68k being the
most popular, then PowerPC, Intel 80960, and 80x86 not nec. in that order)
and other more specialized chips like CPU32, Mips, SPARC, Hitachi, Siemens,
and others.

VxWorks minimum executable size is much smaller than QNX.
QNX claims to be able to scale down to as little as 256K,
VxWorks minimum is on the order of 20K (CISC).

QNX has no visualization tools equivalent to Windview or Stethoscope.

QNX seems to have more PC-typical devices drivers, whereas VxWorks
has more embedded-type device drivers.

VxWorks and QNX don't seem to compete too much.
Although I know of one VxWorks developer who liked both VxWorks and QNX, but
chose VxWorks simply because they wanted to be able to use the Intel 80960
on future designs, although at the time they were leaning toward using
the 80386/80486.

QNX has many happy customers who are doing native development on Intel 80x86
and don't ever intend to change to another processor architecture or O/S.

VxWorks has die-hard fans as well.

Anyway for your reference:

QNX 486 DX2 66MHz published results (QNX 4.21 Specifications)

interrupt latency: 7 microseconds
average context switching: 6 microseconds (user-level only)
average task response time: not published
maximum task response time: not published

VxWorks 486 DX2 66MHz measured results (VxWorks 5.2)

maximum interrupt latency: < 1.0 microseconds
average context-switch: 1.9 microseconds (kernel and user-level)
average task response time: 15 microseconds
maximum task response time: 25 usec

In any case the two environments are very different.

- -e
- --

Eric Linn Rabinowitz
Panoramic Systems
CA 408-289-7757 elr@netcom.com
WA 206-689-1707

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

Newsgroups: comp.os.vxworks
Subject: Sweden
Date: Mon, 27 May 1996 16:25:35 -0700
From: Brampton Library <library@spar.ca>
Organization: Spar Aerospace Ltd.
Message-ID: <31AA39EF.1327@spar.ca>

Hello!

I am a software engineer with 12 years experience mostly in Real Time
Embedded and GUI software development. In my last project I was the
project engineer for the development of the software for an 8 Degrees of
freedom robot controller. This was developed in C using vxWorks as the
real time OS. The Motif Based GUI was developed on a SUN SPARC using
XDesigner.

I am looking for a software development position in southern Sweden and
would appreciate your help greatly (like company names and possible point
of contact). I am currently employed but available within a reasonably
short period of time. I would also incur all moving expenses.

Thank you very much.. Be sure any help is greatly appreciated.

yfillion@wchat.on.ca

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

Newsgroups: comp.os.vxworks
Subject: Compatibility problem with dos and vxworks file system
Date: Tue, 28 May 1996 00:06:15 GMT
From: Tony Wu <tony@hpato.aus.hp.com>
Organization: Hewlett-Packard Co.
Message-ID: <31AA4377.13D1@hpato.aus.hp.com>
Sender: news@hparc12.aus.hp.com (News Daemon ID)

I am trying to format a scsi disk drive (1.2Gbyte) such that
a dos platform (DOS6.2) can understand the file format and VxWork's
dosFs can also understand it.

I've experiment with
1) formating a 200Mbyte disk and installing the file system as the
VxWork's
 dosFs. The PC does not want to recoginize the disk ( the pc does not
 want to recognize the disk as d: drive.)
2) fdisk the scsi drive under the pc to install the dos partition. The
PC
 recognise the scsi drive as a pc logical drive. VxWorks does not
recognise
 the disk and the dosFsInit failed.
 Would it work if I offset it by 1 block with scsiBlkDevCreate?

Is there anyway to get around this problem?

What is my best bet to have a 1.2Gbyte disk that can be understood by
vxworks, dos and unix machine?

Thanks in advance
Tony

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

Newsgroups: comp.os.vxworks
Subject: Re: routed for VxWorks
Date: 17 May 1996 19:02:09 GMT
From: witts@PROBLEM_WITH_INEWS_GATEWAY_FILE (Steve Witt)
Organization: Hughes Aircraft Company
Message-ID: <4niifh$aa8@venice.dh.trw.com>
References: <4ndt2g$2b8@neemit.synopsys.com>
Reply-To: sawitt@hac2arpa.hac.com

> Is there a routed-equivalent program available for VxWorks?
> I am using VxWorks 5.1.1 on a Force 5V, in case it matters.

Yes, in the VxWorks archive: ftp://ftp.atd.ucar.edu/pub/vxworks/vx
with several files called vxrouted...

- --

Steve Witt | mailto:sawitt@hac2arpa.hac.com
Hughes Aircraft Company
El Segundo, California

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

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

From froeber@bbn.com Tue May 28 05:06:33 1996
From: Fred Roeber <froeber@bbn.com>
Date: Tue May 28 05:06:35 PDT 1996
Subject: Re: comp.os.vxworks newsdigest
Michael Migdol asked about spyLib:
> Where
> are the idle time and ISR time information stored? Has anyone written
> functions to retrieve that information? I've gone just about crazy
> looking for it. :-)

The counters are kept in local variables inside spyLib so aren't easily
accessible. The spyLib works by adding a special aux clock interrupt
handler that bumps the local counts for idle and interrupt cycles as
well as task hooks to bump task counts kept in the TCB. Long ago I tried
to do the same thing you are but I had access to the source so could
make the variables global. Without source you are sort of out of luck.
Good luck anyway. Fred
--
 | Fred J Roeber, BBN Systems & Technologies |
 | 50 Enterprise Place Middletown, RI 02842-5202 |
 | froeber@bbn.com 401-849-2543 (X48) |
 | See http://www.bbn.com/tv for TraceMaker info |

From stan@rti.com Tue May 28 10:58:34 1996
From: Stan Schneider <stan@rti.com>
Date: Tue May 28 10:58:36 PDT 1996
Subject: Re: Passing Structs from Unix to PPC target.

>>
>> Im having some difficulty passing a struct from my HP-UX host to my PowerPC
>> target.
>>
>> The struct gets down to the target, but in order to read everything out on
>> the PPC side, I had to put in some padding variables (on the PPC).
>>
>> Then once I pad the struct to get everything out, when I try to send it back
>> to the HP, elements are out of place.
>>
>>
>> Can anyone explain whats going on here ?
>>

Compilers are free to pack structures as they see fit.

>>
>> There must be a better way, ?

Try XDR. It's easy & relatively cheap between big-endian machines. The
"rpcgen" compiler will do the hard work too. See "man rpcgen" on your HP.

 -- Stan

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

From pardo@rti.com Tue May 28 11:03:45 1996
From: Gerardo Pardo-Castellote <pardo@rti.com>
Date: Tue May 28 11:03:47 PDT 1996
Subject: Re: Passing Structs from Unix to PPC target.

>>
>> Im having some difficulty passing a struct from my HP-UX host to my PowerPC
>> target.
>>
>> The struct gets down to the target, but in order to read everything out on
>> the PPC side, I had to put in some padding variables (on the PPC).
>>
>> Then once I pad the struct to get everything out, when I try to send it back
>> to the HP, elements are out of place.
>>
>> Can anyone explain whats going on here ?
>> There must be a better way, ?

Each processor architecture uses possible different storage sizes
(e.g. 32 vs 64 bit pointers and integers), alignment, and even byte
ordering (big endian vs. little endian). Both PPC and hppa are big
endian so byte ordering isn't the problem in this case. But the others
still are. You can either pad your data manually on each processor so
the memory representation is the same, or alternatively, use a machine
independent data-representation format such as XDR.

	-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 brett@rti.com Tue May 28 15:33:41 1996
From: Brett Murphy <brett@rti.com>
Date: Tue May 28 15:33:43 PDT 1996
Subject: Re: X Windows for VxWorks

Greetings,

VisiCom has an X Windows product for VxWorks called VX-Windows. We used
it on two different x86 targets just a couple of months ago. We were quite
pleased with it. It was fast and has been working reliably for us. Check
the TradeWinds directory for more info. Their phone number is
 1-800-621-8474

 -- Brett

===============================================================================
= = =
= Brett Murphy = email: brett@rti.com =
= Real-Time Innovations, Inc. = Phone: (408) 720-8312 =
= 155A Moffet Park Drive, Suite 111 = Fax: (408) 734-5009 =
= Sunnyvale, CA 94089 = =
= = =
===============================================================================

> Submitted-by ZINGLEBJ@ocd231.bwi.wec.com Fri May 24 13:37:28 1996
> Submitted-by: "Zingler, Bill J." <ZINGLEBJ@ocd231.bwi.wec.com>
>
>
> Greetings,
>
> Does anyone know of any third party products that support X Windows on
> VxWorks? Does anyone have any experiences they would like to share on
> these products?
>
> Thanks in advance,
>
> Bill
> _________________________________________________________________
>
> Bill Zingler
> Senior Software Engineer
>
> Northrup Grumman Corp.
> Oceanic Division/D.W. Complex
> P.O. Box1488/MS-9RDW
> Annapolis, MD 21404
>
> Email: zinglebj@ocd231.bwi.wec.com
> Phone: 410-260-5965
> Fax: 410-260-5916
>

From daemon@csg.lbl.gov Wed May 29 04:00:22 1996
From: daemon@csg.lbl.gov
Date: Wed May 29 04:00:25 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Wed May 29 04:00:17 PDT 1996

 Subject: VxWorks FAQ where?
 Subject: shared memory configuration
 Subject: Re: Debugger Problems with Tornado 1.0
 Subject: programming the MC68302?
 Subject: !!! H E L P !!! MC 68060 FP Math Performance
 Subject: VxWorks -> PCNFS performance
 Subject: Software Engineer Wanted

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

Newsgroups: comp.os.vxworks
Subject: VxWorks FAQ where?
Date: Tue, 28 May 1996 12:05:28 GMT
From: wzhang@novice.uwaterloo.ca (W.Z.)
Organization: University of Waterloo
Message-ID: <Ds46x4.JDv@novice.uwaterloo.ca>
Sender: news@novice.uwaterloo.ca (Mr. News)

 Where can I find the VxWorks FAQ ?

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

Newsgroups: comp.os.vxworks
Subject: shared memory configuration
Date: 28 May 1996 08:24:04 GMT
From: mabbih@gi.univ-lr.fr (ABBIH Moustapha)
Organization: Universite de La Rochelle
Message-ID: <4oed74$otv@hpuniv.univ-lr.fr>

helo

I have to configure vxworks to support the shared memory objects. The master
and the slave boards are mvme162 types. The backplane is a vme bus. The
problem is how to determinate the anchor adresse for the slave board?. Or how
to configure the vme adresse base for a mvme162 ????.

If you have some ideas please help me..

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

Newsgroups: comp.os.vxworks
Subject: Re: Debugger Problems with Tornado 1.0
Date: Tue, 28 May 1996 12:42:51 GMT
From: nobody@nowhere
Organization: Northrop Grumman Corporation
Message-ID: <Ds488G.4xK@tron.bwi.wec.com>
References: <4nsigf$7e8@uuneo.neosoft.com> <4ocvgu$oo2@news.pacifier.com>
Sender: usenet@tron.bwi.wec.com (USEnet News Poster)

In article <4ocvgu$oo2@news.pacifier.com>, steved@pacifier.com (Steve Doiel) wrote:
>In <4nsigf$7e8@uuneo.neosoft.com>, Rick Evans <rick@scimisys.com> writes:
>>I am using Tornado version 1.0 on Windows 95. We are having
>>following problems with the debugger.
>>
>>1. When we attach to a task that is loaded with symbols we
>>can only get an assembly listing.
>>
>>2. We can not control the source search path for the debugger
>>through the IDE. We have to set it with the gcc commands.
>>
>>Is their someone else out their using Tornado on Windows 95?
>>If so, are you having these types of problems?
>>
>>
>
>Yes, we did encounter these problems. After a visit from a WRS FAE we
>learned that most of our problems were due to case sensitivity. Tornado and
>the GNU tools are rooted in the UNIX world which is case sensitive.
>
>It was a co-worker that encoutered this problem on W95 (I'm using NT.) She
>learned that apparently all of her problems were due to the inconsistant use
>of case in file naming.
>
>The folks at support@wrs.com should be up on this.
>steved@pacififer.com
>

I have also had problems with the debugger.

Originally, all of my source and object files were in a single directory and
everything worked well.

Problems started when we distributed source files in multiple directories and
included them in the "SourceSearchPath" dialog box of the debugger.

WRS has yet to respond to my detailed description of the problem sent last
week.

Chris Jones
cjones@digsys1.bwi.wec.com

Northrop Grumman - ESSD

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

Newsgroups: comp.os.vxworks
Subject: programming the MC68302?
Date: 23 May 1996 13:43:56 GMT
From: johncoby@ghgcorp.com (JOHN R. COBARRUVIAS)
Organization: Personal Account
Message-ID: <johncoby-2305960838190001@ekm085.jsc.nasa.gov>

I have to program the MC68302 Integrated Multiprotocol Processor, and I
don't know what the hell I am doing!

Can anyone shed some light, suggest a book to read? Anything? I am floundering!

I am using a PEP Modular Computer PVM30 with vxWorks 5.2.

- --

,-_/ . .-,--. ,---. .
' | ,-. |-. ,-. `|__/ | -' ,-. |-. ,-. ,-. ,-. . . . , . ,-. ,-.
 | | | | | | | | \ ,. | -. | | | | ,-| | | | | | / | ,-| `-.
 | `-' ' ' ' ' `-' ` `' `---' `-' `-' `-^ ' ' `-' `' ' `-^ `-'
/ | John R. Cobarruvias johncoby@ghgcorp.com Houston, Tx
`--'

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

Newsgroups: comp.os.vxworks
Subject: !!! H E L P !!! MC 68060 FP Math Performance
Date: 28 May 1996 21:20:21 GMT
From: ipss@roanoke.infi.net (ipss)
Organization: Industrial Process Support Services
Message-ID: <4ofqml$mlq@nw101.infi.net>

We are using an MVE177 with 68060 CPU and seeing greatly degraded FP
performance when dealing with numbers whose magnitude are less than
FLT_MIN. This can cause a fabs() call to go from 1 microsec to 53
microsec! Similar degradation occurs for all FP Math operations.

Has anyone else seen this and can suggest a workaround. This is of
great concern to us in a high speed (1KHz) application which is math
intensive.

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

Newsgroups: comp.os.vxworks
Subject: VxWorks -> PCNFS performance
Date: 28 May 1996 23:54:22 GMT
From: ashrafis@nt.com (Siamak Razzaghe-Ashrafi)
Organization: Northern Telecom Inc., Mission Park
Message-ID: <4og3ne$2a3@nrchh52.rich.nt.com>

Hi

I am having some preformace problems with my vxWorks NFS server.
I have vxWorks 5.2 on a 68360 with a 170MB IDE Drive.

I can transfer 32kbyte/sec from my Sparc station to my vxWorks box by
NFS mounting the file system over 10Mb ethernet.
Is this about the norm.

From a PC client running NFS software I can only get 19Kbyte/sec.

Is anyone doing vxWorks server to PC client NFS file transfer?
If so what kinds of numbers are you getting?

I know my lan is going at lest 5Mb and I was able to copy info from the ram disk to
the hard drive at 225kbyte/sec so I know my hard drive is not the bottle neck.

Any Ideas.

Thankx in advance.

ashrafis@nt.com
- --
Hi

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

Newsgroups: comp.dsp,comp.software-eng,comp.realtime,comp.unix.programmer,nj.jobs,misc.jobs.offered,comp.os.vxworks
Subject: Software Engineer Wanted
Date: Tue, 28 May 1996 21:10:35 GMT
From: "Terry K. Lim" <tkl@pentek.com>
Organization: Pentek, Inc.
Message-ID: <31AB6BCB.41C67EA6@pentek.com>

Position Available: Software Engineer
Company: Pentek, Inc.

 COMPANY DESCRIPTION
Manufacturer of digital signal processing and data acquisition
products for VME and VXI.

 QUALIFICATIONS
Strong C/UNIX programming and experience interfacing with hardware
devices is required. Multiple UNIX or real-time OS platform
experience a plus.

 JOB DESCRIPTION
Responsibilities include developing and maintaining UNIX and
real-time OS drivers for Pentek hardware as well as developing and
maintaining support packages that link 3rd party software products
to Pentek hardware and software.

Contact:

	Terry Lim
	Director of Software Engineering
	Pentek, Inc.
	55 Walnut St.
	Norwood, NJ 07648

	e-mail: tkl@pentek.com
	FAX: (201) 767-7179

- --
Terry Lim | Voice: (201) 767-7100
Director of Software Engineering | FAX: (201) 767-7179
Pentek, Inc. | BBS: (201) 767-8733

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

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

From FREGEAU@digsys1.bwi.wec.com Wed May 29 08:03:50 1996
From: "JEAN FREGEAU" <fregeau@digsys1.bwi.wec.com>
Date: Wed May 29 08:03:52 PDT 1996
Subject: logMsg shared memory message Q??
I would like to route output from all of the boards in my system to a
single output source. Does anyone know of a way to use the logMsg
feature with a shared memory message Q?

Thanks!
Jean Fregeau
fregeau@digsys1.bwi.wec.com

Northrop Grumman - ESSD

From ANDERSDG@f3groups1.fsd.jhuapl.edu Wed May 29 12:53:56 1996
From: "Anderson, Derek G." <ANDERSDG@f3groups1.fsd.jhuapl.edu>
Date: Wed May 29 12:53:58 PDT 1996
Subject: MVME147 Synchronous serial port driver

My version of vxworks only supports asynchronous mode of operation of
the on-board Z8530 SCC's. Vxworks says they do not have a driver to
support synchronous mode on the MVME147, so I was wondering if anyone has
written one. that I could use. I am using port 1,2,and 3 in asynchronous,

port 4 in synchronous. Also, has anyone who used both modes of operation
on the 147 run into major problems; possibly concerning only one
interrupt vector per chip.

Thanks,
Derek

derek.anderson@jhuapl.edu
(410)792-6000 x3746

From vince@lassen.rti.com Wed May 29 15:05:03 1996
From: vince@rti.com (Vince Chen)
Date: Wed May 29 15:05:46 PDT 1996
Subject: RE: !!! H E L P !!! MC 68060 FP Math Performance
> We are using an MVE177 with 68060 CPU and seeing greatly degraded FP
> performance when dealing with numbers whose magnitude are less than
> FLT_MIN. This can cause a fabs() call to go from 1 microsec to 53
> microsec! Similar degradation occurs for all FP Math operations.
>
> Has anyone else seen this and can suggest a workaround. This is of
> great concern to us in a high speed (1KHz) application which is math
> intensive.

Yes, you are getting underflow exception errors. You'll have to figure
out how to turn that off. This is a problem on 167 boards as well.

We had first noticed this when comparing performance of applications
running single-precision vs. double-precision calculations. We were
surprised to see that the single-precision version ran slower.

The reason was that it (a simulated controls system) was doing such a
good job that the errors in the system were below FLT_MIN, thereby
generating underflow exceptions. It took the double-precision
application much longer to hit its underflow limit, so it ran faster
before that point.

We "fixed" the problem by injection noise on the order of FLT_MIN into
the system, since we couldn't disable exception-handling for
underflow.

-vince

P.S. (plug) We figured all this out using our ScopeProfile profiling
tool.

==========================================================================
= = =
= Vincent Chen = email: vince@rti.com =
= Real-Time Innovations, Inc. = Phone: (408) 720-8312 =
= 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 =
= Sunnyvale, CA 94089 = =
==========================================================================

From dbruce@targettech.com Wed May 29 15:07:38 1996
From: dbruce@targettech.com (Dave Bruce)
Date: Wed May 29 15:08:21 PDT 1996
Subject: http server for VxWorks
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 20

My company, Target Technologies, is currently in the process of
developing a http server for VxWorks for some of our internal products.
The core functionality is working and we are currently deciding on the
paradigm for forms support. I don't know if we have decided if we will be
marketing it as a separate product yet, but you could try sending email
to info@targettech.com if you are interested.

Since I have seen several posts asking about the availibility of a VxWorks
based http server, I thought I would post a broadcast response rather
than to the individuals.

================================================================
David R. Bruce dbruce@targettech.com
Project Engineer http://www.targettech.com
Target Technologies, Inc. Real-Time System Integration,
(508)657-9940 Products, and Consulting Services
===============================================================

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: httppost
X-Sun-Content-Lines: 20

My company, Target Technologies, is currently in the process of
developing a http server for VxWorks for some of our internal products.
The core functionality is working and we are currently deciding on the
paradigm for forms support. I don't know if we have decided if we will be
marketing it as a separate product yet, but you could try sending email
to info@targettech.com if you are interested.

Since I have seen several posts asking about the availibility of a VxWorks
based http server, I thought I would post a broadcast response rather
than to the individuals.

================================================================
David R. Bruce dbruce@targettech.com
Project Engineer http://www.targettech.com
Target Technologies, Inc. Real-Time System Integration,
(508)657-9940 Products, and Consulting Services
===============================================================

From "heiner@hic334.decnet.bosch.de"@hic334.decnet.bosch.de Thu May 30 03:37:45 1996
From: Andreas Heiner <"heiner@hic334.decnet.bosch.de"@hic334.decnet.bosch.de>
Date: Thu May 30 03:37:47 PDT 1996
Subject: ISDN for VME and CAPI2.0
Hello guys

I am looking for ISDN adapter cards to plug into a VME rack. I want to use
it with a CAPI2.0 driver.
Is there anybody who had the same problem and can give me some hints from
which company/distributor I can buy such VME-ISDN boards and where I can
get an ISDN-CAPI2.0 (maybe CAPI1.2 is enough to start) driver for VxWorks?

Regards,

Andreas Heiner

Internet: Andreas.Heiner@fr.bosch.de

c/o Robert Bosch GmbH
Dept. FV/SLH
(Corporate Research and Development Systems 2 / Advanced Development
Communications)
Robert-Bosch-Str. 200
D-31139 Hildesheim
Germany
Phone (+49) 5121 493946
FAX (+49) 5121 492520

From daemon@csg.lbl.gov Thu May 30 04:00:30 1996
From: daemon@csg.lbl.gov
Date: Thu May 30 04:00:32 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Thu May 30 04:00:27 PDT 1996

 Subject: Re: i960 and Loader Format Classes?

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

Newsgroups: comp.os.vxworks
Subject: Re: i960 and Loader Format Classes?
Date: 28 May 1996 17:49:12 -0700
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <4og6u8$3oj@elaine25.Stanford.EDU>
References: <199605221848.AA21830@niagra.wrs.com>

In article <199605221848.AA21830@niagra.wrs.com>,
Luke Teyssier <luke@wrs.com> wrote:
>Hello,
>
>Does anyone know of good clases in the San Francisco Bay Area for
>the i960 Architecture family? I'm looking for a fairly intensive
>class on assembly language details and idioms, comparison of the Cx,
>Jx, Hx, Sx, Kx, Details of interrupt and Fault handling, register allocation
>and similar topics, all from a low-level, intensive software perspective.

Don't know about any classes. But Intel has lots of FREE manuals.
Call their Literature Hotline 1-800-548-4725 and order the following:

i960 Processor Assembler's Guide
i960 Processor Software Utilities User Guide
gcc960 User's manual
gdb960 User's manual

These will be shipped to you for FREE!!! You can download the source code etc
from ftp.intel.com. Look for GNUTOOLS960 or something like that.

Also purchase a copy of ...

i960 Cx Microprocessor User's Manual

Which will tell you 95% of what you need to know about i960?

The 5% it doesn't tell you?

Things like ...

Can I my code use region 0 for anything (e.g. stack space)?
If anybody knows please post an answer.

- -earl

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

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

From andyg@emass.com Thu May 30 07:01:36 1996
From: Andy Gross <andyg@emass.com>
Date: Thu May 30 07:01:38 PDT 1996
Subject: Re: i960 and Loader Format Classes?
> Newsgroups: comp.os.vxworks
> Subject: Re: i960 and Loader Format Classes?
> Date: 28 May 1996 17:49:12 -0700
> From: kla@leland.Stanford.EDU (Earl Mitchell)
> Organization: Stanford University, CA 94305, USA
> Message-ID: <4og6u8$3oj@elaine25.Stanford.EDU>
> References: <199605221848.AA21830@niagra.wrs.com>
>
> In article <199605221848.AA21830@niagra.wrs.com>,
> Luke Teyssier <luke@wrs.com> wrote:
> >Hello,
> >
> >Does anyone know of good clases in the San Francisco Bay Area for
> >the i960 Architecture family? I'm looking for a fairly intensive
> >class on assembly language details and idioms, comparison of the Cx,
> >Jx, Hx, Sx, Kx, Details of interrupt and Fault handling, register allocation
> >and similar topics, all from a low-level, intensive software perspective.
>
> Don't know about any classes. But Intel has lots of FREE manuals.
> Call their Literature Hotline 1-800-548-4725 and order the following:
>
> i960 Processor Assembler's Guide
> i960 Processor Software Utilities User Guide
> gcc960 User's manual
> gdb960 User's manual
>
> These will be shipped to you for FREE!!! You can download the source code etc
> from ftp.intel.com. Look for GNUTOOLS960 or something like that.
>
> Also purchase a copy of ...
>
> i960 Cx Microprocessor User's Manual
>
> Which will tell you 95% of what you need to know about i960?
>
> The 5% it doesn't tell you?
>
> Things like ...
>
> Can I my code use region 0 for anything (e.g. stack space)?
> If anybody knows please post an answer.
>
> - -earl

It's been a while since I did anything with the Cx (I'm using the Jx now),
but I believe region 0 can be used for anything. However, all accesses
to the first 1K (this size may change based on which chip you are using -
I'm not sure) will go onchip. The rest of region 0 may be configured
any way you wish.

BTW, I believe that in the "Solutions 960" book they describe the different
families. There is also an "i960 Processors and Related Products" manual
that would be of some help. Earl is correct - talk to Intel's documentation
department. They have plenty of material for you. There's probably stuff
on their fax-back service also...

Please note; either decide on your processor first or get the User's Manual
to each one you are considering. The major differences will be in the
older lines (S, K, C) vs. the newer lines (J, H). While the newer ones
support the i960 core instructions, they've added some.

If you're planning on using vxWorks with the i960, you should be aware
that the Cygnus GNU compiler that they're shipping with Tornado (at
least on the PC) does not support the new i960 instructions. This
is actually a problem with the assembler - it hasn't been updated
for the new lines. Additionally, any new optimizations specific
to the J or H are not in there - optimization is done for the C.

Andy

--
Andy Gross EMASS
Senior Software Engineer 10949 E. Peakview Ave.
E-Mail: andyg@emass.com Englewood, CO 80111
 (303) 705-3762

From MikeMcQuade@prometheus.connectsoft.net Thu May 30 12:19:23 1996
From: Mike McQuade <MikeMcQuade@connect.com>
Date: Thu May 30 12:19:25 PDT 1996
Subject: whats the proper use of sysBusToLocalAdrs()

Whats the correct use of sysBusToLocalAdrs() ?

Ive got several adresses in my header file that Id like to use this call on
to get the correct adress dynamicaly.

The way I used it in the past was to run it one time, note the base address
for STD I/O space, then go back and edit my header file, to put in the
correct addresses.

Any suggestions. ?

Thanks
MikeMcQuade@connect.com

From aisie.aisinc.com!aisinc.com!pew@msen.com Thu May 30 12:30:15 1996
From: pew@aisinc.com (Paul E. Wilt)
Date: Thu May 30 12:30:18 PDT 1996
Subject: Re: i960 and Loader Format Classes?
>
> Submitted-by andyg@emass.com Thu May 30 07:01:36 1996
> Submitted-by: Andy Gross <andyg@emass.com>
>
> > Newsgroups: comp.os.vxworks
> > Subject: Re: i960 and Loader Format Classes?
> > Date: 28 May 1996 17:49:12 -0700
> > From: kla@leland.Stanford.EDU (Earl Mitchell)
> > Organization: Stanford University, CA 94305, USA
> > Message-ID: <4og6u8$3oj@elaine25.Stanford.EDU>
> > References: <199605221848.AA21830@niagra.wrs.com>
> >
> > In article <199605221848.AA21830@niagra.wrs.com>,
> > Luke Teyssier <luke@wrs.com> wrote:
> > >Hello,
> > >
> > >Does anyone know of good clases in the San Francisco Bay Area for
> > >the i960 Architecture family? I'm looking for a fairly intensive
> > >class on assembly language details and idioms, comparison of the Cx,
> > >Jx, Hx, Sx, Kx, Details of interrupt and Fault handling, register allocation
> > >and similar topics, all from a low-level, intensive software perspective.
> >
> > Don't know about any classes. But Intel has lots of FREE manuals.
> > Call their Literature Hotline 1-800-548-4725 and order the following:
> >
> > i960 Processor Assembler's Guide
> > i960 Processor Software Utilities User Guide
> > gcc960 User's manual
> > gdb960 User's manual
> >
> > These will be shipped to you for FREE!!! You can download the source code etc
> > from ftp.intel.com. Look for GNUTOOLS960 or something like that.
> >
> > Also purchase a copy of ...
> >
> > i960 Cx Microprocessor User's Manual
> >
> > Which will tell you 95% of what you need to know about i960?
> >
> > The 5% it doesn't tell you?
> >
> > Things like ...
> >
> > Can I my code use region 0 for anything (e.g. stack space)?
> > If anybody knows please post an answer.
> >
> > - -earl
>
> It's been a while since I did anything with the Cx (I'm using the Jx now),
> but I believe region 0 can be used for anything. However, all accesses
> to the first 1K (this size may change based on which chip you are using -
> I'm not sure) will go onchip. The rest of region 0 may be configured
> any way you wish.
Be careful of the setting you use for the number of register cache sets
used. The default number of register caches (5, I believe) does not use
much of the internal RAM. However, if you set the cache size to a larger
value, the area from 0x3ff and downward will be used. We currently use
9 register cache sets. This ends up eating internal RAM from 0x300-0x3ff
for register caches. Another thing to realize is that if you use the
cached interrupt vector capability of the i960, up to the first 64 bytes
of internal RAM are used to cache these vectors (0x000-0x040).

Another thing to watch: The "i960 Cx Microprocessor User's Manual" has
an error in it when describing register caches. Table 5-1 in the March
1994 version of the manual (p 5-9) indicates that each register cache
takes 16 bytes. Actually each register cache is 64 bytes (16 registers
* 4 bytes/register). We ran afoul of this last year when trying to
increase the number of register sets we used in our system.

Just thought you might find this information useful.
>
> BTW, I believe that in the "Solutions 960" book they describe the different
> families. There is also an "i960 Processors and Related Products" manual
> that would be of some help. Earl is correct - talk to Intel's documentation
> department. They have plenty of material for you. There's probably stuff
> on their fax-back service also...
>
> Please note; either decide on your processor first or get the User's Manual
> to each one you are considering. The major differences will be in the
> older lines (S, K, C) vs. the newer lines (J, H). While the newer ones
> support the i960 core instructions, they've added some.
>
> If you're planning on using vxWorks with the i960, you should be aware
> that the Cygnus GNU compiler that they're shipping with Tornado (at
> least on the PC) does not support the new i960 instructions. This
> is actually a problem with the assembler - it hasn't been updated
> for the new lines. Additionally, any new optimizations specific
> to the J or H are not in there - optimization is done for the C.
>
> Andy
>
>
> --
> Andy Gross EMASS
> Senior Software Engineer 10949 E. Peakview Ave.
> E-Mail: andyg@emass.com Englewood, CO 80111
> (303) 705-3762
--
=============================================================================
Paul Wilt, Sr Software Engineer (313) 332-7044 FAX : (313) 332-7077
Applied Intelligent Systems, Inc. pew@aisinc.com
110 Parkland Plaza
Ann Arbor, MI 48103
=============================================================================

From daemon@csg.lbl.gov Fri May 31 04:00:30 1996
From: daemon@csg.lbl.gov
Date: Fri May 31 04:00:32 PDT 1996
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest Fri May 31 04:00:27 PDT 1996

 Subject: Re: VXworks works, really?
 Subject: Benchmarking VxWorks
 Subject: 3C595 100Mb/sec ethernet driver
 Subject: B E W A R E 68060 & 68040 Math Performance is Terrible ! ! !

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

Newsgroups: comp.os.vxworks
Subject: Re: VXworks works, really?
Date: 28 May 1996 17:25:35 -0700
From: kla@leland.Stanford.EDU (Earl Mitchell)
Organization: Stanford University, CA 94305, USA
Message-ID: <4og5hv$38f@elaine25.Stanford.EDU>
References: <9605231151.AA04387@rst.co.il> <k9wr2qca@qnx.com>

In article <k9wr2qca@qnx.com>, Dan Hildebrand <danh@qnx.com> wrote:
>In article <9605231151.AA04387@rst.co.il>,
>Leonid Rosenboim <leonid@rst.co.il> wrote:
>>> Why choose VXworks if a 486 running the QNX OS or kernel equals
>>> or outperforms VXworks on a 266Mhx Dec Alpha?
>>
>>I do not know how well VxWorks on Alpha performs, but VxWorks surely
>>outperforms QNX on a i486. When comaring two OS's, compare them
>>on the same hardware.
>
>Since VxWorks is not a protected-mode OS, it does not need to manipulate
>the MMU on a context switch, so it has less work to do. The question is
>whether or not MMU protection is valuable to the realtime system, and if it
>is, how much overhead is worth incurring to have it.

They probably made the right choice since this is an application
specific issue. But this doesn't make you feel any better when you are
desperately trying to find a bug in code causing memory to be overwritten. ;-)

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

Newsgroups: comp.os.vxworks
Subject: Benchmarking VxWorks
Date: 29 May 1996 04:47:21 GMT
From: gms4vme@ix.netcom.com (Benjamin Sharfi)
Organization: Netcom
Message-ID: <4ogksp$siu@sjx-ixn3.ix.netcom.com>

Hi,

I am looking for a benchmark suite that will allow me to benchmark
various single board computers with various CPU's using VxWorks.

Can any one out there help !!

Please E-Mail reponse to gms4vme@ix.netcom.com

Thank You

Don Palmer - Project Manager
General Micro Systems, Inc

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

Newsgroups: comp.os.vxworks
Subject: 3C595 100Mb/sec ethernet driver
Date: Thu, 30 May 1996 12:24:44 -0400
From: Mark Nelson <Mark_Nelson@Kodak.COM>
Organization: Eastman Kodak Company
Message-ID: <31ADCBCC.35A6@Kodak.COM>

Anyone got any info on the availability of a 100Mb/sec ethernet driver
for the 3-Com 3C595 etherlink controller? My target system is a Pentium
with multiple PCI buses, I'm using the pc486 BSP from WRS.

- --
 Mark J. Nelson Development Engineer
 Imaging Science Career Development Program
 (716)588-6226 Color Scanning Systems
 Mark_Nelson@Kodak.COM Eastman Kodak Company

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

Newsgroups: comp.realtime,comp.os.vxworks
Subject: B E W A R E 68060 & 68040 Math Performance is Terrible ! ! !
Date: 30 May 1996 17:24:57 GMT
From: ipss@roanoke.infi.net (ipss)
Organization: Industrial Process Support Services
Message-ID: <4okll9$uc1@nw101.infi.net>

While doing a project in VxWorks 5.2 with MVE177 (68060) we found out
that the floating point performance for the 68060 & 68040 is terrible
whenever numbers whose magnitude is less than FLT_MIN or greater than
FLT_MAX are encountered.

From correspondence with others this is apparently due to very poor
software exception handling in Motorola math libraries. This exception
handling was done in hardware on 68030 and earlier.

Motorola is aware of the problem and is utterly unconcerned that the
execution time for a simple fabs() function call can go from 1 microsec
to 53 microsec. They don't seem to get it!

All should be careful when selecting either the 68060 or 68040
architecture for time critical, math intensive applications. Your
only recourse is to rewrite Motorola math libraries or add under/overflow
checks all over your code.

Steve Fournier
ipss@roanoke.infi.net

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

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

From leonid@rst.co.il Fri May 31 05:12:24 1996
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Fri May 31 05:12:29 PDT 1996
Subject: Re: logMsg shared memory message Q??
This one is a challenging question I just could not resist:

> From: "JEAN FREGEAU" <fregeau@digsys1.bwi.wec.com>
> Date: Wed May 29 08:03:52 PDT 1996
> Subject: logMsg shared memory message Q??
> I would like to route output from all of the boards in my system to a
> single output source. Does anyone know of a way to use the logMsg
> feature with a shared memory message Q?

logTask listens on amessage queue, and logMsg sends its stuff to a message
queue, and shared msgQ's are treated the same way as local ones except
when initialized. So, what you need is to tell logLib to send and listen
with a global msgQ that you would create or bind with.

This would normally call for modifications of logLib.c source code,
if you have that.

That is however a bad approach, the shared msgQ's can't be sent to from
an interrupt level, and logMsg use frequently used exactly for that.
Also, logMsg passes arguments which are typically local pointers,
and another CPU will get plain garbage referring through them.

This means you will need to use logFdAdd() to add a file descriptor
to the logTask to send its messages to. This fd can be related
to a custom driver you must write, similar to the pipeDrv stuff,
which would optionally add some identification of the CPU number,
and send the FORMATTED data over to the master CPU.

It can be more easily done with sockets using if_sm network.
Just set up a TCP conenction to the master board, and use the socket
fd with logAdd() to direct all messages over there.

I hope this information will help.
-----------------------------------------------------------------------
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
http://knight.trendline.co.il/~leonid/	E-Mail:	leonid@rst.co.il

From jhillman@wrs.com Fri May 31 06:37:51 1996
From: Jon Hillman <jhillman@wrs.com>
Date: Fri May 31 06:37:53 PDT 1996
Subject: Re: logMsg shared memory message Q??
At 05:12 AM 5/31/96 PDT, you wrote:
>Submitted-by leonid@rst.co.il Fri May 31 05:12:24 1996
>Submitted-by: leonid@rst.co.il (Leonid Rosenboim)
>
>This one is a challenging question I just could not resist:
>
>> From: "JEAN FREGEAU" <fregeau@digsys1.bwi.wec.com>
>> Date: Wed May 29 08:03:52 PDT 1996
>> Subject: logMsg shared memory message Q??
>> I would like to route output from all of the boards in my system to a
>> single output source. Does anyone know of a way to use the logMsg
>> feature with a shared memory message Q?
>
>logTask listens on amessage queue, and logMsg sends its stuff to a message
>queue, and shared msgQ's are treated the same way as local ones except
>when initialized. So, what you need is to tell logLib to send and listen
>with a global msgQ that you would create or bind with.
>
>This would normally call for modifications of logLib.c source code,
>if you have that.
>
>That is however a bad approach, the shared msgQ's can't be sent to from
>an interrupt level, and logMsg use frequently used exactly for that.
>Also, logMsg passes arguments which are typically local pointers,
>and another CPU will get plain garbage referring through them.
>
>This means you will need to use logFdAdd() to add a file descriptor
>to the logTask to send its messages to. This fd can be related
>to a custom driver you must write, similar to the pipeDrv stuff,
>which would optionally add some identification of the CPU number,
>and send the FORMATTED data over to the master CPU.
>
>It can be more easily done with sockets using if_sm network.
>Just set up a TCP conenction to the master board, and use the socket
>fd with logAdd() to direct all messages over there.

I thought I'd add a suggestion here Jean. Establish a generic LOCAL message
queue
to which you write all appropriate logMsg-type stuff. Write a low priority
task which will run on each processor and will receive each message written
to that Q.
That task in turn will send the messages via shared message queue or sockets
to the processor at which you want the message directed, and it will do the
logMsg.

Hey, it works. :->

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

From tony@puma.phx.mcd.mot.com Fri May 31 10:48:31 1996
From: Tony Brefeld <tony@puma.phx.mcd.mot.com>
Date: Fri May 31 10:48:39 PDT 1996
Subject: Re: comp.os.vxworks newsdigest

-- Begin original message --

> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> -------------------------------------------------------
>
> Newsgroups: comp.os.vxworks
> Subject: Benchmarking VxWorks
> Date: 29 May 1996 04:47:21 GMT
> From: gms4vme@ix.netcom.com (Benjamin Sharfi)
> Organization: Netcom
> Message-ID: <4ogksp$siu@sjx-ixn3.ix.netcom.com>
>
> Hi,
>
> I am looking for a benchmark suite that will allow me to benchmark
> various single board computers with various CPU's using VxWorks.
>
> Can any one out there help !!
>
> Please E-Mail reponse to gms4vme@ix.netcom.com
>
>
> Thank You
>
> Don Palmer - Project Manager
> General Micro Systems, Inc
>

-- End original message --

I too would be interested in any benchmark suites available.

------
Thanks

Tony Brefeld				Motorola MCG-Tempe
WK: 1-602-438-3748			MS: DW220
FAX: 1-602-438-6154			2900 S. Diablo Way
INTERNET: tony@phx.mcd.mot.com		Tempe, Az. 85282

From kozubal@javelin.lanl.gov Fri May 31 14:15:15 1996
From: kozubal@javelin.lanl.gov (Andy Kozubal)
Date: Fri May 31 14:15:21 PDT 1996
Subject: RE: whats the proper use of sysBusToLocalAdrs()
>
> Whats the correct use of sysBusToLocalAdrs() ?
>
> Ive got several adresses in my header file that Id like to use this call on
> to get the correct adress dynamicaly.
>
> The way I used it in the past was to run it one time, note the base address
> for STD I/O space, then go back and edit my header file, to put in the
> correct addresses.
>
>
> Any suggestions. ?
>
>
> Thanks
> MikeMcQuade@connect.com
>

The mapping of bus address to RAM address is determined by the BSP, and
this mapping might change if you go to a different board or even change
BSP versions for the same board. Most of the code I've seen uses a call to
sysBusToLocalAdrs() for each device during initialiation and saves the
returned value.

Example:

LOCAL struct myDevReg {
	....
	....
} *pReg;

	/* Initialize ptr to register set */
	status = sysBusToLocalAdrs (VME_AM_STD_SUP_DATA, MY_DEV_REG, (char **)&pReg);
	......

	pReg->csr = 0x40;

|=======================================================================|
| Andy Kozubal (DX-7)			| Digital: akozubal@lanl.gov	|
| Mail Stop P947			|				|
| Los Alamos National Laboratory	| Analog: (505) 667-6508	|
| Los Alamos, New Mexico 87545		|				|
|=======================================================================|

From mea@mclean.sparta.com Fri May 31 15:25:06 1996
From: Mike Anderson <mea@mclean.sparta.com>
Date: Fri May 31 15:25:26 PDT 1996
Subject: RE: whats the proper use of sysBusToLocalAdrs()
At 02:15 PM 5/31/96 PDT, you wrote:
>Submitted-by kozubal@javelin.lanl.gov Fri May 31 14:15:15 1996
>Submitted-by: kozubal@javelin.lanl.gov (Andy Kozubal)
>
>>
>> Whats the correct use of sysBusToLocalAdrs() ?
>>
>

Here's a code snippett that I use for doing address translation:

#include "vxWorks.h"
#include "vme.h"

VOID busAddrXlate (char *busAddr, int AM)
{
 char *xlatedAddr;
 int status;

 status = sysBusToLocalAdrs(AM, busAddr, &xlatedAddr);

 if (status == OK)
 printf("This board sees address 0x%x at 0x%x\n", (UINT32) busAddr,
 (UINT32) xlatedAddr);
 else {
 printf("sysBusToLocalAdrs error!\n");
 printf("Unable to convert address 0x%x with address modifer 0x%x!\n\n",
 (UINT32) busAddr, (UINT32) AM);
 }

}

VOID localAddrXlate (char *busAddr, int AM)
{
 char *xlatedAddr;
 int status;

 status = sysLocalToBusAdrs(AM, busAddr, &xlatedAddr);

 if (status == OK)
 printf("This board sees address 0x%x at 0x%x\n",
 (UINT32) busAddr, (UINT32) xlatedAddr);
 else {
 printf("sysBusToLocalAdrs error!\n");
 printf("Unable to convert address 0x%x with address modifer 0x%x!\n\n",
 (UINT32) busAddr, (UINT32) AM);
 }

}

-> busAddrXlate(0xfe00, 0x2d)
This board sees address 0xfe00 at 0xff04fe00

To then use this techique in code:

#include "vxWorks.h"
#include "vme.h"

STATUS accessHw (char *busAddr, int AM, UINT32 value, char charWidth)
{
 char *xlatedAddr;
 int status;

 status = sysBusToLocalAdrs(AM, busAddr, &xlatedAddr);

 if (status == OK) {
 switch (charWidth) {
 case 1:
 *(xlatedAddr) := value & 0xff;
 break;
 case 2:
 *(xlatedAddr) := value & 0xffff;
 break;
 case 4:
 *(xlatedAddr) := value & 0xffffffff;
 break;
 default:
 *(xlatedAddr) := value & 0xff;
 break;
 }

 }
 else {
 printf("sysBusToLocalAdrs error!\n");
 printf("Unable to convert address 0x%x with address modifer 0x%x!\n\n",
 (UINT32) busAddr, (UINT32) AM);
 return(ERROR);
 }
 return(OK);
}

Then, to write the 8-bit value 0xb5 to short I/O at 0xfe00 you would call:

-> accessHw (0xfe00, 0x2d, 0xb5, 1)

HTH,

===============================================================================
 __ Real-Time System Development, Integration, Training and Services
 //\\
 // \\ Mike Anderson
 // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235
 // / \ \\ SPARTA, Inc. FAX : (703) 734-3323
// \ \\ 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."
===============================================================================