HDTenEightyP/NetNews huggingface dataset:
From: mef@ehsl.mitre.org (Marc E. Fiucznski)
Newsgroups: comp.os.vxworks
Subject: problem with read()/write() on device with databus.
Date: 17 Aug 92 20:19:10 GMT
Distribution: comp
Organization: Electronic Hardware Standards Laboratory, MITRE Corporation,
	Reston, VA.

Hi,

I've implemented a LAN based phone system using vxWorks and UniVoice
telephone boards.  The UniVoice card has dual-port ram (dpram), which
seems to only be accessible in one byte transfers.  

I'm using read/write to get/put data on the TCP/socket.  Ideally I would
like to do the following:

	write(fd, (char *)UniVoice.dpram.audiobuf, BUFFERSIZE);

and 
	read (fd, (char *)UniVoice.dpram.audiobuf, BUFFERSIZE);

That doesn't seem to work properly.  To get around it I do the
following:

	char audiobuffer[BUFFERSIZE];

	bcopyBytes((char *)UniVoice.dpram.audiobuf, 
		   (char *)audiobuffer, 
		   BUFFERSIZE);
	write(fd, (char *)audiobuffer, BUFFERSIZE);


	read (fd, (char *)audiobuffer, BUFFERSIZE);
	bcopyBytes((char *)audiobuffer, 
		   (char *)UniVoice.dpram.audiobuf, 
		   BUFFERSIZE);


Looking at the WRS manual for read

DESCRIPTION
     This routine reads bytes (less than or equal to  <maxbytes>)
     from the specified fd and places them in <buffer>.  It calls
     the device driver to do the work.

and write 

DESCRIPTION
     This routine writes <nbytes>  bytes  from  <buffer>  to  the
     specified file descriptor <fd>.  It calls the driver's write
     routine to do the work.

it seems that the transfer in/out of the given buffer should be a byte
at a time.  What does the "driver" for reading and writing on TCP
sockets actually do?  Anyone?

Marc
From: rypma@waterloo.hp.com (Ted Rypma)
Newsgroups: comp.os.vxworks
Subject: Re: problem with read()/write() on device with databus.
Date: 18 Aug 92 13:17:24 GMT
Article-I.D.: waterloo.Bt6Kx2.478
Distribution: comp
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: Tin 1.1scd1 PL5

Marc E. Fiucznski (mef@ehsl.mitre.org) wrote:
: 
: it seems that the transfer in/out of the given buffer should be a byte
: at a time.  What does the "driver" for reading and writing on TCP
: sockets actually do?  Anyone?
: 
: Marc

Whatever implementation you have of "bcopy()" is doing the job if you have
BSD networking code.  The implementation of that is probably platform
(library) specific.  Do a shell "l bcopy" and see what it does.

Ted Rypma
HP Panacom Division
From: royr@sdf.lonestar.org (Roy Rowan)
Newsgroups: comp.os.vxworks
Subject: Re: duplicate IP address!!
Date: 21 Aug 92 03:30:40 GMT
Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access

In article <9208181321.AA06627@efftoo.boeing.com> @ada3.ca.boeing.com:crispen@efftoo.boeing.com (crispen) writes:
>I don't know how you bring up the AP Labs driver, but on my port of the
>Interphase Sun driver you have to tell the network software your
>IP address for the FDDI board, e.g.
>
>start_fddi("80.0.0.2")
>
>start_fddi calls ifAddrSet (old VxWorks -- don't know what this call is
>called these days -- may be the same).
>
>Could it be that the error message is telling you the truth: that
>you're using the same IP address for both FDDI boards?
>
>Bob Crispen
>crispen@foxy.boeing.com

This is a general comment on the IP address of the ethernet driver.e
The IP layer calls the initializtion routine of the driver and will not
do so with out and IP address. The IP address may be changed with ifAddrSet
after initialization. This is needed if you use the ethernet hooks to 
RARP your IP address. If you use a dummy IP address to cause the 
driver to be initialized and you use the same dummy IP address for all 
cards on a local network segment you will see the duplcate IP address 
message. This is because the first thing that is sent out on the network
is a broadcast ARP or your IP address. 

Roy
royr@sdf.lonestar.org
Xref: sparky comp.os.vxworks:723 comp.realtime:958
From: phy@i88.isc.com (Paul Young)
Newsgroups: comp.os.vxworks,comp.realtime
Subject: TCP throughput numbers
Date: 13 Aug 92 23:41:13 GMT
Organization: INTERACTIVE Systems Corporation, Naperville, IL

I'm looking for TCP throughput rates for RTOS's running on
MVME147/MVME167 boards.
Specifically, I'm interested in send and receive rates for pSOS+ (pNA),
VRTX (TNX), and VxWorks, preferably done with ttcp.

If you have numbers for any of these systems on either board, or even
similar boards, I'd appreciate an email response. I'll post the results,
if there's enough interest.

TIA -

-- 
---------------------------------------------------------------------------
Paul H. Young
Interactive Systems - Software Technologies
phy@i88.isc.com

I do not speak for my employer unless spoken to :-)
---------------------------------------------------------------------------
From: Carl Lacy <lacy@draper.com>
Newsgroups: comp.os.vxworks
Subject: 4211 FDDI on MV167
Date: Mon, 17 Aug 92 14:00:16 EDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

   We are trying to get the following equipment integrated:

   2) MVME167 targets
   2) Interphase 4211 FDDI interfaces
   with/ AP Labs driver for FDDI

   Both MVME167 targets are connected to the same ethernet LAN, and both are
also connected to the same FDDI ring.  They are the only stations on the FDDI
ring.

   This is nearly working, but when a network connection is attempted we
get an ARP error from tNetTask:

0x7f518c (tNetTask): duplicate IP address!! sent from ethernet address: 00:00
:77:16:03:85

   We can eliminate the error by activating the NOARP flag on both FDDI
network interfaces:

   ifFlagChange "pg0", 0x80, 1			# 0x80 == NOARP


   ... but then the network hangs waiting on an ARP response.


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

   Has anyone messed with this FDDI driver before?

   Could we be getting two ARP responses from the second target, one
   back over ethernet, and one back over FDDI?  If so, does the presence
   of two ARP responses for one ARP query count as a duplicate IP address, 
   even if the two media addresses are identical?

   Can you insert manual ARP entries in VxWorks, like in UNIX?

   Any other ideas?

					All FDDI'd out,

					Carl Lacy,  MS 3F
					Charles Stark Draper Laboratory
					555 Technology Square
					Cambridge, Mass.   02139
					   (617) 258-3228
					   (617) 258-1880 (fax)
					   lacy@coyote.draper.com
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Newsgroups: comp.os.vxworks
Subject: duplicate IP address!!
Date: Tue, 18 Aug 92 08:21:33 CDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

I don't know how you bring up the AP Labs driver, but on my port of the
Interphase Sun driver you have to tell the network software your
IP address for the FDDI board, e.g.

start_fddi("80.0.0.2")

start_fddi calls ifAddrSet (old VxWorks -- don't know what this call is
called these days -- may be the same).

Could it be that the error message is telling you the truth: that
you're using the same IP address for both FDDI boards?

Bob Crispen
crispen@foxy.boeing.com
From: kjc@swlvx2.msd.ray.com (KEVIN COX)
Newsgroups: comp.os.vxworks
Subject: Interrupts
Date: 20 Aug 92 14:10:08 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


Hi et all

I have 2 signals which are being brought in via RS232C to a 
MVME712M transition module this module is connected to an
mv147S via a VME backplane.

Question:

How do I direct these signals to the mv147S so that I can
use VxWorks Interrupt handling?  

Solutions, suggestions, and ideas?

Kevin
Newsgroups: comp.os.vxworks
From: geoff@wrs.com (Geoff Espin)
Subject: Re: spawning overhead
Organization: Wind River Systems, Inc.
Date: Tue, 18 Aug 1992 23:36:58 GMT

fortin%helios.nosc.mil@nosc.mil (Richard Fortin) writes:
>Has anyone out there done any overhead studies concerning the hit taken for creating a new process?  We'd be really interested if it had been done with Ada tasks but plain vanilla C spawning would be useful too.

Off the top of my head, here's *toy* benchmark:

    -> sem=semBCreate(0,0)	/* FIFO, EMPTY */
    -> timexFunc 0, sp, semTake, sem
    -> timexFunc 1, semGive, sem
    -> timexN
    ...
    timex: 50 reps, time per rep = 31645 +/- 333 (1%) microsecs

That's on an MVME-147-S1 (68030).

On faster machines, e.g. HKV960 (i80960CA), this test may not work because
zillions of tasks get spawned before memory can be reclaimed.  On
the HKV960 with spTaskStackSize reduced:

    timex: 625 reps, time per rep = 1596 +/- 26 (1%) microsecs

Please, not a *real* benchmark!  Note that the sp() interface
isn't the same as taskSpawn().  It may be more efficient to
taskInit() the required tasks and later taskActivate().

Standard disclaimer!

Geoff
-- 
---
Geoff Espin		geoff@wrs.com	(510)748-4100
Wind			River		Systems
1010 Atlantic Avenue	Alameda		CA 94501
From: shi@frc2.frc.ri.cmu.edu (WenFan Shi)
Newsgroups: comp.os.vxworks
Subject: stand alone system
Date: 13 Aug 92 23:12:26 GMT
Article-I.D.: hay.SHI.92Aug13181226
Reply-To: shi@frc2.frc.ri.cmu.edu (Wenfan Shi)
Distribution: comp
Organization: Field Robotic Center, CMU


Hi, there. I am just wondering how big a stand alone system take,
which only include real time kernel + a litte application(say 20k). Is
that take more than 128k? Any info are appreciated. Thank you.

-wenfan
--
----------------------------------------------------------------------------
Wenfan Shi                     FIELD              Robotics Institute
shi@frc2.frc.ri.cmu.edu       ROBOTICS            Carnegie-Mellon University
(412) 268-6558                 CENTER             Pittsburgh, PA. 15213
----------------------------------------------------------------------------
Newsgroups: comp.os.vxworks
From: marcu@leland.Stanford.EDU (Marc Albert Ullman)
Subject: Re: MVME167 and RealTime Clock
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 14 Aug 92 18:28:13 GMT

In article <carl.713812388@wrs.com> carl@wrs.com (Carl Chesbrough) writes:
>On page 2-63 of the Motorola MV167 Programmer's Reference Guide the
>Prescaler Counter register is shown as R/W.  The description states:
>
>	"... The lower 8 bits of the prescaler counter increment to
>	$FF at the bus clock rate and then they are loaded from the
>	prescaler adjust register.  ..."
>
>Also, the reset value is shown to be 0x00.  Thus if you do not do an
>initial write to this register the first count will be from 0x00 to
>0xff, and not from 0xec to 0xff (for 20 MHz).  Once the counter would
>go from 0x00 to 0xff, then the prescaller adjust register is loaded.

While I admit this is nitpicking, it seems to me that said counter has
already started counting since the time the hardware was reset and so
no matter what you do, the first count will be off.  Once the prescaler
adjust register is initilialized, the next load will be correct.  Also
it's hard to tell which part of the documentation is in error--the text
that says it is a read-only register or the figure that shows it to be
R/W.  Since there is really no reason to make it R/W, I wager that the
text is probably correct (assuming Motorola minimized the logic design).
Anyone have definitive specs on this chip???

--Marc

Newsgroups: comp.os.vxworks
From: marcu@leland.Stanford.EDU (Marc Albert Ullman)
Subject: Re: MVME167 and RealTime Clock
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 14 Aug 92 02:46:26 GMT

In article <1992Aug14.013252.7600@chiton.ucsd.edu> cdl@chiton.ucsd.edu (Carl Lowenstein) writes:
>I just spent the better part of a day wondering why elapsed time as
>measured by counting clock ticks was not tracking well with time of day
>as determined by reading the real-time clock chip.
>
>Deep down in the inside of the PCC2 hardware is a prescale divider
>that divides the CPU clock rate (25 MHz) to make the timer clock.
>The MVME167 Programmers Manual points out that the byte that controls
>the prescaler should be set to (256 - BCLK), or 0xe7 for 25 MHz.
>I found both by peeking at the hardware register and by examining
>the code in vw/config/mv167/sysLib.c that the number in use was 0xe6.
>The one's complement of 25, rather than the two's complement.
>
>	*PCC2_PRESCALE = ~BCLK;		/* one's complement, wrong */
>
>	*PCC2_PRESCALE = -BCLK;		/* two's complement, right */
>
>What a difference between the little straight line and the little wiggly one!

While I agree with your general problem assessment--indeed the library
code is wrong--your fix is not quite correct.  It is the Prescaler Clock
Adjust Register that is being incorrectly initialized.  It is not clear
why the driver even bothers writing to the Prescaler Count Register since
the documentation says it is a read-only register (although the register
map says otherwise).  Thus I believe the correct fix is to change:

	    *PCC2_PRESCALE	    = ~BCLK;
	    *PCC2_PRESCALE_CLK_ADJ  = ~BCLK;
to:
	    *PCC2_PRESCALE_CLK_ADJ  = 256 - BCLK;

Yes, I realize that for a char register the 256 is unnecessary but it
makes it clearer that one read the documentation.

--Marc Ullman
  Stanford University
From: leonid@amil.co.il (Leonid Rosenboim)
Newsgroups: comp.os.vxworks
Subject: Token Ring Driver
Date: Wed, 12 Aug 92 15:23:58 IDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

I am searching for a token ring driver.

Specifically I am after a TMS380C-16 chip leveldriver
than can be integrated with a custom board. The driver should support
TCP/IP and raw packets.

Please reply to me directly, and I will summarize to the list.

Leonid
Newsgroups: comp.os.vxworks
From: cdl@chiton.ucsd.edu (Carl Lowenstein)
Subject: MVME167 and RealTime Clock
Organization: Marine Physical Lab of U.Calif. San Diego
Date: Fri, 14 Aug 1992 01:32:52 GMT

I just spent the better part of a day wondering why elapsed time as
measured by counting clock ticks was not tracking well with time of day
as determined by reading the real-time clock chip.

It was not the difference between 16666 microseconds  and 1/60 second.
That I determined by setting the timer rate to 100 Hz, which has a
period that is an exact number of microseconds.  Everything that was
timed by using clock ticks still took about 26/25 as long as it should.

Deep down in the inside of the PCC2 hardware is a prescale divider
that divides the CPU clock rate (25 MHz) to make the timer clock.
The MVME167 Programmers Manual points out that the byte that controls
the prescaler should be set to (256 - BCLK), or 0xe7 for 25 MHz.
I found both by peeking at the hardware register and by examining
the code in vw/config/mv167/sysLib.c that the number in use was 0xe6.
The one's complement of 25, rather than the two's complement.

	*PCC2_PRESCALE = ~BCLK;		/* one's complement, wrong */

	*PCC2_PRESCALE = -BCLK;		/* two's complement, right */

What a difference between the little straight line and the little wiggly one!


--
From: christ@ostar.pen.tek.com (Chris Tilt)
Newsgroups: comp.os.vxworks
Subject: re: Larger EPROM for VxWorks...
Date: 22 Aug 92 17:48:34 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


  
> We need to be able to write into EPROM our VxWorks system with our
> application.  This will require about 3/4 of a mega byte of EPROM space.
> The existing EPROM space on the Sparc 1E board is 256Kb.  Do you know
> where we can get a daughter board that contains the necessary EPROM
> space?  Any other solutions would also be appreciated.
> 
> 	Thanks
> 	Gary  glb@s1.gov
> -- 

Gary,

  Are you using boot ROM compression? It can give remarkable results,
like 40% or better. See bootLib(1) in the VX manuals.

Chris
Tektronix, Inc.
From: stan@rti.com (Stan Schneider)
Newsgroups: comp.os.vxworks
Subject: re: Ada bindings for StethoScope
Date: Tue, 18 Aug 92 11:36:55 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


Thanks to Rob Steele at JPL for providing StethoScope Ada bindings!

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================
Newsgroups: comp.os.vxworks
From: carl@wrs.com (Carl Chesbrough)
Subject: Re: MVME167 and RealTime Clock
Organization: Wind River Systems, Inc.
Date: Fri, 14 Aug 1992 17:13:08 GMT

marcu@leland.Stanford.EDU (Marc Albert Ullman) writes:

>In article <1992Aug14.013252.7600@chiton.ucsd.edu> cdl@chiton.ucsd.edu (Carl Lowenstein) writes:
>>Deep down in the inside of the PCC2 hardware is a prescale divider
>>that divides the CPU clock rate (25 MHz) to make the timer clock.
>>The MVME167 Programmers Manual points out that the byte that controls
>>the prescaler should be set to (256 - BCLK), or 0xe7 for 25 MHz.
>>I found both by peeking at the hardware register and by examining
>>the code in vw/config/mv167/sysLib.c that the number in use was 0xe6.
>>The one's complement of 25, rather than the two's complement.
>>
>>	*PCC2_PRESCALE = ~BCLK;		/* one's complement, wrong */
>>
>>	*PCC2_PRESCALE = -BCLK;		/* two's complement, right */
>>
>>What a difference between the little straight line and the little wiggly one!

>While I agree with your general problem assessment--indeed the library
>code is wrong--your fix is not quite correct.  It is the Prescaler Clock
>Adjust Register that is being incorrectly initialized.  It is not clear
>why the driver even bothers writing to the Prescaler Count Register since
>the documentation says it is a read-only register (although the register
>map says otherwise).  Thus I believe the correct fix is to change:

>	    *PCC2_PRESCALE	    = ~BCLK;
>	    *PCC2_PRESCALE_CLK_ADJ  = ~BCLK;
>to:
>	    *PCC2_PRESCALE_CLK_ADJ  = 256 - BCLK;

>Yes, I realize that for a char register the 256 is unnecessary but it
>makes it clearer that one read the documentation.

>--Marc Ullman
>  Stanford University

On page 2-63 of the Motorola MV167 Programmer's Reference Guide the
Prescaler Counter register is shown as R/W.  The description states:

	"... The lower 8 bits of the prescaler counter increment to
	$FF at the bus clock rate and then they are loaded from the
	prescaler adjust register.  ..."

Also, the reset value is shown to be 0x00.  Thus if you do not do an
initial write to this register the first count will be from 0x00 to
0xff, and not from 0xec to 0xff (for 20 MHz).  Once the counter would
go from 0x00 to 0xff, then the prescaller adjust register is loaded.

The correct fix is:

	*PCC2_PRESCALE          = ~BCLK;
	*PCC2_PRESCALE_CLK_ADJ  = ~BCLK;

to:

	*PCC2_PRESCALE          = 256 - BCLK;
	*PCC2_PRESCALE_CLK_ADJ  = 256 - BCLK;


Carl C. Chesbrough
Wind River Systems, Inc.
carl@wrs.com
From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: re:  spawning overhead
Date: Thu, 20 Aug 1992 08:14:54 -0400
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

>  Submitted-by fortin%helios.nosc.mil@nosc.mil  Tue Aug 18 16:08:43 1992
>  Submitted-by: fortin%helios.nosc.mil@nosc.mil (Richard Fortin)
>   
>  
>  Has anyone out there done any overhead studies concerning the hit taken
> for creating a new process?  We'd be really interested if it had been
> done with Ada tasks but plain vanilla C spawning would be useful too.

We have run the standard Ada PIWG benchmark tests on a version of VADSWorks
(2.0.3 beta) on a 25MHz 68030 processor.  The "c0000x" series of tests
measures task creation and termination times (combined).  What we found is
it takes about 3ms to create/terminate a task.  A non trivial part of this
is the time to zero out the run time stack since changing the task stack size
from 1000 to 100 bytes drops the execution time down to 2.5ms.  The time
is fairly consistent regardless of how the task is created (via a new allocator
or statically coded).  I can't find the results but I think we looked at how
these times compare with a normal (non Ada) task create/delete and they weren't
too much different.  My take is you don't want to be creating tasks on the
fly in a time critical application.  Hope that helps.   Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|
From: Carl Lacy <lacy@draper.com>
Newsgroups: comp.os.vxworks
Subject: duplicate IP address w/FDDI
Date: Tue, 18 Aug 92 13:01:42 EDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

< I don't know how you bring up the AP Labs driver, but on my port of the
< interphase Sun driver you have to tell the network software your
< IP address for the FDDI board, e.g.

< start_fddi("80.0.0.2")

   I'm using following commands in the two targets:

ifAddrSet       ("pg0", "140.102.134.10")

ifAddrSet       ("pg0", "140.102.134.20")

   ...and ifShow confirms the settings.

   For now I'm going to presume that the driver is confusing it's
IP with the ARP responder's IP, and look for coding errors.

					lacy@coyote.draper.com
From: stan@rti.com (Stan Schneider)
Newsgroups: comp.os.vxworks
Subject: re: spawning overhead
Date: Fri, 21 Aug 92 11:00:29 PDT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

>> 
>> >In general, it seems like pretty tight code.  In case you're curious, here's
>> >where the profiler says the CPU was being used (only routines that accounted
>>        ^^^^^^^^^^^^
>> >for at least 1% shown):
>> 
>> WHAT PROFILER????
>> 

Sorry about that.  The "profiler" is our ScopeProfile module for StethoScope.
Contact us (or your local WRS distributor) for details.

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================