From mea@sparta.com Tue Sep 1 05:19:43 1992 From: mea@sparta.com (Mike Anderson) Date: Tue Sep 1 05:19:51 PDT 1992 Subject: Re: general info needed > > Submitted-by ramos@mtunm.att.com Mon Aug 31 16:21:44 1992 > Submitted-by: ramos@mtunm.att.com > > We're looking into using either VxWorks or pSOS+ on a intel i960-based > embedded system dedicated to communications processing. I have experience > as an application builder on pSOS+ and have access to people who got pSOS+ > running on a custom hardware platform. Unfortunately, > I don't know anyone with VxWorks experience. My questions are these: > > 1) How hard is it to get VxWorks running on a custom platform using the > porting kit and how does it compare to pSOS+? The folks to ask about this are Hughes Network Systems in Gaithersburg. My company supplied them the Heurikon i960s and got their software folks up and running on i960s under VxWorks while their hardware folks got their custom boards fabbed. They then did the port to their new platform and its been operational for several months. They also did a complete trade study on PSOS+ vs. VxWorks before starting on this project and chose VxWorks hands down. I think that one of the key factors was Intel's support of VxWorks and the GNU environment. > 2) How robust is the kernel? (performance, bugs, etc.) We use the i960 almost exclusively for all of our synchronous protocol jobs. The on-chip DMA and the kernel support is excellent and the software speed picks up with each new rev. For example, we started in late 1990 with Heurikon i960s (33 MHz i960CAs) that did about 7K dhrystones. Without changeing the hardware at all we are now at 25K dhrystones. All of that through subsequent revs to VxWorks and the GNU compiler. As far as robustness and bugs are concerned, I frankly feel that the i960 version of VxWorks is more bug-free (largely owing to HNS and Intel hammering the kernel to death) than the 68K flavors of VxWorks. With Heurikon's new Rev 3 boards you can even avoid the big-endian/little-endian problems 'cause they have hardware to do the byte swaps. > 3) What are the limitations and quality of the communications software? We do up to 8 channel serial I/O via Xycom XVME-400 boards and via the 4 on-board ports in both async and sync (HDLC, SDLC, BiSync and Monosync) using the 8530 SCC chips on a single i960. We had to write all the protocols ourselves but the mechanisms to support framing and all of the bit/byte level interrupts is already provided in VxWorks. A couple of quick ioctl hacks to the tyCo drivers supplied in source with the boards and you've got sync comm. > 4) What are your experiences with the VxWorks source debugging environment? I don't have use the debuggers ;-). Truthfully, I find that the GNU environment for debugging is much more friendly than the XRAY+ and just as easy to use. I run the xVxGdb from my PC under PC-Xview and it works like a charm. The ability to interact with the shell directly is an important tool in itself. You can do things just like you were a program and then save it off to a file to be compiled. Much more friendly than dealing strictly through XRAY. ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From pdw@sunbar.mc.duke.edu Tue Sep 1 07:09:30 1992 From: pdw@sunbar.mc.duke.edu (Patrick D. Wolf) Date: Tue Sep 1 07:09:37 PDT 1992 Subject: NFS file server for vxWorks SCSI Disks Has anybody written a file server for a vxWorks SCSI Disk. I realize there are problems mixing real time and NFS Server functions but I would settle for read only. So, what I am looking for is a way to NFS mount for reading, disks that are located on my vxWorks target from my Sun host. Any suggestions or code would be welcome. Patrick Wolf pdw@sunbar.mc.duke.edu 919-660-5114 Duke University Medical Center From bobf@verdix.com Tue Sep 1 07:46:33 1992 From: Bob Foery Date: Tue Sep 1 07:46:40 PDT 1992 Subject: Re: NFS file server for vxWorks SCSI Disks >Has anybody written a file server for a vxWorks SCSI Disk. I realize there are problems mixing real time and NFS Server functions but I would settle for read only. So, what I am looking for is a way to NFS mount for reading, disks that are located on my vxWorks target from my Sun host. Any suggestions or code would be welcome. Patrick, This question has come up a few times in the past. Enclosed are extracts from previous posts. I recently grabbed SOS from Simtel20. If you would like a copy, I'd be happy to send it to you. Hope this helps, Bob Foery Verdix Corporation bobf@verdix.com ============================================================================= Submitted-by omni!hwajin@apple.com Fri Oct 25 15:26:03 1991 Submitted-by: hwajin@omni.com (Hwa-Jin Bae) >PC-based NFS SERVER? I've seen many NFS CLIENTS on PC's (not running unix) >but not many (or any) SERVERS. If a pc is running NFS SERVER code it is >significantly (in complexity) beyond being a BOOTP server. FYI, a GNU copylefted NFS server for MS-DOG exists. It's called SOS and written by none other than some people at LBL. ============================================================================= Submitted-by mea@sparta.com Mon Jan 20 09:07:52 1992 Submitted-by: mea@sparta.com (Mike Anderson) Greetings! There's a public domain NFS Server implementation called SOS (Steve's Own Server, I believe) that runs on PCs using PC-NFS. Its available from the Simtel20 anonymous FTP archives in the UNIX-C directories. It doesn't target VxWorks directly, but it is source that should come close. Good Luck and please send a working version to the user's group archives, ============================================================================= From hill@luke.atdiv.lanl.gov Tue Sep 1 09:19:43 1992 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Tue Sep 1 09:19:50 PDT 1992 Subject: Re: task switch hook > > > >Has anyone tested the task switch hook routines in Vx... > > I hooked a small routine that would write the Id of tasks being switched in > and out to a fixed location in global (VME) RAM. I wrote a similar code which reported the task id of each task modifying a set of contiguous bytes. Jeff From daemon@vxw.ee.lbl.gov Wed Sep 2 04:00:49 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Sep 2 04:00:56 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Sep 2 04:00:42 PDT 1992 Subject: C++ development Subject: how to implement a controller (aka need to periodically trigger task) Subject: MIPS port Subject: RARP for vxworks Subject: 68040 A32D16 gotcha ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: C++ development Date: Mon, 31 Aug 1992 22:14:18 GMT From: heidelgs@ntmtv.UUCP (Greg Heidel) Organization: Northern Telecom Inc, Mountain View, CA Message-ID: <1992Aug31.221418.15438@ntmtv> Sender: heidelgs@ntmtv (Greg Heidel) I have read on the net that several companies have ported the GNU C++ compiler to VxWorks. I am interested in what debugging capabilities are available when developing in this environment (both source-level and run-time). ...thanks for any info --------------------------- Newsgroups: comp.os.vxworks Subject: how to implement a controller (aka need to periodically trigger task) Date: Tue, 1 Sep 1992 16:45:10 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA/ARC Information Sciences Division Keywords: controller, 5.0.2 Message-ID: <1992Sep1.164510.27845@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov) Hi all, This may be a FAQ item (is there one for this group?), but I'd like to hear some opinions on a question: Using VxWorks 5.0.2, what is the best way to implement a digital controller? In other words, what is the best approach to get a task to trigger at a specific frequency (i.e., 10-100 Hz) such that system resources are minimally used? Do you setup an ISR off of the clock to signal (or semaphore) a pended task? Do you use watchdog timers repeatedly? Do you run a task at a high priority and let it poll a timer? Please send any/all responses to: terry@ptolemy.arc.nasa.gov I'll post a summary of the answers I receive. Thanks in advance! - -Terry - -- _______________________________________________________________________________ "You do not understand anything | Terry Fong until you understand it in more | NASA Ames, M/S 269-3, Moffett Field, CA than one way..." -- Marvin Minsky | (415) 604-6063, FTS-464-6063 --------------------------- Newsgroups: comp.os.vxworks Subject: MIPS port Date: Tue, 1 Sep 1992 23:17:15 GMT From: smd@s1.gov (Scott M. Denton) Organization: Lawrence Livermore Laboratory, Livermore CA Message-ID: <1992Sep1.231715.28356@s1.gov> Reply-To: smd@s1.gov (Scott M. Denton) Sender: usenet@s1.gov Where would I find a sample VxWorks port to the MIPS R3000? Thanks, Scott Denton --------------------------- Newsgroups: comp.os.vxworks Subject: RARP for vxworks Date: Tue, 01 Sep 92 23:57:05 GMT From: dbander@netcom.com (David B. Andersen) Organization: Netcom - Online Communication Services (408 241-9760 guest) Message-ID: <27jn4#j.dbander@netcom.com> Sender: David B. Andersen Many is the time I have wished that vxWorks supported RARP. When I ship a product it is a real pain to make sure that some piece of non-volatile memory has the proper inet address. It is also difficult to have to describe to a customer how to change a product's inet address. So why is it that Wind River does not have support for RARP? Has anybody whipped up their own version of RARP that they would be willing to share? Thanks in advance. - -- /------------------------------------------------------------------\ | David B. Andersen (dbander@netcom.com) | \------------------------------------------------------------------/ --------------------------- Newsgroups: comp.os.vxworks Subject: 68040 A32D16 gotcha Date: 2 Sep 92 02:17:30 GMT From: flash@austin.lockheed.com (James W. Melton) Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744 Message-ID: <1181@shrike.com> Recently, we had the joy of porting a small, custom device driver that was developed on an MV147 to a Tadpole TP41. There was a little gotcha that should be of interest to the net at large. The device is an ancient beast that operates in the A32D16 VME space. We have 1 register that contains a 32 bit value. Apparently, (according to a guy at Tadpole), prior versions of the 680x0 processor family would detect if a 32-bit write was destined for a D16 address and break the transfer into two 16-bit transfers to sequential word addresses. Not so with the 68040. If you ask for a 32-bit write to an address, it attempts to comply. If the target address is in D16 space, only the low-order 16 bits will be written to the target address. If all the technical details are incorrect, please free to correct me. The bottom line is, when in D16, only do 16-bit transfers. - ---- - -- Jim Melton, novice guru email: flash@austin.lockheed.com | "So far as we know, our voice mail: (512) 386-4486 | computer has never had fax: (512) 386-4223 | an undetected error" --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Sep 3 04:01:31 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Sep 3 04:01:39 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Sep 3 04:01:25 PDT 1992 Subject: Good book on VxWorks? Subject: Wanted: sample DMA routines Subject: vxWorks for the R3000 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Good book on VxWorks? Date: 2 Sep 92 16:32:17 GMT From: rajiv@bongo.cc.utexas.edu (Rajiv Arora) Organization: The University of Texas at Austin, Austin TX Message-ID: <78937@ut-emx.uucp> Reply-To: rajiv@bongo.cc.utexas.edu (Rajiv Arora) Sender: news@ut-emx.uucp Until a few hours ago, I had never heard about VxWorks. Can anyone recommend a good book that describes the philosophy of VxWorks--I presume it is some kind of real-time OS? Also, is VRTX a similar OS? I'm looking for references to get a general understanding of these OS's, not a detailed description. Any help would be appreciated. - -- ****************************************************************************** * Rajiv Arora Email: rajiv@bongo.cc.utexas.edu * * Phone: (512) 795-9015 * ****************************************************************************** --------------------------- Newsgroups: comp.os.vxworks Subject: Wanted: sample DMA routines Date: 2 Sep 1992 16:34:31 GMT From: jclesius@bbn.com (Jeff Clesius) Keywords: MVME167, DMA Message-ID: Does anyone know of any sample routines available for DMA transfer using the VMEchip2 on a Motorola MVME167? I am conducting an evaluation of the board and it would be nice to check out the performance of the on-board DMA. Thanks (in advance), Jeff Clesius (jclesius@bbn.com) BBN Systems and Technologies 50 Enterprise Center, Suite 200 Middletown, RI 02840-5202 (401) 849-2543 (voice) (401) 849-8611 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: vxWorks for the R3000 Date: 2 Sep 92 13:52:45 GMT From: junel@bilbo.heurikon.com (June Liesch) Organization: Heurikon Corporation, Madison, WI Message-ID: <1686@heurikon.heurikon.com> Reply-To: junel@heurikon.heurikon.com (June Liesch) Sender: news@heurikon.heurikon.com >Where would I find a sample VxWorks port to the MIPS R3000? > >Thanks, >Scott Denton You could get a demo (or purchase) vxWorks 5.0.5-beta2 for the R3000 from Heurikon Corporation (1-800-327-1251). June - -------------------------------------------------------------------------------- June Liesch | "I don't think much of our profession, but con- Software Customer Support | trasted with respectability, it's comparatively Heurikon Corporation | honest." - The Pirate King, from G&S's junel@heurikon.com | "The Pirates of Penzance" - -------------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From mea@sparta.com Thu Sep 3 13:15:37 1992 From: mea@sparta.com (Mike Anderson) Date: Thu Sep 3 13:15:57 PDT 1992 Subject: DDCMP Drivers Greetings! I remember back last June there was some interest in finding DDCMP drivers for VxWorks. Did anyone have any success? If so, I'd like to hear about it 'cause a friend of mine was curious about hooking up to VAXen using this protocol. Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From daemon@vxw.ee.lbl.gov Fri Sep 4 04:01:32 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Sep 4 04:01:39 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Sep 4 04:01:26 PDT 1992 Subject: Re: RARP for vxworks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: RARP for vxworks Date: 3 Sep 92 15:52:58 EST From: els@icf.hrb.com (Eric L. Schott) Organization: HRB Systems, Inc. Message-ID: <1992Sep3.155259.19519@icf.hrb.com> References: <27jn4#j.dbander@netcom.com> In article <27jn4#j.dbander@netcom.com>, dbander@netcom.com (David B. Andersen) writes: > Many is the time I have wished that vxWorks supported RARP. When I ship > a product it is a real pain to make sure that some piece of non-volatile > memory has the proper inet address. It is also difficult to have to > describe to a customer how to change a product's inet address. RARP would be nice. However, RARP does not address the issue of board swaps. That is, when a board fails, the bootparams file would need updated. It would be nice if the application could have control of the address broadcast. For example, I could use a value from the printer port to uniquely identify a board. - -- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" --------------------------- End of New-News digest ********************** From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Fri Sep 4 06:38:11 1992 From: Carl Lacy Date: Fri Sep 4 06:38:18 PDT 1992 Subject: Driver for Excaliber 1553 Would anyone have or know of a VxWorks driver for the Excaliber EXC-1553-C bus interface board? Thanks for info, 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 shaffer@stef.crd.ge.com Fri Sep 4 12:12:13 1992 From: shaffer@stef.crd.ge.com (Phil Shaffer) Date: Fri Sep 4 12:12:33 PDT 1992 Subject: MK48T08 TIme-of-Day Chip Interface Code Has anyone written interface code for the MK48T08 (or MK48T02 or MK48T12) Timekeeper RAM chip? This chip provides time-of-day (seconds through year) as well as non-volatile RAM, and is widely used on processor cards. In particular, I would be interested in C functions to: - set or display the time and date, e.g. as in the Unix date command; - read the time, e.g. as in the Unix time() or ftime() functions; - a version of calendarHostInit() to start the Ada calendar from the MK48Txx, rather than from a Unix host (for VADSworks). I would think this code would be of wide interest because of the frequency of use of this chip. I didn't seen anything that looked likely in the vxWorks archive. Thanks in advance for any help. Phillip L. Shaffer shaffer_phillip@ae.ge.com GE Aircraft Engines, MS A320 1 Neumann Way Cincinnati, OH 45215 From hebo@mbari.org Fri Sep 4 14:23:47 1992 From: Bob Herlien Date: Fri Sep 4 14:23:54 PDT 1992 Subject: Re: MK48T08 TIme-of-Day Chip Interface Code Phil, Get my NTP port from files ntpvx* on the archives at thor.atd.ucar.edu. When you unpack it, you'll find two subdirectories. ./ntp contains the NTP port itself, which you probably don't need. ./usrTime contains a set of Unix-compatible time functions, including gettimeofday(), settimeofday(), time(), stime(), adjtime(), asctime(), ctime(), gmtime(), and localtime(). To use the usrTime functions, you need to implement just two functions for your clock hardware: rtc_read() and rtc_write(). However, the library as shipped contains drivers for the MKT02 chip as implemented on the SBE VPU-30 CPU board, since that's the hardware we're using. It's all explained in the README file. -------------------------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@mbari.org "Limit congressmen to two terms. One in office. One in jail." From csibtfr!tims@apple.com Fri Sep 4 14:53:57 1992 From: csibtfr!tims@apple.com (Tim Seaman) Date: Fri Sep 4 14:54:07 PDT 1992 Subject: Re: MK48T08 TIme-of-Day Chip Interface Code ----- Begin Included Message ----- shaffer@stef.crd.ge.com writes... Has anyone written interface code for the MK48T08 (or MK48T02 or MK48T12) Timekeeper RAM chip? This chip provides time-of-day (seconds through year) as well as non-volatile RAM, and is widely used on processor cards. In particular, I would be interested in C functions to: - set or display the time and date, e.g. as in the Unix date command; - read the time, e.g. as in the Unix time() or ftime() functions; - a version of calendarHostInit() to start the Ada calendar from the MK48Txx, rather than from a Unix host (for VADSworks). I would think this code would be of wide interest because of the frequency of use of this chip. I didn't seen anything that looked likely in the vxWorks archive. Thanks in advance for any help. Phillip L. Shaffer shaffer_phillip@ae.ge.com GE Aircraft Engines, MS A320 1 Neumann Way Cincinnati, OH 45215 ----- End Included Message ----- We have some simple code here which we use to program and retrieve time/date information using the MK48T02 on a Tadpole TP32V CPU Board. /* %W% %G% -*- Mode: C -*- * * Copyright (c) Condor Systems Inc. * * mk48t02.c * * Description : * * Author : Tim Seaman * Created On : Fri Sep 4 14:30:13 1992 * Last Modified By: Tim Seaman * Last Modified On: Fri Sep 4 14:31:13 1992 * * VERSION SPR MODIFIER DATE AND TIME * */ #include "vxWorks.h" typedef struct { int hour; /* 0 - 23 */ int minute; /* 0 - 59 */ int second; /* 0 - 59 */ int hundredthSec; /* 0 - 99 */ } SYS_TIME; typedef struct { int year; /* 1990 - 2089 */ int month; /* 1 - 12 */ int day; /* 1 - 31 */ int dayOfWeek; /* 1 - 7, Sun = 1 */ } SYS_DATE; /* MK48T02 RTC stuff for Tadpole TP32V */ #define RTC_ADDR_0 ((char *) 0x004007f8) /* RTC Register 0 - Control & Cal */ #define RTC_ADDR_1 ((char *) 0x004007f9) /* RTC Register 1 - Seconds + ST */ #define RTC_ADDR_2 ((char *) 0x004007fa) /* RTC Register 2 - Minutes */ #define RTC_ADDR_3 ((char *) 0x004007fb) /* RTC Register 3 - Hour + KS */ #define RTC_ADDR_4 ((char *) 0x004007fc) /* RTC Register 4 - Day-of-Week + FT */ #define RTC_ADDR_5 ((char *) 0x004007fd) /* RTC Register 5 - Day-of-Month */ #define RTC_ADDR_6 ((char *) 0x004007fe) /* RTC Register 6 - Month */ #define RTC_ADDR_7 ((char *) 0x004007ff) /* RTC Register 7 - Year */ #define RTC_WR_BIT 0x80 /* write bit */ #define RTC_RD_BIT 0x40 /* read bit */ #define RTC_CONTROL_CAL_VALUE 0x00 /* current calibration value */ /* forward references */ static void writeTpRtc(); static void readTpRtc(); static void intToBcd(); static int bcdToInt(); /******************************************************************************* * * timeDateSet - set time and date * * Returns: OK if success, else ERROR * */ STATUS timeDateSet(pTime, pDate) SYS_TIME *pTime; /* ptr to time data */ SYS_DATE *pDate; /* ptr to date data*/ { unsigned char bcdData[7]; /* Convert SYS_TIME and SYS_DATE info to bcd for RTC */ /* hundredthSec ignored, since TP32V doesn't support it */ intToBcd(pTime->second, &bcdData[0], 2); bcdData[0] &= 0x7f; intToBcd(pTime->minute, &bcdData[1], 2); bcdData[1] &= 0x7f; intToBcd(pTime->hour, &bcdData[2], 2); bcdData[2] &= 0x3f; intToBcd(pDate->dayOfWeek, &bcdData[3], 2); bcdData[3] &= 0x07; intToBcd(pDate->day, &bcdData[4], 2); bcdData[4] &= 0x3f; intToBcd(pDate->month, &bcdData[5], 2); bcdData[5] &= 0x1f; intToBcd((pDate->year % 100), &bcdData[6], 2); bcdData[6] &= 0xff; writeTpRtc(bcdData); return (OK); } /******************************************************************************* * * timeDateGet - get time and date * * Returns: OK if success, else ERROR * */ STATUS timeDateGet(pTime, pDate) register SYS_TIME *pTime; /* ptr to where time is returned */ register SYS_DATE *pDate; /* ptr to where date is returned */ { unsigned char bcdData[7]; readTpRtc(bcdData); pTime->hundredthSec = 0; pTime->second = bcdToInt(bcdData[0] & 0x7f); pTime->minute = bcdToInt(bcdData[1] & 0x7f); pTime->hour = bcdToInt(bcdData[2] & 0x3f); pDate->dayOfWeek = bcdToInt(bcdData[3] & 0x07); pDate->day = bcdToInt(bcdData[4] & 0x3f); pDate->month = bcdToInt(bcdData[5] & 0x1f); pDate->year = bcdToInt(bcdData[6] & 0xff); if (pDate->year > 89) /* then 20th century */ pDate->year += 1900; else pDate->year += 2000; return (OK); } /******************************************************************************* * * writeTpRtc - Write time & date to TadPole TP32V RTC (real-time-clock) * * Returns: none * */ static void writeTpRtc(timeData) unsigned char timeData[]; { int oldlevel; /* current interrupt level mask */ /* Perform write sequence to MK48T02 Device */ /* Set WR (write) bit */ /* Set all time/date values */ /* Reset WR bit to set new time into RTC */ oldlevel = intLock(); /* disable interrupts */ *RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE | RTC_WR_BIT; *RTC_ADDR_1 = timeData[0]; /* seconds */ *RTC_ADDR_2 = timeData[1]; /* minutes */ *RTC_ADDR_3 = timeData[2]; /* hours */ *RTC_ADDR_4 = timeData[3]; /* day-of-week */ *RTC_ADDR_5 = timeData[4]; /* day */ *RTC_ADDR_6 = timeData[5]; /* month */ *RTC_ADDR_7 = timeData[6]; /* year */ *RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE; intUnlock(oldlevel); /* enable interrupts */ } /******************************************************************************* * * readTpRtc - Read time & date from TadPole TP32V RTC (real-time-clock) * * Returns: none * */ static void readTpRtc(timeData) unsigned char timeData[]; { int oldlevel; /* current interrupt level mask */ /* Perform read sequence from MK48T02 Device */ /* Set RD (read) bit to latch current time/date */ /* Read all time/date values */ /* Reset RD bit */ oldlevel = intLock(); /* disable interrupts */ *RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE | RTC_RD_BIT; timeData[0] = *RTC_ADDR_1; /* seconds */ timeData[1] = *RTC_ADDR_2; /* minutes */ timeData[2] = *RTC_ADDR_3; /* hours */ timeData[3] = *RTC_ADDR_4; /* day-of-week */ timeData[4] = *RTC_ADDR_5; /* day */ timeData[5] = *RTC_ADDR_6; /* month */ timeData[6] = *RTC_ADDR_7; /* year */ *RTC_ADDR_0 = RTC_CONTROL_CAL_VALUE; intUnlock(oldlevel); /* enable interrupts */ } /************************************************************* * * intToBcd - convert an integer to binary-coded decimal. * * This procedure will convert the integer parameter to * binary-coded decimal. * * RETURNS: * pointer to BCD value * */ static void intToBcd(intValue, bcdPtr, nbrDigits) long intValue; /* value to be encoded */ unsigned char bcdPtr[]; /* ptr to BCD results */ int nbrDigits; /* nbr of BCD digits */ { register ii; /* loop counter */ register jj; /* loop counter */ unsigned char bcdText[10]; if (nbrDigits == 6) sprintf (bcdText, "%06ld", intValue); else if (nbrDigits == 4) sprintf (bcdText, "%03ld", intValue); else if (nbrDigits == 2) sprintf (bcdText, "%02ld", intValue); /* encode a maximum of 3 BCD bytes */ jj = 0; for (ii = 0; ii < nbrDigits/2; ii++) { if (bcdText[jj] == 0) break; bcdPtr[ii] = (bcdText[jj] - 0x30); jj++; bcdPtr[ii] = bcdPtr[ii] << 4; if (bcdText[jj] == 0) break; bcdPtr[ii] |= (bcdText[jj] - 0x30); jj++; } } /* end intToBcd */ /************************************************************* * * bcdToInt - convert a 1-byte BCD value to an integer value. * * This procedure will convert a 1-byte binary-coded decimal * value to an integer value. * * RETURNS: * integer value * */ static int bcdToInt (bcdVal) unsigned char bcdVal; /* BCD value */ { int totalVal = 0; /* converted value */ /* convert the BCD digits to int */ totalVal = (((bcdVal & 0xf0)>>4)*10) + (bcdVal & 0x0f); return (totalVal); } /* bcdToInt */ From daemon@vxw.ee.lbl.gov Sat Sep 5 04:00:40 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Sep 5 04:00:48 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Sep 5 04:00:34 PDT 1992 Subject: Seeking vxWorks pricing structure Subject: summary--how to implement a controller ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Seeking vxWorks pricing structure Date: Fri, 4 Sep 1992 14:12:12 GMT From: chuck@westford.ccur.com (Chuck Palmer) Organization: Concurrent Computer Corp. Westford MA. Message-ID: <1992Sep4.141212.1962@westford.ccur.com> Sender: chuck@westford.ccur.com I have used vxWorks in the past as part of a client's project. I now find myself examining its use for another project which I am costing out. A while back, I saw the pricing as part of a Heurikon processor. I was reasonably confused by it all. Could someone explain how the licensing works. The product would be for resale, and would (hopefully) involve selling multiple "units". There would be multiple people developing for the end product on multiple workstations. The benefit of your experience is greatly appreciated. chuck palmer chuck@westford.ccur.com - -- | Charles Palmer (x2997) | | chuck@westford.ccur.com 508-392-2997 | | One Technology Way Fax: 508-392-2492 | | Westford, Ma. 01886 | --------------------------- Newsgroups: comp.os.vxworks Subject: summary--how to implement a controller Date: 5 Sep 92 01:08:38 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA/ARC Information Sciences Division Keywords: controller, periodic tasks Message-ID: <1992Sep5.010838.2171@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov) Hi all, Last week I asked for suggestions on how to implement a digital controller using VxWorks. The problem is essentially to determine what is the most efficient method for periodically executing a task (or a section of code). Depending on how fast you want to run (i.e., how short a period is involved) and how much latency (jitter) you can tolerate, there are three basic approaches: 1) LOW FREQUENCY If the controller runs at less than about 60 Hz, and latency on the order of a few milliseconds is not a problem, the easiest method is to run a high priority task that uses taskDelay() to wait between cycles. The caveats are that taskDelay() runs at system clock granularity and that the task needs to complete in less than a clock tick (or "time" will be lost). It is possible to run faster than 60 Hz if you change the system clock speed (though this will mess up other timing functions), or if you use an auxiliary clock (if your board has one). 2) MEDIUM - HIGH FREQUENCIES For controllers that run between 30 and 10,000 Hz, a better method than using taskDelay() is to setup a controller task that synchs on a binary semaphore. The semaphore is given at the required frequency by an ISR tied to either the system or auxiliary clock. This is the recommended method for task synchronization by Wind River Systems, and is covered in the VxWorks programmer's guide in the synchronization using semaphores section. Sample code is: ----------------------------------------------------------------------- SEM_ID SynchSemaphore; /* * This routine runs at interrupt level. The semaphore lets the loop in * Controller execute one time. */ int ControllerISR (void) { semGive(SynchSemaphore); return(0); } /* * Here is the controller. Spawn this task to start the controller */ STATUS Controller (void) { SynchSemaphore = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); /* Connect the timer to the aux. clock interrupt */ if (sysAuxClkConnect((FUNCPTR) ControllerISR, 0) == OK) { sysAuxClkRateSet (100); /* trigger interrupt at 100 Hz */ sysAuxClkEnable(); rebootHookAdd((FUNCPTR) sysAuxClkDisable); } else { printErr ("Controller: the aux clock is not available\n"); return ERROR; } while (TRUE) { /* wait for the synch */ semTake(SynchSemaphore, WAIT_FOREVER); /* do control function here ... */ } return OK; /* NOT REACHED */ } ----------------------------------------------------------------------- 3) HIGH FREQUENCY / LOW LATENCY If the controller needs to run *really* fast (greater than 10 KHz) or if low latency (jitter) is critical, then as much processing as possible should be done at the interrupt level (since this runs at the highest priority with the lowest latency). One method is to do everything in the ISR. This has problems, however, if other concurrent tasks can't handle interrupts that long. Another approach is to do things similiar to the previous method (i.e., synch a task off of a semaphore), but to try to do some/all of the calcuations in the ISR and to disable the system clock (since the kernel steals 100-300 usecs servicing the clock interrupt). Many thanks to Fred Roeber, Georg Feil, Stan Schneider, Andrew Mitchell, and Clark Briggs!!! - -Terry - -- _______________________________________________________________________________ "You do not understand anything | Terry Fong until you understand it in more | NASA Ames, M/S 269-3, Moffett Field, CA than one way..." -- Marvin Minsky | (415) 604-6063, FTS-464-6063 --------------------------- End of New-News digest ********************** From briggs@thalia.jpl.nasa.gov Sat Sep 5 08:12:32 1992 From: briggs@thalia.jpl.nasa.gov (Clark Briggs) Date: Sat Sep 5 08:12:39 PDT 1992 Subject: how to implement a controller Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as: there are three basic approaches: 1) LOW FREQUENCY If the controller runs at less than about 60 Hz, and latency on the order of a few milliseconds is not a problem, the easiest method is to run a high priority task that uses taskDelay() to wait between cycles. The caveats are that taskDelay() runs at system clock granularity and that the task needs to complete in less than a clock tick (or "time" will be lost). It is possible to run faster than 60 Hz if you change the system clock speed (though this will mess up other timing functions), or if you use an auxiliary clock (if your board has one). 2) MEDIUM - HIGH FREQUENCIES For controllers that run between 30 and 10,000 Hz, a better method than using taskDelay() is to setup a controller task that synchs on a binary semaphore. The semaphore is given at the required frequency by an ISR tied to either the system or auxiliary clock. This is the recommended method for task synchronization by Wind River Systems, and is covered in the VxWorks programmer's guide in the synchronization using semaphores section. Sample code is: code omitted for brevity... 3) HIGH FREQUENCY / LOW LATENCY If the controller needs to run *really* fast (greater than 10 KHz) or if low latency (jitter) is critical, then as much processing as possible should be done at the interrupt level (since this runs at the highest priority with the lowest latency). One method is to do everything in the ISR. This has problems, however, if other concurrent tasks can't handle interrupts that long. Another approach is to do things similiar to the previous method (i.e., synch a task off of a semaphore), but to try to do some/all of the calcuations in the ISR and to disable the system clock (since the kernel steals 100-300 usecs servicing the clock interrupt). end of copy of Terry's story... My Comments: method 1): changing sysclk from 60hz should not be a problem, in most respects. good code can get the sysclk freq and shouldnt code in 60hz. I have run sysclk all the way up until the system cant service the sysclk interrupts fast enough. This was my first attempt at running fast controllers. I got violent frowns from WRS when I turned sysclk up. It seems there is nothing inherently wrong with this its just that they never intended for us to do that to their system. The most significant problem is this causes the scheduler to run a lot more and sink a lot of cpu cycles. (In version 4.0 this was horribly expensive.) Method 2) is the way we run in our labs. It works well enough, but is limited by only one sysauxclk. The isr gets tricky if you are trying to control several tasks at different rates. We have used method 3, too. The biggest difficulty, beyond the obvious poor behavior of tieing up the cpu, it that the processing done in the ISR really has no context. this means no file I/O (no surprise, no one would really violate convention that much would they? you bet they would!)and no floating point! I suggested turning off sysclk, which seems like another terrible thing to do. It works but can have severe consequences. This makes sense to me only if the task is soooo important it is necessary to starve everything else, including the network deamons. But, we've been there too. A final method, is to simply never give up the CPU. We do this to get 14Khz with 50MHz 68030s. Make your task highest priority, never sleep, spin on a sync byte (set by the auxclk isr or a companion cpu), turn off sysclk, no file I/O.... This simply dedicates the entire cpu to your task. Thanks to Terry for the prompt posting and the work to get the information. Clark Briggs briggs@csi.jpl.nasa.gov From carl@umd5.umd.edu Mon Sep 7 20:38:24 1992 From: carl@umd5.umd.edu Date: Mon Sep 7 20:38:32 PDT 1992 Subject: Re: general info needed > Submitted-by mea@sparta.com Tue Sep 1 05:19:43 1992 > Submitted-by: mea@sparta.com (Mike Anderson) > | > Submitted-by ramos@mtunm.att.com Mon Aug 31 16:21:44 1992 | > Submitted-by: ramos@mtunm.att.com | > | > We're looking into using either VxWorks or pSOS+ on a intel i960-based | > embedded system dedicated to communications processing.... | > .....I don't know anyone with VxWorks experience. My questions are these: > > The folks to ask about this are Hughes Network Systems in Gaithersburg... > ...subquent revs to VxWorks and the GNU compiler. As far as robustness > and bugs are concerned, I frankly feel that the i960 version of VxWorks is > more bug-free (largely owing to HNS and Intel hammering the kernel to > death) than the 68K flavors of VxWorks....... Well that was quite a build up! Since I resemble these remarks I'll post an HNS opinion on the questions: |> 1) How hard is it to get VxWorks running on a custom platform using the |> porting kit and how does it compare to pSOS+? VxWorks is hosted on custom hardware via what is know as a board support package (BSP). We had several to develop in a short amount of time. Sadly back then there was _no_ documentation from either WR or Intel. So we had to develop our own base of BSP "how to" experience. Fortunately, the Intel factory in Oregon are terrific and we were able to get example device drivers and other critical questions answered. We didn't and still do not have source access to VxWorks. Without sources, and with the SERIOUS lack of WR documentation we had to invest quite a lot of NRE on the BSP task. I can't specifically comment on the porting kit. This only recently became available and all our BSP work is completed. I did volunteer to review the documentation from a customer perspective given our experience (READ: that we *had* to go through) with BSPs but WR was not interested. BTW, the WR porting kit is something you have to buy _extra_!! Something to the tune of $10K for all the trimmings but I don't have the price sheet handy. To me this seems very vulgar of WR, IMO. Not including such porting documentation AND example BSPs with the standard product is much the same as selling a "build a boat in a bottle" kit without instructions. Anyway, given a good set of instructions I'd estimate about 4 weeks to do a new BSP. Development of a TCP/IP network driver for some interface other than the standard ethernet and serial port will be extra. Overall, the job is not hard if your hardware comes up first time right ;-) It is essential that you look at an existing BSP, such as those available for commercial i960 single board computers. (However you do have to buy a licence for a specific commercial board to get a peek at its BSP.) Maby someone else can comment on how this compairs with pSOS? | > 2) How robust is the kernel? (performance, bugs, etc.) I agree with what Mike said on this. The Intel folks have done a great job on their GNU compiler. Each release has been better at performance largely due to the compiler technology. Hands down, the GNU compiler from Intel is the best tool available for the i960. We have found some bugs during our BSP work. Intel's bug fix turn around has been good for the i960 specific problems. The WR folks take care of the generic kernel problems. Most of the "kernel" problems we have seen has been our own code trashing memory ;-) | > 3) What are the limitations and quality of the communications software? The standard ethernet and serial drivers work well. Intel has updated their driver with most of the 596 errata workarounds. SLIP worked out of the box. TCP/IP works as one would expect, mostly. There is no routed and a few other things, but you can hardwire your routing tables and do gateway stuff. Compaired to the kernel we had more bugs/problems with the TCP/IP communications software. Again, the folks at Intel often had a quick answer. They also fixed all the bugs we raised, or worked with WR together to get them fixed. BTW, if you are planning on developing your own custom network interface, (e.g. TCP/IP over T1, Frame Relay, or whatever), I'd recommend getting full WR sources for the networking code. We didn't have these and simply would not have made it without Intel's help, the grit of our own developers, and looking at the standard BSD sources. Again, this costs extra bucks. Unfortunately with the dearth of WR documentation there is not much choice. It is almost like they expect folks to buy this and it somehow makes up for WR's own documentation inadequacy. | > 4) What are your experiences with the VxWorks source debugging environment? We have never been able to get xVxGDB to work on our hosts since they are not supported by WR. VxGDB however is basically OK. We have reported some bugs. Overall though I have to disagree with Mike. I think XRAY+ is a much more friendly _debugger_. The VxWorks shell does help bridge the gap though. Oh and by the way, it is my understanding that the Intel factory support folks are phasing out and a transition is happening to WR. :-( Thats all for now! --------------------- Carl Symborski Olney Multimedia Inc. From chip@csd.nad.northrop.com Tue Sep 8 09:58:27 1992 From: Peter Ross Date: Tue Sep 8 09:58:34 PDT 1992 Subject: Fortran compiler Hi I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030) that is compatible with vxworks. I'd appreciate any info on where I might obtain one. Thanks Chip From mea@sparta.com Tue Sep 8 11:09:01 1992 From: mea@sparta.com (Mike Anderson) Date: Tue Sep 8 11:09:08 PDT 1992 Subject: Re: Fortran compiler Greetings! > Submitted-by chip@csd.nad.northrop.com Tue Sep 8 09:58:27 1992 > Submitted-by: Peter Ross > > Hi > I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030) > that is compatible with vxworks. I'd appreciate any info on where I might > obtain one. Thanks > Chip > I've just gone through this effort recently and I'll give you the dump on what I found. First, WRS is working with Oasys for a customer to produce a FORTRAN compiler for VxWorks. This product should be in Beta-test by the end of this month with shipping soon after. To make it compatible with the GNU environment, you need to tell the compiler to output assembler and then assemble the file using the GNU assembler. Easily done in a script file. I've sent Oasys one of my FORTRAN benchmarks to convert to assembly, assembled it with as68k and loaded it into VxWorks (68030 and 68040) with no problems. Oasys claims to be working on having an integrated debugger facility for VxWorks using both their FORTRAN and their C++ ready to be shipped with the FORTRAN compiler when it is released. Another other option is to grab the FORTRAN-to-C translator from att.research.com and hack it to work with VxWorks. I have done this and I have a working translator that can target both 68030s and 68040s running VxWorks. I haven't tested it thoroughly, but I did take 5,000 lines of FORTRAN code and pass it through the translator and then through the GNU compiler and run it on VxWorks with zero modifications along the way :-). The code was very floating-point intensive with some formatted I/O. The way the translator handled things like named common blocks was most interesting. It doesn't clean up the code as far as nasties like GOTOs are concerned, but it sure goes a long way towards a reasonable savings in effort. I also understand there are commercial products that do this sort of thing that can do some of the restructuring. I'm afraid that I don't have any info about how good they are for VxWorks. Hope this helps, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From daemon@vxw.ee.lbl.gov Wed Sep 9 04:00:57 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Sep 9 04:01:06 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Sep 9 04:00:40 PDT 1992 Subject: Re: how to implement a controller Subject: ERROR: Remote debug server (RDB) not installed. Subject: Re: ERROR: Remote debug server (RDB) not installed. Subject: Re: ERROR: Remote debug server (RDB) not installed. Subject: another controller technique Subject: periodic task execution ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: how to implement a controller Date: 8 Sep 92 18:42:11 GMT From: sjk@strl.labs.tek.com (Steven John King) Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <4736@crl.LABS.TEK.COM> References: <9209051514.AA08750@thalia.jpl.nasa.gov> Followup-To: comp.os.vxworks Reply-To: sjk@strl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <9209051514.AA08750@thalia.jpl.nasa.gov>, briggs@thalia.jpl.nasa.gov (Clark Briggs) writes: |> Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as: [Requirements #1 and #2 deleted] |> 3) HIGH FREQUENCY / LOW LATENCY |> |> If the controller needs to run *really* fast (greater than 10 KHz) or |> if low latency (jitter) is critical, then as much processing as |> possible should be done at the interrupt level (since this runs at the |> highest priority with the lowest latency). One method is to do |> everything in the ISR. This has problems, however, if other concurrent tasks |> can't handle interrupts that long. Another approach is to do things |> similiar to the previous method (i.e., synch a task off of a |> semaphore), but to try to do some/all of the calcuations in the ISR |> and to disable the system clock (since the kernel steals 100-300 usecs |> servicing the clock interrupt). |> |> end of copy of Terry's story... [Requirements #1 and #2 deleted] |> We have used method 3, too. The biggest difficulty, beyond the obvious |> poor behavior of tieing up the cpu, it that the processing done in the |> ISR really has no context. this means no file I/O (no surprise, no one |> would really violate convention that much would they? you bet they would!)and no floating point! |> |> I suggested turning off sysclk, which seems like another |> terrible thing to do. It works but can have severe consequences. This |> makes sense to me only if the task is soooo important it is necessary |> to starve everything else, including the network deamons. But, we've |> been there too. |> |> A final method, is to simply never give up the CPU. We do this to get |> 14Khz with 50MHz 68030s. Make your task highest priority, never sleep, |> spin on a sync byte (set by the auxclk isr or a companion cpu), turn off |> sysclk, no file I/O.... This simply dedicates the entire cpu to your |> task. Another method, that helps lower both the interrupt latency and context switch time is to write your own interrupt routine and connect it directly to the vector, as follows: 1) Copy the wrapper routine generated by intConnect(). If you don't have source, simply do an "i" on the routine attached to the clock interrupt. You may have to search through the vectors (starting at intVecBaseGet()) on a running target to find the wrapper code. 2) Remove the calls to intEnt() and intExit(). Instead increment intCnt (a global) where intEnt() is called. Decrement intCnt where intExit() is called. NOTE: This works for most VxWorks routines that can be called from interrupt-level. NO PROMISE THAT IT WILL ALWAYS WORK. ;^) 3) If your interrupt handler doesn't receive a parameter, don't push one onto the stack. 4) If your "C" routine saves/restores D2, don't save/restore it in this routine. I believe GNU saves it. Other compilers must not. 5) Perform an RTE at the end of the handler. 6) Connect the handler to the interrupt vector using intVecSet(). Optionally save the old on using intVecGet() before the intVecSet(). NOTES:This only saves context switch overhead if the task that will start after the interrupt is dismissed is the highest priority task that is ready to execute. In case #3 this will likely be true. You save the lookup overhead in this case. In either case you save some of the overhead of the default wrapper routine. This method is only for the brave, crazy and/or skilled. Wind River probably won't accept support calls if you need help debugging this change. |> Thanks to Terry for the prompt posting and the work to get the information. Agreed! - -- Steven (sjk@strl.labs.tek.com) "Sometimes if you have a cappuccino and then try again it will work OK." (Dr. Brian Reid) "Sometimes one cappuccino isn't enough." (Marcus Ranum) "A double vanilla latte always works." (Me) --------------------------- Newsgroups: comp.os.vxworks Subject: ERROR: Remote debug server (RDB) not installed. Date: Tue, 8 Sep 1992 20:26:39 GMT From: vanandel@rsf.atd.ucar.edu (Joe VanAndel) Organization: NCAR/UCAR Keywords: RDB Message-ID: <1992Sep8.202639.10441@ncar.ucar.edu> Sender: news@ncar.ucar.edu (USENET Maintenance) I am trying to build a vxWorks kernel (5.02) with RDB support. I added the following line #define INCLUDE_RDB to config.h for the target I'm building, and re-compiled all the objects. But when I boot, I get the message: 0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed. So, what am I missing? - -- Joe VanAndel Internet:vanandel@ncar.ucar.edu NCAR - ATD/RSF P.O Box 3000 Fax: 303-497-2044 Boulder, CO 80307-3000 Voice: 303-497-2071 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ERROR: Remote debug server (RDB) not installed. Date: Tue, 8 Sep 1992 22:05:03 GMT From: markf@wrs.com (Mark Fox) Organization: Wind River Systems, Inc. Keywords: RDB Message-ID: References: <1992Sep8.202639.10441@ncar.ucar.edu> Sender: news@wrs.com (News Manager) vanandel@rsf.atd.ucar.edu (Joe VanAndel) writes: >I am trying to build a vxWorks kernel (5.02) with RDB support. I added the >following line >#define INCLUDE_RDB > >to config.h >for the target I'm building, and re-compiled all the objects. But when I boot, I get the message: > >0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed. For VxWorks 5.0.2, VxGDB support is provided on a separate distribution tape. This tape includes the host executables (debugger, GUI, and command driver), as well as the archive module (rdb.a) containing the code for the remote debug RPC server that runs as a task under VxWorks. The message above indicates that the VxGDB distribution has not been installed in the VxWorks tree. To install the VxGDB distribution, untar the VxGDB tape into a temporary directory, then run the script "installVxgdb" that you will find in the root of the resulting tree. This script will prompt you for the location of the VxWorks tree into which you wish to install VxGDB. For more details, see Part I, Section 2 of the "VxGDB User's Guide." Mark Fox Wind River Systems markf@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ERROR: Remote debug server (RDB) not installed. Date: 8 Sep 92 21:39:56 GMT From: sjk@strl.labs.tek.com (Steven John King) Organization: Software Technology Research Lab, Tektronix, Inc. Keywords: RDB Message-ID: <4737@crl.LABS.TEK.COM> References: <1992Sep8.202639.10441@ncar.ucar.edu> Followup-To: comp.os.vxworks Reply-To: sjk@strl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <1992Sep8.202639.10441@ncar.ucar.edu>, vanandel@rsf.atd.ucar.edu (Joe VanAndel) writes: |> I am trying to build a vxWorks kernel (5.02) with RDB support. I added the following line |> #define INCLUDE_RDB |> |> to config.h |> for the target I'm building, and re-compiled all the objects. But when I boot, I get the message: |> |> 0xffea8 (tRootTask): ERROR: Remote debug server (RDB) not installed. To which they should add the message: 0xf1234 (tRootTask): INFO: Copy the rdb.a from your vxGdb distribution into the appropriate library directory of your vxWorks distribution and rebuild. Steven (sjk@strl.labs.tek.com) "Sometimes if you have a cappuccino and then try again it will work OK." (Dr. Brian Reid) "Sometimes one cappuccino isn't enough." (Marcus Ranum) "A double vanilla latte always works." (Me) --------------------------- Newsgroups: comp.os.vxworks Subject: another controller technique Date: 8 Sep 92 22:43:22 GMT From: brad@huey.Jpl.Nasa.GOV (Brad Hines) Organization: JPL Spatial Interferometry Group Keywords: vxworks controller Message-ID: <1992Sep8.224322.18705@jato.jpl.nasa.gov> Reply-To: brad@huey.Jpl.Nasa.GOV Sender: nobody@jato.jpl.nasa.gov I initially mailed this to Terry concerning a technique we use for implementing controllers, and he suggested that it might be worth posting. =========== From brad Tue Sep 8 14:34:06 1992 To: doctor@kronos.arc.nasa.gov Subject: periodic task execution I just saw your summary of responses to how to periodically schedule tasks, and I thought you might be interested in my 2 cents about how we do it in our lab. We use a technique related to the semGive scheme. We use an external clock (from an IRIG time code reader card to get microsecond timing resolution) hooked to an ISR. Rather than calling semGive to resume the desired controller task, which then has to go through system tables to find out who's waiting on the semaphore and then make a taskResume call, we just call the taskResume ourselves (after all, you get the task id for the task when you first spawn it). Basically, the thinking is why go through the extra layer of abstraction of the semaphore when all you really want to do is resume a specific task (semaphores are more appropriate when there may be more than one task waiting on a given resource). At the end (or beginning) of each task iteration, there is a taskSuspend(0) call (so the taskResume/taskSuspend pair replaces the semGive/semTake pair), which is also faster than the semTake. Finally, the taskResume is naturally deterministic; the semGive probably isn't since the OS has to deal with the bookkeeping involved when multiple tasks wait for the same semaphore. (As an aside, my personal opinion is that WRS recommends semaphores for this kind of thing because WRS is proud of their semaphores, and heck, it just sounds more like real computer science.) If there are several periodic tasks to run, you have a couple of options. For example, I have written a deterministic high-speed periodic task scheduling library for use in a project here which supplies the ISR and routines to add and delete tasks from the queue of tasks to run periodically, as well as lots of ways of manipulating the task queues. In addition, it allows for one task which runs at interrupt level. We ended up using this in one part of the project, but in another part that needs very high speed, we instead chained the various controller tasks together, combining the do-it-in-the-ISR and the taskResume techniques. In our system, the ISR runs at 5-10 kHz depending on base CPU speed, and there are three standard VxWorks tasks that run at lower speeds (800 Hz, 200 Hz, and 2 Hz). The tasks are chained together - i.e, if the ISR runs at 8 kHz, it calls taskResume to resume the 800 Hz task on every 10th iteration. The 800 Hz task calls taskResume to resume the 200 Hz task on every 4th iteration, and the 200 Hz task calls taskResume to resume the 2 Hz task every 100th time through. It's not as elegant as some of the other techniques, but it is the fastest of all the techniques mentioned for this kind of system, and it's also the simplest and most direct. Hope this is helpful or at least interesting. - -Brad - -- Brad Hines Internet: brad@huey.jpl.nasa.gov Jet Propulsion Lab, Pasadena, California --------------------------- End of New-News digest ********************** From fjr@ssd.ray.com Wed Sep 9 06:31:27 1992 From: Roeber Date: Wed Sep 9 06:31:34 PDT 1992 Subject: Re: VxGDB Mark Fox from WRS writes: > For VxWorks 5.0.2, VxGDB support is provided on a separate distribution > tape. This tape includes the host executables (debugger, GUI, and command > driver), as well as the archive module (rdb.a) containing the code for the > remote debug RPC server that runs as a task under VxWorks. The message > above indicates that the VxGDB distribution has not been installed in the > VxWorks tree. > > To install the VxGDB distribution, untar the VxGDB tape into a temporary > directory, then run the script "installVxgdb" that you will find in the > root of the resulting tree. This script will prompt you for the location > of the VxWorks tree into which you wish to install VxGDB. For more details, > see Part I, Section 2 of the "VxGDB User's Guide." Is VxGDB an added cost option? The posting didn't make it clear one way or the other. If it costs extra, how much is it for a 680X0 system using a SPARC host? Also, is VxGDB a window based version of gdb or a standard text based version? Thanks for the info. _______________________________________________________ | 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 @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Wed Sep 9 10:46:31 1992 From: Carl Lacy Date: Wed Sep 9 10:46:39 PDT 1992 Subject: usrTime for mvme167 I am working at bringing up ttcp on VxWorks, using the port graciously provided by Marc E. Fiuczynski (mef@ehsl.mitre.org) This requires use of Bob Herlien's usrTime library, also graciously provided on the VxWorks archive. However, as available it's 'rtc_read' and 'rtc_write' functions are targetted for the MK48T02 Real-Time Clock Chip on VPU-30. (God, don't you love working with public domain software!?!) Before I convert these over to my current target, a MVME167, I thought I'd check if anyone might have already done so. Thanks, Carl Lacy, MS 3F Charles Stark Draper Laboratory 555 Technology Square Cambridge, Mass. 02139 (617) 258-3228, 258-1558 (617) 258-1880 (fax) lacy@coyote.draper.com From pdw@sunbar.mc.duke.edu Wed Sep 9 14:00:29 1992 From: pdw@sunbar.mc.duke.edu (Patrick D. Wolf) Date: Wed Sep 9 14:00:35 PDT 1992 Subject: DOS free space Does anybody have a nifty way for determining the free space left on a DOS file system disk? Thanks in advance,` Patrick Wolf pdw@sunbar.mc.duke.edu Duke University Medical Center 919-660-5114 From interf!zeus!brackett@uunet.uu.net Wed Sep 9 14:31:33 1992 From: interf!zeus!brackett@uunet.uu.net (Todd Brackett) Date: Wed Sep 9 14:32:03 PDT 1992 Subject: Your usergroup's meeting Hello everybody, I just want to remind you about the East Coast VxWorks Usergroup Meeting in Boston, MA next week. We have set up a very interesting meeting and I want to make sure that you all try to attend. We will have, for the first time, actual hands on demos of third party software and systems on hand. We will be hearing from Dave Wilner all about the new bells and whistles due in the next release of VxWorks. As we are meeting just after the BUSCON East show you can try to convince the boss it is a two for one deal (good luck!). See you all there....... 1992 VxWorks Users Group Friday, September 18 Sheraton Hotel and Towers Boston MA. 8:30 a.m. -- 5 p.m., with a break at noon for lunch. Regards, ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From nora@wrs.com Wed Sep 9 15:43:22 1992 From: nora@wrs.com Date: Wed Sep 9 15:43:31 PDT 1992 Subject: users group meeting VxWorks Users: Here is a follow-up to Todd Bracketts email: There is still time to sign up for the VxWorks Users Group Meeting, September 18, 1992 at the Sheraton Hotel and Towers in Boston, MA. If you register in advance you will receive $10 off the $50 fee. Email nora@wrs.com or call Nora Patterson at 1-800-545-WIND, to sign up by Friday Sept. 11. In addition to David Wilner, Tony Barbagallo, of WRS, and Mike Teimann of Cygnus Support, we will have presentations given by: Mike Anderson, SPARTA, Inc. SPARTA will be discussing our latest release of the ARTSE(Tm) process distribution, control and communications executive. ARTSE(Tm) presents to the applications programmer a platform-independent communications layer that supports Sun 3, Sun 4, Silicon Graphics and DECStation as well as VxWorks-based hosts. This communications layer is based on a SPARTA-developed reliable datagram facility that can sustain > 4MBPs transfer rates between two SPARCStation 1+-class machines over Ethernet. Process allocation and message routing is handled via an iconic point-and-shoot style user interface with messages being able to be delivered to multiple destinations without multiple application-level write calls ala multicast. SPARTA will be demonstrating ARTSE(Tm) using our robot demo that incorporates 2 VxWorks CPUs, a SPARCStation and our home-brew robot (Z80-based controlled from VxWorks). Stan Schneider, Real-Time Innovations, Inc. Stan Schneider from Real-Time Innovations, Inc. will give a short presentation on RTI's StethoScope product, including a live demonstration. StethoScope is a graphical monitoring and data collection utility designed expressly to work with VxWorks. It lets programmers examine and analyze real-time applications while they're running. StethoScope can monitor, graph, store, and analyze any variable or memory location in your system. It provides direct visibility of many things that no other tool can show. StethoScope includes the ScopeProfile dynamic execution profiler for VxWorks. ScopeProfile analyzes the execution flow of a real-time program on a procedure-by-procedure basis. It shows you exactly how your VxWorks program is utilizing the CPU. Mike Trest, VisiCom Laboratories VisiCom's primary business is a line of emulators and communications controllers for military applications. VisiCom is also a VxWorks reseller who provides services to builders of custom embedded hardware systems. Custom BSP's and device drivers for VME and NON-VME environments is VisiCom's forte. In addition to hardware and system design activities, VisiCom's staff of over 130 includes over 40 software professionals who work with VxWorks/VADSworks applications, BSPs, and drivers on a daily basis. Mike Trest will be presenting VisiCom's X-Windows product VX-Windows (tm). VX-Windows brings high speed X-Server capabilities to your real-time designs. VX-Windows incorporates the standard MIT X libraries and a complete X-Server which supports several hardware boards. VX-Motif is also available. Users group attendees will see demonstration clients written with windX, VX-Windows, VX-Motif all sharing a common display. A survey of actual fielded applications will be reviewed. Mike will be available to answer your one-on-one questions. Garth Gullekson, Bell-Northern Research Garth Gullekson, from Bell-Northern Research, will be giving an overview of the concepts of ObjecTime. ObjecTime is a new object-oriented CASE tool, targeted for real-time systems. It supports the ROOM methodology, which allows the creation of executable analysis or design models. It is based primarily on communicating hierarchically decomposed finite-state machines with well defined message-based protocols between them. Inheritance can be applied to architectures and high-level designs, not just C++ code segments. Future plans for the product include the ability to take detailed ObjecTime designs and run them unaltered on VxWorks-based product platforms Lloyd Bishop, Tadpole Technology Tadpole Technology will discuss its philosophy to custom board design and how that has enabled Tadpole's customers to meet technology and time-to-market pressures. We will also discuss how that approach has resulted in an extensive range of single board computers available to the general market. Soon to be announced product will also be discussed. Sven Spoerri, Atlantic Aerospace Electronics Corp. Ultranet is a high performance network consisting of hardware and software that will support data transfer rates between host computers of up to 1 Gigabit/second. Atlantic Aerospace Electronics Corp. has ported the software driver for Ultra's VME host adapter so that applications running under the VxWorks real-time operating system kernel can transfer data over an Ultra network using standard TCP/IP network protocols. Data transfer rates of up to 12 Mbytes/sec have been achieved between VME systems with 68030 single board computers running VxWorks communicating over an Ultra network. The talk will provide an overview of the hardware and software, performance results and suggest potential applications. See you there. From daemon@vxw.ee.lbl.gov Thu Sep 10 04:00:56 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Sep 10 04:01:03 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Sep 10 04:00:49 PDT 1992 Subject: Re: DOS free space Subject: Re: VxGDB Subject: Re: Fortran compiler ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: DOS free space Date: 9 Sep 92 23:21:19 GMT From: scoob@bnr.ca (Christian Marcotte) Organization: Bell-Northern Research, Ontario, Canada Message-ID: <1992Sep9.232119.3528@bnr.ca> References: <9209092057.AA15841@pat.mc.duke.edu> Sender: news@bnr.ca (usenet) In article <9209092057.AA15841@pat.mc.duke.edu> pdw@sunbar.mc.duke.edu (Patrick D. Wolf) writes: > >Does anybody have a nifty way for determining the free space left on a DOS >file system disk? Use ioctl on with: FIONFREE: Return amount of free space on volume. This will return the number of bytes free based on the number for free clusters in the FAT. - -- - --------------------------------------------------------------------------- Christian Marcotte Bell-Northern Research scoob@bnr.ca 3500 Carling Ave Telephone: (613) 763-2782 Nepean, Ont., Canada K1Y 4H7 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxGDB Date: Thu, 10 Sep 1992 04:19:03 GMT From: markf@wrs.com (Mark Fox) Organization: Wind River Systems, Inc. Message-ID: References: <199209091258.AA22296@pike.ssd.ray.com> Sender: news@wrs.com (News Manager) Fred Roeber asks: > Is VxGDB an added cost option? The posting didn't make it clear one way or > the other. If it costs extra, how much is it for a 680X0 system using > a SPARC host? At one point remote debugging support was offered as an unbundled option, but since just about everyone wanted it, WRS decided to bundle it with the OS. (This is true for customers purchasing VxWorks directly from WRS; I don't know what the situation is for VARs.) > Also, is VxGDB a window based version of gdb or a standard > text based version? Thanks for the info. VxGDB has an X-based GUI. Mark Fox Wind River Systems markf@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fortran compiler Date: 9 Sep 92 13:26:52 EST From: els@icf.hrb.com (Eric L. Schott) Organization: HRB Systems, Inc. Message-ID: <1992Sep9.132652.19540@icf.hrb.com> References: <9209081655.AA16599@csd.nad.northrop.com> In article <9209081655.AA16599@csd.nad.northrop.com>, chip@csd.nad.northrop.com (Peter Ross) writes: > > I need a fortran cross compiler for my Sun sparc to Mc680x0 (at least 68030) > that is compatible with vxworks. I'd appreciate any info on where I might > obtain one. Thanks An approach I have not tried, but which MAY be viable is to get the GNU Fortran (now in alpha) and build it as a cross compiler. - -- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sat Sep 12 04:00:26 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Sep 12 04:00:33 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Sep 12 04:00:19 PDT 1992 Subject: 167BUG Diagnostics and VxWorks Subject: Re: 167BUG Diagnostics and VxWorks Subject: Re: usrTime for mvme167 Subject: Re: 167BUG Diagnostics and VxWorks ------------------------------------------------------- Newsgroups: comp.sys.m68k,comp.os.vxworks,comp.realtime Subject: 167BUG Diagnostics and VxWorks Date: 11 Sep 92 13:53:04 GMT From: r2c@icf.hrb.com (Robert J. Cole) Organization: HRB Systems, Inc. Keywords: 167BUG, VxWorks, Diagnostics Message-ID: <1992Sep11.085304.19546@icf.hrb.com> Followup-To: comp.os.vxworks I am attempting to write c diagnostic routines for the Motorola 167 board to run in vxWorks. The Motorola 167BUG firmware exists on the board and on power-up, boots and passes control to vxWorks. 167BUG exists in the first two PROMS and VxWorks in the second set. VxWorks boot ok in this configuration. The intention is to run the user diagnostic routines on the 167 board which will make use of the resident Motorola diagnostic routines already in ROM, however this effort seems to be rife with difficulty. Has anyone done anything similar to what I am attempting and is able to offer any advice? Rob Cole. r2c@icf.hrb.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 167BUG Diagnostics and VxWorks Date: 11 Sep 92 16:56:40 GMT From: sjk@strl.labs.tek.com (Steven King) Organization: Software Technology Research Lab, Tektronix, Inc. Keywords: 167BUG, VxWorks, Diagnostics Message-ID: <4744@crl.LABS.TEK.COM> References: <1992Sep11.085304.19546@icf.hrb.com> Followup-To: comp.os.vxworks Reply-To: sjk@strl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <1992Sep11.085304.19546@icf.hrb.com>, r2c@icf.hrb.com (Robert J. Cole) writes: |> I am attempting to write c diagnostic routines for the Motorola |> 167 board to run in vxWorks. The Motorola 167BUG firmware exists on the |> board and on power-up, boots and passes control to vxWorks. 167BUG |> exists in the first two PROMS and VxWorks in the second set. VxWorks |> boot ok in this configuration. The intention is to run the user diagnostic |> routines on the 167 board which will make use of the resident Motorola |> diagnostic routines already in ROM, however this effort seems to be rife |> with difficulty. |> |> Has anyone done anything similar to what I am attempting and is |> able to offer any advice? I helped someone do similar work on a Force CPU-30. We obtained the CPU-30 diagnostics that Force uses in manufacturing. They were written in motorola assembler, so we converted them to use the as syntax. What we did was link romInit() at a different address. At the address that romInit() used to live, the diagnostic routines were placed. The diagnostics transferred control to romInit() upon completion. Another method is to allow VxWorks to initialize the hardware and call the diagnostic routine immediately after sysHwInit(). Of course, you won't be able to run write/read memory tests where VxWorks lives, and you won't be able to mess with any hardware registers that were previously initialized. It's much easier to develop code using this method, and you simply have to link it in with bootrom.hex (or whatever ROM version you build). Also, when you deploy a system and a "real" version of VxWorks lives in all the ROMs you can easily link in the diagnostics with this larger version of VxWorks. Steven (sjk@strl.labs.tek.com) "Sometimes if you have a cappuccino and then try again it will work OK." (Dr. Brian Reid) "Sometimes one cappuccino isn't enough." (Marcus Ranum) "A double vanilla latte always works." (Me) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: usrTime for mvme167 Date: 11 Sep 92 18:07:28 GMT From: mef@athos.rutgers.edu (Marc E. Fiuczynski) Organization: Rutgers Univ., New Brunswick, N.J. Message-ID: References: <9209091746.AA12150@coyote.draper.com> Hi, Hope you can get the clock stuff to work on your processor. Does your processor support time-of-day-clock sysclass? I got ttcp to work on our MATRIX 320 and 330 boards using these system calls. By the way, I'm not working at MITRE anymore. My summer internship with them ended aug. 28th. Until next summer my email address will be mef@cs.washington.edu. Marc - -- ______________________________________________________________________________ Marc E. Fiuczynski \\ Home: (703) 815-8920 Work: (703) 883-5632 mef@cs.rutgers.edu // UUCP: {backbone}!rutgers!cs.rutgers.edu!mef --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 167BUG Diagnostics and VxWorks Date: Fri, 11 Sep 1992 21:58:27 GMT From: gcall@systemname.uucp (Glen Call) Organization: Motorola Computer Group Marketing Keywords: 167BUG, VxWorks, Diagnostics Message-ID: <1992Sep11.215827.8578@phx.mcd.mot.com> References: <1992Sep11.085304.19546@icf.hrb.com> Sender: gcall@systemname (Glen Call) > I am attempting to write c diagnostic routines for the Motorola >167 board to run in vxWorks. The Motorola 167BUG firmware exists on the >board and on power-up, boots and passes control to vxWorks. 167BUG >exists in the first two PROMS and VxWorks in the second set. VxWorks >boot ok in this configuration. The intention is to run the user diagnostic >routines on the 167 board which will make use of the resident Motorola >diagnostic routines already in ROM, however this effort seems to be rife >with difficulty. > > Has anyone done anything similar to what I am attempting and is >able to offer any advice? > >Rob Cole. r2c@icf.hrb.com --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Tue Sep 15 04:01:09 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Sep 15 04:01:16 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Sep 15 04:00:54 PDT 1992 Subject: interphase 4211 driver?? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: interphase 4211 driver?? Date: Mon, 14 Sep 1992 19:55:04 GMT From: heyes@dadev.cebaf.gov (Graham Heyes) Organization: Continuous Electron Beam Accelerator Facility Message-ID: Sender: usenet@murdoch.acc.Virginia.EDU Does anyone have a driver for the Interphase 4211 FDDI interface. As far as I know WRS are supposed to have a driver for free but I haven't been able to get hold of it yet. I've got the hardware and want to get going as quickly as possible. If anyone has a copy of the driver which they can E-mail or give ftp coordinates for that would be a great help. Thanks, Graham Heyes --------------------------- End of New-News digest ********************** From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Tue Sep 15 09:50:35 1992 From: Carl Lacy Date: Tue Sep 15 09:50:44 PDT 1992 Subject: interphase 4211 driver?? Yes, AP Labs sells one. I've been working with it for several weeks and after some confusion, porting, and debugging it appears to be working. (At least on a MVME167 with 5.0.2). However, there is a pesky license issue, or I would be happy to email you a copy of it. The following is from their user's guide cover page; give them a call and see what you can work out. Good luck, 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 AP Labs User's Guide for the Interphase V/FDDI 4211 Peregrine VxWorks Device Driver Document #: VS-DRV-FDDI4211-1.0 September 20. 1991 Prepared By: Advanced Processing Laboratories, Inc. 6215 Ferris Square San Diego, California 92121 (619) 546-8626 From daemon@vxw.ee.lbl.gov Wed Sep 16 04:00:57 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Sep 16 04:01:04 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Sep 16 04:00:50 PDT 1992 Subject: Best way to implement a task at exactly XX Hertz Subject: Re: Best way to implement a task at exactly XX Hertz Subject: Force CPU-40 ethernet address ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Best way to implement a task at exactly XX Hertz Date: Tue, 15 Sep 1992 15:07:21 GMT From: muts@fys.ruu.nl (Peter Mutsaers) Organization: Rijks Universiteit Utrecht Message-ID: Sender: usenet@fys.ruu.nl (News Control) As the subject says, I wonder what the best way is to implement a task which must run at precise time intervals. In UNIX I'd use setitimer and handle SIGALRM, but this is not available. What I would htink of in VxWorks is more clumsy as I would have thought to be necessary, to my surprise, so maybe I am overlooking something. Do you have a better idea than the following?: Say I want to run at exactly 20 Hz: - - use a special timer task with top priority - - make it do: 1) taskDelay for 49 ms (a bit less than 50) 2) poll until tickGet is modulo 50 ms 3) give a semafore that the periodic job is pending on. This way I always immediately run when the 50ms mark is passed; but still I think it is clumsy that I cannot set a timer to expire in 1 process which then sleeps until it expires. Any improvements/ideas welcomed, - -- _________________________________________________________________________ Peter Mutsaers. |================================================ muts@fys.ruu.nl | Quod licet bovi, non licet Jovi --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Best way to implement a task at exactly XX Hertz Date: 15 Sep 92 20:02:06 GMT From: bard@cutter.ssd.loral.com (J H Woodyatt) Organization: Abiogenesis 4 Less Message-ID: <1992Sep15.200206.20042@wdl.loral.com> References: Reply-To: bard@cutter.ssd.loral.com Sender: news@wdl.loral.com In article , muts@fys.ruu.nl (Peter Mutsaers) writes: # As the subject says, I wonder what the best way is to implement a task # which must run at precise time intervals. [...] # Say I want to run at exactly 20 Hz: # - use a special timer task with top priority # - make it do: 1) taskDelay for 49 ms (a bit less than 50) # 2) poll until tickGet is modulo 50 ms # 3) give a semafore that the periodic job is pending on. # # This way I always immediately run when the 50ms mark is passed; but # still I think it is clumsy that I cannot set a timer to expire in 1 # process which then sleeps until it expires. # # Any improvements/ideas welcomed, Howzabout a watchdog timer? If you don't want your 50Hz code to run at interrupt level, have the watchdog call a routine that gives a semaphore that your task is pending on. - -- J H Woodyatt Space Systems/Loral "there's a lot going on that you miss. nothing soft about THESE machines. mean, timeless, mean, purposeful, crammed with meaning." -- Andrew Palfreyman --------------------------- Newsgroups: comp.os.vxworks Subject: Force CPU-40 ethernet address Date: 16 Sep 92 05:46:25 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep16.054625.26551@afterlife.ncsc.mil> I've just started using a Force CPU-40 with an Eagle-1 module (ethernet). Looking at usrConfig.c, it appears that the ethernet address for the board is not set. (Well, the first 4 bytes are set to Force's default, but the lower 2 bytes are always 0.) How do others deal with this? Would Force or WRS care to comment? - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- End of New-News digest ********************** From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Wed Sep 16 04:46:41 1992 From: Carl Lacy Date: Wed Sep 16 04:46:48 PDT 1992 Subject: 4211 Driver experience Well, I'm using the AP Labs drivers for the Interphase 4211 FDDI in VxWorks as a network interface with TCP/IP. I'm fairly inexperienced with network drivers, but it seems to operate fine after some initial debugging of the source. (The driver hadn't been run on a MVME167 previously.) I've run rlogin and ttcp so far, with no obvious problems. As to performance, I can't say much yet as the initial thruput with the default parameters of ttcp was only ~1 mbyte/sec, so I need to play some more. Here's the initial performance run, but PLEASE take it with a grain of salt. I'm still checking out ttcp options, and would welcome any input from more experienced users. Invocation of ttcp on two VxWorks targets: ---------------------------------------------------- Bri: vxttcp 0,0,5005,"140.102.134.20",0,1,1,0,0 | | TCP REC, SINK, VERBOSE, X, X Itz: vxttcp 0,0,5005,"140.102.134.10",1,1,1,0,0 | | TCP XMT, SINK, VERBOSE, X, X (Default of 8Kbyte blocks) Output of ttcp ---------------------------------------------------- ttcp-t: 16777216 bytes in 17.56 real seconds = 932.82 KB/sec +++ ttcp-t: 16777216 bytes in 17.56 CPU seconds = 932.82 KB/cpu sec ttcp-t: 2048 I/O calls, msec/call = 8.78, calls/sec = 116.60 ttcp-t: 0.0user 17.5sys 0:17real 100% ttcp-t: buffer address 0x700000 From @ada3.ca.boeing.com:crispen@efftoo.boeing.com Wed Sep 16 06:03:04 1992 From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> Date: Wed Sep 16 06:03:11 PDT 1992 Subject: Re: Best way to implement a task at exactly XX Hertz Now I'm starting to get worried. All the suggestions I've seen aren't anything like what I've always done. The following seems so obvious (so I'm starting to think that it's wrong!): (a) The guy who runs at interrupt level: int clock_heartbeat; int clock_task_id; STATUS clock_resume_status; void resume_clock() { clock_heartbeat++; clock_resume_status = taskResume(clock_task_id); } (b) The guy who executes at task level: foo() { #define ME 0 int my_heartbeat; clock_task_id = taskIdSelf(); for (;;) { my_heartbeat = clock_heartbeat; putc('.', stdout); if (my_heartbeat == clock_heartbeat) taskSuspend(ME); } } (c) Connecting the clock (could go into foo just before the loop): clock_heartbeat = 0; sysAuxClkDisable(); sysAuxClkRateSet(RATE); sysAuxClkConnect(resume_clock, 0); sysAuxClkEnable(); Caveat: there may be some grammatical errors in the above -- I copied it from some Ada that pragma Interfaces to the VxWorks C routines. There's a couple of nice features. For one thing, you get catch-up protection if you overrun (which you're likely to with putc unless you do it real slow). For another, you can substitute intConnect for sysAuxClkConnect and get the same result. So what have I been doing wrong? +-------------------------------+--------------------------------------+ | Bob Crispen | The owls are not what they seem | | crispen@foxy.boeing.com +--------------------------------------+ | (205) 461-3296 |Opinions expressed here are mine alone| +-------------------------------+--------------------------------------+ From mitchell@aaec1.aaec.com Wed Sep 16 06:55:52 1992 From: mitchell@aaec1.aaec.com Date: Wed Sep 16 06:55:58 PDT 1992 Subject: Re: Best way to implement a task at exactly XX Hertz ># Say I want to run at exactly 20 Hz: ># Peter Mutsaers. >Howzabout a watchdog timer? If you don't want your 50Hz code to run >at interrupt level, have the watchdog call a routine that gives a >semaphore that your task is pending on. >J H Woodyatt Many CPU boards have an aux timer, and supply sysAuxClkRateSet and sysAuxClkIntConnect or some such thing in the board support package. The advantage here is that the execution period does not have to be a multiple of the system clock as with the watch dog stuff. Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | From ntmtv!fleishma@ames.arc.nasa.gov Wed Sep 16 08:44:17 1992 From: ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman) Date: Wed Sep 16 08:44:25 PDT 1992 Subject: Re(2): Best way to implement a task at exactly XX Hertz Bob Crispen writes: > Submitted-by @ada3.ca.boeing.com:crispen@efftoo.boeing.com Wed Sep 16 06:03:04 1992 > > Now I'm starting to get worried. All the suggestions I've seen aren't > anything like what I've always done. The following seems so obvious > (so I'm starting to think that it's wrong!): > > (a) The guy who runs at interrupt level: > > int clock_heartbeat; > int clock_task_id; > STATUS clock_resume_status; > void resume_clock() > { > clock_heartbeat++; > clock_resume_status = taskResume(clock_task_id); > } > > (b) The guy who executes at task level: > > foo() > { > #define ME 0 > int my_heartbeat; > clock_task_id = taskIdSelf(); > for (;;) { > my_heartbeat = clock_heartbeat; > putc('.', stdout); > if (my_heartbeat == clock_heartbeat) > taskSuspend(ME); > } > } There is at least one area to worry in the taskSuspend-taskResume approach. It is based on assumption that your task is SUSPENDed only by you. I know at least 2 points where this assumption is wrong: - breakpoint - bus error In bus-error case (unless you have signal-based recovery) the result will be disasterous: ISR will taskResume and your task will hit bus-error again (and again and again ...). I would go with simple binary semaphore approach. ----------------------------------------------------------- Emanuel Fleishman voice: (415) 940-2346 Northern Telecom, fax: (415) 966-1067 685 E. Middlefield Road UUCP: ames!ntmtv!fleishma Mountain View, CA 94039 ARPA: fleishma@ntmtv.com or: ntmtv!fleishma@ames.arc.nasa.gov ------------------------------------------------------------ From daemon@vxw.ee.lbl.gov Thu Sep 17 04:00:29 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Sep 17 04:00:39 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Sep 17 04:00:23 PDT 1992 Subject: Re: Best way to implement a task at exactly XX Hertz Subject: Re: Force CPU-40 ethernet address Subject: re: Best way to implement a task at exactly XX Hertz Subject: Re: Best way to implement a task at exactly XX Hertz Subject: RFD: comp.sys.vmebus Subject: Re: re: Best way to implement a task at exactly XX Hertz ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Best way to implement a task at exactly XX Hertz Date: Wed, 16 Sep 1992 06:50:36 GMT From: muts@fys.ruu.nl (Peter Mutsaers) Organization: Rijks Universiteit Utrecht Message-ID: References: <1992Sep15.200206.20042@wdl.loral.com> Sender: usenet@fys.ruu.nl (News Control) >>On 15 Sep 92 20:02:06 GMT, bard@cutter.ssd.loral.com (J H Woodyatt) said: J> Howzabout a watchdog timer? If you don't want your 50Hz code to J> run at interrupt level, have the watchdog call a routine that J> gives a semaphore that your task is pending on. I thought about this, but the problem with this is that I lose time in between and there is no resynchronization with the system clock. Each time when the timer expires at takes a while before I can set the watchdog timer again, thus I lose a bit of time in between. This might disrupt our algorithm. - -- _________________________________________________________________________ Peter Mutsaers. |================================================ muts@fys.ruu.nl | Quod licet bovi, non licet Jovi --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Force CPU-40 ethernet address Date: Wed, 16 Sep 1992 16:27:07 GMT From: carl@wrs.com (Carl Chesbrough) Organization: Wind River Systems, Inc. Message-ID: References: <1992Sep16.054625.26551@afterlife.ncsc.mil> Sender: news@wrs.com (News Manager) smb@afterlife.ncsc.mil (Steve M. Burinsky) writes: >I've just started using a Force CPU-40 with an Eagle-1 module (ethernet). >Looking at usrConfig.c, it appears that the ethernet address for the board >is not set. (Well, the first 4 bytes are set to Force's default, but the >lower 2 bytes are always 0.) How do others deal with this? Would Force >or WRS care to comment? >-- >Steve M. Burinsky >smb@afterlife.ncsc.mil This is from the 5.0.2b sysLib.c file for the frc40: - ----------------------------------- /* * The Force CPU-40 has the licensed inet number of 00.80.42.c0.xx.xx where * the last four digits are the last four digits of the serial number. * Unfortunately there is no way to read the serial number from software so * we synthesize a unique ethernet address by placing the lowest two bytes of * the internet number in the lowest two bytes of the ethernet address. * This is done in usrRoot() in usrConfig(). */ unsigned char lnEnetAddr[6] = {0x00, 0x80, 0x42, 0xc0, 0x00, 0x00}; - ----------------------------------- Then from the usrConfig.c file: - ----------------------------------- #if defined(TARGET_FRC_37) || defined(TARGET_FRC_30) || defined(TARGET_FRC_40) /* Force 30 ,37 & 40 are supposed to use the board serial number as the * last two bytes of the ethernet address, but this is not currently * available at run-time (i.e. in non-volatile RAM), so we use the * bottom two bytes of the internet address instead. */ if (strcmp (devName, "ln") == 0) { IMPORT char lnEnetAddr []; /* ethernet addr for lance */ u_long inet = inet_addr (inetAdrs); lnEnetAddr [4] = (inet >> 8) & 0xff; lnEnetAddr [5] = inet & 0xff; } #endif /* TARGET_FRC_37 or _30 or _40 */ - --------------------------------- This will be changing in the next release (check with sales for timing). We are allocating 2 bytes in NVRAM which will hold the lower 2 bytes for the ethernet address. Hope this helps, Carl C. Chesbrough Wind River Systems 1010 Atlantic Avenue Alameda, California 94501 (510) 748-4100 --------------------------- Newsgroups: comp.os.vxworks Subject: re: Best way to implement a task at exactly XX Hertz Date: Wed, 16 Sep 1992 21:06:51 GMT From: bard@cutter.ssd.loral.com (J H Woodyatt) Organization: Abiogenesis 4 Less Message-ID: <1992Sep16.210651.8373@wdl.loral.com> References: <9209161313.AA06318@sparky.noname> Reply-To: bard@cutter.ssd.loral.com Sender: news@wdl.loral.com In article <9209161313.AA06318@sparky.noname>, mitchell@aaec1.aaec.com writes: # # ># Say I want to run at exactly 20 Hz: # ># Peter Mutsaers. # # >Howzabout a watchdog timer? If you don't want your 50Hz code to run # >at interrupt level, have the watchdog call a routine that gives a # >semaphore that your task is pending on. # >J H Woodyatt # # Many CPU boards have an aux timer, and supply sysAuxClkRateSet and # sysAuxClkIntConnect or some such thing in the board support package. The # advantage here is that the execution period does not have to be a multiple # of the system clock as with the watch dog stuff. Indeed. Mine don't. If they did, I could have multiple tasks pending on semaphore/watchdog combinations running at a multiple of the system clock rate, and I could use the auxillary clock to fake a set of watchdog timers to give semaphores to tasks running at multiples of the auxillary clock rate. So far, all the examples I've seen are multiples of my system clock rate: 100 Hz, and it failed to register on me that the question might have applied to how to get a task to run at exactly 75 Hz. On my boards, I'd have to kludge up something that approximated 75 Hz, and it wouldn't be as good as using the auxillary clock. I suppose I could probably borrow one of the baud rate generators on the Z8530 DUARTs or something, if I hadn't already run out of unused timer-like devices. Sorry to waste all that bandwidth. - -- J H Woodyatt Space Systems/Loral "there's a lot going on that you miss. nothing soft about THESE machines. mean, timeless, mean, purposeful, crammed with meaning." -- Andrew Palfreyman --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Best way to implement a task at exactly XX Hertz Date: 16 Sep 92 17:26:33 GMT From: muts@fys.ruu.nl (Peter Mutsaers) Organization: Rijks Universiteit Utrecht Message-ID: References: <9209161256.AA20057@efftoo.boeing.com> Sender: usenet@fys.ruu.nl (News Control) On Wed, 16 Sep 92 07:56:12 CDT, crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> said: c> So what have I been doing wrong? Nothing! I didnt' know about sysAuxClk**. So this is very helpful and indeed the way to go, thanks. I only thought about sysClk** but didn't want to change usrClock and import extra overhead in the 200Hz timing for a 20Hz talk. - -- _________________________________________________________________________ Peter Mutsaers. |================================================ muts@fys.ruu.nl | Quod licet bovi, non licet Jovi --------------------------- Newsgroups: news.announce.newgroups,news.groups,comp.realtime,comp.robotics,comp.lang.c,comp.sys.m68k,comp.os.os9,comp.os.misc,comp.lang.ada,comp.os.vxworks,comp.sys.sun.hardware Subject: RFD: comp.sys.vmebus Date: 17 Sep 92 00:09:09 GMT From: dstewart+@cs.cmu.edu (David B Stewart) Organization: The Robotics Institute, Carnegie Mellon University Message-ID: Followup-To: news.groups Sender: tale@uunet.uu.net (David C Lawrence) This is a Request For Discussion (RFD) regarding creation of an unmoderated newsgroup for discussing all aspects of computing related to the VMEbus and VMEbus-based systems: comp.sys.vmebus Discussions on hardware and software for VMEbus. The VMEbus is one of the more popular standards for developing open-architecture applications based on off-the-shelf hardware. Many hardware components, operating systems, and applications are based on this standard, yet there currently is no USENET group where discussions of this standard, and related items, are appropriate. The proposal is to create comp.sys.vmebus as a forum for discussing issues related to developing VMEbus-based systems. This includes discussion on the VMEbus Specification; VMEbus-based hardware, such as CPU boards and I/O devices; secondary buses such as VSB, VXI, and VMX; open-architecture applications based on the VMEbus; and hardware-dependent software, such as device drivers and bus communication protocols. The group is also available for questions and answers, so that developers of VMEbus-based hardware and software can get feedback or help with any problems they may encounter. Discussions should not be about hardware-independent software which use the VMEbus, such as the operating system or language being used, as there are other comp.* newsgroups dedicated to those functions. The discussion on this proposal will take place in news.groups. Please see the pertinent postings in news.answers and news.announce.newgroups for the rules that will be followed in creating a newsgroup (cf. ). - -- David B. Stewart - email: The Robotics Institute snail mail: - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213 Current Projects: - Chimera 3.0 Real-Time Operating System - Reconfigurable Sensor-Based Control Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: re: Best way to implement a task at exactly XX Hertz Date: 17 Sep 92 01:40:54 GMT From: dat@noao.edu (D'Anne Thompson) Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Message-ID: <1992Sep17.014054.15436@noao.edu> References: <1992Sep16.210651.8373@wdl.loral.com> Sender: news@noao.edu To all who need accurate timing and plan to use their sysClkxxx or sysClkAuxxx routines: BEWARE. Some cpu boards generate their system clock interrupts (and auxilliary clock interrupts) from baud rate generator type devices. These devices cannot synthesize any random interrupt rate. As an example, consider the Heurikon V2F cpu's that I use. The baud rate generator uses a 2.4576MHz crystal (thats a common frequency). The board support package code is setup only to use the divide by 200 prescale mode of the M68901 multi-function-peripheral chip. An attempt to set the system clock to run at 60 hertz results in the following. 2457600 / (200 * 60) = 204 with remainder of 9600 Now if you work backwards you find that the frequency of the clock is actually (2457600 / (200 * 204)) = 60.24 Hertz. Even rounding the earlier result to 205 generates a clock rate of 59.94 Hertz. In the case of the Heurikon V2F board I was forced to use a system clock rate of 64 Hertz in order to have an accurate clock. (2457600 / (200 * 64)) = 192 with no remainder. In summary, if a truly accurate interrupt rate is needed, you had better investigate your system clocks at the device level before just assuming that "sysClkRateSet(60)" is going to do what you think it will! I now have access to WWV satellite clocks (IRIG) and I use them to adjust the clock rate set in my MFP chip so that I get exactly 64 * 60 * 60 * 24 clock ticks per day. Now that the IRIG system is installed I could use it to maintain an even 60 hertz clock rate, but I'm not about to mess with something thats working). - -- D'Anne Thompson National Optical Astronomy Observatories P.O. Box 26732, Tucson, AZ 85726 (602) 325-9335 dat@noao.edu {...}!uunet!noao.edu!dat --------------------------- End of New-News digest ********************** From @ada3.ca.boeing.com:crispen@efftoo.boeing.com Thu Sep 17 05:51:55 1992 From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> Date: Thu Sep 17 05:52:02 PDT 1992 Subject: Re(2): Best way to implement a task at exactly XX Hertz ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman) sez: >There is at least one area to worry in the taskSuspend-taskResume approach. >It is based on assumption that your task is SUSPENDed only by you. > >I know at least 2 points where this assumption is wrong: > - breakpoint > - bus error > >In bus-error case (unless you have signal-based recovery) the result will >be disasterous: ISR will taskResume and your task will hit bus-error again >(and again and again ...). > >I would go with simple binary semaphore approach. You're right about the BERR -- the sound of a terminal shrieking is still in my recent memory. Can you expand a little on the semaphore thing, please? And how does it behave when there's an overrun? BTW, I think I know the *worst* way to execute a task at XX Hz -- call netJobAdd from interrupt to execute your routine at task level. Actually, depending on your requirements, that might not be all bad, depending on the priority you give netTask (I think you'd be better off making a duplicate of netTask). For one thing, you could easily manage multiple-clock overruns. Hmmmmm -- for some requirements that might be just the ticket. Thanks, Bob +-------------------------------+--------------------------------------+ | Bob Crispen | The owls are not what they seem | | crispen@foxy.boeing.com +--------------------------------------+ | (205) 461-3296 |Opinions expressed here are mine alone| +-------------------------------+--------------------------------------+ From @ada3.ca.boeing.com:crispen@efftoo.boeing.com Thu Sep 17 08:21:13 1992 From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> Date: Thu Sep 17 08:21:22 PDT 1992 Subject: Re: Best way to implement a task at exactly XX Hertz dat@noao.edu (D'Anne Thompson) sez: >To all who need accurate timing and plan to use their sysClkxxx or >sysClkAuxxx routines: BEWARE. > >Some cpu boards generate their system clock interrupts (and auxilliary >clock interrupts) from baud rate generator type devices. These devices >cannot synthesize any random interrupt rate. That's one of the lovable things about computers. I recall an experiment where we actually used that "feature". We wanted to measure how long it took a message to get from one bucket to another over FDDI, so we had the sender generate an interrupt when he sent it and the receiver generate another interrupt when he got it. The message was sent when the aux clock ticked, and for reasons we won't go into here, the receiver had to poll the FDDI board at some rate, controlled by its aux clock. We hooked up the IRQ lines to an o'scope. It turned out that one board was an MVME147 and the other was an MVME133XT. Because the clocks were a *little* bit different, we simply watched them approach the polling frequency over a period of several minutes and, voilla! the answer. It's been traditional in the flight simulation business to sell 50 Hz or 25 Hz max iteration rate simulators to European customers and 60 Hz or 30 Hz simulators to American customers for that very reason -- the clock on board could only generate certain frequencies. Actually, in a distributed simulator, we have been syncing the various buckets on a clock tick message over FDDI. We can stand a (not too bad) distribution about a known frequency better than we can stand a variety of frequencies on the system. Of course, other applications will have other requirements. +-------------------------------+--------------------------------------+ | Bob Crispen | The owls are not what they seem | | crispen@foxy.boeing.com +--------------------------------------+ | (205) 461-3296 |Opinions expressed here are mine alone| +-------------------------------+--------------------------------------+ From prb@aplexus.jhuapl.edu Thu Sep 17 08:54:58 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Thu Sep 17 08:55:05 PDT 1992 Subject: Fastest General Purpose CPU Board Hello World, We are currently running a system with many MVME-167 68040 Boards. But we need to reduce the size significantly in the future. Thus we would like to upgrade to faster boards. Perhaps an R4000, HP PA risc, Sparc, etc. Suggestions (especially with SpecMarks) are requested. Thanx, Paul R. Bade Johns Hopkins University / Applied Physics Lab (301)-953-5000 x8681 prb@aplexus.jhuapl.edu From lauren@wrs.com Thu Sep 17 15:41:20 1992 From: lauren@wrs.com Date: Thu Sep 17 15:41:27 PDT 1992 Subject: NFS Server ? Does anyone know of an NFS Server for VxWorks? From daemon@vxw.ee.lbl.gov Sun Sep 20 04:00:45 1992 From: daemon@vxw.ee.lbl.gov Date: Sun Sep 20 04:00:53 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Sep 20 04:00:39 PDT 1992 Subject: Spurious interrupts on MVME167 boards Subject: Re: how to implement a controller ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.sys.m68k Subject: Spurious interrupts on MVME167 boards Date: Fri, 18 Sep 1992 12:23:05 GMT From: nina@fynu.ucl.ac.be (Alain Ninane - FYNU) Organization: University of Louvain (LLN) - Nuclear Physics Dept. Keywords: spurious - interrupts - mvme167 - mvme147 - vxworks Message-ID: <1992Sep18.122305.17296@info.ucl.ac.be> Followup-To: comp.os.vxworks Sender: news@info.ucl.ac.be (News Administrator) Hardware : MVME147, MVME167 Software : VxWorks 5.0.2 Folks, I have an application which handle VMEbus interrupts requested by a data acquisition board (to be precise, a CAMAC branch). In the user level code, I enclose critical sections by the sysIntDisable() and sysIntEnable() routines. The code was working well, in any condition, on MVME147 boards. However, when I started to use the new MVME167 and under an heavy load of interrupts, I started to receive a lot of spurious interrupts. For those who are not aware of what a spurious interrupt is, let me tell you that such an exception occurs when the processor tries to read, without succes, the interrupt vector during an IACK cycle. It's like a bus error in the vector read operation. Fortunately, some times ago (July '92), there was a discussion about spurious interrupts on Motorola boards. A nice summary was posted by shaffer@stef.crd.ge.com. In short, the best way to protect critical sections is not to disable the VMEbus interrupt handler but instead to raise the processor priority. Indeed, that solves the problem. Now, the question ... In the summary, people says that the spurious interrupt appears when one turns off interrupts in the middle of an IACK cycle ... How is this possible ? As far as I know, the IACK cycle is started by the processor itself. It cannot therefore do something else (and in particular, it cannot disable the interrupt handler in the VMEChip2). Am I wrong ? Does the IACK cycle be started by the VMEChip2 itself ? I would like to hear any comment on this. Thanks, Alain - -- Dr. Alain H. Ninane | Tel : +32-10-47.32.73 - Fax: +32-10-45.21.83 University of Louvain | Internet: Ninane@fynu.ucl.ac.be Nuclear Physics Dept. | Ch. du Cyclotron, 2 B-1348 Louvain-la-Neuve | BELGIUM --------------------------- Newsgroups: comp.os.vxworks Subject: Re: how to implement a controller Date: 19 Sep 92 01:42:50 GMT From: lim@telerobotics.jpl.nasa.gov (David Lim) Organization: Jet Propulsion Laboratory Message-ID: References: <9209051514.AA08750@thalia.jpl.nasa.gov> Reply-To: lim@telerobotics.jpl.nasa.gov Sender: news@elroy.jpl.nasa.gov (Usenet) In general would you recommend rearranging the task priorities of VxWorks tasks such that yours is the highest. I.e. would you put your task at priority 1 and move all the vxWorks tasks to be higher than yours, with the exception of excTask? I suppose another alternative is to place your task at priority 0 along with excTask and logTask. But that seems dangerous if your task encounters an exception. --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Mon Sep 21 04:00:42 1992 From: daemon@vxw.ee.lbl.gov Date: Mon Sep 21 04:00:50 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Sep 21 04:00:35 PDT 1992 Subject: MailBoxInterupt Subject: MVME117 & ST3283N Help wanted Subject: Processor disappearing from backplane network Subject: Re: interphase 4211 driver?? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: MailBoxInterupt Date: 20 Sep 92 18:59:26 GMT From: skoft@itk.unit.no (Gunleiv Skofteland) Organization: Norwegian Institute of Technology / SINTEF, Trondheim, Norway Message-ID: Sender: news@ugle.unit.no (NetNews Administrator) I want to send messages (12 bytes) from one CPU (mv165) to another (mv147) at 30 Hz on VME backplane. I am concidering using mailboxinterupts, but I don't know how to use it. I would welcome any help from experienced users. The messages are positions estimated from video-images, and are inputs to a robot controller. Real time is very important. I have tried using sockets for the communication, but it fails at this speed due to latency. - -- Gunleiv Skofteland Institutt for Teknisk Kybernetikk : Tel +47 7 594386 NTH : Fax +47 7 594399 7034 Trondheim : Email skoft@itk.unit.no --------------------------- Newsgroups: comp.os.vxworks Subject: MVME117 & ST3283N Help wanted Date: 20 Sep 92 22:37:53 GMT From: eks@pe.dk (Eigil Krogh Soerensen) Organization: Purup Electronics A/S, Denmark Keywords: Seagate ST3283N MVME117 MVME117-bug VersaDOS Message-ID: <1818@pe.dk> I'm trying to get a Seagate ST3283N disk drive running with a MVME117 board and VersaDOS. Hope someone can help with the following two problems. 1. When connected to the MVME117 board the terminator power must come from the SCSI bus and the termination on the drive must be 220/330 ohms passive. I have two descriptions of how to configure the drive that way a) "Seagate ST3283 Family: Installation Guide, Rev. A" b) "Seagate ST3283 SCSI Interface Drive Product Manual" When I follow these descriptions the drive acts as if it has no SCSI terminators at all. How is the right way to jumper/configure the drive. 2. If I set the SCSI-bus termination jumpers slight different from the descriptions the drive *acts* as if the SCSI-bus termination works. BUT now the MVME117 initiator hangs when the drive is accessed. This counts both for the MVME117- bug and the opr.-sys. VersaDOS. Why is that ? MVME117-bug version is 1.x MVME117 scsi firmware version is 1.1 VersaDOS version is 4.51. The MVME117 initiator system is not able to handle dis-/reconnect. That shouldn't be any problem as the drive is not allowed to dis-/reconnect unles it is allowed to by the initiator. Is there a problem here with the ST3282N drive ? The MVME117 system runs fine with a Seagate ST4350N WREN IV 94171-350 drive ! Thank you in advance. Eigil Krogh Sorensen (eks@pe.dk) Purup Prepress. --------------------------- Newsgroups: comp.os.vxworks Subject: Processor disappearing from backplane network Date: 21 Sep 92 03:11:47 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep21.031147.27873@afterlife.ncsc.mil> Under 5.0.2: I have two Force CPU-40s, one of which acts as a gateway between the ethernet and the backplane network. After proc 1 boots via the gateway, it recv()'s a TCP stream from proc 0. Every 2 seconds proc 0 send()'s ~100kB to proc 1 in ~64B chunks. During normal operation, bpShow() on each processor shows that there are 2 processors on the backplane net, and the number of input packets from proc 1 tracks the number of output packets from proc 0. After about 30 hours of operation, the send() on proc 0 fails with an errno of EPIPE (actually S_iosLib_EPIPE, I think). From what I can tell, this occurs because proc 0 believes there is no reader on the socket being written. A bpShow() on each processor at this point shows some strange things. First, bpShow() on either processor now only reports that proc 0 is on the backplane network. Secondly, while proc 1 shows ~5 million input packets and ~3 million output packets (which I assume are due to TCP acknowledgements), proc 0 shows 50 input packets and 51 output packets. Once in this state, no further backplane network communication can be initiated or completed. Attempting to connect from one processor to the other results in an ETIMEDOUT. Has anyone seen any similar behavior? Any suggestions as to where to look or what to look for next? Thanks. - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: interphase 4211 driver?? Date: 21 Sep 92 03:37:42 GMT From: flash@austin.lockheed.com (James W. Melton) Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744 Message-ID: <1204@shrike.com> References: <9209151650.AA13188@coyote.draper.com> In article <9209151650.AA13188@coyote.draper.com> lacy@draper.com (Carl Lacy) writes: > > Yes, AP Labs sells one. I've been working with it for several weeks >and after some confusion, porting, and debugging it appears to be working. >(At least on a MVME167 with 5.0.2). > Actually, the driver should be available from your friendly Interphase sales person. The driver belongs to Interphase; they paid AP Labs to write it. However, don't look for much support. AP Labs won't talk to you unless you bought it from them and Interphase is just now spinning up their vxWorks expertise. Caution: The driver AS SHIPPED assumes the following nasty things: 1) That VME addressing is the same as local addressing. There is even a comment where sysLocalToBusAdrs *should* be that they chose a macro because it is faster. Didn't work on my board (Tadpole TP-41) 2) That the DMA address space is in A24 (STD) space. Sorry, but in my architecture everything is in A32 (EXT) space. Changing THAT required the technical expertise of a nice guy at Interphase. That said, the board seems to work great. After following the sales channels at Interphase, I *did* get the support I needed to get the driver working, including finding out that I had it cabled wrong! (makes a difference) The folks at Interphase went the extra mile. The folks at AP Labs wouldn't even get out of their chair. Just my experience. - -- Jim Melton, novice guru email: flash@austin.lockheed.com | "So far as we know, our voice mail: (512) 386-4486 | computer has never had fax: (512) 386-4223 | an undetected error" --------------------------- End of New-News digest ********************** From interf!zeus!brackett@uunet.uu.net Mon Sep 21 06:47:32 1992 From: interf!zeus!brackett@uunet.uu.net (Todd Brackett) Date: Mon Sep 21 06:47:39 PDT 1992 Subject: job in DC Interferometrics Inc. is looking for an experienced VxWorks programmer to work on a sattelite ground station system and other projects. Candidates should have 2+ years experience with VxWorks on 68K targets. Please respond directly to the address below if interested. Thanks, ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Mon Sep 21 07:55:40 1992 From: Carl Lacy Date: Mon Sep 21 07:55:48 PDT 1992 Subject: Re: interphase 4211 driver?? Yes, those were the problems with the AP Labs driver that I saw also. I also got no help from AP Labs (as Interphase was the licensee), and spent 4 weeks debugging the driver for my target. Also if you're using the driver, consider adding return (0); to the end of the initialization section. In my mvme167 target that function did not explicitly set its return, so the caller, set_if_addr, saw a failure code, and then did not set the IP address in the driver's ifnet data structure. This left the driver with an IP address of 0.0.0.0, with resulting ARP duplicate address problems. Bottom line: If you're using the AP Labs driver, just buy a support contract from them. From psm%helios.nosc.mil@nosc.mil Mon Sep 21 11:30:44 1992 From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh) Date: Mon Sep 21 11:30:52 PDT 1992 Subject: Evaluating VME CPUs We are about to launch an evaluation of the following VME boards for suitability to our application: Performance Technology PT-VME141 Force CPU40 Synergy SV430 Besides the general 'performance' (criteria for which we have yet to define) of the boards, we are particularly interested in Ada support, and in how well they are able to handle at least 4 high-speed (>256kbits) synchronous serial I/O channels. I'd appreciate hearing from anyone else who has looked into these boards. I'd also appreciate hearing about what other people have used for evaluation criteria of such products in the past. Scot McIntosh From daemon@vxw.ee.lbl.gov Tue Sep 22 04:00:56 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Sep 22 04:01:04 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Sep 22 04:00:42 PDT 1992 Subject: Re: Processor disappearing from backplane network Subject: VxGDB Single Step Problem Subject: Re: VxGDB Single Step Problem Subject: Re: Processor disappearing from backplane network ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Processor disappearing from backplane network Date: Mon, 21 Sep 1992 15:54:27 GMT From: geger@phantom.den.mmc.com (George Eger (303) 971-6974) Organization: Fault Tolerant Avionics, Martin Marietta Astronautics Group Keywords: BP Interface Message-ID: <1992Sep21.155427.18141@den.mmc.com> References: <1992Sep21.031147.27873@afterlife.ncsc.mil> Sender: news@den.mmc.com (News) In article <1992Sep21.031147.27873@afterlife.ncsc.mil>, smb@afterlife.ncsc.mil (Steve M. Burinsky) writes: |> Under 5.0.2: |> I have two Force CPU-40s, one of which acts as a gateway between the |> ethernet and the backplane network. After proc 1 boots via the |> gateway, it recv()'s a TCP stream from proc 0. Every 2 seconds proc 0 |> send()'s ~100kB to proc 1 in ~64B chunks. During normal operation, |> bpShow() on each processor shows that there are 2 processors on the |> backplane net, and the number of input packets from proc 1 tracks the |> number of output packets from proc 0. |> |> After about 30 hours of operation, the send() on proc 0 fails with |> an errno of EPIPE (actually S_iosLib_EPIPE, I think). From what I can |> tell, this occurs because proc 0 believes there is no reader on the |> socket being written. |> |> A bpShow() on each processor at this point shows some strange things. |> First, bpShow() on either processor now only reports that proc 0 is on |> the backplane network. Secondly, while proc 1 shows ~5 million input |> packets and ~3 million output packets (which I assume are due to TCP |> acknowledgements), proc 0 shows 50 input packets and 51 output |> packets. |> |> Once in this state, no further backplane network communication can |> be initiated or completed. Attempting to connect from one processor |> to the other results in an ETIMEDOUT. |> |> Has anyone seen any similar behavior? Any suggestions as to where to |> look or what to look for next? |> |> Thanks. |> -- |> |> Steve M. Burinsky |> smb@afterlife.ncsc.mil I think you should check to see if the Force card has rebooted. I have some experience w/ a MVME-167 acting as gateway for 4 SBE VCOM-100 FDDI cards. When the 167 goes down/reboots, it zero's its own memory, which happens to include the BP control block and buffer pool. The SBE's are left waiting for an indication of something to happen (through mailboxes that were listed/attached in the old BP control block). The 167 has disconnected the SBE's, so it no longer knows about them, and the SBE's never check to see if they are still attached to the BP. Try using a block of offboard memory on a separate card. The proc 0 Force card should be set to not clear this memory, so it may be able to have it come back up without loosing the proc 1 attachment. Check to see if proc 0 Force is rebooting/restarting the BP interface. Probably a symptom of another problem anyway. Good Luck. George Eger --------------------------- Newsgroups: comp.os.vxworks Subject: VxGDB Single Step Problem Date: Mon, 21 Sep 1992 14:22:22 GMT From: gould@waterloo.hp.com (Dan Gould) Organization: HP Panacom Div Waterloo ON Canada Message-ID: Sender: news@waterloo.hp.com (NetNews) Sometimes, but not always, the VxGDB Next function attempts to step into VxWorks system calls (eg: printf()). When this happens, it is difficult and sometimes impossible to get back to the execution stream of interest. I am debugging a remote target, and am using the X-Windows version of VxGDB. Does anyone know what causes this? - -- Dan Gould gould@waterloo.hp.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxGDB Single Step Problem Date: Tue, 22 Sep 1992 00:23:48 GMT From: markf@wrs.com (Mark Fox) Organization: Wind River Systems, Inc. Message-ID: References: Sender: news@wrs.com (News Manager) gould@waterloo.hp.com (Dan Gould) writes: > Sometimes, but not always, the VxGDB Next function attempts to step into > VxWorks system calls (eg: printf()). When this happens, it is difficult > and sometimes impossible to get back to the execution stream of interest. Internally, the "next" command actually does single-step into functions. When this happens, VxGDB sets a temporary breakpoint at the next instruction to be executed in the calling frame, then silently continues the target task. All of this should be invisible to the user. The behavior you describe can occur when you attempt to "next" over a function whose address is unknown to VxGDB. This situation will arise when VxGDB, in the process of connecting to a target system, can't find an object module that was loaded into the VxWorks target during a previous debugging session. In this case, when you give the "target" command, you'll see something like this: (vxgdb) targ tmarkf Attaching remote machine across net... Connected to tmarkf. Reading symbol data from /folk/markf/vw.502b/config/mv147/vxWorks... (no debugging symbols found)...done. test2.o: No such file or directory. If you now try to single-step over a function located in "test2.o," VxGDB will step into the function as normally, then halt the target program. It does this because--not knowing the address of the function in which the program is executing--it thinks you might have stepped to some random address not in your program, and wants to warn you about this. If this is happening when you step over a call to printf (), it might be that VxGDB was unable to locate the VxWorks boot image when connecting to the target. This will happen if, for some reason, the boot file is not accessible to VxGDB via the pathname specified to the VxWorks target as boot parameter. Of course, if there is a breakpoint set within the code you're stepping over, the target program will hit that breakpoint. But from your description, I don't think that this is what is happening, since this would have been less mysterious--VxGDB would have told you that the target program was stopping at a breakpoint. In any case, you should be able to use the "finish" command to get back to the frame from which the "next" command was issued. Mark Fox Wind River Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Processor disappearing from backplane network Date: 22 Sep 92 03:43:18 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Keywords: BP Interface Message-ID: <1992Sep22.034318.641@afterlife.ncsc.mil> References: <1992Sep21.031147.27873@afterlife.ncsc.mil> <1992Sep21.155427.18141@den.mmc.com> In article <1992Sep21.155427.18141@den.mmc.com> geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes: > >I think you should check to see if the Force card has rebooted. Neither processor is rebooting. - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- End of New-News digest ********************** From tlusco@inquisitor.gsfc.nasa.gov Tue Sep 22 06:14:59 1992 From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco) Date: Tue Sep 22 06:15:08 PDT 1992 Subject: DR11W Communications Has anyone out there used a DR11W under VxWorks? We are trying to use VMIC's DR11W-A card with some Heurikon V3Ds to do some acquisition from DR11W devices. So far we have had problems getting the cards to initiate DMA cycles. If anyone has any experience with DR11W or similar interfaces, we would appreciate any help you can give. Please contact me privatly or on the list, whichever is most convenient. Brief problem description: One crate with V3D as controller, 64MB memory card and DR11W, One crate with V3D as controller, 64MB memory card and DR11W, additional V3D CPUs. As a test case, we are trying to get one crate to talk to the other crate through the DR11Ws. We set one DR11W as reader, one as writer. then initiate DMA transfer. Plugging in a bus analyzer on the read side shows that two words were transferred into memory...sometimes. Sometimes we only get one, sometimes none at all. Very frustrating. Tom Lusco electronics Engineer XTE spacecraft GSE NASA/GSFC tlusco@inquisitor.gsfc.nasa.gov From enorgren@ehsl.mitre.org Tue Sep 22 07:45:32 1992 From: enorgren@ehsl.mitre.org (Eric J Norgren) Date: Tue Sep 22 07:45:39 PDT 1992 Subject: submitting articles Exploder Rep: I am currently working in the Electronic Hardware Standards Laboratory ( EHSL ) in Reston, VA. We are developing real-time data/voice/video communication systems for the Army, Navy, and Air Force. We are working on standards for a real-time voice data transfer protocol as well as a standardized call setup protocol for connecting to different hosts. I would like to submit article(s) to the exploder. What is the procedure for submitting articles to the exploder? Thank you for your assistance. Sincerely, Eric Norgren From tom@as.arizona.edu Tue Sep 22 11:08:52 1992 From: tom@as.arizona.edu (Thomas J. Trebisky) Date: Tue Sep 22 11:08:59 PDT 1992 Subject: DR11W software There was recent interest in software for a VMIC DR11W board. The following may not be of interest since my work was done for the Ikon Corp board, but anyway.... I wrote software for the Ikon corp. "buffered VMEbus DR11-W emulator" that is presently running fine under VxWorks. I don't know if this would be of any use to you, but I could make it available to you if you have any interest. Let me know. This was used in a VME box with a MVME147A cpu board, but very little of the software should be specific to that cpu. Tom From psm%helios.nosc.mil@nosc.mil Wed Sep 23 08:32:12 1992 From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh) Date: Wed Sep 23 08:32:19 PDT 1992 Subject: Re: submitting articles Has anyone put up the NFSSTONE benchmark program under vxworks? From mitchell@aaec1.aaec.com Wed Sep 23 14:01:30 1992 From: mitchell@aaec1.aaec.com Date: Wed Sep 23 14:01:38 PDT 1992 Subject: Re: Spurious interrupts >Now, the question ... In the summary, people says that the >spurious interrupt appears when one turns off interrupts in >the middle of an IACK cycle ... How is this possible ? As >far as I know, the IACK cycle is started by the processor >itself. It cannot therefore do something else (and in >particular, it cannot disable the interrupt handler in the >VMEChip2). Am I wrong ? Does the IACK cycle be started by >the VMEChip2 itself ? > >I would like to hear any comment on this. > >Thanks, > >Alain > There is a finite amount of time from the interrupt assertion to the processor running the IACK cycle. Even if there were no other interrupters to the CPU, this time would be non-zero, and this type of failure could occur because the signal must propagate all the way to the CPU, which then has to finish any instructions that are in process. In this case, spurious interrupts are unlikely, since the probability of hitting the peripheral while it is asserting IRQ is low. Thus its not turning off the interrupter during an IACK cycle, but during an IRQ before the IACK. If the CPU is servicing an interrupt of equal or higher priority, or is under and "intlock", it will not run the IACK cycle until these conditions are cleared. Since the 68030 will consider any interrupt that is valid for 2 CPU cycles, (correct me if I'm wrong) if an interrupt came in during an "intlock" and the interrupter was disabled during the same intlock, then a spurrious interrupt will occur after the intUnlock when the CPU runs the IACK cycle. Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | From daemon@vxw.ee.lbl.gov Thu Sep 24 04:01:38 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Sep 24 04:01:46 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Sep 24 04:01:31 PDT 1992 Subject: FORSALE: 68020 VME System $650 Subject: Force CPU-40 BP_TAS hardware bug? Subject: network numbers for backplane networks Subject: Re: Evaluating VME CPUs ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: FORSALE: 68020 VME System $650 Date: Thu, 24 Sep 1992 00:00:41 GMT From: sja@world.std.com (Stuart J Adams) Organization: The World Public Access UNIX, Brookline, MA Message-ID: I have the following VME system for sale for $650 or best offer. 3 slot VME enclosure w/ power supply This is a Series 3 enclosure from Electronic Solutions with a 175W power supply. It is 3.5" x 19.75" x 17" and is rack mountable. Complete Manuals Motorola MVME134/D1 16MHz 68020 VME CPU Card with 68851 PMMU 4 MBytes RAM 2 Serial Ports Battery Backey Clock/NVRAM MVME134BUG in ROM Complete Manuals on Board and ROM Monitor Motorola MVME333-2 Intelligent Communications Controller VME Card This a 10MHz 68010 based six channel serial controller card with 512K RAM. MVME333BUG in ROM Complete Manuals on Board and ROM Monitor MVME705A/D2 Serial Transciever Module Transceiver Module for the above board. Connects to P2 on VME bus and brings serial channels to DB-25 connectors Complete Manuals This is system was hardly used and is in mint condition. (No dust, scratches, marks, etc.) Thanks, Stuart Adams sja@world.std.com --------------------------- Newsgroups: comp.os.vxworks Subject: Force CPU-40 BP_TAS hardware bug? Date: 24 Sep 92 02:47:22 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep24.024722.14909@afterlife.ncsc.mil> I've heard that the Force CPU-40 suffers from a hardware bug that makes a test-and-set (TAS) instruction on the VMEbus unreliable (whatever that means). In any case, I've been having problems booting a CPU-40 across the backplane. After "Loading...", things hang about 30% of the time. Rumor has it that changing BP_TAS to FALSE (choosing software TAS on the bp net) will fix my problem. Anyone else run into this? Thanks. - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: network numbers for backplane networks Date: 24 Sep 92 03:14:02 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep24.031402.15646@afterlife.ncsc.mil> Currently, I allocate a unique network number for every crate I have with a backplane network running. Since my group has lots of crates under development, I could chew up a large number of network numbers over the next few years. I have considered using subnetting to help me make better use of network numbers. I considered allocating a new network number for each project. Then, I would subnet that network for each instance (copy of a given crate) that I create. However, I haven't had much success making this work. From what documentation I can find on subnetting, I think I'm trying to do something it was not intended for. Everyone I've talked to knows just enough about subnetting to not be sure if this should work. How do you deal with network numbers for backplane networks? Thanks. - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Evaluating VME CPUs Date: 23 Sep 92 12:55:21 EST From: els@icf.hrb.com (Eric L. Schott) Organization: HRB Systems, Inc. Message-ID: <1992Sep23.125521.19586@icf.hrb.com> References: <9209211832.AA05757@helios.nosc.mil> In article <9209211832.AA05757@helios.nosc.mil>, psm%helios.nosc.mil@nosc.mil (Scot McIntosh) writes: > We are about to launch an evaluation of the following VME boards for > suitability to our application: > > Performance Technology PT-VME141 > Force CPU40 > Synergy SV430 > > Besides the general 'performance' (criteria for which we have yet to > define) of the boards, we are particularly interested in Ada support, > and in how well they are able to handle at least 4 high-speed > (>256kbits) synchronous serial I/O channels. I'd appreciate hearing > from anyone else who has looked into these boards. I'd also > appreciate hearing about what other people have used for evaluation > criteria of such products in the past. We did a similar evaluation of single board computers, some of which are in you list. We began testing with following "standalone" tests: 1. DMA (VMEbus to SBC memory) 2. TCP socket speeds to a SparcStation 3. Raw dhrystones (dhry-2) These tests showed significant differences between products. The key results were: 1. VMEbus speeds had dramatic ranges. One board max'ed out at 3.8 Megabyte/s and another max'ed at 40.9 MB/s. Some boards did/ did not support D32 BLT and D64 BLT. 2. TCP speeds were rather consistent (0.45 MB/s) except for two boards: one was 0.065 MB/s and another was 0.822 MB/s. 3. Most boards ran 9500 Dhrys/s. One board had full cache control and was running 23,188 Dhrys/s. For those interested, one specific board had the highest rates in all three catagories. We then took the best two performing boards and executed one "combined" benchmark which did simultaneous execution of the above three tests. Fixed quantities were chosen for the test so that all three transfers on the slowest board completed at nearly the same time. This test showed dramatic results: Standalone Combined Board Net DMA Dhry Net DMA Dhry A .491 4.4 9375 .256 3.8 161 B .822 19.4 23188 .878 15.9 6138 DMA was either D32 or D32 BLT. When all was done, we bought board "B." (See if you can determine which entry is "puzzling.") In summary: 1. Select good benchmark tests 2. Be sure to have one "simulated application" 3. Watch the cache issues: some boards support hardware to invalidate cache, so don't. 4. Ignore ALL vendor claims. Run your own benchmarks. Work with the vendors to resolve discrepencies. - -- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@icf.hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" --------------------------- End of New-News digest ********************** From fjr@rayssd.ssd.ray.com Thu Sep 24 11:47:24 1992 From: Roeber Date: Thu Sep 24 11:47:32 PDT 1992 Subject: Re: network numbers for backplane networks > Subject: network numbers for backplane networks Steve M. Burinsky writes: > > Currently, I allocate a unique network number for every crate I have with > a backplane network running. Since my group has lots of crates under > development, I could chew up a large number of network numbers over the next > few years. I have considered using subnetting to help me make better use > of network numbers. > > I considered allocating a new network number for each project. Then, I > would subnet that network for each instance (copy of a given crate) that > I create. However, I haven't had much success making this work. From what > documentation I can find on subnetting, I think I'm trying to do something > it was not intended for. Everyone I've talked to knows just enough about > subnetting to not be sure if this should work. > > How do you deal with network numbers for backplane networks? It took us a while to figure out how to subnet our network and get all the routing issues worked out. It works just fine now under VxWorks. Each crate is it's own subnet. While you can get things set up this way, a new protocol that WRS announced support for at last weeks user group meeting should go a long way towards making multiple crate networks much easier to set up and maintain. Basically, WRS has added support for "proxy arp" to their network code. Since it sounds like you are trying to prepare for the future rather than address a current problem, I would suggest you just wait till the next release of VxWorks is available and then configure proxy arp to do what you want (I'm sure the documentation that comes with the release will make it very clear how to configure it ;-). 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 daemon@vxw.ee.lbl.gov Fri Sep 25 04:00:55 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Sep 25 04:01:04 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Sep 25 04:00:47 PDT 1992 Subject: Re: network numbers for backplane networks Subject: Re: Force CPU-40 BP_TAS hardware bug? Subject: Proxy arp (was "network numbers for backplane networks") Subject: Re: Spurious interrupts (SUMMARY) ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: network numbers for backplane networks Date: 24 Sep 92 23:08:39 GMT From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1992Sep24.031402.15646@afterlife.ncsc.mil> Sender: hwajin@iphasew.com >>>>> On 24 Sep 92 03:14:02 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said: Steve> I considered allocating a new network number for each project. Steve> Then, I would subnet that network for each instance (copy of a Steve> given crate) that I create. However, I haven't had much Steve> success making this work. From what documentation I can find Steve> on subnetting, I think I'm trying to do something it was not Steve> intended for. Everyone I've talked to knows just enough about Steve> subnetting to not be sure if this should work. using subnets with backplane devices work fine -- i know several people who have done this in the past. also, i heard a rumor that the new release of vxworks has proxy arp, which should allow another solution that will work nicely for backplane nets. i know somewhere in those archive disks of wind river, there are some application notes about this stuff -- at least about subnetting over bp, etc., so i'd talk to them for help. ~hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Force CPU-40 BP_TAS hardware bug? Date: 24 Sep 92 23:03:01 GMT From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1992Sep24.024722.14909@afterlife.ncsc.mil> Sender: hwajin@iphasew.com >>>>> On 24 Sep 92 02:47:22 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said: Steve> I've heard that the Force CPU-40 suffers from a hardware bug Steve> that makes a test-and-set (TAS) instruction on the VMEbus Steve> unreliable (whatever that means). In any case, I've been Steve> having problems booting a CPU-40 across the backplane. After Steve> "Loading...", things hang about 30% of the time. Rumor has it Steve> that changing BP_TAS to FALSE (choosing software TAS on the bp Steve> net) will fix my problem. Anyone else run into this? you probably already know tas being good for implementing something like semaphores since it's automic test-and-update. in vme/m68k context, tas is implemented using rmw (read-modify-write) cycle, which is automic, if your board's bus interface logic doesn't implement this properly, tas'ing to off-board memory won't always work. on boards that have trouble with tas (i'm using one), you can use software-tas option in backplane driver, which emulates tas by checking the location several times after it is test-and-set. if you still have trouble with this, you can try turning data-cache off. in 4.0.x vxworks, you do this by modifying sysALib.s in your bsp (sysCacheEnable routine). in 5.0+ vxworks, i think wrs added cacheLib, so you should use the routines in cacheLib. ~hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Proxy arp (was "network numbers for backplane networks") Date: Fri, 25 Sep 1992 04:19:52 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep25.041952.22130@afterlife.ncsc.mil> References: <199209241328.AA00372@pike.ssd.ray.com> Could someone please explain what proxy arp will or won't do for me? - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Spurious interrupts (SUMMARY) Date: Fri, 25 Sep 1992 09:33:46 GMT From: Ninane@fynu.ucl.ac.be (Alain Ninane - FYNU) Organization: University of Louvain (LLN) - Nuclear Physics Dept. Message-ID: <1992Sep25.093346.23760@info.ucl.ac.be> Followup-To: comp.os.vxworks Sender: news@info.ucl.ac.be (News Administrator) Folks, One week ago, I posted a request about spurious interrupts on a MVME167 board. I knew the solution but I wanted to understand why the problem was cured. Original posting: > Hardware : MVME147, MVME167 > Software : VxWorks 5.0.2 > I have an application which handle VMEbus interrupts > requested by a data acquisition board (to be precise, a > CAMAC branch). In the user level code, I enclose critical > sections by the sysIntDisable() and sysIntEnable() > routines. The code was working well, in any condition, on > MVME147 boards. However, when I started to use the new > MVME167 and under an heavy load of interrupts, I started to > receive a lot of spurious interrupts. > > For those who are not aware of what a spurious interrupt > is, let me tell you that such an exception occurs when the > processor tries to read, without succes, the interrupt > vector during an IACK cycle. It's like a bus error in the > vector read operation. > > Fortunately, some times ago (July '92), there was a > discussion about spurious interrupts on Motorola boards. A > nice summary was posted by shaffer@stef.crd.ge.com. In > short, the best way to protect critical sections is not to > disable the VMEbus interrupt handler but instead to raise > the processor priority. Indeed, that solves the problem. > > Now, the question ... In the summary, people says that the > spurious interrupt appears when one turns off interrupts in > the middle of an IACK cycle ... How is this possible ? As > far as I know, the IACK cycle is started by the processor > itself. It cannot therefore do something else (and in > particular, it cannot disable the interrupt handler in the > VMEChip2). Am I wrong ? Does the IACK cycle be started by > the VMEChip2 itself ? Phillip L. Shaffer (shaffer_phillip@ae.ge.com) says that: > As I understand it, IACK is initiated by an interrupt, which is > of course asynchronous with instruction execution, so you can be > executing an instruction that disables just as an interrupt is > occurring -- thus the occasional problem. and, Andrew Mitchell (mitchell@aaec.com) writes: > There is a finite amount of time from the interrupt assertion to the > processor running the IACK cycle. Even if there were no other interrupters > to the CPU, this time would be non-zero, and this type of failure could > occur because the signal must propagate all the way to the CPU, which then > has to finish any instructions that are in process. In this case, spurious > interrupts are unlikely, since the probability of hitting the peripheral > while it is asserting IRQ is low. Thus its not turning off the interrupter > during an IACK cycle, but during an IRQ before the IACK. Below, I have tried to sketch a scenario. If an interrupt comes at the same time the CPU is executing the instruction to disable the VMEbus interrupts, the IACK will be started but will failed due to the disabled interrupter (--> spurious irq). The situation is even worst if I listen to the Andrew's comment about time propagation on the board. The (not yet spurious) IRQ could be started even before the CPU executes the code to disable the interrupter. If the interrupts are ``disabled'' by raising the processor priority, the problem doesn't occur because the IACK cycle is not started (if it started, the ISR would be executed - a forbidden situation with regards to the CPU status register !). ---- Time axis -------> |<-- Disable instruction ->| ----- ----- ----- ----- ----- ----- ----- ----- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- ----- ----- ----- ----- ----- ------ ----- ---- | | /------>------>----->----- ----\ / | \ / | \ (IACK cycle) / \ \ / \ \ (IREQ) \ (Interrupter disabled) Now, the problem has never occured on MVME147. We were first confronted to it on MVME167. I suspect therefore that the design of either the MC68040, the VMEChip2, the PCC2 or the MVME167 leads to critical courses which were not on the MVM147. Thanks to all people who give me some hints ! Alain - -- Dr. Alain H. Ninane | Tel : +32-10-47.32.73 - Fax: +32-10-45.21.83 University of Louvain | Internet: Ninane@fynu.ucl.ac.be Nuclear Physics Dept. | Ch. du Cyclotron, 2 B-1348 Louvain-la-Neuve | BELGIUM --------------------------- End of New-News digest ********************** From mea@sparta.com Fri Sep 25 05:14:17 1992 From: mea@sparta.com (Mike Anderson) Date: Fri Sep 25 05:14:26 PDT 1992 Subject: Re: Proxy ARP Greetings! >Could someone please explain what proxy arp will or won't do for me? > >- -- > >Steve M. Burinsky >smb@afterlife.ncsc.mil Begin Proxy ARP lesson... The Address Resolution Protocol (ARP) is used in the event that host A wishes to communicate with host B and A knows B's internet (i.e., logical) address but not B's Ethernet (i.e., physical network) address. An ARP request is broadcast by A to the network that essentially says "please tell me the physical address of the host that corresponds to this internet address." In a normal ARP request, all hosts on the broadcast medium receive the message, but only the host that actually has the desired internet address responds. This response is in the form of an ARP reply packet that essentially says the following logical address can be found via this physical address. The requesting host (host A) then adds this information to its ARP cache for future reference (the ARP cache can be viewed using the arp -a command). As long as the newly cached address keeps being used, the entry will stay in the cache and no new ARP requests will be needed. If the cache gets flushed or that entry ages until it gets removed from the cache, then a new ARP request will be needed if A is to talk to B again. For what its worth, I believe that at least some implementations of UNIX will have all of the hosts that see the ARP reply cache the logical to physical mapping as well just in case they need it later. ARP requests are broadcasts. By definition, broadcasts are not automatically forwarded across gateways (including CPU 0 in a VxWorks backplane). This is not a bug but a *feature* to keep the Internet from being clogged with local broadcast packets. Therefore, CPUs in VxWorks backplanes have no means to answer ARP requests by themselves. Therefore, without an explicit route to get to CPUs on the backplane (entered via route add or via routed), hosts on the main net cannot "see" VxWorks CPUs. Enter Proxy ARP. With Proxy ARP, CPU 0 can answer the ARP request for a CPU in the backplane by giving CPU 0's physical network address in the ARP reply. This means that the requesting host will simply send all of the packets destined for, say, CPU 1 to CPU 0 and then CPU 0 will have to forward them (this forwarding is done without the requesting host's knowledge and no new routing table entries are made). This also means that we will no longer have to set the backplane up as a separate network and establish routes. With Proxy ARP, the CPUs on the VxWorks backplane will no longer appear as though they are using a gateway because the Proxy ARP daemon on CPU 0 will make the backplane "look" just like an extension of the main net with a group of hosts on it. As I understand it, the implementation of Proxy ARP for VxWorks 5.1 will use the base internet address of CPU 0 as a starting address and then use the CPU number as an offset to determine the new internet number for the VxWorks CPUs. E.g., if CPU 0 is 192.48.111.20, then CPU 1 would be 192.48.111.21, CPU 2 would be 192.48.111.22, etc. This could be an annoying limitation for some applications, but will probably be offset by the greater ease of set up and maintenance of Internet numbers for Systems Admin types who usually don't understand how VxWorks backplanes operate and can't quite figure out why you *need* all those network numbers for those dinky little VMEbus chassis. End of Proxy ARP lesson... Hope this helps, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From daemon@vxw.ee.lbl.gov Sat Sep 26 04:00:46 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Sep 26 04:00:54 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Sep 26 04:00:39 PDT 1992 Subject: 2nd RFD: comp.sys.vmebus ------------------------------------------------------- Newsgroups: news.announce.newgroups,news.groups,comp.realtime,comp.robotics,comp.lang.c,comp.sys.m68k,comp.os.os9,comp.os.misc,comp.lang.ada,comp.os.vxworks,comp.sys.sun.hardware Subject: 2nd RFD: comp.sys.vmebus Date: Fri, 25 Sep 1992 13:08:57 GMT From: dstewart+@cs.cmu.edu (David B Stewart) Organization: The Robotics Institute, Carnegie Mellon University Message-ID: Followup-To: news.groups Sender: tale@uunet.uu.net (David C Lawrence) This is the 2nd Request for Discussion (RFD) regarding creation of an unmoderated newsgroup 'comp.sys.vmebus' for discussing all aspects of computing related to the VMEbus and VMEbus-based systems. So far the following summarizes what has been discussed on news.groups about the proposed creation of comp.sys.vmebus: 1- No objections yet. Some say this newsgroup is long overdue. 2- Naming the newsgroup 'comp.sys.vme' VS. 'comp.sys.vmebus'. The shorter name was recommended by one netter, saying that it is a common abbreviation. However, not everyone agrees since VMEbus is the official name, and VME is the name of a mainframe operating system. Based on this, I plan on keeping the name 'comp.sys.vmebus' when we have the Call for Votes (CFV). 3- One person recommends that the charter of the newgroup be expanded to include other buses related to VMEbus, such as Futurebus+. Additional discussion on this point is encouraged. All discussions should take place in news.groups. The Call for Votes will occur on Oct. 17 at the earliest, according to the USENET rules for creating a new newsgroup. (cf. ). The original Request for Discussion follows: - ------------------------------------------------------------------------- This is a Request for Discussion (RFD) regarding creation of an unmoderated newsgroup for discussing all aspects of computing related to the VMEbus and VMEbus-based systems. comp.sys.vmebus Discussions on hardware & software for VMEbus. The VMEbus is one of the more popular standards for developing open-architecture applications based on off-the-shelf hardware. Many hardware components, operating systems, and applications are based on this standard, yet there currently is no USENET group where discussions of this standard, and related items, are appropriate. The proposal is to create comp.sys.vmebus as a forum for discussing issues related to developing VMEbus-based systems. This includes discussion on the VMEbus Specification; VMEbus-based hardware, such as CPU boards and I/O devices; secondary buses such as VSB, VXI, and VMX; open-architecture applications based on the VMEbus; and hardware-dependent software, such as device drivers and bus communication protocols. The group is also available for questions and answers, so that developers of VMEbus-based hardware and software can get feedback or help with any problems they may encounter. Discussions should not be about hardware-independent software which use the VMEbus, such as the operating system or language being used, as there are other comp.* newsgroups dedicated to those functions. The discussion on this proposal will take place in news.groups Please see the pertinent postings in news.answers and news.announce.newgroups for the rules that will be followed in creating a newsgroup (). - -- David B. Stewart - email: The Robotics Institute snail mail: - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213 Current Projects: - Chimera 3.0 Real-Time Operating System - Reconfigurable Sensor-Based Control Systems --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Tue Sep 29 04:00:57 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Sep 29 04:01:04 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Sep 29 04:00:50 PDT 1992 Subject: Locking Interrupts.. ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Locking Interrupts.. Date: 29 Sep 92 04:17:11 GMT From: zafer@bcars474.UUCP (Zafer Elbi) Organization: Bell-Northern Research, Ottawa, Canada Keywords: VxWorks Message-ID: <1992Sep29.041711.8216@bnr.ca> Sender: zafer@bcars474 (Zafer Elbi) For the following code: int lock = intLock(); .. .. ..---> Task switch .. intUnlock(); If there is a task switch occurs in the middle of the interrupt routine, can the preempting task unlock the interrupts again? Thanks for the reply.. --------------------------- End of New-News digest ********************** From prb@aplexus.jhuapl.edu Tue Sep 29 05:30:44 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Tue Sep 29 05:30:51 PDT 1992 Subject: Re: comp.os.vxworks newsdigest zafer writes: -> For the following code: -> int lock = intLock(); -> .. -> .. -> ..---> Task switch -> .. -> intUnlock(); -> If there is a task switch occurs in the middle of the interrupt routine, can -> the preempting task unlock the interrupts again? If there are no interrupts allowed, there will be no clock interrupts or other interrupts to bring about a task switch. So the answer is, there is no prempting task. Paul Bade From fjr@rayssd.ssd.ray.com Tue Sep 29 07:40:49 1992 From: Roeber Date: Tue Sep 29 07:40:56 PDT 1992 Subject: Re: task locking and interrupt locking > zafer writes: > > > -> For the following code: > > -> int lock = intLock(); > -> .. > -> .. > -> ..---> Task switch > -> .. > -> intUnlock(); > > -> If there is a task switch occurs in the middle of the interrupt routine, can > -> the preempting task unlock the interrupts again? > > > If there are no interrupts allowed, there will be no clock interrupts or > other interrupts to bring about a task switch. So the answer is, > there is no prempting task. > > Paul Bade While Paul is right that there will be no implicit task switchs, I assume the original question would be what happens if the code that had interrupts locked out did an explicit task switch (e.g. resumed a higher priority task). Personally, I don't know why someone would do that but I seem to remember that VxWorks will handle such a situation correctly, unblocking interrupts for the new task and restoring the lockout when the original task runs again. This is covered in the CAVAET section of the intLock manual page. 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 mitchell@aaec1.aaec.com Tue Sep 29 12:11:44 1992 From: mitchell@aaec1.aaec.com Date: Tue Sep 29 12:11:51 PDT 1992 Subject: Re: Locking Interrupts.. >Sender: zafer@bcars474 (Zafer Elbi) > >For the following code: > >int lock = intLock(); >.. >.. >..---> Task switch >.. >intUnlock(); > >If there is a task switch occurs in the middle of the interrupt routine, can >the preempting task unlock the interrupts again? > >Thanks for the reply.. > >--------------------------- Interrupt service routines are never preempted by tasks. They run at interrupt level on the CPU, which is kind of like "higher than 0" priority. They have no task context and many vxWorks "things" won't work. The only thing that can preempt an interrupt is a higher priority interrupt (or another level 7 if currently a level 7 (NMI)). This is for a 680x0, and is the way the chip works; I don't know about other CPU families. intLock() is rarely needed in an ISR, since the same level interrupt is ignored, other interrupts tend to be unrelated, no task will run until all pending interrupts are finshed, and ISR's typically do some simple I/O and/or give semaphores. intLock at the task level is quite different; it locks out all interrupts (except NMI level 7 - which one tries to avoid using for non-fatal events), and is very useful when manipulating data that is also used by an ISR. Long intLocks() should be avoided because they increase latency, making the system "less" real-time. The current interrupt mask is part of the task context, and is switched with the rest of the task. If a task is at one intLock level and is switched out, then the interrupt level mask in the CPU will be set to the new task's intLock level, and restored when the original task is switched back in. If the intLock level is at the default level 7, then the only way to get a context switch is for the current task to ask for one via a semGive or other kernel call (see CAVEAT under intLock()). intLock levels other that 7 are set with intLockLevelSet(), which sets up the control word to be used by the "quick" intLock(), intUnlock(). intLevelSet() dets the level directly, but is slower than intLock and intUnlock. Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | From daemon@vxw.ee.lbl.gov Wed Sep 30 04:00:32 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Sep 30 04:00:43 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Sep 30 04:00:24 PDT 1992 Subject: Beginner questions on VxWorks Subject: Re: comp.os.vxworks newsdigest Subject: bug with mutex semaphores in 5.0.2??? Subject: re: comp.os.vxworks newsdigest Subject: Re: 167BUG Diagnostics and VxWorks Subject: Re: Locking Interrupts.. Subject: Re: bug with mutex semaphores in 5.0.2??? Subject: Intertask communication mechanisms Subject: Re: Intertask communication mechanisms ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Beginner questions on VxWorks Date: 29 Sep 92 14:31:20 GMT From: Laurent.vonAllmen@imt.unine.ch Organization: University of Neuchatel, Switzerland Message-ID: <1992Sep29.143120.870@unine.ch> Hello! Sorry for this beginner request but we are starting a new projet and we have little time to make a choice. We are evaluating VxWorks: We would like to answer the following questions: - Which types of processor are supported? - Is a VME driver included? - Which mass storage facility? - Any remote debugging? - Posix conformance? We would be grateful if either we receive the answers or we are given references about these OS comparisons/benchmarks. Please e-mail answers to X.400 : C=ch; A=arcom; P=switch; O=unine; OU=imt; S=vonAllmen; G=Laurent Internet-style : Laurent.vonAllmen@imt.unine.ch Any help mostly welcome. Thank you. Laurent von Allmen --------------------------- Newsgroups: comp.os.vxworks Subject: Re: comp.os.vxworks newsdigest Date: 29 Sep 92 14:41:21 GMT From: vreeburg@fys.ruu.nl (Jurriaan Vreeburg) Organization: Physics Department, University of Utrecht, The Netherlands Message-ID: <1992Sep29.144121.7175@fys.ruu.nl> References: <9209291230.AA17923@aplexus.jhuapl.edu> In <9209291230.AA17923@aplexus.jhuapl.edu> prb@aplexus.jhuapl.edu (Paul R. Bade) writes: >zafer writes: > >-> For the following code: >-> int lock = intLock(); >-> .. >-> .. >-> ..---> Task switch >-> .. >-> intUnlock(); >-> If there is a task switch occurs in the middle of the interrupt routine, can >-> the preempting task unlock the interrupts again? >If there are no interrupts allowed, there will be no clock interrupts or >other interrupts to bring about a task switch. So the answer is, >there is no prempting task. Not completely true. See the man-pages for intLock(): IMPORTANT CAVEAT intLock() can be called both from interrupt and from task level. When called from a task context, (which is the case with Zafer), the interrupt lock level is part of the task's context. Locking out interrupts DOES NOT PREVENT RESCHEDULING. Thus, if a task locks out interrupts and then invokes kernel services that cause the task to block or causes a higher priortity task to be ready, then rescheduling will occur and interrupts will be unlocked while other tasks run. Rescheduling may be expicitly disabled wirh taskLock(). To answer Zafer's question: the preempting task can not intUnlock(), because the lock is not part of its own context. - -- Jurriaan Vreeburg email: vreeburg@fys.ruu.nl Department of Physics and Astronomy tel.: (+31)-(0)30-534566 P.O. Box 80.000 3508 TA Utrecht Holland --------------------------- Newsgroups: comp.os.vxworks Subject: bug with mutex semaphores in 5.0.2??? Date: Tue, 29 Sep 1992 17:51:43 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA/ARC Information Sciences Division Keywords: semaphore, bug, 5.0.2 Message-ID: <1992Sep29.175143.20505@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov) Hi all, I seem to be having a problem with mutual exclusion semaphores: they don't seem to work at all!!!! For example, given the following code: - ------------------------------------------------------------------------------ #include "vxWorks.h" #include "semLib.h" SEM_ID semId; waitAndPrint () { extern SEM_ID semId; while (1) { semTake (semId, WAIT_FOREVER); printf ("got semId!\n"); } } - ------------------------------------------------------------------------------ I compile under 5.0.2 using cc68k: cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \ -I/usr1/vw/h -c waitAndPrint.c Then in the VxWorks shell: - -> semId = semMCreate (1) (note: 1 = SEM_Q_PRIORITY) semId = 0x33fdcec: value = 54264916 = 0x33c0454 - -> ld < waitAndPrint.o value = 0 = 0x0 - -> semTake (semId, -1) (note: -1 = WAIT_FOREVER) value = 0 = 0x0 By this point, the semId should be empty and anything that attempts to take it should pend. So, I start up the waitAndPrint task: - -> waitAndPrint got semId! got semId! got semId! got semId! . . . (Ctrl-C) As you can see, waitAndPrint NEVER pends. It ALWAYS is able to take the semaphore. If I replace "semMCreate (1)" with "semBCreate (1, 1)" (i.e., use a regular binary semaphore), everything works as expected (i.e., waitAndPrint pends). So, am I doing something wrong? Or is there a bug here? - -Terry - -- _______________________________________________________________________________ Q:"What do you do with your life?" | Terry Fong A:"Nothing. But I do it terribly | NASA Ames, M/S 269-3, Moffett Field, CA well!" - John Drake (Secret Agent)| (415) 604-6063 voice, 604-4036 fax --------------------------- Newsgroups: comp.os.vxworks Subject: re: comp.os.vxworks newsdigest Date: Tue, 29 Sep 1992 21:41:30 GMT From: bard@cutter.ssd.loral.com (J H Woodyatt) Organization: Abiogenesis 4 Less Message-ID: <1992Sep29.214130.9257@wdl.loral.com> References: <9209291230.AA17923@aplexus.jhuapl.edu> Reply-To: bard@cutter.ssd.loral.com Sender: news@wdl.loral.com prb@aplexus.jhuapl.edu (Paul R. Bade) writes: # If there are no interrupts allowed, there will be no clock interrupts or # other interrupts to bring about a task switch. So the answer is, # there is no prempting task. I thought context switches could occur in the absence of clock interrupts when a task is made ready by giving a semaphore. - -- J H Woodyatt (a.k.a. Dr. Strychnine) Space Systems/Loral Help keep Las Vegas clean. Eat your kill. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 167BUG Diagnostics and VxWorks Date: Tue, 29 Sep 1992 23:48:24 GMT From: pat@wrs.com (Patrick Boylan) Organization: Wind River Systems, Alameda CA Keywords: 167BUG, VxWorks, Diagnostics Message-ID: References: <1992Sep11.085304.19546@icf.hrb.com> Reply-To: pat@wrs.com Sender: news@wrs.com (News Manager) In article <1992Sep11.085304.19546@icf.hrb.com>, r2c@icf.hrb.com (Robert J. Cole) writes: |> |> I am attempting to write c diagnostic routines for the Motorola |> 167 board to run in vxWorks. The Motorola 167BUG firmware exists on the |> board and on power-up, boots and passes control to vxWorks. 167BUG |> exists in the first two PROMS and VxWorks in the second set. VxWorks |> boot ok in this configuration. The intention is to run the user diagnostic |> routines on the 167 board which will make use of the resident Motorola |> diagnostic routines already in ROM, however this effort seems to be rife |> with difficulty. |> |> Has anyone done anything similar to what I am attempting and is |> able to offer any advice? |> |> Rob Cole. r2c@icf.hrb.com Rob, I've done something similar for the Motorola MVME-147 and MVME-133. The procedure involves booting MBUG, then upon successful MBUG boot, MBUG searches for a boot block. This boot block is used to jump start vxWorks. Diagnostic results from MBUG were no more than pass/fail (if it failed it would not make it to vxWorks). The results are printed out onto the console which was good enough for us. Unfortunatley it was difficult to extract the individual diagnostics procedures from MBUG. As far as I remember there was no jump table, nor was it well enough modularized to allow for this much execution granularity, even with the source code. This is the procedure for using MBUG power up test procedures and then vectoring to VxWorks. These steps are specifically for the MVME147 and MVME133. The MVME-167 might be different, however. Install MBUG PROMS in bank0. Reconfigure jumpers for the larger size EPROMS (see documentation for the target). Build VxWorks with a ROM start address equal to the bank1 base address instead of bank0. This is changed in the VxWorks file "vw//config.h". Optionally poke the BOOT block (shown below) into these ROMs also using the editor of the PROM programmer. I put it at address 0xffa1f800 on the MVME133XT. Incidentally, another option is to put the bootblock direclty into non-volatile RAM. Install the newly built VxWorks PROMS in bank1. In order to cause MBUG to autovector to vxWorks. MBUG completes self test, then checks the romboot flag (set from the MBUG debugger), then if an address is specified when the romboot is turned on, then this address is searched first for the boot block, if the bootblock is not found at this address, memory is searched for a bootblock in NVRAM, RAM, or ROM . Note that the boot blovk has to be on an 8KByte (0x2000) boundary). The boot block can be inserted into non-volatile RAM. This makes it easier for testing, and is easier and quicker to set up. The MV133XT nonvolatile RAM is in the RTC which is located at 0xfffc0000 There are 2040 bytes available but the first 256 are used for the VxWorks boot line. Try putting the boot block at 0xfffc0300. Take a look at the memory to make sure it is not being used by MBUG. The MVME147 battery backed RAM should be at 0xfffe0000. Using MBUG search through this novram for a block that is not being used. Modify memory to insert the following data into the NV RAM: Boot block data for the MVME133XT follows: xxxx000: 424f 4f54 0000 0018 0000 0016 7678 576f *BOOT........vxWo* xxxx010: 726b 7320 d2b6 0000 4e56 0000 dffc 0000 *rks ....NV......* xxxx020: 0000 48d7 0000 4ef9 fff2 0008 7000 4e5e *..H...N.....p.N^* xxxx030: 4e75 ffff Boot block data for the MVME147 follows: xxxx000: 424f 4f54 0000 0018 0000 0016 7678 576f *BOOT........vxWo* xxxx010: 726b 7320 d2b6 0000 4e56 0000 dffc 0000 *rks ....NV......* xxxx020: 0000 48d7 0000 4ef9 ffa0 0008 7000 4e5e *..H...N.....p.N^* xxxx030: 4e75 ffff The boot block for other processors is the same except the appropriate bank 1 execution address should be inserted into offset 28. In the first case it is 0xfff20008 which is the MVME133XT ROM bank1 base address + 8. The MVME147 bank1 execution address is 0xffa00008. Then insert the checksum. This is the last word of the boot block (at offset 32). This is sum from the first word of the bootblock (offset 0) to the last word of the bootblock (0x30), but inverted so that the total checksum including this word should add up to zero. Note: I can't remember whether it is 16 bit or 8 bit checksum. Look at MBUG documentation or try it. Configure romboot parameters in MBUG, using the rb command. Turn on RB, assign the address where the boot block is located (saves time) and rom boot on power up only (this allows you to use the RESET switch to get back to MBUG). Cycle power to test rom boot procedure. If it takes a while and sits at a message saying searching for boot block, then either the boot block has not been found, the address is wrong, or the checksum does not match. If the address is wrong and the boot block is located at an 8KByte (0x2000) boundary then it should be found eventually. It just may take a while. When it is found note the address that it was found at and specify this address as the search start address to save some time. Hope that helps. Regards, Patrick - -- Patrick Boylan, Consulting Engineer, FAE Asia/Pacific Wind River Systems 1010 Atlantic Ave. Alameda, CA 94501 email: pat@wrs.com tel: (510)748-4100 fax: (510)814-2010 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Locking Interrupts.. Date: 29 Sep 92 23:46:37 GMT From: hwajin@iphasew.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1992Sep29.041711.8216@bnr.ca> Sender: hwajin@iphasew.com >>>>> On 29 Sep 92 04:17:11 GMT, zafer@bcars474.UUCP (Zafer Elbi) said: Zafer> int lock = intLock(); Zafer> .. Zafer> .. Zafer> ..---> Task switch Zafer> .. Zafer> intUnlock(); Zafer> If there is a task switch occurs in the middle of the interrupt Zafer> routine, can the preempting task unlock the interrupts again? i suppose the answer is yes, since anyone can call intUnlock() if they want to but whether it is desirable to do so is another matter. the interrupt mask information is part of the task context -- in m68k world, status register contains this info which gets saved and restored per context switch. what you may or may not want to do is to disable the task switch (taskLock()/taskUnlock()) depending on whether you're really concerned about locking out interrupts and not being context switched out (which could alter the interrupt masks depending on which task gets switched in). ~hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: bug with mutex semaphores in 5.0.2??? Date: 30 Sep 92 03:22:25 GMT From: hwajin@mondo.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1992Sep29.175143.20505@kronos.arc.nasa.gov> Sender: hwajin@iphasew.com >>>>> On 29 Sep 92 17:51:43 GMT, doctor@kronos.arc.nasa.gov (Terry Fong) said: Terry> Nntp-Posting-Host: tardis-arclan.arc.nasa.gov Terry> SEM_ID semId; Terry> waitAndPrint () Terry> { Terry> extern SEM_ID semId; Terry> while (1) { Terry> semTake (semId, WAIT_FOREVER); Terry> printf ("got semId!\n"); Terry> } Terry> } Terry> -> semId = semMCreate (1) (note: 1 = SEM_Q_PRIORITY) Terry> semId = 0x33fdcec: value = 54264916 = 0x33c0454 Terry> -> ld < waitAndPrint.o Terry> value = 0 = 0x0 Terry> -> semTake (semId, -1) (note: -1 = WAIT_FOREVER) Terry> value = 0 = 0x0 interesting... it looks like when you compiled the above program, _semId gets defined as a common global symbol, not an unknown (external) symbol (rightly so because you didn't declare it "extern") and when you create a _semId from the shell it gets entered into vxWorks symbol table, but subsequently loading the module overwrites the symbol table entry for _semId. you may verify this by printing address of semId from the shell before and after the loading. [ i haven't tried this theory so i could be wrong, but at least that's the way i remember the way vxWorks loader worked ]. the result is that you're not doing the semTake on _semId you think you're using, and the new one probably contains 0 values for the counter so semTake just returns, and returns, and.... ~hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Intertask communication mechanisms Date: 30 Sep 92 05:29:36 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Sep30.052936.15428@afterlife.ncsc.mil> I'm exploring my alternatives for intertask communication among tasks on the same or other boards. I need: 1. High throughput. 2. Ordered delivery. 3. High reliability (but < 100% is potentially acceptable). 4. Multicasting (one sender, several receivers). Given that the only physical communications medium accessable to all of the processors is the backplane, it would seem that my alternatives are: 1. TCP on the backplane network. 2. UDP on the backplane network. 3. Some shared memory mechanism that I implement. 4. Some other (unknown to me) mechanism. My concerns are that: 1. TCP throughput is too low. 2. UDP throughput is too low and potentially too unreliable or unordered. 3. I have to write my own mechanism. 4. There is something better out there that I'm not aware of. Any suggestions, comments, or questions are welcomed. Thanks. - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Intertask communication mechanisms Date: Wed, 30 Sep 1992 08:58:25 GMT From: muts@fys.ruu.nl (Peter Mutsaers) Organization: Rijks Universiteit Utrecht Message-ID: References: <1992Sep30.052936.15428@afterlife.ncsc.mil> Sender: usenet@fys.ruu.nl (News Control) On 30 Sep 92 05:29:36 GMT, smb@afterlife.ncsc.mil (Steve M. Burinsky) said: SMB> 1. TCP throughput is too low. SMB> 2. UDP throughput is too low and potentially too unreliable or unordered. SMB> 3. I have to write my own mechanism. SMB> 4. There is something better out there that I'm not aware of. Why not simply use shared memory (assuming your VME board supports it) and use TCP sockets to tell that data is available to the other board. - -- _________________________________________________________________________ Peter Mutsaers. |================================================ muts@fys.ruu.nl | Quod licet bovi, non licet Jovi --------------------------- End of New-News digest ********************** From briggs@thalia.jpl.nasa.gov Wed Sep 30 08:19:15 1992 From: briggs@thalia.jpl.nasa.gov (Clark Briggs) Date: Wed Sep 30 08:19:23 PDT 1992 Subject: Intertask Communications Mechanisms Steve M. Burinsky writes, while looking for communications schemes: >My concerns are that: >1. TCP throughput is too low. >2. UDP throughput is too low and potentially too unreliable or unordered. But Steve gave no speed requirements. There are a lot of advantages to using TCP or UDP simply because they exist and are so flexible and transportable. Before taking 1 & 2 above as givens, consider your real speed needs vs development effort carefully. It has been my experience that TCP speeds (even over ethernet) are quite acceptible and if continuous transfer speed requirements are really that high, the overall system design and component load balancing must be done very carefully. I wont offer any firm speed figures, but I seem to remember discussion in here pointing out ethernet transfer speeds of 400K bytes (or bits? whats a factor of 8 anyway?). With care, backplane speeds should be substantially higher, but again I offer no figures for lack of memory. Remember, WRS firmly believes sockets, etc, can be slicked up to provide sufficient transfer speed for most applications, while maintaining standards. (I got this I believe from the last West Coast User Group Meeting.) Peter Mutsaers adds: >Why not simply use shared memory (assuming your VME board supports it) >and use TCP sockets to tell that data is available to the other board. I think that is an excellent compromise that avoids moving large amounts of data across the sockets. Clark Briggs briggs@csi.jpl.nasa.gov From dit@bach.jhuapl.edu Wed Sep 30 10:43:41 1992 From: dit@bach.jhuapl.edu (Daryl I. Tewell) Date: Wed Sep 30 10:43:49 PDT 1992 Subject: Re: bug with mutex semaphores Regarding: > I seem to be having a problem with mutual exclusion semaphores: they > don't seem to work at all!!!! For example, given the following code: > > - ------------------------------------------------------------------------------#include "vxWorks.h" > #include "semLib.h" > > SEM_ID semId; > > waitAndPrint () > { > extern SEM_ID semId; > > while (1) { > semTake (semId, WAIT_FOREVER); > printf ("got semId!\n"); > } > } > - ------------------------------------------------------------------------------ > I compile under 5.0.2 using cc68k: > > cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \ > -I/usr1/vw/h -c waitAndPrint.c > > Then in the VxWorks shell: > > - -> semId = semMCreate (1) (note: 1 = SEM_Q_PRIORITY) > semId = 0x33fdcec: value = 54264916 = 0x33c0454 > - -> ld < waitAndPrint.o > value = 0 = 0x0 > - -> semTake (semId, -1) (note: -1 = WAIT_FOREVER) > value = 0 = 0x0 > > By this point, the semId should be empty and anything that attempts to > take it should pend. So, I start up the waitAndPrint task: > > - -> waitAndPrint > got semId! > got semId! > got semId! > got semId! Here's my SWAG: When you assign semId before loading waitAndPrint.o, you are using an instance of semId that already exists in the symbol table (presumably from a previous load). If none had existed, you would have gotten the message: new symbol "semId" added to symbol table The subsequent load of waitAndPrint adds another instance of semId to the symbol table. The first instance of semId is the one accessed at the shell level (by virtue of its being the first instance found in the symbol table by the shell), and the second (or last) instance is the one accessed by waitAndPrint (because the access to semId by waitAndPrint need not be satisfied by a symbol table reference). Since the last instance of semId is never initialized, the semTake call in waitAndPrint returns ERROR (invalid semaphore id), which you do not check for. You can use a little defensive programming to test this theory, i.e. try checking for an ERROR return from semTake. If this is indeed the problem, then you must move your initial semCreate and semTake calls into waitAndPrint, where they will necessarily access the same semId variable. From mea@sparta.com Wed Sep 30 12:24:04 1992 From: mea@sparta.com (Mike Anderson) Date: Wed Sep 30 12:24:19 PDT 1992 Subject: Re: Intertask Communications Mechanisms Greetings! > > Steve M. Burinsky writes, while looking for communications schemes: > > >My concerns are that: > > >1. TCP throughput is too low. > >2. UDP throughput is too low and potentially too unreliable or unordered. > > But Steve gave no speed requirements. There are a lot of advantages to using > TCP or UDP simply because they exist and are so flexible and transportable. > Before taking 1 & 2 above as givens, consider your real speed needs vs > development effort carefully. It has been my experience that TCP speeds > (even over ethernet) are quite acceptible and if continuous transfer speed > requirements are really that high, the overall system design and component > load balancing must be done very carefully. > > Remember, WRS firmly believes sockets, etc, can be slicked up to provide > sufficient transfer speed for most applications, while maintaining standards. > (I got this I believe from the last West Coast User Group Meeting.) > > Peter Mutsaers adds: > >Why not simply use shared memory (assuming your VME board supports it) > >and use TCP sockets to tell that data is available to the other board. > I think that is an excellent compromise that avoids moving large amounts of > data across the sockets. I firmly agree with Clark and Peter. We can sustain > 4 MBPs (about 520 KBytes/Sec) between two SPARC 1+ class machines via Ethernet using our ARTSE(Tm) Datagram Protocol (reliable datagrams). Providing that there are no overly restrictive latency issues, sockets can be used to signal across the bus (using the backplane driver) to waiting tasks when memory blocks have been copied. A faster mechanism would be hardware interrupts or mailbox interrupts, but sockets can easily provide a simple, software only solution to interprocessor comms. I would tend to lean towards reliable datagrams over stream sockets simply because there is less CPU overhead associated with datagrams (i.e., your program doesn't have to poll the socket to read *all* of the data... its either there or its not). ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From mea@sparta.com Wed Sep 30 12:38:53 1992 From: mea@sparta.com (Mike Anderson) Date: Wed Sep 30 12:39:39 PDT 1992 Subject: Re: bug with mutex semaphores Greetings! > Submitted-by dit@bach.jhuapl.edu Wed Sep 30 10:43:41 1992 > Submitted-by: dit@bach.jhuapl.edu (Daryl I. Tewell) > > > Regarding: > > > I seem to be having a problem with mutual exclusion semaphores: they > > don't seem to work at all!!!! For example, given the following code: > > > > Here's my SWAG: > > When you assign semId before loading waitAndPrint.o, you are using an > instance of semId that already exists in the symbol table (presumably > from a previous load). If none had existed, you would have gotten the > message: > > new symbol "semId" added to symbol table > > The subsequent load of waitAndPrint adds another instance of semId to the > symbol table. The first instance of semId is the one accessed at the shell > level (by virtue of its being the first instance found in the symbol table > by the shell), and the second (or last) instance is the one accessed by > waitAndPrint (because the access to semId by waitAndPrint need not be > satisfied by a symbol table reference). Since the last instance of semId > is never initialized, the semTake call in waitAndPrint returns ERROR > (invalid semaphore id), which you do not check for. > Daryl is quite correct on this point, but there is one other thing to take into account. When you created the semId from the shell, you used: -> semId = semMCreate (1) This put a symbol into the symbol table by the name of "semId". However, the gcc compiler generated a symbol "_semId" as a result of the SEM_ID semId; declaration. When referencing variable from the shell, the shell will first try to find a variable that matches exactly what you typed in and if that fails, it then prepends an "_" and looks again before telling you it doesn't exist. Therefore, after you've created the the semId from the shell and then loaded the compiled code, you now have two variables in the symbol table namely, "semId" and "_semId" and both of them are distinct. Try to use lkup "semId" and you'll see what I mean. The bottom line is to be wary about creating variables from the shell that will be used by "C" code later. Always use the "_" when creating such variables to avoid confusion. Also, if you're doing things from the shell, use the extern SEM_ID semId; declaration and the _semId = semMCreate(1) shell command (create from the shell and THEN load the code) and the two references will use the same entry from the symbol table. I found out about this while teaching real-time programming courses to my customers. It was certainly mysterious the first time. Good Luck, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From umphreys@acet02.amil.co.il Wed Sep 30 17:38:08 1992 From: umphreys@acet02.amil.co.il (Ray Umphreys) Date: Wed Sep 30 17:38:16 PDT 1992 Subject: re: Newsgroups: comp.os.vxworks doctor@kronos.arc.nasa.gov (Terry Fong) writes: >I seem to be having a problem with mutual exclusion semaphores: they >don't seem to work at all!!!! For example, given the following code: > >- ------------------------------------------------------------------------------ >#include "vxWorks.h" >#include "semLib.h" > >SEM_ID semId; > >waitAndPrint () >{ > extern SEM_ID semId; > > while (1) { > semTake (semId, WAIT_FOREVER); > printf ("got semId!\n"); > } >} >- ------------------------------------------------------------------------------ > >I compile under 5.0.2 using cc68k: > > cc68k -O -fstrength-reduce -fcombine-regs -msoft-float -traditional \ > -I/usr1/vw/h -c waitAndPrint.c > >Then in the VxWorks shell: > >- -> semId = semMCreate (1) (note: 1 = SEM_Q_PRIORITY) >semId = 0x33fdcec: value = 54264916 = 0x33c0454 >- -> ld < waitAndPrint.o >value = 0 = 0x0 >- -> semTake (semId, -1) (note: -1 = WAIT_FOREVER) >value = 0 = 0x0 > >By this point, the semId should be empty and anything that attempts to >take it should pend. So, I start up the waitAndPrint task: > >- -> waitAndPrint >got semId! >got semId! >got semId! >got semId! >. >. >. >(Ctrl-C) > >As you can see, waitAndPrint NEVER pends. It ALWAYS is able to take >the semaphore. If I replace "semMCreate (1)" with "semBCreate (1, 1)" >(i.e., use a regular binary semaphore), everything works as expected >(i.e., waitAndPrint pends). So, am I doing something wrong? Or is >there a bug here? No, there is no bug. Mutual exclusion semaphores can be taken mutiple times by the SAME task ( and should be given the same number of times ). The take will block only if it is executed from another task. In your example both the semTake and the waitAndPrint are executed in the shell's task context. If you spawn waitAndPrint as a task, then it will block the way you want. From thor@thor.atd.ucar.edu Wed Sep 30 23:00:29 1992 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Wed Sep 30 23:00:37 PDT 1992 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 1637 -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 37126 Jun 12 13:31 ansilib01 -rw-r--r-- 1 thor 18913 Jun 12 13:31 ansilib02 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 9054 Jun 12 13:32 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 1991 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 41667 Feb 5 1992 ntpvx01 -rw-r--r-- 1 thor 38524 Feb 5 1992 ntpvx02 -rw-r--r-- 1 thor 41997 Feb 5 1992 ntpvx03 -rw-r--r-- 1 thor 39218 Feb 5 1992 ntpvx04 -rw-r--r-- 1 thor 39625 Feb 5 1992 ntpvx05 -rw-r--r-- 1 thor 28741 Feb 5 1992 ntpvx06 -rw-r--r-- 1 thor 32516 Feb 5 1992 ntpvx07 -rw-r--r-- 1 thor 37119 Feb 5 1992 ntpvx08 -rw-r--r-- 1 thor 41643 Feb 5 1992 ntpvx09 -rw-r--r-- 1 thor 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 1991 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 1991 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 19912 Aug 27 13:52 tp41.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor 4636 Feb 4 1992 vx_cplusplus -rw-r--r-- 1 thor 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 1992 wdog_class Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Mar 17 1992 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn.