From vlp@mr.picker.com Tue Jun 1 06:03:32 1993 From: vlp@mr.picker.com (Vic Potter) Date: Tue Jun 1 06:04:53 PDT 1993 Subject: MVME 147 memory check utilities > >We are using a MVME147 cpu as part of a medical control system and are required to perform extensive >memory and board level functional operation checks on startup. This is similar to what the Motorola >boot-roms do on startup. They check memory, CPU registers, addressing modes, exception processing >nvram, and board 12v fuse states. Its a bit of a long shot, but if anyone has already gone through >this hoop with VxWorks, we would greatly appreciate any source or ideas which may give us a head start. > It is possible, with minor changes configuration changes, to allow the vxWorks boot roms be co-resident on the MVME 147 board with the standard motorola m-bug roms. I think that the m-bug will provide the functions you are looking for. I have done this for the MVME 167 board and in the near future will be doing it for the MVME 147 board also. The process involves changing the constants that define the starting location of the code and the entry point address. The boot code that executes out of rom is mostly position independent. It will also be necessary to change the flags that are passed to the ld command when building the boot roms. It is also possible to configure m-bug to automatically boot vxWorks on powerup or reset with the rb command. I have gotten most of my support for this effort from my local Motorola office. If you have any questions I will try to assist. Vic Potter Picker International Inc. vlp@mr.picker.com From garyb@abekrd.co.uk Tue Jun 1 09:42:35 1993 From: Gary Bartlett Date: Tue Jun 1 09:42:44 PDT 1993 Subject: RARP and VxWorks Has anyone implemented RARP (client side) for VxWorks targets so that on bootup out of ROMs, the target Internet Address can be setup without having to rely on battery-backed RAM or other external devices? If not, how easy would it be to add RARP support using VxWorks. I didn't see much in the way of low-level library calls that could be used to broadcast RARP packets rather than IP. Can anyone help or offer suggestions? Thanks, Gary From daemon@vxw.ee.lbl.gov Wed Jun 2 04:00:47 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jun 2 04:00:56 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jun 2 04:00:38 PDT 1993 Subject: Re: VME Number Crunchers Subject: PVM Subject: socket cleanup Subject: Real-Time Programming position, NM ------------------------------------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: VME Number Crunchers Date: Tue, 1 Jun 1993 12:19:13 GMT From: davep@hpwine60.uksr.hp.com (Dave Porter) Organization: the HP UK Response Centre Message-ID: References: Followup-To: comp.realtime,comp.os.vxworks Sender: news@hpwin052.uksr.hp.com (News Administrator) >I need some information on VME number crunching boards. I have >... >If anyone knows of any other boards and points-of-contact, I >would greatly appreciate the information. HP produces a VME board (the current model is actually two boards) which may be of interest to you. It is the HP9000 model 742rt, which is based on HP's 50MHz implementation of the PA-RISC 7100 chip (as used in the other HP9000 series 700 systems). The note I have gives the performance as 57MIPS / 15 MFLOPS. Please contact your local sales office if you need more information, or get back to me via email and I'll see what I can do to help. Best Regards, DaveP Dave Porter email: davep@hpwin051.uksr.hp.com Hewlett-Packard UK Response Centre HPDESK: Dave PORTER /HP8005/RC Bracknell, Berkshire Phone: (44) 0344-362146 Fax: (44) 0344-361737 --------------------------- Newsgroups: comp.os.vxworks Subject: PVM Date: 1 Jun 93 13:05:08 GMT From: cherp@cscnx15 (Chernett P) Message-ID: <10165@sersun1.essex.ac.uk> Reply-To: cherp@uk.ac.esssex Sender: news@sersun1.essex.ac.uk Has anyone ported PVM to VxWorks? - -- ************************************* * Paul Chernett University of Essex * * Department of Computer Science * * cherp@essex.ac.uk 0206 872048 * * NeXT Mail welcome * ************************************* --------------------------- Newsgroups: comp.os.vxworks Subject: socket cleanup Date: 1 Jun 1993 15:57:16 GMT From: kent@fndaug.fnal.gov (Simon Kent) Organization: Fermi National Accelerator Laboratory, Batavia IL Message-ID: <1ufu8s$1pv@fnnews.fnal.gov> Hi, The VxWorks description of reboot implies that netLib adds a hook to cause all network interfaces to be reset. The result is that netLib will kill the network so no user-added hook routines will be able to use the network. Does VxWorks clean up sockets on reboot? We have a problem that sockets remain open after reboot. Is anyone familiar with this problem, and a solution? Thanks, kent --------------------------- Newsgroups: comp.os.vxworks Subject: Real-Time Programming position, NM Date: Tue, 1 Jun 93 20:05:40 GMT From: rmilner@chaos.aoc.nrao.edu (Ruth Milner) Organization: National Radio Astronomy Observatory, Socorro NM Message-ID: <1993Jun1.200540.571@chaos.aoc.nrao.edu> [I realize that technical groups are not generally the appropriate place for job postings. However, this is a highly specialized field, and response from misc.jobs.offered has been poor, so I am reposting directly here. Feel free to move to the next message now if you don't wish to read the posting. :-) ] - ------------------------------------------- Please note that this is not an entry-level position. We are looking for someone with significant real-world experience programming for a real- time environment. The equipment mentioned below is an extremely complex custom-designed system, with an equally complex software environment. Development is done on Sun workstations, with the real-time code running under VxWorks on Motorola VME-based processors. Funding for the observatory comes from the National Science Foundation. If you have any questions about the position, please email me at rmilner@aoc.nrao.edu (though I may not be able to reply until next week). Resumes/applications should be sent to our personnel department at the address below. Thank you very much. - ----------------------- REAL-TIME SCIENTIFIC PROGRAMMER/ANALYST The National Radio Astronomy Observatory has an excellent opportunity available for a Real-Time Scientific Programmer. The NRAO operates several world-class radio telescopes, including the Very Large Array, comprising 27 antennas in central New Mexico, and the Very Long Baseline Array (VLBA), consisting of 10 radio dishes spread across the United States and now nearing completion. This position is located at the Array Operations Center in Socorro, NM. The programmer/analyst will join a team of programmers and scientists who are responsible for the completion and maintenance of the VLBA antenna and correlator real-time control systems, relatively mature but not yet fully implemented designs. Working under the guidance of a senior team member, the programmer/analyst will modify and enhance existing code, and write new programs, to control real-time, dedicated digital hardware. Enhancements to the correlator's capabilities will continue to be made in the future. The position requires a B.S. or equivalent experience in Computer Science, Electrical Engineering, or physical sciences. Several years' experience with real-time programming in the C language is essential, as is familiarity with the UNIX development environment. Experience with the VxWorks real-time operating system, and familiarity with 680x0-based VME computers, are highly desirable. Good interpersonal skills are a must. Socorro is a small, historic town of 8,000 people located at the western edge of the Rio Grande Valley, 75 miles south of Albuquerque. To take advantage of this opportunity, please respond by 6/15/93 to: Ina W. Cole, Personnel, National Radio Astronomy Observatory, P.O. Box O, Socorro NM 87801. EOE, M/F/H - -- Ruth Milner NRAO/VLA Socorro NM Computing Division Head rmilner@zia.aoc.nrao.edu --------------------------- End of New-News digest ********************** From steele@telerobotics.jpl.nasa.gov Wed Jun 2 08:04:32 1993 From: steele@telerobotics.jpl.nasa.gov (Rob Steele) Date: Wed Jun 2 08:04:40 PDT 1993 Subject: Single script File I am using multiple boards, but would like to only use one script file. I need some mechanism for building if statements and or jumps to labels within the script file to do what I want. Is this possible? and how would I go about doing it? Any replies are appreciated. Rob Steele steele@telerobotics.jpl.nasa.gov From calvin@netcom.com Wed Jun 2 09:09:49 1993 From: calvin@netcom.com (John Calvin) Date: Wed Jun 2 09:09:59 PDT 1993 Subject: Message Message queuing problems.. could come veterans of VxWorks message handling give me a few clues about passing message structures out of an ISR. Actually the message could originate from just about anywhere, the problem Im having is than when I try to pass a pointer to my message structure, the message never seems to get sent. Ive verified that by replacing my message structure pointer with "hello from ISR" everything is connecting ok. The queues are being set up properly and the QID's are being handled ok, and I get "hello from ISR" at the recieving end. When I return to my message structure pointer my receving end always times out. Ive attached a segment of my sender and reciever in hopes someone can tell me whats going wrong. I appologize however that it was somewhat butchered to make it presentable within 20 lines or so. If there apears to be some undeclared variables its probably because they got removed by mistake. Process waiting for message from ISR. typedef struct MC_MSGHLR /* Message handler structre */ { UINT16 channel_num; /* Channel or Axis from which interrupt */ UINT16 vector; /* Vector number */ UINT16 level; /* Interrupt Level */ UINT16 status_reg; /* Status Reg. Snapshot at interrupt time */ } MC_MSGHLR; MSG_Q_ID mqSectorIsrQue,mqLinearIsrQue; VOID sync() { MC_MSGHLR Mc_msg; int rstat; mqSectorIsrQue = msgQCreate (MAX_MSGS, MAX_MSG_LEN, MSG_Q_FIFO); mqLinearIsrQue = msgQCreate (MAX_MSGS, MAX_MSG_LEN, MSG_Q_FIFO); while (1) { /* Wait 1 second for message in synchronization queue */ if ((rstat = msgQReceive (mqLinearIsrQue,(char *) &Mc_msg, sizeof(Mc_msg), stime*1)) == ERROR) LogMsg ("Timeout recieving synchronization message\n"); logMsg ("\nInterrupt came in from channel num = %d\n", Mc_msg.channel_num); } } ------------------------------------------------------------------------------ ISR with message loader (sender) LOCAL MC_MSGHLR isr_msg = { 0,0,0,0}; LOCAL VOID mcISR (board) FAST int board; /* board number */ { FAST int channel; /* channel number */ FAST int code; /* additional code when sending a signal */ code = *CIO_PA(mcDV [board*2].b_addr); /* Load message structure */ isr_msg.channel_num = 0x0e; isr_msg.vector = MC_INTNUM; isr_msg.level = MC_INTLEVEL; isr_msg.status_reg = code; /* Launch message */ msgQSend ( vimcDv [channel].msgQid, (char *) &isr_msg, sizeof(isr_msg), NO_WAIT); } Any hints would be gladly apreciated. Note: This is actualy some third party code which I am trying to modify to support VxWorks 5.1's lack of signal codes. Previously the ISR triggered a signal with an associated code number which the signal reciever used to determine the source of the interrupt. Wind River has removed this feature from their latest release, requiring some workarounds in our ISR's. the sigRaise command no longer exists in 5.1! Thanks in advance John Calvin (Calvin@netcom.com) From calvin@netcom.com Wed Jun 2 09:39:43 1993 From: calvin@netcom.com (John Calvin) Date: Wed Jun 2 09:39:52 PDT 1993 Subject: Message_handler Message queuing problems.. could come veterans of VxWorks message handling give me a few clues about passing message structures out of an ISR. Actually the message could originate from just about anywhere, the problem Im having is than when I try to pass a pointer to my message structure, the message never seems to get sent. Ive verified that by replacing my message structure pointer with "hello from ISR" everything is connecting ok. The queues are being set up properly and the QID's are being handled ok, and I get "hello from ISR" at the recieving end. When I return to my message structure pointer my receving end always times out. Ive attached a segment of my sender and reciever in hopes someone can tell me whats going wrong. I appologize however that it was somewhat butchered to make it presentable within 20 lines or so. If there apears to be some undeclared variables its probably because they got removed by mistake. Process waiting for message from ISR. typedef struct MC_MSGHLR /* Message handler structre */ { UINT16 channel_num; /* Channel or Axis from which interrupt */ UINT16 vector; /* Vector number */ UINT16 level; /* Interrupt Level */ UINT16 status_reg; /* Status Reg. Snapshot at interrupt time */ } MC_MSGHLR; MSG_Q_ID mqSectorIsrQue,mqLinearIsrQue; VOID sync() { MC_MSGHLR Mc_msg; int rstat; mqSectorIsrQue = msgQCreate (MAX_MSGS, MAX_MSG_LEN, MSG_Q_FIFO); mqLinearIsrQue = msgQCreate (MAX_MSGS, MAX_MSG_LEN, MSG_Q_FIFO); while (1) { /* Wait 1 second for message in synchronization queue */ if ((rstat = msgQReceive (mqLinearIsrQue,(char *) &Mc_msg, sizeof(Mc_msg), stime*1)) == ERROR) LogMsg ("Timeout recieving synchronization message\n"); logMsg ("\nInterrupt came in from channel num = %d\n", Mc_msg.channel_num); } } ------------------------------------------------------------------------------ ISR with message loader (sender) LOCAL MC_MSGHLR isr_msg = { 0,0,0,0}; LOCAL VOID mcISR (board) FAST int board; /* board number */ { FAST int channel; /* channel number */ FAST int code; /* additional code when sending a signal */ code = *CIO_PA(mcDV [board*2].b_addr); /* Load message structure */ isr_msg.channel_num = 0x0e; isr_msg.vector = MC_INTNUM; isr_msg.level = MC_INTLEVEL; isr_msg.status_reg = code; /* Launch message */ msgQSend ( vimcDv [channel].msgQid, (char *) &isr_msg, sizeof(isr_msg), NO_WAIT); } Any hints would be gladly apreciated. Note: This is actualy some third party code which I am trying to modify to support VxWorks 5.1's lack of signal codes. Previously the ISR triggered a signal with an associated code number which the signal reciever used to determine the source of the interrupt. Wind River has removed this feature from their latest release, requiring some workarounds in our ISR's. the sigRaise command no longer exists in 5.1! Thanks in advance John Calvin (Calvin@netcom.com) From fjr@ssd.ray.com Wed Jun 2 11:32:31 1993 From: Roeber Date: Wed Jun 2 11:32:39 PDT 1993 Subject: Re: Single script File Rob Steele wrote: > > > I am using multiple boards, but would like to only use one script > file. I need some mechanism for building if statements and or > jumps to labels within the script file to do what I want. Is > this possible? and how would I go about doing it? You may want to look at a public domain program called expect. It provides a full script language that can handle very complex actions. We have used it for a number of local script tasks. Expect is based on a language called TCL. Wind River has actually built TCL into the 5.1 release of VxGDB. It is how they do all their command scripts. Anyway, the "Proceedings of the Summer 1990 USENIX Conference" contains an article "expect: Curing Those Uncontrollable Fits of Interaction" that covers the tool. It tells where to get the code via anonymous ftp. Fred | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 177 | | Portsmouth, RI 02871-1087 (401) 842-4205 | | fjr@ssd.ray.com | From daemon@vxw.ee.lbl.gov Thu Jun 3 04:01:14 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jun 3 04:01:25 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jun 3 04:01:05 PDT 1993 Subject: Ammunition For Choosing VxWorks Subject: NFS & VxWorks Subject: Re: MVME 147 memory check utilities Subject: Another NFS Question with VXWORKS Subject: Rebuilding gcc for 5.1 Subject: VxWorks Consultants ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Ammunition For Choosing VxWorks Date: 2 Jun 93 12:14:32 GMT From: sp_sjp@space.alcbel.be (Simon Pryor) Organization: Alcatel Bell Telephone Message-ID: <2037@alcbel.be> Reply-To: sp_sjp@space.alcbel.be Sender: root@alcbel.be We are evaluating solutions to a forthcoming embedded project, that we have planned, and would appreciate any comments. The project is to be in C++, on a (probable) VME target with Sun SPARC hosts. We have used ObjectCenter on a previous project (Sun host & target), so the VxWorks & WindC++ Gateway would be one obvious (and interesting) solution. We are also looking at a full OOA, OOD and Cadre's latest TeamWork, appears to also link directly into ObjectCenter, closing the loop from Analysis to real-time embedded code. We will need a very high data throughput, maybe FDDI or Ethernet, which makes VxWorks networking also attractive. We could also envisage using things like SNMP in the future and I note there have been ports to VxWorks; What about other RT OSs? An alternative might be VRTX using the Velocity cross-development environment (or indeed others). Does anyone have any convincing arguments as to why VxWorks is best (or otherwise). Either technical and/or commercial (financial) arguments would be of interest. I realise the I'll get scores of hate-mail, but I get the impression that VxWorks is winning the "real-time os" wars, with people moving from things like VRTX, pSOS+, LynxOS, etc, to VxWorks. Is this true? Simon Pryor, sp_sjp@space.alcbel.be --------------------------- Newsgroups: comp.os.vxworks Subject: NFS & VxWorks Date: Wed, 2 Jun 1993 16:30:18 GMT From: ramsey@itd.nrl.navy.mil Organization: US Naval Research Lab, Washington, DC Message-ID: Sender: usenet@ra.nrl.navy.mil My users are interested in using the nfsLib to access their home directories from their VxWorks cpus. This creates some interesting security questions: I trust my users not to intentionally use nfsAuthUnixSet() to access other users' files, but how robust is the nfsLib when invoked by buggy code? If I do export a file system I want to have control over who can rlogin to the VxWorks chassis. (The default is to allow anyone to rlogin from anywhere without a password. Combine this with nfsAuthUnixSet() and life could get real interesting.) The "INCLUDE_SECURITY" provides encrypted passwords to restrict access. How much trust do you place in the "INCLUDE_SECURITY" features? My inclination is to create a small UNIX partition that is exported read/write to the VxWorks machines. I would export the home directories read-only. I would use the "INCLUDE_SECURITY" stuff to keep out the riffraff. Do you feel this is sufficiently secure? How have your approached this problem? Thanks, Jim --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MVME 147 memory check utilities Date: 2 Jun 93 13:27:43 GMT From: billc@motatl.UUCP (Bill Cutts) Organization: Motorola MCG, Atlanta, GA Message-ID: <227@motatl.UUCP> References: <9306011254.AA19725@vette> Unfortunately I missed the original article that Vic Potter quotes below so I'm not sure who asked this question: vlp@mr.picker.com (Vic Potter) writes: : > : >We are using a MVME147 cpu as part of a medical control system and are required to perform extensive : >memory and board level functional operation checks on startup. This is similar to what the Motorola : >boot-roms do on startup. They check memory, CPU registers, addressing modes, exception processing : >nvram, and board 12v fuse states. Its a bit of a long shot, but if anyone has already gone through : >this hoop with VxWorks, we would greatly appreciate any source or ideas which may give us a head start. : > : : It is possible, with minor changes configuration changes, to : allow the vxWorks boot roms be co-resident on the MVME 147 board : with the standard motorola m-bug roms. I think that the m-bug : will provide the functions you are looking for. : < rest of the article deleted > There was a white paper written by a Motorola Engineer which addressed this issue with the MVME147. From the description of his work: The implementation is unique in that it has two different modes of operation: first, the application program can directly call into the firmware resident diagnostic programs on the 147 board, assuming that the 147bug ROMs are present on the board; second, a subset of the same 147bug diagnostic programs were extracted from the 147bug source base ... are supplied in a library for linking with the application and execution out of RAM memory. I can supply a copy of this white paper if only a couple people request them. The real source for this should be your local support person. If they're unfamiliar with the white paper have them contact me and I'll tell them about it :-). - -- Bill Cutts | INET : billc@atl.mcd.mot.com | Systems Engineer | UUCP : emory!motatl!billc | Motorola Computer Group | #include | --------------------------- Newsgroups: comp.os.vxworks Subject: Another NFS Question with VXWORKS Date: Wed, 2 Jun 1993 17:02:20 GMT From: shebert@dw3f.ess.harris.com (Steven Hebert) Organization: Harris GISD Keywords: NFS,MOUNT,VXWORKS Message-ID: Reply-To: shebert@dw3f.ess.harris.com (Steven Hebert) Sender: usenet@jabba.ess.harris.com (Usenet News Feed Account) We are using a VMEbus system with 3 MV167 Boards and a hard disk drive. We know we are able to mount the host Sun file system, can the converse be done. Meaning mount the VXWORKSfile system from the host Sun? Thank you in advance Steve shebert@suw3ad.ess.harris.com --------------------------- Newsgroups: comp.os.vxworks Subject: Rebuilding gcc for 5.1 Date: Wed, 2 Jun 1993 20:11:55 GMT From: binkley@xavier.dfrf.nasa.gov (Rob -Not from Bloom County- Binkley, EIT) Organization: NASA Dryden Flight Research Facility, Edwards CA Keywords: gcc rebuild Message-ID: <1993Jun2.201155.3996@news.dfrf.nasa.gov> Sender: news@news.dfrf.nasa.gov (Usenet news) We recently installed vxWorks 5.1 on our main Sun file server. What I would LIKE to do is rebuild gcc to change the environment variable it uses from: GCC_EXEC_PREFIX to: CC68K_EXEC_PREFIX The reason I want to do this is that on the same system is gcc 2.4.2 built as a native compiler for the Sun. There is a environemnt variable conflict. Can't have it both ways. There are MANY more users of the native mode compiler than of the vxWorks cross-compiler, so that would be MUCH easier to maintain. And the native gcc compiler is kept up-to-date as often as new versions come out. Gcc is used to maintain a consistant compiler across several platforms here. So...how is the gcc cross-compiler for vxWorks (68k-family) built? There is a 'configure.in' and a 'Makefile.in' file, but how to specify host/target information? Any info would be greatly appreciated... - -- - ----------------------------------------------------------------------------- | Robert L. Binkley, EIT | INTERNET: binkley@xavier.dfrf.nasa.gov | | NASA Dryden FRF | ADDRESS: 130.134.144.2 | | PO Box 273 MS: B4840A | -or- | | Edwards, CA 93523-5000 | binkley@xfe.dfrf.nasa.gov | | fone: 805-258-3776 | 130.134.128.86 | | fax: 805-258-2792 | | |---------------------------------------------------------------------------| | barf [ba:rf] 2. "He suggested using FORTRAN, and everybody barfed." | | | | - From The Shogakukan DICTIONARY OF NEW ENGLISH (Second edition) | - ----------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks,misc.jobs.contract Subject: VxWorks Consultants Date: 2 Jun 1993 18:05:45 -0400 From: pmoyer@access.digex.net (Paul Moyer) Organization: CDA, Inc., McLean, VA USA Keywords: VxWorks Message-ID: <1uj87p$gh0@access.digex.net> Location: McLean, VA and Client site located in South Central, VA Duration: 9+ months Rate: @ $50/hr VxWorks Consulting ================== CDA, Inc. is participating in the development and structured testing of a high-speed router running under the VxWorks operating system (on a i960 platform). As part of this project we are required to verify all aspects of VxWorks. This effort includes test plan development, test execution and report analysis. Candidates must possess extensive knowledge of VxWorks internals (kernel) with good verbal and writing skills. Candidates must be available to work 40+ hours/week. Work will be performed at CDA (in McLean, VA) and also at our client site located in South Central, Virginia. Project is expected to begin mid June. If interested please call Ron Miller at (703) 821-1858 or Fax resume to (703) 821-9859. Regards, Paul Moyer, CDA email: pmoyer@access.digex.com --------------------------- End of New-News digest ********************** From danc@lds.loral.com Thu Jun 3 05:16:38 1993 From: danc@mail.lds.loral.com (Dan Cunningham 5102) Date: Thu Jun 3 05:16:48 PDT 1993 Subject: AMTEL AT29c010 Question: We are building our own CPU board with the SPARClite processor. We have already contracted with Wind River Systems to port VxWorks to this new CPU board. We want to use the AMTEL AT29c010 flash memory chip (128kx8, 32 pin PLCC) as memory for the board. Can Wind River Systems program these?? NOTE: We use the 3900 Data I/O programmer which does program this part. Dan Cunningham Loral Data Systems (813) 371-0811 ext. 5102 e-mail: danc@lds.loral.com From rmk@ssd.ray.com Thu Jun 3 06:50:10 1993 From: Kulakowski Date: Thu Jun 3 06:50:22 PDT 1993 Subject: Re: Single script File Sometimes we have a problem with Fred. He doesn't seem to read. > Submitted-by fjr@ssd.ray.com Wed Jun 2 11:32:31 1993 > Submitted-by: Roeber > > Rob Steele wrote: > > > > > > I am using multiple boards, but would like to only use one script > > file. I need some mechanism for building if statements and or > > jumps to labels within the script file to do what I want. Is > > this possible? and how would I go about doing it? > > > | Fred J Roeber, Raytheon Submarine Signal Division | > I'm writing because Fred is too embarassed to write himself. Once again someone must cover for him as his fingers became engaged before his brain ;-). We solved the above problem in one of two ways. 1) We use a separate file for each processor and make the names unique in the bootline. Because shell scripts can be nested, each can bring in a common set of files to accomplish what needs to be done in all of them. 2) We have also written startup programs that are loaded by startup.cmd and use the result of a gethostname to determine what processor they are in and perform initialization accordingly. The only problem is that the program must be compiled. With vxWorks, all commands are C functions so coding the routines is straight forward. Just duplicate what you would normally have in the command file. These work well in the case where multiple processors must be synchronized. because "while"s and "if"s can be used freely. Hope this helps and once again, sorry for Fred, sometimes he gets away from us. ---------------------------------------------------------------------- * Rich Kulakowski * Raytheon Submarine Signal Division * * * 1847 West Main Road, Mail Stop 177 * * rmk@ssd.ray.com * Portsmouth, RI 02871-1087 * * * (401) 842-4210 * ---------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Fri Jun 4 04:01:19 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jun 4 04:01:28 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jun 4 04:01:05 PDT 1993 Subject: Re: Message_handler Subject: Re: MVME 147 memory check utilities Subject: NEWBIE Needs FAQ and info on vxworks - U 2 can help :-) ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Message_handler Date: 3 Jun 1993 12:32:37 GMT From: pho@mserv1.dl.ac.uk (P.Owens,C20,3492) Organization: Daresbury Laboratory, UK Message-ID: <1ukr15$fqc@mserv1.dl.ac.uk> References: <9306021640.AA10922@netcom.netcom.com> Reply-To: pho@mserv1.dl.ac.uk calvin@netcom.com (John Calvin) asks: >could come veterans of VxWorks message handling give me a few clues about >passing message structures out of an ISR. Actually the message could >originate from just about anywhere, the problem Im having is than when I >try to pass a pointer to my message structure, the message never seems to >get sent. Ive verified that by replacing my message structure pointer >with "hello from ISR" everything is connecting ok. The queues are being >set up properly and the QID's are being handled ok, and I get "hello from ISR" >at the recieving end. When I return to my message structure pointer my >receving end always times out Try checking if msgQSend returns ERROR and see what the errno is. - --- Pete Owens P.Owens@daresbury.ac.uk --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MVME 147 memory check utilities Date: 3 Jun 93 12:22:34 EST From: els@hrb.com (Eric L. Schott) Organization: HRB Systems, Inc. Message-ID: <1993Jun3.122235.20299@icf.hrb.com> References: <9306011254.AA19725@vette> In article <9306011254.AA19725@vette>, vlp@mr.picker.com (Vic Potter) writes: > > > > > >We are using a MVME147 cpu as part of a medical control system and are required to perform extensive > >memory and board level functional operation checks on startup. This is similar to what the Motorola > >boot-roms do on startup. They check memory, CPU registers, addressing modes, exception processing > >nvram, and board 12v fuse states. Its a bit of a long shot, but if anyone has already gone through > >this hoop with VxWorks, we would greatly appreciate any source or ideas which may give us a head start. > > > > It is possible, with minor changes configuration changes, to > allow the vxWorks boot roms be co-resident on the MVME 147 board > with the standard motorola m-bug roms. I think that the m-bug > will provide the functions you are looking for. > > I have done this for the MVME 167 board and in the near future > will be doing it for the MVME 147 board also. > > It is also possible to configure m-bug to automatically boot > vxWorks on powerup or reset with the rb command. I too have done this (167 only). It works. I found it took additional time for the board to boot because the Bug PROMs wanted to check the additional PROMs. (I believe this can be shortened.) We discarded this approach because: 1. The extra boot time. 2. The need to program additional NVRAM parameters 3. The inability to run 167 diagnostics without a CRT, etc. attached to the serial port. Our alternate approach was to obtain the Motorola "loadable" diags and compile them in with the VxWorks PROMS. This tooks some effort, but that combined with an "RARP-like" deamon allows us to 1. Boot without ANY NVRAM programming (except a rare clobbered ethernet address). This allows cards to be swapped and ONLY the VMEbus system controller needs changed as required. This greatly speeds and simplifies field maintaince. 2. Ability to run diags on command. When the PROMs request load parameters (e.g. IP addresses), the deamon supplies information on which (if any) diagnostic tests to run. - -- Eric L. Schott, HRB Systems, Inc. 814/238-4311 els@hrb.com "As we acquire more knowledge, things do not become more comprehensible but more mysterious." Albert Schweitzer, "Paris Notes" --------------------------- Newsgroups: comp.os.vxworks Subject: NEWBIE Needs FAQ and info on vxworks - U 2 can help :-) Date: 3 Jun 1993 15:10:08 -0500 From: lwb@cs.utexas.edu (Lance W. Bledsoe) Organization: CS Dept, University of Texas at Austin Message-ID: <1ullr0$9k8@im4u.cs.utexas.edu> Hello, We are starting off on a new project that requires vme bus and real time os. I understand that vxworks is the way to go. Can sombody send me a FAQ for this group, and info and contacts for the suppliers of vxworks. Sorry to be so stupid, mabey I can help you with C++ sometime. :-) Thanks, Lance - -- +------------------------------------------------------------------------+ | Lance W. Bledsoe lwb@im4u.cs.utexas.edu (512) 258-0112 | | "Ye shall know the TRUTH, and the TRUTH shall make you free." | +------------------------------------------------------------------------+ --------------------------- End of New-News digest ********************** From stan@rti.com Fri Jun 4 13:15:29 1993 From: stan@rti.com (Stan Schneider) Date: Fri Jun 4 13:15:40 PDT 1993 Subject: StethoScope 4.1 =============================================================================== P R O D U C T N E W S =============================================================================== StethoScope 4.1, ScopeProfile, and RTILib Released -------------------------------------------------- StethoScope 4.1 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 Graphical data collection and monitoring StethoScope is a real-time graphical monitoring, performance analysis, and data collection tool for VxWorks. Use it to watch any of your program variables evolve in real time. StethoScope opens a window into your application; it shows you what's really happening. Use StethoScope's flexible triggering modes to collect the data you really need. Save it for later comparisons or export it to engineering analysis tools such as MATLAB and MatrixX. Each data set is time-stamped, labeled with signal names and units, and accompanied by any user notes. Other powerful features include on-screen measurements and annotation, PostScript output, "X vs Y" plots, full configuration control, workspace save and restore, direct numeric display, multiple buffer management (continue to collect data while you view saved buffers), and derived signal calculations. StethoScope will rapidly become your most important debugging, analysis, and performance enhancing tool. 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. Monitor your CPU usage graphically with StethoScope. Now comes with a friendly interactive interface. ScopeProfile shows you exactly where you're spending your CPU cycles. RTILib tools include: HeapCheck Memory integrity tester Detect and find problems that corrupt the system memory pool. Trace memory allocation to find memory leaks and excessive usage. Examples of problems these routines will expose include writing off the end of an array, using an orphan pointer, allocating but not freeing blocks, etc. rshell Re-entrant shell program Open multiple interactive terminal sessions. Add menus, user input, and simple debugging to your program without tying up the VxWorks shell. Use rshell to parse files of commands or send commands directly from a UNIX host. Patch Code-patching utility Quickly interject code segments into an actively running system. Insert delays into driver code, protect routines from task switching, etc. with a simple one-line command. Trace Execution tracing facility Get a record of what routines were called, which task called them, what order they were called in, and the list of arguments each was called with. Follow and debug code execution sequences; watch how your multi-process (and interrupt) environment works. cle Tcsh-style command-line editor Add tcsh (emacs) line editing and recall to any tty-based program. Use it, for example, with rlogin and rshell to give a friendly, familiar interface. FastBuffer Fast buffer management Allocate a pool of fixed-size memory buffers. Access this memory very quickly, even from interrupt-level code. Query Interrogation utilities Easily prompt the user for strings, integers, reals, filenames, and more. All routines have defaults and limit checking. Shm Shared-memory server Share memory between VxWorks CPU cards, between UNIX processes, or between UNIX processes and VxWorks targets in some shared-bus configurations. netio Simplified interfaces to the TCP and UDP code Speed your development with these simplified interfaces to the network code. ------------------------------------------------------------------------------ StethoScope 4.1 supports Sun4 hosts running SunOS 4.x or Solaris 2.x and these targets: arch VxWorks StethoScope ScopeProfile RTILib 68k+ 5.0 yes yes yes 68k+ 5.1 yes yes yes 683xx 5.1 yes yes yes i960 5.0 yes yes yes* sparc 5.0 yes yes yes* sparc 5.1 yes yes yes* sparcLite 5.1 yes yes yes* vxsim 5.0 yes no yes* sun4 Solaris 1.x yes no yes++ sparcSol2 Solaris 2.x yes no yes++ + 68k supported with or without floating-point coprocessor * Patch and Trace tools run only on 680x0 processors ++ SunOS 4.x (sun4) and SunOS 5.x (sparcSol2) libraries included to allow connection to UNIX-based programs. Patch, Trace, rshell, and HeapCheck not supported on UNIX. ------------------------------------------------------------------------------ For a limited time, all these tools are bundled at one low price. Contact your WRS sales representative or RTI for more details and licensing information. 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. -- 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 thoff@netxwest.com Fri Jun 4 16:28:18 1993 From: thoff@netxwest.com (Todd Hoff) Date: Fri Jun 4 16:28:27 PDT 1993 Subject: Ideas on Updating Software in Place? Does anyone have any experience with or ideas on how to replace/update running software in place? One big question: how? Thanx for any help From daemon@vxw.ee.lbl.gov Sun Jun 6 04:01:02 1993 From: daemon@vxw.ee.lbl.gov Date: Sun Jun 6 04:01:10 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jun 6 04:00:54 PDT 1993 Subject: Stack checking ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Stack checking Date: Sat, 5 Jun 1993 20:28:19 GMT From: mkb@cs.cmu.edu (Mike Blackwell) Organization: Field Robotics Center, CMU Message-ID: Reply-To: mkb@cs.cmu.edu Sender: news@cs.cmu.edu (Usenet News System) What tools are available to help you determine how much stack to allocate to a task? How about for real time stack checking while debugging (I realize you'd take a performance hit). It looks like RTIlib will do the trick. Anything else out there? thanks! Mike Blackwell mkb@cmu.edu --------------------------- End of New-News digest ********************** From ross@scfe.chinalake.navy.mil Mon Jun 7 09:32:45 1993 From: "Go Oakland, Go Eck!!!" Date: Mon Jun 7 09:33:16 PDT 1993 Subject: please delete me DELETE From daemon@vxw.ee.lbl.gov Tue Jun 8 04:01:10 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jun 8 04:01:19 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jun 8 04:01:00 PDT 1993 Subject: VxWorks SCSI for next release... Subject: StethoScope Experiences Subject: SNMP input requested ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks SCSI for next release... Date: Mon, 7 Jun 1993 15:40:13 GMT From: carl@wrs.com (Carl Chesbrough) Organization: Wind River Systems, Inc. Keywords: SCSI Message-ID: Sender: news@wrs.com (News Manager) I am currently working on a specification for updating the VxWorks SCSI support. I am looking for input from existing users to add to the specification. The next release will support SCSI-2 devices as well as the existing devices we support. We will have support for block devices (disks) and sequential devices (tapes). There will be support for disconnect/reconnect and synchronous transfer as well as multiple initiators. If you have any additional requests, or have existing code you have written and care to provide WRS so we can evaluate it and add it to our standard product please contact me at the following address: Carl C. Chesbrough Wind River Systems, Inc. 1010 Atlantic Avenue Alameda, California 94501 (510) 748-4100 carl@wrs.com I do not have a timeframe for the next release, but now is the time to get your request in. Those supplying code, or requesting a feature may be asked to work with us as a BETA site for the code when it is available. Thank you, - -Carl. --------------------------- Newsgroups: comp.os.vxworks Subject: StethoScope Experiences Date: Mon, 7 Jun 1993 17:55:44 GMT From: sass@ast.saic.com (Dennis Sass) Organization: SAIC Message-ID: <1993Jun7.175544.22467@ast.saic.com> Reply-To: sass@ast.saic.com Sender: news@ast.saic.com I'a appreciate hearing of any experiences (positive and otherwise) of using StethoScope - especially in a VADSWorks (Ada) environment. Thanks in advance. - --- Dennis Sass | telephone: 619.458.5152 Science Applications International Corporation | fax: 619.546.6833 4161 Campus Point Court MS/E3 | internet: sass@ast.saic.com San Diego, CA 92121 | - -- --------------------------- Newsgroups: comp.os.vxworks Subject: SNMP input requested Date: Mon, 7 Jun 1993 21:24:07 GMT From: hipp@wrs.com (Emily Hipp) Organization: Wind River Systems, Inc. Message-ID: Sender: news@wrs.com (News Manager) Hi, I'm interested in obtaining some information about SNMP and VxWorks. If you are currently using SNMP with VxWorks, and/or have a interest in SNMP for VxWorks and are willing to provide input (i.e. fill out a quick questionnaire), please send me your email/air mail address. Your input is appreciated! Send to me at hipp@wrs.com Thanks! Emily Hipp --------------------------- End of New-News digest ********************** From interf!atlas!io!vhopson@uunet.uu.net Tue Jun 8 10:31:28 1993 From: interf!atlas!io!vhopson@uunet.uu.net (Vince Hopson) Date: Tue Jun 8 10:31:38 PDT 1993 Subject: SCSI Implementation My company is currently involved in producing a driver for a SCSI disk drive array (also contains Exabyte 8mm tape drives). The hardware that we decided on was a dedicated processor made by Interphase Corp. called a Cougar V/SCSI-2 4220. If anyone has written a driver for or worked with this particular board, I would appreciate any comments/suggestions from you. I would also like to solicit any comments in general about disk drive SCSI interaction, or Exabyte anomalies. Please reply to my private e-mail address below, or if you feel that your answer has some value for the exploder, post it there. I will be checking both places. Thanks in advance. ...vince ------------------------------------------------------------------------------- Vincent M. Hopson vhopson@interf.com Interferometrics Inc. voice: (202) 653-0945 8150 Leesburg Pike fax: (202) 653-1848 14th Floor Vienna VA 22182 ------------------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Wed Jun 9 04:01:09 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jun 9 04:01:20 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jun 9 04:00:58 PDT 1993 Subject: 68040 data cache info requested Subject: Summary: Ammunition For Choosing VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: 68040 data cache info requested Date: 8 Jun 93 17:57:49 GMT From: kearns@budoe.bu.edu (Ed Kearns) Organization: Boston University Physics Department Keywords: motorola 68040 cache mvme167 Message-ID: <122322@bu.edu> Sender: news@bu.edu Hi net, I would like information about controlling the data cache on the 68040 that is in my MVME167. Specifically, I want to turn it off and on. I have been unable to find anything in '167 Programmer's Guide; the other doc I have handy is the M68000 Family Reference which speaks of a CINV instruction on page 3-307, and the cache control register (CACR) on 3-299, but does not give details. Some net.help would be greatly appreciated, Ed --------------------------- Newsgroups: comp.os.vxworks Subject: Summary: Ammunition For Choosing VxWorks Date: 9 Jun 93 10:40:32 GMT From: sp_sjp@nodomain (Simon Pryor) Organization: Alcatel Bell Telephone Message-ID: <2047@alcbel.be> Reply-To: sp_sjp@nodomain Sender: root@alcbel.be In article <2037@alcbel.be>, on 2 Jun 93, I ask the questions: > We are evaluating solutions to a forthcoming embedded project, > that we have planned, and would appreciate any comments. > > The project is to be in C++, on a (probable) VME target with > Sun SPARC hosts. We have used ObjectCenter on a previous > project (Sun host & target), so the VxWorks & WindC++ Gateway > would be one obvious (and interesting) solution. > > We are also looking at a full OOA, OOD and Cadre's latest > TeamWork, appears to also link directly into ObjectCenter, > closing the loop from Analysis to real-time embedded code. > > We will need a very high data throughput, maybe FDDI or > Ethernet, which makes VxWorks networking also attractive. > > We could also envisage using things like SNMP in the future and > I note there have been ports to VxWorks; What about other RT OSs? > > An alternative might be VRTX using the Velocity cross-development > environment (or indeed others). > > Does anyone have any convincing arguments as to why VxWorks is > best (or otherwise). Either technical and/or commercial (financial) > arguments would be of interest. > > I realise the I'll get scores of hate-mail, but I get the impression > that VxWorks is winning the "real-time os" wars, with people moving > from things like VRTX, pSOS+, LynxOS, etc, to VxWorks. Is this true? Since then I have had several replies, some of them asking me to summarize my replies back to the net which I have done here. I was unsure of normal practise, but I have suppressed the names of respondents, as I thought appropriate, to protect their right to anonymity (as they e-mailed me, and any entry direct to the net may have been worded differently). A US government worker wrote (it receives may gold "Best Reply" award): > I never believe that there's one *true* answer to all questions. I > think that the answer depends on the situation, and that each situation > needs to be examined on it's own. > > VRTX32 and PSOS+ have long histories as robust, reliable, fast RT > kernels for resource-limited, embedded applications, like telephones. > > However, the world is changing. People are developing real-time systems > which are *not* resource limited. VMEbus systems typically have Mbytes of > RAM and ROM, as well as network and disk connections, all at a reasonable > cost. WRS started off by added support for these things *on top* of PSOS > and VRTX, i.e. making theses kernels less suitable for their intended > application, but more suitable for this 'new' type of application. > Since both SCG (PSOS) and Ready Systems (VRTX) are grafting VxWorks-like > development facilities on top of their core systems, > it appears that they are 'caving in'. However, last I checked, they still > offer a 'core' kernel at a ridiculously low price. With VxWorks you *have* to > buy all the bells and whistles. > > Systems like QNX and LynxOS seem (to me) to be approaching the problem > from a much different angle. It seems that they are relying on the > fact the standards (defacto and de jure) tend to make systems more competitive. > > Both of these systems will run on an off-the-shelf IBM PC, and support > POSIX standards for programming. VxWorks is now scrambling to add POSIX > support (some of 1003.1 and 1003.4, draft 12), but will never be able > to fully support these standards. VxWorks also doesn't work on iNTEL machines. > > before LynxOS and QNX, there was OS-9 (and OS-9000). This was touted as > something of a UNIX work-alike, tho it never complied with POSIX, so > it seems not to have caught on as much as it could have. > > Soo..... I see the real-time world as divided into three segments : > > 1) 'small' realtime systems, like my GPS, or my laser printer, constrained > in resources and price. VRTX32 and PSOS+ are ideal. VxWorks could be used, but > mostly because of it's development environment, not because of it's features. > > 2) 'medium' systems, usually one programmer, one computer, > dedicated to a specific task. Many scientific experiments fall into this > category. Take some data, massage said data. Use the results to control > some apparatus, log the results. The segment seems to be dominated by turn-key > systems, like Lynx or QNX on a PC. I've also seen Lynx and OS-9 on VME systems > in this environment. VxWorks is ill-suited, 'cause you need to buy 2 computers, > not one. VxWorks is not a self-hosting system. > > 3) 'big' networked realtime systems, like the particle accelerator > control system we're building, or N.Y. City's integrated traffic light system. > VxWorks is ideal. The cost of VxWorks is small WRT the cost of the whole > system. A well-integrated, and easy-to-use development environment is a > requirement for a large system, with many people working on it. > > If VxWorks is 'winning' it's because it's essentially unrivalled in category > 3) applications, and category 3) applications are becoming more prevalent. > VRTX velocity and PSOS 'quick start' (or whatever it's called) aren't quite > as well integrated into the UNIX host as VxWorks is. I *don't* think VxWorks will > make great inroads in category 2) applications against firmly entrenched > competitors like Lynx and QNX. > > BTW, you never stated what your application was. Since you mentioned goodies > like C++, Cadre, and FDDI (not ATM?), it sounds like your application fits > into category 3). If I were you, I'd use VxWorks. To this I would add: WRS have released MicroWorks which is presumably to address the category 1) applications and means you don't have to buy all the bells & whistles. Ready Systems seem to dumping the monolithic VRTX32 and moving to VRTXsa which is a micro-kernel with scalable, preemptable library kernel routines, and their Spectra development evironment, competing with most things the WRS have for category 3). A disgruntled Hardware/BSP developer wrote (against WRS): > The one comment I would make is that the customer support is definitly > substandard. The level 1 support people seem to know less then I do and if > you are running a custom board, they take very little interest in assisting > you w/ problems that might very likely be theirs. > > I find this particularly puzzling in light of the fact that we are > evaluating their OS for use in multiple platforms, and if it were my > company, I would be kissing mucho butt to make a good impression. A nuclear physicist at a Belgian university wrote: > I'm using VxWorks since 3 years for RT data acquisition. I'm really happy > with it and I am still convinced that it is the more powerful RT kernel > right now ! However, one choice to consider now is also Lynx OS which > follows closely the 1003.x suite - this might be an advantage despite > lower performances ! An ISI employee dbarnett@isi.com (David Barnett) wrote: > I am Product Marketing Manager for Networking Products at Integrated > Systems, producers of the pSOSystem (and pSOS and pSOS+) real-time > operating system and development environment. > > You mention that you require C++ development. I believe that ISI was the > first RTOS vendor to have fully integrated and supported C++ support, which > began shipping in November, 1992. In addition to including a C++ compiler > our C++ support also includes class libraries for all OS services. We have > also made several major enhancements to standard C++ to make it more > suitable for real-time use. One of these is replacing the standard C++ > memory allocator (malloc) with one optimized for C++ use. Our allocator > (whose use is transparent to the programmer, of course) solves the C++ heap > fragmentation problem be utilizing several heaps for data structures of > different sizes. These sizes are selected by the programmer based upon the > sizes of data structures in the application. Another optimization is an > "object register". This allows objects to be automatically freed when the > task which owns them exits. > > With regards to SNMP, I believe that pSOSystem is the only RTOS to include > an integrated SNMP agent, which may also function as a proxy. We include a > MIB compiler so that you may extend or restrict its functionality. We have > also instrumented out TCP/IP stack so that it fully suports all MIB-II > objects and operations (except for the EGP group), including read-write, > row insertion and row deletion. There is a standard ioctl() programming > interface to our MIB-II functionality so SNMP may be bypassed when just > MIB-II functionality is needed or so our MIB-II implementation may be used > with other SNMP agents. > > With regard to networking support, we have a complete TCP/IP stack which > includes the source code to both Ethernet and FDDI device drivers (as well > as SLIP). Our networking device driver interface is protocol and upper > layer-implementation independent. This both simplifies the effort and code > involved in writing a driver and also allows our drivers to be shared > between the TCP/IP and other protocol stacks (such as OSI). It is not > necessary to modify our networking drivers to use them with other protocol > stacks. > > Since you are interested in both object oriented design and networking, you > may also be interested in a new product we have just introduced. It is > called the "Distributed Systems Generator" (pSOSystem/DSG) and consists of > development tools, libraries and application programming interfaces > designed to facilitate the design and development of real-time distributed > systems. With pSOSystem/DSG, an application is specified in terms of state > machines. Each state machine is designated a "worker". Workers > communicate using either synchronous remote procedure calls or asynchronous > message queues. Inter-worker communication is optimized based upon whether > the two communicating workers reside in the same task, different tasks on > the same CPU, different CPUs of the same type or with the same data > representation or different CPUs of different types. Faciltities are also > provided for fault tolerance and to support dynamic reconfiguration. > pSOSystem/DSG also runs under several UNIX variants (including SunOS). > This has two advantages: it allows code sharing and seamless communications > in a heterogeneous UNIX/pSOSystem environment and also allows applications > to be fully developed under UNIX and later executed on top of pSOSystem. > The pSOSystem/DSG programming interface hides the differences in the > underlying tasking and timer interfaces between UNIX and pSOSystem. Another ISI employee nlethaby@isi.com wrote: > Financial: > Integrated Systems (the company that produces pSOS+) is a public-owned > company with a consistent record of profitability and growth. We have been > publically owned for much longer than WindRiver and have a large amount of > cash in the bank (>$25 million). Financially, we are the stongest RTOS > company. > > Although I'm not sure of Alcatel Bell relationship to other parts of > Alcatel, Alcatel has made very significant investments in pSOS+ in Dallas > and on the east coast. > > Technical: > pSOS+ is very suitable for your project requirements. > > 1. C++. We have offered a C++ solution for over a year, whereas WindRiver > is only just introducing their solution. Our solution is also more > complete, addressing issues such as optimized memory management for C++ > and providing an object-oriented interface to some pSOS+ services. Since we > have been supporting C++ projects for more than a year, our technical > suport staff are more experinced in C++ issues than WindRiver's. We also > have a training course for pSOS+ C++ users. While we do not provide formal > integration with ObjectCenter, there is no reason why you cannot continue > to use it. Certainly, I know at least one pSOS+ C++ user that uses > ObjectCenter extensively. > > 2. Networking. We have good networking support including etherent and > FDDI. Unlike WindRiver, we already supply a fully supported version of SNMP > for pSOS+. A disgruntled pSOS users wrote (psos+ hate mail, let me be the first): > We recently had a merger of **** and had > the *priviledge* of moving from vxworks to psos. > Let me count the ways I hate psos+ > > 1) no on line man pages > 2) the manual is broken down by products. There is no master > index. If you change from looking up socket() to > looking up bcopy() you must pull out a different manual > 3) Intuititive names like > sm_p acquire a semaphore > sm_v give a semphore > 4) Needing a 4 character identifier when createing each semaphore > and task. This makes porting a real pain > 5) Total incompability with unix makes using widely available > anon ftp packages very hard. > 6) No mail exploder. *Total* isolation from other users. > 7) The old phone-call system for getting tech support. How many > times have I seen the answer from a VxWorks engineer > posted right to the vxworks mail exploder. > 8) totally unfamiliar debugger. > 9) absolutely unbelievably gross makefiles. They use many includes > of other files which makes it very hard to use any > compile directives in your makefiles. > 10) that nagging feeling that my unix knowledge and therefore general > marketability is slowly draining away. > > I produced a 2 page position paper on why choosing psos would cost > us more in devlopment time and reduce the labor pool we could hire > from. If it isn't obvious why using psos will cost you more from > the above points just think about the learning curve and retraining > time you waste when hiring someone unix literate and expecting > them to start producing psos code. Well, that was about it. I'll leave you to make your own conclusions. No doubt the debate will continue. A big thankyou to all who gave of their time to reply. sp_sjp@space.alcbel.be (Simon Pryor) --------------------------- End of New-News digest ********************** From fjr@ssd.ray.com Wed Jun 9 07:30:23 1993 From: Roeber Date: Wed Jun 9 07:30:31 PDT 1993 Subject: Re: 68040 data cache info requested Ed Kearns writes: > I would like information about controlling the data cache on the > 68040 that is in my MVME167. Specifically, I want to turn it off and on. > > I have been unable to find anything in '167 Programmer's Guide; > the other doc I have handy is the M68000 Family Reference which > speaks of a CINV instruction on page 3-307, and the cache control > register (CACR) on 3-299, but does not give details. VxWorks for the 167 provides a number of routines to control the cache. They are named cache* and are contained in the cacheLib and cacheALib files. For some reason I don't understand, there are no man pages for these two modules. Since I don't know why the information isn't publically provided, I don't think I can list what the source files say. You should ask VxWorks for info on the routines in these modules. Fred | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 177 | | Portsmouth, RI 02871-1087 (401) 842-4205 | | fjr@ssd.ray.com | From stan@rti.com Wed Jun 9 10:45:13 1993 From: stan@rti.com (Stan Schneider) Date: Wed Jun 9 10:45:22 PDT 1993 Subject: Re: 68040 data cache info requested >> Submitted-by fjr@ssd.ray.com Wed Jun 9 07:30:23 1993 >> >> Ed Kearns writes: >> > I would like information about controlling the data cache on the >> > 68040 that is in my MVME167. Specifically, I want to turn it off and on. >> > >> > I have been unable to find anything in '167 Programmer's Guide; >> > the other doc I have handy is the M68000 Family Reference which >> > speaks of a CINV instruction on page 3-307, and the cache control >> > register (CACR) on 3-299, but does not give details. >> >> VxWorks for the 167 provides a number of routines to control the cache. >> They are named cache* and are contained in the cacheLib and cacheALib files. >> For some reason I don't understand, there are no man pages for these two >> modules. Since I don't know why the information isn't publically provided, >> I don't think I can list what the source files say. You should ask VxWorks >> for info on the routines in these modules. Fred >> The VxWorks 5.1 programmer's reference contains pretty thorough documentation on these functions. Full man pages are also provided. -- 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 daemon@vxw.ee.lbl.gov Thu Jun 10 04:01:18 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jun 10 04:01:28 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jun 10 04:01:07 PDT 1993 Subject: AP Labs VxWorks AIO Device Drivers Subject: (argc,argv) constructions under VxWorks Subject: Re: SCSI Implementation Subject: Re: StethoScope Experiences ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: AP Labs VxWorks AIO Device Drivers Date: Wed, 9 Jun 1993 13:47:24 GMT From: curry@tc.fluke.COM (John Curry) Organization: John Fluke Mfg. Co., Inc., Everett, WA Message-ID: <1993Jun9.134724.7375@tc.fluke.COM> We are seriously looking at the AP Labs AIO IEEE and PIO Device drivers for VxWorks and I was wondering if anyone else on the net has had experiences with AP Labs and/or their software. I'm particularly interested in how you felt about their software, their technical support, and the company in general. Any information would be helpful. Thanks, John Curry curry@tc.fluke.com --------------------------- Newsgroups: comp.os.vxworks Subject: (argc,argv) constructions under VxWorks Date: 9 Jun 93 16:04:40 GMT From: carey@budoe.bu.edu (Robert Carey) Organization: Boston University Physics Department Message-ID: <122490@bu.edu> Sender: news@bu.edu Dear net, Some months ago, there was a discussion of how to implement the (argc,argv) construction within VxWorks. Did anyone save this discussion or can someone direct me to an archive site? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SCSI Implementation Date: Wed, 9 Jun 1993 22:18:58 GMT From: carroll@ast.saic.com (John Carroll) Organization: SAIC Message-ID: <1993Jun9.221858.2474@ast.saic.com> References: <9306082029.AA02637@io.pleiades> Reply-To: carroll@ast.saic.com Sender: news@ast.saic.com In article AA02637@io.pleiades, interf!atlas!io!vhopson@uunet.uu.net (Vince Hopson) writes: > >My company is currently involved in producing a driver for a SCSI disk drive >array (also contains Exabyte 8mm tape drives). The hardware that we decided >on was a dedicated processor made by Interphase Corp. called a >Cougar V/SCSI-2 4220. > >If anyone has written a driver for or worked with this particular board, I >would appreciate any comments/suggestions from you. I would also like to >solicit any comments in general about disk drive SCSI interaction, or >Exabyte anomalies. > >Please reply to my private e-mail address below, or if you feel that your >answer has some value for the exploder, post it there. I will be checking >both places. > >Thanks in advance. > ...vince > > >------------------------------------------------------------------------------- >Vincent M. Hopson vhopson@interf.com >Interferometrics Inc. voice: (202) 653-0945 >8150 Leesburg Pike fax: (202) 653-1848 >14th Floor >Vienna VA 22182 >------------------------------------------------------------------------------- AP Labs in San Diego "sort of" has a driver for the Cougar board. It requires the use of their Asynchronous I/O software library. The reason they "Sort of" have a driver is that they wanted us to pay for some of the software development costs. In addition, I believe there is a licensing fee for each CPU that uses their Asynchronous I/O software library. We opted for Macrolink in Irvine and I have successfully tested a beta release of their software on VxWorks 5.02b. Macrolink is interested in selling boards - thus there is a very low cost ($150) fee for their software - which includes source code. For our low volume project, we saved $ by going with Macrolink. - -- John Carroll | telephone: 619.458.5071 Science Applications International Corporation | fax: 619.558.1391 4161 Campus Point Drive MS E3 | email: carroll@ast.saic.com San Diego, CA 92121 | - -- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: StethoScope Experiences Date: Thu, 10 Jun 93 09:15:27 GMT From: dankoski@leland.Stanford.EDU (Paul Dankoski) Organization: Stanford University Message-ID: <1993Jun10.091527.5170@leland.Stanford.EDU> Sender: news@leland.Stanford.EDU (Mr News) In article <1993Jun7.175544.22467@ast.saic.com> sass@ast.saic.com writes: >I'a appreciate hearing of any experiences (positive and otherwise) of using >StethoScope - especially in a VADSWorks (Ada) environment. Thanks in >advance. Dennis Sass, My experience as a StethoScope user has been positive. Although another graduate student actually did the setup on our a VME chassis and Sun workstation/UNIX environment, installation of upgrades has been easy. In general, Stethoscope is very intuitive and technically it is a solid product. It let's you get your work done without getting in the way! IMHO, this is nice because you avoid steep learning curves associated with some other products. (Sorry, I can't give you any opinions about an Ada environment). Another graduate student used Stethoscope for collecting data from the Rapid Thermal Multiprocessor here at Stanford University for portions of his thesis. I can contact him for you if you have an interest in other references. Real Time Innovations has been responsive to all of our questions and concerns. If you have specific questions, please contact me and I can go into more detail. Hope this helps, Paul Dankoski dankoski@rtm.stanford.edu - -- Paul Dankoski email: dankoski@isl.stanford.edu W1: (415) 723-3024 W2: (415) 725-6948 --------------------------- End of New-News digest ********************** From ppinkow@jupiter.ksc.nasa.gov Thu Jun 10 12:48:19 1993 From: ppinkow@jupiter.ksc.nasa.gov (Patrick Pinkowski) Date: Thu Jun 10 12:48:28 PDT 1993 Subject: VxWorks Driver for Interphase 4211 FDDI Board I have a motorola mv167 33 MHz 68040 with the Interphase 4211 FDDI board. I am attempting to write a device driver to drive the board at higher rates that can be attained with the protocols (UDP, TCP). One of the primary requirements for the data transmission is that network latency or delta-time between packets must be the same. A latency in the range of 50 usec is desirable, but 100 usec is acceptable. HAS ANYONE DEVELOPED A DRIVER TO THE 4211 BOARD TO PROVIDE THESE DETERMINISTIC LATENCIES? Thanks, Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov From ppinkow@jupiter.ksc.nasa.gov Thu Jun 10 12:51:57 1993 From: ppinkow@jupiter.ksc.nasa.gov (Patrick Pinkowski) Date: Thu Jun 10 12:52:14 PDT 1993 Subject: VxWorks Driver for Interphase 4211 FDDI Board - Additional Info > I have a motorola mv167 33 MHz 68040 with the Interphase 4211 FDDI board. > I am attempting to write a device driver to drive the board at higher rates > that can be attained with the protocols (UDP, TCP). One of the primary > requirements for the data transmission is that network latency or delta-time > between packets must be the same. A latency in the range of 50 usec is > desirable, but 100 usec is acceptable. HAS ANYONE DEVELOPED A DRIVER TO > THE 4211 BOARD TO PROVIDE THESE DETERMINISTIC LATENCIES? Oh, by the way I am sending small packet on the order of 100 bytes. Thanks, Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov From daemon@vxw.ee.lbl.gov Fri Jun 11 04:01:18 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jun 11 04:01:27 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jun 11 04:01:07 PDT 1993 Subject: Re: 68040 data cache info requested ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: 68040 data cache info requested Date: 10 Jun 93 17:03:21 GMT From: kearns@budoe.bu.edu (Ed Kearns) Organization: Boston University Physics Department Keywords: motorola 68040 cache mvme167 Message-ID: <122619@bu.edu> References: <122322@bu.edu> Sender: news@bu.edu Thanks net, I got several helpful responses. Several people (including WRS) pointed to the library routines cacheEnable(DATA_CACHE), cacheDisable(INSTRUCTION_CACHE) where the constants are defined in . This is available in VxWorks 5.0.2b and later. Its so happens that I mostly want to solve this for OS9 and FYI, there exists a similar routine, CCtl. As a low level solution, I was pointed to 68040 only instruction MOVEC which can directly manipulate the cache control register. This is documented in chapter 7 of the 68040 Users Manual. I gotta go get one. Anyway, thanks for all the constructive suggestions, Ed --------------------------- End of New-News digest ********************** From dkocinsk@ehsl.mitre.org Mon Jun 14 15:13:44 1993 From: dkocinsk@ehsl.mitre.org (David L. Kocinski) Date: Mon Jun 14 15:13:53 PDT 1993 Subject: Interphase FDDI Driver I know that many have tangled with the Interphase 4211 FDDI VxWorks driver that is delivered with the board. The version I have is 1.2 from AP Labs. Does someone know what the fixes are for this driver. David Kocinski dkocinsk@mitre.org From daemon@vxw.ee.lbl.gov Tue Jun 15 04:00:42 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jun 15 04:00:50 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jun 15 04:00:34 PDT 1993 Subject: Lisp? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Lisp? Date: 14 Jun 93 12:11:58 From: rmt@unh.edu (Roy M. Turner) Organization: Computer Science Department/Marine Systems Eng. Lab., U. New Hampshire Message-ID: Reply-To: rmt@cs.unh.edu (Roy M. Turner) Hi folks, I know it may not be a popular thing to do on realtime systems, but we have need of a Lisp that runs under VxWorks. Does anyone know of such a beastie that is available, preferably cheap/free? Thanks. --Roy - -- - ------------- Roy M. Turner Research Assistant Professor Department of Computer Science Kingsbury Hall, University of New Hampshire, Durham, NH 03824 Internet: rmt@cs.unh.edu Phone: (603)862-2980 --------------------------- End of New-News digest ********************** From mea@sparta.com Tue Jun 15 05:58:46 1993 From: mea@sparta.com (Mike Anderson) Date: Tue Jun 15 05:59:09 PDT 1993 Subject: Re: Lots of Infernal Stupid Parenthesis (Lisp) Greetings! Roy Turner writes: > > I know it may not be a popular thing to do on realtime systems, but we have > need of a Lisp that runs under VxWorks. Does anyone know of such a beastie > that is available, preferably cheap/free? Thanks. > --Roy > - -- Well, as strange as this may seem, I've actually been putting some thought into this problem for VxWorks. It would seem to me that Lisp may have some desirable benefits in real-time systems for certain robotics and other "AI" applications where self-modifying behavior may be a useful objective (rather than an errant pointer ;-). I haven't gotten much further than investigating the PD XLisp distribution from the simtel20 archives. However, since XLisp is written in C, is available in source and can be found in the public domain, it seems that this may be a good place to start. Now, it's not anywhere even close to a full CLOS (object-oriented, common Lisp) implementation, nor is it even complete common Lisp. But, at least it may be a good starting place. The full address of simtel20 is wsmr-simtel20.army.mil. Please keep the net posted if you make any progress. BTW, has anyone made any progress towards a VxWorks server implementation of NFS? Later, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From @ada3.ca.boeing.com:crispen@eight-ball.boeing.com Tue Jun 15 05:58:56 1993 From: crispen <@ada3.ca.boeing.com:crispen@eight-ball.boeing.com> Date: Tue Jun 15 05:59:11 PDT 1993 Subject: Re: Lisp? rmt@unh.edu (Roy M. Turner) >I know it may not be a popular thing to do on realtime systems, but we have >need of a Lisp that runs under VxWorks. Does anyone know of such a beastie >that is available, preferably cheap/free? Thanks. Depending on what you want to do with it, you may find that something like Rick Wilber and Jenny Wright's ARTIE (Ada Real-Time Inference Engine) or NASA JSC's CLIPS (C Language Integrated Production System) may do the trick. I should know a whole lot more about CLIPS (I'd better, soon, for the project I'm working on!) but I'm given to understand that it looks so much like Lisp that you can do at least half of the stuff in Winston's book on it. If either of these things sound interesting, take it offline and email me and I'll see if I can come up with the addresses. CLIPS is sorta free (media cost only, I believe) and ARTIE, while it was developed as a proprietary system in Boeing has been published now, I think. +-------------------------------+--------------------------------------+ | Bob Crispen | Who will babysit the babysitters? | | crispen@foxy.boeing.com +--------------------------------------+ | (205) 461-3296 |Opinions expressed here are mine alone| +-------------------------------+--------------------------------------+ From harvey@cse.lbl.gov Wed Jun 23 11:01:03 1993 From: harvey@cse.lbl.gov (Everett Harvey) Date: Wed Jun 23 11:01:10 PDT 1993 Subject: Exploder machine down for a few days The vxwexplo mail exploder machine was down for a few days. Sorry for the inconvenience. Everett Harvey at Lawrence Berekely Lab (510) 486-7525 From mhprice@sandia.gov Wed Jun 23 12:05:22 1993 From: mhprice@sandia.gov Date: Wed Jun 23 12:05:30 PDT 1993 Subject: X.25 protocol for VxWorks? Does anyone know of a public or commercial implementation of the X.25 protocol for use with VxWorks? If anyone has any information, I would appreciate it. _/_/_/_/ _/ _/ _/ Mark H. Price _/ _/_/ _/ _/ Email: mhprice@sandia.gov _/_/_/_/ _/ _/ _/ _/ (505) 845-9732 FAX 844-2925 _/ _/ _/_/ _/ Senior Member of the Technical Staff _/_/_/_/ _/ _/ _/_/_/_/ Real-Time Monitors & Controllers Department 2337 Sandia National Laboratories Albuquerque, NM 87185 From mitchell@harpo.aaec.com Wed Jun 23 13:51:22 1993 From: mitchell@harpo.aaec.com Date: Wed Jun 23 13:51:31 PDT 1993 Subject: selNodeAdd et. al. Can anyone point me to information on these routines for 5.02. The documentation sends me off to the I/O system section of the programmer's guide which doen't seem to mention select. I'm trying to add select capability to a driver and don't know how to initialize the node that gets copied into the select list, or what criterion are used to find the node to remove (selNodeDelete). Does the new node have to be completely initialized? Should I set the semaphore pointer to the select sem in the task id block? I am not looking at the right manual? (BTW my 5.1 documentation seemed no better). Andrew Mitchell | Internet: mitchell@aaec.com Atlantic Aerospace | tel: (617) 890-4200 470 Totten Pond Road | fax: (617) 890-0224 Waltham MA 02154 USA | From thoff@netxwest.com Wed Jun 23 16:07:18 1993 From: thoff@netxwest.com (Todd Hoff) Date: Wed Jun 23 16:07:26 PDT 1993 Subject: Any problems with increaing the number of fds? The default number of fds is 50. We need more than this. Are there any problems with increasing this number to say 256 as it is on the Sun? Thanx for any help From daemon@vxw.ee.lbl.gov Thu Jun 24 04:01:27 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jun 24 04:01:38 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jun 24 04:01:17 PDT 1993 Subject: Ironics IV-SPRC Experiences? Subject: SparcEngine experience? Subject: NFS server for VxWorks proposal Subject: problems initializing network from EPROM Subject: Where is the FAQ? Subject: Re: Where is the FAQ? Subject: SNMP availability for Vxworks? Subject: sun2ce virtual memory Subject: Re: SNMP availability for Vxworks? Subject: Re: SNMP availability for Vxworks? Subject: FAQ of Vxworks? Subject: need help with serial configuration Subject: WANTED: X for VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Ironics IV-SPRC Experiences? Date: Tue, 15 Jun 1993 15:30:29 GMT From: osmolski@ireq.hydro.qc.ca (George Osmolski) Organization: Institut de recherche d'Hydro-Quebec, Varennes, Canada Message-ID: Sender: news@ireq.hydro.qc.ca (Netnews Admin) Can anybody share their experiences (positive or negative) with the Ironics IV-SPRC-25 or more importantly IV-SPRC-40 CPU cards? If you used vxWorks, which version was used? Email responses will be kept in confidence. - -- George Osmolski osmolski@ireq-robot.hydro.qc.ca Laboratoire de Robotique osmolski@ireq-robot.uucp Institut de recherche d'Hydro-Quebec(IREQ) (514)652-8235 Varennes, Quebec, Canada --------------------------- Newsgroups: comp.os.vxworks Subject: SparcEngine experience? Date: Tue, 15 Jun 1993 16:41:54 GMT From: dac@frc.ri.cmu.edu (Daniel Christian) Organization: Field Robotic Center, CMU Message-ID: Reply-To: dac@ri.cmu.edu (Dan Christian) Sender: news@cs.cmu.edu (Usenet News System) Have many people used VxWorks on SparcEngines? How stable is it? Which boards work well (or not)? What bandwidth do you get over the onboard ethernet (to a fast system like a SparcStation 2)? How much memory is used up at run time by the standard development kernel? Do the Sun (or Gnu) compilers work for development? How does performance compare to SunOs (general or floating point)? The real question: Is it a better solution than a 68040 board? " " MIPS boards? Does it work better in embeded systems than Solaris 1 or 2? Many, many thanks, - -Dan - -- ___________________________________________________________________________ Dan Christian Field Robotics Center Carnegie Mellon University (412) 268-6562 dac@ri.cmu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: NFS server for VxWorks proposal Date: Tue, 15 Jun 1993 16:11:55 GMT From: hjb@netcom.com (h.j.bae) Organization: PEACEFUL STAR, Oakland, CA, Voice:(510)536-7607, Page:(510)466-9166 Message-ID: if anyone out there is willing to provide target environment (vme board, backplane, vxworks runtime or some sort of emulation of vxworks) in the bay area, i'd be willing to work in providing a free nfs server port in source format. i'd also like to port the net-2 tcp/ip to whatever the latest vxworks wrs sells nowadays -- i've done this already for a vendor who isn't going to make the port available (besides, it was to a very old version of vxworks). i was responsible for vxworks 5.0 networking code while i worked there. so i think i know how to do this work -- perhaps better this time. i'm willing to do all this work for free and make all the source available freely (as they should be, since bsd originals are free). just need some equipment. all this is pretty easy work, if someone else wants to do the work, i'd be more than happy to help as much as i can. love, hwajin - -- Email: hjb@netcom.com Office: (510)536-7607 Pager: (510)466-9166 PEACEFUL STAR PROJECT, Oakland, California UNIX, Embedded/Realtime, Networking Consultants --------------------------- Newsgroups: comp.os.vxworks Subject: problems initializing network from EPROM Date: Tue, 15 Jun 1993 16:43:26 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA ARC/ Information Science Division Keywords: EPROM, network Message-ID: <1993Jun15.164326.244@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov) Hi all, I am trying to burn some application code into EPROM but I am having problems getting the network to initialize when I boot from this EPROM. Some background info: VxWorks 5.0.2b Heurikon HK68/V3D (68EC030) with EI interface AMD 27C040 EPROM The procedure I am following is: - edited kernel Makefile (changed ADDED_MODULES to include my application) - edited config.h and configAll.h to choose facilities: excluded SHELL, NET_SHOW, NET_SYM_TBL, etc. included NETWORK, EI, NET_INIT - edited usrConfig.c (added application start code at end of usrRoot() code) - did a "make vxWorks_rom.hex" - burned "vxWorks_rom.hex" to EPROM - use standard boot EPROM to setup boot parameters (IP address, target name, etc.) which are stored in NOVRAM - swapped boot EPROM with new EPROM - turn on the system What happens, of course, is that I get an error message "Attaching network interface ei0... failed". My best guess is that the call to eiattach(), which is run from usrNetInit(), is failing for some reason. I don't understand this because if I go back to the original boot EPROM and build a network bootable kernel using the same configuration (i.e., just do a "make vxWorks" without changing any parameters), everything works flawlessly. Any suggestions or insights? Recommended methods for debugging EPROM related bugs? Thanks. - -terry - -- _______________________________________________________________________________ A straight line may be the shortest Terry Fong distance between 2 points, but it is NASA-AMES M/S 269-3, Moffett Field, CA by no means the most interesting-Dr. Who (415) 604-6063 office, 604-6081 lab --------------------------- Newsgroups: comp.os.vxworks Subject: Where is the FAQ? Date: 17 Jun 93 18:13:30 GMT From: tmf30@ccc.amdahl.com (Tanming Fang) Organization: Amdahl Corporation, Sunnyvale CA Message-ID: <3cWk02pp46za01@JUTS.ccc.amdahl.com> Where can I find the FAQ for this group? Also someone wants to know where to look for some article related to Vxworks. Something like "RFC 738" and "RFC 1119". Does any one know where to look for these stuff? Maybe some ftp sites? Thank you in advance, Tanming Fang tmf30@juts.ccc.amdahl.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Where is the FAQ? Date: Fri, 18 Jun 1993 14:21:52 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <3cWk02pp46za01@JUTS.ccc.amdahl.com> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Sender: news@cs.cmu.edu (Usenet News System) I don't think we've created a FAQ yet, have we? The RFCs can be obtained (among many others, I suspect) via anonymous ftp from wuarchive.wustl.edu, under directory /doc/rfc - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Das Trinkgefaess, wenn einmal leer, macht keine rechte Freude mehr - W. Busch --------------------------- Newsgroups: comp.os.vxworks,comp.protocols.snmp Subject: SNMP availability for Vxworks? Date: 18 Jun 93 15:54:02 GMT From: sp_ppm@space.alcbel.be (Paul Moore) Organization: Alcatel Bell Telephone Message-ID: <2055@alcbel.be> Followup-To: comp.os.vxworks Reply-To: sp_ppm@alcbel.be Sender: root@alcbel.be Hello, I would like to know are there any commercial SNMP implementations that can be used with Vxworks? At the moment, I don't know a lot about SNMP (I'm waiting for my copy of "The Easy Book" to arrive), but I understand that once the SNMP agent is in place, that a MIB then has to be written. Does this involve much effort. I hope that it is covered in this book. Please email, and I will summarise, if useful. Thank you for your time, Paul - ---- Paul Moore, email: sp_ppm@space.alcbel.be Alcatel Bell Telephone, Space Dept. TS664, phone: (+32) 3/829.5024 Berkenrodelei 33, 2660 Hoboken, Belgium. --------------------------- Newsgroups: comp.os.vxworks Subject: sun2ce virtual memory Date: Fri, 18 Jun 93 15:33:48 GMT From: mcdowell@exlogcorp.exlog.com (Steve McDowell) Organization: Baker Hughes INTEQ, Inc. Message-ID: <1993Jun18.153348.12517@exlog.com> Sender: mcdowell@exlog.com (Steve McDowell) Under vxWorks 5.1 on a sun2ce: Does anyone have any documentation or examples on manipulating the mmu on a force sun2ce board using the supplied (and undocumented) calls: sun4SysGet/Set() sun4PageGet/Set() sun4SegGet/Set() Also, I'm looking for the bit definitions for the page map & PMEG entries. Any help is greatly appreciated, thanks. - -- Opinions are mine, not my employers --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SNMP availability for Vxworks? Date: Mon, 21 Jun 1993 00:09:17 GMT From: pwilson@world.std.com (Pete Wilson) Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <2055@alcbel.be> Paul Moore writes -- : I would like to know are there any commercial SNMP implementations that can : be used with Vxworks? The Universal SNMP Agent (portable sources, platform- and OS-independent) is installed on hundreds of VxWorks machines. Customer wrote a VxWorks version of MIB2 for the Agent. E-mail me for more information on v1 and v2 releases. +---------------------------------------------------------------------------+ | Pete Wilson e-mail: pwilson@world.std.com | | Paul Freeman Associates, Inc. phone : 508-692-4436 | | 14 Pleasant Street, P. O. Box 2067 Westford, Massachusetts USA 01886 | +---------------------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SNMP availability for Vxworks? Date: Mon, 21 Jun 1993 14:40:22 GMT From: sharpster@hns.com (Stephen Harpster) Organization: Hughes Network Systems Message-ID: <1993Jun21.144022.13096@hns.com> References: <2055@alcbel.be> Sender: news@hns.com (USENET news system) In article <2055@alcbel.be>, sp_ppm@space.alcbel.be (Paul Moore) writes: |> |> I would like to know are there any commercial SNMP implementations that can |> be used with Vxworks? Jeff Case, the guy who "invented" SNMP, is president of a company called SNMP Research, Inc. Their product runs under VxWorks very nicely. We've used it successfully for some time now. For more info, talk to John Southwood SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, Tennessee 37920-9716 phone: 615-573-1434 fax: 615-573-9197 - -- Stephen Harpster Hughes Network Systems sharpster@hns.com --------------------------- Newsgroups: comp.os.vxworks Subject: FAQ of Vxworks? Date: 23 Jun 93 19:42:34 GMT From: ays80@RUTS.ccc.amdahl.com (Anupam Srivastava) Organization: Amdahl Corporation, Sunnyvale CA Message-ID: <07EB02pm476n01@JUTS.ccc.amdahl.com> Reply-To: ays80@RUTS.ccc.amdahl.com (Anupam Srivastava) Sender: netnews@ccc.amdahl.com Where is the FAQ for this newsgroup? Thx in adv, Anupam --------------------------- Newsgroups: comp.os.vxworks Subject: need help with serial configuration Date: Wed, 23 Jun 1993 22:59:48 GMT From: doctor@kronos.arc.nasa.gov (Terry Fong) Organization: NASA ARC/ Information Science Division Keywords: serial, ioctl Message-ID: <1993Jun23.225948.6126@kronos.arc.nasa.gov> Sender: usenet@kronos.arc.nasa.gov (usenet@ptolemy.arc.nasa.gov) Hi all, Can anyone tell me how to configure a serial port for: 1200 baud 7 data bits 1 stop bit odd parity As far as I can tell, the ioctl's within tyLib only allow me to configure a port for: 1200 baud *** 8 data bits *** 1 stop bit *** odd parity *** (input, using ioctl for OPT_7_BIT) Any help would be greatly appreciated! Thanks. - -terry - -- _______________________________________________________________________________ 3-PEAT....3-PEAT....3-PEAT....3-PEAT Terry Fong DA BULLS !!! NASA-AMES M/S 269-3, Moffett Field, CA 3-PEAT....3-PEAT....3-PEAT....3-PEAT (415) 604-6063 office, 604-6081 lab --------------------------- Newsgroups: comp.os.vxworks Subject: WANTED: X for VxWorks Date: 22 Jun 93 09:37:58 +0100 From: pquaaden@mswe.dnet.ms.philips.nl Organization: Philips Medical Systems Nederland Message-ID: <1993Jun22.093758.131418@mswe.dnet.ms.philips.nl> Hello there!! This is the first time I post something on news, so I hope everything goes OK!! I am looking for X stuff on VxWorks. Can someone mail me where I can find this?? My mailaddress is: pquaaden@cardio1.ms.philips.nl Thanks!!! Peter Quaaden --------------------------- End of New-News digest ********************** From mea@sparta.com Thu Jun 24 15:47:12 1993 From: mea@sparta.com (Mike Anderson) Date: Thu Jun 24 15:47:41 PDT 1993 Subject: ROM Sizes > 128K Greetings! I'm trying to build a set of boot ROMs wherein the compressed size of the ROMs is greater than 128K. I've changed the ROM_SIZE field in both the Makefile and the config.h for my target (Heurikon HK68G/V3D) to reflect the fact that I'm using 27020 (2 MBit) ROMs. I do the make bootrom.hex and everything seems to go fine. The making of the ROMs goes like a charm, but when I put the ROM on the board, it crashes and burns. That is, nothing seems to happen and I never get even a boot prompt. I seem to remember a discussion on the exploder sometime back regarding boot ROM sizes (maybe stack segment problems?) but I've been unable to find them in any of my collected discussion files. Is there anyone out there who has run into this problem and solved it? I believe that it may be related to my inability to produce uncompressed (for speed) boot ROMs that also have a size > 128K bytes. Any clues would be greatly appreciated. Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From daemon@vxw.ee.lbl.gov Fri Jun 25 04:00:46 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jun 25 04:00:54 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jun 25 04:00:37 PDT 1993 Subject: workQPanic: what to do? Subject: Re: ROM Sizes > 128K ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: workQPanic: what to do? Date: Thu, 24 Jun 1993 17:01:24 GMT From: verleun@fys.ruu.nl (Vincent Verleun) Organization: Physics Department, University of Utrecht, The Netherlands Keywords: kernel queue reboot Message-ID: <1993Jun24.170124.28890@fys.ruu.nl> Howdy, Switching from one system (PEP/VM20) to another (Force30) I experience weird things. Software running OK on the VM20 doesn't seem to work on the Force30. I'm using some interrupt code with the 'intConnect' routine which is encapsulated with 'sysIntDisable/sysIntEnable'. That's where the Force30 hangs up on me (and performs an auto-reboot); I get back the *very* descriptive: "workQPanic: Kernel work queue overflow." (Can't find anything in the docs on that!) If I check the stacksizes with the 'checkStack' command I don't see any difference between the VM20 and the Force30. In a nutshell; I'm baffled. What's wrong with my Force30 kernel? Help/hints/comments are highly appreciated! (either email or post). Regards, Vince. - -- Vincent Verleun verleun@fys.ruu.nl. Utrecht University Physics Department Data Acquisiton Group. Buys Ballotlab 063b, Princetonplein 5, 3584 CC Utrecht, the Netherlands. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ROM Sizes > 128K Date: Thu, 24 Jun 1993 22:59:31 GMT From: browen@lyapunov.aoc.nrao.edu (Bruce Rowen) Organization: National Radio Astronomy Observatory, Socorro NM Message-ID: References: <9306242244.AA03345@helios.sparta.com> Sender: news@nrao.edu Just a thought (maybe a bit naive): Could you be overlapping memory partitions? --------------------------- End of New-News digest ********************** From ekins@sifvsj.sinet.slb.com Fri Jun 25 05:53:09 1993 From: ekins@sifvsj.sinet.slb.com (Phil Ekins - Schlumberger Instruments R&D - Farnborough UK) Date: Fri Jun 25 05:53:22 PDT 1993 Subject: GPIB driver I am looking into getting a GPIB (IEEE-488) connection to our system. We have an MVME147 CPU card and considering any possible GPIB cards and associated software. The main concern is the driver software for the GPIB card (as long as the GPIB card fits a VME rack and reliable) as we do not want to spend time writing drivers. Has anyone got (know of) a VxWorks GPIB driver for a GPIB card? Thanks, Phil. ******************************************************************************* Phil Ekins, SINet: sif::Ekins Schlumberger Technologies, Internet: Ekins@sif.Sinet.SLB.Com Instruments Division, Tel: (44) 252 376666 Ext.2287 Victoria Road, Fax: (44) 252 543854 Farnborough, GU14 7PW, England. ******************************************************************************* From fjr@rayssd.ssd.ray.com Fri Jun 25 07:30:07 1993 From: Roeber Date: Fri Jun 25 07:30:15 PDT 1993 Subject: Re: workQPanic: what to do? Vincent writes: > Switching from one system (PEP/VM20) to another (Force30) I experience > weird things. Software running OK on the VM20 doesn't seem to work on > the Force30. I'm using some interrupt code with the 'intConnect' routine > which is encapsulated with 'sysIntDisable/sysIntEnable'. That's where > the Force30 hangs up on me (and performs an auto-reboot); I get back > the *very* descriptive: "workQPanic: Kernel work queue overflow." > (Can't find anything in the docs on that!) The work queue is used by the kernel as part of its critical section method. Rather than locking interrupts whenever critical kernel tables are modified, the VxWorks kernel sets a special internal flag but leaves interrupts enabled. If kernel functions (e.g. semGive) are called from interrupt handlers, they check this flag. When the flag is set indicating the kernel is busy, the function is defered to a point where the kernel exits its critical section. The defering is done by stacking the function call on the work queue. If the critical section is too long or you get too many interrupts that try to do kernel functions too quickly then you can overflow the work queue. Is there any chance that you are using some interrupt on the Force30 that needs to be explicitly disabled in the interrupt handler to keep from occuring again (some of them work that way). If you don't disable it, you would keep getting it over and over. If the handler did something like semGive, that could explain the overflow. Fred | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 177 | | Portsmouth, RI 02871-1087 (401) 842-4205 | | fjr@ssd.ray.com | From OWENS@lodtm.llnl.gov Fri Jun 25 08:48:48 1993 From: OWENS@lodtm.llnl.gov Date: Fri Jun 25 08:48:55 PDT 1993 Subject: Re: workQpanic I experienced a similar situation when moving a set of boards from one chassis to another. In my case it was due to the fact that the backplane came from the vendor with all the iack jumpers installed. Pretty easy to remedy, but it kept me going for an hour or 2. Doug Owens Lawrence Livermore National Lab From bbeavers@ll.mit.edu Fri Jun 25 11:32:37 1993 From: bbeavers@ll.mit.edu (Willet I Beavers Jr [Bill]) Date: Fri Jun 25 11:32:45 PDT 1993 Subject: boot proms for mv167's Has anyone out there built their own boot proms for Motorola MV167 using a Unisite burner? I building the bootrom.hex on a sun3, using unix2dos utilty, copying the file onto a PC floppy. I am using Motorola EXORmacs format (87 in our version of the Unisite software). Any insights, suggestions would greatly be appreciated. Up to now, the only success I have had is copying the distribution proms. Thanks. ================================================== Bill Beavers MIT Lincoln Lab bbeavers@ll.mit.edu 244 Wood St. Voice: 617 981-2518 Lexington, Ma. 02173-9108 Fax: 617 981-7271 ================================================== From vlp@mr.picker.com Fri Jun 25 12:49:15 1993 From: vlp@mr.picker.com (Vic Potter) Date: Fri Jun 25 12:49:23 PDT 1993 Subject: boot proms for mv167's > Has anyone out there built their own boot proms > for Motorola MV167 using a Unisite burner? I am building my own boot proms for a Motorola MV167 using a Unisite burner. Our host is a HP 700 unix system. I am copying the bootrom.hex file to a PC disk directly with no file conversion. Our PC is linked to the unix server with NFS. I am then using the Motorola S3 record selection (95 on our Unisite) to read the file from disk. In you need more information I will try to help. _________________________________________________________________ Vic Potter Picker International vlp@mr.picker.com 5500 Avion Park Dr. (216) 473-5734 Heighland Heights, Oh 44143 _________________________________________________________________ From interf!atlas!io!vhopson@uunet.uu.net Fri Jun 25 16:44:01 1993 From: interf!atlas!io!vhopson@uunet.uu.net (Vince Hopson) Date: Fri Jun 25 16:44:14 PDT 1993 Subject: Ethernet and surge supression Hi, We are currently involved in a project to build an "out-door" network of thick ethernet cable (running ethernet of course). The cabling and connections will, of course be protected but the runs are rather long. This brings up the possibility of a variety of surge/spike effects. If anyone has any information on surge supression on ethernet thick cabling, or experience with a network of this type, I would appreciate any input you may have. Thanks in advance... ...vince ------------------------------------------------------------------------------- Vincent M. Hopson vhopson@interf.com Interferometrics Inc. voice: (202) 653-0945 8150 Leesburg Pike fax: (202) 653-1848 14th Floor Vienna VA 22182 ------------------------------------------------------------------------------- From daemon@vxw.ee.lbl.gov Sat Jun 26 04:00:48 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Jun 26 04:00:56 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jun 26 04:00:40 PDT 1993 Subject: International Software ------------------------------------------------------- Newsgroups: comp.os.v,comp.os.vms,comp.os.vxworks,comp.os.xinu Subject: International Software Date: Fri, 25 Jun 1993 12:18:25 GMT From: jbowyer@cis.vutbr.cz (Bowyer Jeff) Organization: Technical University of Brno, Czech Republic Message-ID: <1993Jun25.121825.7997@cis.vutbr.cz> Reply-To: jbowyer@cis.vutbr.cz Please share your operating system expertise with our mailing list. INSOFT-L on LISTSERV@CIS.VUTBR.CZ Internationalization of Software Discussion List Internationalization of software relates to two subjects: 1. Software that is written so a user can easily change the language of the interface; 2. Versions of software, such as Czech WordPerfect, whose interface language differs from the original product. Topics discussed on this list will include: -- Techniques for developing new software -- Techniques for converting existing software -- Internationalization tools -- Announcements of internationalized public domain software -- Announcements of foreign-language versions of commercial software -- Calls for papers -- Conference announcements -- References to documentation related to the internationalization of software This list is moderated. To subscribe to this list, send an electronic mail message to LISTSERV@CIS.VUTBR.CZ with the body containing the command: SUB INSOFT-L Yourfirstname Yourlastname Owner: Center for Computing and Information Services Technical University of Brno Udolni 19, 602 00 BRNO Czech Republic INSOFT-L-REQUEST@CIS.VUTBR.CZ --------------------------- End of New-News digest ********************** From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com Sun Jun 27 01:34:37 1993 From: leonid@rst.hellnet.org (Leonid Rosenboim) Date: Sun Jun 27 01:35:02 PDT 1993 Subject: Re: Ethernet and surge supression Common practice says that long runs of cables in the out-doors, be it Ethernet or anything else, should use Fiber. The reasons are too numerous to get into at this forum, besides surges and spikes there are possible ground potential difference, fire standards, security and maintenance costs. ----------------------------------------------------------------------- Leonid Rosenboim Voice/Fax: +972-3-72-44-98 R S T Software Industries Ltd. E-Mail: leonid@RST.HellNet.Org P.O.Box 8077, Ramat-Gan 52180, Israel WRS Distributor From daemon@vxw.ee.lbl.gov Sun Jun 27 04:01:57 1993 From: daemon@vxw.ee.lbl.gov Date: Sun Jun 27 04:02:06 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jun 27 04:01:49 PDT 1993 Subject: nfs server snapshot available ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: nfs server snapshot available Date: Sun, 27 Jun 1993 03:53:58 GMT From: hjb@netcom.com (h.j.bae) Organization: PEACEFUL STAR, Oakland, CA, Voice:(510)536-7607, Page:(510)466-9166 Message-ID: anonymous ftp: netcom.com directory: pub/hjb/nfsd/ contains a snapshot of "hack" nfsd. there is a README file there. love, hwajin - -- Email: hjb@netcom.com Office: (510)536-7607 Pager: (510)466-9166 PEACEFUL STAR PROJECT, Oakland, California UNIX, Embedded/Realtime, Networking Consultants --------------------------- End of New-News digest ********************** From csibtfr!tims@apple.com Mon Jun 28 13:47:29 1993 From: csibtfr!tims@apple.com (Tim Seaman) Date: Mon Jun 28 13:47:38 PDT 1993 Subject: Re: GPIB driver > > Submitted-by ekins@sifvsj.sinet.slb.com Fri Jun 25 05:53:09 1993 > Submitted-by: ekins@sifvsj.sinet.slb.com (Phil Ekins - Schlumberger Instruments R&D - Farnborough UK) > > I am looking into getting a GPIB (IEEE-488) connection to our system. We have > an MVME147 CPU card and considering any possible GPIB cards and associated > software. The main concern is the driver software for the GPIB card (as long as > the GPIB card fits a VME rack and reliable) as we do not want to spend time > writing drivers. > > Has anyone got (know of) a VxWorks GPIB driver for a GPIB card? We are using a THEMIS TSVME-409 Interface Card which includes a GPIB interface (The only part we are using is the GPIB). The vxWorks driver is one we purchased from APLABS which uses their aio library. They supply a set of ROMS for the THEMIS card also. APLABS provides pretty extensive documentation for their drivers. THEMIS: (Couldn't Find Any Address or Phone Number) APLABS: San Diego, Ca (619)546-8626 --tim From trc@renoir.admin.cftnet.com Mon Jun 28 15:25:37 1993 From: trc@renoir.admin.cftnet.com (Technical Resource Connection Inc) Date: Mon Jun 28 15:25:46 PDT 1993 To : VXWORKS PROGRAMMERS From: Technical Resource Connection trc@cftnet.com Subject: Positions in development environment Skills: vxworks development skills in c/c++ preferably in data switching environment From npr@jach.hawaii.edu Mon Jun 28 18:33:36 1993 From: npr@jach.hawaii.edu (Nick Rees) Date: Mon Jun 28 18:33:48 PDT 1993 Subject: Transputer link interface to VxWorks I am starting an application that needs a transputer link to be interfaced to VxWorks. I have looked at boards from INMOS, Transtech and Parsytec, but noone seems to done a VxWorks driver for them yet. Has anyone had to do this before, and so may save me reinventing the wheel? Nick Rees Joint Astronomy Centre 660 N A'ohoku Place Ph (808) 961-3756 Hilo HI 96720 Fax (808) 961-6516 From daemon@vxw.ee.lbl.gov Tue Jun 29 04:01:11 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jun 29 04:01:21 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jun 29 04:01:02 PDT 1993 Subject: Realtime OS choice.. help! Subject: 5.0 and 5.1 same cage Subject: Establishment of pSOSystem email users' group ------------------------------------------------------- Newsgroups: comp.realtime,comp.os.vxworks,comp.os.os9 Subject: Realtime OS choice.. help! Date: 28 Jun 93 14:23:22 GMT From: arium@wattle.itd.adelaide.edu.au (Arium Research Practel Sales) Organization: The University of Adelaide Keywords: A cry in the wilderness.. Message-ID: I am looking for case studies in implementing the customization requirements for a couple of real-time operating systems.. please mail me if you have had experience in porting any of the RTOS described below.. We are about to commence development of a real-time system using an in-house MC60EC000 CPU board and proprietary multi-io and serial cards. Currently we use GCC and RGDB over RS232 as our sole developmental tools. As We (I! :-) am about to step over from the world of 'simple' IO (DMA sdlc channel etc) to a complex multi-protocol (Rs232, sdlc on Rs485 and others too wierd to mention) I thought to myself.. 'Time to get a Real Operating System (tm)'. After obtaining the Net 'Everything you never wanted to know about real-time operating systems' and sending off two-dozen odd faxes I've narrowed what I *think* are my choices. Anyone out there care to comment on what I might be looking forward to in supporting any of the below on my (projected) target system? Target system: uniprocessor MC68EC000@8MHz. 128k ROM. 256k to 4M RAM DMA-driven Serial communications controller. multiple interrupt-driven serial ports multiple variegated interface boards Candidate RTOS ============== OS/9: 'Atomic OS/9' with the IO manager and OS/9 device driver support. Any comments on what the init module requires? Anyone using Fastrak for Unix and Atomic OS/9 via serial port (slip)? PDOS: PXROM porting kit to permit porting to user-defined board .. any tales to tell? Precise/MPX: These guys seem to have a _very_ sweet deal.. a few k$ and you get steaknives! (and source code). What is the supplied debugger like? Has anyone out there gotten RGDB support working for this puppy? VxWorks: Any comments on how complex the 'Board Support Package' would be for my vanilla system? Esp: How tricksy are the interrupt-handlers? Question: Any chance of getting Sun-3 based support for MicroWorks? (we aint got no steenkin sparc processor senor) If I've not put in here, please give me a clout via EMAIL. oh yeah.. for interests sake I'll post a summary of responses (if any :-) and what RTOS (if any :-) I get allowed (or ordered :-) to buy - -- keith cohen would-be software engineer arium research arium@wattle.itd.adelaide.edu.au --------------------------- Newsgroups: comp.os.vxworks Subject: 5.0 and 5.1 same cage Date: Mon, 28 Jun 93 19:57:50 GMT From: rlmarks@sun-valley.Stanford.EDU (Richard L. Marks) Organization: stanford Message-ID: <1993Jun28.195750.5670@leland.Stanford.EDU> Sender: rlmarks@sun-valley (Richard L. Marks) Hello, I have heard the rumor that there are difficulties having two processor boards in a VME cage, one running VxWorks 5.0 and the other running 5.1. Specifically, I have heard this for Motorola 167 boards. Is this true? If so, is there a fix? I have some old software, and the company won't upgrade to make it work for 5.1 until Oct. I have some new software, and it only works with 5.1. Luckily, the two pieces of software go on separate boards. I don't have the second board yet, or I would just try it. If anyone can help, I'd appreciate it. Rick Marks --------------------------- Newsgroups: comp.os.vxworks Subject: Establishment of pSOSystem email users' group Date: 28 Jun 93 15:03:00 From: raster@isi.com (Radek Aster x211) Organization: Software Components Group, Integrated Systems Inc. Message-ID: This message is to announce the existence of an pSOSystem e-mail users' group -- psosuser@isi.com. It is a unmoderated, publicly accessible (e-mail) forum for exchange of information about pSOSystem and it's components. (including but not restricted to pSOS+, pNA+, pHILE+, pROBE+, pREPC+, pX11+, pRPC+, XRAY+, drivers, etc.) Customers may subscribe (or un-subscribe) to the group by sending e-mail to psosuser-request@isi.com. The e-mail should include a request for group subscription (or-un-subscription). Questions, advice, answers, and generally useful information sent via e-mail to psosuser@isi.com will be forwarded to all subscribers. Direct customer access to the ISI technical support group remains available via e-mail.(scg_suprt@isi.com.) NOTE : Currently the user's group is implemented as a email alias, but will be updated to a LISTSERVer. - -- - ------------------------------------------------------------------------------- | ,__o !___ _-\_<, Radek Aster email : raster@isi.com <(*)>--(*)/'(*) ISI/SCG Technical Support or raster@cs.uoregon.edu tel : (408) 980-1500 x 211 @ ___ Integrated Systems Inc. fax : (408) 980-0400 _ \ _\ 3260 Jay St. (*)-^+-(*) Santa Clara CA 95054-3309 - ------------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From jch@leonard.sodima.fr Wed Jun 30 02:10:02 1993 From: jch@leonard.sodima.fr (Jean-Claude HEUDIN) Date: Wed Jun 30 02:10:13 PDT 1993 Subject: AI features on VxWorks Hi Roy, I recently read a mail from you requesting some AI features on VxWorks... We sell a product called KOS (Knowledge-based Operating System). This software runs on most Unix platforms and VxWorks. KOS is a distributed realtime system which includes object-oriented programming, multiple inference engines and many other useful things. The syntax is based on SCHEME, that is a "pure" and elegant lisp language. KOS enables to call directly within that language realtime primitives, socket connections or any user-defined C or KOS procedure. Unfortunately, KOS is a software product, not a freeware... However, you can buy it at a small price if you are from a university. Many customer already use KOS in Europe : Dassault Aviation, Sextant Avionics, Aerospatiale, BP Research, etc, for distributed realtime applications. If you are interested by KOS, you can call me at the following address : Dr. Jean-Claude HEUDIN SODIMA S.A. Z.A. COURTABOEUF 18, Avenue du QUEBEC 91961 LES ULIS CEDEX - FRANCE Phone: (33.1) 69.07.32.18 Fax: (33.1) 69.07.66.58 mail: jch@sodima.sodima.fr Best regards. Jean-Claude. From daemon@vxw.ee.lbl.gov Wed Jun 30 04:01:15 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jun 30 04:01:24 PDT 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jun 30 04:01:07 PDT 1993 Subject: vxWks on 1Mb MVME162? Subject: Re: GPIB driver ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: vxWks on 1Mb MVME162? Date: Tue, 29 Jun 93 13:36:35 GMT From: mcdowell@exlogcorp.exlog.com (Steve McDowell) Organization: Baker Hughes INTEQ, Inc. Message-ID: <1993Jun29.133635.23932@exlog.com> Sender: mcdowell@exlog.com (Steve McDowell) Does anyone know if it's possible to put vxWorks (5.1) on a Motorola '162 with only 1Mbyte of RAM? WRS "doesn't know yet".... Thanks in advance. - -- Opinions are mine, not my employers --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GPIB driver Date: Wed, 30 Jun 1993 01:17:41 GMT From: claus@pepiiu1.SLAC.Stanford.EDU (Richard Claus) Organization: Stanford Linear Accelerator Center Message-ID: References: <9306251840.AA12394@csibtfr.condorew> Sender: news@unixhub.SLAC.Stanford.EDU >In article <9306251840.AA12394@csibtfr.condorew> csibtfr!tims@apple.com (Tim Seaman) writes: > > > > Submitted-by ekins@sifvsj.sinet.slb.com Fri Jun 25 05:53:09 1993 > > Submitted-by: ekins@sifvsj.sinet.slb.com (Phil Ekins - Schlumberger Instruments R&D - Farnborough UK) > > > > I am looking into getting a GPIB (IEEE-488) connection to our system. We have > > an MVME147 CPU card and considering any possible GPIB cards and associated > > software. The main concern is the driver software for the GPIB card (as long as > > the GPIB card fits a VME rack and reliable) as we do not want to spend time > > writing drivers. > > > > Has anyone got (know of) a VxWorks GPIB driver for a GPIB card? > > > We are using a THEMIS TSVME-409 Interface Card which includes a GPIB > interface (The only part we are using is the GPIB). The vxWorks driver > is one we purchased from APLABS which uses their aio library. They supply > a set of ROMS for the THEMIS card also. APLABS provides pretty extensive > documentation for their drivers. > > THEMIS: (Couldn't Find Any Address or Phone Number) > > > APLABS: San Diego, Ca (619)546-8626 > > --tim National Instruments ((800) 433-3488, Austin, Tx) has a bunch of GPIB products for VME and VXI processors running VxWorks. I am using their VXIcpu-030 and while I have no interest in the GPIB part of it, the rest of the board and software seems to work fine. Their GPIB-1014 series VME boards might do the trick for you. Themis can be reached at (510) 734-0870 (Oakland(?), CA). Cheers, Ric --------------------------- End of New-News digest ********************** From thor@thor.atd.ucar.edu Wed Jun 30 23:00:30 1993 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Wed Jun 30 23:00:40 PDT 1993 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 2098 -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 37126 Jun 12 1992 ansilib01 -rw-r--r-- 1 thor 18913 Jun 12 1992 ansilib02 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor 19170 Apr 1 10:21 dirlib01 -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 2453 Mar 10 13:41 gcc+68040 -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 10281 Apr 1 10:25 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 1991 libx11 -> libX11 -rw-r--r-- 1 thor 3515 Mar 16 14:32 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 41667 Feb 5 1992 ntpvx01 -rw-r--r-- 1 thor 38524 Feb 5 1992 ntpvx02 -rw-r--r-- 1 thor 41997 Feb 5 1992 ntpvx03 -rw-r--r-- 1 thor 39218 Feb 5 1992 ntpvx04 -rw-r--r-- 1 thor 39625 Feb 5 1992 ntpvx05 -rw-r--r-- 1 thor 28741 Feb 5 1992 ntpvx06 -rw-r--r-- 1 thor 32516 Feb 5 1992 ntpvx07 -rw-r--r-- 1 thor 37119 Feb 5 1992 ntpvx08 -rw-r--r-- 1 thor 41643 Feb 5 1992 ntpvx09 -rw-r--r-- 1 thor 19593 Oct 27 1992 ping01 -rw-r--r-- 1 thor 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 1991 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 1991 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 41196 Oct 16 1992 stevie01 -rw-r--r-- 1 thor 35279 Oct 16 1992 stevie02 -rw-r--r-- 1 thor 35278 Oct 16 1992 stevie03 -rw-r--r-- 1 thor 35012 Oct 16 1992 stevie04 -rw-r--r-- 1 thor 34502 Oct 16 1992 stevie05 -rw-r--r-- 1 thor 37476 Oct 16 1992 stevie06 -rw-r--r-- 1 thor 30073 Oct 16 1992 stevie07 -rw-r--r-- 1 thor 31562 Oct 16 1992 stevie08 -rw-r--r-- 1 thor 37360 Oct 16 1992 stevie09 -rw-r--r-- 1 thor 20662 Oct 16 1992 stevie10 -rw-r--r-- 1 thor 25717 Oct 16 1992 stevie11 -rw-r--r-- 1 thor 28075 Oct 16 1992 stevie12 -rw-r--r-- 1 thor 31852 Oct 16 1992 stevie13 -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 19912 Aug 27 1992 tp41.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 5608 Dec 2 1992 veclist01 -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor 8601 Mar 16 14:21 vx_cplusplus -rw-r--r-- 1 thor 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 1992 wdog_class -rw-r--r-- 1 thor 5179 Apr 1 10:24 xxx Unix sources: total 81 -rw-r--r-- 1 thor 1074 Mar 26 10:07 index drwxr-xr-x 2 thor 512 Mar 26 10:03 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar