From daemon@vxw.ee.lbl.gov Sat Oct 1 04:00:24 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Oct 1 04:00:31 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Oct 1 04:00:13 PDT 1994 Subject: rpc between 167 and sun Subject: Reminder - Archive is moving! Subject: Aborting spawned tasks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: rpc between 167 and sun Date: 30 Sep 1994 13:24:21 GMT From: rgi@se07.wg2.waii.com (Ram G. Iyer) Organization: Western Geophysical Exploration Products Message-ID: I am running VxWorks V5.1.1 on a MVME167 and also have a Sun S10 running 4.1.3. The problem that I am experiencing is with RPC (yeah, I know it's in the unsupported directory). I have the following function: static int xdr_ErrorXdr(xdrsp, errorxdrp) XDR *xdrsp; ErrorXdr *errorxdrp; { char *ptr; ptr = errorxdrp->error_string; if (!xdr_u_long(xdrsp, &errorxdrp->error_code)) return(0); /* encode/decode function failed */ if (!xdr_u_long(xdrsp, (u_long *)&errorxdrp->time_stamp)) return(0); if (!xdr_u_long(xdrsp, &errorxdrp->sequence_no)) return(0); if (!xdr_u_long(xdrsp, &errorxdrp->packet_sequence)) return(0); if (!xdr_string(xdrsp, &ptr, sizeof(errorxdrp->error_string))) return(0); return(1); } Similar code is used on the Sun side to encode/decode the data structure. I am expecting five unsigned longs. This works fine except when I try to pass a number like 0xffff0000. 0x7fff0000 gets passed just fine. When it does fail, I get errno == 22 as returned from the Sun. 22 is EINVAL which is invalid argument. Has anyone tried this and managed to get it to work. I appreciate any help I can get. Please respond to the newsgroup, since I DO read it. If you do send me direct email, I will post a summary of responses. Thanks - -- +----------------------------------------------------+ | Ram G. Iyer | email: (iyer@wg2.waii.com) | | Western Geophysical | phone: (713) 964-6236 | | 3600 Briarpark Drive | fax : (713) 781-7417 | | Houston, Texas 77042 | My opinions are just that. | +----------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Reminder - Archive is moving! Date: 30 Sep 1994 20:34:00 GMT From: thor@ymir.atd.ucar.edu (Rich Neitzel) Organization: National Center for Atmospheric Research Message-ID: <36hsno$5ja@ncar.ucar.edu> Sender: thor@ymir (Rich Neitzel) Remember that come Oct. 3 the ftp address for the VxWorks Archive will be: ftp.atd.ucar.edu and the path: /pub/vxworks At that time people trying the old address will get nothing more then a message pointing them to the new address. The email address is uneffected by this change. - -- Richard Neitzel thor@atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjx'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- Newsgroups: comp.os.vxworks Subject: Aborting spawned tasks Date: 30 Sep 1994 20:40:46 GMT From: elefant@u.washington.edu (David Smith) Organization: University of Washington, Seattle Message-ID: <36ht4e$59f@nntp1.u.washington.edu> Dear Net, I am attempting to implement a scheme for aborting spawned tasks when the only information I have been given is the task id. taskDelete () won't work because it doesn't clean up any malloced memory or open file descriptors, etc. An idea that I think might work is to set a flag in one of the "reservedN" or "spareN" fields in the WIND_TCB for the given task, and have the spawned task code periodically check that flag. Does anyone have any comments about the above idea or other ways of solving the problem? - -Thanks a lot. Dave - ------- daves@apl.washington.edu elefant@u.washington.edu --------------------------- End of New-News digest ********************** From dervis@venus.aselsan.com.tr Sun Oct 2 00:38:02 1994 From: Argun DERVIS Date: Sun Oct 2 00:38:09 PDT 1994 Subject: Support for Unix file system Greetings, Does anyone have a UNIX file system driver for VxWorks ? We would like to transfer large amount of data stored through a SCSI port of Force-3ce VME board, to an optical disk and then analyze the data on a Workstation running Solaris 1.x. In order to make such a transfer, we definitely need the UNIX file system driver. We know that, it could be writen under VxWorks, but we do not have that much time to do it on ourselves. Is there anyone who knows or written such a driver, we would like to pay for it. We welcome any third party software house for their suggestions. Please send the answers directly to me, Regards, Argun DERVIS ASELSAN Electronics Inc. Fax: 90-312-354 5205 Tel: 90-312-385 1900 / 2660 email: dervis@venus.aselsan.com.tr From mkrokosz@astro.ge.com Sun Oct 2 08:29:30 1994 From: Matthew Krokosz Date: Sun Oct 2 08:29:37 PDT 1994 Subject: Re: Aborting spawned tasks The method I have used for making a clean abort from a task is the following. First off, all my tasks have an entry point routine and a cleanup routine with the following syntax: tsk_Name_Task - entry point routine tsk_Name_Cleanup - cleanup routine When I spawn my task's, I spawn them with the following name: c_tsk_Name_Task I then have a DeleteHook routine which first checks to see if the task which is exiting has a "c_" prefixed to its task name. If it does, then it knows that it must have a corresponding cleanup routine. Knowing that, the DeleteHook routine will simply look up the symbol "tsk_Name_Cleanup" in the system symbol table. When it finds the address for that symbol, it simply invokes that routine which cleans up all memory, fd's, etc... I also have a variation that works well with spawning multiple instances of one task with task variables. ************************************************************************* | Matthew Krokosz email: mkrokosz@astro.ge.com | | Martin Marietta Astro Space phone: (609) 490-7194 | | Princeton, NJ | | | ************************************************************************* From daemon@vxw.ee.lbl.gov Mon Oct 3 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Mon Oct 3 04:00:31 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Oct 3 04:00:13 PDT 1994 Subject: A quick file descriptor question... Subject: Re: 3.5" SCSI-floppy drives... Where? Subject: Re: MC68360 QUADS board SIMMS Subject: Re: 3.5" SCSI-floppy drives... Where? Subject: Re: watch dog Subject: Driver, VMIVME-2511 digital I/O board wanted ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: A quick file descriptor question... Date: 2 Oct 1994 18:53:45 GMT From: jjwang@clark.net (Jason J Wang) Organization: Clark Internet Services, Inc., Ellicott City, MD USA Keywords: dup,fstat,stderr Message-ID: <36mvjp$4eo@clarknet.clark.net> Is it possible to create a file descriptor and set it to STDOUT. In Unix, one could just dup the stdout file descriptor. In a related question, is it possible to fstat the stdout fd? Thanks in advance! - -Jason --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 3.5" SCSI-floppy drives... Where? Date: Sun, 2 Oct 1994 20:21:44 +0000 From: anj@mail.ast.cam.ac.uk (Andrew Johnson) Organization: Royal Greenwich Observatory Message-ID: References: <9409280743.AA00420@rst.co.il> <36epaa$g13@news.cerf.net> In article <36epaa$g13@news.cerf.net> synergy@nic.cerf.net (John E. Clark) writes: >The problem here is that we get request for 'has IBM compatible >floppy capability'. Several times in my life I've written drivers >for that horrible Intel/Nec chip that was/is the standard floppy >interface. Maybe if there are better chips these days I could >see supporting the interface which could also do 8" floppies as well. >I really think this is the reason I feel so helpless in this >'best of all possible market driven worlds', because the markets I'm >in are not big enough for the giants to provide the best possible >product at any price. (The TEAC SCSI was notorious for wyrd revision >differences...but better than an OMTI). Have you tried using a Floptical drive? They are backwards compatible with a 3.5" IBM Floppy, and you also gain the 21Mb Floptical format. I know of Two manufacturers, Insite Peripherals (CA) and someone else whose name escapes me for the moment. We use the Insite drives, and although they can be a bit slow when they spin up from rest, they work just fine. - - Andrew ,_}\_. http://cast0.ast.cam.ac.uk/~anj/ / \ anj@mail.ast.cam.ac.uk ~~~~~~~~| ,--/;. )~~~~ _ _ ., |/ (/ U / \ ___ _| |_ _ ___ _ _ .`., /_\ . . | - | | . | ~_| -_| |~| | wwWWWww' |_|_|_|_|___|_| |___|_____| --------------------------- Newsgroups: comp.sys.m68k,comp.os.vxworks Subject: Re: MC68360 QUADS board SIMMS Date: Sun, 2 Oct 1994 20:12:46 GMT From: dana@wrs.com (Dana Burd) Organization: Wind River Systems, Inc. Message-ID: References: Sender: news@wrs.com (News Manager) >We want to upgrade the SIMM on the board, but are having trouble finding the >exact Motorola part listed in the manual. Has anyone tried other vendors? Is >this a standard PC-type SIMM. It appears that any 1M by 36 SIMM should work, >but I want to verify this. (We have a 1Meg SIMM and we want 4MB = 1M x 36) >Also, the bootprom from the VxWorks Board Support Package for that board appears to >autodetect the Motorola parts. Will it autodetect the other vendors as well? The BSP does, indeed, autodetect what SIMM size and speed you are using. I have successfully run our QUADS boards with 1, 4, and 8 Mbyte SIMMs. As far as which type SIMMs... well, I picked ones that had similar trace spacings and form factors, and they slid right in... I believe the ones I was using came out of a SPARCstation LX, but I am not sure. I have used Mitsubishi, Toshiba, and a "noname" brand. The Toshiba part number was THM361020S (80ns). Not sure about the Mitsubishi, put it has a stamp on the back that says "MH1M33SEJ-8 Japan 1465A01" Hope this helps, - -Dana +--------------------------------------------------------------+ | Dana Burd Wind River Systems, Inc. | | Software Development Engineer 1010 Atlantic Avenue | | dana@wrs.com Alameda, CA 94501 | +--------------------------------------------------------------+ --------------------------- Newsgroups: comp.periphs.scsi,comp.os.os9,comp.os.vxworks Subject: Re: 3.5" SCSI-floppy drives... Where? Date: 3 Oct 1994 04:04:33 GMT From: olson@anchor.engr.sgi.com (Dave Olson) Organization: Silicon Graphics, Inc. Mountain View, CA Message-ID: <36nvsh$9r2@gazette.engr.sgi.com> References: <1994Sep26.144939.29870@matrix.com> srm@matrix.com (Steve Morris) writes: | We had some trouble obtaining TEAC SCSI-floppy drives (FD-235HS). | (Is anyone else?) I'm almost positive that they are out of production. | Are there any other manufacturers of 3.5" floppy drives with a | SCSI interface? Sure; the floptical from Insite or IoMega (the bernoulli folks) does 720KB and 1.44MB as well as the floptical 21MB. Much easier to program and more reliable than the TEAC also, in my experience (and just about the same price). - -- The most beautiful things in the world are | Dave Olson those from which all excess weight has been | Silicon Graphics removed. -Henry Ford | olson@sgi.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: watch dog Date: Mon, 3 Oct 1994 04:38:52 GMT From: kent@wrs.com (Kent Long) Organization: Wind River Systems, Inc. Message-ID: References: <9409232316.AA08602@tcville.ES.HAC.COM> Sender: news@wrs.com (News Manager) In article toma@tc.fluke.COM (Tom Anderson) writes: > >>Note the following from the VxWorks documentation: > >>1. In VxWorks, the timer must be explicitly cancelled, or the timeout routine >> will be invoked, even if the task which started the watchdog timer is >> running, suspended or deleted. > >As I interpret its mangled syntax, the point of the above sentence is >that the timeout routine will be invoked regardless of the state of the >task which started the watchdog (if indeed the watchdog was started by >a task at all), unless the timer is cancelled before it expires. This >does not imply any requirement to cancel watchdog timers after they >have expired, or in the expiration callback itself. > >If someone at Wind River is reading this, perhaps they will be kind enough >to either confirm or deny my interpretation (and maybe clarify stuff like this >in the manual). Yes, you are right in your interpretation, and also in your suggestion that this be made clearer. Watchdogs exist independently from the task which created them, and therefore must be cancelled explicitly even if the the invoking task has since exited/suspended/etc. This section of the documentation will get some attention in an upcoming maintenance release. I hope that things will be more plainly stated then. - kent Kent Long Wind River Systems kent@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: Driver, VMIVME-2511 digital I/O board wanted Date: Mon, 3 Oct 1994 06:23:32 GMT From: stewl@mame.mu.OZ.AU (Stuart Lucas) Organization: Computer Science, University of Melbourne, Australia Keywords: 2511, parallel I/O Message-ID: Sender: news@cs.mu.OZ.AU HI there.. I was wondering if anybody knew of (or has ) a vxworks device driver for the VMIVME-2511 48-bit digital parrallel input/output board, made by VME Microsystems International Corporation. Thanking you in advance Stuart Lucas - -- Stuart Lucas Robotics & Design Group Department of Mechanical & Manufacturing Engineering Ph.: (03) 344 6680 University of Melbourne, Victoria Melbourne. Fax.: (03) 347 8784 Email: stuart@spike.mame.mu.OZ.AU Ah: (03) 571 2878 --------------------------- End of New-News digest ********************** From dervis@venus.aselsan.com.tr Mon Oct 3 07:22:03 1994 From: Argun DERVIS Date: Mon Oct 3 07:22:10 PDT 1994 Subject: Support for Green Spring IP-488 driver Greetings, Does anyone have an IP-488 software driver for Green Spring Industry Pack products? We would like to share any C source code that can program the TI GPIB controller that is found on the IP-488 product ? Please send the answers directly to me, Regards, Argun DERVIS ASELSAN Electronics Inc. Fax: 90-312-354 5205 Tel: 90-312-385 1900 / 2660 email: dervis@venus.aselsan.com.tr From DNEELAY@fwbsmtp.ftwa.tasc.com Mon Oct 3 11:37:36 1994 From: DNEELAY@fwbsmtp.ftwa.tasc.com Date: Mon Oct 3 11:37:50 PDT 1994 Subject: Re: SCSI Floppy Hi everyone: We purchased a TEAC SCSI floppy drive from ACT Technico... it cost us about 250.00 and the integration was straight forward. It gave us the capability to back and forth from the VME system to a PC/Sun. If anyone is intrested in purchasing it they should call Lee Raguz at ACTTechnico (lee@acttechnico.com). Happy SystemIntegration- Dinesh internet:dneelay@tasc.com From daemon@vxw.ee.lbl.gov Tue Oct 4 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Oct 4 04:00:33 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Oct 4 04:00:14 PDT 1994 Subject: RARP Subject: ARP ? Subject: Re: Aborting spawned tasks Subject: Re: 3.5" SCSI-floppy drives... Where? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: RARP Date: Mon, 3 Oct 1994 11:15:57 GMT From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera) Organization: International Computers Limited Message-ID: Reply-To: rsgawera@ss11.wg.icl.co.uk Sender: news@oasis.icl.co.uk Dear All, Does anyone know where I can get hold of an RARP daemon to run on VxWorks ? Alternatively, can the VxWorks PROXY ARP be used without a shared memory network ie I have a board with 2 interfaces, ethernet and a proprietry net. Can I use PROXY ARP across both interfaces ? cheers, Raj Raj Gawera Designer ICL CSD email : rsgawera@wg.icl.co.uk --------------------------- Newsgroups: comp.os.vxworks Subject: ARP ? Date: Mon, 3 Oct 1994 19:25:48 GMT From: jprice@lds.loral.com (Jeffrey Price, 6823) Organization: LORAL Data Systems Keywords: ARP Message-ID: <1994Oct3.192548.22193@lds.loral.com> Reply-To: jprice@lds.loral.com Sender: news@lds.loral.com Hello : I am building an application in which I want the unix host to direct ALL pkts to any IP address to the same target. There are several ways I can think of to do this. I am interested in y'alls opinions on which is the best in terms of ease and efficiency . 1. Have the Unix Host update its ARP table via (arp command) to reflect that all IP addresses map to same target ethernet address. This requires a manual (or programatic action). A more automated and hence generic approach may be to : 2. Have ARP code on target respond to all ARP requests with its own ethernet address. Is this possible, and if so how. 3. Use input hooks and reply to ARP requests myself I have installed an etherInputHook(). I guess this could catch the ARP requests and then issue a ARP response with etherOutput(). Can someone tell me what is or where to find the exact strucutre of an ARP message so that I could parse it when I received it in the input hook ? Other ideas or comments ? Thanks for the help, Jeff Price --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Aborting spawned tasks Date: Tue, 4 Oct 1994 07:30:18 GMT From: gadi@teleop.co.il (Gadi Friedman) Organization: TeleOp Communication Industries, Ltd. Message-ID: References: <36ht4e$59f@nntp1.u.washington.edu> Sender: news@wang.com In article <36ht4e$59f@nntp1.u.washington.edu> elefant@u.washington.edu (David Smith) writes: >Dear Net, > >I am attempting to implement a scheme for aborting spawned tasks when >the only information I have been given is the task id. taskDelete () >won't work because it doesn't clean up any malloced memory or open file >descriptors, etc. How about using signals? (Like in unix). You can send the task a signal, and have it clean itself up, and exit. Gadi --------------------------- Newsgroups: comp.periphs.scsi,comp.os.os9,comp.os.vxworks Subject: Re: 3.5" SCSI-floppy drives... Where? Date: Tue, 4 Oct 1994 09:38:14 GMT From: basl@inter.NL.net (Bas Laarhoven) Organization: NLnet Message-ID: References: <1994Sep26.144939.29870@matrix.com> <36nvsh$9r2@gazette.engr.sgi.com> olson@anchor.engr.sgi.com (Dave Olson) writes: >srm@matrix.com (Steve Morris) writes: >| We had some trouble obtaining TEAC SCSI-floppy drives (FD-235HS). >| (Is anyone else?) >I'm almost positive that they are out of production. The FD-235HS is replaced by a new, smaller version with integrated SCSI controller: FD-05HGS-600. It's SCSI controller FC-5 is almost :( compatible with the FC-1-10 (European) controller on the FD-235HS. >| Are there any other manufacturers of 3.5" floppy drives with a >| SCSI interface? >Sure; the floptical from Insite or IoMega (the bernoulli folks) does >720KB and 1.44MB as well as the floptical 21MB. Much easier to program >and more reliable than the TEAC also, in my experience (and just about >the same price). Interesting, how do you get them that cheap ? In our experience the Floptical drives require special software, are less robust, and are twice as expensive as the Teac drives ! (On the other hand they are twice as fast too because of the doubled rotation speed). Bas Laarhoven >-- >The most beautiful things in the world are | Dave Olson >those from which all excess weight has been | Silicon Graphics >removed. -Henry Ford | olson@sgi.com --------------------------- End of New-News digest ********************** From del@rst.com Tue Oct 4 07:42:56 1994 From: del@rst.com (Mark Del Giorno) Date: Tue Oct 4 07:43:02 PDT 1994 Subject: SCSI Drive Bandwagon - How easy is it? Heyyyyyyyyyyyyyyy, I've got a MVME162 w/SCSI and can get my hands on a Teac SCSCI 3.5" floppy. I've been looking for an easy way to capture a bunch of data and store it for later analysis. The question is: How much effort is involved in writing the software to flush the data buffers to a file on the floppy? (does the floppy have to be pre-formatted? are the routines already written and working with "standard" vxWorks?) Does anyone have a simple piece of code that shows how this is easily done? Thanks in advance! _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) _/ _/ _/ _/ (410) 876-9200 Fax: 876-9470 _/_/_/_/ _/_/_/_/ _/ Robotic Systems Technology _/ _/ _/ _/ 1110 Business Parkway South _/ _/ _/_/_/_/ _/ Westminster, MD 21157 From johnb@imatron.com Tue Oct 4 09:09:05 1994 From: John Bressler Date: Tue Oct 4 09:09:11 PDT 1994 Subject: subscribe subscribe From eli@radmail.rad.co.il Tue Oct 4 10:46:00 1994 From: "eli herskovitz" Date: Tue Oct 4 10:46:07 PDT 1994 Subject: VxWorks on Pentium-PCI Ethernet NICs driver? Hi fox We are currently looking for the "best" platform and OS. Does anyone know if there is somewhere a VxWorks running on Intel Pentium? Optimized for Pentium? Do you know of a driver written for any PCI Ethernet controller? Are there development tools on a PC? (e.g. compiler, debugger) and did anyone work with the PC as a development host? I am new in this neighborhood, so please excuse me if my questions are out of ... Thanks in advance Iris Tal eli@radmail.rad.co.il From daemon@vxw.ee.lbl.gov Wed Oct 5 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Oct 5 04:00:34 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Oct 5 04:00:13 PDT 1994 Subject: Re: 3.5" SCSI-floppy drives... Where? Subject: Software applications engineer position / Portland OR metro area Subject: Re: 3.5" SCSI-floppy drives... Where? Subject: Re: Sharing code with task specific data Subject: Re: 3.5" SCSI-floppy drives... Where? Subject: SDLC serial protocol for VxWorks ------------------------------------------------------- Newsgroups: comp.periphs.scsi,comp.os.os9,comp.os.vxworks Subject: Re: 3.5" SCSI-floppy drives... Where? Date: 4 Oct 1994 08:37:20 -0400 From: schuster@panix.com (Michael Schuster) Organization: PANIX Public Access Internet and Unix, NYC Message-ID: <36ria0$lsa@panix3.panix.com> References: <1994Sep26.144939.29870@matrix.com> <36nvsh$9r2@gazette.engr.sgi.com> In article , Bas Laarhoven wrote: > >In our experience the Floptical drives require special software, >are less robust, and are twice as expensive as the Teac drives ! >(On the other hand they are twice as fast too because of the doubled >rotation speed). Here in the Us I've seen several places selling the Bernoulli flopticals at very deep "closeout" prices. I think they are abandoning this market. - -- Mike Schuster | schuster@panix.com | 70346.1745@CompuServe.COM - ------------------- | schuster@shell.portal.com | GEnie: MSCHUSTER --------------------------- Newsgroups: comp.software-eng,comp.os.vxworks,misc.jobs.offered Subject: Software applications engineer position / Portland OR metro area Date: 29 Sep 94 18:05:11 GMT From: recruit@crl.labs.tek.com (Recruiting Officer) Organization: Tektronix Inc., Beaverton, Or. Message-ID: <6709@crl.labs.tek.com> Followup-To: poster Please consider this opportunity to work in a challenging software engineering position in the beautiful Pacific Northwest ... Job Title: APPLICATIONS ENGINEER IV (MULTI-LEVEL) Organization: TEKTRONIX LABORATORIES Location: Beaverton Shift: Day Job Duties: Port, maintain, enhance, and tailor the GNU C/C++ compiler and debugger to Tektronix host- and cross-development environments. Be the corporation- wide support expert for compiler/debugger tools, including "cloner" and emulator extensions, on multiple host and target platforms. Provide backup support for VxWorks (embedded operating system). Investigate future advances in software development tools. Investigate computer aided software engineering (CASE) tools. Develop and deliver training for various tooling offerings. Skills/Compentencies Required: BSCS or BSEE required; MSCS or MSEE strongly preferred. Strong emphasis in software engineering technologies preferred. Excellent oral and written communication skills required. Excellent troubleshooting and problem- resolution skills required. Excellent teamwork and self-motivational skills required. Ability and willingness to simultaneously perform both extremely complicated technical work and routine work required. C programming experience required; C++ programming experience strongly preferred. Background/coursework about compilers and debuggers required; experience with the GNU compiler and debugger strongly preferred. Background/coursework about real-time operating systems required; experience in supporting and/or developing real-time operating systems preferred; experience with supporting and/or developing with VxWorks strongly preferred. Background/coursework about software configuration management systems required; experience with Atria ClearCase strongly preferred. Background in computer-aided software engineering (CASE) tools preferred. Applicants with fewer qualifications will be considered to fill the position at a lower level. Tektronix supports a drug-free work environment, and all employment offers are contingent upon successful completion of our pre-employment drug test. Tektronix is an equal opportunity/affirmative action employer and encourages diversity in the workplace. Application Procedure: To express your interest in this position, please reply to this posting (or send e-mail to recruit@dtl.labs.tek.com) and include an ASCII or postscript copy of your resume. E-mail submissions will be accepted *ONLY* between Sept. 29, 1994 and Oct. 13, 1994. Principals only please! --------------------------- Newsgroups: comp.periphs.scsi,comp.os.os9,comp.os.vxworks Subject: Re: 3.5" SCSI-floppy drives... Where? Date: 4 Oct 1994 17:59:45 GMT From: bdhp8uc@uxa.ecn.bgu.edu (Andrew Jackson) Organization: Educational Computing Network Message-ID: <36s56h$t7u@news.ecn.bgu.edu> References: <1994Sep26.144939.29870@matrix.com> <36nvsh$9r2@gazette.engr.sgi.com> <36ria0$lsa@panix3.panix.com> Followup-To: comp.periphs.scsi,comp.os.os9,comp.os.vxworks Michael Schuster (schuster@panix.com) wrote: : In article , Bas Laarhoven wrote: : > : >In our experience the Floptical drives require special software, : >are less robust, and are twice as expensive as the Teac drives ! : >(On the other hand they are twice as fast too because of the doubled : >rotation speed). We can provide as many of the FD-235HS711 and FD-235JS606 as you may need. We have experienced no shortages and can fill orders of 100 or more. Andrew Jackson Computer Subsystems Unlimited (312) 221-9205 voice a-jackson2@bgu.edu --------------------------- Newsgroups: comp.os.vxworks,comp.realtime Subject: Re: Sharing code with task specific data Date: 4 Oct 1994 18:58:08 GMT From: sblachma@aoc.nrao.edu (Steve Blachman) Organization: National Radio Astronomy Observatory, Socorro NM Message-ID: <36s8k0$29t@chaos.aoc.nrao.edu> References: Reply-To: sblachma@aoc.nrao.edu In article FvI@netcom.com, bagpiper@netcom.com (Michael Hunter) writes: > Can you explain this a little farther. I usu. hear good > things about VxWorks as a non-hosted embedded OS, but the lack of > shared code support sounds like a real lack. VxWorks has excellent shared code support. We routinely run with dozens of instances of the same task (and code) running together. There are also lots of shared support functions. As I understood the original poster, they want to have separate data areas for each task, but a malloc for this type of storage was not adequate, I did not understand why. Global data shared between tasks is also easy, so is private data for each task. If they need global data NOT shared between tasks, then they could have a linked list of pointers to malloced storage. VxWorks has nice linked list support. Steven Blachman --------------------------- Newsgroups: comp.os.os9,comp.os.vxworks,comp.periphs.scsi Subject: Re: 3.5" SCSI-floppy drives... Where? Date: Tue, 4 Oct 1994 16:05:15 -0500 From: "Ingo Cyliax" Organization: Computer Science, Indiana University Message-ID: <1994Oct4.160525.22463@news.cs.indiana.edu> References: <1994Sep26.144939.29870@matrix.com> <36nvsh$9r2@gazette.engr.sgi.com> In article <36nvsh$9r2@gazette.engr.sgi.com>, Dave Olson wrote: >srm@matrix.com (Steve Morris) writes: >| We had some trouble obtaining TEAC SCSI-floppy drives (FD-235HS). >| (Is anyone else?) Yes, I have 6 on back order for 3 months now. I don't think I'll ever see them. >I'm almost positive that they are out of production. I think you are right, the last batch I received were manufactured a while ago and have been stocked for at least a year. >| Are there any other manufacturers of 3.5" floppy drives with a >| SCSI interface? >Sure; the floptical from Insite or IoMega (the bernoulli folks) does >720KB and 1.44MB as well as the floptical 21MB. Much easier to program >and more reliable than the TEAC also, in my experience (and just about >the same price). Do they handle 360rpm spindle speed, I have an application that requires that. Anyway, do you have a reliable vendor ? See ya, -ingo - -- /* Ingo Cyliax, cyliax@cs.indiana.edu, +1 812 333 4854, +1 812 855 6984 (day) */ --------------------------- Newsgroups: comp.os.vxworks Subject: SDLC serial protocol for VxWorks Date: 4 Oct 1994 13:55:13 -0700 From: rls@ltis.loral.com (Randy Silagi) Organization: Loral Test And Information Systems Keywords: SDLC Message-ID: Does anyone know where I could get an implementation of SDLC for VxWorks? I need SDLC, so I will consider all possible alternatives, SDLC source code for any operating system, buying someones port of SDCL to vxWorks, buying SDLC and porting it to vxWorks, or ... Please let my know if you have any ideas. +------------------------------------------------------------------+ | Randy Silagi E-Mail: rls@ltis.loral.com | Loral Test & Information Systems | 15378 Avenue of Science Phone: 619-674-5100, X4798 | San Diego, CA 92128-3407 Fax: 619-674-5145 +-------------------------------------------------------------------+ --------------------------- End of New-News digest ********************** From rcb0135@lxe6.lxe.com Wed Oct 5 05:46:27 1994 From: rcb0135@lxe6.lxe.com (Robert Barbrow) Date: Wed Oct 5 05:46:35 PDT 1994 Subject: RE: SDLC serial protocol for VxWorks < Does anyone know where I could get an implementation of SDLC < for VxWorks? I need SDLC, so I will consider all possible < alternatives, SDLC source code for any operating system, buying < someones port of SDCL to vxWorks, buying SDLC and porting it to < vxWorks, or ... < < Please let my know if you have any ideas. Hi Randy, You might want to look at the 4.4BSD-Lite source code tree. It contians some HDLC, X.25 source that may be helpful to you. You can find the source at many sites here is one of them: ftp.cdrom.com (wcarchive.cdrom.com) in "/.6/bsd-sources/4.4BSD-Lite/usr/src/sys/netccitt" The directory list is: -rw-r--r-- 1 root man 885 Aug 16 08:34 .desc.txt -rw-r--r-- 1 root man 885 Aug 16 08:34 00index.txt -r--r--r-- 1 bin man 2000 Jun 11 1993 README.hdlc -r--r--r-- 1 bin man 955 Jun 11 1993 README.packet -r--r--r-- 1 bin man 3263 Jun 11 1993 ccitt_proto.c -r--r--r-- 1 bin man 3370 Jun 11 1993 dll.h -r--r--r-- 1 bin man 5734 Jun 11 1993 hd_debug.c -r--r--r-- 1 bin man 17569 Jun 11 1993 hd_input.c -r--r--r-- 1 bin man 7122 Jun 11 1993 hd_output.c -r--r--r-- 1 bin man 9274 Jun 11 1993 hd_subr.c -r--r--r-- 1 bin man 4333 Jun 11 1993 hd_timer.c -r--r--r-- 1 bin man 3855 Jun 11 1993 hd_var.h -r--r--r-- 1 bin man 4780 Jun 11 1993 hdlc.h -r--r--r-- 1 bin man 20293 Jun 11 1993 if_x25subr.c -r--r--r-- 1 bin man 13187 Jun 11 1993 llc_input.c -r--r--r-- 1 bin man 9125 Jun 11 1993 llc_output.c -r--r--r-- 1 bin man 68237 Jun 11 1993 llc_subr.c -r--r--r-- 1 bin man 5550 Jun 11 1993 llc_timer.c -r--r--r-- 1 bin man 24360 Jun 11 1993 llc_var.h -r--r--r-- 1 bin man 6581 Jun 11 1993 pk.h -r--r--r-- 1 bin man 4401 Jun 11 1993 pk_acct.c -r--r--r-- 1 bin man 4500 Jun 11 1993 pk_debug.c -r--r--r-- 1 bin man 30088 Jun 11 1993 pk_input.c -r--r--r-- 1 bin man 10949 Jun 11 1993 pk_llcsubr.c -r--r--r-- 1 bin man 6344 Jun 11 1993 pk_output.c -r--r--r-- 1 bin man 29519 Jun 11 1993 pk_subr.c -r--r--r-- 1 bin man 4356 Jun 11 1993 pk_timer.c -r--r--r-- 1 bin man 15990 Jun 11 1993 pk_usrreq.c -r--r--r-- 1 bin man 9147 Jun 11 1993 pk_var.h lrwxrwxr-x 1 root wheel 16 Jun 29 09:28 tags -> /var/db/sys_tags -r--r--r-- 1 bin man 6282 Jun 11 1993 x25.h lrwxrwxr-x 1 root wheel 5 Jun 29 09:28 x25_sockaddr.h -> x25.h -r--r--r-- 1 bin man 2979 Jun 11 1993 x25acct.h -r--r--r-- 1 bin man 3026 Jun 11 1993 x25err.h Don't know how complete/incomplete this code is but just happened to notice it the other day while looking through a text book. -------------------------------------------------------------------------- Robert Barbrow Voice: (404)447-4224 ex.3365 Project Engineer LXE Inc. FAX: (404)447-6928 125 Technology Parkway e-mail: rcb0135@lxe6.lxe.com (work) Norcross, GA. 30092 robert@crl.com (home) From server@wrs.com Wed Oct 5 15:08:27 1994 From: Tech Support Mail Server Date: Wed Oct 5 15:08:34 PDT 1994 Subject: The Wind River SPR List !!!! VXWORKS 5.1.x SPR LIST ====================== Wind River Systems Technical Support is pleased to announce the availability of the new SPR list to all of our VxWorks customers. We are also launching the Technical Support Email Server through which you will be able to obtain this and other documents from tech support, such as information on VxWorks training classes and technical notes. The list can be obtained by sending email to server@wrs.com with "sprlist" anywhere in the subject line of the mail (no body of the mail required). For information on other available documents, also include the word "help" in the subject. For example, if you include: Subject: wtn09sprlisttraining you will receive Wind Technote 9, the SPR list and training information. (Please note: only VxWorks customer's can receive the SPR list). Please submit all other technical support requests to Wind River Technical Support by email to support@wrs.com, or call 800-872-4977. Wind River Systems, Technical Support. From daemon@vxw.ee.lbl.gov Thu Oct 6 04:00:24 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Oct 6 04:00:33 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Oct 6 04:00:13 PDT 1994 Subject: VxWorks books? Subject: getting child's task id at exit time Subject: CFP: ACM SIGPLAN Languages, Compilers & Tools for Real-Time Systems Subject: Many CPUs and Many LORAL 1553 cards ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks books? Date: 5 Oct 1994 20:28:10 GMT From: minakami@Xenon.Stanford.EDU (Michael K. Minakami) Organization: Computer Science Department, Stanford University. Message-ID: <36v28q$l91@Times.Stanford.EDU> I'm looking for some good introductory material to VxWorks. Also anything that would allow a comparison with pSOS or OS-9 for an embedded controller. Thanks, MikeM - -- - ------------------------------------------------------------------------------ Michael Minakami, On Command Video Ph: (408) 986-4650 Sr. Software Engineer - Digital Servers Fax: (408) 496-0668 "A time and place for everything under the sun" --------------------------- Newsgroups: comp.os.vxworks Subject: getting child's task id at exit time Date: 6 Oct 94 01:44:45 GMT From: jens@Xenon.Stanford.EDU (Jens Christensen) Organization: Stanford University: Computer Science Department Message-ID: Under VxWorks, when task deletion hooks get called taskIdSelf() seems to return the taskid of the parent, and not of the child task that is exiting and on whose behalf cleanup should be done. Is there any way of obtaining the task id of the exiting task? Thanks, Jens --------------------------- Newsgroups: comp.os.qnx,comp.os.lynx,comp.os.vxworks Subject: CFP: ACM SIGPLAN Languages, Compilers & Tools for Real-Time Systems Date: 5 Oct 1994 22:29:28 -0400 From: rich@cs.umd.edu (Richard Gerber) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Message-ID: <36vne8$eqo@coltrane.cs.umd.edu> ****************************************************************************** CALL FOR PAPERS ACM SIGPLAN Workshop on Languages, Compilers and Tools for Real-Time Systems (In Conjunction with ACM SIGPLAN PLDI/PEPM) La Jolla, California June 21-22, 1995 ACM SIGPLAN LCT-RTS '95 is an interface between two dynamic fields of computer science and engineering: programming languages and real-time systems. The time is right for this workshop: top researchers in these areas are addressing many similar problems, but with slightly different perspectives and technologies. LCT-RTS provides a forum where these researchers can share their results and directions, and where they can potentially form new collaborations based on common interests. MOTIVATION: Until recently real-time systems development was the province of experienced specialists, who were trained to deal both at very high and low levels of abstraction. Programmers were faced with a variety of custom kernels, non-standard languages and vendor-specific device interfaces. System integration inevitably involved a complicated process of taking timing measurements, hand-tuning the code, and then re-measuring. These ad-hoc techniques have not scaled to support modern systems, which often possess multiple, complex, interacting components. There is a growing desire to adopt advanced design strategies, standard kernels, reusable modules, generic languages and the like. Also, the majority of real-time developers is longer drawn from the ranks of embedded controls experts; rather, it is composed of animators, physicists, video producers, musicians, medical technicians, automotive engineers, manufacturing engineers, etc. New software approaches are necessary to support these new systems, and this new generation of real-time programmers. THE WORKSHOP: ACM SIGPLAN LCT-RTS '95 is devoted to investigating software technologies for contemporary real-time systems. This is the second LCT-RTS workshop; last year's meeting showed that there is significant interest in this area. Original submissions are invited in all areas relevant to this theme, including (but not restricted to) the following list of topics: * Programming Languages for Real-Time: Industrial and Research * Design: Requirements, System Specification, Analysis * Exception Handling: Semantics, Policies, Mechanisms * Prototyping Languages * Timing Analysis: Static and Dynamic Approaches * Scheduling Analysis * Realtime on RISC: Caches, Register Windows, Pipelines * Realtime Memory Management and Garbage Collection * Support for Parallelism and Data Placement * Program Transformation and Optimization for Real-Time Performance * Profiling, Measurement and Debugging * System Integration and Testing Of particular interest are case studies, or experimental results based on application-building experiences; for example in interactive graphics, imaging, manufacturing, etc. Papers should report new research, and should not exceed 5000 words (approximately 10 pages typeset 10-point on 16-point spacing, or 15 typewritten double-spaced pages). Short papers are also welcomed, which describe existing implementations, work-in-progress, or new problems and important issues. Short papers should not exceed 3000 words (6 pages). All accepted papers will be presented at the workshop and published in the proceedings. SUBMISSION: Please submit seven (7) copies of papers, to: ACM SIGPLAN LCT-RTS Attn: Richard Gerber Department of Computer Science University of Maryland College Park, MD 20742 USA Papers will be reviewed the program committee for appropriateness of content and presentation. Proceedings will be distributed at the workshop. IMPORTANT DATES Submission of draft paper: 23 January 1995 Notification of acceptance: 22 March 1995 Final version due: 15 May 1995 PROGRAM COMMITTEE Alan Burns (University of York) Richard Gerber, Co-Chair (University of Maryland) Rajiv Gupta (Univ of Pittsburgh) Mary Hall (Caltech) Connie Heitmeyer (Naval Research Lab) Insup Lee (University of Pennsylvania) Al Mok (University of Texas at Austin) Thomas Marlowe, Co-Chair (Seton Hall University, NJIT RTCL) Steve Tjiang (Synopsys Inc.) PROGRAM CO-CHAIRS Richard Gerber Thomas Marlowe Department of Computer Science Department of Mathematics University of Maryland Seton Hall University College Park, MD 20742, USA South Orange NJ 07079, USA telephone: +1 301 405 2710 telephone: +1 201 761 9784 fax: +1 301 405 6707 fax: +1 201 761 9596 rich@cs.umd.edu marlowe@cs.rutgers.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Many CPUs and Many LORAL 1553 cards Date: 6 Oct 1994 12:56:03 +1000 From: dmr@hercules.iassf.easams.com.au (Dewan RASHID) Organization: EASAMS (Australia) Pty Ltd Message-ID: <36vp03$6ma@hercules.iassf.easams.com.au> Hi VxWorks and MUX BUS People: I am running three mvme-167 processors with couple of LORAL 1553 cards on the same back plane (under vxWorks environment). Now I am trying to do the following things. 1. One CPU and multiple 1553 cards: Run Bus Controller (BC) in one 1553 card, Remote Terminals (RTs) in another 1553 card and Bus Monitor (BM) in yet another 1553 card. 2. Multiple CPU and one 1553 card: Run BC from CPU0 in a 1553 card, run RTs from CPU1 and run BM from CPU2 in the same 1553 card. The other option (assign one CPU per 1553 card) is easy to do. The problem has arisen because the LORAL driver does have a set of global variables to keep track of the resources in the 1553 card. For each specific card this set of global variables differ. So my questions are: 1. Is there any one who have solved these problems before? 2. If so, can I share some experiences? Looking forward for some suggestions, insights or a piece of code that can help me. Many thanks, Dewan RASHID. ============================================================================ Dewan M. Rashid | dmr@iassf.easams.com.au | EASAMS Australia (Ltd) | 61-2-367-4575 |Experience is what you get GEC Marconi Systems. | |just after you needed it. | | ============================================================================ --------------------------- End of New-News digest ********************** From mkrokosz@astro.ge.com Thu Oct 6 06:47:28 1994 From: Matthew Krokosz Date: Thu Oct 6 06:47:35 PDT 1994 Subject: Re: getting child's task id at exit time When a task delete hook routine is called, vxworks passes it a pointer to the exiting tasks WIND_TCB, which is the task control block. The WIND_TCB structure contains the task id. Take a look at the structure, I think it is in taskLib.h. ************************************************************************* | Matthew Krokosz email: mkrokosz@astro.ge.com | | Martin Marietta Astro Space phone: (609) 490-7194 | | Princeton, NJ | ************************************************************************* From Hugh.C.Briggs@jpl.nasa.gov Thu Oct 6 16:00:05 1994 From: Hugh.C.Briggs@jpl.nasa.gov Date: Thu Oct 6 16:00:12 PDT 1994 Subject: a question about semaphores. ---------------------------- Forwarded with Changes --------------------------- From: cbenson@cmipss2.retix.com at Internet Date: 10/6/94 12:22PM *To: at Internet Subject: a question about semaphores. ------------------------------------------------------------------------------- the following was on the psos users mail distribution system. im not interested so much in the psos answer, but the vxworks answer. I do hope my knee-jerk action to "just ask the net" doesnt waste your time. clark briggs Hugh.C.Briggs@jpl.nasa.gov _______________________________________________________________________________ Subject: a question about semaphores. From: cbenson@cmipss2.retix.com at Internet Date: 10/6/94 12:22 PM Message From: psosuser@isi.com at Internet Hi there, When a semaphore is created with sm_create, the returned values include a semaphore id. If the semaphore is later removed with sm_delete is it possible for another semaphore to be create with the same semaphore id or is it guaranteed unique for the life of the system (or until some enormous counter goes around the clock whichever comes first)? thanks -colin From nps@radstone.co.uk Fri Oct 7 01:28:14 1994 From: nps@radstone.co.uk (Nigel P Street) Date: Fri Oct 7 01:28:22 PDT 1994 Subject: Re: a question about semaphores. > ------------------------------------------------------------------------------- > the following was on the psos users mail distribution system. im not interested > so > much in the psos answer, but the vxworks answer. > > When a semaphore is created with sm_create, the returned values > include a semaphore id. If the semaphore is later removed with > sm_delete is it possible for another semaphore to be create with the > same semaphore id or is it guaranteed unique for the life of the > system (or until some enormous counter goes around the clock whichever > comes first)? When a semaphore is created using VxWorks (using semCreate) a data structure is allocated (using 'malloc') and this is used to hold details of the semaphore during its existence. The type allocated is 'struct semaphore' and is defined in /vw/h/semLib.h for pre-5.1 VxWorks and /vw/h/private/semLibP.h for 5.1 and later. The SEM_ID returned is merely the address of this allocated store (i.e. the SEM_ID is a pointer to an instance of the semaphore structure). Any operation on that semaphore can than be quickly actioned by 'following' the semaphore ID. When the semaphore is deleted, the memory area used to hold the semaphore data structure is freed off making it available for re-allocation. The semaphore ID must *not* be used after the semaphore has been deleted as that memory area may have been re-allocated for another use - if it is used corruption may result! The advantage of using a pointer as the semaphore ID is speed of access and (with a reliable malloc function) guaranteed uniqueness. Using a clock value as the ID would give neither of these things. Hope that helps, Nige St. ------------------------------------------------------------------------------ | Nigel P Street C Eng Radstone Technology PLC | | Principal Engineer Water Lane | | Towcester voice - 01327 359444 | | work - nps@radstone.co.uk Northants fax - 01327 358112 | | home - nige@zagota.demon.co.uk NN12 7JN | ------------------------------------------------------------------------------ From daemon@vxw.ee.lbl.gov Fri Oct 7 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Oct 7 04:00:36 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Oct 7 04:00:13 PDT 1994 Subject: vendor info Subject: Looking for RTOS evaluation/comparison file Subject: Driver manuals Subject: Re: SDLC serial protocol for VxWorks Subject: Re: getting child's task id at exit time Subject: messages from interrupt level lost Subject: Re: ARP ? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: vendor info Date: Tue, 4 Oct 1994 17:34:04 GMT From: fisher@acuson.com (Diane Fisher) Organization: Acuson; Mountain View, California Message-ID: <1994Oct4.173404.27671@acuson.com> I would like to find out the name and address of the vendor of Vxworks. Please email the information to: fisher@acuson.com --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Looking for RTOS evaluation/comparison file Date: 06 Oct 1994 14:45:15 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) I recall that a while back someone compiled a fairly extensive summary of features, pros and cons of several popular RTOSs - could someone please send me pointer to that file (or the file itself:-) if it's still around somewhere? Thanks a 2^20! - -Henning - -- Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ I know it's a non sequitur, but what does that have to do with it ? --------------------------- Newsgroups: comp.os.vxworks Subject: Driver manuals Date: 6 Oct 1994 15:08:28 GMT From: rlight@site.gmu.edu (Robert Light (ECE 512)) Organization: George Mason University, Fairfax, Virginia, USA Message-ID: <3713tc$19r@portal.gmu.edu> Hi, I'm in need of device driver manuals. Does anyone know of an 3rd party book writers on this subject? Specifically I am writing a VME device driver for an Ironics IV-3234 intelligent serial card. Any information would be greatly appreciated! Thanks in advance, Rob. - -----------------+---------------------------------+-------------------------- Robert W. Light | VARCOM Corporation | Phone: 703/591-2805 Systems Analyst | 3251 Old Lee Highway, Suite 407 | Fax: 703/591-2807 | Fairfax, Virginia 22030 | Email: rlight@varcom.com - -----------------+---------------------------------+-------------------------- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln When I was a boy I was told that anybody could become President. Now I'm beginning to believe it. -- Clarence Darrow --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SDLC serial protocol for VxWorks Date: 6 Oct 1994 17:38:36 GMT From: synergy@nic.cerf.net (John E. Clark) Organization: CERFnet Dial n' CERF Customer Message-ID: <371cms$4cg@news.cerf.net> References: <9410051243.AA02202@lxe6.lxe.com> In article <9410051243.AA02202@lxe6.lxe.com> rcb0135@lxe6.lxe.com (Robert Barbrow) writes: +< Does anyone know where I could get an implementation of SDLC +< for VxWorks? I need SDLC, so I will consider all possible +< alternatives, SDLC source code for any operating system, buying +< someones port of SDCL to vxWorks, buying SDLC and porting it to +< vxWorks, or ... +< +< Please let my know if you have any ideas. + +Hi Randy, + +You might want to look at the 4.4BSD-Lite source code tree. It contians some +HDLC, X.25 source that may be helpful to you. You can find the source at many This only implements a DTE-DTE link, ie Point-To-Point. HDLC includes the idea of multi-drop, as well as wending a path through a tel-co switch system, which I don't think this stuff even remotely does, or thinks about. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: getting child's task id at exit time Date: 6 Oct 1994 23:05:39 GMT From: jjwang@clark.net (Jason J Wang) Organization: Clark Internet Services, Inc., Ellicott City, MD USA Message-ID: <371vs3$33k@clarknet.clark.net> References: Jens Christensen (jens@Xenon.Stanford.EDU) wrote: : Under VxWorks, when task deletion hooks get called taskIdSelf() : seems to return the taskid of the parent, and not of the child : task that is exiting and on whose behalf cleanup should be done. : Is there any way of obtaining the task id of the exiting : task? : Thanks, : Jens The task deletion hook can be called with one argument, WIND_TCB *Tcb i.e. del_hook (WIND_TCB *Tcb) What I've used in the past is a kluge of sorts. The task id of the child task is effectively taskNameToId(*Tcb->name). Hope this helps! - -Jason --------------------------- Newsgroups: comp.os.vxworks Subject: messages from interrupt level lost Date: Thu, 6 Oct 1994 23:41:06 GMT From: subbu@cs.Buffalo.EDU (Subbu Deivanayagam) Organization: Wind River Systems, Inc. Message-ID: Sender: news@wrs.com (News Manager) > What is my vxworks system trying to tell me when it says : > 0x39f8f4 (tExcTask): 22 messages from interrupt level lost. tExcTask is a facility provided for Interrupt Service Routines to facilitate execution of code at task level. (Code executed at ISRs is executed at the Interrupt level) _func_excJobAdd should be called at interrupt level with the correct parameters so that a request is sent to tExcTask. This communication from the ISR to the tExctask is done using message Queues. Since ISRs cannot WAIT for the message queues to be available, they just throw it into the queue (NO_WAIT) and hope it reaches the tExctask. In a system receiving large number of interrupts, there is a possiblity that this might get lost. This is what you are seeing in the above error message. Subbu. +----------------------------------------------------------------+ | | | Subbu Deivanayagam Wind River Systems | | Technical Support 1010 Atlantic Ave. | | email: subbu@wrs.com | | | +----------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ARP ? Date: Fri, 7 Oct 1994 08:54:52 GMT From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera) Organization: International Computers Limited Message-ID: References: <1994Oct3.192548.22193@lds.loral.com> Reply-To: rsgawera@ss11.wg.icl.co.uk Sender: news@oasis.icl.co.uk In article 22193@lds.loral.com, jprice@lds.loral.com (Jeffrey Price, 6823) writes: > >Hello : > >I am building an application in which I want the unix host to direct ALL >pkts to any IP address to the same target. > >There are several ways I can think of to do this. I am interested in y'alls >opinions on which is the best in terms of ease and efficiency . > >1. Have the Unix Host update its ARP table via (arp command) to reflect > that all IP addresses map to same target ethernet address. This requires > a manual (or programatic action). A more automated and hence generic > approach may be to : OK for small number of destinations. If target is connected to large network, you could look at routing as an alternative. This would involve setting up separate networks and have the target act as a router. >2. Have ARP code on target respond to all ARP requests with its own ethernet address. > > Is this possible, and if so how. > This sounds very much like Proxy ARP. It's described in the VxWorks manual but the manual makes it sound like this is only intended for ethernet & shared memory network combinations. You'ld have to make sure that only the target responds to ARP requests, and that the real ARP destination cannot reply directly tro host. Can anyone out there offer advice / direction / clarification on Proxy ARP ? I posted a question here a while back but got no response. >3. Use input hooks and reply to ARP requests myself an ARP message so that I could parse it when I received it in the input hook ? ARP message formats, and how they fit into ethernet packets is detailed in the header file netinet/if_ether.h and net/if_arp.h. It's also detailed in some RFCs somewhere. >Other ideas or comments ? Option 2 sounds favourable. Where will your target pass IP frames to ? Another ethernet ? Good Luck! Let us know how you get on. Raj Raj Gawera ICL CSD email : rsgawera@wg.icl.co.uk --------------------------- End of New-News digest ********************** From Keith_Zhang.LAX1B@xerox.com Fri Oct 7 13:41:25 1994 From: Keith_Zhang.LAX1B@xerox.com Date: Fri Oct 7 13:41:31 PDT 1994 Subject: Special raw data file system on VxWorks ... hi, We are trying to implement a local file system on VxWorks. The requirement is different from the one that is supplied by Wind River. It must be unbuffered and used to store large chunks of raw image data. It does not need to have any directories nor multiple files. Just one single file to store the raw data is all we need. We primarily use it to cache raw image data received from the SCSI bus. Does anyone have the implementation already and something close to this? Please let us know if you do. Thanks! /Keith ------------------------------------------------------ Name: Keith Zhang Company: Xerox Corp. Address: 101 E Continental Blvd Mail stop: ESC1-14D El Segundo CA 90245 Tel: 310 - 333 - 3372 Fax: 310 - 333 - 6442 email: kzhang.lax1b@xerox.com From csibtfr!eugenel@apple.com Fri Oct 7 15:10:49 1994 From: csibtfr!eugenel@apple.com (Eugene Leung) Date: Fri Oct 7 15:10:56 PDT 1994 Subject: NTP Do anyone has any info about setting up NTP for a 68030 target using vxWorks as well as on a SUN workstation? Thanks. ================================================================================ - - - Eugene Leung + email: csibtfr!eugenel@apple.com - - Sr. S/W Engineer + phone: (408)371-9580 ext 714 - - Condor Systems Inc. + fax: (408)371-9589 - - - ================================================================================ From daemon@vxw.ee.lbl.gov Sat Oct 8 04:00:31 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Oct 8 04:00:39 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Oct 8 04:00:13 PDT 1994 Subject: Re: Support for Green Spring IP-488 driver Subject: VME Board Design Subject: Re: Looking for RTOS evaluation/comparison file Subject: Re: 3.5" SCSI-floppy drives... Where? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Support for Green Spring IP-488 driver Date: 07 Oct 1994 17:51:26 GMT From: pjg@tesla.esl.com (Paul Gyugyi) Organization: ESL, Inc. Message-ID: References: <9410031421.AA24563@lbl.gov> In article <9410031421.AA24563@lbl.gov> Argun DERVIS writes: Does anyone have an IP-488 software driver for Green Spring Industry Pack products? I also have a need for IP-488 drivers. Please contact me if you have (or will have) such a library for sale. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | ESL, a TRW Company TRW | | | | 495 Java Drive Paul J. Gyugyi, Ph.D. | | Post Office Box 3510 Sr. Systems Engineer | | Sunnyvale, CA 94088-3510 Advanced Processor Applications | | voice: 408.738.2888 ext. 4408 Paul_Gyugyi@smtp.esl.com | | fax: 408.743.6425 pjg@tesla.esl.com | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - -- =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= | Paul Gyugyi scrabble...click...snap... | | gyugyi@earthsea.stanford.edu Paul_Gyugyi@smtp.esl.com | =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= --------------------------- Newsgroups: misc.jobs.offered,comp.arch.bus.vme,comp.os.vxworks,comp.os.os9,comp.realtime,comp.dsp Subject: VME Board Design Date: Fri, 7 Oct 1994 19:20:03 GMT From: tje@rabuka.ariel.com (Jeff Enderwick) Organization: Ariel Corporation, Highland Park, NJ Message-ID: Sender: news@ariel.com Ariel Corporation has openings for digital design engineers with experience designing and implementing VME boards. Requirements include: + Solid background in VME board design, + Experience with DSPs and/or real-time & high-speed processors, + Experience with bring-up and transition into mfg., including test, + Knowledge of assembly language programming (C helpful). These are not entry-level positions. Please send resumes to: Ariel Corporation Department 709 433 River Road Highland Park, NJ 08904 FAX: (908) 249-2123 --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: Looking for RTOS evaluation/comparison file Date: 7 Oct 1994 17:56:34 -0500 From: askew@Starbase.NeoSoft.COM (Bill Askew) Organization: NeoSoft Internet Services +1 713 684 5969 Message-ID: <374jn2$j8s@Starbase.NeoSoft.COM> References: In article , Henning Pangels wrote: > >I recall that a while back someone compiled a fairly extensive >summary of features, pros and cons of several popular RTOSs - could >someone please send me pointer to that file (or the file itself:-) if >it's still around somewhere? > >Thanks a 2^20! > >-Henning >-- >Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center >Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University >------------------------------------------------------------------------------ > I know it's a non sequitur, but what does that have to do with it ? I would like this info too - -- ==================================================================== R. William Askew A Harley Ride a Day, askew@Neosoft.com Helps Drive the Blues Away RWA ==================================================================== --------------------------- Newsgroups: comp.os.os9,comp.os.vxworks,comp.periphs.scsi Subject: Re: 3.5" SCSI-floppy drives... Where? Date: Fri, 7 Oct 1994 21:34:20 +0000 From: fred@genesis.demon.co.uk (Lawrence Kirby) Organization: none Message-ID: <781565660snz@genesis.demon.co.uk> References: <1994Sep26.144939.29870@matrix.com> <36nvsh$9r2@gazette.engr.sgi.com> <1994Oct4.160525.22463@news.cs.indiana.edu> Reply-To: fred@genesis.demon.co.uk Sender: usenet@demon.co.uk In article <1994Oct4.160525.22463@news.cs.indiana.edu> cyliax@cs.indiana.edu "Ingo Cyliax" writes: >Do they handle 360rpm spindle speed, I have an application that >requires that. Anyway, do you have a reliable vendor ? They spin faster to provide greater throughput than normal floppy drives. Spindle speed isn't usually important for SCSI since you are just transferring logical blocks. Why does your application need a particular spindle speed? - -- - ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com - ----------------------------------------- --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Oct 9 04:00:21 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Oct 9 04:00:28 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Oct 9 04:00:12 PDT 1994 Subject: Cross-debugging (gdb) in emacs? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Cross-debugging (gdb) in emacs? Date: Fri, 7 Oct 1994 21:48:46 GMT From: iec@netcom8.netcom.com (Interstate Electronics Corp) Organization: NETCOM On-line services Message-ID: Reply-To: mre@lpf.org (Mike Elliott) Sender: iec@netcom.com (Interstate Electronics Corp) Problem: How to use gdb in a cross-debugging environment from within emacs. It seems to me it should be quite straightforward to use gdb from within emacs for cross-debugging in a manner similar to its common use for self-hosted debugging. It will not work identically because M-x gdb prompts for a program to debug, which doesn't allow for the establishment of cross-debugging via a 'target vxworks 68kbox' command. Could anyone help me with this? - -- - -- ======================================================================== Mike Elliott mre@emerald.ccss.com mre@lpf.org ======================================================================== --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Mon Oct 10 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Mon Oct 10 04:00:29 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Oct 10 04:00:12 PDT 1994 Subject: Re: getting child's task id at exit time ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: getting child's task id at exit time Date: 9 Oct 1994 11:23:03 GMT From: per@erix.ericsson.se (Per Hedeland) Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Message-ID: <378jqn$c16@euas20.eua.ericsson.se> References: <199410061346.JAA03208@a9926.ASTRO.GE.COM> <371vs3$33k@clarknet.clark.net> In article jens@Xenon.Stanford.EDU (Jens Christensen) writes: >Under VxWorks, when task deletion hooks get called taskIdSelf() >seems to return the taskid of the parent, and not of the child >task that is exiting and on whose behalf cleanup should be done. Not really, strictly speaking VxWorks tasks don't have children or parents - however it is correct that the delete hook is not normally (ever?) called in the context of the exiting task, thus taskIdSelf() is not useful. In article <199410061346.JAA03208@a9926.ASTRO.GE.COM> Matthew Krokosz writes: >When a task delete hook routine is called, vxworks passes it a pointer >to the exiting tasks WIND_TCB, which is the task control block. The >WIND_TCB structure contains the task id. I certainly can't find it - but the pointer to the WIND_TCB *is* the task id - i.e. you just need to cast it to int. Although I haven't seen this documented anywhere, I guess it's unlikely to change anytime soon... - and as far as I can see, it's the only reasonable/reliable way to get the exiting task's id in a delete hook. In article <371vs3$33k@clarknet.clark.net> jjwang@clark.net (Jason J Wang) writes: >The task deletion hook can be called with one argument, WIND_TCB *Tcb >i.e. del_hook (WIND_TCB *Tcb) > >What I've used in the past is a kluge of sorts. The task id of the child >task is effectively taskNameToId(*Tcb->name). (I assume that should be taskNameToId(Tcb->name).) Yes, slow and also unreliable in general - there is no guarantee that task names are unique. (int)Tcb works fine. - --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@sunic.sunet.se or ...uunet!erix.ericsson.se!per --------------------------- End of New-News digest ********************** From DNEELAY@fwbsmtp.ftwa.tasc.com Mon Oct 10 07:41:09 1994 From: DNEELAY@fwbsmtp.ftwa.tasc.com Date: Mon Oct 10 07:41:16 PDT 1994 Subject: 060 VME SBC Card Anyone intrested in providing a quote for a 68060 VME single board computer with 16M Ram, E-net, SCSI-2, 2-Serial (minimum), 1Parallel, etc. (board configuration package must be available from Verdix for VADSworks). Please e-mail it to dneelay@tasc.com Thanks- Dinesh Neelay TASC 1992 Lewis Turner Blvd, Ft. Walton Beach, FL 32547 From johnge@pogo.wv.tek.com Mon Oct 10 08:08:58 1994 From: johnge@pogo.wv.tek.com (John A Gervais) Date: Mon Oct 10 08:09:05 PDT 1994 Subject: embedded symbol tables I am using makeSymTbl in a Makefile for an embedded system with limited RAM. Is is necessary to have the symbol table located in RAM? Things seem to die quickly if I locate it in ROM. Is there a comprehensive list of things I must do to prevent attempts to write/add to the symbol table? Thanks, John Gervais johnge@pogo.WV.TEK.COM From guthrie@power.amasd.anatcp.rockwell.com Mon Oct 10 08:11:13 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Mon Oct 10 08:11:20 PDT 1994 Subject: X Windows Server Does anybody offer software to make a single board computer, running VxWorks 5.1.1 an X Windows Server ? Preferably Wind River. Robert Guthrie From dervis@venus.aselsan.com.tr Mon Oct 10 10:04:37 1994 From: dervis@venus.aselsan.com.tr (dervis) Date: Mon Oct 10 10:04:45 PDT 1994 Subject: Sun news group Hi, Can any body tell me any one of the Sun News Group addresses ? Thanks, Argun DERVIS ASELSAN Military Electronics ANKARA-TURKIYE e-mail : dervis@venus.aselsan.com.tr tel : 90-312-3851900 (ext 2660), fax : 90-312-3545205 From daemon@vxw.ee.lbl.gov Tue Oct 11 04:00:32 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Oct 11 04:00:56 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Oct 11 04:00:13 PDT 1994 Subject: Re: VxWorks on Pentium-PCI Ethernet NICs driver? Subject: vxWorks Positions Available Subject: Re: Looking for RTOS evaluation/comparison file Subject: Disk Drives? Which? Subject: Re: 060 VME SBC Card Subject: Re: Looking for RTOS evaluation/comparison file Subject: Summary of Responses - RTOSes for High Performance Embedded Systems Subject: Comp.realtime: A list of real-time operating systems and tools (LONG) Subject: table of contents Subject: A list of real-time operating systems. Subject: Commercial real-time operating systems. Subject: AMX. Subject: CHORUS. Subject: CX/UX, CX/SX, CX/RT. Subject: DECelx and VAXELN. Subject: HP-RT. Subject: iRMX. Subject: LynxOS. Subject: MTOS-UX. Subject: OS-9, OS-9000. Subject: OS/32. Subject: PDOS. Subject: Precise/MPX. Subject: pSOS+. Subject: pSOS+ pSOSystem. Subject: PXROS. Subject: QNX. Subject: REAL/IX. Subject: RTU. Subject: SORIX 386/486. Subject: SPOX. Subject: SunOS. Subject: Umax V, uMPX, uRTT, uARTE. Subject: UNOS. Subject: VAXELN. Subject: VENIX/386. Subject: VRTX. Subject: VxWorks. Subject: XLoad. Subject: Research (non-commercial) real-time operating systems. Subject: Chimera 3.0 Subject: Harmony Real-Time Operating System Subject: Commercial real-time toolkits. Subject: RTworks. Subject: Contributions to comp.realtime FAQs. ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks on Pentium-PCI Ethernet NICs driver? Date: Mon, 10 Oct 1994 10:11:43 GMT From: "Eli Herskovitz" Organization: Tel-Aviv University Computation Center Message-ID: <199410101211511341.eli@radmail.rad.co.il> References: <9410071305.AA30795@qnx.com> Sender: eli@radmail.rad.co.il In message Fri Oct 7 09:05:47 1994, Dan Hildebrand writes: > In article <199410041943488185.eli@radmail.rad.co.il> you write: > >>Hi fox >> We are currently looking for the "best" platform and OS. >> Does anyone know if there is somewhere a VxWorks running on Intel >> Pentium? Optimized for Pentium? >> >> Do you know of a driver written for any PCI Ethernet controller? >> >> Are there development tools on a PC? (e.g. compiler, debugger) and did >> anyone work with the PC as a development host? >> > > Is VxWorks the only OS you're looking at? There are other realtime OS's > for the PC that provide good answers to the questions you'ved asked here. > -- I had sent a fax asking for data on QNX and didn't get any reply. I didn't try harder because we want a portable OS that is good for more than one processor (e.g. i960, Pentium), and as I understood, the QNX works only on PC. However I'll appreciate any information you'll be kind enough to supply. Thanks & regards Iris Tal eli@radmail.rad.co.il RADGUARD 8 hanechoshet st. Tel Aviv 69710 Israel tel: 972-3-6459592 fax: 972-3-6487990 --------------------------- Newsgroups: comp.os.vxworks Subject: vxWorks Positions Available Date: 10 Oct 1994 09:46:50 -0600 From: krussell@xmission.com (Kevin Russell) Organization: XMission Public Access Internet (801-539-0900) Message-ID: <37bnla$6se@xmission.xmission.com> BTS Broadcast Television Systems, Inc., a division of Philips, has the following positions open in Salt Lake City, Utah. BTS provides hardware and software solutions for customers in video related businesses including television stations, cable companies, video production houses, and many others. BTS is an equal opportunity employer with competitive salaries with a full benefit package including 401K and tuition reimbursement. BTS also provides a state of the art work environment with the latest hardware and software development tools. Relocation may be available. We currently have openings in our control system software engineering group. This group develops real time systems for the control of audio / video equipment. Development targets include the 68000 running vxWorks, v25 running a proprietary kernel, and Windows. The system is lan based with ip based protocols over ethernet as the communications mechanism between nodes. All positions require 3+ years experience in C, 1+ year(s) in C++, and a BS degree in a related discipline or equivalent experience. Software Design Engineer (Windows) CODE 541-E-94 Develop various supporting applications for the configuration of our control system product. 3+ years experience in Windows programming using Borland or Microsoft tools is required. TCP/IP, DDE, and/or database design experience is a plus. Software Design Engineer (real time) CODE 542-E-94 Develop real time software running on our proprietary hardware under vxWorks. 3+ years experience in real time development is required. 68000, v25, vxWorks, pSOS, and/or TCP/IP experience is a plus. Software Design Engineer (Windows Contract) CODE 531-E-94 3 - 6 month position. Develop network interface application for our control system product. 3+ years windows experience using Borland or Microsoft tools is required. Strong DDE and TCP/IP experience using the Winsock API is also required. Candidates with strong TCP/IP backgrounds using tools other than Winsock, or other networking experience will also be considered. You may send your resume via email to krussell@xmission.com, via fax to (801) 977-1539, or via U.S. Mail to: Kevin Russell c/o Human Resources BTS Broadcast Television Systems P.O. Box 30816 Salt Lake City, Utah 84130-0816 Be sure to reference the CODE in your correspondence. --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: Looking for RTOS evaluation/comparison file Date: 10 Oct 1994 17:23:21 GMT From: Blaine Kubesh Organization: SSI Message-ID: <37bta9$7i4@news.internex.net> References: In article Henning Pangels, hmp@frc2.frc.ri.cmu.edu writes: > I recall that a while back someone compiled a fairly extensive > summary of features, pros and cons of several popular RTOSs - could > someone please send me pointer to that file (or the file itself:-) if > it's still around somewhere? I received an extensive RTOS feature comparion from Accelerated Technology. It reviews the following companies/Products. Accelerated Technology Nucleus RTX, Nucleus Plus A.T. Barett & Associates RTXC, RTXC/MP Byte-BOS Integrated Systems Byte-BOS Eyring PDOS, VMEPROM Integrated Systems pSOS+ JMI Software Consultants C Executive Kadak AMX Multitasking Exec. Lynx Lynx OS Micro Digital SMX Microware Systems OS-9, OS-9000 Ready Systems VRTX RTMX-UniFLEX UniFLEX Spectron Microsystems SPOX U.S. Software MultiTask! C Exec. Wind River VxWorks I found this guide very useful in selecting and comparing RTOS features. It is fairly comprehensive with the features, but does not elaborate on each product individually, mainly has a bunch of tables that mark an 'X' if the product supports the feature. The guide may be biased toward Accelerated's Nucleus PLUS product in it's selection of features, since it *is* their marketing guide. You can make up your own mind about that. Call Accelerated Technology at 800-468-6853 and ask for their RTOS feature comparison, FREE!. I am not associated with any of these companies. I found this guide useful while looking for an RTOS. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Blaine Kubesh Internet: blaine@sonicsys.com Sonic Systems, Inc. Call Sign: ke6gsx =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --------------------------- Newsgroups: comp.os.vxworks Subject: Disk Drives? Which? Date: Mon, 10 Oct 1994 16:34:14 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Message-ID: <1994Oct10.163414.12138@brtph560.bnr.ca> Sender: billag@b4pphff (Bill Gutknecht) I'd like to attach some small (200MB) SCSI drives to a MVME162 system and run the DOS filesystem. Any recommendations on vendors that supply disks that work well with the VxWorks drivers? Thanks. Bill - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 060 VME SBC Card Date: 11 Oct 1994 02:33:35 GMT From: dat85715@indirect.com (D'Anne Thompson) Organization: Internet Direct, Inc. Message-ID: <37cthv$pdb@herald.indirect.com> References: Reply-To: dee@ioinc.tucson.az.us Sender: dat85715@bud.indirect.com Wind River hasn't released VxWorks for the 68060 yet. It is in testing and should be released soon. Synergy Microsystems, my employer, has an 060 SBC board in production testing now. We will be receiving the beta version of VxWorks 060 as soon as WRS releases it. The SV-460 will be available in both single and dual processor versions, with up to 32MB of memory. It is fully compatible with our EZ-bus daughterboards. The newest daughterboard, the EWSE, combines ethernet and wide-fast-scsi (16.9 MB/sec sustained throughput using scsiLib and our ncr720 driver). Other daughterboards combine ethernet with hi-speed serial (T1 rates), GPIB, VSB, and other common interfaces. Please call or write our sales people at 1-619-452-0020 for pricing and delivery. Delivery of VxWorks will be up to WRS, but it should be anytime now. You can send email to sales at 'del@synergy.encinitas.ca.us'. I can't answer about VADsWorks, you should call Verdix or WRS for more info. D'Anne Thompson Synergy Microsystems, Inc. dee@ioinc.tucson.az.us dee@synergy.encinitas.ca.us dat85715@indirect.com --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: Looking for RTOS evaluation/comparison file Date: 11 Oct 1994 04:23:30 GMT From: mhuang@buast7.bu.edu (maohai huang) Organization: Boston University Message-ID: <37d402$76t@news.bu.edu> References: <37bta9$7i4@news.internex.net> Followup-To: comp.realtime,comp.os.vxworks Blaine Kubesh (blaine@sonicsys.com) wrote: : In article Henning Pangels, : hmp@frc2.frc.ri.cmu.edu writes: : > I recall that a while back someone compiled a fairly extensive : > summary of features, pros and cons of several popular RTOSs - could : > someone please send me pointer to that file (or the file itself:-) if : > it's still around somewhere? i have some interesting RT-related posts. a lot of them are sort of dated. here are two. i have an on year old faq and patches. but you can probably find them at rtfm.mit.edu. you may or may not find these useful. you may want to contact original posters for updated versions. i don't know if these info are/were accurate. on usenet you get what you paid. and i hope nobody will feel offended by my reposting w/o authors' consent. - - mh - ------------included 1------------- From: ross@prpa.philips.com (Ross Morley) Subject: Summary of Responses - RTOSes for High Performance Embedded Systems Message-ID: <1993Jul8.005932.8084@prpa.philips.com> Organization: Philips Research Palo Alto Date: Thu, 8 Jul 1993 00:59:32 GMT Lines: 492 Just over a week ago I posted the following enquiry... > I am looking for real time OS kernels for high performance > embedded systems, for any processor. (I don't want to restrict > the information to RTOSes that support a particular processor). > Modularity is highly desirable (the ability to include only the > parts of the OS needed for an application). > > I'm interested in your opinions and experiences with any such > kernels and the associated application development environments. > Some RTOSes I'm aware of that might be suitable are: > - SPOX, > - VRTX/sa, > - Nucleus RTX. > > Please email responses if they are old-hat info that's > been on this group before (I'm new). If others are > interested I'll summarize responses. Thanks. I received a number of responses by email and smail (snail-mail, for the non-net.literate), including several requests for summaries. So here is the promised summary. I also received a lot of information as a result of phone enquiries to various development system companies. Since there's a lot of overlap, I'll include them all. I have not had time to fully digest all this information and evaluate the various RTOSes for our needs, but someone out there may benefit from knowing these all exist. If you want more info on any, please contact the vendor directly (I'll include phone numbers at least). While I did get a lot of names and vendors of RTOSes, I did not get many opinions or experiences from users of these RTOSes, so for the most part I'll just have to sift through vendor literature. Those opinions/experiences I did get have been included where the responder's permission was given. For ease of finding them, they are marked with #### (there ended up being only one). I have not included opinions from employees of the vendors. [Disclaimer: This information is incomplete, and any opinions are mine unless otherwise stated. The reader is advised to contact the appropriate vendor(s) if more detailed information is required.] [Note: Some lists are tabulated with tabs stops set every 8 positions.] Overview - RTOSes Mentioned =========================== RTOS Vendor - ---- ------ CHORUS Chorus systemes, France Helios Distributed Software, UK MTEX Telenetworks Nucleus RTX, Nucleus PLUS Accelerated Technology OS-9, OS-9000 Microware Systems pSOS+ Integrated Systems Inc. QNX QNX Software Systems, Canada SPOX Spectron Microsystems Virtuoso Intelligent Systems International, Begium VRTX, VRTXsa Ready Systems VxWorks Wind River Systems RTOSes not in the comp.realtime FAQ (version 1.06, May 1993) =================================== Helios Distributed Software, UK MTEX Telenetworks Nucleus RTX, Nucleus PLUS Accelerated Technology Virtuoso Intelligent Systems International, Begium VRTXsa Ready Systems Summary Per RTOS (in alphabetical order) ================ CHORUS - ------ Excerpts from email response from the vendor (mm@chorus.fr): > You might want to take a look at CHORUS, a distributed real-time > microkernel that can be combined with the CHORUS/MiX subsystem, which > is modular fully compatible UNIX System V (R3.2 or R4.0) > implementation. CHORUS runs on i386/i486, 680x0, SPARC, transputer and > on several other processors. > There are several technical reports on CHORUS (in PostScript format) > available via anonymous FTP from Chorus systemes, France: > ftp.chorus.fr [192.33.15.3], directory pub/chorus-reports. See the file > "index" for an overview. > If it's more convenient for you, you can get the same reports from > Oregon's Graduate Institute, Portland, OR, USA: cse.ogi.edu > [129.95.10.2], in the directory pub. > There is also a set of ~90 slides on Chorus and CHORUS available in > the directory pub/chorus-slides/CS-TR-92-64 (PostScript, versions 1-up > and 2-up). Chorus contact information: Sales Support Europe & Pacific Rim Chorus systemes 6, avenue Gustave Eiffel F-78182 St. Quentin en Yvelines Cedex Contact: Marc Maathuis Tel: +33 (1) 30 64 82 57 (direct) FAX: +33 (1) 30 57 00 66 U.S. Subsidiary (for support in US) Chorus Systems Inc. 15262, NorthWest Greenbrier Parkway, Beaverton, OR 97006. Contact: Will Neuhauser Tel: (503) 690 2300 Fax: (503) 690 2320 Helios - ------ Quote from vendor brochure: "Helios is a distributed operating system designed to run on MIMD computers. The Open System architecture provides complete parallel programming support for both personal and supercomputers." Contact information: Distributed Software, Ltd. The Maltings, Charlton Rd., Shepton Mallet, Sommerset BA4 5QE, United Kingdom. Tel: +44 (0) 749 344345 Fax: +44 (0) 749 344977 MTEX - ---- A small, simple, VRTX-like kernel available with C source code and no royalties, for a moderate license fee. Contact information: Telenetworks 625 Second St., Suite 100, Petaluma, CA 94952 Tel: (707) 778 8737 Fax: (707) 778 7476 Nucleus RTX - ----------- Quote from vendor brochure: "Nucleus is a multitasking executive specifically designed for real-time embedded applications." C source code and no royalties for a moderate license fee. Multitasking debugger and performance analysis tools available. File system and TCP/IP add-ons available. All add-ons and tools mentioned above available source with no royalties. Offered by many DSP board vendors with their products. Available for most well known processors (RISC, CISC & DSP). Contact information: Accelerated Technology, Inc. P.O. Box 850245 Mobile, AL 36685 Tel: (205) 661 5770 Fax: (205) 661 5788 Nucleus PLUS - ------------ A more advanced kernel than Nucleus RTX, that uses a microkernel approach. Deterministic, modular, extensible, very flexible memory management, better interrupt management. No mention of upward compatibility with Nucleus RTX - appears to be a new kernel. C source code and no royalties for a moderate license fee. Contact information: See Nucleus RTX. OS-9 - ---- Scalable architecture built around standalone microkernel. Quote from vendor brochure: "OS-9 is a modular operating system that provides deterministic, high-performance operation for 680X0-based applications." Contact information: Microware Systems Corporation 1900 N.W. 114th St. Des Moines, Iowa 50325-7077 Tel: (515) 224 1929 Fax: (515) 224 1352 (See the FAQ for more details of regional offices). OS-9000 - ------- Quote from vendor brochure: "OS-9000 is a 32 bit, modular, real-time, multi-user, multi-tasking operating system designed to turn your 386/486-based PCs and industrial systems into sophisticated real-time platforms." Contact information: See OS-9. pSOS+ - ----- Quote from vendor brochure: "Optimized to meet demands of next generation embedded applications, pSOS+ is an advanced, robust, multi-tasking kernel..." Deterministic. Modular. Integrated with lots of development tools. A distributed (multi-processing) version is available, pSOS+m. Quote from vendor brochure: "pSOSystem is a modular, high-quality performance, real-time operating system designed specifically for embedded microprocessors." pSOSystem is a complete OS built around the pSOS+ kernel. Contact information: Integrated Systems, Inc. 3260 Jay St. Santa Clara, CA 95054 Tel: (408) 980 1500 Fax: (408) 980 0400 (See the FAQ for more details of regional offices). QNX - --- A distributed, POSIX, real-time microkernel for x86 processors. This one's in the FAQ. I received lots of information from the vendor, and one comment from a user. First, from a technical employee of the vendor (danh@qnx.com): > Two QNX papers are available via anonymous FTP from ftp.cse.ucsc.edu > (128.114.134.19): > > /pub/qnx-paper.ps.Z "An Architectural Overview of QNX" Note: that's /pub/qnx/qnx-paper.ps.Z > > The architecture of the QNX microkernel is outlined, and its performance > compared to the SVR4 UNIX system (a monolithic kernel). This paper was > presented at the April/92 USENIX Microkernel conference and again at the > Jan/93 Usenix. > > /pub/qnx/qnx_embed.ps.Z "A Microkernel POSIX OS for Realtime Embedded Systems" > > Using QNX as an example, this paper discusses the suitability of > microkernel and POSIX technologies for a range of realtime embedded systems > development. System solutions for small, stand-alone ROM-based systems, > network-distributed embedded systems, bus-connected distributed systems and > large-scale, multiprocessor, distributed systems are discussed. This paper > was presented at the April/93 Embedded Computer Conference. > In addition, here's a recent press release: > > QNX Software Systems Announces QNX 4.1: > > * Fault-Tolerant, Realtime, Distributed-Processing Capabilities Enhanced * > > QNX Software Systems, Ltd., developers of the QNX realtime operating > system, have released QNX 4.1, a POSIX OS based on microkernel technology. > QNX 4.1 started shipping in July, 1992, and features enhanced disk I/O, > multiple redundant network links, and a 10% reduction in context-switch > time compared to QNX 4.0. > The QNX microkernel provides only the essential process scheduling and > interprocess communication (message passing) facilities from which all the > other services in the operating system are built. This approach results in > a 7 Kbyte microkernel with performance characteristics equivalent to a > realtime executive. Because server processes can be removed or added, QNX > is scalable from small, ROM-based systems up to large, multiprocessor, > distributed systems. Networking services are provided by extending the > message-passing model to be network-transparent, such that communicating > processes need not care whether they reside on the same or different nodes > on the network. The server processes that provide the remainder of the > system are implemented directly on these services, resulting in a fully > distributed operating system. The full text of the press release can be obtained from danh@qnx.com (it's too long to include in the summary). There was also a detailed specifications overview, which can be obtained from danh@qnx.com. #### And now... a response from a happy user (quoted with permission): > From rgallen@muug.mb.ca Tue Jun 29 08:47:22 1993 > In comp.realtime you write: > > >I am looking for real time OS kernels for high performance > >embedded systems, for any processor. (I don't want to restrict > >the information to RTOSes that support a particular processor). > >Modularity is highly desirable (the ability to include only the > >parts of the OS needed for an application). > > QNX meets your requirements. It runs on Intel processors and sports a > Pentium optimizing compiler. > > QNX is a microkernel (8K) based RTOS that has only 1 mandatory process. The > mandatory process is Proc which provides process loading, priority mgmt etc.. > The microkernel and Proc together weigh in at around 80K (i.e. Proc is ~72K). > > >I'm interested in your opinions and experiences with any such > >kernels and the associated application development environments. > >Some RTOSes I'm aware of that might be suitable are: > > I have used QNX for the past 6 years and I am very happy with it. QNX Software > Systems Limited (QSSL) has excellent technical support and is very responsive > to customer requests. QNX 4.2 (which I am beta testing), is absolutely > awesome. > > Contact danh@qnx.com for more information > > email: rgallen@muug.mb.ca mail: Expert Technology Corporation > QUICS: rgallen (613) 591-0934 502-52 Albert St. > Voice: (204) 958-5676 Winnipeg, Manitoba, Canada R3B 1E8 > Fax: (204) 958-5678 Contact information: [ Note: the company's name has changed since the FAQ (used to be Quantum Software Systems) ] QNX Software Systems QNX Software Systems 175 Terrence Matthews Cr. Westendstr.19 6000 Frankfurt Kanata, Ontario K2M 1W8 am main 1 Canada Germany voice: (613) 591-0931 x111 (voice) voice: 49 69 97546156 x299 fax: (613) 591-3579 (fax) fax: 49 69 97546110 SPOX - ---- Real-time embeddable kernel designed with DSPs in mind. Modular, microkernel architecture. ANSI C (including stdio) and math (including vectors, matrices, filters) libraries available. A quote from a vendor flyer on a technical seminar: "With today's generation of fixed and floating point DSP processors, Spectron's industry standard SPOX operating system can execute numerically-intensive signal processing algorithms and also simultaneously perform complex system control and communication functions the significantly reduce - *and often eliminate* - the need for general-purpose microprocessors in many applications." (emphasis theirs). Having been to a SPOX system programming course (3 days), I can add my own opinion here: The SPOX kernel seems very well designed. Contact information: Spectron Microsystems 5266 Hollister Ave Santa Barbara, CA 93111 Tel: (805) 967 0503 Fax: (805) 683 4995 Virtuoso - -------- Real-time kernel designed for distributed multiprocessor systems. Quote from vendor literature: "The multiprocessor version of VIRTUOSO was designed to provide transparent distributed real-time processing without the need to change any line of source code when changing attributes or system resources..." Written in ANSI C. Source code of kernel is supplied. Expensive. Available in single processor version for 1/3 the cost of the full version. Run-time royalties. Contact information: Intelligent Systems International nv/sa Lindestraat 9 B-3210 Linden Begium Tel: +32 16 62 15 85 Fax: +32 16 62 15 84 VRTX - ---- Real-time, deterministic, embeddable kernel. Monolithic (not extensible), but see VTRXsa. Add-ons available include I/O components, file management (DOS), multitasking debugger and system monitor, and real-time multiprocessor executive. Contact information: Ready Systems 470 Potero Ave. Sunnyvale, CA 94086 Tel: (408) 736 2600 (corporate) (800) 228 1249 (sales) Fax: (408) 522 7197 There are also offices in France, Germany, UK, Japan, Korea, Italy, most of which are not listed in the FAQ. VRTXsa - ------ Scalable, modular, deterministic, embeddable, real-time kernel. Upward compatible with VRTX, and improved performance. Quote from vendor literature: "Scalable RTOS architecture based on Ready Systems' new Nanokernel [TM] technology." Add-ons include TCP/IP support, file I/O (optional DOS compatibility), C runtime libraries (including stdio). Supported by Spectra [TM] development environment which is TCP/IP based and provides RTOS aware debug tools. Contact information: See VRTX. VxWorks - ------- A real-time kernel that was mentioned to me and is in the FAQ. I requested but have yet to receive information from the vendor. Contact Information: Wind River Systems (see FAQ for address, as it's all I have) Tel: (510) 748 4100 (Alameda, CA office) (800) 545 9463 Note: The FAQ lists the area code of the Alameda office as 415. This is no-longer true. The new area code 510 now applies. - -- Ross Morley .---. email: ross@prpa.philips.com Philips Research Palo Alto | ___\ Phone: (415) 354 0325 4005 Miranda Ave, Suite 175 \/ \ FAX: (415) 354 0309 Palo Alto, CA 94304 ^^ - ------------included 2------------- From: linimon@nominil.lonesome.com (Mark Linimon) Subject: Comp.realtime: A list of real-time operating systems and tools (LONG) References: Approved: news-answers-request@MIT.Edu Organization: Lonesome Dove Computing Services Date: Mon, 16 Aug 1993 07:10:45 GMT Message-ID: Summary: Commercial and educational software availability (periodic posting) Expires: Mon, 27 Sep 1993 07:09:47 GMT Lines: 958 Archive-name: realtime-computing/list Version: 1.09 (August 1993) Last-Modified: Sat Jul 31 20:53:04 EDT 1993 This posting provides an incomplete list of software operating systems and tools available for the real-time market, gathered from various net.postings. Two companion postings, "Comp.realtime: Welcome to comp.realtime" , and "Comp.realtime: Frequently Asked Questions (FAQs)", , provide an introduction to the group, and answers to frequently asked questions. These articles are repeated periodically for the benefit of new readers. [Editorial comments may be found in brackets.] - ------------------------------ Subject: table of contents Subject: A list of real-time operating systems and toolkits. Subject: Commercial real-time operating systems. Subject: AMX. Subject: CHORUS. Subject: CX/UX, CX/SX, CX/RT. Subject: DECelx and VAXELN. Subject: HP-RT. Subject: iRMX. Subject: LynxOS. Subject: MTOS-UX. Subject: OS-9, OS-9000. Subject: OS/32. Subject: PDOS. Subject: Precise/MPX. Subject: pSOS+. Subject: pSOS+ pSOSystem. Subject: PXROS. Subject: QNX. Subject: REAL/IX. Subject: RTU. Subject: SORIX 386/486. Subject: SPOX. Subject: SunOS. Subject: Umax V, uMPX, uRTT, uARTE. Subject: UNOS. Subject: VAXELN. Subject: VENIX/386. Subject: VRTX. Subject: VxWorks. Subject: XLoad. Subject: Research (non-commercial) real-time operating systems. Subject: Chimera 3.0 Subject: Harmony Real-Time Operating System Subject: Commercial real-time toolkits. Subject: RTworks. Subject: Contributions to comp.realtime FAQs. - ------------------------------ Subject: A list of real-time operating systems. Below is a list of both commercial and research Real-Time Operating Systems (RTOS) which are being used around the world for implementing sensor-based systems. Only the name and address of at most one distributor per country per RTOS is included. Since the available features of each RTOS are constantly changing, and the advantages and disadvantages of each are greatly a matter of opinion and target application, no such descriptions are given. If you want that information, contact the distributor directly, or ask your colleagues on the Net for their opinions. Please send updates/changes/corrections to ; however, you might want to Cc: the original author, David B. Stewart . - ------------------------------ Subject: Commercial real-time operating systems. The following commercial RTOSes are listed in alphabetical order. [The list is known to be incomplete; please feel free to add others.] - ------------------------------ Subject: AMX. Environment: Runs on 80x86, 680x0, Z80, 64180, and 8080/85 computers. Canada: Kadak Products Ltd 206-1847 West Broadway Vancouver, B.C., Canada V6J 1Y5 tel +1 604 734 2796 fax +1 604 734 8114 - ------------------------------ Subject: CHORUS. Environment: Distributed real-time microkernel. Runs on Intel 80x86, Motorola 68k, Motorola 88k, SPARC, MIPS R3000, Transputer T805 and T9000 simulator, and HP PA-RISC. U.S.A.: Chorus systems Inc. 15262, NorthWest Greenbrier Parkway Beaverton, OR 97006 tel +1 503 690 2300 fax +1 503 690 2320 Email: Will Neuhauser France: Chorus systemes 6, Avenue Gustave Eiffel F-78182 Saint Quentin en Yvelines Cedex tel (33) 1 30 64 82 00 fax (33) 1 30 57 00 66 Email: Marc Maathuis - ------------------------------ Subject: CX/UX, CX/SX, CX/RT. Variants: CX/UX: regular, CX/SX: secure, CX/RT: even more real-time. Environment: Runs on vnendor's NH5800 symmetric multiprocessor, with up to eight 88110 RISC processors. U.S.A.: Harris Computer Systems Division 2101 W. Cypress Creek Road Ft. Lauderdale, FL 33309-1892 tel +1 305 974 1900 fax +1 305 977 5580 - ------------------------------ Subject: DECelx and VAXELN. Environment: The DECelx Toolkit runs on DECsystems under the Ultrix O/S; targets are DECsystem, R3000 SBC (both endians) or Motorola 68k. The DECelx Toolkit also runs on DECsystems (AXP based) running DEC OSF/1. The VAXELN Toolkit runs on a VAX under the VMS operating system; target is VAX. [Note: DEC folk have stated that "VAXen is a discouraged term".] U.S.A.: Corporate Headquarters Digital Equipment Corporation 146 Main Street Maynard, Massachusetts 01754-2571 tel +1 800 344 4825 (1-800-DIGITAL) (toll free; in North America onlyl) tel +1 508 493 5111 Europe: European Headquarters Digital Equipment Corporation 12 Avenue des Morgines Case Postale 176 CH-1213 Petit-Lancy 1, Geneva Switzerland tel (41) 22-709-4111 Japan: Japan Regional Office Digital Equipment Corporation Japan Sunshine 60, P.O. Box 1135 1-1, Higashi Ikebukuro 3-chome Toshima-ku Tokyo Japan 170 tel (81) 3-3989-7111 Canada: Canadian Headquarters Digital Equipment of Canada, Ltd. 100 Herzberg Road Kanata, Ontario, Canada K2K 2A6 tel +1 613 591 4375 International: General International Area Headquarters Digital Equipment Corporation 100 Nagog Park Acton, Massachusetts 01720-3499 tel +1 508 264 7111 NOTE: Digital has offices in approximately 130 countries worldwide. - ------------------------------ Subject: HP-RT. Environment: HP-RT and its applications run on the HP 9000 Series 700rt target systems. The HP-RT Developer's Kit is hosted on HP 9000 Series 700 and 800, HP-UX (Release 9.0) systems. U.S.A.: Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94303 (800) 637-7740, (toll free; in North America only.) Canada: Hewlett-Packard (Canada) Ltd. 6877 Goreway Drive Mississauga, Ontario L4V 1MB (800) 387-3867, (toll free; in North America only.) Latin America: Hewlett-Packard Latin America Region Headquarters Monte Pelvoux No. 111-2nd Floor Lomas de Chapultepec 11000 Mexico, D.F. (525) 202-0155 Japan: Yokogawa-Hewlett-Packard Ltd. Kohrakuen Shinjuku Bld. 15-7 Nishi Shinjuku 4-Chome Shinjuku, Tokyo 160 +81-3-5371-1351 Asia Pacific Hewlett-Packard Asia Pacific Ltd. 22/F Bond Centre West Tower 89 Queensway, Central Hong Kong +852-848-7777 Australia/New Zealand: Hewlett-Packard Australia Ltd. 31-41 Joseph Street Blackburn, Victoria 3130 Melbourne, Australia +61-3-272-2895 European Headquarters: Hewlett-Packard S.A. Route du Nant-d'Avril 150 CH-1217 Meyrin 2/Geneva Switzerland +41-22-780-8111 - ------------------------------ Subject: iRMX. Environment: iRMX III: Runs on Intel 80X86-based computers iRMX for Windows: Runs on 386SX-based and later IBM and Compaq-compatibles Email: Chris Carvalho U.S.A.: Intel Corporation 5200 N.E. Elam Young Parkway Hillsboro, OR 97124 toll free (800) 438-4769 (1-800-GET-IRMX) (in North America) tel +1 408 987 8080. U.K.: Intel Corporation (UK) Ltd. Piper's Way Swindon, Wiltshire SN3 1RJ tel (44) 793 696-000 France: Intel Paris 1 Rue Edison-BP 303 78054 St.-Quentin-en-Yvelines Cedex tel (33) 1 30 57 70 00 Japan: Intel Japan K.K. Flower-Hill Shin-machi 1-23-9, Shinmachi Setagaya-ku, Tokyo 15 tel (81) 0298-47-8511 Germany: Intel Semiconductor GmbH Seidlestrasse 277 D-8000 Munchen tel (49) 089 90 99 20 - ------------------------------ Subject: LynxOS. Environment: Runs on a wide variety of platforms, including Motorola, Intel, Sun, and Hewlett Packard. (The platforms that Lynx sells are PC-AT, MVME 147, MVME 167, Intel i860, Motorola M88K, MIPS R3000 and Sparc. Lynx does not sell the HP version; it is available from HP as HP-RT.) U.S.A.: Lynx Real-Time Systems, Inc. 16780 Lark Avenue Los Gatos, CA 95030 tel +1 408 354 7770 fax +1 408 354 7085 - ------------------------------ Subject: MTOS-UX. Environment: Runs on a variety of platforms including MC680x0. U.S.A.: Industrial Programming, Inc. 100 Jericho Quadrangle Jericho, NY, 11753 toll free (800) 365-MTOS (in North America) tel +1 516 938 6600 - ------------------------------ Subject: OS-9, OS-9000. Environment: OS-9: Runs on MC68xxx processors. Self-hosted, DOS, or popular Unix cross-development supported. OS-9000: Runs on 32-bit MC680x0 and Intel 80x86 processors. Self-hosted, Sun, or HP cross-development supported. U.S.A.: Microware Systems Corporation Corporate Headquarters 1900 N.W. 114th Street Des Moines, Iowa 50325-7077 tel +1 515 224 1929 (corporate headquarters) fax +1 515 224 1352 (corporate headquarters) tel +1 408 980 0201 (western regional office) tel +1 603 929 4107 (northeastern regional office) tel +1 407 725 2840 (southeastern regional office) UK, Holland, Belgium, Luxemberg, Scandinavia: Microware Systems (UK) Limited Leylands Farm, Nobs Crook Colden Common Winchester, Hants. England, SO21 1TH tel (44) 703 601990 fax (44) 703 601991 France, Russia, Spain, Italy: Microware Systems France Chateau de la Saurine Pont de Bayeux 13590 Meyreuil France tel (33) 42 58 63 00 fax (33) 42 58 62 28 Germany: Dr. Rudolf Keil, GmbH Gerhart-Hauptmann-Str. 30 6915 Dossenheim West Germany tel (49) 6221 862091 fax (49) 6221 861954 Switzerland: Elsoft AG Zelweg 12 CH-5405 Baden-Dattwill Switzerland tel (41) 56 83 3377 fax (41) 56 83 3020 Japan Microware Systems K.K. 17-3, Sotokanda 2-Chome Chiyoda-Ku Tokyo 101, Japan tel (81) 3-3257-9000 fax (81) 3-3257-9200 Australia Microprocessor Consultants Pty. Ltd 23, Norma Road Palm Beach 2108 NSW Australia tel (61) 2 974 4917 fax (61) 2 974 4900 - ------------------------------ Subject: OS/32. Environment: Runs on Concurrent Computer Corp. machines. See 'RTU' entry for address and telephone information. - ------------------------------ Subject: PDOS. Environment: Runs on MC680x0-based computers. Development can be either self-hosted, or through cross-development from Sparc, HP, or VMS workstation, or IBM PC compatible. Email: Richard Mikesell U.S.A.: Eyring Corporation 1455 West 820 North Provo, Utah 84601 ATTN: Richard Mikesell tel +1 801 375 2434 fax +1 801 377 3850 Germany: SYSTRIX Hindenburgring 31 7900 Ulm GERMANY tel (49) 7319340-120 fax (49) 7319340-100 Holland: INTERAY Lageweg 2a JW Bergum Friesland HOLLAND tel (31) 5116-4052 fax (31) 5116-2698 Japan: HITACHI ZOSEN 1-1 Hitotsubashi 1-chome Chiyoda-ku Tokyo 100 JAPAN tel (81) 3-3217-8525 fax (81) 3-3201-0522 - ------------------------------ Subject: Precise/MPX. Environment: Runs on 80x86, 680x0, 68302. (Note, see 'Harmony' entry for research version of Precise/MPX) Email: jeremy@psti.com Canada Precise Software Technologies Inc. 301 Moodie drive Suite 308 Nepean, Ontario, Canada K2H 9C4 tel: +1 613 596 2251 fax: +1 613 596 6713 - ------------------------------ Subject: pSOS+. Environment: Software Components Group, who distributed pSOS+, have merged with Integrated Systems, Inc. See entry for pSOSystem, below. - ------------------------------ Subject: pSOS+ pSOSystem. Environment: Full scale embedded/real-time OS including pSOS+ and pSOS+m (multiprocessing) kernels, networking/multiprocessing extensions, file systems and development environment. Runs on a variety of microprocessors, including Motorola 680x0, 683xx, and 881x0; and Intel i960, 386/486 and Pentium. Requires a host workstation or PC for program development. Supported Sun4, IBM-PC or compatible, HP9000-300/400/700, HP Apollo, IBM RS6000, DECstation, and VAX/VMS. Email: scg_sales@isi.com U.S.A. and "rest of world": Integrated Systems, Inc. 3260 Jay Street Santa Clara, CA 95054 tel: +1 800 543 PSOS +1 408 980 1500 fax: +1 408 980 0400 U.K.: Integrated Systems, Ltd. First Floor, Gate House Fretherene Road, Welwyn Garden City Herts AL8 6NS England tel: +44 707 331 199 fax: +44 707 391 108 France: Integrated Systems, S.A. 1 rue du Petit Robinson 78350 Jouay-en-Josas France tel: +33 1 34 65 3732 fax: +33 1 34 65 0034 Germany: ARS Integrated Systems, GmbH Starnberger STR 22 D-8035 Gauting Muenchen, Germany tel: +49 89 850 6081 fax: +49 89 850 8918 Japan: Integrated Systems, Inc. 601 Sanpo Ebisu Building 1-2-6 EBISU MINAMI Shibuya-ku Tokyo 150 tel: +81 3 5721 0101 fax: +81 3 5721 4770 - ------------------------------ Subject: PXROS. Environment: Real-time microkernel with low-overhead interrupt structure. UNIX emulation functions such as filesystems, TCP/IP, NFS, and so forth, also available. Selfhosted, or hosted on UNIX or DOS/Windows. Runs on Intel 80386/486, Motorola 68020/30/40 and PowerPC, NSC 32k, and Siemens 80C166/167 processors. Email: Germany: [I'm still awaiting further information on this entry -- Mark] - ------------------------------ Subject: QNX. Environment: Distributed, POSIX, real-time microkernel. Runs on Intel 80x86 based processors. Also hosts MS-Windows in Standard mode. Email: Dan Hildebrand Canada: QNX Software Systems (formerly Quantum Software Systems) 175 Terence Matthews Cr. Kanata, Ontario K2M 1W8 Canada tel +1 800 363 9001 (toll-free; in North America only) tel +1 613 591 0931 fax +1 613 591 3579 Germany: Quantum Software Systems Westendstr. 19 6000 Frankfurt am Main 1 Germany tel 49-69-97546156 fax 49-69-97546110 - ------------------------------ Subject: REAL/IX. Environment: Runs on the vendor's Tri-Dimensional Series of computer systems, which use the MC680x0, MC88x00, and Intel iSBX 80386/80486 processors. VMEbus, Multibus II, and AT/EISA bus versions are available. Email: dan@modcomp.com uunet!modcomp!dan U.S.A. and Latin America: Modular Computer Systems, Inc. 1650 West McNab Road P.O.Box 6099 Ft. Lauderdale, FL 33340-6099 tel +1 305 974 1380 (for U.S.A.) tel +1 305 977 1795 (for Latin America) Canada: MODCOMP Canada, Ltd. 160 Traders Blvd. Mississauga, Ontario Canada L4Z 3K7 tel +1 416 890 0666 fax +1 416 890 0266 International (outside North & Latin America): Modular Computer Systems The Business Centre Molly Millars Lane Wokingham, Berkshire RG11 2JQ, UK tel (44) 0734-786808 fax (44) 0734-786399 - ------------------------------ Subject: RTU. Environment: Runs on Concurrent's multiprocessor systems using 680x0 (1-3) or R3000 (1-8) microprocessors. Email: Ted Swoyer North America Concurrent Computer Corporation 2 Crescent Place Oceanport, NJ 07727 toll free (800) 631-2154 (in North America) tel +1 908 870 4500 Tel. Numbers: Intl. Headquarters +1 908 758 7411 Australia (61) 2-887-1000 Belgium (32) 2-6604924 France (33) 130-853700 Germany (49) 89856030 Greece (30) 1-682-9927 Hong Kong (85) 2-880-0802 Italy (39) 39-639421 Japan (81) 3-3864-5711 Netherlands (31) 18-2038000 Singapore (65) 339-8877 Spain (34) 1-259-3911 Sweden (46) 8-733-0265 United Kingdom (44) 753-534511 - ------------------------------ Subject: SORIX 386/486. Environment: Runs on Intel 80386 and 80486 processors. Email: sorix386@norisc@kommu@Germany.EU.net sorixhot@norisc.erls01.siemens.de (common questions, prices ...) sorix386@norisc.erls01.siemens.de (detailed technical support) Germany: Siemens AG Automation Group Operating Systems and Software Technology P.O. Box 4848, W-8500 Nuremberg 1 Fed. Rep. of Germany (tel) (49) 911-8952203 (fax) (49) 911-8953735 - ------------------------------ Subject: SPOX. Environment: A Digital Signal Processor (DSP) specific kernel. It runs on all the following processors: Texas Instruments C30, C40, C50; Analog Devices 21XX, 210XX; and Motorola 56000, 96000. A host development system is required, but target code may be embedded. U.S.A.: Spectron Inc. 5266 Hollister Ave Santa Barbara, CA 93111 tel +1 805 967 0503 fax +1 805 683 4995 (note: former number listed was incorrect) - ------------------------------ Subject: SunOS. Partial information from: devil@imp.HellNet.org (Gil Tene): The Solaris 2.x kernel is a preemptive multithreaded kernel, entirely different from the SunOS 4.x kernels. I've read some of their white papers on real-time features. The new OS supports a realtime priority scheduling class above the normal unix scheduling class. They quote a "guaranteed" worst-case response time (event-to-actual-process running) of under 1ms on a Sparc 2. The newer machines (Sparc 10) should do much better, but the hard 1ms response time is good enough to qualify it as a realtime OS. - ------------------------------ Subject: Umax V, uMPX, uRTT, uARTE. Variants: Umax V: Encore's R/T enhanced multithreaded Unix uMPX: Encore's Concept compatable Kernel uRTT: "Real Time Threads" kernel (POSIX compliant interface) uARTE: Ada R/T Exec "Bare Machine Ada" Environment: Runs on vendor's 88100 multi processor family of computer systems. U.S.A.: Encore Computer Corporation 6901 West Sunrise Blvd. Fort Lauderdale, Florida 33313-4499 tel +1 305 797 5403 Canada: Encore Informatique Limitee 100 Alexis Nihon Blvd. Suite 270 St. Laurent, Quebec H4M 2N7 Canada tel +1 514 744 2854 U.K., Sweden, Holland, and Germany: Encore Computer (UK) LTD. Marlborough House Mole Business Park Randalls Road Leatherhead Surrey KT227BA England (44) 372-363363 France, Spain, and Italy Encore Computer S. A. Parc D' Activite De Bois D'Arcy Secteur Nord, Rue Michael Faraday 78180 Montigny-Le-Bretonneux France (33) 13-460-61-01 Hong Kong, Japan, and Pacific Rim: Encore Computer (Asia) Limited Room 3505 Windsor House 311 Gloucester Road Causeway Bay, Hong Kong (85) 2-576-9686 - ------------------------------ Subject: UNOS. Environment: Runs on MC680x0 and Intel 80x86 based processors. Email: usenet@frog.crds.com U.S.A.: Charles River Data Systems, Inc. 983 Concord St. Framingham, MA. 01701 tel +1 508 626 1000 fax +1 508 626 1046 [I've heard from more than one source that UNOS is no longer being actively marketed; their email address may have changed, as well. -- Mark] - ------------------------------ Subject: VAXELN. Environment: Toolkit runs on VAX under VMS operating system; target is VAX. See entry DECelx for address list. - ------------------------------ Subject: VENIX/386. Variants: Interactive SysVR3.2 + real-time extensions. Environment: Runs on 80x86 computers. U.S.A.: VenturCom 215 First Street Cambridge, MA 02142 tel +1 617 661 1230 - ------------------------------ Subject: VRTX. Environment: Runs on a wide variety of processors, including MC680x0, Intel 80x86 and 80960, and National Semiconductor series 32000. Email: mktg@ready.com U.S.A.: Ready Systems 470 Potrero Avenue P.O.Box 60217 Sunnyvale, CA 94086 toll free (800) 228-1249 (in North America) tel +1 408 736 2600 fax +1 214 991 8775 [this may be a regional office -- mcl.] Europe: Ready Systems SARL (Paris) 16 Bis Rue Grange Dame Rose 78140 Velizy-Villacoublay France tel. (33) 39 46 89 86 fax. (33) 39 46 65 68 - ------------------------------ Subject: VxWorks. Environment: Runs on a wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro. Requires a host workstation for program development. Supported host platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS. Western U.S.A.: Wind River Systems Inc. 1010 Atlantic Avenue Alameda, CA 94501 toll free (800) 545-9463 (in North America) tel +1 510 748 4100 fax +1 510 814 2010 Eastern U.S.A.: Wind River Systems, Inc. 77 North Washington St. 5th Floor Boston, MA 02114 tel +1 617 367 6567 fax +1 617 367 9295 Europe: Wind River Systems EC 27 Avenue de la Baltique Batiment B4 LP 739 Z.A. Courtaboeuf 91962 Les Ulis CEDEX tel (33) 69 07 78 78 fax (33) 69 07 08 26 Japan: WRS Japan / WRS Asia-Pacific YS Shin-Yokohama Bldg. 2-15-10 Shin-Yokohama Kouhoku-ku, Yokohama-Shi Kanagawa, 222 tel (81) 45-474-5600 fax (81) 45-474-5545 United Kingdom: WRS UK Ltd. Aston Science Park Aston Triangle Birmingham B7 4BJ tel (44) 21-359-0981 fax (44) 21-628-1889 Germany: WRS GmbH Freisinger Strasse 34 Postfach 1320 W-8045 Ismaning tel (49) 89-96-09-49-46 fax (49) 89-96-09-49-40 - ------------------------------ Subject: XLoad. Environment: Runs on 680x0 and 68332 computers. Email: Daniel Diez Switzerland: Mecos Robotics AG Gutstr. 38 CH 8400 Winterthur, Switzerland tel (..41) +52 295828 fax (..41) +52 299653 - ------------------------------ Subject: Research (non-commercial) real-time operating systems. [Note: only research RTOSes that have been packaged and are available for use outside the research institution are included. They are listed alphabetically.] - ------------------------------ Subject: Chimera 3.0 Environment: Runs on MC680X0-based single board computers. Supports i860 floating point accelerators as special purpose processors. Requires a Sun workstation for program development. Email: chimera@cmu.edu U.S.A.: Dept. of Electrical and Computer Engineering Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 ATTN: David B. Stewart tel +1 412 268 7120 fax +1 412 268 3890 - ------------------------------ Subject: Harmony Real-Time Operating System Environment: Runs on 80x86, 680x0, and 68302 processors. (Note: see 'Precise/MPX' entry for commercial version of Harmony). Email: Dr. Morven Gentleman Canada: Software Engineering Laboratory Institute for Information Technology (IIT) Building M-50 National Research Council Canada Ottawa, Ontario, Canada K1A 0R6 tel: +1 613 993 2629 fax: +1 613 952 7151 - ------------------------------ Subject: Commercial real-time toolkits. The following commercial toolkits are listed in alphabetical order. [The list is OBVIOUSLY known to be incomplete; please feel free to add others.] - ------------------------------ Subject: RTworks. Environment: RTworks is not an OS, but a high-level toolkit for building time-critical applications. It consists of a family of independent software modules developed for intelligent real- time data acquisition, data analysis, message/data distribution, and message/data display. It offers a number of sophisticated problem-solving strategies including knowledge-based systems, a point-and-click graphical user interface, temporal and statistical reasoning, and the ability to distribute and application over a network. It is built specifically to take advantage of multiple workstations distributed across a heterogeneous network in a client-server architecture. Email: Rob Chekaluk U.S.A.: Talarian Corporation 444 Castro Street, Suite 140 Mountain View, CA 94041 U. S. A. tel: +1 415 965 8050 fax: +1 415 965 9077 - ------------------------------ Subject: Contributions to comp.realtime FAQs. [Material for this posting was initially gathered and collated by David B. Stewart ; however, errors and omissions are my own responsibility -- Mark] The following folks, among others, have sent in updates or corrections: Ann-Marie St. Laurent Rob Chekaluk Martin Chorich Chris Deboer Kent Long Jeri Ann May Eric Gauthier Marc Maathuis Alan F. Perry Mitch Stanek David B. Stewart John Jay G. Tanlimco Gil Tene Michael C. Tiernan (mtiernan@world.std.com) Disclaimer: information of this nature changes rapidly. It's quite possible that it may have changed recently. In particular, this is fair warning to those who get this file from archive sources: please be sure to check the date to make sure you've got a recent version of the file. This file can be found posted every 4 weeks on comp.realtime on USENET, and cross- posted to news.answers and comp.answers. Further disclaimer: not all of the telephone numbers have been properly internationalized; perhaps one of our less USA-centric readers could help out with suggestions. :-) I welcome reactions, additions, and corrections to this posting via email at linimon@nominil.lonesome.com. - -- Mark Linimon / Lonesome Dove Computing Services / Roanoke, Virginia {chinacat,uunet}!nominil!linimon || linimon@nominil.lonesome.com - -- Mark Linimon / Lonesome Dove Computing Services / Roanoke, Virginia {chinacat,uunet}!nominil!linimon || linimon@nominil.lonesome.com "It's a small town, son, may I ask what you're doing here?" I am coming to believe that Netnews is the digital equivalent of junk food... --------------------------- End of New-News digest ********************** From rcm@ssd.ray.com Tue Oct 11 12:05:11 1994 From: Mandler Date: Tue Oct 11 12:05:17 PDT 1994 Subject: Re: Looking for RTOS evaluation/comparison file In article , Henning Pangels wrote: > >I recall that a while back someone compiled a fairly extensive >summary of features, pros and cons of several popular RTOSs - could >someone please send me pointer to that file (or the file itself:-) if >it's still around somewhere? > >Thanks a 2^20! > >-Henning >-- >Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center >Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University >------------------------------------------------------------------------------ > I know it's a non sequitur, but what does that have to do with it ? I would think that this information would be of interest to many people on this exploder. If this list is reasonably current, please pass it along. _____________________________________________________________________ | Roland C Mandler, Raytheon Equipment Division Portsmouth facility | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 | | | | I used to have my phone number here, but those unscrupulous vendor | | reps took advantage of me. Now they can send to my email address, | | and I don't have a difficult time ignoring them any more! | | | | rcm@ssd.ray.com | |_____________________________________________________________________| From kozubal@luke.atdiv.lanl.gov Tue Oct 11 12:07:09 1994 From: kozubal@luke.atdiv.lanl.gov (Andy Kozubal) Date: Tue Oct 11 12:07:16 PDT 1994 Subject: Password lookup Does anyone have a VxWorks routine that uses NIS to get a passwaord entry? I'm looking for the functional equivalent of YPMATCH(1). ----------------------------------------------------------------------- Andy Kozubal | Mail Stop H820 | Accelerator Operations and Technology Phone: (505) 667-6508 | Los Alamos National Laboratory E-mail: AKozubal@lanl.gov | Los Alamos, New Mexico 87545 ----------------------------------------------------------------------- From kozubal@luke.atdiv.lanl.gov Tue Oct 11 12:26:03 1994 From: kozubal@luke.atdiv.lanl.gov (Andy Kozubal) Date: Tue Oct 11 12:26:09 PDT 1994 Subject: Re: getting child's task id at exit time Jens Christensen writes: >Under VxWorks, when task deletion hooks get called taskIdSelf() >seems to return the taskid of the parent, and not of the child >task that is exiting and on whose behalf cleanup should be done. Normally the delete hook routine gets called in the context of the task that called taskDelete() or 'td'. However, if a task attempts to delete itself, the process is handed over to the "ExcTask" (is this called assisted suicide?). One caveat: the ExcTask is spawned without the floating point option (VX_FP_TASK). I use the same delete hook routine to clean up after any number of related tasks, and I use a linked list to keep track of their task IDs. ----------------------------------------------------------------------- Andy Kozubal | Mail Stop H820 | Accelerator Operations and Technology Phone: (505) 667-6508 | Los Alamos National Laboratory E-mail: AKozubal@lanl.gov | Los Alamos, New Mexico 87545 ----------------------------------------------------------------------- From server@wrs.com Tue Oct 11 15:15:18 1994 From: Tech Support Mail Server Date: Tue Oct 11 15:15:25 PDT 1994 Subject: SPR LIST - SPECIAL ANNOUNCEMENT !!!! VXWORKS 5.1.1 SPR LIST ====================== PLEASE READ THE SPECIAL NOTICE AT THE END OF THIS MESSAGE !!!!! Wind River Systems Technical Support is pleased to announce the availability of the new SPR list to all of our VxWorks customers. We are also launching the Technical Support Email Server through which you will be able to obtain this and other documents from tech support, such as information on VxWorks training classes and technical notes. The list can be obtained by sending email to server@wrs.com with "sprlist" anywhere in the subject line of the mail (no body of the mail required). For information on other available documents, also include the word "help" in the subject. For example, if you include: Subject: wtn09sprlisttraining you will receive Wind Technote 9, the SPR list and training information. (Please note: only VxWorks customer's can receive the SPR list). Please submit all other technical support requests to Wind River Technical Support by email to support@wrs.com, or call 800-872-4977. SPECIAL NOTICE: IF YOU ARE HAVING DIFFICULTIES RECEIVING FILES PLEASE CHECK THE FOLLOWING: 1) WE MUST HAVE YOUR EMAIL ADDRESS IN OUR RECORDS FOR YOU TO RECEIVE THE SPR LIST. PLEASE MAIL alex@wrs.com WITH YOUR VXWORKS LICENSE NUMBER AND YOUR COMPANY NAME TO UPDATE THIS ADDRESS. (This applies to all EC and US users. In Japan please contact you local distributor) 2) THE RETURN ADDRESS IN YOUR MAIL HEADER MAY DIFFER FROM YOUR ACTUAL RETURN ADDRESS. IF IN DOUBT PLEASE USE THE "Reply-To:" FIELD IN YOUR MAIL. From daemon@vxw.ee.lbl.gov Wed Oct 12 04:00:29 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Oct 12 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Oct 12 04:00:14 PDT 1994 Subject: Thanks Subject: Re: 060 VME SBC Card Subject: FOUND: RTOS evaluation/comparison file Subject: Problems with Beta GCC vxWorks compiler ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Thanks Date: Tue, 11 Oct 1994 14:19:52 GMT From: "Dan Frommer" Organization: Tel-Aviv University Computation Center Message-ID: <199410111620096356.danf@radmail.rad.co.il> References: <9410071305.AA30795@qnx.com> Sender: danf@radmail.rad.co.il Frank, First I'd like to thank you again for your help and for the information you provided; we feel that customer inputs are crucial to our success. I would appreciate it if we could schedule an additional telecon to discuss further "box" encryption/authentication solutions. I'm generally available Monday through Thursday 8:00-10:00 your time. Please let me know the best time to talk. Thanks and regards, Dan Frommer Prinicpal Software Engineer RADGuard Network Security Ltd. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 060 VME SBC Card Date: Tue, 11 Oct 1994 16:39:46 GMT From: jmg@sales.heurikon.com (James Gmeinder) Organization: Heurikon Corporation Message-ID: References: Sender: news@heurikon.com (0000-news(0000)) DNEELAY@fwbsmtp.ftwa.tasc.com writes: >Anyone intrested in providing a quote for a 68060 VME single board computer with 16M Ram, E-net, SCSI-2, 2-Serial (minimum), 1Parallel, etc. (board configuration package must be available from Verdix for VADSworks). >Please e-mail it to dneelay@tasc.com >Thanks- >Dinesh Neelay >TASC >1992 Lewis Turner Blvd, >Ft. Walton Beach, FL 32547 Heurikon makes such a board - no daughter cards needed. I'll send you a data sheet via snail mail. (If you'd like it faxed, please contact me.) thanks, - -- - -------------------------------------------------------------------------- James Gmeinder Heurikon Corporation (608) 831-5500 Application Engineer Madison, WI 53717 jmg@heurikon.com --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: FOUND: RTOS evaluation/comparison file Date: 11 Oct 1994 17:42:59 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <37bta9$7i4@news.internex.net> <37d402$76t@news.bu.edu> Followup-To: comp.realtime,comp.os.vxworks Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) To all interested parties: I found the paper "A Survey of Real-Time Operating Systems" by Kaushik Ghosh on the net. Its WWW URL is: file://ftp.cc.gatech.edu/pub/coc/tech_reports/1993/GIT-CC-93-18.ps.Z It's 60+ pages in length, so I haven't read it all yet and can't comment on the contents. - -Henning - -- Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Das Trinkgefaess, wenn einmal leer, macht keine rechte Freude mehr - W. Busch --------------------------- Newsgroups: comp.os.vxworks Subject: Problems with Beta GCC vxWorks compiler Date: Tue, 11 Oct 1994 19:35:58 GMT From: jtcummi@sandia.gov (Jeff Cummings) Organization: Sandia National Laboratories Message-ID: <1994Oct11.193558.24677@sandia.gov> Reply-To: jtcummi@sandia.gov Sender: news@sandia.gov (Usenet News Admin) Gentlemen, I am using the beta version of the GNU compiler for the Mips R3000, running on the HKV3500 board. We have recently switched to the GNU compiler and have used CCX in the past. We are currently executing the compiler with the following switches: gcc-sde -g -G 0 -mcpu=r3000 -c -o test.o -DVXWORKS -DCPU=R3000 -Ivw/h -Iinclude We are experiencing two unusual problems. The First problem is as follows: When I enable interrupts from one of our boards to the HKV3500, vxWorks exits to the shell with the following error message: interrupt: Uninitialized Interrupt! Vector number 19 (0-255). User defined interrupt Program Counter: 0x807855cc Status Register: 0x3000df04 Note that the vector number is returned as 19. We do not generate an interrupt vector at location 19. I used a VMETRO card to examine the VME bus during the transisition. As you can see from the following, the card generated a 0xc0 (decimal 192) vector address. Time BR3:0 BgL AM Address Data Size Cyc Stat ___________________________________________________________________ -4 11.59us .... ---- 09 1B010034 8000F8F8 LONG WRI OK -3 15.49us .... ---- 09 1B018808 8000007B LONG WRI OK -2 4.09us .... ---- 09 1B01882C 80000000 LONG WRI OK -1 1.646s .... ---- 09 1B01002C 8000000F LONG WRI OK TRIG 20.39us .... ---- 09 IACK=2 FFFFFFC0 ... IACK OK We have run this routine under CCX and have not seen the same problems. - ------------------------------------------------------------------------------- Jeff Cummings, Sandia National Laboratories, (505)-844-2094, jtcummi@sandia.gov MS 0503 Department 2335 - ------------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Thu Oct 13 04:00:23 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Oct 13 04:00:30 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Oct 13 04:00:11 PDT 1994 Subject: Re: 68060 SBC Subject: MV147 & MV167 Time of Day Clocks Subject: Re: X Windows Server ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: 68060 SBC Date: Wed, 12 Oct 1994 16:00:31 GMT From: dad@systemname.uucp (Don Dingee) Organization: Motorola Computer Group Marketing Message-ID: <1994Oct12.160031.25136@phx.mcd.mot.com> Reply-To: dad@caesars.phx.mcd.mot.com Sender: dad@systemname (Don Dingee) Motorola Computer Group is nearing a production release of the MVME177 VME SBC, which is a direct upgrade to the MVME167 68040 family. Early availability customers have been working with pre-release versions of the boards with good results. We expect to provide production shipments with 68060s being provided in mid-November. ^^^^^^^^^^ This board provides a 50 MHz 68060, Ethernet, SCSI, 4 serial ports, and uses the MVME167 memory modules for 4MB to 256MB of ECC memory. Requests for info can be directed to your nearest MCG sales office, or our TeleSales number is 1-800-624-6449. - -- Don Dingee, MCG Marketing dad@caesars.phx.mcd.mot.com --------------------------- Newsgroups: comp.os.vxworks,comp.sys.m68k Subject: MV147 & MV167 Time of Day Clocks Date: Wed, 12 Oct 1994 21:02:02 GMT From: dwp@mrst.com (David W. Penfield) Organization: MRS Technology, Inc. Message-ID: <1994Oct12.210202.2491@mrst.com> Does anyone know where I could find drivers for the the MK48T02/MK48T08 time of day clock chips that are on the MV147/MV167 boards? Are there any anywhere on the net, or does anyone have a descritption of how to program these chips? Thanks, - ------------------------------------------------------------------------- David W. Penfield MRS Technology, Inc. (508) 250-0450 10 Elizabeth Drive Fax: (508) 250-0102 Chelmsford, MA 01824 dwp@mrst.com - ------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: X Windows Server Date: Wed, 12 Oct 1994 22:31:54 GMT From: owen@nosc.mil (Wallace E. Owen) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Oct12.223154.13463@nosc.mil> References: <9410101510.AA05608@power.amasd.anatcp.rockwell.com> Sender: news@nosc.mil In article <9410101510.AA05608@power.amasd.anatcp.rockwell.com>, Bob Guthrie wrote: >Does anybody offer software to make a single board computer, running >VxWorks 5.1.1 an X Windows Server ? Preferably Wind River. > > Robert Guthrie VisiCom Labs sells a product called "VX-Windows for vxWorks, supplying both client- and server- level software. Client software includes development libraries for X11 and the X toolkit (Xt). A separate package supplies Motif headers and linkable libraries. The server software is available to support a number of embedded graphics con- trollers, from frame buffers to accelerators. Contact Gene Kennon at VisiCom in San Diego (619) 457-2111 or gene_kennon@visicom.com. I work for VisiCom, but have never had occasion to use this product so this isn't a recommendation. -- Wallace Owen owen@visicom.com or owen@nosc.mil --------------------------- End of New-News digest ********************** From rhin!chrism@lbl.gov Thu Oct 13 05:51:31 1994 From: rhin!chrism@lbl.gov Date: Thu Oct 13 05:51:38 PDT 1994 Subject: Re: X Windows Server Hi All, there is a product called VxWindows. It includes X11R5 client and server software. It is available on different architectures and chipsets. It is available through WRS. Ask your local WRS representative for more information. Best regards Christoph Marscholik, FAE Wind River Systems GmbH Freisinger Strasse 34 85737 ISMANING GERMANY +49 89 96 09 49 43 phone +49 89 96 09 49 40 fax +49 161 28 32 114 car phone Email: chrism@wrsec.fr ______________________ end of message __________________________________________ From ken@esd.ray.com Thu Oct 13 08:14:51 1994 From: ken@esd.ray.com (Swimming Man Burning) Date: Thu Oct 13 08:14:58 PDT 1994 Subject: unbuffered socket send [resend of bounced mail] hi - we're sending variable-length messages via a socket to a remote data collection box it's imperative that the sends happen as they are generated however, it appears the message data may be getting buffered until there is enough to output (or perhaps a timeout occurs) using vxWorks 5.1.1 (under VADSworks) on a 68040 tried doing an FIOFLUSH ioctl call for the socket after the send but that didn't seem to help any suggestions? TIA ps: is there a list of what the ioctl functions mean, and what there arguments are? didn't see it after rtfm ------------------------------------------------------------------ Ken Balmy Too fast to live Raytheon ESD Too young to die ken@esd.ray.com Bye, bye ^D B{= ------------------------------------------------------------------ From hebo@mbari.org Thu Oct 13 08:22:17 1994 From: Bob Herlien Date: Thu Oct 13 08:22:23 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > Does anyone know where I could find drivers for the the MK48T02/MK48T08 > time of day clock chips that are on the MV147/MV167 boards? Are there any > anywhere on the net, or does anyone have a descritption of how to > program these chips? Download usrTime.shar from the vxWorks archives. This is a unix-compatible time library, containing functions like gettimeofday(), settimeofday(), etc. It includes drivers for the MK48T08 chip as implemented on the MVME-162 CPU. -------------------------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@mbari.org From seaweed!bob@netcom.com Thu Oct 13 08:35:38 1994 From: bob schulman Date: Thu Oct 13 08:35:44 PDT 1994 Subject: Re: X Windows Server >Does anybody offer software to make a single board computer, running >VxWorks 5.1.1 an X Windows Server ? Preferably Wind River. Seaweed Systems offers a suite of high-performance X servers and suite of client-side libraries and clients for the X Window System. This software is X11R6 (which was released by the X Consortium last April). This software has been tailored to the needs of the embedded market and is structured to prevent leaks of various system resources (memory, file descriptors, etc.). Client side code includes all the core X libraries (Xlib, Xt, Xaw, Xext, XIE, etc.) and the Motif library as well. Various clients, including xterm, mwm, and twm are also included. Source and object licenses are both available for the client-side and server-side products. Note that the server-side source license includes source to the entire server and not just to the graphics drivers. For more information, please contact info@seaweed.com Bob Schulman bob@seaweed.com (510) 482-3575 From mea@mclean.sparta.com Thu Oct 13 11:51:18 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Thu Oct 13 11:51:25 PDT 1994 Subject: Re: unbuffered socket send Greetings! Ken Balmy writes: > ... > it's imperative that the sends happen as they are generated > > however, it appears the message data may be getting buffered until > there is enough to output (or perhaps a timeout occurs) > > using vxWorks 5.1.1 (under VADSworks) on a 68040 > > tried doing an FIOFLUSH ioctl call for the socket after the send > but that didn't seem to help > > any suggestions? Yes. What you're seeing is a result of the TCP code wanting to combine packets together to save on the protocol overhead. To turn this off, simply use: int true = TRUE; status = setsockopt(sockFd, IPPROTO_TCP, TCP_NODELAY, &true, sizeof(true)); Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mwbrown@somnet.sandia.gov Thu Oct 13 15:54:06 1994 From: "Matthew W. Brown" Date: Thu Oct 13 15:54:12 PDT 1994 Subject: BUS ERROR, memcpy(), etc VxPerts, Maybe someone can help me out here. I am transfering some data from a VME A/D board's Dual Port Ram (DVME601E). The way that I have been doing this is slow (but works)--see below. char dpr[32764]; char *place_ptr; unsigned i; place_ptr = buff_p; for(i=0;i Allen-Bradley Subject: Work Panic with serial port and Modem Subject: Re: VME <-> Allen-Bradley Subject: DOS File System Glitches Subject: 68360 SMC-UART Driver Available Now ! Subject: Re: Cross-debugging (gdb) in emacs? ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.sys.m68k Subject: Re: MV147 & MV167 Time of Day Clocks Date: 13 Oct 1994 11:35:04 GMT From: gary@eflandnc.efland.uu.net (Gary Thomas) Organization: UUNET Communications Message-ID: <37j618$h2r@news.UU.NET> References: <1994Oct12.210202.2491@mrst.com> Followup-To: comp.os.vxworks,comp.sys.m68k David W. Penfield (dwp@mrst.com) wrote: : Does anyone know where I could find drivers for the the MK48T02/MK48T08 : time of day clock chips that are on the MV147/MV167 boards? Are there any : anywhere on the net, or does anyone have a descritption of how to : program these chips? : Thanks, : ------------------------------------------------------------------------- : David W. Penfield : MRS Technology, Inc. (508) 250-0450 : 10 Elizabeth Drive Fax: (508) 250-0102 : Chelmsford, MA 01824 dwp@mrst.com : ------------------------------------------------------------------------- These chips are just battery backed-up SRAMs with a few special bytes which correspond to the current time (m/d/y/h/m/s). To use them, all you need to do is access the appropriate byte (no funny masking/shifting/etc)! You should have [or can get from Motorola] a data sheet on the part. If you still need help, email me & I can send you some code. - -------------------------------------------------------------------------- Gary Thomas | MLB Associates | If you can read this, then it's (919) 732-6560 (day) 732-6560 (night) | not *my* signature! email: gary@efland.UU.NET | uunet!eflandnc!gary | - -------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: unbuffered socket send Date: 13 Oct 1994 17:07:21 GMT From: jls@corse.inria.fr (Jean-Luc Szpyrka) Organization: Inria Sophia Antipolis Message-ID: <37jpg9$30i@sophia.inria.fr> References: <9410131514.AA03453@boromir.esd.ray.com> Reply-To: jls@sophia.inria.fr In article <9410131514.AA03453@boromir.esd.ray.com>, ken@esd.ray.com (Swimming Man Burning) writes: |> [resend of bounced mail] |> |> hi - |> |> we're sending variable-length messages via a socket to a remote |> data collection box |> |> it's imperative that the sends happen as they are generated |> Do just like in a "normal" Unix program, you have to put the socket in TCP_NODELAY mode. Just after the socket initialisation, you use setsockopt to do it : Example (compile under VxWorks with the -DVXWORKS flag) /*---- start ----*/ /* I'm not sure that all the include are necessary */ #include #include #include #include #include #include procedure() { int fd; int one=1; #ifndef VXWORKS struct protoent *p; #endif /* init the tcp connection, fd is the file descriptor of your socket */ ....... /* TCP_NODELAY mode */ #ifdef VXWORKS if( setsockopt(fd, 6, TCP_NODELAY, &one, sizeof(one)) < 0) { logMsg("setsockopt problem"); } #else /* in Unix, you should do the following to get the tcp protocol number (even if you know it is 6) */ p = getprotobyname("tcp"); if( p && setsockopt(fd, p->p_proto, TCP_NODELAY, &one, sizeof(one)) < 0) { perror("setsockopt"); } #endif } /*---- end ----*/ ------------------------------------------------------------------------- Jean-luc Szpyrka "Taste is the enemy of Art" Email: jls@sophia.inria.fr Tel: (33) 93 65 79 69 Fax: (33) 93 65 78 45 INRIA - 2004 route des lucioles - BP 93 - SOPHIA-ANTIPOLIS cedex (France) ------------------------------------------------------------------------- --------------------------- Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks Subject: VME <-> Allen-Bradley Date: Thu, 13 Oct 1994 17:57:14 GMT From: mcgehee@noao.edu (Peregrine M. McGehee) Organization: National Optical Astronomy Observatories, Tucson AZ Message-ID: <1994Oct13.175714.28883@noao.edu> Sender: mcgehee@noao.edu () I am being supplied an Allen-Bradley PLC 5/25 based local control system and need to integrate this into a VxWorks/VMEbus control system. What are my hardware/software options?? Thanks, Peregrine - -- _______________________________________________________________________________ Peregrine M. McGehee Controls Group Gemini 8-Meter Telescopes Project PO Box 26732, Tucson, AZ 85726-2632 E-mail: mcgehee@gemini.edu Phone: (602) 321-3423 --------------------------- Newsgroups: comp.os.vxworks Subject: Work Panic with serial port and Modem Date: Thu, 13 Oct 1994 18:52:41 GMT From: carroll@ast.saic.com (John Carroll) Organization: SAIC Message-ID: <1994Oct13.185241.16350@ast.saic.com> Reply-To: carroll@ast.saic.com Sender: news@ast.saic.com I am posting this message for a friend. Please reply to him at meeks@sqi.com. I'm writing a serial port and external modem driver program for an Mvme167 with VxWorks 5.1.1. Inside file cd2400Serial.c I have written my own function that is very much like WindRivers tyCoInitChannel(). I initialize the appropriate serial channel, #2 enabling interrupts for assertion of the Carrier Detect signal. After the channel is initialized I write the necessary modem setup commands out through my serail port. All of which appears to work fine,based on the lights on my modem, I place it in auto-answer mode. Next, I call my modem from a PC and my carrier detect light comes on and I receive a kernel work queue overflow. According to WindRiver, kernel work queue overflows are a result of too many interrupts or an interrupt is not being acknowledged correctly. All my ISR does, at this time, is disable CD assertion interrupts, write a zero to the serial port con- troller chips Modem End of Interrupt register and call logMsg. One other test I did was to enable interrupts for deassertion of CD. With this I was able to make the call. Then I read the channels Modem Signal Value Register (MSVRRTS) which indicated that CD had been asserted. Then from the remote, I terminated the call and received the interrupt and a work queue overflow. If anyone can offer any insight, I would be very grateful. Please respond directly, as I can not access the newgroup and am having a friend post this for me. Thanks in advance, Dave Meeks email address: meeks@sqi.com --------------------------- Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks Subject: Re: VME <-> Allen-Bradley Date: 13 Oct 1994 20:16:49 GMT From: gary@eflandnc.efland.uu.net (Gary Thomas) Organization: UUNET Communications Message-ID: <37k4jh$qvu@news.UU.NET> References: <1994Oct13.175714.28883@noao.edu> Followup-To: comp.arch.bus.vmebus,comp.os.vxworks Peregrine M. McGehee (mcgehee@noao.edu) wrote: : I am being supplied an Allen-Bradley PLC 5/25 based local control : system and need to integrate this into a VxWorks/VMEbus control system. : What are my hardware/software options?? : Thanks, : Peregrine : -- : _______________________________________________________________________________ : Peregrine M. McGehee Controls Group : Gemini 8-Meter Telescopes Project PO Box 26732, Tucson, AZ 85726-2632 : E-mail: mcgehee@gemini.edu Phone: (602) 321-3423 A&B has a VMEbus card which can talk to your PLC - I think it's called an 8003. - -------------------------------------------------------------------------- Gary Thomas | MLB Associates | If you can read this, then it's (919) 732-6560 (day) 732-6560 (night) | not *my* signature! email: gary@efland.UU.NET | uunet!eflandnc!gary | - -------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: DOS File System Glitches Date: 13 Oct 1994 15:47:31 -0600 From: dtubbs@xmission.com (dtubbs) Organization: XMission Public Access Internet (801 539 0900) Message-ID: <37k9tj$l73@xmission.xmission.com> I'm having some very strange problems with the VxWorks 5.1.1 implementation of the DOS file system. After creating the file system, the directories (and files) on the disk seem to come and go. One minute I see them when I do a 'ls", and the next time they're gone. This happens when I execute 'ls' from the CL and when I execute 'ls' from inside a program. the "opendir()" and "readdir()" functions have the same problem - the entries seem to come and go. I've tried this on multiple systems and they all seem to behave the same. I created the file system with th AUTOSYNC option, so there should not be any difference from the physical device and the local image in memory. At this point in time, I believe this to be a NASTY bug in 5.1.1, since it reared its ugly head since our company upgraded from 5.0.2... Any Ideas??? Dave Tubbs Evans & Sutherland Computer Corporation EMAIL: dtubbs@xmission.com PHONE: 801.582.5847 ext. 6419 --------------------------- Newsgroups: comp.os.vxworks Subject: 68360 SMC-UART Driver Available Now ! Date: Thu, 13 Oct 1994 21:48:57 GMT From: btadlock@metronet.com (Bobby Tadlock) Organization: Texas Metronet, Internet for the Individual 214-705-2901 (info) Keywords: 68360,SMC-UART Message-ID: Ive written the low level code for the Motorola 68360 SMC Ports in UART mode. This code is in 68360 assembly language. If interested contact me at: btadlock@metronet.com or 214-596-3683 Plano, TX - -- ******************************************************** * Bob Tadlock Voice 214-596-3104 * * btadlock@metronet.com Data/Fax 28.8K 214-596-3683 * --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Cross-debugging (gdb) in emacs? Date: 14 Oct 1994 06:52:16 GMT From: hjb@hybrid.com (Hwajin Bae) Organization: Hybrid Networks, Cupertino, CA Message-ID: <37l9r0$76n@hybrid.com> References: Reply-To: hjb@hybrid.com (Hwajin Bae) In article mre@lpf.org (Mike Elliott) writes: >Problem: > How to use gdb in a cross-debugging environment from within emacs. > >It seems to me it should be quite straightforward to use gdb from >within emacs for cross-debugging in a manner similar to its >common use for self-hosted debugging. It will not work identically >because M-x gdb prompts for a program to debug, which doesn't allow >for the establishment of cross-debugging via a 'target vxworks 68kbox' >command. this can be accomplished by modifying gdb.el program. look under your lisp code directory. the (defun gdb .... can be changed to not prompt for the file name. and the gdb-command-name can be changed to point to a different gdb command as well (if you have a special version of gdb for vxworks). i used to do this all the time... hwajin PEACEFUL STAR --------------------------- End of New-News digest ********************** From singer@osfrt.mro1.dec.com Fri Oct 14 04:57:10 1994 From: singer@osfrt.mro1.dec.com Date: Fri Oct 14 04:57:17 PDT 1994 Subject: Re: BUS ERROR, memcpy(), etc > Submitted-by mwbrown@somnet.sandia.gov Thu Oct 13 15:54:06 1994 > Submitted-by: "Matthew W. Brown" > > VxPerts, > > Maybe someone can help me out here. I am transfering some data from a > VME A/D board's Dual Port Ram (DVME601E). The way that I have been doing > this is slow (but works)--see below. > > char dpr[32764]; > char *place_ptr; > unsigned i; > > place_ptr = buff_p; > > for(i=0;i dpr[i] = *place_ptr; > > A much faster way would be to use memcpy() as below > > memcpy(&dpr[0],place_ptr,buf_len); > > Unfortunately, when I use memcpy(), I get a bunch of bus errors. > I have also seen this when I do a low level write with the board's > Dual Port Ram as the source. > > I had initially thought that I needed to change the boards address > modifier selection; however, the way the jumper is set, I should have > Standard non-privileged data access, Standard non-privileged program access, > Standard supervisory data access, and Standard supervisory program access. > > Anyway, I have no idea why I can copy the memory explicitly (slowly), but not > using memcpy() of write(). Can anyone clue me in here? > > Thanks, > Matthew Brown > mwbrown@sandia.gov > memcpy calls bcopy which if both source and dest are on long boundries will use and equivilent of *(long *)dest++ = *(long *)source++; This wont work with a device that only responds to D16 cycles. Use bcopyBytes or bCopyShorts instead. ------------------------------------------------------------------------------- Matthew R. Singer LM Technology Systems Engineer Systems & Software Consulting singer@osfrt.mro1.dec.com VxWorks/Unix/MS-DOS/X Window/Motif 508-467-9108 508-877-8736(v) 508-877-8756(fax) ------------------------------------------------------------------------------- From mwbrown@somnet.sandia.gov Fri Oct 14 08:30:56 1994 From: "Matthew W. Brown" Date: Fri Oct 14 08:31:02 PDT 1994 Subject: BUS ERROR & memcpy() Many thanks to Matthew Singer and Lawrence T. Hoff who both correctly diagnosed the problem (my card responds to D16) and provided a solution--the use of bcopyBytes(). I tried it out this morning and it works like a champ. (Seems so obvious in hindsight...) Thanks to the others who also provided suggestions. Matthew Brown mwbrown@sandia.gov From fbh@vlsi50.gsfc.nasa.gov Fri Oct 14 08:48:32 1994 From: fbh@vlsi50.gsfc.nasa.gov (Francis B. Hallahan) Date: Fri Oct 14 08:48:40 PDT 1994 Subject: RE: BUS ERROR, memcpy(), etc >From: "Matthew W. Brown" >Maybe someone can help me out here. I am transfering some data from a >VME A/D board's Dual Port Ram (DVME601E). The way that I have been doing >this is slow (but works)--see below. > >...code deleted > >A much faster way would be to use memcpy() as below > > memcpy(&dpr[0],place_ptr,buf_len); > >Unfortunately, when I use memcpy(), I get a bunch of bus errors. >I have also seen this when I do a low level write with the board's >Dual Port Ram as the source. > >I had initially thought that I needed to change the boards address >modifier selection; however, the way the jumper is set, I should have >Standard non-privileged data access, Standard non-privileged program access, >Standard supervisory data access, and Standard supervisory program access. > >Anyway, I have no idea why I can copy the memory explicitly (slowly), >but not using memcpy() of write(). Can anyone clue me in here? I've had lot's of fun;-) with the vxWorks bcopy routine on a custom 68040 board. With bcopy vxWorks tries to do the maximum bus transfer that the cpu will allow. For the 68040 this is a MOVE16 instruction; however, our VME hardware generates a BUS error for this instruction. I had to use the bAlib.o from the vxWorks library for our 68030 BSP. My guess from the description of your problem is that your A/D board does not support the kind of memory transfer that memcpy is trying. VxWorks does provide the routines bcopyBytes, bcopyWords, and bcopyLongs to allow you to specifically set the size of the transfer. It's worth noting though that bcopyBytes is not going to be any faster than your code. In any case your transfer speed cannot be faster than what your A/D board will support Hope this helps, Frank Hallahan ----------------------------------------------------------------------- | Frank Hallahan | Hallahan@gsfc.nasa.gov | | Computer Sciences Corporation | fbh@vlsi.gsfc.nasa.gov | | at Nasa Goddard Space Flight Center | Phone (301) 286 7064 | ----------------------------------------------------------------------- From mjeronis@astro.ge.com Fri Oct 14 11:06:24 1994 From: Mike Jeronis Date: Fri Oct 14 11:06:31 PDT 1994 Subject: Comments/Suggestions appreciated Hello, We are fast approaching the deadline for the delivery of a system that we are currently developing. The reason I'm posting is because I'm concerned that some of the assumptions that were made months ago might come back and bite us. Currently our system consists of two SBCs (Force 3CEs) and a handful of slave cards. One of the SBCs is running vxWorks and our real-time app., the other is running Solaris. We have requirements to support a SCSI harddisk, Tape drive, and Floppy. We also have to provide a Graphical User I/F (X-windows). Initially, we planned on implementing the design utilizing one SBC running vxWorks, but after several months into the design several issues developed that led us to pursue the addition of the Solaris Workstation. These issues were: 1. the X-windows Server issues. 2. vxWorks driver support for DATs. 3. the system is heavily dependent on data files and databases, this required us to provide online file editing capability. 4. easier integration of the scsi devices. 5. the idea of a full up workstation in the box was favorable. We felt that the addition of the Solaris workstation would reduce our effort in many of the areas, provide the user with the file editing capability and offload the X server from the real-time SBC. The two SBCs are connected over the network and the board running vxWorks boots via the harddisk connected to the board running Solaris. One little (but significant) requirement that I failed to mention and we failed to consider several months ago, is that the system needs to powerup and our application started without any manual intervention. This means that the Solaris workstation (our vxWorks host) will need to come up automatically and Reliably. My concern: We have just started to integrate the Solaris workstation and the issue of the automatic startup is something that our Unix people feel is possible, but reliable bootup is in question. I'm curious to know if anybody is utilizing this configuration and what is required to configure the Solaris system to perform the way we need it. I would also appreciate any comments on the basic premise of the design and any suggestions for a backup. Thanks, ********************************************************************** * Michael Jeronis email: mjeronis@astro.ge.com * * Martin Marietta Astro Space phone: (609) 490-7120 * * Princeton, NJ * ********************************************************************** From mick@starlab.lbl.gov Fri Oct 14 13:26:18 1994 From: mick@starlab.lbl.gov (Mike Michnovicz) Date: Fri Oct 14 13:26:24 PDT 1994 Subject: unsubscribe unsubscribe From daemon@vxw.ee.lbl.gov Sat Oct 15 04:00:28 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Oct 15 04:00:37 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Oct 15 04:00:12 PDT 1994 Subject: Apple-Talk Driver Subject: Re: Looking for RTOS evaluation/comparison file Subject: [Q] Renaming directories in the dosFs... Subject: Realtime software engineering positions available ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Apple-Talk Driver Date: 14 Oct 1994 19:46:56 GMT From: ericm@gold.gvg.tek.com (Eric McLaughlin) Organization: The Grass Valley Group, Inc. Message-ID: <37mn7g$3bq@gv-gate.gvg.tek.com> Reply-To: ericm@gold.gvg.tek.com Hi, I'm looking for an Apple-Talk network interface/driver for VxWorks. Is there one available? - ------------------------------------------- | | | Eric McLaughlin | | The Grass Valley Group | | P.O. box 1114 | | Grass Valley, CA. 95945-1114 | | email: ericm@iceman.gvg.tek.com | | Phone: (916) 478-3863 | - ------------------------------------------- --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: Looking for RTOS evaluation/comparison file Date: Fri, 14 Oct 94 14:48:31 GMT From: danh@qnx.com (Dan Hildebrand) Organization: QNX Software Systems Message-ID: <9kw0vdr@qnx.com> References: <37bta9$7i4@news.internex.net> <37d402$76t@news.bu.edu> In article <37d402$76t@news.bu.edu>, maohai huang wrote: >> Two QNX papers are available via anonymous FTP from ftp.cse.ucsc.edu >> (128.114.134.19): >> >> /pub/qnx-paper.ps.Z "An Architectural Overview of QNX" >Note: that's /pub/qnx/qnx-paper.ps.Z Additional papers are also available from quics.qnx.com:/pub/papers. - -- Dan Hildebrand danh@qnx.com QNX Software Systems, Ltd. phone: (613) 591-0931 x204 (voice) 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 --------------------------- Newsgroups: comp.os.vxworks Subject: [Q] Renaming directories in the dosFs... Date: 14 Oct 1994 10:58:43 -0700 From: gnn@tx.abekas.com (George Neville-Neil) Organization: Abekas Video Systems, Inc. Keywords: dos Message-ID: Hi Folks, I've just been in contact with the folks at Wind River about this problem and they've made it a "request for enhancement." I need to be able to rename a directory in the dos file system. On my project we store a lot of data (i.e. up to several megabytes) in a directory and the user sees this as one file. They'd like to be able to rename that file (which is a directory) and it is necessary that this does not take a long time. A long time is the time it takes to recursively copy the whole directory and then delete the old one. Any pointers to code dealing with this would be greatly appreciated. I looked in the archive and did not see anything of use in this, but I could have missed something. Thanks, George - -- George V. Neville-Neil work: gnn@abekas.com home:gnn@netcom.com Home Page: ftp://ftp.netcom.com/pub/gnn/gnn.html --------------------------- Newsgroups: comp.os.vxworks Subject: Realtime software engineering positions available Date: Fri, 14 Oct 1994 22:55:54 GMT From: elr@netcom.com (Eric Rabinowitz) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: PANORAMIC SYSTEMS Panoramic Systems is an engineering firm dedicated to supporting realtime and embedded systems engineering on the West Coast. We are looking for for full and part time Software Engineers to join our organization. Candidates should be seasoned 'senior' engineers in the world of realtime design. Recent college graduates will not be considered, please do NOT apply! We are looking for people who can comunicate effectively with our customers and produce quality work in a reasonable time frame. Here is our wish list: - ----------------------------------------------------- Experience writing realtime os applications with Unix cross development tools. Experience with writing device drivers for Unix and/or realtime operating systems. Hands on knowledge of C++ is a plus, C is mandatory. Knowledge of In-circuit emulators, romulators, logic analyzers and reading schematics is a plus. Experience with GUI's such as X-Windows and Microsoft Windows is a plus. Please FAX your resume to: 408-257-0982 or e-mail an ascii version to elr@netcom.com - -- Eric Linn Rabinowitz Panoramic Systems CA 408-289-7757 elr@netcom.com WA 206-689-1707 --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Oct 16 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Oct 16 04:00:31 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Oct 16 04:00:13 PDT 1994 Subject: BUS ERROR & memcpy() Subject: Re: BUS ERROR, memcpy(), etc Subject: Comments/Suggestions appreciated Subject: unsubscribe ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: BUS ERROR & memcpy() Date: 14 Oct 94 06:32 GMT+0300 From: mwbrown@somnet.sandia.gov Message-ID: <199410141532.JAA14150@somnet.san> Sender: Notesfile to Usenet Gateway Many thanks to Matthew Singer and Lawrence T. Hoff who both correctly diagnosed the problem (my card responds to D16) and provided a solution--the use of bcopyBytes(). I tried it out this morning and it works like a champ. (Seems so obvious in hindsight...) Thanks to the others who also provided suggestions. Matthew Brown mwbrown@sandia.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Re: BUS ERROR, memcpy(), etc Date: 14 Oct 94 18:48 GMT+0300 From: fbh@vlsi50.gsfc.nasa.gov Message-ID: <9410141548.AA02630@vlsi50.gsfc.n> References: <199410132256.QAA09803@somnet.san> Sender: Notesfile to Usenet Gateway >From: "Matthew W. Brown" >Maybe someone can help me out here. I am transfering some data from a >VME A/D board's Dual Port Ram (DVME601E). The way that I have been doing >this is slow (but works)--see below. > >...code deleted > >A much faster way would be to use memcpy() as below > > memcpy(&dpr[0],place_ptr,buf_len); > >Unfortunately, when I use memcpy(), I get a bunch of bus errors. >I have also seen this when I do a low level write with the board's >Dual Port Ram as the source. > >I had initially thought that I needed to change the boards address >modifier selection; however, the way the jumper is set, I should have >Standard non-privileged data access, Standard non-privileged program access, >Standard supervisory data access, and Standard supervisory program access. > >Anyway, I have no idea why I can copy the memory explicitly (slowly), >but not using memcpy() of write(). Can anyone clue me in here? I've had lot's of fun;-) with the vxWorks bcopy routine on a custom 68040 board. With bcopy vxWorks tries to do the maximum bus transfer that the cpu will allow. For the 68040 this is a MOVE16 instruction; however, our VME hardware generates a BUS error for this instruction. I had to use the bAlib.o from the vxWorks library for our 68030 BSP. My guess from the description of your problem is that your A/D board does not support the kind of memory transfer that memcpy is trying. VxWorks does provide the routines bcopyBytes, bcopyWords, and bcopyLongs to allow you to specifically set the size of the transfer. It's worth noting though that bcopyBytes is not going to be any faster than your code. In any case your transfer speed cannot be faster than what your A/D board will support Hope this helps, Frank Hallahan - ----------------------------------------------------------------------- | Frank Hallahan | Hallahan@gsfc.nasa.gov | | Computer Sciences Corporation | fbh@vlsi.gsfc.nasa.gov | | at Nasa Goddard Space Flight Center | Phone (301) 286 7064 | - ----------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Comments/Suggestions appreciated Date: 14 Oct 94 13:01 GMT+0300 From: mjeronis@astro.ge.com Message-ID: <199410141801.OAA00576@a9927.astr> Sender: Notesfile to Usenet Gateway Hello, We are fast approaching the deadline for the delivery of a system that we are currently developing. The reason I'm posting is because I'm concerned that some of the assumptions that were made months ago might come back and bite us. Currently our system consists of two SBCs (Force 3CEs) and a handful of slave cards. One of the SBCs is running vxWorks and our real-time app., the other is running Solaris. We have requirements to support a SCSI harddisk, Tape drive, and Floppy. We also have to provide a Graphical User I/F (X-windows). Initially, we planned on implementing the design utilizing one SBC running vxWorks, but after several months into the design several issues developed that led us to pursue the addition of the Solaris Workstation. These issues were: 1. the X-windows Server issues. 2. vxWorks driver support for DATs. 3. the system is heavily dependent on data files and databases, this required us to provide online file editing capability. 4. easier integration of the scsi devices. 5. the idea of a full up workstation in the box was favorable. We felt that the addition of the Solaris workstation would reduce our effort in many of the areas, provide the user with the file editing capability and offload the X server from the real-time SBC. The two SBCs are connected over the network and the board running vxWorks boots via the harddisk connected to the board running Solaris. One little (but significant) requirement that I failed to mention and we failed to consider several months ago, is that the system needs to powerup and our application started without any manual intervention. This means that the Solaris workstation (our vxWorks host) will need to come up automatically and Reliably. My concern: We have just started to integrate the Solaris workstation and the issue of the automatic startup is something that our Unix people feel is possible, but reliable bootup is in question. I'm curious to know if anybody is utilizing this configuration and what is required to configure the Solaris system to perform the way we need it. I would also appreciate any comments on the basic premise of the design and any suggestions for a backup. Thanks, ********************************************************************** * Michael Jeronis email: mjeronis@astro.ge.com * * Martin Marietta Astro Space phone: (609) 490-7120 * * Princeton, NJ * ********************************************************************** --------------------------- Newsgroups: comp.os.vxworks Subject: unsubscribe Date: 14 Oct 94 23:22 GMT+0300 From: mick@starlab.lbl.gov Message-ID: <9410142022.AA25015@starlab.plk.a> Sender: Notesfile to Usenet Gateway unsubscribe --------------------------- End of New-News digest ********************** From leonid@rst.co.il Sun Oct 16 06:42:04 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Sun Oct 16 06:42:12 PDT 1994 Subject: Re: Solaris bootup etc. >From mjeronis@astro.ge.com Fri Oct 14 11:06:24 1994 >... >We have just started to integrate the Solaris workstation and the issue >of the automatic startup is something that our Unix people feel is possible, >but reliable bootup is in question. I'm curious to know if anybody is >utilizing this configuration and what is required to configure the Solaris >system to perform the way we need it. >I would also appreciate any comments on the basic premise of the design >and any suggestions for a backup. Solaris is a desktop, so is Windows and Mac, and they pretty much rely on the fact that there is a human being around, thus human intervention is assumed to be available in the design of these systems. Here are the things that can go wrong: 1. The Unix system needs a logon to start running graphical applications. There are many industrial machines that live with that kind of arequirement. This could be circumvented, but I have;t seen anyone that done it so far. 2. The boot sequence may fail due to disk inconsistencies created by a power failure. Usually the operator is prompted before files or directories are removed. 3. Erasure or corruption of NVRAM will cause boot to fail (you can call this a hardware problem though). 4. It takes very long to boot Solaris (5-15 minutes). 5. If a network is connected, this could become the primary reason for a boot sequence to fail. That's all I could remember right now, and I am sure there are more. You can not replace VxWorks with Solaris or vice versa, mixing them sure offers some benefits, and some bottle necks too. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel Cell: +972-50-307-142 Wind River Systems Distributor E-Mail: leonid@rst.co.il From leonid@rst.co.il Mon Oct 17 03:36:22 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Mon Oct 17 03:36:30 PDT 1994 Subject: light-wight GUI for VxWorks A potential customer is looking for a light-weight GUI (Graphical User Interfac) library for VxWorks, which is not based on X-Windows, thus more suitable for low-cost embedded systems. The hardware architecture is a generic x86 PC equipped with VGA compatible graphics. Commercial offers are wlcome. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel Cell: +972-50-307-142 Wind River Systems Distributor E-Mail: leonid@rst.co.il From daveg@zeus.datasrv.co.il Mon Oct 17 10:46:18 1994 From: David Gasul Date: Mon Oct 17 10:46:28 PDT 1994 Subject: Queues in VxWorks Is there a general purpose library for handling queues in VxWorks (I couldn't find one in the Reference guide)? A freeware? Thx, David Gasul Email: daveg@zeus.datasrv.co.il Telegate Ltd. Voice: +972-3-5388634 Aryt Building FAX: +972-3-5335877 7 Haplada St. 60218 Or-Yehuda, ISRAEL From siveland@msmail3.hac.com Mon Oct 17 13:25:00 1994 From: "Iveland, Scott T" Date: Mon Oct 17 13:25:06 PDT 1994 Subject: Ada & 1750A Person From: Iveland, Scott T on Fri, Oct 14, 1994 4:10 PM Subject: Ada & 1750A Person To: vxexpolder ---Wanted--- A real time embedded systems person with Ada and 1750A experience. We need contract help with a software/hardware integration task on a Meteorlogical Satellite Sensor. The flight software is written with a TLD Ada cross compiler hosted on an HP workstation. The emulator being used is from Tasco. If you can help us out starting IMMEDIATELY let us know! The task will last 4-6 months. Send a short description of your talents and a way to contact you. Thanks! Send responses to Rod Ontjes @ 805-562-7590 or rontjes@msmail3.hac.com From kkelly@ll.mit.edu Mon Oct 17 13:27:03 1994 From: kkelly@ll.mit.edu (Kevin Kelly) Date: Mon Oct 17 13:27:09 PDT 1994 Subject: Re: Comments/Suggestions appreciated Michael Jeronis (mjeronis@astro.ge.com) writes that he added a Solaris workstation to his VxWorks system for the following reasons: > 1. the X-windows Server issues. > 2. vxWorks driver support for DATs. > 3. the system is heavily dependent on data files and > databases, this required us to provide online > file editing capability. > 4. easier integration of the scsi devices. > 5. the idea of a full up workstation in the box was > favorable. When we had to build a portable system with similar requirements we initially chose a portable SPARC (RDI Britelite), but eventually replaced it with a notebook PC. The PC is smaller, lighter, SIMPLER, more reliable, and boots a whole lot quicker. We connected to the VxWorks with Ethernet, had SCSI capability (both on PCMCIA cards). Our end users were a lot more comfortable with a MS Windows interface than the X interface it replaced, too. If your system is not portable you can get a Pentium and have plenty of power to run X if you want it. Good Luck, Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Kevin Kelly kkelly@ll.mit.edu Raytheon Box 997 (617) 981-2462/2463 Range Services Engineering APO, AP 96557 US Army Kwajalein Atoll ++++++++++++++++++ Republic of the Marshall Islands ++++++++++++++++++++++++ From rgonzale@esperanza.harvard.edu Mon Oct 17 13:34:14 1994 From: rgonzale@esperanza.harvard.edu (Ray Gonzalez) Date: Mon Oct 17 13:34:22 PDT 1994 Subject: Users Group I was wondering about how I can get some info. on the East Coast Users Group Meetings and how one can find out when, and where they meet. Ray ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Raymond Gonzalez | Harvard-Smithsonian Center for Astrophysics gonzalez@cfa.harvard.edu | Smithsonian Astrophysical Observatory voice (617) 496-7622 | 60 Garden St. MS-78 FAX (617) 496-7554 | Cambridge, Mass 02138-1596 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :I felt sad, because I had no shoes to wear, until I saw a man wearing nothing but shoes. From daemon@vxw.ee.lbl.gov Tue Oct 18 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Oct 18 04:00:38 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Oct 18 04:00:14 PDT 1994 Subject: Re: X Windows Server Subject: Re: FOUND: RTOS evaluation/comparison file Subject: Re: BUS ERROR, memcpy(), etc Subject: stethoscope software Subject: [Q] The shell's editor mode.. Subject: Fortran in vxwork ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: X Windows Server Date: Mon, 17 Oct 1994 13:18:08 GMT From: cmdorat@tc.fluke.COM (Richard Kowalsky) Organization: Fluke Corporation, Everett, WA Message-ID: References: <9410131217.AA02946@rhin> Just thought I would quickly throw in my $0.02, since I am not related to WRS or VisiCom. I am using the VXwindows and it is a far better package than the old Wind-X previously offered by WRS. It should do what you want. The standard caviats apply. I'm an X-novice, definately not an expert, but I have been able to get a pretty reasonable, network intensive, multi-user app running. The boss is smiling, I may go home early....;-) - -- - ---------------------------------------------------------------------------- | Richard Kowalsky ___ ____________ | | Fluke Corporation __--/ \--__ {____________} | | cmdorat@tc.fluke.com <---Internet < NCC1701 > / / | | 206-356-6279 <---Audionet ----_____---- / / | | 6920 Seaway Blvd 178D <---Ancientnet _\ \___/_/___ | | Everett, Wa. 98203 }< \ | | \_____________/ | | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| | Standard Discalimer: I represent no one other than myself | - ---------------------------------------------------------------------------- --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: FOUND: RTOS evaluation/comparison file Date: Mon, 17 Oct 1994 14:41:14 GMT From: mrl6a@uvacs.cs.Virginia.EDU (Matthew R. Lehr) Organization: University of Virginia Computer Science Department Message-ID: References: <37bta9$7i4@news.internex.net> <37d402$76t@news.bu.edu> Followup-To: comp.realtime Sender: usenet@murdoch.acc.Virginia.EDU hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: > I found the paper "A Survey of Real-Time Operating Systems" by Kaushik > Ghosh on the net. Its WWW URL is: > > file://ftp.cc.gatech.edu/pub/coc/tech_reports/1993/GIT-CC-93-18.ps.Z While we're on the subject, I'd like to plug the IEEE Technical Committee on Real-Time Systems's WWW page: http://cs-www.bu.edu/pub/ieee-rts/Home.html You can access quite a bit of academic research through this page (although not Georgia Tech's just yet). A lot of links have been added since August. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: BUS ERROR, memcpy(), etc Date: Mon, 17 Oct 1994 17:00:44 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: References: <199410132256.QAA09803@somnet.sandia.gov> Matthew W. Brown (mwbrown@somnet.sandia.gov) wrote: : VxPerts, : Maybe someone can help me out here. I am transfering some data from a : VME A/D board's Dual Port Ram (DVME601E). The way that I have been doing : this is slow (but works)--see below. : char dpr[32764]; : char *place_ptr; : unsigned i; : Thanks, : Matthew Brown : mwbrown@sandia.gov Another poster points out the potential byte/word/long access issue, which is probably the problem. Another problem could be, if you're putting dpr[] on the stack, that a task's stack is overflowing. Anything can happen after that. (Hi stevel) John Finley jfinley@netcom.com --------------------------- Newsgroups: comp.os.vxworks Subject: stethoscope software Date: 17 Oct 1994 20:20:56 GMT From: morrell@cwc.ai.mit.edu (John B. Morrell) Organization: MIT Artificial Intelligence Lab Message-ID: <37umb8INNj8@life.ai.mit.edu> Does anyone out there have any opinions about Stethoscope software that they'd be willing to share ? (private e-mails OK). I am contemplating buying it. In particular, can it help with tracking bus errors from the backplane? John Morrell --------------------------- Newsgroups: comp.os.vxworks Subject: [Q] The shell's editor mode.. Date: 17 Oct 1994 19:55:03 -0700 From: gnn@tx.abekas.com (George Neville-Neil) Organization: Abekas Video Systems, Inc. Message-ID: Hi Folks, I've been using the VxWorks shell for a while now and I have a question. Can its mode be set to EMACS (like bash)? Right now it has what would be considered and EDITOR variable of VI. Thanks, George - -- George V. Neville-Neil work: gnn@abekas.com home:gnn@netcom.com Home Page: ftp://ftp.netcom.com/pub/gnn/gnn.html --------------------------- Newsgroups: comp.os.vxworks Subject: Fortran in vxwork Date: 18 Oct 1994 10:40:34 GMT From: bocci@dxcern.cern.ch (Valerio Bocci) Organization: INFN Rome 2 Message-ID: <3808n2$sop@serra.unipi.it> Reply-To: bocci@sunsan1.iss.infn.it We are thinking to use Vxwork in our environment, but we have a lot of Fortran code written. is there the possibility to use a fortran compiler for Vxwork ? Who provide this fortran compilers ? Thanks Valerio Bocci --------------------------- End of New-News digest ********************** From sblachma@aoc.nrao.edu Tue Oct 18 09:12:44 1994 From: Steve Blachman Date: Tue Oct 18 09:12:51 PDT 1994 Subject: Re: Fortran in vxwork OASYS has a Fortran cross-compiler. We are testing it for making 68xxx code in a SUN 4 development environment. So far it is working. Steven Blachman From mmuri@qualcomm.com Tue Oct 18 09:37:39 1994 From: mmuri@qualcomm.com (Mark Muri) Date: Tue Oct 18 09:37:45 PDT 1994 Subject: Registering for the 'Exploder' (per the Wind River Users Group flyer) Name: Mark Muri Company: Qualcomm, Inc Address: 6455 Lusk Blvd., San Diego, CA 92121 Phone: (619) 658-3303 FAX: (619) 658-2108 email: mmuri@qualcomm.com Application: Call Control Processor. It is a 'central nervous system' for a large number of land/mobile/cellular/etc calls. It focuses on Qualcomm's zoomy CDMA digital technology for cellular and mobile systems. Hardware: Many, many, many Motorola VME167 cards... Thanks! From tsb@mclean.sparta.com Tue Oct 18 11:33:34 1994 From: "Todd S. Brackett" Date: Tue Oct 18 11:33:41 PDT 1994 Subject: Wanted: VMIC VMIVME-4512 Driver Hi Folks, Anybody got a driver for the VMIC VMIVME-4512 A/D D/A Board? Thanks! ----------------------------------------------------------- |Todd S. Brackett | Voice -> 703 448 1683 x249 | |tsb@mclean.sparta.com | FAX -> 703 734 3323 | |_________________________________________________________| | | | /\\ SPARTA, Inc. | | ///\\ 7926 Jones Branch Drive | | /////\\ Suite 900 | | ///// \\ McLean, VA 22102 | | / \\\\\ \\ | | \ \\\\\ // | | \ ////// | | \////// SPARTA | | \//// Pride In Performance | | \// | ___________________________________________________________ From tracy@wrs.com Tue Oct 18 12:24:44 1994 From: tracy@wrs.com (Tracy Butler) Date: Tue Oct 18 12:24:51 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > >Newsgroups: comp.os.vxworks >Subject: Fortran in vxwork >Date: 18 Oct 1994 10:40:34 GMT >From: bocci@dxcern.cern.ch (Valerio Bocci) >Organization: INFN Rome 2 >Message-ID: <3808n2$sop@serra.unipi.it> >Reply-To: bocci@sunsan1.iss.infn.it > > >We are thinking to use Vxwork in our environment, but we have a lot of Fortran >code >written. >is there the possibility to use a fortran compiler for Vxwork ? >Who provide this fortran compilers ? > > Thanks > Valerio Bocci > > There are two compiler vendors that we're aware of at WRS who supply a Fortran compiler for VxWorks. - Green Hills Software (Oasys is their distributor) (805) 965-6044 : This is the Green Hills number - Diab Data (415) 571-1700 From mmuri@qualcomm.com Tue Oct 18 12:56:44 1994 From: mmuri@qualcomm.com (Mark Muri) Date: Tue Oct 18 12:56:51 PDT 1994 Subject: RE: Registering for the 'Exploder' >Hi Mark: > >In case you didn't do this already, what you want to do is send a message with >"subscribe" as the subject & body (without the quotes, of course) to: > > vxwexplo-request@lbl.gov > >The message you sent got to the mailing list itself, to which I & many others >belong... Yes, I realized this mistake right AFTER I hit the return key... Sorry for the wide distribution. I guess I was praying some human moderator had caught it in time! Mark From mwbrown@somnet.sandia.gov Tue Oct 18 15:18:38 1994 From: "Matthew W. Brown" Date: Tue Oct 18 15:18:44 PDT 1994 Subject: write() VxPerts, I had posted last week about generating BUS ERRORs when using memcpy() to transfer data from a VME A/D board's Dual Port RAM to an array, and several of you correctly concluded that my board didn't allow 32-bit data transfers. So, I'm now using bcopyWords() to do the same thing (and every thing works OK). Now, what I'd really like to do is move the contents of the RAM directly to disk using write(). Apparently, write() also tries to do 32-bit data transfers (so again I get BUS ERRORS). I don't suppose that there is an equivalent solution here--like writeBytes() or writeWords()? It seems to me that this would be a common situation--moving data directly from the acquisition boards to disk as quickly as possible. (So, I should be experiencing a problem that has been solved many times :) Any suggestions would be greatly appreciated. Thanks, Matthew Brown mwbrown@sandia.gov From daemon@vxw.ee.lbl.gov Wed Oct 19 04:00:22 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Oct 19 04:00:30 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Oct 19 04:00:13 PDT 1994 Subject: Re: Fortran and vxWorks Subject: Re: Fortran in vxwork Subject: Re: Fortran and vxWorks Subject: GNU linker generating coff files without symbol table ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fortran and vxWorks Date: 18 Oct 1994 15:26:37 GMT From: vanandel@stout.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <380pfd$h78@ncar.ucar.edu> References: <3808n2$sop@serra.unipi.it> Sender: vanandel@canoe (Joe Van Andel) In article <3808n2$sop@serra.unipi.it>, bocci@dxcern.cern.ch (Valerio Bocci) writes: |> |> We are thinking to use Vxwork in our environment, |> but we have a lot of Fortran code written. |> is there the possibility to use a fortran compiler for Vxwork ? |> Who provide this fortran compilers ? |> (Mail bounced, so I'm posting). I would think your best hope would be an automated translation of Fortran to C, using "f2c". I haven't personally done this, but the translator is available from an AT&T research machine (netlib.att.com:/netlib/f2c) - -- Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fortran in vxwork Date: 18 Oct 1994 15:35:50 GMT From: mwette@mr-ed.jpl.nasa.gov (Matt Wette) Organization: Jet Propulsion Laboratory Message-ID: <380q0m$etf@grover.jpl.nasa.gov> References: <3808n2$sop@serra.unipi.it> In article <3808n2$sop@serra.unipi.it>, bocci@dxcern.cern.ch (Valerio Bocci) writes: |> |> We are thinking to use Vxwork in our environment, but we have a lot of Fortran code |> written. |> is there the possibility to use a fortran compiler for Vxwork ? |> Who provide this fortran compilers ? We tried using Fortran w/ VxWorks. We tried f2c (free Fortran to C converter available via anonymous ftp from netlib.att.com) and the Green Hills fortran cross compiler. With f2c we had problems trying to link the structures generated from common blocks to other C routines. Common blocks in different files with the same name may not necessarily get linked together properly. If you don't have common blocks that you need to share among files, and you don't use any nonstandared, (e.g., VMS features), you should be OK. The Green Hills stuff was painful to use. I had to sort through *lots* of options to get the thing to generate assembler that the GNU gas could handle. Then someone else wanted to use it with the libraries, which weren't VxWorks compatible. They sent us an updated compiler but now the options to generate the proper assembly have changed and these options are not proprietary. You could probably use GH but you'd better be ready to shell out money for compiler, assembler, linker and who knows what else they'll require you to buy. I ended up hand translating everything to C. Matt - -- matthew.r.wette@jpl.nasa.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fortran and vxWorks Date: Tue, 18 Oct 1994 17:19:09 GMT From: bobf@courier.hq.verdix.com (Bob Foery) Organization: Rational Software Corporation Message-ID: <1994Oct18.171909.24929@verdix.com> References: <3808n2$sop@serra.unipi.it> <380pfd$h78@ncar.ucar.edu> Sender: news@verdix.com You might also try Green Hills. I believe that they may have (or had) an integration between their FORTRAN compiler and VxWorks. Good luck. Robert F. Foery, Jr. Rational Software Corporation bobf@rational.com --------------------------- Newsgroups: comp.os.vxworks Subject: GNU linker generating coff files without symbol table Date: 18 Oct 1994 21:08:28 GMT From: duhrenho@vette.world (David Uhrenholdt) Organization: Lockheed Sanders Message-ID: We are using the gnu 68k linker sent to us from Wind River and it produces a coff file without a useable symbol table (the strings section or what ever it is called is in the file). Because of the environment we are in we need to use coff. To get around this problem we generate an a.out file and extract the symbol table. Unfortantly, the linker links the images differently about 80% of the time. Anyone seen this problem? Know of any better work arounds? Would getting a more recent version of the linker be useful? Dave - -- Dave Uhrenholdt duhrenho@vette.sanders.lockheed.com Phone (603) 885-7305 --------------------------- End of New-News digest ********************** From jritchie@wrs.com Wed Oct 19 10:16:23 1994 From: jritchie@wrs.com (Jim Ritchie) Date: Wed Oct 19 10:16:30 PDT 1994 Subject: HDLC Driver Does anyone have a VxWorks device driver available for either the Motorola 68360 or 68302 microproccessor that supports HDLC over the Serial Communication Controllers (SCCs) that they would be willing to share? I understand that you can get some generic code from Motorola that supports HDLC on these devices, but it would be great if someone already has this code ported to VxWorks. Thanks, Jim ========================================= Jim Ritchie Account Manager Wind River Systems 5201 Great America Parkway, Suite 320 Santa Clara, CA 95054 Ph: (408) 562-5769 Fax: (408) 562-5775 ========================================= From WELCH@asd2.jsc.nasa.gov Wed Oct 19 10:57:23 1994 From: WELCH@asd2.jsc.nasa.gov Date: Wed Oct 19 10:57:30 PDT 1994 Subject: unsubscribe unsubscribe From xanda@netcom.com Wed Oct 19 15:01:35 1994 From: xanda@netcom.com (Larry J. Gardner) Date: Wed Oct 19 15:01:41 PDT 1994 Subject: VxWorks Code Examples for a fast RealTime system I am a new VxWorks user and am looking for some coding examples to get started. My application will require fsst simple semaphores and inteerrupt handling for interfaces to an Interphase fast and wide disk system and an Imaging Technologies frame buffer. Any examples of user input processing to handle processing setup wouuld also be appreciated. Thanks for the help. Larry Gardner Xanda@netcom.com. From biaggi@maple.nosc.mil Wed Oct 19 15:15:35 1994 From: "Biaggi Luis E." Date: Wed Oct 19 15:15:41 PDT 1994 Subject: USERS GROUP MESSAGES I received lots of messages daily from "root" (root@vxw.ee.lbl.gov). I get to read many of the questions/answers which are very helpful. I heard that all these messages are saved somewhere and even archived. Does anyone know where and how to get to recent (passed few weeks/month) messages either by E-mail and/or FTP? Sometimes I keep some for my reference, but other times I erased them finding out that "yes...I read about that one before...." Thanks..... Luis Biaggi Company: NCCOSC RDT&E Div. E-Mail: BIAGGI@NOSC.MIL Tel: (619) 553-9472 Fax: (619) 553-8339 From 100067.355@compuserve.com Thu Oct 20 01:21:21 1994 From: Philippe Weber <100067.355@compuserve.com> Date: Thu Oct 20 01:21:29 PDT 1994 Subject: VxMP example code Does anyone have some code showing the capatibilities and the performances of VxMP. My goal is to build a multi-processor demonstration system. Thanks in advance. From rhin!joergb@lbl.gov Thu Oct 20 01:21:52 1994 From: rhin!joergb@lbl.gov Date: Thu Oct 20 01:22:03 PDT 1994 Subject: Re: light-wight GUI for VxWorks > A potential customer is looking for a light-weight GUI (Graphical User > Interfac) library for VxWorks, which is not based on X-Windows, thus > more suitable for low-cost embedded systems. The hardware architecture > is a generic x86 PC equipped with VGA compatible graphics. > > Commercial offers are wlcome. > ----------------------------------------------------------------------- > Leonid Rosenboim Phone: +972-3-67-00-321 > R S T Software Industries Ltd. Fax: +972-3-67-24-498 > P.O.Box 8077, Ramat-Gan 52180, Israel Cell: +972-50-307-142 > Wind River Systems Distributor E-Mail: leonid@rst.co.il > > ********** Hi Leonid, thanks for your answers to my i960-Benchmarks questions. Concerning your question about light-weight GUI we have something called MGR (window based visualisation) which is compared to X11 really light-weight (some 100K of memory required). Unfortunately it is currently only available on Sun cross 68k for VxWorks. We know the company reccoware, which makes MGR very well and perhaps you should talk to this company about porting MGR to PC-targets. The address is: Reccoware Systems Ulrichstr. 26 Unterwittelsbach D-86551 Aichach Germany Tel: +49-8251-51299 Fax: +49-8251-51301 At last one more question about i960. I did some sizing I got really startled about the size of the VxWorks image. A normal VxWorks for development is close to 1 MB for the i960. Did you do some sizing on i960. Any information would be appreciated. Thanks in advance ###################################################################### # Joerg Bertholdt Wind River Systems GmbH Phone: +49-89-96094942 # # FAE Freisinger Strasse 34 Fax: +49-89-96094940 # # joergb@wrsec.fr 85737 ISMANING # # GERMANY # ###################################################################### From daemon@vxw.ee.lbl.gov Thu Oct 20 04:00:54 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Oct 20 04:01:16 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Oct 20 04:00:27 PDT 1994 Subject: Fortran Compiler for Vxwork 2 Subject: C++ and VxWorks Subject: Re: C++ and VxWorks Subject: SCI Bus Subject: 386/486 Targets Subject: MVME162/MVME162LX Subject: Configuring memory on VMEbus ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Fortran Compiler for Vxwork 2 Date: 19 Oct 1994 11:45:09 GMT From: bocci@sunsan1.iss.infn.it (Valerio Bocci) Organization: INFN Istituto Nazionale Fisica Nucleare Message-ID: <3830s5$tid@serra.unipi.it> Reply-To: bocci@dxcern.cern.ch > |> We are thinking to use Vxwork in our environment, > |> but we have a lot of Fortran code written. > |> is there the possibility to use a fortran compiler for Vxwork ? > |> Who provide this fortran compilers ? I want to add some other informations; We want to use OSF/1 machine (AXP Alpha DEC processor) as host and DEC AXP target machine with VxWork. In OSF/1 there is a fortran Compiler. Thanks Valerio Bocci --------------------------- Newsgroups: comp.os.vxworks Subject: C++ and VxWorks Date: 19 Oct 1994 16:12:21 GMT From: chase@tif487.ed.ray.com (Tom Chase) Organization: Equipment Division, Raytheon Company Message-ID: <383gh5$rs3@news.ed.ray.com> My project is planning to develop embedded real-time software using C++. I would like to hear the experiences of any C++/ObjectCenter/VxWorks users. I am starting to get the feeling that there are not alot of you out there! How did the tools work together? Can you use the ObjectCenter environment for system level debug? Thanks for reading, Tom - -- Opinions expressed here are mine, and not my employer's. ===================================================================== Fred Ross-Perry chase@ed.ray.com Raytheon Company Equipment Division (508) 490-2231 1001 Boston Post Road, Marlborough, MA 01752 m/s 3-2-3925 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: C++ and VxWorks Date: Wed, 19 Oct 1994 21:21:39 GMT From: pfulghum@boi.hp.com (Pat Fulghum) Organization: Hewlett-Packard / Boise, Idaho Message-ID: References: <383gh5$rs3@news.ed.ray.com> Sender: news@boi.hp.com (Boise Site News Server) Tom Chase (chase@tif487.ed.ray.com) wrote: : My project is planning to develop embedded real-time software using : C++. I would like to hear the experiences of any : C++/ObjectCenter/VxWorks users. I am starting to get the : feeling that there are not alot of you out there! : How did the tools work together? Can you use the ObjectCenter : environment for system level debug? We are also looking at doing the same. Just getting started though. I would like to get forwarded any info that you get. - -- Pat Fulghum pfulghum@boi.hp.com --------------------------- Newsgroups: comp.os.vxworks Subject: SCI Bus Date: Wed, 19 Oct 1994 21:46:30 GMT From: maillet@wrs.com (Al Maillet) Organization: Wind River Systems, Inc. Message-ID: Is anyone familiar with a commercially available board that is based on the SCI (Scalable Coherent Interconnect, IEEE 1596) bus. Oh, it must run VxWorks. Al Maillet al@wrs.com - -- Al Maillet Wind River Systems Inc. 8910 University Center Lane Phone: (619)597-2477 Suite 300 Fax: (619)558-8918 San Diego, CA 92122-2477 al@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: 386/486 Targets Date: Wed, 19 Oct 1994 21:49:31 GMT From: maillet@wrs.com (Al Maillet) Organization: Wind River Systems, Inc. Message-ID: Is anyone familiar with a commercially available board that includes a 386 or 486 micro and is based on the EISA, ISA, or PCI bus? Al Maillet al@wrs.com - -- Al Maillet Wind River Systems Inc. 8910 University Center Lane Phone: (619)597-2477 Suite 300 Fax: (619)558-8918 San Diego, CA 92122-2477 al@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: MVME162/MVME162LX Date: 19 Oct 1994 19:20:08 GMT From: s_wagner@irau28.ira.uka.de (Marcel Wagner) Organization: University of Karlsruhe, FRG Keywords: serial interface,overrun error Message-ID: <383rh8INN38r@iraun1.ira.uka.de> I have the following two problem with our MVME162 and MVME162LX boards : - - The MVME162 is equiped with 2MB flash memory.The first MB is used by the system software BUG.Now I try to get the VxWorks bootrom in the second half.To do this, I want to use the port #1 of the serial interface. If I start the download with LO 1 FF900000 I always get an overrun error. It only works with 110 baud and that's tooo slow.I 've tried it with XON/XOFF on and off but nothing helps. I hope somebody can help me. - -The other problem is our MVME162LX board. The jumper settings are all correct, but if I insert it in the VME rack and turned it on, there is no output at the terminal, but the LED's shows, that the board is running. I have no ideas what I can do. Thanks for reading, Marcel (s_wagner@ira.uka.de) --------------------------- Newsgroups: comp.os.vxworks Subject: Configuring memory on VMEbus Date: Wed, 19 Oct 1994 19:59:04 GMT From: davel@fairmpc.fairfld.mcd.mot.com (David Lowery) Organization: Motorola Computer Group, Fairfield Sales Office Message-ID: <1994Oct19.195904.7642@phx.mcd.mot.com> Sender: davel@fairmpc (David Lowery) I have a 68K board customer using VxWorks and they would like to know if there is way to configure some specific off-board VMEbus memory as cache-inhibited to a VxWorks task. Thanks, Dave --------------------------- End of New-News digest ********************** From ken@esd.ray.com Thu Oct 20 10:33:09 1994 From: ken@esd.ray.com (Swimming Man Burning) Date: Thu Oct 20 10:33:16 PDT 1994 Subject: memPartAlloc error due offboard addresses hi - we have an Ada application running in an embedded 68040 SBC under vxWorks our application is getting a memPartAlloc error upon program load we've traced it to several large data structures reflecting offboard register sets, device RAMs, etc., on other VME cards these seem to appear to the kernel as part of the local program memory required for program data structures it seems that the kernel counts data space for structures that have been affixed to offboard address locations, against the available local (processor card) memory the kernel then decides the processor card does not contain enough memory we're cross compiling from a Sun, in Ada (VADSworks 3.0.0c), for a 68040 (DY 4 SVME-144), under vxWorks 5.1.1 any clues as to what we may be doing wrong (or not doing right)? TIA ------------------------------------------------------------------ Ken Balmy Too fast to live Raytheon ESD Too young to die ken@esd.ray.com Bye, bye ^D B{= ------------------------------------------------------------------ From ppinkow@jupiter.ksc.nasa.gov Thu Oct 20 11:42:49 1994 From: Patrick Pinkowski Date: Thu Oct 20 11:42:57 PDT 1994 Subject: VME Hippi Cards Does anyone know of a manufacturer of VME Hippi Cards? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Patrick T. Pinkowski NASA - Kennedy Space Center MC: TE-ISD-4 KSC, FL 32899 ph: (407) 861-1075 fax: (407) 861-0197 email: ppinkow@jupiter.ksc.nasa.gov ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From tsb@mclean.sparta.com Thu Oct 20 15:35:31 1994 From: "Todd S. Brackett" Date: Thu Oct 20 15:35:39 PDT 1994 Subject: Re: VME Hippi Cards > Submitted-by ppinkow@jupiter.ksc.nasa.gov Thu Oct 20 11:42:49 1994 > Submitted-by: Patrick Pinkowski > > Does anyone know of a manufacturer of VME Hippi Cards? > MYRIAD LOGIC Makes one.... They're in Silver Spring, MD 301-588-4155 Regards, ----------------------------------------------------------- |Todd S. Brackett | Voice -> 703 448 1683 x249 | |tsb@mclean.sparta.com | FAX -> 703 734 3323 | |_________________________________________________________| | | | /\\ SPARTA, Inc. | | ///\\ 7926 Jones Branch Drive | | /////\\ Suite 900 | | ///// \\ McLean, VA 22102 | | / \\\\\ \\ | | \ \\\\\ // | | \ ////// | | \////// SPARTA | | \//// Pride In Performance | | \// | ___________________________________________________________ From tsb@mclean.sparta.com Thu Oct 20 16:02:09 1994 From: "Todd S. Brackett" Date: Thu Oct 20 16:02:17 PDT 1994 Subject: Re: Stethoscope Stethoscope is a FIRST CLASS piece of software. I would recommend it to anybody who needed a window into your data on your VxWorks system. I have used it in control systems (servo loops, robotics, etc), data acquisition systems (Talk about a high tech strip chart!) and as a debugging aid for all kinds of numerical analysis problems (recursive algorithms etc.) In all cases I have found the product easy to use, and an extreme time saver in chasing bugs (lost pointers, etc..). As far as looking for bus errors go you must remember that bus errors, in general, are a hardware issue and Stethoscope is a software tool for data collection. I suppose you could set up your own bus error handler and instrument it with Stethoscope if you like although I think that might be a little unorthodox. Regards, ----------------------------------------------------------- |Todd S. Brackett | Voice -> 703 448 1683 x249 | |tsb@mclean.sparta.com | FAX -> 703 734 3323 | |_________________________________________________________| | | | /\\ SPARTA, Inc. | | ///\\ 7926 Jones Branch Drive | | /////\\ Suite 900 | | ///// \\ McLean, VA 22102 | | / \\\\\ \\ | | \ \\\\\ // | | \ ////// | | \////// SPARTA | | \//// Pride In Performance | | \// | ___________________________________________________________ From ntmtv.com!kapoorsx@ntmtv.portal.com Thu Oct 20 19:11:56 1994 From: kapoorsx@ntmtv.com (Sanjay Kapoor) Date: Thu Oct 20 19:12:02 PDT 1994 Subject: Can signals unblock a select() call? I was wondering if VxWorks supported unblocking a select() call with a signal as Unix does. I tried it with SIGINIT,SIGIO, & SIGURG and it didn't seem to work. The blocked task received the signal, but it was not interrupted from it's select() call (i.e. the select() call did not return -1 as it does in Unix). Am I using the wrong signal, or is this just not implemented in VxWorks? Thanks, Sanjay Kapoor kapoorsx@ntmtv.com Northern Telecom Mountain View, Ca From stan@lassen.rti.com Thu Oct 20 19:25:31 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Thu Oct 20 19:25:40 PDT 1994 Subject: StethoScope 4.2 released =============================================================================== A N N O U N C E M E N T =============================================================================== StethoScope 4.2 Released ------------------------ StethoScope version 4.2 is now shipping. This package includes three components: the StethoScope graphical data monitoring and collection tool, the ScopeProfile dynamic execution profiler, and the RTILib collection of focused utilities and debugging tools. StethoScope 4.2 is available on SunOS 4.x, Solaris 2.x, DEC, and HP hosts. It includes a full Motif-compliant graphical interface for all platforms. "Floating" licenses are now available. Target support includes m68k, cpu32, sparc, alpha, i960, and x86. All host/target combinations are supported. Several other configurations are in progress, ask for details. The release includes: StethoScope Graphical data collection and monitoring Watch any of your program variables evolve in real time. See just what your application is doing. Answer questions a debugger can't touch, such as how much overshoot your controller has, how long it took the valve to close, how noisy the sensor is, or how long a queue is getting. Save and export any variable values for later analysis with Matlab or other tools. StethoScope opens a window into your application; it shows you what's really happening. You'll use it every day! ScopeProfile Dynamic execution profiler Monitor the execution flow of VxWorks programs on a procedure-by-procedure basis. Calculate exactly how much CPU each routine is using. ScopeProfile shows you exactly where you're spending your CPU cycles. RTILib Tools and utility package, including: HeapCheck Memory error detection Detect and find problems that corrupt the system memory pool. HeapTrace Memory usage analysis Trace memory allocation to find memory leaks and excessive usage. rshell Re-entrant shell program Open multiple interactive terminal sessions. Patch Code-patching utility Quickly interject code segments into an actively running system. Trace Execution tracing facility Follow and debug code execution sequences. FastBuffer Fast fixed-size buffer management VxGDB (static debugging), StethoScope (dynamic variable monitor and data collection), and WindView (event and timing analysis), combine to form the most comprehensive real-time toolset on the market. Contact RTI or your WRS sales representative for more details. Email inquiries should be sent to "info@rti.com" or "sales@wrs.com". This posting was submitted under the comp.os.vxworks occasional commercial postings policy. Please forgive the marketing hype. Some tools not available on some target architectures. From daemon@vxw.ee.lbl.gov Fri Oct 21 04:00:35 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Oct 21 04:00:47 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Oct 21 04:00:13 PDT 1994 Subject: Re: USERS GROUP MESSAGES Subject: RARP Subject: VxWorks multicast support Subject: FAQ for this group Subject: Mosaic Home Page for Wind River ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: USERS GROUP MESSAGES Date: Thu, 20 Oct 1994 10:43:27 GMT From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld) Organization: Hollandse Signaal apparaten BV Message-ID: <1994Oct20.104327.26653@hgl.signaal.nl> References: <2EA59A81@maple.nosc.mil> Sender: usenet@hgl.signaal.nl (USENET News System) Biaggi Luis E. (biaggi@maple.nosc.mil) wrote: : I received lots of messages daily from "root" (root@vxw.ee.lbl.gov). I get : to read many of the questions/answers which are very helpful. I heard that : all these messages are saved somewhere and even archived. Does anyone know : where and how to get to recent (passed few weeks/month) messages either by : E-mail and/or FTP? Sometimes I keep some for my reference, but other times : I erased them finding out that "yes...I read about that one before...." : Thanks..... : Luis Biaggi : Company: NCCOSC RDT&E Div. : E-Mail: BIAGGI@NOSC.MIL : Tel: (619) 553-9472 : Fax: (619) 553-8339 We had roughly the same problem. In order to overcome this problem, I have written a small shell script that evaluates my email-box. The tool collects for one week each day all incomming vug mail (Vxwork-User-Group), and distributes information ( "Subject" lines ) to a internal email list of persons who are interested in the Vxwork-User-Group information. The 'collect' file is in 'email' format. In this way the user who wants to read the information can use his/here preferred own email reader. All 'collect' files are stored in a directory : ...somewhere.../vxworks/INFO_files/vxWorks_Users_Group_Exploder_email ( here it is /usr/users/vxworks/INFO_files/vxWorks_Users_Group_Exploder_email ) The name of the 'collect' files is : the 'date' of the week e.g. "940626" , "940710" , "940717" I have written this small program for a SUN workstation with SunOS 4.1.* It is one shell script. And it uses also the 'ELM' mail tool. It is not written with a wide distribution in mind. But a port to other users and/or computers can be very easily done. Usage and distribution is conform the Free Software Foundation "GNU GENERAL PUBLIC LICENSE" Interested ? Tell me and I will place it in "Newsgroups: comp.os.vxworks". ============================================================================== = B.J.M. Vloedbeld Dept:SDA-DID-DIM Org:Hollandse Signaalapparaten B.V. = = Adress : P.O.box 42 7550 GD Hengelo, The Netherlands = = Phone :+31-74-483994 FAX:+31-74-484009 email:bjm_vloedbeld@hgl.signaal.nl = =============================================================[Unclassified]=== --------------------------- Newsgroups: comp.os.vxworks Subject: RARP Date: Thu, 20 Oct 1994 10:51:54 GMT From: rsgawera@ss11.wg.icl.co.uk (Raj Gawera) Organization: International Computers Limited Message-ID: Reply-To: rsgawera@ss11.wg.icl.co.uk Sender: news@oasis.icl.co.uk Dear All, Does vxWorks support RARP in any way ? I can't find any reference to it in the manuals. Or alternatively, is there a version of RARP that works on vxWorks? cheers in advance, Raj Raj Gawera Designer ICL CSD email : rsgawera@wg.icl.co.uk --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks multicast support Date: 20 Oct 1994 20:54:25 GMT From: steve@aplsun.jhuapl.edu (Steven Kahn) Organization: Johns Hopkins U. Applied Physics Lab, Laurel, Maryland Message-ID: <386le1$sh3@aplcomm.jhuapl.edu> Is anyone aware of VxWorks support for host extensions for IP multicasting (RFC 1112)? I'm interested in either Wind River or 3rd party products or plans. Thanks. - -- ============================================================================= Steven Kahn, room 6-103 Steven_Kahn@jhuapl.edu Johns Hopkins University Applied Physics Lab Laurel, MD 20723-6099 +1 301 953 6812 --------------------------- Newsgroups: comp.os.vxworks Subject: FAQ for this group Date: 20 Oct 1994 19:31:34 GMT From: jvieiro@bnr.ca (Jorge Vieiro) Organization: Bell-Northern Research Ltd. Message-ID: <386gim$195@bmerhc5e.bnr.ca> Where can I get the FAQ for this group (if one exists)? Thanks, Jorge (jvieiro@bnr.ca) --------------------------- Newsgroups: comp.os.vxworks Subject: Mosaic Home Page for Wind River Date: Fri, 21 Oct 1994 00:04:19 GMT From: ralles@hapuna.caltech.edu (Rosemary Alles) Organization: Caltech Astronomy Department Message-ID: Reply-To: ralles@hapuna.caltech.edu (Rosemary Alles) Sender: news@news.Hawaii.Edu Dear All, Does anybody know if Wind River has a mosaic home page? Regards, Rosemary Rosemary Alles Software Engineer W.M. Keck Observatory Kamuela HI 96743 --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Fri Oct 21 06:41:08 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Fri Oct 21 06:41:15 PDT 1994 Subject: Re: FAQ for this group Greetings! The VxWorks FAQ is located at: teacher.mclean.sparta.com (157.185.32.10) and is availbale via anonymous FTP. We are currently working on a new revision of the FAQ that should be on-line in the next couple of weeks. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From jjahncke@divi.com Fri Oct 21 07:18:15 1994 From: jjahncke@divi.com (Jim Jahncke) Date: Fri Oct 21 07:18:22 PDT 1994 Subject: Re: VME Hippi Cards > Submitted-by ppinkow@jupiter.ksc.nasa.gov Thu Oct 20 11:42:49 1994 > Submitted-by: Patrick Pinkowski > > Does anyone know of a manufacturer of VME Hippi Cards? > CHI Systems, Inc makes one (it is even VxWorks based). They can be reached at: CHI Systems, Inc. 47211 Bayside Parkway Fremont, CA 94538 510/440-0400 800/736-2322 +--------------------------------------------------------------+ | Jim Jahncke Internet: jjahncke@divi.com | | DiviCom | | 580 Cottonwood Drive Phone: (408) 944-6732 | | Milpitas, CA 95035 FAX: (408) 944-6705 | +--------------------------------------------------------------+ From xhd@zfssun1.tz.rus.uni-stuttgart.de Fri Oct 21 07:27:45 1994 From: xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS) Date: Fri Oct 21 07:27:54 PDT 1994 Subject: Re: C++ and VxWorks Tom Chase (chase@tif487.ed.ray.com) wrote: : My project is planning to develop embedded real-time software using : C++. I would like to hear the experiences of any : C++/ObjectCenter/VxWorks users. I am starting to get the : feeling that there are not alot of you out there! : How did the tools work together? Can you use the ObjectCenter : environment for system level debug? I'm also interested in this, please forward. Thank's Nick ____________________________________________________________________ | | | Nikolaus Hild | | Centre for Manufacturing Technologies Stuttgart | | Nobelstr. 15 | | 70569 Stuttgart | | Germany | |____________________________________________________________________| | | | Phone: +49 711 131 62 41 | | Fax: +49 711 131 62 11 | | Email: xhd@zfssun1.tz.rus.uni-stuttgart.de | |____________________________________________________________________| From mgr@rtp.co.uk Fri Oct 21 10:28:01 1994 From: mgr@rtp.co.uk (Mark Richardson) Date: Fri Oct 21 10:28:08 PDT 1994 Subject: Re: StethoScope 4.2 released Hi Stan, By way of introduction I'm the FAE for RTP (WRS distributor) in the UK, I I believe you've spoken to Paul Keir my colleague in the past. I'm mailing in response to the crass commercial on the Exploder. Part of my job as FAE is to demo WRS and associated software, I could sure use the new release of Stethoscope in the demos, could you send us an update? We have two machines which we use for demos.... Hostname: demo Hostid: 52001bca Hostname: rtp Hostid: 200009bc Both of these machines are Sun4 hosts. It would be most convenient if we could have the m68k, cpu32 & sparc tapes. If you could send us a couple of manauls and the keys to go with these that'd begreat. Could you give me an idea when you'll be releasing a PowerPc version. Also.... I`m sure our sales dept could use around 50 or so brochures if you've re-released these then we could probably use about 50. Many thanks in advance Mark Richardson Real Time Products Ltd Unit 8, Holt Court, Aston Science Park Jennens Rd Birmingham England B7 4EJ Tel: 021 333 6955 Fax: 021 333 5433 From visicom!VisiCom.COM!trest@lbl.gov Fri Oct 21 15:17:44 1994 From: Mike Trest Date: Fri Oct 21 15:17:51 PDT 1994 Subject: Re: write() > Matthew Brown writes... > > Now, what I'd really like to do is move the contents of the RAM directly > to disk using write(). Apparently, write() also tries to do 32-bit data > transfers (so again I get BUS ERRORS). I don't suppose that there is an > equivalent solution here--like writeBytes() or writeWords()? Well, you are in luck . . . mabey! Look thru your code for the "xxxCtrlCreate()" call which is used to initilize your SCSI controler. The arguments to that call include the routine to be used for writing and reading from your specific scsi interface controller. An example of one which I wrote is: FAS_SCSI_CTRL *fasCtrlCreate (baseAdrs, regOffset, clkPeriod, fasDmaBytesIn, fasDmaBytesOut) FAST UINT8 *baseAdrs; /* base address of the controller chip */ int regOffset; /* addr offset between consecutive regs. */ UINT clkPeriod; /* period of the controller clock (nsec) */ FUNCPTR fasDmaBytesIn; /* function for SCSI DMA input */ FUNCPTR fasDmaBytesOut; /* function for SCSI DMA output */ { ... pFAS->scsiCtrl.scsiBytesIn = (FUNCPTR) fasBytesIn; pFAS->scsiCtrl.scsiBytesOut = (FUNCPTR) fasBytesOut; pFAS->scsiCtrl.scsiDmaBytesIn = (FUNCPTR) fasDmaBytesIn; pFAS->scsiCtrl.scsiDmaBytesOut = (FUNCPTR) fasDmaBytesOut; ... } Typically, the DMA routine is in your BSP source code. The Bytes routine is typically in the SCSI driver library fasLib.c which is not generally delivered in source code. In the Dma and the Bytes routines you will find a section similar to the following: for (ix = 0; ix < MAX_FIFO_DEPTH; ix++) *pFAS->pFIFOREG = *pBuffer++; Which moves the data from the address pointed by the write (pBuffer) into the hardware write registers (in this case, a FIFO). This example assumes that the target memory is byte addressable. As with many VxWorks things, if you do not like what was provided, then supply your own on the CtrlCreate in usrConfig/bootConfig files. And yes, I know this ties your code very closely to the hardware, but you gave some very hardware specific requirements. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 VisiCom Laboratories Fax: 619 457 0888 10052 Mesa Ridge Court San Diego, CA 92121 ==================================================== From jarvidss@sw.seisy.abb.se Sat Oct 22 01:30:20 1994 From: 'Jonas Arvidsson' Date: Sat Oct 22 01:30:43 PDT 1994 Subject: Object code conversion I would like to use ld68k to convert an a.out relocatable file to a coff-m68k ditto. What command line options and/or script file commands should I use? _ ___ ___ .-----------------------------.--------------------------. / \ | )| ) | Jonas Arvidsson, dept. LKSS | Tel: +46 21 342667 | / _ \ | \| \ | ABB Industrial Systems | Fax: +46 21 342555 | /_/ \_\|__/|__/ | S-721 67 Vasteras, SWEDEN | jarvidss@sw.seisy.abb.se | `-----------------------------^--------------------------' From jarvidss@sw.seisy.abb.se Sat Oct 22 01:43:17 1994 From: 'Jonas Arvidsson' Date: Sat Oct 22 01:44:08 PDT 1994 Subject: Object code conversion I would like to use ld68k to convert an a.out relocatable file to a coff-m68k ditto. What command line options and/or script file commands should I use? From daemon@vxw.ee.lbl.gov Sat Oct 22 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Oct 22 04:00:35 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Oct 22 04:00:14 PDT 1994 Subject: gettimeofday in VXworks? Subject: long list of mbufs Subject: Interupts, Vector Tbl, ISR's Help Requested! Subject: No echo with scanf() in a task ? Subject: Loading objects via TFTP Subject: Re: Fortran in vxwork Subject: Re: MVME162/MVME162LX ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: gettimeofday in VXworks? Date: Thu, 20 Oct 1994 14:46:20 GMT From: jimenez@phantom (Javier Jimenez) Organization: Lockheed Missiles & Space Co. Message-ID: Sender: news@butch.lmsc.lockheed.com (Internet NEWS Account) I am trying to coordinate time on a Sun workstation with the clock in our VXworks environment. Currently, I use the gettimeofday system call to get the time on the Sun but I could not find the same call in VXworks. Does any one now of an accurate way to synchronize the clocks? Thanks. - -- Javier Jimenez Lockheed Aeronautical Systems Company 86 South Cobb Dr. -------------------------------------- Dept. 73-6M Zone 0670 Phone: (404) 494-3060 Marietta, GA 30063-0670 Email: jimenez@gelac.lasc.lockheed.com --------------------------- Newsgroups: comp.os.vxworks Subject: long list of mbufs Date: Fri, 21 Oct 1994 12:21:27 GMT From: wjw@pt.com (Wald Wojdak) Organization: Performance Technologies, Incorporated Message-ID: <1994Oct21.122127.17067@pt.com> Hi, In my FDDI VxWorks driver, I am getting a long chain of mbuf structures as oppose to clusters. The maximum number of linked mbuf structures is 37. How can I convince the VxWorks to use clusters as oppose to a long list of mbuf structures. There is a big difference in performance between one the other. I am using ttcp program and sending UDP/IP 4000 bits frames. The socket buffer size is set to 40960. - -- __ Wald Wojdak, Performance Technologies Incorporated wjw@pt.com 315 Science Parkway, Rochester, New York 14620 uupsi!ptsys1!wjw --------------------------- Newsgroups: comp.os.vxworks Subject: Interupts, Vector Tbl, ISR's Help Requested! Date: Fri, 21 Oct 1994 11:38:19 -0700 From: cobarruvias@asd1.jsc.nasa.gov (John R. Cobarruvias) Organization: NASA/JSC Message-ID: Followup-To: comp.os.vxworks This may be a very basic question, so bear with me: I have a number of tasks running in a 68020 MV135 processor. One task handles an interrupt from another card and based upon the Vector Table starts up the appropriate ISR. Now from a software point, I understand connecting the ISRs to the vector table with the routine intConnect(), and have built a shell with a number of ISRs. What I need to do now is test this logic and the interrupt handling. So, the question is how do you generate interupts inorder to test the software? I've loked through the reference manual for vxWorks and cant find anything. Is there a way to do this via software? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _/_/_/_/_/_/_/_/_/_/_/ ~ John R. Cobarruvias ~ _/ _/ _/ ~ NASA-Johnson Space Center ~ _/ ~ Mail Code EK31 ~ _/_/_/_/_/ _/ _/ _/ ~ Hou, CITY OF CHAMPIONS TX 77058 ~ _/ _/ _/ _/_/ _/_/ ~ 713-483-9357, 713-483-4319 (fax) ~ _/_/_/_/_/ _/ _/ _/ _/ ~ cobarruvias@asd1.jsc.nasa.gov ~ _/ _/ _/ _/ _/ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _/ _/ _/ _/ _/ Gig Em Aggies _/ 1994 NBA CHAMPIONS, HOUSTON ROCKETS! _/_/_/_/_/ --------------------------- Newsgroups: comp.os.vxworks Subject: No echo with scanf() in a task ? Date: 21 Oct 1994 17:06:39 GMT From: snapa@cert.fr (Ola Snapa) Organization: CERT, CS Dpt. Toulouse, France Message-ID: <388sev$it1@naurouze.cert.fr> A colleague of mine modified his code a little bit and he wound up with a few scanf() function calls inside a task. (These calls used to be made from a function that was directly invoked by the shell). None of us being VxWorks experts, we are unable to explain why there's now no echoing of the input. Scanf gets the input all right, but there's not a trace of it on the screen. Why would scanf behave differently in a user spawned task ? We have RTFM (by the way: are there other books/articles than the two from WRS ?) but we can't find any help there. The vxworks-faq doesn't mention it neither. VxWorks version: 5.1 Host: SunOS 4.1 We would very much appreciate your help. - -------------------------------------------------------------------- Ola A. Snapa email: snapa@cert.fr _____ _____ ______ ______ ONERA/CERT - DERA / ___/ / ___/ / __ / /_ __/ 2, avenue Edouard-Belin / / / /__ / /_/ / / / 31055 Toulouse cedex / / / ___/ / __ / / / FRANCE / /__ / /__ / / | | / / /____/ /____/ /_/ |_| /_/ - -------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Loading objects via TFTP Date: Fri, 21 Oct 1994 21:15:45 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Message-ID: <1994Oct21.211545.20736@brtph560.bnr.ca> Sender: billag@b4pphff (Bill Gutknecht) Ok, why doesn't this work? I can load the same module just fine using a remsh device with an open() call and a loadModule() call ... but this one keeps returning the same old garbage: - -> billLoad 0,"test3.o" loadModule: S_objLib_OBJ_ID_ERROR tftp error ---> tftp transfer failed: error 0x20 value = 0 = 0x0 - -> printErrno 0x20 S_errno_EPIPE value = 14 = 0xe - -> Any clues?? * I know TFTP works, since I can do the "octal dump" mode and see all the data. When I compare that dump to an 'od -h' on the workstation, it looks identical. Thanks, Bill - ----------------------------------------------------------------- #include #include #include #include MODULE_ID billLoad(int i,char *name) { MODULE_ID module = NULL; int dfd, efd; char path[256]; int a; char c; int j; strcpy(path,"/bnr/users/u1/billag/wr/"); strcat(path,name); if ( tftpXfer("b4pph102",0,path,"get","binary",&dfd,&efd) == ERROR ) { perror("tftpXfer"); return(module); } if ( i ) { j=0; printf("0000000 "); while ( (a = read(dfd,&c,1)) > 0 ) { j++; printf("%02x",(unsigned char) c); if ( (j % 2) == 0 ) printf(" "); if ( (j % 16) == 0 ) { printf("\n%07d ",j); } } } else if ( (module = loadModule(dfd,GLOBAL_SYMBOLS)) == NULL ) perror("loadModule"); close(dfd); printf("\ntftp error ---> \n"); while ( (a = read(efd,&c,1)) > 0 ) { putchar(c); } close(efd); return(module); } - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Fortran in vxwork Date: 21 Oct 1994 14:57:38 GMT From: chatterj@lfwc.lockheed.com (Shash Chatterjee) Organization: Lockheed Fort Worth Company Message-ID: <388kt2$n9v@cliffy.lfwc.lockheed.com> References: <3808n2$sop@serra.unipi.it> Reply-To: chatterj@lfwc.lockheed.com If you can help it don't do it! Having said that, let me tell you what you can do. We use Fortran a lot (80%). Green-Hills/Oasys makes cross-compilers for all kind's of host/target combinations. I understand that they have symbolic debuggers that work with Fortran/VxWorks. For SPARC targets and a SPARC host, you can use Sun's F77 compiler. We use Sun-3's and 68K targets with Sun's F77 compiler. We are unable to use the symbolic debugger. Also, FORTRAN I/O (read, write, etc) does not work...but we can always call C-functions like printf, scanf (Sun has an extension "pragma" that allows FORTRAN routines to call C functions without a trailing underscore). We use VMS extensions to F77 (structures and pointers) to allow us to share data among multiple processors and also to pass parameters to C routines (by value instead of by reference). We also use assembler directives to force the linker to put the FORTRAN Common Blocks at known addresses. Good Luck, Shash - --- +---------------------------------------- ------------------------+ + INTERNET (SMTP): ChatterjeeS@lfwc.lockheed.com + + LFWC (SMTP): ChatterjeeS@esdi (ChatterjeeS@[134.189.222.82])+ + LFWC (MSMAIL): Sasvata.Chatterjee (CHTTRS) + +---------------------------------------- ------------------------+ + Shash Chatterjee + + Electronic Systems Design & Integration + + Lockheed Fort Worth Company + + P.O. Box 748, MZ2273 VOICE: (817) 763-1495 + + Ft. Worth, TX 76101 FAX: (817) 777-2115 + +---------------------------------------- ------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MVME162/MVME162LX Date: Fri, 21 Oct 1994 21:27:38 GMT From: billag@b4pphff.bnr.ca (Bill Gutknecht) Organization: BNR Inc., RTP, NC Keywords: serial interface,overrun error Message-ID: <1994Oct21.212738.21101@brtph560.bnr.ca> References: <383rh8INN38r@iraun1.ira.uka.de> Sender: billag@b4pphff (Bill Gutknecht) In article <383rh8INN38r@iraun1.ira.uka.de>, s_wagner@irau28.ira.uka.de (Marcel Wagner) writes: |> - The MVME162 is equiped with 2MB flash memory.The first MB is used by |> the system software BUG.Now I try to get the VxWorks bootrom in the |> second half.To do this, I want to use the port #1 of the serial |> interface. If I start the download with LO 1 FF900000 I always get an |> overrun error. It only works with 110 baud and that's tooo slow.I |> 've tried it with XON/XOFF on and off but nothing helps. I hope somebody |> can help me. I do this ... (in 162Bug) lo 1 10000 On my HP9000/720 workstation (UX9.01) i run a program called ssrec (send s records ... its goofy, but it works!) Here's the source: #include #include #include #include #define BLOCK_SIZE 1024 main(int argv,char *argc[]) { int tty; int fdes; struct termios tty_attr; char block[BLOCK_SIZE]; int i,j=0; if ( (argv != 2) && (argv != 3) ) { fprintf(stderr,"Usage: %s []\n",argc[0]); exit(1); } if ( (tty = open(argc[1],O_WRONLY|O_NOCTTY)) == -1 ) { perror(argc[1]); exit(1); } if ( tcgetattr(tty,&tty_attr) == -1 ) { perror(argc[1]); exit(1); } tty_attr.c_cflag = B9600|CS8|CREAD|HUPCL; tty_attr.c_iflag = IXON|IXOFF|IGNPAR|IGNBRK; tty_attr.c_oflag = 0; tty_attr.c_lflag = 0; tty_attr.c_cc[VMIN] = 1; if ( tcsetattr(tty,TCSANOW,&tty_attr) == -1 ) { perror(argc[1]); exit(1); } if ( argv == 3 ) { if ( (fdes = open(argc[2],O_RDONLY)) == -1 ) { perror(argc[2]); exit(1); } } else fdes = fileno(stdin); while ( (i = read(fdes,block,BLOCK_SIZE)) > 0 ) { if ( i < 1 ) { perror("read"); continue; } printf("Wrote [%6d] bytes\r",j+=i); fflush(stdout); while ( write(tty,block,i) < 1 ) perror("write"); } printf("\n"); close(fdes); close(tty); } Once this is all done, do this on the MVME do the pflash command, you'll have to get specifics for your particular bootrom file size (use size68k) Good luck! - ------------------------------------------------------------------------------ Bill Gutknecht "If I die, I will go before Crom and he will BNR/Northern Telecom ask me 'What is the Riddle of Steel?' If I do Research Triangle Park, NC not know it, he will cast me out of Valhalla billag@bnr.ca and laugh at me ... " - ------------------------------------------------------------------------------ --------------------------- End of New-News digest ********************** From leonid@rst.co.il Sun Oct 23 01:40:05 1994 From: leonid@rst.co.il (Leonid Rosenboim) Date: Sun Oct 23 01:40:12 PDT 1994 Subject: Re: Can signals unblock a select() call? > I was wondering if VxWorks supported unblocking a select() call with > a signal as Unix does. I tried it with SIGINIT,SIGIO, & SIGURG and it didn't > seem to work. The blocked task received the signal, but it was not interrupted > from it's select() call (i.e. the select() call did not return -1 as > it does in Unix). Am I using the wrong signal, or is this just not > implemented in VxWorks? It depends on which version of VxWorks you are using. In 5.0.x it was a know problem that signals did not interrupt system calls. This was fixed in 5.1, and since then signals can interrupt all system calls I ever tried. Should work for select too. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-67-00-321 R S T Software Industries Ltd. Fax: +972-3-67-24-498 P.O.Box 8077, Ramat-Gan 52180, Israel Cell: +972-50-307-142 Wind River Systems Distributor E-Mail: leonid@rst.co.il From daemon@vxw.ee.lbl.gov Sun Oct 23 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Oct 23 04:00:33 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Oct 23 04:00:13 PDT 1994 Subject: Re: cmsg cancel <9410141548.AA02630@vlsi50.gsfc.n> Subject: Re: C++ and VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks,control Subject: Re: cmsg cancel <9410141548.AA02630@vlsi50.gsfc.n> Date: 20 Oct 94 20:57:16 MET From: goetzke@miriam.hanse.de (Stefan Goetzke) Organization: Intel outside - Amiga makes it possible Message-ID: References: In article fbh@vlsi50.gsfc.nasa.gov writes: >Cancelling spewage from notes gateway >. Was soll denn der Schei_? M|llt uns hier doch bitte nicht mit Tausenden von control-Messages zu! Danke. - -- _ _ // Stefan Goetzke <--Umlauttest:-d-v-|-_-D-V-\--> goetzke@miriam.hanse.de \X/ Postmonopol? Weg mit dem Dreck! Privatisierung JETZT!!! Glueckskeks: He who falls in love with himself will have no rivals. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: C++ and VxWorks Date: Sat, 22 Oct 1994 00:36:01 GMT From: prasad@netcom.com (Prasad Mokkapati) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: References: <383gh5$rs3@news.ed.ray.com> chase@tif487.ed.ray.com (Tom Chase) writes: >My project is planning to develop embedded real-time software using >C++. I would like to hear the experiences of any >C++/ObjectCenter/VxWorks users. I am starting to get the >feeling that there are not alot of you out there! I do not do much real-time programming, but was involved in porting our company's CORBA product from UNIX to VxWorks and was quite impressed by VxWorks support for C++. The cross development environment was on SUNOS. >How did the tools work together? Can you use the ObjectCenter >environment for system level debug? For debugging we just used vxGdb++ and were quite happy with it. - -- Prasad Mokkapati prasad@netcom.com --------------------------- End of New-News digest ********************** From dwampl@atl.com Sun Oct 23 18:05:51 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Sun Oct 23 18:05:58 PDT 1994 Subject: Re: C++ and VxWorks We've used "WindC++" and ObjectCenter. If you aren't expecting a "Borland C++", then the tool set should work for you, with some limitations. I do have a few gripes. 1) The cfront/gcc compiler combination is much slower than a true compiler. The warning and error messages from cfront are often next to useless. Also, I suspect that code size and efficiency is not as good as C code compiled with gcc (this is speculation...). 2) The "munching" process in VxWorks (where you set up the calls to constructors and destructors for global, static objects) is not very easy to use. (In "normal" C++ applications for PCs, workstations, etc., this is handled transparently during the link step.) This is annoying more than serious. 3) We avoided using templates because the mechanism in cfront is difficult to use, is VERY slow, and has lousy diagnostics. It might work for individual C++ developers, but our SW environment is such that everyone checks out source code from configuration control and builds SW locally. We felt that we couldn't require other developers to be affected by the template mechanisms behaviour, especially slower build times. 4) ObjectCenter provides excellent capabilities, especially with regards to data display. However, it is slow to start up and connect to a target for a large executable (because it reads everything up front, rather than incrementally, as is the case for vxgdb). Occasionally, it crashes. It has a few annoying bugs (at least in our version...). The "step" command doesn't step into a function; you have to set a breakpoint in it yourself. It looks for C++ source in the temporary C file output by cfront; you have to use the "gdb dir ..." command to tell it where the real file is located. It can't seem to recognize and display class-static variables, and it has problems with symbols from nested classes. However, all of these can be worked-around and may be fixed in the latest OC/gdb68k versions (we are not quite up-to-date, for various reasons). I *do* like OC a lot for native Sun debugging, although it can quickly exhaust RAM and virtual memory for large projects. We used C++ for a small subset of a large project. I recommend the same "gradual" approach. When we started, the tools weren't mature enough for our whole project, which is large and has memory constraints. Also, the build times would be prohibitive. The tools have improved a little, but it would be wise to do a careful evaluation based on your requirements. You should also consider "g++" for Vxworks from Cygnus Support (info@cygnus.com I believe). Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From 100274.2150@compuserve.com Mon Oct 24 06:15:56 1994 From: Eli Crombie <100274.2150@compuserve.com> Date: Mon Oct 24 06:16:02 PDT 1994 Subject: DiCOM Standard //////////////////////////////////////////////////////////////// From : Eli Crombie CMT Medical Technologies Haifa, Israel Tel: +972-4-550225, Ext. 138, Fax : +972-4-550-249 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Subject : ACR NEMA / DiCOM standard implemetation Hi VxPerts ! CMT Medical is a company that deals with medical imaging, & digitazing images for X-Ray rooms. We are now in the process of designing the impelementation of the DiCOM standard (Digital Imaging and Communications in Medicine). I would like to know whether anyone has implemented the above standard for VxWorks, or in C in general for any other OS, or could give me any other lead for such application. Any kind of information will be appreciated. TIA From mpc@globesat.lanl.gov Mon Oct 24 09:23:07 1994 From: mpc@globesat.lanl.gov (Michael Caffrey) Date: Mon Oct 24 09:23:14 PDT 1994 Subject: recommended ADC's hello, I am interested in vendors that have 100kHz adc with about 4 inputs for VMEbus AND have vxWorks drivers, any suggestions ? Thanks, Michael ---------------------------------------------------------------- Michael Caffrey PHONE:(505) 667-2422 MS: D440 FAX:(505)665-4197 Los Alamos National Laboratory EMAIL: mpc@lanl.gov Los Alamos, NM 87545 GROUP: NIS-3 A nanosecond here, a nanosecond there, and pretty soon you're talking about Real Time." (apologies to the late Sen. Everett Dirksen) "I don't think, therefore I'm not." , setracseD eneR From hebo@mbari.org Mon Oct 24 09:35:15 1994 From: Bob Herlien Date: Mon Oct 24 09:35:21 PDT 1994 Subject: Re: gettimeofday > I am trying to coordinate time on a Sun workstation with the clock in > our VXworks environment. Currently, I use the gettimeofday system > call to get the time on the Sun but I could not find the same call in > VXworks. Does any one now of an accurate way to synchronize the > clocks? Get usrTime.shar from the vxWorks archives. It is a Unix-compatible time library that includes gettimeofday(), settimeofday(), and other time related calls. It conflicts with the WRS ansiTime library (which came later), so you need to uninclude the latter. Full details are in the README file in usrTime.shar. -Bob Herlien From tweadon@sadira.gb.nrao.edu Mon Oct 24 10:27:58 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Mon Oct 24 10:28:05 PDT 1994 Subject: doing an "ls" from a program. Does anybody know if there's a simple way to have a program do an "ls" from a task and determine what is in the current directory vxWorks shell is "cd'd" into ? I want the information to be returned to the task, not to be printed up on the console as it would if you typed it into the shell. I'm running 5.1.1. Thanks Tim Weadon National Radio Astronomy Observatory Green Bank, WV. 24944 ************************************************************************* * Anybody out there collect old paper money from foreign countries, * like USSR, East Germany, etc? If so and you know of an exploder for it * or would like to trade let me know at tweadon@nrao.edu * ************************************************************************* From rhin!joergb@lbl.gov Mon Oct 24 11:22:29 1994 From: rhin!joergb@lbl.gov Date: Mon Oct 24 11:22:35 PDT 1994 Subject: SunSoft C Compiler Greeting, has anybody used the SunSoft C Compiler for VxWorks/Sparc? What did you experiance? Thanks for reply. ###################################################################### # Joerg Bertholdt Wind River Systems GmbH Phone: +49-89-96094942 # # FAE Freisinger Strasse 34 Fax: +49-89-96094940 # # joergb@wrsec.fr 85737 ISMANING # # GERMANY # ###################################################################### From daemon@vxw.ee.lbl.gov Tue Oct 25 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Tue Oct 25 04:00:40 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Oct 25 04:00:12 PDT 1994 Subject: Graphic display tools for VxWorks ?? Subject: 27xxx EPROMS in PLCC package? Subject: Re: 27xxx EPROMS in PLCC package? Subject: Re: 27xxx EPROMS in PLCC package? Subject: bootprom questions Subject: vxworks debugging tools ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Graphic display tools for VxWorks ?? Date: Mon, 24 Oct 1994 12:09:26 GMT From: segrest@bobseg.enet.dec.com () Organization: Me and only Me Message-ID: <1994Oct24.120926.14373@datum.nyo.dec.com> Reply-To: segrest@bobseg.enet.dec.com () Sender: usenet@datum.nyo.dec.com (USENET News System) Greetings, What tools are commonly used to develop graphic interfaces for embedded VxWorks applications ??? For example, vendor X developed a control system for a mechanical device. As part of the project they want to provide a low cost graphic display of the machine status. A common VGA controller and monitor are being considered. Does vendor X have to start from scratch or are there tools available ?? Is there anything in the public domain ?? - -- Bob Segrest --------------------------- Newsgroups: comp.os.vxworks Subject: 27xxx EPROMS in PLCC package? Date: 24 Oct 1994 15:57:23 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Followup-To: comp.os.vxworks Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) I realize this is only tangential to this group, but odds are someone around here knows the answer: I'm starting to use a Motorola MVME162, which has a PROM socket for PLCC-package chips. A local vendor claims that the standard 27-series EPROMs *don't exist* in the PLCC package - only PROMs, not erasable. I'm surprised at this, but I guess I'd believe it due to the small size. Can anyone confirm or contradict this statement? Thanks, - -Henning - -- Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ If you aren't part of the solution, you're part of the precipitate. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 27xxx EPROMS in PLCC package? Date: Mon, 24 Oct 1994 10:45:53 From: waters@reg.triumf.ca (Graham Waters) Organization: Triumf Message-ID: References: In article hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: >From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) >Subject: 27xxx EPROMS in PLCC package? >Date: 24 Oct 1994 15:57:23 GMT >I'm starting to use a Motorola MVME162, which has a >PROM socket for PLCC-package chips. A local vendor claims that the >standard 27-series EPROMs *don't exist* in the PLCC package - only >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it >due to the small size. Can anyone confirm or contradict this >statement? Rather than PROMS, we use FLASH specificely the 28F020 available as a 32 pin PLCC. Graham Waters TRIUMF, Meson Research Facility Vancouver, Canada. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 27xxx EPROMS in PLCC package? Date: Mon, 24 Oct 1994 17:56:23 GMT From: owen@nosc.mil (Wallace E. Owen) Organization: NCCOSC RDT&E Division, San Diego, CA Message-ID: <1994Oct24.175623.5150@nosc.mil> References: Sender: news@nosc.mil In article , Henning Pangels wrote: > >I'm starting to use a Motorola MVME162, which has a >PROM socket for PLCC-package chips. A local vendor claims that the >standard 27-series EPROMs *don't exist* in the PLCC package - only >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it >due to the small size. Can anyone confirm or contradict this >statement? This is not true. I'm looking at some _ceramic_, not _plastic_, eproms, in a 44-pin j-lead package, p/n "M5M27C202JK -10", made by Mitsubishi. We use them on our Moto cards. > >Henning Pangels |hmp@cs.cmu.edu | Field Robotics Center >Senior Research Programmer|(412) 268-7088 |Carnegie-Mellon University >------------------------------------------------------------------------------ > If you aren't part of the solution, you're part of the precipitate. // Wally - -- | "I can see nothing, sire.", the bowman said. | | "I only wish I had such eyes," the King remarked in a fretful tone.| | "To be able to see nobody? And at that distance, too! Why, it's as | | much as I can do to see real people by this light!" | --------------------------- Newsgroups: comp.os.vxworks Subject: bootprom questions Date: Mon, 24 Oct 1994 21:32:59 GMT From: rrailey@relay.nswc.navy.mil (Rene H. Railey) Organization: NSWCDD, Dahlgren, VA 22448 Message-ID: Sender: news@relay.nswc.navy.mil (oanews) I was wondering just how the booting process occurs in 5.0.2b with respect to the bootproms. I am using a four prom setup with vxworks and mv167 bug proms. If my setup always uses the first location , i.e. fff800000, as the start of ROM , would not this cause a error ? My vxworks proms start at fffa00000 instead. I am asking this because I am having a hard time sorting out bootInit.c as to what just is happening. In bootInit.c there are variables such as ROM_IN_BANK1 and UNCOMPRESS that I can not find out where they are. Is there a cc68k command that will give me the values of defines ? Thanks in advance Rene H. Railey ! This is my opinion Naval Surface Warfare Center ! and does not necessarily Dahlgren Division Code F33 ! reflect the views of my Dahlgren, VA 22448-5000 ! employer. (703) 663-6276 rrailey@relay.nswc.navy.mil P.S Elvis is a deadhead --------------------------- Newsgroups: comp.os.vxworks Subject: vxworks debugging tools Date: Mon, 24 Oct 1994 22:20:01 GMT From: davem@micom.com (David Monachello) Organization: Micom Communications Corp. Keywords: debug Message-ID: <1994Oct24.222001.9345@micom.com> Sender: news@micom.com hi, I'm looking into ways to improve our debug environment. We are currently using vxgdb and vxmon. I would like to use RDB and windview but I'm not sure if they would work with our system because we have our own tcp/ip protocol stack. Is this possible? Also, has anyone use vxvmi as a debug tool? I would think it would be possible to use this to track down errant memory accesses. Also, are there any other debug type tools available - wind river or 3rd party? thanks for any info, dave monachello - -- ************************************************** * Dave Monachello @ Micom Communications Corp. * * email: davem@micom.com * ************************************************** --------------------------- End of New-News digest ********************** From sergi@hpbpq5.bpo.hp.com Tue Oct 25 06:40:12 1994 From: Sergi Casas (QA Software Testing, BPO) Date: Tue Oct 25 06:40:20 PDT 1994 Subject: vxworks debugging tools Dave Monachello writes: > hi, > ... > Also, has anyone use vxvmi as a debug tool? I would think it would be > possible to use this to track down errant memory accesses. > > Also, are there any other debug type tools available - wind river or 3rd > party? > thanks for any info, > dave monachello I am also VERY interested on alternative ways to debug with vxWorks, specially erroneous memory accesses and memory leaks. Could you, please, forward me any info you may get on this subject? I think the idea of using vxvmi seems quite interesting as long as there is an MMU available; hope someone else may point out how to take advantage of it. Is there anything like Purify from Pure Software on vxWorks? (Purify is a memory control&reporting tool through object code insertion techniques, but as far as I know, does not support multitasking/multithreaded applications) I can talk about RTI's Sthetoscope & RTILib, which contain the HeapCheck modules to check the vxworks memory partitions against corruption of heap data structures. I'm using an i960 target, and RTILib has many limitations on it, but maybe in some other architectures can be pretty useful. I'm sure Stan Schneider will be glad of hearing this free advertisement and will be able to add more info. It's your turn, Stan! :-) Greetings, vxcoWorkers -- |============================================================================| | Sergi Casas ##### / ##### | | Hewlett-Packard Company ### /_ _ ### e-mail: sergi@hp-bpo.bpo.hp.com | | Barcelona Division (BCD) ## / / / / ## | | Avda. Graells, 501 ## / / /_/ ## Phone : +34 3 582 14 75 | | 08190 S. Cugat (Barcelona) ### / ### FAX : +34 3 582 25 15 | | SPAIN ##### / ##### | |============================================================================| From pearson@se01.wg2.waii.com Tue Oct 25 07:39:23 1994 From: pearson@se01.wg2.waii.com (Paul Pearson) Date: Tue Oct 25 07:39:29 PDT 1994 Subject: strptime, timegm and timelocal Our application uses a custom board to keep track of time in seconds and fractions thereof. Wind River supplies the VxWorks versions of gmtime, localtime and strftime. Do the the VxWorks versions of the inverse Unix functions strptime, timegm and timelocal exist? pearson@wg2.waii.com From guthrie@power.amasd.anatcp.rockwell.com Tue Oct 25 08:19:42 1994 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Tue Oct 25 08:19:48 PDT 1994 Subject: 27xxx EPROMS in PLCC package? Henning Pangels Writes: >I'm starting to use a Motorola MVME162, which has a >PROM socket for PLCC-package chips. A local vendor claims that the >standard 27-series EPROMs *don't exist* in the PLCC package - only >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it >due to the small size. Can anyone confirm or contradict this >statement? > >Thanks, > >- -Henning The way I figure it a PLCC package is not erasable. The "P" stands for plastic and you can't have a window on a plastic part. However, ATMEL makes a ceramic part with a window that is the same dimension as a PLCC. This part is 44 pins and is 1Mbit. I have checked with a lot of vendors and have not found much variety or any of the 4Mbit density parts. The plastic parts are cheaper and are available in the higher densities, so you could just use them as disposable PROMs. I am still considering that as an option. Robert Guthrie From dwampl@atl.com Tue Oct 25 09:30:13 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Tue Oct 25 09:30:20 PDT 1994 Subject: Fw: Re: C++ and Vxworks This is useful information. One "editorial"; I think the cygnus product is now more "plug-and-play" than it appears to have been when Peter started with it (?). Thanks for the info, Peter. dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "We begin bombing in five minutes...." 7:^] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ----- Begin Included Message ----- >From pjb@iassf.easams.com.au Mon Oct 24 19:20:29 1994 Date: Tue, 25 Oct 1994 11:39:34 +1000 (EST) >From: Peter BREW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dwampl@atl.com Subject: re: C++ and VxWorks Content-Length: 2197 Dean, If you think this is interesting then you could post it to the net. We too looked at the OC/gcc stuff for vxworks, but about 14 months ago. At that time the product was unavailable but we could get OC native for our HPs using their cfront to see what would soon be available. VxWorks only supplied (and still do) an old version of the C compiler (gcc 2.2.3). We are building a distributed avionics test system of about 200K lines of C++ on VME 68040 computers and HP workstations. OC certainly had some great features (especially the interpreter) but was far too resource hungry (money and RAM) for our project, and yes, very slow. Instead we went with cygnus support's g++, but had to do a little porting of the VxWorks supplied standard libraries. The problems are that their headers are based on an older version of the compiler and so some things have changed a little (stddef.h for eg) and that they bundle their OS calls into the standard libraries so extracting them takes a little effort. Add to this that their calls sometimes use obsolete library calls that cygnus no longer supply and you've got a headache. There's also fiddly things like making the compiler include headers in the right order and converting the vxworks headers to angle brackets because Wind River use regular quotes. We also added the iostream library to the vxworks kernel so that it is dynamically linked according to vxworks usual model. Collecting This porting has to be done (to a lesser degree) every time there is a compiler upgrade from either party. Initially it was two to three weeks effort and the stdio functions don't always work. However we have excellent response from cygnus, a completely up-to-date compiler, its fast and we have complete control over the run time environment. We use a graphical development environment called sniff to give the visualisation stuff which integrates well with the other cygnus tools. Looking back I wouldn't do it any other way. Peter Brew EASAMS Australia Pty Ltd email pjb@iassf.easams.com.au Unit 5, 2 Giffnock Avenue phone +61-2-367-4535 North Ryde NSW 2113 fax +61-2-367 4566 Australia ----- End Included Message ----- From dad@caesars.phx.mcd.mot.com Tue Oct 25 10:17:09 1994 From: dad@caesars.phx.mcd.mot.com (Don Dingee) Date: Tue Oct 25 10:17:17 PDT 1994 Subject: Re: 27xxx EPROMs in PLCC package Since there is some confusion .... The MVME162 family uses a 32 pin PLCC (plastic leadless chip carrier) for PROM. The parts which Motorola Computer Group ships are TI TMS27PC040-15FML, which are plastic one time programmable (OTP) parts. We are not aware of a 32 pin part available in ceramic, and thus having an erasure window. One other post indicated a FLASH part (28F020) which we have not tested but may work. The MVME162 also has 1MB of FLASH on board which can be used for applications. The MVME167 family uses a 44 pin CLCC, and accomodates ceramic package EPROMs such as the M5M27C202-12. These larger parts do have erasure windows. One post has indicated this, but these parts are specific to the MVME167, not the MVME162. I hope this clarifies this issue. Don Dingee, Motorola Computer Group -- Boards Marketing From stan@lassen.rti.com Tue Oct 25 15:33:29 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Tue Oct 25 15:33:37 PDT 1994 Subject: Re: vxworks debugging tools >> >> Submitted-by sergi@hpbpq5.bpo.hp.com Tue Oct 25 06:40:12 1994 >> >> I am also VERY interested on alternative ways to debug with vxWorks, >> specially erroneous memory accesses and memory leaks. Could you, please, >> forward me any info you may get on this subject? I think the idea of using >> vxvmi seems quite interesting as long as there is an MMU available; hope >> someone else may point out how to take advantage of it. >> >> Is there anything like Purify from Pure Software on vxWorks? >> (Purify is a memory control&reporting tool through object code insertion >> techniques, but as far as I know, does not support multitasking/multithreaded >> applications) >> >> I can talk about RTI's Sthetoscope & RTILib, which contain the >> HeapCheck modules to check the vxworks memory partitions against corruption >> of heap data structures. I'm using an i960 target, and RTILib has many >> limitations on it, but maybe in some other architectures can be pretty useful. >> I'm sure Stan Schneider will be glad of hearing this free advertisement and >> will be able to add more info. It's your turn, Stan! :-) >> OK, I can take a hint... BTW, all the memory utilities are now supported on the i960. I'll answer the question with an exerpt from RTILib's FAQ: --------------------------------------------------------------------------- Some answers to FAQ's (Frequently-Asked Questions) about RTILib: Q: What does HeapCheck do? How does it relate to VxVMI? To Purify? HeapCheck checks the heap (the memory managed by malloc/free) for inconsistencies. It detects any memory write that damages the heap (such as writing off the end of an array, using a bad pointer, etc.). While it detects these errors "after the fact", calls to HeapCheck can be patched in likely places in your code to help catch the problem before the damage spreads (memory errors can be like cancer). It's by no means a perfect solution, but it serves two crucial purposes: a) it tells you when memory errors are a problem, and b) it helps you track them down in a reasonable timeframe. In our experience, a) is the more important, many of our customers spend days looking for some intermittent or nasty bug they think is completely unrelated to memory usage before they try HeapCheck. We've never run into a problem that couldn't be found in an hour or so "after the fact"; most are found in minutes. In its default configuration, VxVMI protects program text segments from being clobbered. VxVMI can be set up to protect other regions of memory. [With some effort] VxVMI can also be configured to change allowed memory regions on a task switch, and thus catch inter-task bad memory references. It uses the MMU hardware, & so is fast & reliable. However, VxVMI won't catch the more common case of a task that damages its own memory, i.e. the heap. Problems like writing off the end of an array, writing to a "freed" pointer, etc. [almost always] affect the task's own memory space, and thus can't be caught by an MMU. HeapCheck can be used to detect and isolate these cases. [ To use the UNIX analogy, VxVMI works like the UNIX memory manager; it protects code segments, task interactions, and things that trash the system. HeapCheck is similar to Purify; it finds problems within a task's address space. Q: What does HeapTrace do? How is it different from HeapCheck? RTILib also contains HeapTrace, a utility that records what routine allocated each block of memory. HeapTrace is useful for detecting memory leaks (something VxVMI doesn't do at all). HeapTrace patches the VxWorks memory management routines with routines that record every transaction. Then, it can go through the heap and display what blocks were allocated by what routines, etc. It does a good job of finding memory leaks, as well as showing how and why memory is being used. For instance, there was a thread on memory leaks last year: >> From: winans@xray.aps.anl.gov (John R. Winans) >> Why does the following program continuously eat memory? [...program deleted, calls fopen/fclose repeatedly...] >> memShow() says that I consume 288 bytes each time I go around the loop. >> And once in a while, it jumps by 1704. A display from HeapTrace after 7 fopen - fclose cycles: -> HeapTraceShow 10 Blocks Total Call stack (to depth 10) 7 1960 _funcCall _fopen _open _iosOpen _netOpen _netGet _ftpXfer _ftpHookup _socket _socreate 1 1408 _ipintr _tcp_input _sonewconn _tcp_usrreq _tcp_attach _tcp_newtcpcb _m_getclr _m_more _m_expand _m_clalloc The 280-byte blocks (1960/7 = 288 with header) are allocated by the socket create code. The 1408-byte block (that with a 288-byte block and header produces a 1704-byte jump) is a network buffer (mbuf) allocated by m_clalloc down in the tcp code. Purify finds leaks by scanning all of memory for blocks that aren't referenced. That's much less reliable, slower, and harder to understand than the interactive display options used by HeapTrace. Having an on-line interactive interface is a real advantage that's simply not available to Purify. (HeapTrace actually has a Purify-style memory scan routine called "HeapTraceLeaks", but it's undocumented because of these issues. Anyone that wants to try it, drop me a line.) Q: How does FastBuffer differ from malloc? FastBuffer provides memory allocation that's 10 times faster than malloc/free. It allocates (user-specified) fixed-size memory buffers. Malloc allows any size blocks, but it's relatively slow and non-deterministic. FastBuffer can also be called in interrupt code, etc. Q: What does Trace do? How is it related to VxGDB? To UNIX/PC tools? Trace lets you monitor routines called and their parameters. For each execution of a traced routine, a record is output showing what was called, which task called it, what parameters it was called with, etc. For example, you can find out what files a program opens via: -> Trace fopen,"%s, %s" -> rshell3: 1: _fopen(setup, r) rshell3: 2: _fopen(setup.observer, r) rshell3: 3: _fopen(/local/export/rts/root/target1/setup.vis, r) rshell3: 4: _fopen(../log, w+) You can trace any function call in the system, including VxWorks system functions and your own functions. This can be a really useful tool. VxGDB is a debugger. You can stop the program at breakpoints and look at the parameter list, but it really doesn't do anything much like this. I suppose you might be able to write some sort of TCL script to print these records and continue, but it would be quite an effort to say the least. There's a (sort of) Unix equivalent called "trace" on SunOS4, "truss" on Solaris. There are a number of DOS system-call trace programs on the market. It's a really popular tool in the DOS world. [This one's only available on 68k right now.] Q: What does Patch do? What good is it? Patch allows you to insert a "hook" anywhere in any code. It inserts a routine to be called before or after any other function in the compiled code. Patch is useful for lots of things. For instance, it's how Trace gets installed to display function calls. Some other examples: To interject a 1-second delay before every call to ReadA2D: PatchSet(ReadA2D, taskDelay, 0, 60) To see if task interactions are causing problems in MyRoutine: PatchSet(MyRoutine, taskLock, taskUnlock) Another way to do the above: mutex = semBCreate(1, 1) PatchSet(SendPacket, semTake, semGive, mutex, -1, 0); To count the invocations of MyRoutine: mycount = 0; PatchSet(MyRoutine, PatchCount, 0, &mycount) [This one's only available on 68k right now.] Q. What's the difference between rshell and the VxWorks shell? Rshell is a simple remote terminal server for VxWorks. It is *not* intended as a replacement for the VxWorks shell. It only parses a very limited subset of the C language. However, rshell opens a new connection and spawns a shell process for every incoming request. So, you can have as many connections to the target as you like. You can run interactive programs without tying up the VxWorks shell. You can also send commands directly from the UNIX command line. Most users will always want a VxWorks shell connection as their primary interface. The rshell connections are useful for ancilliary functions, such as profiling, running a user menu, running spy, etc. It's also very useful when running commands that you wish to set breakpoints in (easier than spawning a process), restarting or analyzing a dead shell, etc. --------------------------------------------------------------------------- RTILib has a bunch of other stuff as well, such as a menu and user input processing package, a shared-memory server, etc., but these aren't really "tools", & I've burned enough bandwidth for today... -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From greg@eng.nmr.varian.com Tue Oct 25 16:24:36 1994 From: greg@eng.nmr.varian.com (Greg Brissey x6951) Date: Tue Oct 25 16:24:44 PDT 1994 Subject: How to pick the best VME interrupt Level & vector VxPerts, Maybe someone can help me out here. I have 3 - 4 VME boards I am controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is how to best pick the VME interrupt level and vectors for my boards. A different level for each board or a single level for all and let the order within the cardcage determine the relative priorities. Which level(s) do I pick? What vectors are safe to use. I obviously don't what to pick ones that VxWorks already uses. Or am I confused and are VME vectors different from the on board vectors. There must be some method to this madness..... Thanks in advance, Greg Brissey greg.brissey@nmr.varian.com (415) 424-6951 From daemon@vxw.ee.lbl.gov Wed Oct 26 04:00:30 1994 From: daemon@vxw.ee.lbl.gov Date: Wed Oct 26 04:00:41 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Oct 26 04:00:17 PDT 1994 Subject: Re: doing an "ls" from a program. Subject: VxWorks_User_Group email script Subject: Re: 27xxx EPROMS in PLCC package? Subject: VMIC Drivers Subject: arcnet Subject: Re: 27xxx EPROMS in PLCC package? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: doing an "ls" from a program. Date: Tue, 25 Oct 1994 13:02:45 GMT From: clegg@ssd.fsi.com Organization: Flightsafety International, Broken Arrow, OK Message-ID: <1994Oct25.130245.38189@dev1.ssd.fsi.com> References: <9410241727.AA26714@sadira.gb.nrao.edu> Reply-To: clegg@ssd.fsi.com Sender: news@dev1.ssd.fsi.com In <9410241727.AA26714@sadira.gb.nrao.edu>, tweadon@sadira.gb.nrao.edu (TIM WEADON) writes: >Does anybody know if there's a simple way to have a program do an "ls" >from a task and determine what is in the current directory vxWorks >shell is "cd'd" into ? I want the information to be returned to the task, >not to be printed up on the console as it would if you typed it into the >shell. >I'm running 5.1.1. > Use ioDefPathGet(strptr) and the current working directory will be placed in the memory pointed to by strptr. Roger Clegg clegg@ssd.fsi.com --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks_User_Group email script Date: Tue, 25 Oct 1994 12:50:39 GMT From: bjm_vloedbeld@hgl.signaal.nl (B.J.M. Vloedbeld) Organization: Hollandse Signaal apparaten BV Message-ID: <1994Oct25.125039.10488@hgl.signaal.nl> Sender: usenet@hgl.signaal.nl (USENET News System) Hello, I received a couple of questions about my script that evaluates the email from the VxWorks_User_Group. I hope you that you can use it. (And like it) success, --Ben-- - -- ============================================================================== = B.J.M. Vloedbeld Dept:SDA-DID-DIM Org:Hollandse Signaalapparaten B.V. = = Adress : P.O.box 42 7550 GD Hengelo, The Netherlands = = Phone :+31-74-483994 FAX:+31-74-484009 email:bjm_vloedbeld@hgl.signaal.nl = =============================================================[Unclassified]=== #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 10/25/1994 11:09 UTC by db158@sun52 # Source directory /ufs/sd1c/work/oaerms/db158/work/vxworks/vug_email # # existing files will NOT be overwritten unless -c is specified # This format requires very little intelligence at unshar time. # "if test", "echo", "true", and "sed" may be needed. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 7854 -rwxr-xr-x get_it_from_email # # ============= get_it_from_email ============== if test -f 'get_it_from_email' -a X"$1" != X"-c"; then echo 'x - skipping get_it_from_email (File already exists)' else echo 'x - extracting get_it_from_email (Text)' sed 's/^X//' << 'SHAR_EOF' > 'get_it_from_email' && X#! /bin/sh X X# ============================================================================== X# = B.J.M. Vloedbeld Dept:SDA-DID-DIM Org:Hollandse Signaalapparaten B.V. = X# = Adress : P.O.box 42 7550 GD Hengelo, The Netherlands = X# = Phone :+31-74-483994 FAX:+31-74-484009 email:bjm_vloedbeld@hgl.signaal.nl = X# ========================================================[Unclassified]======== X# X# version 1.0 Oct-20-1994 X# X# licensing+rights : conform " GNU GENERAL PUBLIC LICENSE" X# a copy can be obtained from the above email adres or X# even BETTER ==>> write to Free Software Foundation Inc. X# 675 Mass Ave X# Cambridge, MA 02139, USA X# X# This program is distributed in the hope that it will be useful, X# but ABSOLUTELY WITHOUT ANY WARRANTY; without even the implied warranty of X# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the X# GNU General Public License for more details. X# X# X# usage : this program can be placed anywhere ,and with the name you like X# ( e.g. in the 'vug_exp_dir' as : .get_it_from_email ) X# it is called by cron, example crontab-line : X# 15 22 * * * ( cd /usr/users/vxworks/INFO_files/vxWorks_Users_Group_Exploder_email && ./.get_it_from_email 2>/dev/null ) X# X# I used the name .get_it_from_email, so that users normally would not X# be confused by the file .get_it_from_email . X# I have placed the script and the data in one directory. X# 'ls -la' in the directory : X# total 2022 X# drwxr-sr-x 3 db158 1024 Oct 21 09:21 . X# drwxrwxr-x 5 oaerms 512 Jun 1 15:07 .. X# -rwxr-xr-x 1 db158 7051 Oct 21 09:49 .get_it_from_email X# drwxr-sr-x 2 db158 3584 Oct 21 09:19 .safe X# -r--r--r-- 1 db158 56279 May 26 13:43 940526 X# -r--r--r-- 1 db158 31640 May 27 15:45 940527 X# ........ and more files X# -r--r--r-- 1 db158 79279 Oct 9 22:15 941009 X# -r--r--r-- 1 db158 140997 Oct 16 22:15 941016 X# -rw-r--r-- 1 db158 60501 Oct 21 09:19 this_week_vxworks_ug_mail_file X# X# X X# init X########################## X# name of directory where all the vxWorks_Users_Group_Exploder_email is placed Xvug_exp_dir=/usr/users/vxworks/INFO_files/vxWorks_Users_Group_Exploder_email X# name of 'mailbox' file (user who subscribed) Xmailbox_file=/var/spool/mail/db158 X# for test only..... XDEBUG=false X# information about available vug-info wil be sent to this list of all (internal) users XMail_to_users='_vxworks' X# parameters ? Xif [ $# -gt 0 ] ; then X # DEBUG mode ? X if [ "$1" = "-d" ] ;then X echo "******* DEBUG mode ********" X DEBUG=true X cp $mailbox_file $vug_exp_dir/tmp_mailbox X mailbox_file=$vug_exp_dir/tmp_mailbox X Mail_to_users=db158 X fi Xfi X X X# var MAIL is used by some mail tools XMAIL=$mailbox_file X# this variable defines the here used mail tool XMAILER=/usr/ucb/mail X# string that is used to search email XSender_string="vxwexplo@lbl.gov" X# name of file that contains the vug data Xnew_msg_file=`date '+%y%m%d'` X# name of ELM XELM="/usr/users/tools/bin/elm" X# be sure that all here needed executables can be found XPATH=$PATH:/usr/users/tools/bin Xexport PATH Mail_to_users ELM MAIL MAILER DEBUG new_msg_file X X# ELM must be available Xif [ ! -d /usr/users/tools/elm ] ; then X echo "ELM is not available " X exit 1 Xfi X# $MAIL must be available Xif [ ! -f $MAIL ] ; then X echo "mailbox $MAIL is not available" X exit 1 Xfi X X# save vxworks email en andere data X################################### Xcd $vug_exp_dir X#tmpfile=tmp_`date '+%y%m%d_%H%M%S'` ;export tmpfile Xtmpfile=this_week_vxworks_ug_mail_file ;export tmpfile X# create a 'script' file for $MAILER X$MAILER -H |sed -e 's/^[ ]*//' -e 's/^[A-Z]*//' -e 's/^[ ]*//' |\ X awk "\$2 ~ /^$Sender_string\$/ \ X {printf \"save %d $tmpfile\\ndelete %d\\n\" , \$1 , \$1} \ X END{printf \"quit\\n\"}" > Mailer_script_file X# read now all 'vug' email, and write that to a temp file with all vig mail of 'this' week X# /usr/ucb/mail works better (easier) then 'readmsg' of ELM. /usr/ucb/mail is also able to delete the msg , readmsg (elm) not X# ELM can not work with a script file X X######## TEST !!!!! X# save first the current $tmpfile, until this program is proven 'bugfree'.......... X# IF bugfree THEN 'comment' lines between 'start test fase' and 'end test fase' X# start test fase*************************** Xcp $tmpfile ./.safe/test_only_${tmpfile}_`date '+%y%m%d_%H%M%S'` X(echo "============= TEST fase $Sender_string `date` =========== X Xfile $tmpfile bevat NU :" Xmail -f $tmpfile -H ) |$MAILER -s 'TEST' db158 X# end test fase*************************** X X(MAILRC=Mailer_script_file ;export MAILRC MAIL ; $MAILER -n -f $MAIL >/dev/null) X X# IF day = "sunday" AND there is mail from $Sender_string mail THEN $tmpfile is present and not empty X################################################################################################### X[ -s $tmpfile ] || echo "*** '$Sender_string' get_it_from_email*** NO-MAIL today" Xif [ \( "`date '+%a'`" = "Sun" \) -a -s $tmpfile ] ; then X # bericht naar "$Mail_to_users" X awk "BEGIN{ msg_cnt=0 X subject_plek=9999 X line_length=9999 X msg_flg=\"init\" X nss=\" no subject specified by sender\" X subj=nss X print X printf \"\\t******************************************\\n\" X printf \"\\t*** ***\\n\" X printf \"\\t*** vxWorks Users Group Exploder email ***\\n\" X printf \"\\t*** ***\\n\" X printf \"\\t******************************************\\n\" X print X printf \"\\tdate : %s\\n\" , \"`date '+%d %h %y'`\" X print X printf \"--------------------------------------------------------------------------------\\n\" X } X { from_plek=index(\$0 ,\"From \") X # NEW MESSAGE starts NOW , start of new header !!! X if ( from_plek == 1 ) \ X { # print info from previous message X if ( msg_flg != \"init\" ) printf \"message %3d : %s\\n\" ,msg_cnt , subj X msg_flg=\"start_of_header\" X msg_cnt++ X subj=nss X } X subject_plek=index(\$0 ,\"Subject:\") X line_length=length(\$0) X # are we in the message header ? X if ( ( msg_flg == \"start_of_header\" ) && ( line_length == 0 ) ) msg_flg = \"end_of_header\" X # real SUBJECT in header ??? X if ( ( msg_flg == \"start_of_header\" ) && ( subject_plek == 1 ) ) subj=substr ( \$0 , 9 , length(\$0)) X }\ X END { # print once the info of the last message X printf \"message %3d : %s\\n\" ,msg_cnt , subj X # print some information X printf \"--------------------------------------------------------------------------------\\n\" X print X printf \"These messages are available in :\\n\" X printf \"directory - %s\\n\" , \"$vug_exp_dir\" X printf \"file - %s\\n\" , \"$new_msg_file\" X printf \"file format - mailbox \\n\" X print X printf \"You can use any mail reader ,for instance :\\n\" X printf \" mail -f $vug_exp_dir/$new_msg_file\\n\" X printf \" elm -f $vug_exp_dir/$new_msg_file\\n\" X printf \"or...any way you like......\\n\" X print X }" $tmpfile >tmp_file_for_elm_message_to_send X X # IF there is 'tmp_file_for_elm_message_to_send' AND NOT empty X # THEN the information about all the available 'vug' messages can be send to the 'Mail_to_users' list X [ -s tmp_file_for_elm_message_to_send ] && ( X cat tmp_file_for_elm_message_to_send |\ X $ELM -s 'vxWorks Users Group Exploder email' $Mail_to_users >/dev/null 2>&1 X ) X X X # rename $tmpfile to a real name X mv $tmpfile $new_msg_file X chmod 444 $new_msg_file X X # remove NOW the $tmpfile !! X rm -f $tmp_file Xfi X X# DO NOT remove here the $tmpfile !! Xrm -f tmp_file_for_elm_message_to_send Mailer_script_file SHAR_EOF true || echo 'restore of get_it_from_email failed' fi exit 0 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 27xxx EPROMS in PLCC package? Date: 25 Oct 1994 17:16:32 -0000 From: simona@abekrd.co.uk (Simon Aglionby) Organization: Abekas Video Systems Ltd, Reading, UK. Message-ID: <38jehg$36o@willow.abekrd.co.uk> References: In hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: >I'm starting to use a Motorola MVME162, which has a >PROM socket for PLCC-package chips. A local vendor claims that the >standard 27-series EPROMs *don't exist* in the PLCC package - only >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it >due to the small size. Can anyone confirm or contradict this >statement? As I understand it (as a mere hardware designer), your vendor is strictly correct - *erasable* 27C0x0 chips don't come in PLCC (plastic leaded chip carrier), only OTP (one time programmable) devices, or effectively PROMs, come in PLCC. For a price, you can get most of them in windowed ceramic LCC (leadless chip carrier), but LCC and PLCC are not interchangeable in the same socket - you need a CLCC (ceramic leaded chip carrier), which (tell me I'm wrong) I haven't seen at the 32 pin size of 27C010/20/40 devices. I have seen 44 pin CLCC programmable logic devices - typically 4 times the price of the same device in PLCC. This is only the same as DIP - windowed EPROMs are in ceramic DIP, and OTP PROMs are in non-windowed plastic. The chip inside is the same, but without a UV transparent window, you don't get to erase the plastic packaged devices. Basically you don't get windows in plastic packages. I'm not familiar with the MVME162, but the obvious possibilities are either to buy lots of OTP PLCC devices and keep throwing them away till you get the code right, or checkout the pinout of a 5V only flash device of appropriate size. If it fits, and the MVME162 will allow a write operation to what it thinks is a read only area of memory, reprogram the flash in situ; if not reprogram the chip in your programmer. Simon Aglionby --------------------------- Newsgroups: comp.os.vxworks Subject: VMIC Drivers Date: Tue, 25 Oct 1994 19:59:05 GMT From: zal@bnlux1.bnl.gov (gonzalo maldonado) Organization: Brookhaven National Laboratory, Upton, NY 11973 Message-ID: <1994Oct25.195905.6887@bnlux1.bnl.gov> Does anyone have a driver for the VMIC-2170 Digital Output board and/or the VMIC-1160 Digital Input board (besides VMIC itself). Thanks ***************************************************************************** * Zal Maldonado Brookhaven National Laboratory * * zal@bnl.gov * ***************************************************************************** --------------------------- Newsgroups: comp.os.vxworks Subject: arcnet Date: Tue, 25 Oct 1994 21:34:38 GMT From: desmond@rsgi02.rhic.bnl.gov (Edmond Desmond) Organization: Brookhaven National Laboratory Message-ID: <1994Oct25.213438.13666@bnlux1.bnl.gov> Sender: news@bnlux1.bnl.gov (Usenet news) Keywords: arcnet Does anyone know of a driver written for the Compcontrol CC121 ARCNET interface module. This is the only VME module I have been able to locate which provides an ARCNET interface. If anyone knows of another I would appreciate the information. This is for an application to download data from a VME system to a set of distributed PMT front end electronic modules for the PHENIX detector. Thanks, Ed Desmond Brookhaven National Laboratory email: desmond@rsgi02.rhic.bnl.gov phone: (516) 282-4768 fax: (516) 282-3253 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 27xxx EPROMS in PLCC package? Date: Tue, 25 Oct 1994 22:36:35 GMT From: dkessner@vigra.com (David Kessner) Organization: Vigra, San Diego, CA Message-ID: References: <1994Oct24.175623.5150@nosc.mil> Newsgroups: comp.os.vxworks Organization: NCCOSC RDT&E Division, San Diego, CA Date: Mon, 24 Oct 1994 17:56:23 GMT In article , Henning Pangels wrote: > >I'm starting to use a Motorola MVME162, which has a >PROM socket for PLCC-package chips. A local vendor claims that the >standard 27-series EPROMs *don't exist* in the PLCC package - only >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it >due to the small size. Can anyone confirm or contradict this >statement? This is not true. I'm looking at some _ceramic_, not _plastic_, eproms, in a 44-pin j-lead package, p/n "M5M27C202JK -10", made by Mitsubishi. We use them on our Moto cards. The standard ceramic window'd package is very expensive. The costs of a UV erasable EPROM with a windowed package is more expensive than the costs of a Flash based EPROM in a plastic package. Given that, chip makers have started to phase out the windowed packages and the first to go were the ones with the lowest volumn-- the 27XXX series of EPROMS. We've found that some Windowed-DIP EPROMs are getting harder to find. The solution is to use Flash 28XXX (or is it 29XXX?) series chips insted, since they are cheaper, pin compatable, and more importantly they are available. On the other hand, I have some Misubishi M5M27C020JK's right here and they work just fine. David Kessner dkessner@vigra.com --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Wed Oct 26 04:50:07 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Wed Oct 26 04:50:14 PDT 1994 Subject: Re: How to pick the best VME interrupt Level & vector Greetings! > Submitted-by: greg@eng.nmr.varian.com (Greg Brissey x6951) > > VxPerts, > > Maybe someone can help me out here. I have 3 - 4 VME boards I am > controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is > how to best pick the VME interrupt level and vectors for my boards. > A different level for each board or a single level for all and let > the order within the cardcage determine the relative priorities. > Which level(s) do I pick? What vectors are safe to use. I > obviously don't what to pick ones that VxWorks already uses. > Or am I confused and are VME vectors different from the on board vectors. > > There must be some method to this madness..... > Well, it all depends on how you're trying to use the system and how many other boards will be there. From your description, you could do either approach and end up with a working system. However, a few rules of thumb/explainations are perhaps in order. I'm not that familiar with the 162LX per se, but in general (at least for the 68K family, things are different for architectures such as SPARC and i960) there are 256 interrupt vectors -- the first 100 (0x64) are usually reserved. An interrupt vector is essentially nothing more than a pointer to an interrupt handler (ISR). The hardware will typically support both on-board hardware such as SCSI, Ethernet, RS-232, etc. and off-board (i.e., VMEbus) hardware interrupts. The hardware interrupt is then connected to a software vector either by filling in the vector table directly (the vector table occupies the first 0x400 bytes in a 68K address space by default) or via a mechanism such as intConnect. The on-board interrupt sources do not generally interfere with (i.e., occupy) any of the interrupt *levels* from the VMEbus. You'll have to check your board (using Jeff Hill's fabulous "veclist.c" code from the User's Group archives) to see with interrupt vectors are attached in your system. An interrupt *level* is a hardware signal from the VMEbus. You have interrupt level *generators* and interrupt level *responders*. As you've alluded to in your message, you know about the ability to have multiple interrupt generators at the same level and just use the vector to sort out *which* generator raised the interrupt level. During the interrupt cycle on the bus, the generator (G) raises the level, the responder (R) (you can only have one R per *level*) will assert the interrupt acknowledge (IACK* -- remember the IACK pins on the bus that have to be jumpered if you have an empty slot?) signal and the *first* G on the daisy chain that's expecting an IACK* will intercept it. Then the G arbitrates the bus and places the interrupt *vector* number on the data lines. The R then responds with DTACK* (data transfer acknowledge) and the interrupt *bus* cycle is complete. This is where your ISR starts running (based on the interrupt vector number) and you may do additional transfers on the bus to service the hardware. What happens if the interrupt Gs are all at the same interrupt level is that we get an inherent priority of the devices based on their physical location in the bus (first card in the daisy chain is highest because it has first "dibs" on the IACK* signal as it comes down the wire and so on). In a system with lots of interrupt activity at the same level, you get the same exponential decay of interrupt service that we see in bus arbitration of requests at the same level. That is, the last card in the rack gets the poorest service -- occasionally to the point of the interrupt cycle failing entirely. The VMEbus interrupt levels have a hard-wired priority where level 7 is highest and level 1 is lowest. I don't recommend using level 7 (there's been lots of discussion on this forum recently about the reasons why so I won't belabor the discussion) so you boil down to either using the hardwired priorities of the VMEbus levels, or the de-facto priorities of the location of the card on the daisy chain. Either way you have a priority-oriented scheme, but with different levels, you have a more well-known (and hopefully better understood) mechanism that allows you better control of the absolute priorities of interrupts in your system. If you've got the levels to burn, I'd use them. I'd only use the same level approach if I had lots of boards in the system (especially if I've got say 6+ of one kind) and couldn't give each board its own level. I'm not sure how the 162's IP modules impact this discussion, but I believe that they will use "on-board" interrupts and hence not interfere with the off-board VMEbus levels. Hope this helps, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From mea@mclean.sparta.com Wed Oct 26 04:58:53 1994 From: mea@mclean.sparta.com (Mike Anderson) Date: Wed Oct 26 04:59:00 PDT 1994 Subject: Re: PLCC PROMs for MVME162 Greetings! > In article , > Henning Pangels wrote: > > > >I'm starting to use a Motorola MVME162, which has a > >PROM socket for PLCC-package chips. A local vendor claims that the > >standard 27-series EPROMs *don't exist* in the PLCC package - only > >PROMs, not erasable. I'm surprised at this, but I guess I'd believe it > >due to the small size. Can anyone confirm or contradict this > >statement? > Does anyone know if the EPROM emulator companies have PLCC-equivalent adapters? This might be a way to go to "get it right" before burning the PLCC PROMs. Maybe something like the XLNT Designs NetROM product. Just a thought. Regards, =============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Director, Real-Time Systems // / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235 // \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323 \\ \ // Suite 900 EMAIL : mea@mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." =============================================================================== From tweadon@sadira.gb.nrao.edu Wed Oct 26 05:16:25 1994 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Wed Oct 26 05:16:33 PDT 1994 Subject: Re: comp.os.vxworks newsdigest > >Does anybody know if there's a simple way to have a program do an "ls" > >from a task and determine what is in the current directory vxWorks > >shell is "cd'd" into ? I want the information to be returned to the task, > >not to be printed up on the console as it would if you typed it into the > >shell. > >I'm running 5.1.1. > > > Use ioDefPathGet(strptr) and the current working directory will be placed in the memory > pointed to by strptr. > Roger Clegg > clegg@ssd.fsi.com I guess I didn't make my question clear enough, since all my responses have told me how to determine which directory is the "present working directory". What I'm looking for is a list of the files in the current working directory ie: what "ls" typically does for you. Thanks Tim Weadon National Radio Astronomy Observatory Green Bank, WV. 24944 From prb@aplexus.jhuapl.edu Wed Oct 26 05:42:43 1994 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Wed Oct 26 05:42:52 PDT 1994 Subject: Re: vxworks debugging tools and run-time checks Hi, If you are looking for a better debugger for vxWorks, you may want to take a look at MULTI which is offered by Green Hills / Oasys. The toolset works for C, C++, and Ada. It includes compilers, builders, version control, and a slick debugger. We are familiar with Makefiles and already have a revision control system set up, so we have only been evaluating the compiler and debugger. The debugger provides a much much much nicer user interface than vxgdb. The compiler mentions run-time checking using a compiler switch. Run-time checking when implemented would check for memory leaks, array bound indexes, nil pointer deferences, etc. The run-time checking is not yet implemented due to lack of support in the Wind Kernel. I have been speaking to Wind River in hopes that I can influence them to provide the necessary instrumentation of the kernel. They have mentioned adding run-time checks to their Wind-View Product, but I feel this is the wrong approach. I want to be able to turn on and off runtime checks with a compiler flag so that I can produce the most efficient code. If you are interested in these run-time checks please call Wind River and express this interest. I can provide a contact a Wind River if you want one. +====================================================================+ | __ ____ __ __ | | /\ \ / \ \ /\_\__ /\ \ Johns Hopkins University | | / \_\ | /\ \ \ / / /\_\\ \ \ Applied Physics Lab. | | / /\ | |\ \/ \ \ / / / / / \ \ \ | | / \/ |_| \ /\ \_\ / / / / / \ \ \ Paul R. Bade | | / /\__/_/ \ \ \/_// / / / / / / / (301)-953-6000 x8681 | | / / / \ \_\ \ \/ / / / / / prb@aplexus.jhuapl.edu | | \/_/ \/_/ \__/_/ \/_/ | | __ ____ __ __ | | /\ \ / \ \ /\ \ /\ \ | | / \_\ | /\ \ \ / \_\ / \ \ | | / /\ | |\ \/ \ \ / /\ |_| / /\ \ \ | | / \/ |_| \ /\ \_\ / / / | | \/ / \ \ | | / /\ / / \ \ \/_// / / / / / /\ \_\ | | \ \/ / / \ \_\ \ \/ / / \/ / / / | | \__/_/ \/_/ \__/_/ /_/_/ | | | +====================================================================+ From dwampl@atl.com Wed Oct 26 09:16:36 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Wed Oct 26 09:16:42 PDT 1994 Subject: Capturing "tt" to a string I would like to capture the output of "tt" to a char. string, or find a function that provides similar functionality without having to play games with "stdout". Any suggestions? Thanks, dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From hill@luke.atdiv.lanl.gov Wed Oct 26 14:46:48 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Wed Oct 26 14:46:54 PDT 1994 Subject: Re: unbuffered socket send > > we're sending variable-length messages via a socket to a remote > data collection box > > it's imperative that the sends happen as they are generated > > however, it appears the message data may be getting buffered until > there is enough to output (or perhaps a timeout occurs) > > using vxWorks 5.1.1 (under VADSworks) on a 68040 > > tried doing an FIOFLUSH ioctl call for the socket after the send > but that didn't seem to help > Check out the TCP_NODELAY socket option. Jeff From sdarensb@milton.viasat.com Wed Oct 26 15:17:14 1994 From: sdarensb@milton.viasat.com Date: Wed Oct 26 15:17:21 PDT 1994 Subject: Problem with Startup Script Our startup scripts down loads our executable and then starts our executive by spawning some tasks. After our application finishes initializing, I get a data access exception from the tRootTask, and I cannot access the shell or rlogin into the target. At this point, our application is executing fine, which uses the ethernet, and I cannot get back to the by typing control c. I get the data access exception about every other time I reboot, and everything work normally when I don't get the ERROR. The tRootTask appears to be a boot task because I do not see it when I do an i command. If I execute our startup script from the shell after the target is booted with the < command, I do not get the ERROR. It appears to me that something might not be completely initialized before our application accesses it. Has anyone ever seen a similar problem or have any suggestions for finding the problem. We need to have access to the shell after our application starts so the user can enter an occasional command. We could live with the ERROR if we could restart the shell and take input from the console with our application running. We are running 5.1 on a SPARC 2LC from Themis. All of the tasks in our application have a priority between 5 and 20. To initialize, our application probes the VMEbus to see which devices are on-line and then download data to the devices that are on-line from files on our workstation. We are using ftp instead of rsh to boot the targets. thanks in advance for any help Shelton Darensburg From mmuri@qualcomm.com Wed Oct 26 16:02:57 1994 From: mmuri@qualcomm.com (Mark Muri) Date: Wed Oct 26 16:03:03 PDT 1994 Subject: NFS server on VxWorks People, Is there an NFS server for VxWorks? We're actively using the NFS client stuff. Maybe I'm not reading the manual (5.1.1) right... Just hooked some SCSI disks up and wanted to access them from other cards within the same cage (across the Shared Memory network). NFS is the way to go. I can FTP to the card (from Solaris) and get/put to the disk. Thanks. Mark Muri <=================o=====================================================> | Mark Muri | E-Mail: mmuri@qualcomm.com (619) Work: 658-3303 | | Senior Engineer | Office: Q-244A Fax: 658-2108 | | QUALCOMM, Inc <+> Car: 895-8315 | | 6455 Lusk Blvd., San Diego, CA 92121 Pager: 636-0446 | <=======================================================================> From daemon@vxw.ee.lbl.gov Thu Oct 27 04:00:32 1994 From: daemon@vxw.ee.lbl.gov Date: Thu Oct 27 04:00:40 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Oct 27 04:00:15 PDT 1994 Subject: VxWorks faq? Subject: LAT for VXWorks ??? Subject: Cyclone Microsystems ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks faq? Date: Wed, 26 Oct 1994 14:49:00 GMT From: rusty@indirect.com (Rusty Carruth) Organization: Internet Direct, indirect.com Message-ID: Sender: usenet@indirect.com (System Operator) Hi, Vxperts! We are considering using vxworks for one of our products. The competitor is OS/2 (yikes, what a difference!). (And I'm not sure I want to waste the bandwidth required to explain why those 2 choices - besides, *I* wanted us to use Lynx....) Here's the scoop (more or less): This is mostly a user interface system - most of its job is "just" to display info to the user and take user commands (and control the automatic display of realtime information in response to those commands, and to change operating modes of the system based on user commands). We do have SOME time constraints, but this is mostly not a realtime system (in what I would consider the classical sense - yes, we DO display realtime data, but without direct intervention of the user interface computer). The user interface computer is going to be a 386, a 486, or a pentium - most probably we are looking at a 486 or pentium. Video from the video source is combined with video from the user interface computer (from now on I'll just call it the computer) by hardware somehow. (Currently hardware has not decided exactly how that is going to happen. We may use a standard VGA for the computer, and do some sort of combining, who knows (this means we MAY need some sort of drivers written for whatever os we choose)). The users of the system will have available a softkey menu thing (probably using an LCD display) that allows them to make choices (another thing we will probably need a driver for). The displays from the computer will have mixed graphics and text, and will need to be placed exactly where we want them to go on the computer display "screen". We will need to do some sort of windowing also, allowing folks to see multiple realtime images, reports, and such like stuff also. Oh, yes - the users will need to be able to take various measurements from the screen using onscreen cursors. Probably not enough info, but - if you were to choose an OS for this project (which needs to be shipped to customers by end of 95, and which needs to have basic functionality (all hardware controls in response to user input working right) by middle of next year, which is expected to consist of about 100,000 lines of code, and have a group of 12 software folks doing it. So - what would you folks choose? and why? As always, email preferred (and I'll summarize - in traditional net fashion ;-) - -- Rusty Carruth aka N7IKQ aka rusty@indirect.com Broken: rusty@descomp.com The Phoenix Linux User's group has formed! Details: me. --------------------------- Newsgroups: comp.os.vxworks Subject: LAT for VXWorks ??? Date: Wed, 26 Oct 1994 15:44:55 GMT From: segrest@bobseg.enet.dec.com () Organization: Me and only Me Message-ID: <1994Oct26.154455.17862@datum.nyo.dec.com> Reply-To: segrest@bobseg.enet.dec.com () Sender: usenet@datum.nyo.dec.com (USENET News System) Has anyone ported the LAT protocol into VxWorks ?? Is anyone interested ?? - -- Bob Segrest --------------------------- Newsgroups: comp.os.vxworks Subject: Cyclone Microsystems Date: 26 Oct 1994 13:52:46 GMT From: saeten@hannover.sgp.slb.com (Arne Saeten) Organization: Schlumberger, Geco-Prakla Message-ID: <38lmve$c12@snlsu1> Reply-To: saeten@ghas32.hannover.sgp.slb.com Hello! Anyone out there got the fax # or email-addr. to Cyclone Microsystems?? ( Support/technical support). Arne Saeten Geco-Prakla Schlumberger --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Fri Oct 28 04:00:25 1994 From: daemon@vxw.ee.lbl.gov Date: Fri Oct 28 04:00:36 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Oct 28 04:00:14 PDT 1994 Subject: WindC++/VxWorks5.0.2 Subject: VGA for VxWorks Subject: Re: How to pick the best VME interrupt Level & vector Subject: re: comp.os.vxworks newsdigest Subject: re: 27xxx EPROMs in PLCC Subject: Re: Cyclone Microsystems ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: WindC++/VxWorks5.0.2 Date: Thu, 27 Oct 1994 10:24:47 GMT From: takihiro@sdl.hitachi.co.jp (Takihiro Masatoshi) Organization: Systems Development Lab., Hitachi Ltd., JAPAN Message-ID: <1994Oct27.102450.14728@hsdlgw92.sdl.hitachi.co.jp> Sender: news@hsdlgw92.sdl.hitachi.co.jp (News manager) Hello, We are planning to use "Wind C++". It supports VxWorks Ver. 5.1 but we are using Ver. 5.0.2. Does anybody has experience "Wind C++" with VxWorks Ver.5.0.x? Our agency said that they didn't know whether it was possible or not. Any information will be helpful to us. Thanks. - -- - -- TAKIHIRO Masatoshi S03U Systems Development Laboratory, Hitachi, Ltd. E-mail : takihiro@sdl.hitachi.co.jp --------------------------- Newsgroups: comp.os.vxworks Subject: VGA for VxWorks Date: Thu, 27 Oct 1994 15:34:29 GMT From: segrest@bobseg.enet.dec.com () Organization: Me and only Me Message-ID: <1994Oct27.153429.8796@datum.nyo.dec.com> Reply-To: segrest@bobseg.enet.dec.com () Sender: usenet@datum.nyo.dec.com (USENET News System) I am looking for an ISA or PCI graphics card with a VxWorks driver. Does anyone make one ?? Has anyone written a generic VGA driver of some sort for VxWorks ?? Is there anything in the public domain ?? Is anyone else interested in this kind of product ?? If I have to write a device support package from scratch, what functionality functionality would you like to see ?? - -- Bob Segrest --------------------------- Newsgroups: comp.os.vxworks Subject: Re: How to pick the best VME interrupt Level & vector Date: 27 Oct 1994 18:29:13 GMT From: vanandel@stout.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <38orhp$did@ncar.ucar.edu> References: <9410252326.AA05295@eng.nmr.varian.com> Sender: vanandel@canoe (Joe Van Andel) In article <9410252326.AA05295@eng.nmr.varian.com>, greg@eng.nmr.varian.com (Greg Brissey x6951) writes: |> VxPerts, |> |> Maybe someone can help me out here. I have 3 - 4 VME boards I am |> controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is |> how to best pick the VME interrupt level and vectors for my boards. |> A different level for each board or a single level for all and let |> the order within the cardcage determine the relative priorities. |> Which level(s) do I pick? What vectors are safe to use. I |> obviously don't what to pick ones that VxWorks already uses. |> Or am I confused and are VME vectors different from the on board vectors. |> Wind River has a tech. note on how to determine which vectors are used. If you can find the interrupt vector table (frequently at the start of your on-board RAM), you can determine which vectors are unused, since all unused vectors point to the same entry point (excIntStub). If you disassemble the routine pointed to by a used interrupt vector, you'll see something like: 403b1ea0 4eb9 4004 4faa JSR _intEnt 403b1ea6 48e7 e0c0 MOVEM .L D0-D2/A0-A1,-(A7) 403b1eaa 2f3c 0000 0001 MOVE .L #00001,-(A7) 403b1eb0 4eb9 4000 276c JSR _tyCoIntWr 403b1eb6 588f ADDQ .L #0x4,A7 403b1eb8 4cdf 0307 MOVEM .L (A7)+,D0-D2/A0-A1 403b1ebc 4ef9 4004 4fbc JMP _intExit 403b1ec2 ffaf DC.W 0xffaf 403b1ec4 403b DC.W 0x403b 403b1ec6 1e98 MOVE .B (A0)+,(A7) Interrupt vectors 64-255 (offset 0x100-0x3fc) are available for use by interrupts generated by your boards, assuming your MVME162LX isn't using them for on-board devices. (You can look at your board support package to determine which on-board devices use which interrupt vectors). Regarding choosing interrupts levels, first of all, don't use level 7 interrupts, since no operating system (including VxWorks) can mask them out during critical sections. It is generally better to use different interrupt levels, rather than relying on the order within the cardcage, simply because it makes your system easier to re-configure. If you decide to change the priority of different cards, wouldn't you rather re-compile, rather than swap boards? In general, you need to determine which of your boards has the highest priority based on your application, and the characteristics of your boards. If a board needs to be serviced within a given period of time to avoid losing data, then you need to give it a higher interrupt priority level. For example, some serial I/O cards have very little buffering for incoming characters, so if you are servicing higher priority interrupts continuously, you could miss characters. - -- Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: re: comp.os.vxworks newsdigest Date: 27 Oct 1994 18:34:33 GMT From: vanandel@canoe.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <38orrp$did@ncar.ucar.edu> References: <9410261216.AA05138@sadira.gb.nrao.edu> Sender: vanandel@canoe (Joe Van Andel) tweadon@sadira.gb.nrao.edu (TIM WEADON) writes: |> I guess I didn't make my question clear enough, since all my responses have told me |> how to determine which directory is the "present working directory". |> What I'm looking for is a list of the files in the current working directory |> ie: what "ls" typically does for you. |> |> Thanks |> Tim Weadon |> National Radio Astronomy Observatory |> Green Bank, WV. 24944 I believe you want to look at "dirLib", to get a list of files in a given directory. You would have to pass the current directory to opendir() - -- Joe VanAndel Internet: vanandel@ncar.ucar.edu National Center for Web http://www.atd.ucar.edu/jva/home.html Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: re: 27xxx EPROMs in PLCC Date: Thu, 27 Oct 94 21:55:00 +0001 From: john.irving@almac.co.uk (JOHN IRVING) Organization: ALMAC : Grangemouth, Scotland : +44 (0)1324 665371 Message-ID: <89C9523.0278000E2F.uuout@almac.co.uk> Reply-To: john.irving@almac.co.uk (JOHN IRVING) dad@caesars.phx.mcd.mot.com writes: DD>The MVME167 family uses a 44 pin CLCC, and accomodates ceramic DD>package EPROMs such as the M5M27C202-12. These larger parts do DD>have erasure windows. One post has indicated this, but these DD>parts are specific to the MVME167, not the MVME162. These square EPROMs are wonderful - if you pull them out of the sockets and push them back in a couple of times, the pins lose their profile and short out at the corners... -- John Irving, Cheltenham (john.irving@almac.co.uk) - --- * POW 1.1 On Trial * With my Stealth Modem, you'll never see me coming! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Cyclone Microsystems Date: Thu, 27 Oct 1994 22:35:18 GMT From: jfinley@netcom.com (John Finley) Organization: NETCOM On-line Communication Services (408 261-4700 guest) Message-ID: References: <38lmve$c12@snlsu1> Arne Saeten (saeten@hannover.sgp.slb.com) wrote: : Anyone out there got the fax # or email-addr. to : Cyclone Microsystems?? ( Support/technical support). Fax (203) 786-5025 Voice (203) 786-5536 They're cyclone.com, but I don't know any accounts. John Finley jfinley@netcom.com --------------------------- End of New-News digest ********************** From 100073.647@compuserve.com Fri Oct 28 06:51:31 1994 From: "Bloomfield (2)" <100073.647@compuserve.com> Date: Fri Oct 28 06:51:38 PDT 1994 Subject: Subscription Please could you send us subscription information for the VxWorks user group From dwampl@atl.com Fri Oct 28 09:00:56 1994 From: dwampl@atl.com (Dean Wampler (dwampl@atl.com)) Date: Fri Oct 28 09:01:02 PDT 1994 Subject: Re: Subject: WindC++/VxWorks5.0.2 > > Newsgroups: comp.os.vxworks > Subject: WindC++/VxWorks5.0.2 > Date: Thu, 27 Oct 1994 10:24:47 GMT > >From: takihiro@sdl.hitachi.co.jp (Takihiro Masatoshi) > Organization: Systems Development Lab., Hitachi Ltd., JAPAN > Message-ID: <1994Oct27.102450.14728@hsdlgw92.sdl.hitachi.co.jp> > Sender: news@hsdlgw92.sdl.hitachi.co.jp (News manager) > > Hello, > > We are planning to use "Wind C++". > It supports VxWorks Ver. 5.1 but we are using Ver. 5.0.2. > Does anybody has experience "Wind C++" with VxWorks Ver.5.0.x? > Our agency said that they didn't know whether it was possible or not. > > Any information will be helpful to us. > > Thanks. > > - -- > - -- > TAKIHIRO Masatoshi S03U Systems Development Laboratory, Hitachi, Ltd. > E-mail : takihiro@sdl.hitachi.co.jp > We are using WindC++ with V5.1. If I remember correctly, the product literature says that V5.1 is required. Dean +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Dean Wampler, Ph.D. email: dwampl@atl.com | | Advanced Technology Laboratories | | MS: 264 office: (206) 487-7871 | | 22100 Bothell Highway S.E. fax: (206) 486-5220 | | Bothell, WA 98041-3003 | |-----------------------------------------------------------------| | "I feel your pain...." =:O] | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From stan@lassen.rti.com Fri Oct 28 09:17:44 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Fri Oct 28 09:17:50 PDT 1994 Subject: Re: comp.os.vxworks newsdigest >> We are planning to use "Wind C++". >> It supports VxWorks Ver. 5.1 but we are using Ver. 5.0.2. >> Does anybody has experience "Wind C++" with VxWorks Ver.5.0.x? >> Our agency said that they didn't know whether it was possible or not. The VxWorks 5.0.x headers aren't set up for C++. You may be able to do it, but it will be painful. It's well worth the upgrade cost (both $$ and effort). -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From greg@eng.nmr.varian.com Fri Oct 28 10:04:04 1994 From: greg@eng.nmr.varian.com (Greg Brissey x6951) Date: Fri Oct 28 10:04:10 PDT 1994 Subject: Sockets don't close on VxWorks reboot Dear VxPerts, First, a quick thanks to all that responded to my interrupt & vector question. Thanks again... On to the the question at hand. Here's the scenario: Process on SUN workstation (4.1.3) has a socket open to a task on mv162LX running VxWorks 5.1.1. Now if the SUN process is writing to the socket when the VxWorks is rebooted the SUN process receives SIGPIPE or some indication that the socket is gone. This is good. However if the SUN process is reading from the socket when the VxWorks is reboot the SUN process receives NO indication that the socket is gone. This is BAD. Wind River claims they are not responsible for application resources. I guess this means I suppost to close it before rebooting, But how do I know some has pressed the BIG Red button ? Is there anyone that can help me out. Whats going on and more important how do I fix or get around this bug (Oops, I mean 'opportunity' :) Thanks in advance, Greg Brissey greg.brissey@nmr.varian.com Varian Assoc. From hill@luke.atdiv.lanl.gov Fri Oct 28 11:01:05 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Fri Oct 28 11:01:12 PDT 1994 Subject: Re: Sockets don't close on VxWorks reboot > However if the SUN process is reading from the socket when the VxWorks > is reboot the SUN process receives NO indication that the socket is gone. > This is BAD. First I am assuming that we are talking about TCP/IP sockets and that the client side needs to rapidly detect disconnect. Note also that this is a question specific to BSD sockets (which happen to be implemented in vxWorks). Once the server finishes rebooting you will receive disconnect notification from the socket. If you wish to rapidly detect situations where someone has turned off the server's host then you have two options: 1) Implement a heart beat protocol above TCP/IP. 2) Use the keep alive socket option. Note however that the delay prior to disconnect detect is set globally for all TCP/IP circuits initiated on the same host and is usually quite long by default (but kernel configurable). Hope this helps. Jeff ______________________________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From daemon@vxw.ee.lbl.gov Sat Oct 29 04:00:24 1994 From: daemon@vxw.ee.lbl.gov Date: Sat Oct 29 04:00:32 PDT 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Oct 29 04:00:13 PDT 1994 Subject: Re: How to pick the best VME interrupt Level & vector Subject: Re: NFS server on VxWorks Subject: Power PC Board for vxWorks. ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: How to pick the best VME interrupt Level & vector Date: Fri, 28 Oct 1994 13:17:59 GMT From: geger@hellcat.den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Message-ID: <1994Oct28.131759.19185@den.mmc.com> References: <9410252326.AA05295@eng.nmr.varian.com> <38orhp$did@ncar.ucar.edu> Sender: news@den.mmc.com (News Admin) In article <38orhp$did@ncar.ucar.edu>, vanandel@stout.atd.ucar.edu (Joe Van Andel) writes: |> In article <9410252326.AA05295@eng.nmr.varian.com>, greg@eng.nmr.varian.com (Greg Brissey x6951) writes: |> |> VxPerts, |> |> |> |> Maybe someone can help me out here. I have 3 - 4 VME boards I am |> |> controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is |> |> how to best pick the VME interrupt level and vectors for my boards. |> |> A different level for each board or a single level for all and let |> |> the order within the cardcage determine the relative priorities. |> |> Which level(s) do I pick? What vectors are safe to use. I |> |> obviously don't what to pick ones that VxWorks already uses. |> |> Or am I confused and are VME vectors different from the on board vectors. |> |> |> |> Wind River has a tech. note on how to determine which vectors are used. If you |> can find the interrupt vector table (frequently at the start of your on-board |> RAM), you can determine which vectors are unused, since all unused vectors point |> to the same entry point (excIntStub). If you disassemble the routine pointed to |> by a used interrupt vector, you'll see something like: |> |> 403b1ea0 4eb9 4004 4faa JSR _intEnt |> 403b1ea6 48e7 e0c0 MOVEM .L D0-D2/A0-A1,-(A7) |> 403b1eaa 2f3c 0000 0001 MOVE .L #00001,-(A7) |> 403b1eb0 4eb9 4000 276c JSR _tyCoIntWr |> 403b1eb6 588f ADDQ .L #0x4,A7 |> 403b1eb8 4cdf 0307 MOVEM .L (A7)+,D0-D2/A0-A1 |> 403b1ebc 4ef9 4004 4fbc JMP _intExit |> 403b1ec2 ffaf DC.W 0xffaf |> 403b1ec4 403b DC.W 0x403b |> 403b1ec6 1e98 MOVE .B (A0)+,(A7) |> |> Interrupt vectors 64-255 (offset 0x100-0x3fc) are available for use by interrupts |> generated by your boards, assuming your MVME162LX isn't using them for on-board |> devices. (You can look at your board support package to determine which on-board |> devices use which interrupt vectors). |> |> |> -- |> Joe VanAndel Internet: vanandel@ncar.ucar.edu |> National Center for Web http://www.atd.ucar.edu/jva/home.html |> Atmospheric Research I saw this and the original posting and had already created a utility, map68KIVT, to do just that. I've mailed it to thor@ncar.ucar.edu, so it should be in the vxWorks archives by now. It looks at the 256 interrupt pointers and uses symFindByValueAndType() to try to lookup the name of the ISR's. If anybody wants the source, and it's not in the archives, mail me and I'll send you a copy. GWE ||========================================================================== ||George Eger / geger@den.mmc.com || Voice - (303) - 971 - 6974 || ||Integ. Fault Tolerant Avionics || Fax - (303) - 977 - 1145 || ||Space Launch Systems || MS T320 || ||Martin Marietta Astronautics || P.O. Box 179, Denver CO 80201 || ||========================================================================== ||We are at a cusp - between the past when humans were more reliable than || ||computers and the future when computers are more reliable than humans. || ||========================================================================== ||All opinions (however truthful or misinformed) are my own. || ||========================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: Re: NFS server on VxWorks Date: Fri, 28 Oct 1994 16:48:49 GMT From: dat85715@indirect.com (D'Anne Thompson) Organization: Internet Direct, indirect.com Message-ID: References: Sender: dat85715@bud.indirect.com In article mmuri@qualcomm.com (Mark Muri) writes: > People, > > Is there an NFS server for VxWorks? We're actively using the NFS client > stuff. Maybe I'm not reading the manual (5.1.1) right... > > Just hooked some SCSI disks up and wanted to access them from other cards > within the same cage (across the Shared Memory network). NFS is the way to > go. I can FTP to the card (from Solaris) and get/put to the disk. > > Thanks. > > Mark Muri > Mark, Wind River just sent out a beta tape of their NFS server code. We should see it in Release 5.1.2 which is due very soon now. I only had a chance to test it briefly but it worked fine. That doesn't help now does it? I think you should be able to setup up the scsi host with an ftp daemon and then access it via the netdriver from the other cpus. (I haven't done it personally - I'll try it today and let you know). You shouldn't have to use ftp client get/put directly, the netdriver should perform all that for you. D'Anne Thompson dat85715@indirect.com dee@ioinc.tucson.az.us --------------------------- Newsgroups: comp.os.vxworks Subject: Power PC Board for vxWorks. Date: 29 Oct 1994 05:01:19 GMT From: hbh@cho.gsis.co.kr (Huh Byoung Hoe) Organization: HANAnet Operating Centre(KTRC) Message-ID: <38skv0$2dl@usenet.hana.nm.kr> Sender: hbh@LGTwins (Huh Byoung Hoe) Does anyone know about the Power PC board made by motorola and supporting vxWorks BSP ? How to get the information of Power PC board for vxWorks ? Can anybody tell me any one of the upper question ? Thanks a lot. - ------------------------------------------------------ Huh Byoung Hoe Test Equipments Lab, Electro-Mechanic Division, Research & Development Laboratory, GoldStar Industrial Systems CO., LTD. Lucky-Goldstar R&D Complex. 533, HoGae-Dong, DongAnKu, AnYang-Shi, KyoungKi-Do 430-080, KOREA Tel: 82-343-50-7537 Fax: 82-343-50-7599 E-mail: hbh@cho.gsis.co.kr - ------------------------------------------------------- --------------------------- End of New-News digest ********************** From BRIDGERUNNER@delphi.com Sat Oct 29 21:58:12 1994 From: BRIDGERUNNER@delphi.com Date: Sat Oct 29 21:58:19 PDT 1994 Subject: unsubscribe Will be incommunicado for some time so I must unsubscribe! From daemon@vxw.ee.lbl.gov Sun Oct 30 04:00:21 1994 From: daemon@vxw.ee.lbl.gov Date: Sun Oct 30 04:00:28 PST 1994 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Oct 30 04:00:12 PST 1994 Subject: V Fast VxWorks processor ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: V Fast VxWorks processor Date: Thu, 27 Oct 1994 08:59:16 +0000 From: Paul@pgt1.demon.co.uk (Paul Tindall) Organization: Myorganisation Message-ID: <783248356snz@pgt1.demon.co.uk> Reply-To: Paul@pgt1.demon.co.uk Sender: usenet@demon.co.uk Very Fast VxWorks Processor Card I amd building a system that needs a processor card running about 10 times the speed of a 68040. The problem could be split into 3 separate processors, but with extra overhead. The board run VxWorks and preferably VadsWorks, coz we've got to use Ada - although at a real push we could get away with C. The nature of the task is DSP like and requires several lookups in some large table. Any ideas would be gratefully received, cheers Paul - -- Paul Tindall - Principal Software Consultant MASS Consultants 01480 472622 (UK) --------------------------- End of New-News digest ********************** From has@snmy.info.kobelco.co.jp Sun Oct 30 20:26:08 1994 From: Sigeo Hasegawa Date: Sun Oct 30 20:26:16 PST 1994 Subject: PCI & Pentium Hi Anyone who try to use PCI-bus or Pentium-CPU, Please let me know your status of development. Is it possible for me to use PC-AT Pentium for VxWorks? Regards, --------------------------------------------------- Electronics & Information Division KOBE STEEL, LTD. Shigeo Hasegawa TEL: 81-78-261-6460 FAX: 81-78-261-6499 E-mail: has@info.kobelco.co.jp --------------------------------------------------- From pardoe@ncp.gpt.co.uk Mon Oct 31 06:08:41 1994 From: "Matthew Pardoe" Date: Mon Oct 31 06:08:48 PST 1994 Subject: Tag Overflow I am posting this for a colleague. > > Does any one know what the following error message means: > > "Tag Overflow in target program" > > I get in when running my program using VxSim and debugging it > with VxGDB 2.0. I believe it may have something to do with a > structure tag being overwritten as it occurs when I set one of > the members of a structure. > I can find no referrence to this error in any of the mannuals. > > We are using vxWorks 5.1.1 running on a sparc classic (4.1.3c sunos) > > Thanks in anticipation. > Matthew Pardoe =============================================================================== Matthew Pardoe _/_/ _/_/ _/ _/_/_/_/ email : pardoe@ncp.gpt.co.uk GPT Ltd. _/ _/ _/ _/ _/ _/ tel : +44 202 782653 Sopers Lane _/ _/ _/ _/ _/ _/_/_/_/ fax : +44 202 782163 Poole BH17 8BH _/ _/ _/_/_/_/ _/ England =============================================================================== From brian@wrs.com Mon Oct 31 07:51:44 1994 From: Brian Lazara Date: Mon Oct 31 07:51:51 PST 1994 Subject: Re: comp.os.vxworks newsdigest > > Subject: V Fast VxWorks processor > > ------------------------------------------------------- > > > Very Fast VxWorks Processor Card > > I amd building a system that needs a processor card running > about 10 times the speed of a 68040. The problem could be split > into 3 separate processors, but with extra overhead. The board > run VxWorks and preferably VadsWorks, coz we've got to use Ada > - although at a real push we could get away with C. The nature > of the task is DSP like and requires several lookups in some > large table. Any ideas would be gratefully received, > > cheers > > Paul > - -- > Paul Tindall - Principal Software Consultant MASS Consultants > 01480 472622 (UK) Paul, Without knowing your I/O requirements, I think that you should consider a 2 board solution. I once built a simulator with similar requirements. The boards were a 68k board running vxWorks controlling a card with 4 ATT DSPs on it. All the controller code was in Ada. This did the filling of the pipeline, some pre-processing based on commands coming in over ethernet, DSP download and control/timing. The DSPs were all cranking away using a lookup type alogorithm that used a swing buffer to change to new data downloaded by the vxWorks target. If you have a DSP like application, it might be better to design your architecture with DSPs. Brian Lazara Wind River Systems ES group From blair@wyeth.ds.boeing.com Mon Oct 31 09:09:09 1994 From: blair@wyeth.ds.boeing.com (Rick Blair) Date: Mon Oct 31 09:09:15 PST 1994 Subject: Re: comp.os.vxworks newsdigest > > Subject: V Fast VxWorks processor > > ------------------------------------------------------- > > > Very Fast VxWorks Processor Card > > I amd building a system that needs a processor card running > about 10 times the speed of a 68040. The problem could be split > into 3 separate processors, but with extra overhead. The board > run VxWorks and preferably VadsWorks, coz we've got to use Ada > - although at a real push we could get away with C. The nature > of the task is DSP like and requires several lookups in some > large table. Any ideas would be gratefully received, > > cheers > > Paul > - -- > Paul Tindall - Principal Software Consultant MASS Consultants > 01480 472622 (UK) Paul, You might want to look into several of the MIPS based cards from Heurikon. They now have an r4400 based card (I think, unfortunatly my product info is not with me). That would be a real barn burner. Cheers, Rick *************************************************** * email: blair@elvis.ds.boeing.com * * voice: (206)657-6582 * * usSnail: P.O. Box 3707 M/S 9F-61 * * Seattle, Wa 98124 * * * *Disclaimer: The contents of this message in no * * way reflects the Opinions either real* * or imaginary of the Boeing Company. * * All Opinions/rantings are my own and * * only I am responsible for them. * *************************************************** From mgr@rtp.co.uk Mon Oct 31 09:38:42 1994 From: mgr@rtp.co.uk (Mark Richardson) Date: Mon Oct 31 09:38:49 PST 1994 Subject: Profibus & VxWorks Hi! Does anyone out there have any experience of implementing the PROFIBUS protocol on VxWorks? Do any drivers exist for it? Any experiences/comments welcome... Thanks in advance ********************************************************* * * * Mark Richardson * * Real Time Products * * Unit 8, Holt Court, * * Aston Science Park * * Birmingham, B7 4EJ. Tel: 021 333 6955 * * ENGLAND. Fax: 021 333 5433 * * * * Where in the world.... * * Green, Zero and Point Five in a day? * * * ********************************************************* From hill@luke.atdiv.lanl.gov Mon Oct 31 09:43:52 1994 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Mon Oct 31 09:43:58 PST 1994 Subject: Re: comp.os.vxworks newsdigest > > I saw this and the original posting and had already created a utility, > map68KIVT, to do just that. I've mailed it to thor@ncar.ucar.edu, so it > should be in the vxWorks archives by now. It looks at the 256 interrupt > pointers and uses symFindByValueAndType() to try to lookup the name of the > ISR's. If anybody wants the source, and it's not in the archives, mail me > and I'll send you a copy. > There is already a utility (veclist) in the archives that performs this function. Jeff ______________________________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos, NM USA 87545 FAX 505 665 5107 From aisie.aisinc.com!aisinc.com!tam@msen.com Mon Oct 31 10:15:23 1994 From: tam@aisinc.com (Tod More) Date: Mon Oct 31 10:15:31 PST 1994 Subject: Re: Sockets don't close on VxWorks reboot > > Submitted-by greg@eng.nmr.varian.com Fri Oct 28 10:04:04 1994 > Submitted-by: greg@eng.nmr.varian.com (Greg Brissey x6951) > > Dear VxPerts, > > First, a quick thanks to all that responded to my interrupt & vector > question. Thanks again... > > On to the the question at hand. > Here's the scenario: > Process on SUN workstation (4.1.3) has a socket open to a task on mv162LX > running VxWorks 5.1.1. > Now if the SUN process is writing to the socket when the VxWorks is rebooted > the SUN process receives SIGPIPE or some indication that the socket is gone. > This is good. > However if the SUN process is reading from the socket when the VxWorks > is reboot the SUN process receives NO indication that the socket is gone. > This is BAD. > Wind River claims they are not responsible for application resources. > I guess this means I suppost to close it before rebooting, But how do I know > some has pressed the BIG Red button ? > > Is there anyone that can help me out. Whats going on and more important > how do I fix or get around this bug (Oops, I mean 'opportunity' :) I had this same problem between a Sun, and a PC, if you hit the big red switch on the PC, the socket was left open on the (sun, RS6K, HP, Mips....). We had to add a heartbeat to our unix programs to send a beat to the "PC", and wait to see if we timmed out (this timeout can take up to 10 minutes as specified by TCP/IP). I know this is an ugly solution, but it did work. Our problem was that we only allowed so many connections to our unix servers, and when a PC went away we wern't freeing the connection, the heart beat fixed the problem for us. Good luck tod. From COBARRUVIAS@asd2.jsc.nasa.gov Mon Oct 31 11:46:03 1994 From: JOHN R COBARRUVIAS '78 Date: Mon Oct 31 11:46:10 PST 1994 Subject: Subscription request Please subscribe me to VxWorks Exploder. From jtosey@glenayre.com Mon Oct 31 12:24:16 1994 From: jtosey@glenayre.com (Joseph Tosey [4572]) Date: Mon Oct 31 12:24:22 PST 1994 Subject: Re: Sockets don't close on VxWorks reboot > I had this same problem between a Sun, and a PC, if you hit the big red > switch on the PC, the socket was left open on the (sun, RS6K, HP, Mips....). > We had to add a heartbeat to our unix programs to send a beat to the > "PC", and wait to see if we timmed out (this timeout can take up to 10 minutes > as specified by TCP/IP). I know this is an ugly solution, but it did work. > Our problem was that we only allowed so many connections to our unix servers, > and when a PC went away we wern't freeing the connection, the heart beat fixed > the problem for us. There are a lot of solutions to this problem, although none are trivial. I know of only three mechanisms which can be used to address it; polling (1 below), events (4, 5 below) or a connectionless transformation (2, 3 below). 1. Put a trivial UDP server on the PC which returns a fixed packet containing the reboot time. This way it can be polled for a reset without messing up all your application protocols. Also, if several connections are formed with the same PC, this provides an economy-of-scale reduction in overhead. 2. Use UDP instead of TCP, and make your protocol connectionless. While this may sound impossible, Sun managed to do this with NFS. 3. Keep using TCP, but make your protocol transaction oriented, so that a connection is only formed for a short duration on which real-time constraints can be imposed. When the constraints are violated, your connection is gone. Some applications are particularly suited for this, such as database operations (SQL) and message transfer. If you are confident that the PC is just being reset and not turned off, you have a few more alternatives: 4. If the PC is on a LAN, it can send a broadcast packet telling everyone that it just reset. 5. If the PC frequently talks to a few servers (perhaps two or three), it can notify them after reboot that it has just reset. Good luck! ------------------------------------------------------------------------------- Joseph Tosey Fax: +1 604 293 4317 Manager, OS & Networking Reception: +1 604 293 1611 Glenayre Electronics Voice Mail: +1 604 293 4399 x572 1570 Kootenay St, Vancouver, BC V5K 2B8 Timezone: PST/PDT (same as US/CA) Canada From stan@lassen.rti.com Mon Oct 31 21:08:25 1994 From: stan@lassen.rti.com (Stan Schneider) Date: Mon Oct 31 21:08:31 PST 1994 Subject: Re: V Fast VxWorks processor >> > >> > I amd building a system that needs a processor card running >> > about 10 times the speed of a 68040... >> >> If you have a DSP like application, it might be better to design your >> architecture with DSPs. >> This sounds like an interesting one to jump into. A reasonable (albeit religious) argument can be made that DSPs are losing most of their Harvard-architecture and fast floating-point advantages. This is because cache & concurrent instruction execution technology have revolutionized memory system design, and higher densities are allowing fancy on-chip FPUs. For instance the new PowerPC and Alpha chips have single-clock multiply-accumulate floating point units, and closely approach (exceed?) DSP performance. In the meantime, the DSP's lousy programmability really cripples any general-purpose tasks you need to do. DSPs are great for an engine controller, but they don't address the complexities of the real world (i.e. VxWorks). There are several processors that can give you the 10x 68040 performance: R4000, Alpha, PowerPC. There are many more on the way RSN. I'd look at them before a DSP. Just thought I'd try to pick a fight... -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From thor@thor.atd.ucar.edu Mon Oct 31 23:00:10 1994 From: thor@thor.atd.ucar.edu (Rich Neitzel) Date: Mon Oct 31 23:00:16 PST 1994 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 ------------------------------------------------ VxWorks sources: