From bemills@sandia.gov Fri Nov 1 08:25:09 1996 From: bemills@sandia.gov (Barbara Mills) Date: Fri Nov 1 08:25:12 PST 1996 Subject: anyone at Sandia have an MV167 to lend? Hi. I'm in need of an MV167 for about a month. Does anyone at Sandia National Labs have one I could use? Thanks in advance. _______________________________________________________ | | | Barbara E. Mills Voice (505) 845-9826 | | bemills@sandia.gov Fax (505) 844-2925 | |_____________________________________________________| From tothl@ascs.aro.allied.com Fri Nov 1 09:39:37 1996 From: tothl@ascs.aro.allied.com (Lou Toth) Date: Fri Nov 1 09:39:55 PST 1996 Subject: unsubscribe unsubscribe From intrepid!minidds@uunet.uu.net Fri Nov 1 10:30:02 1996 From: intrepid!minidds@uunet.uu.net (Lee Kappel) Date: Fri Nov 1 10:30:05 PST 1996 Subject: PowerPC Interrupt Levels We're using Tornado/VxWorks 5.3 with an mv1604 board support package. What are the valid levels for intLockLevelSet? Also, what is the format of the key returned by intLock? We are seeing intLock return 0xB030 or 0x9030 Kyle hoyt@eci-cec.com minidds@eci-cec.com From daemon@csg.lbl.gov Sat Nov 2 04:00:32 1996 From: daemon@csg.lbl.gov Date: Sat Nov 2 04:00:36 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Nov 2 04:00:25 PST 1996 Subject: Re: Tornado on WinNT Subject: Re: Kbhit Subject: PPP and Tornado Subject: PPP and VxWorks Subject: Using Tornado with emacs Subject: Re: Using Tornado with emacs Subject: odd behaviour of slow disk drive... Subject: Re: Video driver on VxWorks Subject: Are you happy with Vx Works and Wind River Subject: Re: Routing question Subject: Clarification Of Question - Re: Non Terminating TCP/IP Sockets Subject: Seeking XDR functions/types Subject: Re: Seeking XDR functions/types Subject: BSP for Arnewsh SBC360 board Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado on WinNT Date: Thu, 31 Oct 1996 10:28:48 -0800 From: Frank Weissig Organization: Teleport - Portland's Public Access (503) 220-1016 Message-ID: <3278EFE0.3999@teleport.com> References: <557mjj$bti@cobra.Minn.Net> Reply-To: faw@teleport.com Dave Hansen wrote: > > Apologies if this appears multiple times. My news server has been > "throttling" and I don't think my previous attempts have made it > out... > > We will be beginning an evaluation of VxWorks and Tornado for a new > product we're starting work on. My new computer will arrive with NT > 4.0 installed. The Tornado docs specify NT 3.51, and previous > messages in this group have indicated that Wind River is less than > completely supportive of 4.0. So I have a 3.51 CD and the latest > service pack downloaded, and I'm all ready to revert once the system > arrives. You shouldn't have to do that. I've been using Tornado 1.0 on 4.0 for a couple of months and there are no show-stoppers, just some annoyances. And for all I know, these same problems may apear under 3.51 - I don't have time to do regression testing for WRS. The three most annoying problems: 1) When you are debugging and the debugged process is running, the target server and debugger processes on the NT side suck up 100% of the CPU time. This makes performance sluggish, to say the least! 2) The GUI display of local variables is buggy. In particular, display of pointers to structures doesn't always (if ever) seem to work. However, the character-mode gdb window works fine, so you can get around it. 3) If you have files open in Tornado's pathetic little editor, you get frequent spurious message boxes telling you that the file contents have been changed. > > But the sales guy and the AE from Wind River say this is no longer > true (and in fact never was). Here's a quote from Gary Percy at WRS tech support from August 20: >>I left something out of my email yesterday. I should have stated >>that the 4.0 version of NT had not yet been validated by WRS. >>We have validated 3.51. >> >>You are right that 4.0 is now the current version of NT, but it >>is still the case that it has yet to be validated by WRS. That's the last I've ever heard on the problems I submitted. I'll let you decide how that fits with what the sales guy and AE told you... I wouldn't use lack of tech support as a reason for not going to NT 4.0. So far, I've found WRS tech support to be nearly worthless anyway. The scenario on everything I've submitted has been: 1) Send problem descrption to WRS. 2) Get response asking for small test case. 3) Spend time writing test case, send it to WRS. 4) Never hear anything again. > Their only caution was to ensure the > FTP server is installed on the Tornado host (this is not the default > for 4.0). So how about it? Has anyone recently been turned away by > Wind River support for having 4.0 installed rather than 3.51? > > Also, are there any other gems of wisdom regarding Tornado on NT out > there? I know UN*X would probably be a better option for various > reasons, but that option is not available to me. (at least I don't > have to try Win95 :) > > Thanks in advance, > > -=Dave > > I can barely speak for myself, so I surely can't speak for B-Tree > > |==================================================================| > | Dave Hansen | B-Tree Verification Systems, Inc. | > | dhansen@btree.com | 5929 Baker Rd, Suite 475 | > | (VOICE) 612-930-4112 | Minnetonka, MN 55345-5955 | > | (FAX) 612-936-2187 | | > |==================================================================| - -- Frank Weissig Senior Staff Engineer STEP Technology, Inc. frank@steptech.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Kbhit Date: Fri, 01 Nov 1996 09:24:28 -0800 From: Graham Waters Organization: TRIUMF Message-ID: <327A324C.318@triumf.ca> References: <32769BCC.23FB72DA@leland.stanford.edu> eric olsen wrote: > > Is there a kbhit function? > If so, where? > > thanks, > > I wish there was I usually do something like this : /* kbhit: returns TRUE if character waiting This functions suspends the shell and sets the console in RAW mode. The shell is restored when the keyboard is hit. */ int kbhit(int ioFd, char *byte) { int old, options, rawmode, shellId; if (!rawmode) /* do this on first call */ { options = ioctl(ioFd,FIOGETOPTIONS,0) /* current console */ old = options; options = options & ~OPT_LINE & ~OPT_ECHO; ioctl(ioFd, FIOSETOPTIONS, options) /* unbuffered mode */ shellId = taskNameToId("tShell"); taskSusp[end(shellId); /* prevent the shell intercepting characters *? rawmode = 1; return(0); } else { status = ioctl(ioFd, FIOREAD,(int)&BytesUnread); /* key hit? */ if (nBytesUnread > 0) { read(ioFd,byte,nBytesUnread); /* read the key just hit */ status = ioctl(ioFd,FIOFLUSH,0); ioctl (ioFd, FIOSETOPTIONS, old; /* restore line mode */ rawmode = 0; taskResume(shellId); return(1) /* return 1 if key hit */ } else return(0); /* return 0 if no key hit */ } } Good luck Graham. +-----------------------------------------------------------------------+ | Graham Waters, Control System Eng Internet: waters@triumf.ca | | TRIUMF --- University of British Columbia, phone: (604)-222-1047 | | Vancouver, BC, Canada Fax: (604)-222-7307 | | http://www.triumf.ca | +-----------------------------------------------------------------------+ --------------------------- Newsgroups: comp.os.vxworks Subject: PPP and Tornado Date: Thu, 31 Oct 1996 14:20:44 +0100 From: Rune Okstad Organization: Micro Design AS Message-ID: <3278A7AB.44E1@microdesign.no> Reply-To: Rune.Okstad@microdesign.no Hi! We have connected two computers via an RS485 serial line and want to use TCP/IP. With AIX on one side and VxWorks on the other, what are my options for an underlying protocol, and where do I get a suitable implementation of it. Can I use PPP? I appreciate all answers. Thanks, Rune Okstad. --------------------------- Newsgroups: comp.os.vxworks Subject: PPP and VxWorks Date: Thu, 31 Oct 1996 14:29:38 +0100 From: Rune Okstad Organization: Micro Design AS Message-ID: <3278A9C2.3843@microdesign.no> Reply-To: Rune.Okstad@microdesign.no Hi! We have connected two computers via an RS485 serial line and want to use TCP/IP. With AIX on one side and VxWorks on the other, what are my options for an underlying protocol, and where do I get a suitable implementation of it. Can I use PPP? I appreciate all answers. Thanks, Rune Okstad. --------------------------- Newsgroups: comp.os.vxworks Subject: Using Tornado with emacs Date: Thu, 31 Oct 96 14:31:52 GMT From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star Message-ID: <55b98o$jsr@idiom.com> Reply-To: chaos@idiom.com Some of you have sent email asking me how to use emacs as IDE instead of the default Tornado GUI/IDE for development. All you have to do is set up environment variables correctly. Here's an example of a batch file that will set up to use Tornado compilers in the DOS shell: - --------------------------- set CPU=CPU32 set TOOL=gnu set WIND_HOST_TYPE=x86-win32 set WIND_BASE=c:\Tornado PATH C:\Tornado\host\x86-win32\lib\gcc-lib\m68k-wrs-vxworks\2.6-95q2;c:\tornado\host\x86-win32\bin;%PATH% - ----------------------------- Furthermore, you can also edit, compile, etc. inside GNU emacs (ported to NT), if you set up things correctly. Here's my $HOME/_emacs profile: - ------------------------------- ;; ;; (c-set-style "bsd") (setq c-basic-offset 8) (setq-default c-basic-offset 8) (require 'hilit19) ;(global-set-key [f3] 'isearch-forward) (setq-default win32-pass-optional-keys-to-system t) ;(setq-default isearch-wrapped t) (setenv "CPU" "CPU32") (setenv "TOOL" "gnu") (setenv "WIND_HOST_TYPE" "x86-win32") (setenv "BOARD" "vina") (setenv "PATH" "C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2;c:\\tornado\\host\\x86-win32\\bin;C:\\WINNT35\\system32;C:\\WINNT35;c:\\bin;c:\\brief;c:\\emacs\\emacs-19.33\\bin;c:\\tornado\\host\\x86-win32\\bin;c:\\bat;c:\\usr\\bin") (setq-default auto-save-default nil) (setq my-path '("C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2" "c:\\tornado\\host\\x86-win32\\bin" "c:\\bat" )) (setq-default exec-path (append my-path exec-path)) ;(set-background-color "black") ;(set-foreground-color "grey") ;(set-cursor-color "green") ;(set-default-font "-*-Courier New-normal-r-*-*-16-120-*-*-c-*-*-ansi-") (set-default-font "-*-Courier-normal-r-*-*-16-120-*-*-c-*-*-ansi-") ;(set-default-font "-*-Lucida Console-bold-r-*-*-13-97-*-*-c-*-*-ansi-") (global-unset-key "\C-x\C-q") (global-set-key "\C-x\C-q" 'toggle-read-only) ;(global-unset-key "\C-x\C-b") ;(global-set-key "\C-x\C-b" 'electric-buffer-list) (global-unset-key "\C-x\C-e") (global-set-key "\C-x\C-e" 'compile) (global-unset-key "\M-g") (global-set-key "\M-g" 'goto-line) ;(enable-flow-control) (setenv "RCSPATH" "%d/rcs/%f") (setenv "CVSROOT" "z:/") (setenv "TZ" "PST8PDT") (setenv "LOGNAME" "hjb") (setenv "USER" "hjb") (setq-default explicit-shell-file-name "c:\\4dos\\4nt.exe") (setq-default shell-file-name "c:\\4dos\\4nt.exe") (display-time) (setq-default visible-bell t) ;(require 'cc-compat) ;; (setq gdb-command-name "gdbm68k") ; ; initial geometry ; (set-frame-height frame-initial-frame 42 ) (setq initial-frame-alist '((top . 1) (left . 120) (width . 80) (height . 42))) - -------------------------------------------- As far as the gdb goes, you can run gdbm68k either from command line or instead NT gnu emacs DOS shell window. You have to be running a target server, and specify "target wtx targetservername". http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Using Tornado with emacs Date: Thu, 31 Oct 96 14:40:40 GMT From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star Message-ID: <55b9p8$jsr@idiom.com> References: <55b98o$jsr@idiom.com> My news reader's editor inserted some bogus line-breaks into my last article which makes the examples hard to use. I'll attempt here to fix it... (such are joys of using primitive OS'es and applications on PeeCee's)... example 1 (a batch file) - ---------------------------------------------- set CPU=CPU32 set TOOL=gnu set WIND_HOST_TYPE=x86-win32 set WIND_BASE=c:\Tornado PATH C:\Tornado\host\x86-win32\lib\gcc-lib\m68k-wrs-vxworks\2.6-95q2;c:\tornado\host\x86-win32\bin;%PATH% - ------------------------------------------------ example 2 (emacs profile) - --------------------------------------------------- ;; ;; (c-set-style "bsd") (setq c-basic-offset 8) (setq-default c-basic-offset 8) (require 'hilit19) ;(global-set-key [f3] 'isearch-forward) (setq-default win32-pass-optional-keys-to-system t) ;(setq-default isearch-wrapped t) (setenv "CPU" "CPU32") (setenv "TOOL" "gnu") (setenv "WIND_HOST_TYPE" "x86-win32") (setenv "BOARD" "vina") (setenv "PATH" "C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2;c:\\tornado\\host\\x86-win32\\bin;C:\\WINNT35\\system32;C:\\WINNT35;c:\\bin;c:\\brief;c:\\emacs\\emacs-19.33\\bin;c:\\tornado\\host\\x86-win32\\bin;c:\\bat;c:\\usr\\bin") (setq-default auto-save-default nil) (setq my-path '("C:\\Tornado\\host\\x86-win32\\lib\\gcc-lib\\m68k-wrs-vxworks\\2.6-95q2" "c:\\tornado\\host\\x86-win32\\bin" "c:\\bat" )) (setq-default exec-path (append my-path exec-path)) ;(set-background-color "black") ;(set-foreground-color "grey") ;(set-cursor-color "green") ;(set-default-font "-*-Courier New-normal-r-*-*-16-120-*-*-c-*-*-ansi-") (set-default-font "-*-Courier-normal-r-*-*-16-120-*-*-c-*-*-ansi-") ;(set-default-font "-*-Lucida Console-bold-r-*-*-13-97-*-*-c-*-*-ansi-") (global-unset-key "\C-x\C-q") (global-set-key "\C-x\C-q" 'toggle-read-only) ;(global-unset-key "\C-x\C-b") ;(global-set-key "\C-x\C-b" 'electric-buffer-list) (global-unset-key "\C-x\C-e") (global-set-key "\C-x\C-e" 'compile) (global-unset-key "\M-g") (global-set-key "\M-g" 'goto-line) ;(enable-flow-control) (setenv "RCSPATH" "%d/rcs/%f") (setenv "CVSROOT" "z:/") (setenv "TZ" "PST8PDT") (setenv "LOGNAME" "hjb") (setenv "USER" "hjb") (setq-default explicit-shell-file-name "c:\\4dos\\4nt.exe") (setq-default shell-file-name "c:\\4dos\\4nt.exe") (display-time) (setq-default visible-bell t) ;(require 'cc-compat) ;; (setq gdb-command-name "gdbm68k") ; ; initial geometry ; (set-frame-height frame-initial-frame 42 ) (setq initial-frame-alist '((top . 1) (left . 120) (width . 80) (height . 42))) - -------------------------------------------- http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: odd behaviour of slow disk drive... Date: Thu, 31 Oct 1996 23:18:38 +0000 From: rms Organization: X Message-ID: Reply-To: richard@carapace.demon.co.uk Dear Sirs We make a board with video ram. Only 16 bit or higher accesses are permitted. Our platform is essentially a PC. We now make a reduced specification version, for which our buyer found a supply of inexpensive low performance low capacity disk drives. The drives work perfectly EXCEPT when writing to the video store. ( by which I mean that I point a read() command at the video ram and let vxWorks write into the ram directly. ) Needless to say only even numbers of bytes are ever requested. My hardware man says that 8 bit accesses must be being created. To test this I tried reading into a traditional RAM buffer and then writing to the video RAM with an INT16* to guarantee 16 bit access. When I do this there is no problem. Allthouh this SEEMS to have fixed the problem I remain woried that under load conditions my fully fledged systems may show the same problem. I am loath to buffer everything on grounds of speed. I considered that some timeing, critical section or shared access problem was being exaserbated(sp?) by the slow drive but I doubt that is the case as the disturbances are in fixed locations. How can disk speed affect the read() mechanism? Yours faithfully 'BAFFLED' Responses by E-Mail please to richard.simmons@oxtel.com - -- rms --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Video driver on VxWorks Date: Thu, 31 Oct 1996 23:23:46 +0000 From: rms Organization: X Message-ID: References: <326F11EB.47BD@ozy.dec.com> <326F88C9.14A1@finley.com> <554iuv$lep@isoit109.bbn.hp.com> Reply-To: richard@carapace.demon.co.uk In article <554iuv$lep@isoit109.bbn.hp.com>, Juergen Sang writes >John Finley (john@finley.com) wrote: >: Rami Smair wrote: > >: > I'm likely to be writing video driver on VxWorks, I need any >: > >: > Any help would be appreciated. > >: If you providing more specific information, it's more likely >: someone will pop up and say "I've done that already". > >In fact, there is a commercially Windowing System (MetaGrafix) >available for at least DOS, pSOS+/386 and VX-Works 386. It >supports nice features as windowing, 16 bit fonts, all drawing >functions you expect (incl. Beziers etc. pp.). We have used >it in our latest products, and were quite pleased. > Do you have an E-Mial address for MetaGraphics? Thanks Richard. - -- rms --------------------------- Newsgroups: comp.os.vxworks Subject: Are you happy with Vx Works and Wind River Date: Thu, 31 Oct 1996 17:04:25 -0800 From: Jim Jaskol Organization: The Walt Disney Company Message-ID: <32794C99.67F9@corp.disney.com> We currently use pSOS, and are thinking about using VxWorks. I would like advice from current VxWorks users--especially those who have used pSOS. How is the development environment? How good is the support from Wind River? Are there lots of board support packages? Are the board support packages of high quality? And please don't limit your comments to the above questions. If there's something I should know before jumping in, let me know. Thanks, Jim Jaskol --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Routing question Date: Thu, 31 Oct 96 19:49:36 GMT From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star Message-ID: <55brsd$58d@idiom.com> References: <01bbc7f1$42930e00$4c79d9ce@daysbetween> To disable IP forwarding, turn off global variable ipforwarding. For example, from shell - -> ipforwarding=0 http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Clarification Of Question - Re: Non Terminating TCP/IP Sockets Date: Fri, 01 Nov 1996 08:23:38 -0500 From: Ray Gilbert Organization: General Instruments Communications Division Message-ID: <3279F9DA.711@gic.gi.com> References: <327503B6.7860@gic.gi.com> <32779160.3AF8@peacefulstar.oakland.ca.us> Reply-To: rgilbet@gic.gi.com When the SCO client is shutdown, the shutdown code does a kill -9 on all the tasks communicating with the VxWorks based server (ugly huh). Now, it seems that on some level, the client system "cleans up" the socket connections to the server, except for 2 or 3 that just linger. The fioRead call gets an error for those sockets that are "cleaned up" and everything is OK, but I am still stuck with the lingering connections. That is the part that I cannot figure out. Why would some connections close fine, and others just vanish? Ray H.J. Bae wrote: > > It depends on what you mean when you "shutdown" the clients. > If you properly shutdown client applications using shutdown() > followed by close() socket calls, the server side should > receive a TCP FIN, and read() on server socket will return > with error, which will tell you when client goes away. > If you just power down (withoug doing graceful shutdown of > Unix OS) on the client side, server won't know anything > about client going away. > -- > http://peacefulstar.oakland.ca.us > mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Seeking XDR functions/types Date: 31 Oct 1996 22:25:35 GMT From: scott@tcville.es.hac.com Organization: Hughes Aircraft Message-ID: <55b90v$k93@hacgate2.hac.com> Reply-To: scott@tcville.es.hac.com I am seeking some XDR functions/source to allow data xport (socket based) between a VxWorks target and a Unix host (AIX & Solaris). Thanks for any/all assistance, E. Scott Channell - --- Hughes Aircraft Co. voice: (310) 616-1059 Image and Signal Processing Lab addr: scott@tcville.es.hac.com PO Box 902, EO/E01/A172, El Segundo, Ca. 90245 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Seeking XDR functions/types Date: 1 Nov 1996 18:50:16 -0800 From: kla@leland.Stanford.EDU (Earl Mitchell) Organization: Stanford University, CA 94305, USA Message-ID: <55ect8$g3c@elaine23.Stanford.EDU> References: <55b90v$k93@hacgate2.hac.com> In article <55b90v$k93@hacgate2.hac.com>, wrote: >I am seeking some XDR functions/source to allow >data xport (socket based) between a VxWorks target >and a Unix host (AIX & Solaris). > >Thanks for any/all assistance, > E. Scott Channell > >--- >Hughes Aircraft Co. voice: (310) 616-1059 >Image and Signal Processing Lab addr: scott@tcville.es.hac.com >PO Box 902, EO/E01/A172, El Segundo, Ca. 90245 > xdr functions should be built into the kernel image especially if rpcLib is included (i.e. RPC uses XDR for data transmission to heterogeneous hosts. To check try lkup from shell - -> lkup "xdr" Should see functions like xdr_int xdr_long xdr_short ... See SunOS documentation for more info on how to use XDR functions. Here's some sample code I threw together to give you an idea how to use XDR with sockets. void sendXdrMsg(char *msg, BOOL (*xdrfcn)(), int bufferLen) { XDR out ; char *buffer ; /* Create buffer to hold XDR encoded msg and tie to an XDR out stream */ buffer = malloc(bufferLen) ; xdrmem_create(&out, buffer, bufferLen, XDR_ENCODE); /* Encode msg in XDR */ if ( (*xdrfcn)( &out, msg)) { /* send XDR encoded msg over socket */ send(socketFd, buffer, bufferLen, 0) ; } /* destroy XDR out stream and buffer */ xdr_destroy(&out); free(buffer); } typedef struct Foo { int a ; long b ; } Foo ; /* user defined xdr function for Foo */ BOOL xdr_Foo(XDR *xdrs, Foo *pfoo) { return( xdr_int(xdrs, &(pfoo->a)) && xdr_long(xdrs, &(pfoo->b)) ) ; } sender() { int msg1 ; Foo msg2 ; sendXdrMsg(&msg1, xdr_int, sizeof(msg1)) ; sendXdrMsg(&msg2, xdr_Foo, sizeof(msg2)) ; } You should be able to figure out the rest using this simple example. The receiver would use a function recvXdrMsg() which would use XDR_DECODE for xdr_memcreate(), and it call xdrfcn() after doing a recv() for socket. To really do messages your xdr_Foo() should exploit xdr_union and a type field. --------------------------- Newsgroups: comp.os.vxworks Subject: BSP for Arnewsh SBC360 board Date: 1 Nov 1996 11:21:13 -0800 From: Christopher J. Netter Organization: Lucent Technologies Message-ID: <55dij9$hmu@lex.zippo.com> Greetings, Has anyone put together a BSP for the Arnewsh SBC360. This is a VME board from Arnewsh (Fort Collins,CO) with a Motorola 68360 on it. We have a half dozen around and it seems like a waste to not make use of them. Thanks, Chris Netter Lucent Technologies cnetter@lucent.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Sat, 02 Nov 1996 06:12:15 GMT From: sgaeke@cris.com (Steve Gaeke) Organization: Concentric Internet Services Message-ID: <55eecn$oj7@herald.concentric.net> References: <32794C99.67F9@corp.disney.com> Jim Jaskol wrote: We have not been real pleased with the Tornado port to x86. There was a lot of good salesmanship up front but after we jumped into it, we found almost everything was still pretty buggy or promises were made and not kept. I wish now we had gone with pSOS. Why are you thinking of dropping pSOS and what platform are you developing for? sgaeke@cris.com ///////////////////////////////////////////////////////////// My opinions are my own and do not reflect those of my employer. ///////////////////////////////////////////////////////////// >We currently use pSOS, and are thinking about using VxWorks. I would >like advice from current VxWorks users--especially those who have used >pSOS. > How is the development environment? > How good is the support from Wind River? > Are there lots of board support packages? > Are the board support packages of high quality? >And please don't limit your comments to the above questions. If there's >something I should know before jumping in, let me know. >Thanks, >Jim Jaskol --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 1 Nov 1996 20:45:30 -0800 From: ralerche@lindy.stanford.edu (Robert A. Lerche) Organization: MSB Associates Message-ID: <55ejla$9gm@lindy.stanford.edu> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> I just selected VxWorks / Tornado for a client developing a network access device. So far I'm very satisfied with the support I've gotten, though it has been a bit of a struggle since we are using the 68EN302 as our processor and the board support package for it just became available. The BSP is for the Motorola FADS302 board; I had to make a few small changes to get it to work in our target. I have to say that the first-line technical support is not as knowledgeable as I might wish, but they are courteous and will escalate a problem after they understand that they are unable to solve it. I think they're a little bit swamped, too. I think the tools work best if you install the target server on a Unix platform, rather than trying to use PC's running Win95 as target servers. Maybe Windows NT works, but Win95 doesn't really work if you try to use a third system as the client. --------------------------- End of New-News digest ********************** From adler@bnlku5.phy.bnl.gov Sat Nov 2 08:35:52 1996 From: "Steve Adler" Date: Sat Nov 2 08:35:55 PST 1996 Subject: This is a test.... This is a test. From adler@bnlku5.phy.bnl.gov Sat Nov 2 12:45:41 1996 From: "Steve Adler" Date: Sat Nov 2 12:45:43 PST 1996 Subject: vxworks and linux I submitted this posting before and got no answer. I don't know if its because no one cares or if my posting didn't go through. In any case, I won't post this again. -------------VxWorks on Linux Survey------------------- Please fill out and return to adler@bnlku5.phy.bnl.gov 1) I would be interested in a release of VxWorks/Tornado which hosts off a PC running Linux. YES NO If you answered yes the question 1, go to question 2 else go to question 5. 2) Knowledge of Linux: Check the item which pertains to you. I'm a Linux guru and have no trouble maintaining Linux on my PC I'm a Linux novice and need help maintaining my system I've heard of Linux but have never used it or have talked to anyone who has or is using it. 3) Linux distribution: Currently I use or maintain PC's with the following Linux distributions (check more than one if you use or maintain PC's with more than one distribution) Redhat Debian Slakware Other specify here -> None 4) Wind River support for Linux: Check the item which describes the level of support you expect from Wind River Systems if they released the Linux host platform. a) I only need support for Tornado and other VxWorks related software products. b) Item a) and help with generic Unix questions regarding my writing and debugging VxWorks software. c) Item a), b) and help maintaining my Linux system. Stop here: Thanks for filling out the survey. 5) Non Linux interest: Check the item which best describes your attitude towards Linux and or VxWorks on a PC platform I run VxWorks off a Unix workstation (Sun, HP, SGI etc.) and have no need to use Linux. Linux is public domain software and therefore too unreliable to use in my work developing VxWorks code. I'll never be able to get the support I need. I don't know what Linux is, so I'm not interested. I run Windows 95 on my PC and VxWorks support for Windows 95 suits me just fine. I run Windows NT on my PC and VxWorks support for Windows NT suits me just fine. Stop here: Thank you for filling out the survey. Steve Adler. From wbeebe@gate.net Sun Nov 3 16:45:23 1996 From: William Beebe Date: Sun Nov 3 16:45:25 PST 1996 Subject: unsubscribe unsubscribe From tmorris@me.umn.edu Mon Nov 4 07:55:03 1996 From: "Ted Morris" Date: Mon Nov 4 07:55:06 PST 1996 Subject: Re: vxworks and linux > > Submitted-by adler@bnlku5.phy.bnl.gov Sat Nov 2 12:45:41 1996 > Submitted-by: "Steve Adler" > > I submitted this posting before and got no answer. I don't > know if its because no one cares or if my posting didn't go > through. In any case, I won't post this again. > > -------------VxWorks on Linux Survey------------------- > > Please fill out and return to adler@bnlku5.phy.bnl.gov > > 1) I would be interested in a release of VxWorks/Tornado which > hosts off a PC running Linux. > ===> YES > NO > > If you answered yes the question 1, go to question 2 else > go to question 5. > > 2) Knowledge of Linux: Check the item which pertains to you. > > I'm a Linux guru and have no trouble maintaining Linux on my > PC > ===> I'm a Linux novice and need help maintaining my system > > I've heard of Linux but have never used it or have talked to > anyone who has or is using it. > > 3) Linux distribution: Currently I use or maintain PC's with the > following Linux distributions (check more than one if you use > or maintain PC's with more than one distribution) > > Redhat > Debian > Slakware ===> Other specify here -> MatLAB, massive sortie of pub. domain software > None > > 4) Wind River support for Linux: Check the item which describes > the level of support you expect from Wind River Systems if > they released the Linux host platform. > ===> a) I only need support for Tornado and other VxWorks related software > products. > > b) Item a) and help with generic Unix questions regarding my writing > and debugging VxWorks software. > > c) Item a), b) and help maintaining my Linux system. > > Stop here: > > Thanks for filling out the survey. > > thank YOU, no problem! Ted > > _/_/_/ _/_/ _/_/ _/_/ _/_/_/ _/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/ ------------------------------------------------------------------------------ Ted Morris tmorris@me.umn.edu 612-625-3520 Center For Advanced Manufacturing Design And Control 612-625-9881 Institute of Technology FAX: 612-625-8884 University of Minnesota 111 Church St. S.E. (Rm 125) Mpls MN 55455 "A lie can travel halfway around the world before the truth can get its shoes on." [Actually, NOT Mark Twain] ------------------------------------------------------------------------------ From daemon@csg.lbl.gov Tue Nov 5 04:00:40 1996 From: daemon@csg.lbl.gov Date: Tue Nov 5 04:00:43 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Nov 5 04:00:37 PST 1996 Subject: Re: Tcl/Tk Subject: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board Subject: Re: Are you happy with Vx Works and Wind River Subject: Anyone using ZBufs? Subject: Serial Port Programming in VM30 Subject: Re: Virtual to Physical address conversion. Subject: Re: Problem with free() Subject: VME interrupt levels & vectors Subject: Re: pc-486 serial ports 3+4 Subject: Re: Floating Point From ROM Subject: web server on vxw? Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Video driver on VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tcl/Tk Date: Fri, 01 Nov 1996 11:06:49 -0700 From: "Loay (Louie) Abu-Husein" Organization: Color LaserJet and Consumable Division, R&D Labs Message-ID: <327A3C39.20EF@boi.hp.com> References: <3275C320.893@llnl.gov> I am trying to port Tcl To VxWorks but I ran into problems with the following system calls that Tcl have but not VxWorks: 1. System calls used to build pipes: fcntl(), pipe(), dup2(), fork() 2. System calls used for host and user identification such as: getuid(), getpwnam() 3. Also how to handel environment variables such as the use of the char **environ Global variable. I have written stubs and disabled functionality temporarly until a more permenant solution is found. Does anyone know the answer to 1 and 2 in perticular. Thanks. - -- _/ _/ _/_/_/ Loay (Louie) Abu-Husein _/ _/ _/ _/ Intranet: http://hpbs4896.boi.hp.com/ _/_/_/ _/_/_/ Internet: http://www.boi.hp.com/ _/ _/ _/ EMail: mailto:loay@hpbs4896.boi.hp.com _/ _/ _/ --------------------------- Newsgroups: comp.os.vxworks Subject: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board Date: Thu, 31 Oct 1996 20:03:25 -0500 From: "Thomas A. Bond" Organization: Realtime Software Solutions, Inc. Message-ID: <32794C5D.102F27DC@realtime1.com> Hello, Is there a protocol available for downloading code to a VxWork DEC apha board from a WinNT Intel/DEC based PC? The startup code would be downloaded from the WinNT machine to the Vxworks DEC aplha board via some boot loader code using some type of protocol. Is there a version of tftp available for WinNT or any other viable protocol to accomplish this task? Thanks! Tom - -- +=============================================================+ || || || What the world needs today ! || || || || // || || // // ///// // // // // || || // // // // // // /// || || ///// // // // ///// // // || || || || The choice of a smarter generation ! || || || +=============================================================+ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Mon, 04 Nov 1996 12:59:04 -0500 From: rypma@waterloo.hp.com (Ted Rypma) Organization: HP Panacom Division Message-ID: References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> In article , gerlach@netcom.com (Matthew H. Gerlach) wrote: >Interesting, my experience with GNU tools in general has been great, and >Wind River's use of the GNU tools, IMHO is a compelling reason to use >VxWorks. I second Matthew's comments. It is in many ways _because_ of the Gnu tools that we were able to avoid problems and move ahead, sometimes in spite of Wind River. The Gnu tools made us independent of Wind River's ability to support tools. We put tgdb (tcl front end to gdb) in place of Wind Rivers version and are happier with it. We have a choice in which vendor (or ourselves, for that matter) does tool support. - -- - ----- Ted Rypma, Waterloo, Ontario, Canada === rypma@waterloo.hp.com --------------------------- Newsgroups: comp.os.vxworks Subject: Anyone using ZBufs? Date: Tue, 29 Oct 1996 04:57:12 GMT From: jay@fallcreek.com (Jay Slupesky) Organization: Fall Creek Systems, Inc. Message-ID: <5543lo$jg7@clark.zippo.com> Reply-To: jay@fallcreek.com Hello, Has anyone tried using ZBufs to improve the performance of socket-based programs? I have a simple routine that reads data from one socket and writes it to another. When I use ZBufs, the program actually runs much SLOWER than when I use read() and write(). Using ZBufs should make the program faster, not slower, since it eliminates two data copies. Anyone have any thougnts? Jay Slupesky Fall Creek Systems, Inc. Pleasanton, California, USA jay@fallcreek.com http://users.aol.com/jslupesky "Professional Internet user on closed circuit. Do not attempt." --------------------------- Newsgroups: comp.os.vxworks Subject: Serial Port Programming in VM30 Date: Mon, 04 Nov 1996 18:10:15 +0900 From: Jun-pyo Hong Organization: BISE Lab., Inha Univ. Message-ID: <327DB2F7.21DF@inhavision.inha.ac.kr> I am using VxWorks(V5.1.1) on the VM30. Working Computer and OS is Workstation and SUN-OS. VM30 board is mounted VME bus. I am trying to program two serial ports on VM30. If anyone have been that, please help me. Thanks to read. J.P.Hong --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Virtual to Physical address conversion. Date: 4 Nov 1996 20:44:57 GMT From: friedl@cher.heurikon.com (Ted Friedl) Organization: Heurikon Corporation Message-ID: <55lkk9$7rp@badger.heurikon.com> References: <327E1257.65792670@ccii.co.za> <55l8r1$hbc@news.sei.cmu.edu> In article <55l8r1$hbc@news.sei.cmu.edu>, Theodore Marz wrote: > >In article <327E1257.65792670@ccii.co.za>, Casey Crellin writes: > This is speaking from a Motorola 68K perspective (mvme-167). [snip] For code portability between different target platforms, it is probably best to use the macros supplied in cacheLib.h. See CACHE_DMA_VIRT_TO_PHYS() and CACHE_DMA_PHYS_TO_VIRT(). Ted Friedl Senior Software Engineer Heurikon Corporation Madison, WI --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Problem with free() Date: Sun, 03 Nov 1996 04:26:49 GMT From: brucew@phoenix.net (Bruce) Organization: BranPaul Systems Message-ID: <55h6v8$e8c$1@uhura.phoenix.net> References: <51mket$t5n@mark.ucdavis.edu> In comp.os.vxworks saquresh@taco.engr.ucdavis.edu (Shehrzad Ahmed Qureshi) wrote: > My problem is when I try to free these pointers. I will make a call >such as > free ((char *) &rec->priority[1]) and will get an error like this it should be free( rec->priority[1]); drop the address operator as it is already a pointer. --------------------------- Newsgroups: comp.os.vxworks Subject: VME interrupt levels & vectors Date: 25 Oct 1996 08:59:03 GMT From: "Ron Gross" Organization: Precision Data Services Message-ID: <01bbc25a$6bec15e0$f371e8c7@rgross.venus.star.net> We have a MVME-133XT (68020) running 4.0.2VxWorks (working on moving to 5.2) and have installed a new card in out VME rack (DeltaTau PMAC-VME). This card provides three interrupt vectors on one interrupt level, depending on what the interrupt was for. I have not setup interrupts on VxWorks before, and the docs (4.0.2 and 5.2) do not seem to talk about levels. 1. How do I tell VxWorks about the interrupt level (3 or 4 can be used)? Does VxWorks just trap all level interrupts and automatically get the vector number and use that to 'vector' to the selected routine? 2. Do I use a seperate routine to handle each interrupt vector? - -- Ron Gross Precision Data Services --------------------------- Newsgroups: comp.os.vxworks Subject: Re: pc-486 serial ports 3+4 Date: 24 Oct 1996 14:03:57 -0700 From: dzhu@enlil.jpl.nasa.gov (David Zhu) Organization: jpl Message-ID: References: <326B827B.4D87@mail.imech.uni-duisburg.de> Sender: dzhu@enlil.jpl.nasa.gov In article <326B827B.4D87@mail.imech.uni-duisburg.de> Stefan Vogel writes: > > > Hi, > > I would like to use the serial ports 3 and 4 > on a pc-board. Has anyone experience in this > Subject?? > > Stefan > > > > We've installed a quad serial board on a PC104 system. Since it is only a 8-bit board, it cannot use interrupt above 7. But it supports shared interrupt; so we rewrote the interrupt handler. If shortage of interrupt lines are not a problem, you only need to modify pc.h and create the devices after bootup. David - -- - ---------------------------------------------------------------------- David Q. Zhu Jet Propulsion Laboratory e-mail: David.Zhu@jpl.nasa.gov MS 198-235 phone: 818-354-9058 (office) 4800 Oak Grove Dr. Pasadena, CA 91109 - ---------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Floating Point From ROM Date: Tue, 05 Nov 1996 02:48:07 GMT From: jdeffner@west.net (john deffner) Organization: West.Net Communications Message-ID: <55m9gm$hib@daffy.sb.west.net> References: <01bbc9b4$6e2d9d40$dc4698c2@prsf56re.prestel.co.uk> On 3 Nov 1996 18:26:01 GMT, "Robin Smith" wrote: >We are using VxWorks 5.1.1 under Rational Ada and are having problems with >floating point when blowing an app into ROM. It works fine when built as a >RAM image but the same floating point call (any of sin/cos/sqrt) causes the >task to terminate. >Can any body help? > >Thanks >Robin Well, this may not be applicable, but it sure was puzzling when I was working with it - We're running 5.3 on a 386ex board that is very similar to the intel eval board except for some chip selects and memory bus widths. The system crashed on takeoff on our board unless we disabled the floating point. It turned out vxWorks was probing for the coprocessor using a routine called fppProbeSup. Neither the eval board (which worked) or our board (which doesn't) has a coprocessor, but fppProbeSup returns a 'not found' on the eval board and hangs the bus on our board. There's something very bad about our board and It may be the bus width difference between the flash on the eval board and on ours. Kind of a hard problem to troubleshoot. I ended up hacking the hex code to remove the part of fppProbeSup that probes for the coprocessor (replaced it with nops) so it just returns 'not found'. --------------------------- Newsgroups: comp.os.vxworks Subject: web server on vxw? Date: Tue, 05 Nov 1996 02:57:11 GMT From: jdeffner@west.net (john deffner) Organization: West.Net Communications Message-ID: <55ma1l$hlh@daffy.sb.west.net> There's been some talk in the trades about embedded web servers so you could use a standard browser as an interface and talk http to the embedded processor. We've got an infrared video camera running vxWorks that could use a new user interface one of these days. Has anyone any information or thoughts on this for vxWorks? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Mon, 04 Nov 1996 08:48:45 -0500 From: "Mark J. Nelson" Organization: Eastman Kodak Company Message-ID: <327DF43D.7EE2@Kodak.COM> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> Reply-To: "Mark J. Nelson" Steve Gaeke wrote: > Jim Jaskol wrote: > > We have not been real pleased with the Tornado port to x86. We've been using the Wind River Systems pc486 bsp on a Pentium target system with very few problems. I've rarely had to go to tech support; on the few occasions I have, I've gotten quite reasonable response. > > How is the development environment? Good. > > How good is the support from Wind River? Not bad. > > Are there lots of board support packages? We were really interested in one particular bsp... > > Are the board support packages of high quality? Seems good so far. - -- Mark J. Nelson Eastman Kodak Company Development Engineer mailto:Mark_Nelson@Kodak.COM voice (716)588-6226 / fax (716)477-6811 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Mon, 04 Nov 1996 09:37:27 -0600 From: Steve Woloschek Organization: GE Medical Systems Message-ID: <327E0DB7.6513@med.ge.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> I second Steve's comments. But most of my problems stem from the fact that WRS uses GNU tools. IMOH, this is a real downfall. I have had many problems with these tools and getting support through WRS for GNU problems is impossible. Even though the salesman said it would not be an issue, since Cygnus was great about problems! Ya right! If I were to do it again I would pick pSOS Steve Woloschek Steve Gaeke wrote: > > Jim Jaskol wrote: > > We have not been real pleased with the Tornado port to x86. There was > a lot of good salesmanship up front but after we jumped into it, we > found almost everything was still pretty buggy or promises were made > and not kept. I wish now we had gone with pSOS. Why are you thinking > of dropping pSOS and what platform are you developing for? > > sgaeke@cris.com > --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Video driver on VxWorks Date: 4 Nov 1996 15:17:22 GMT From: jusa@bbn.hp.com (Juergen Sang) Organization: Hewlett Packard GmbH Germany Message-ID: <55l1e2$94l@isoit109.bbn.hp.com> References: <326F11EB.47BD@ozy.dec.com> <326F88C9.14A1@finley.com> rms (richard@carapace.demon.co.uk) wrote: : Do you have an E-Mial address for MetaGraphics? I used to use sales@metagraphics.com They also have a web server, as far as I recall. - -- Cu, J|rgen - ------------------------------------------------------------------ J|rgen Sang Phone +49-7031-14-2302 Hewlett Packard GmbH FAX +49-7031-14-7023 Bvblingen Instruments Division Email jusa@bbn.hp.com Herrenberger Str. 130 71034 Bvblingen WWW (HP internal access) Germany http://bidro63.bbn/jusa.html - ------------------------------------------------------------------ --------------------------- End of New-News digest ********************** From evdsande@emt.ie.philips.nl Tue Nov 5 04:48:14 1996 From: "E. v.d. Sande" Date: Tue Nov 5 04:48:16 PST 1996 Subject: RE: Are you happy with Vx Works and Wind River Jim Jaskol wrote: >We currently use pSOS, and are thinking about using VxWorks. I would >like advice from current VxWorks users--especially those who have used >pSOS. > > How is the development environment? > How good is the support from Wind River? > Are there lots of board support packages? > Are the board support packages of high quality? > >And please don't limit your comments to the above questions. If there's >something I should know before jumping in, let me know. In response to what Steve Gaeke stated: We are also not very pleased with the Tornado port to x86. We are using Tornado on a PC-host running windows-95 and a dedicated target system based on a 80386EX processor. We ran into a lot of problems implementing vxWorks on our target system and support from windriver was everything except satisfactory. We started evaluating pSOS, so our question is also : Why are you thinking of dropping pSOS and switch to vxWorks ? evdsande@emt.ie.philips.nl Best Regards Eric van der Sanden _______________________________________________________ Philips Electronic Manufacturing Technology B.V. Ing. E. van der Sanden Electrical Development Building BY-041 P.O.box 218 5600 MD Eindhoven The Netherlands Tel: +31 40 2722762 Fax: +31 40 2724610 E-mail: evdsande@emt.ie.philips.nl _______________________________________________________ From leonid@rst.co.il Tue Nov 5 07:26:59 1996 From: leonid@rst.co.il (Leonid Rosenboim) Date: Tue Nov 5 07:27:02 PST 1996 Subject: Re: Floating Point on MIPS On 3 Nov 1996 18:26:01 GMT, "Robin Smith" wrote: >We are using VxWorks 5.1.1 under Rational Ada and are having problems with >floating point when blowing an app into ROM. It works fine when built as a >RAM image but the same floating point call (any of sin/cos/sqrt) causes the >task to terminate. >Can any body help? > >Thanks >Robin We have encountered a similar problem, which also relates to VADS Ada on VxWorks 5.2 and MIPS R4000 processor. Here is the problem: If the program is in C, the C compiler generates directly machine instructions for the math functions. inline. Ada in contrast, will call the functions of the same names inside the VxWorks libraries. Turns out these functions work incorrectly, as they can not be tested with a "C" application, the compiler will never generate calls to these functions. Ada does. the solution was to create a small file in assembly, which contains new definitions for the math functions, with the body of each function simply calling the machine instruction appropriate. This assembly file was placed in the BSP directory, and linked in to the kernel. I hope this helps. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-559-8144 R S T Software Industries Ltd. Mobile: +972-50-307-142 P.O.Box 11502, AZUR 58017, Israel Fax: +972-3-559-8244 WWW: http://www.rst.co.il E-Mail: leonid@rst.co.il From ddavies@worf.dvg.com Tue Nov 5 08:10:58 1996 From: ddavies@worf.dvg.com (Douglas Davies) Date: Tue Nov 5 08:11:00 PST 1996 Subject: RE: Are you happy with Vx Works and Wind River I hope that the Wind River folks are paying attention to this thread and several other recent threads; ie. C++ compiler support, C++ I/O streams support/pricing, GNU tool quality/support, etc. IMHO you have some substantial quality and pricing issues to address... I have been using VxWorks for almost 8 years now. In the beginning, I was very impressed with the quality, etc.. That however changed with the "slick" marketing and exorbitant pricing of tornado. In short, I am no longer impressed... And you can bet that I will be investigating other RTOS options before we begin any new development. -Doug Douglas Davies Director of Software Engineering Utah Scientific, Inc. From slirosi@gic.gi.com Tue Nov 5 09:00:18 1996 From: "Lirosi, Salvatore (HT-MS)" Date: Tue Nov 5 09:00:26 PST 1996 Subject: Zbufs ==> jay@fallcreek.com wrote: => Has anyone tried using ZBufs to improve the performance of => socket-based programs? I have a simple routine that reads data from => one socket and writes it to another. When I use ZBufs, the program => actually runs much SLOWER than when I use read() and write(). => Using ZBufs should make the program faster, not slower, since it => eliminates two data copies. => Anyone have any thougnts? I've spent about 2 weeks investigating the usefulness of UDP over zbufs for our application. What I've found is that the zbuf interface is not worth using unless you are simply reading into a socket and writing to another without any data manipulation. In addition, the data should be consistently more than 512 bytes in size per read operation. Sal LiRosi From mea@mclean.sparta.com Tue Nov 5 09:45:32 1996 From: Mike Anderson Date: Tue Nov 5 09:45:34 PST 1996 Subject: RE: Are you happy with Vx Works and Wind River Jim Jaskol wrote: > How is the development environment? > How good is the support from Wind River? > Are there lots of board support packages? > Are the board support packages of high quality? >And please don't limit your comments to the above questions. If there's >something I should know before jumping in, let me know. With regards to my viewpoint on VxWorks, I find the following things to be true: 1) The development environment in VxWorks is as good as that of any other *embedded* RTOS. That is, it would be wonderful to have and IDE like Microsoft Visual C++ with the integrated debugger, etc. PSOS kinda has that with the Microtec toolset and XRAY etc. However, WRS's use of the GNU toolset means that we can control the sources for the major components of the tools chain and can ask for help from the 'net to resolve issues. Yes, there are some bugs in the GNU toolset. However, in the years since WRS switched to the GNU tools, I have yet to find a *serious* compiler bug (even when developing BSPs for new boards). I think Windview (especially when coupled with RTI's Stethoscope product) is extremely useful, especially if you don't have the bucks for an ICE. However, I'm not as bullish on Tornado. More on that in a later paragraph. 2) WRS's support capabilities are, I believe, typical of the industry. That is to say, WRS has good people who mean well and are trying to fulfill the support requirements of a *very* diverse community. Unfortunately, I believe that there are too few support folks for the size of the user base. Also, I have a feeling that there is a general lack of what I'll refer to as "real-world" embedded systems development experience. Perhaps the support folks should be cycled through the engineering department to give them a better understanding of the O/S and its features. 3) As to BSPs, I seriously doubt that you could find an RTOS with more BSPs than VxWorks. Also, the quality of the BSPs are generally good. There are, of course, going to be problems. Some companies that are, say OS9 shops, may not do as complete a job of a VxWorks BSP as a dedicated VxWorks-oriented vendor. This is largely owing to lack of VxWorks BSP experience. However, you do get most of that BSP code as source, so like the GNU environment, you can tailor the BSP locally to meet your requirements. I guess the bottom line on the BSPs is to make sure that your hardware vendor has a good deal of experience with VxWorks so that they can help address any BSP deficiencies you may find. 4) Now, what about Tornado? If you were to believe all of the press (and the WRS salescritters), Tornado is a radically new development approach that will revolutionize the industry. However, I believe that in an effort to increase sales, improve the stock price, etc. that many at WRS have lost sight of the *real* product. That is, the base VxWorks O/S that runs on the target. Tornado seems to be well suited for the development model of those large companies such as HP wherein they are embedding VxWorks into a printer. That is, when you don't have much RAM, no serial console ports, and maybe no Ethernet, then Tornado represents a fine development environment *in theory*. And, I believe, that the Unix implementation comes pretty close to realizing that environment in practice. However, from what I've heard from the net, I believe that there are some serious problems (memory leaks, etc.) in the Tornado product under Win 95 & Win NT. Let's face it people, Win 95 & NT do not have the same level of robustness that you find in a BSD or System V derived Unix. I, personally, like both Win 95 & NT. But, when you introduce folks that are used to writing Win 3.1 or MSDOS code into a multi-threaded O/S with semaphores, event-queuing, etc. they are going to miss many of the concepts. This has many implications. First, if the WRS development team for the 95 & NT platform came from a Unix background, they're no doubt frustrated by the new (and continually changing) Win32 API. Evidence the new WINHEC driver specification for both platforms. Just the size of the Win32 API is daunting. Alternatively, if the developers came from a Windows environment, they must be going nuts with all of the new concepts in the 32-bit address space, events, Ring 0 VXDs and all of the rest of the stuff that's new to 95 & NT. Now, from a support perspective, if you open the RTOS to all of these Win 3.1 developers, you've just opened Pandora's box. Just the implications of a preemptive, priority-based scheduler can be overwhelming to folks that have never seen such a creature before. This causes more support calls, which means a higher burden on the support techs to educate the customer, which results in poorer service across the board because of lack of cycles. Real-time programming is not as simple as writing a database app. Should WRS have tried to move Tornado to the 95 & NT platform? I believe that the answer is yes. But, WRS needed to beef up their support organization to handle the influx of calls from people just trying to grasp the basic concepts of the RTOS. And what of Tornado for those of us who work in the VMEbus world? As I've said, my impression of Tornado is that it's well suited for the truly "embedded" applications such as printers and truck transmissions. That's most of WRS's west coast business. But, here on the East coast, many of us are still using VME for mission critical kinds of systems such as launch control and signal processing. Evidence the East coast user's group meeting wherein over 90% of the attendees were using VMEbus. In the VME environment, I believe that the extra overhead of the network traffic generated by Tornado and it's host-based shell, loader and symbol table have a negative impact on our ability to perform hard real-time applications. Many of you have seen the problems of trying to run 20-30 targets when you're using Tornado and need a window for each target. But, WRS provided the mechanisms to deal with this problem by allowing us to reconfigure the *target* RTOS to look and act like VxWorks 5.2. With the shell, loader and symbol table on the target, we can eliminate all of that non-deterministic network traffic. To summarize: IMHO, VxWorks is still the best RTOS on the street for a wide variety of jobs. It's as well supported as any other product out there. If you like GNU, great you can use it. If you don't, then buy the compilers from Diab Data, Green Hills or Centerline and you can still use VxWorks on the target. Yes, there are outright hacks in VxWorks. Have you seen Windows NT lately? Talk about hacks ;-). Tornado is a good thing if you application hardware has limited RAM/connectivity. Reconfigure Tornado to look like 5.2 if you're using the VMEbus with *lots* of targets. In any case, it's the operating system on the *target* that matters, not so much the development tools (once you get to a certain point ;-). To WRS, you've got a good product. Don't let the marketeers or your own marketing hype make you lose sight of the *real* product. The VxWorks RTOS. Don't cut your engineering staff to save money. You'll only lose in the long run if the real product suffers from lack of talent being applied. Tornado is neat, but all the fancy GUIs in the world won't help if the can't meet our real-time deadlines. Look at symmetric multiprocessing. How about fixing the MSDOS file system so we can exchange media with 95 & NT boxes? What about SCSI-2 (fast/wide) support (and SCSI-3)? Multi-initiator SCSI transfers between processors? Multicast IP support. Just to name a few. WRS used to be an engineering-driven company, I sometimes get the impression that you're now marketing driven. Your profitablility is good (your pricing policy needs serious work though). But, don't forget the user base that got you there. We picked VxWorks because your RTOS was light years ahead of the competition technically, not because you've got a nifty ad in Computer Design Magazine. End of tirade, ============================================================================ === __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235 // / \ \\ SPARTA, Inc. FAX : (703) 893-5494 // \ \\ 7926 Jones Branch Drive EMAIL : mea@mclean.sparta.com \\ \ // Suite 900 Web : http://www.mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." ============================================================================ === From pean@mbari.org Tue Nov 5 10:04:15 1996 From: Andrew Pearce Date: Tue Nov 5 10:04:17 PST 1996 Subject: RE: Are you happy with Vx Works and Wind River Hi, regretfully, I must second Doug's remarks. We have found the support at WRS to be almost non existent. Getting their attention on a problem always seems to be a hassle and the follow through is sadly lacking. IMHO, WRS has adopted a pricing scheme for their products which would be appropriate for a well supported product. I would be happy to pay the costs if the support was there, useful product enhancements were frequent, bugs were tracked, listed in some accessible fashion (so we don't keep rediscovering the same problems), fixed in a timely manner and rolled into the next release. Maybe Tornado will solve all my problems. :) Prehaps we should have a different format for the vxWorks users group. At present, it seems more like a soap box for WRS corporate policy than a forum where users can get together and talk about the issues they face day to day. There is useful information here which WRS could use to enhance their products and improve support if they are willing to listen. -- Andrew Pearce | email: pean@mbari.org Monterey Bay Aquarium Research Institute | tel: (408) 775-1746 7700 Sandholt Rd | fax: (408) 775-1646 Moss Landing, CA 95039 | URL: http://www.mbari.org/~pean "Coping's easy. Not pureeing your loved ones, that's the hard part." Basil Fawlty From jdeangcd@eng.kns.com Tue Nov 5 12:08:01 1996 From: jdeangcd@eng.kns.com (Joe DeAngelo) Date: Tue Nov 5 12:08:08 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Jim Jaskol wrote: > How is the development environment? > How good is the support from Wind River? > Are there lots of board support packages? > Are the board support packages of high quality? I've got to agree with Mike Anderson. VxWorks is technically a very nice product, when you look at the product, the kernel. The development tools are not the fanciest, but they are robust and work on robust platforms, and are the up to the state of the industry for embedded systems. There is a VERY strong Board Support Package presence. Service from WRS, however, has been disappointing to me. And it is not limited to the technical expertise of the service reps. There are administrative problems, where although on support contract, upgrades for supported components are very difficult to get in a timely fashion, particularly for those components provided through WRS from a third party. Even quotes from their sales people seem to be difficult to get! As far as Tornado is concerned, there are a few very nice technical improvements but basically is seems to me as far as the kernel is concerned, that its just a minor upgrade. I don't have experience with Tornado, and may NEVER have it because I've been waiting for a quote from the sales guy for over a month. Joe DeAngelo From vince@lassen.rti.com Tue Nov 5 12:55:10 1996 From: vince@rti.com (Vince Chen) Date: Tue Nov 5 12:55:12 PST 1996 Subject: Re: [Fwd: Re: Tcl/Tk] Our port of Tcl can be found at: ftp://ftp.atd.ucar.edu/pub/vxworks/vx/tclvx7.3.tar.gz It should contain the full source. -vince ========================================================================== = = = = Vincent Chen = email: vince@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 = = Sunnyvale, CA 94089 = = ========================================================================== From stan@rti.com Tue Nov 5 15:40:57 1996 From: Stan Schneider Date: Tue Nov 5 15:40:59 PST 1996 Subject: WRS User's group meeting Hi all! Well, the recent thread on the exploder makes this especially relevant... The 1997 Wind River Users Conference and Exhibition will be held January 13 and 14, 1997 at Techmart, Santa Clara, California. The proposed agenda is attached. Be sure to attend! There is a considerable change in format this year. In particular, we are trying to make the user's group (and Wind River) more responsive to the user's needs. For the newer users, there are two much-requested short courses on VxWorks and Tornado. For everyone, there will be much less marketing-style WRS presentations, and more focus-group meetings. There will also be Q&A sessions with WRS technical and management panels. I also think it's time for the user's group to "grow up", draft and adopt a purpose statement and bylaws and become more independent. So, we will convene a steering committee to discuss the organization and format. If you're interested in serving on the committee, please drop me an email (stan@rti.com). -- Stan stan@rti.com Agenda at a glance Moday January 13, 1997 Pre-conference Training sessions 9:00am to 4:00pm Conference opening 4:15pm to 4:30pm Keynote address 4:30pm to 5:00pm Welcome reception 5:00pm to 7:00pm Tuesday January 14, 1997 Wind River presentations 8:30am to 9:30am Breakout sessions 9:30am to 11:00am Application stories 11:15am to 12:00pm Breakout sessions 1:30pm to 3:00pm Corporate question and answer panel 3:00pm to 3:45pm Technical question and answer panel 4:00pm to 4:45pm Breakout sessions summary and closing 4:45pm to 5:15pm Exhibition and reception 5:30pm to 7:30pm More details: Users Conference and Exhibition Santa Clara, January 13 and 14, 1997 ----------------- Pre-conference training Sessions (Monday January 13, 1997 - 9:00am to 4:00pm) *Training session #1: Overview on how to build a BSP. *Training session #2: Real-time Multitasking, Semaphores and Intertask Communication. These training sessions are for users who have intermediate level of skill and want to aquire some good expertise in these fields. Each session is a subset of an existing Wind River training class. We're offering these high quality, professional classes - worth $500 - to Users Conference and Exhibition attendees at a greatly reduced rate. Conference Opening (4:00pm to 5:00pm) * Opening by Stan Schneider PhD., Conference Chair Stan was one of the first VxWorks users while at Stanford, and authored many tools for the VxWorks environment. Stan is now President of Real-Time Innovations, Inc. * Keynote address: Watch this space! Welcome reception. (from 5:00pm to 7:00pm) ----------------- Tuesday January 14, 1997 Wind River presentations: ( 8:30am to 9:30am) * Welcome and introduction David Larrimore, Vice President of Marketing - Wind River Systems David Fraser, Vice President of Engineering - Wind River Systems Breakout sessions: (9:30am to 11:00am, repeated 1:30 to 3:00pm) Each session offers you a more intimate setting in which to meet with other users and top Wind River engineers and discuss a single topic in depth. The four sessions will be repeated after lunch, so you'll have a chance to join two of the four. * BSP Issues * Tools * Java * VxWorks Kernel (configuration, Tornado compatibility, future directions, etc.) Application Stories: (11:15am to 12:00pm) * Embedded System Virtual Memory with VxWorks presented by Jeff Szczepanski of Xerox. An embedded system implementation that uses data compression hardware in conjunction with virtual memory techniques to extend available RAM space of a system. * Tornado for I2O presented by David Wilner, Chief Technical Officer, WRS Technical design of the I2O standard with emphasis on the IRTOS API and how to write I2O-compliant drivers. The basic objective of I2O is to provide an I/O device driver architecture that is independent of both the specific device being controlled and the host operating system. Corporate question and answer panel (from 3:00 to 3:45pm) Have your questions answered by Wind River top management in an interactive forum. Panelists: David Fraser, Vice President of Engineering David Larrimore, Vice President of Marketing Linda Postenrieder, Customer Support Manager Markus Robinson, Quality Engineering Manager David Wilner, Chief Technical Officer Technical question and answer panel: (4:00 to 4:45pm) Come prepared to have Wind River's top engineers analyze your technical issues and answer any technical questions in this interactive session. John Fogelin, Chief Technologist Jose Gonzales, Networking Group Manager John Hartmann, Tools Group Manager Kent Long, Runtime Group Manager Francis Saint Amant, Director, Customer Services D'Anne Thompson, Senior Development Engineer David Wilner, Chief Technical Officer Conference Closing (4:45pm to 5:15pm) * Summary of breakout sessions * Closing remarks Exhibition and reception: (5:15pm to 7:30pm) Enjoy refreshments while visiting approximately 30 exhibitions by Wind River Tornado Partners. From jhend@primenet.com Tue Nov 5 17:40:14 1996 From: John R Henderson Date: Tue Nov 5 17:40:16 PST 1996 Subject: 5.3 compability 5.2 compability mode How do you put 5.3 into 5.2 compatibility mode? ____________________________ | John R. Henderson, HMSC | | Hughes Missile Systems Co. | | (520) 792-0162 | | Email:jhend@primenet.com | |____________________________| From alexh@eikon.e-technik.tu-muenchen.de Wed Nov 6 01:46:47 1996 From: Alexander Helmke Date: Wed Nov 6 01:46:59 PST 1996 Subject: unsubscribe Hi, Folks! I need to unsubscribe from the vxWorks Users Group since I have another acces to the mailings now. Though it's interesting, I don't want to read everything twice... Thank you, Alex -- ************************************************************ Alexander Helmke Karl-Theodor-Str. 56 +49-89-338690 80803 Muenchen alexh@eikon.e-technik.tu-muenchen.de Germany helmke@lpr.e-technik.tu-muenchen.de ************************************************************ From alexh@eikon.e-technik.tu-muenchen.de Wed Nov 6 01:47:00 1996 From: Alexander Helmke Date: Wed Nov 6 01:47:02 PST 1996 Subject: unsubscribe Hi, Folks! I need to unsubscribe from the vxWorks Users Group since I have another acces to the mailings now. Though it's interesting, I don't want to read everything twice... Thank you, Alex -- ************************************************************ Alexander Helmke Karl-Theodor-Str. 56 +49-89-338690 80803 Muenchen alexh@eikon.e-technik.tu-muenchen.de Germany helmke@lpr.e-technik.tu-muenchen.de ************************************************************ From rasolofo@cenbg.in2p3.fr Wed Nov 6 02:22:27 1996 From: "H. Rasolofo 399" Date: Wed Nov 6 02:22:30 PST 1996 Subject: unsubscribe I need to unsubscribe from vxWorks Users Group regards. From avlasblo@best.ms.philips.com Wed Nov 6 03:17:41 1996 From: Arjon Vlasblom Date: Wed Nov 6 03:17:43 PST 1996 Subject: Re: unsubscribe At 01:47 06-11-96 PST, you wrote: > > Submitted-by alexh@eikon.e-technik.tu-muenchen.de Wed Nov 6 01:47:00 1996 > Submitted-by: Alexander Helmke > > Hi, Folks! > > I need to unsubscribe from the vxWorks Users Group > since I have another acces to the mailings now. > > Though it's interesting, I don't want to read everything twice... > > Thank you, > That doesn't mean you also have to send it twice. Arjon -- //// (0 0) _____________________________o00_( )_00o______________________________ / \ | Arjon Vlasblom High Tech Automation BV | | voice: +31 499 474725 Ekkersrijt 4006, 5692 DA Son | | fax : +31 499 474799 The Netherlands | | email: arjon.vlasblom@hta.nl http://www.hta.nl | |----------------------------------------------------------------------| | T H E E M B E D D E D S O F T W A R E C O M P A N Y | |----------------------------------------------------------------------| | Disclaimer: This message does not necessarily reflect the company's | | opinion just my own humble one. | \______________________________________________________________________/ From daemon@csg.lbl.gov Wed Nov 6 04:00:22 1996 From: daemon@csg.lbl.gov Date: Wed Nov 6 04:00:26 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Nov 6 04:00:20 PST 1996 Subject: Re: Virtual to Physical address conversion. Subject: Re: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board Subject: Does Vxworks(for x86) support a PCI ethernet card. Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: Floating Point From ROM Subject: Re: Are you happy with Vx Works and Wind River Subject: Sound Card drivers ?? Subject: Re: Are you happy with Vx Works and Wind River ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Virtual to Physical address conversion. Date: 4 Nov 1996 17:23:45 GMT From: tfm@sei.cmu.edu (Theodore Marz) Organization: The Software Engineering Institute Message-ID: <55l8r1$hbc@news.sei.cmu.edu> References: <327E1257.65792670@ccii.co.za> In article <327E1257.65792670@ccii.co.za>, Casey Crellin writes: |> Hi, |> |> I would like to convert an addrtess from virtual to physical. |> |> Similar to the unix ktop() or vtop() functions. |> |> How do I do this? |> |> I see in the manuals there is a vmContextShow() whose output |> includes both physical and virtual addresses. |> |> I would imagine I owuld use the sysPhysMemDesc[] |> But how? |> |> |> Thanks |> |> Casey |> |> |> -- |> Casey Crellin |> casey@ccii.co.za |> |> CCII Systems (Pty) Ltd |> ----------------------------------------------------------------------------- Casey, This is speaking from a Motorola 68K perspective (mvme-167). Unless you are running the (add on software) VxVMI, there is no difference between the logical and physical address. sysPhysMemDesc addresses how much/where PHYSICAL memory is from a board's perspective. If you are using the MMU with VxVMI, then you can create virtual memory contexts, one of which is the global virtual context. This context is inherited by all other virtual contexts and is initialized as being equivalent to the memory specified in sysPhysMemDesc. You would create a new virtual context as per the manual, using information in the system tables to determine where the end of physical memory was / what the next free virtual address is and create a new virtual memory context. You can then allocate memory (by the page) and map it into this context. If you do not want it accessable to everyone, you have to map it out in the global virtual context. VxWorks doesn't give you any help in managing virtual memory contexts or any help in managing the virtual address space. It is fairly easy to establish each task in it's own virtual memory context and protect it in the global virtual context (except for the stack and the TCB, which have to be writable for everyone, it has to do with task establishment and context switching). There is sample context switch hook code that works in the manual. Need more info? Post again. Basically, unless you are using VxVMI, or are messing with the MMU yourself, there is no translation between logical and physical addresses, at least on a board local point of view. BTW - it doesn't seem that VxVMI is a terribly popular package. Or at least, people just let it run in it's default mode, which makes text segments read-only in a single (global virtual) context. Ted Marz Software Engineering Institute Carnegie Mellon University --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Protocol for Downloading code from WinNT Intel/DEC system to Vxworks DEC alpha board Date: Tue, 05 Nov 1996 11:56:42 +0100 From: Philippe Le Foll Organization: France Telecom Interactive Message-ID: <327F1D6A.3F3857D2@eurobretagne.fr> References: <32794C5D.102F27DC@realtime1.com> NT provide both in version 3.5 and 4.0 an ftp server that accept anonymous connection, this should fit your requirement, you may also check for sosnt with is a free implementation of a small nfs server on NT. phillf@iu-vannes.fr Thomas A. Bond wrote: > > Hello, > > Is there a protocol available for downloading code to a > VxWork DEC apha board from a WinNT Intel/DEC based PC? > The startup code would be downloaded from the WinNT machine to the > Vxworks DEC aplha board via some boot loader code using some type of > protocol. Is there a version of tftp available for WinNT or any other > viable protocol to accomplish this task? Thanks! > > Tom > > -- > +=============================================================+ > || || > || What the world needs today ! || > || || > || // || > || // // ///// // // // // || > || // // // // // // /// || > || ///// // // // ///// // // || > || || > || The choice of a smarter generation ! || > || || > +=============================================================+ --------------------------- Newsgroups: comp.os.vxworks Subject: Does Vxworks(for x86) support a PCI ethernet card. Date: Tue, 05 Nov 1996 12:32:42 -0800 From: eric olsen Organization: stanford university Message-ID: <327FA46A.C09DCB@leland.stanford.edu> Are there any drivers for a PCI ethernet card for the x86 port of vxworks??? I see that there are 5 or 6 cards supported by the kernel, are any of them PCI cards, or does anyone have a driver for a PCI card???? thanks, - -------------------------------------------------------------- "How can I lose to such an idiot?" Aaron Nimzovich(1886-1935) eric olsen eolsen@leland.stanford.edu - -------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Tue, 05 Nov 1996 08:05:57 -0600 From: Steve Woloschek Organization: GE Medical Systems Message-ID: <327F49C5.69DF@med.ge.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <55md5u$5b@idiom.com> My issue with gnu is due to its lack of support for ieee695. I have worked with the 2.6 release from Cygnus for a win32 host. This version of the linker provides a.out-sunos-big and theoritically it supports srec, symbolsrec and binary. None of the BDM's or ICE's that we have support a.out. They use ieee695 or srecord. The GNU linker core dumped anytime I tried to use any other format besides a.out. objcopy was no better. I downloaded the 2.7 version from the web for a unix host and configured for iee695. Guess what, it only provided global debug information. (no local symbols or file information) Again, not very useful. And again certain options core dumped the linker and objcopy. I tried coff format also with no luck. I have used MRI before, and at least the tools did not crash when using certain options. If you can use a.out it probably works great. Or if you could spend the time to debug and fix the tools it is probably ok. I needed ieee695 support which gnu did not support well. Maybe things have changed. Just my .02 worth, Steve Woloschek H.J. Bae wrote: > > GNU toolchain certainly works better than any other > cross-deveopment tools I've used, including pSOS with > MRI tools. Have you actually used those tools? > You can't be serious. > > http://peacefulstar.oakland.ca.us > mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Tue, 5 Nov 1996 12:41:33 GMT From: valentin@netcom.com (Valentin Pepelea) Organization: Netcom Communications, Santa Clara, CA Message-ID: References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> Sender: valentin@netcom11.netcom.com In article <327E0DB7.6513@med.ge.com> Steve Woloschek writes: >I second Steve's comments. But most of my problems stem >from the fact that WRS uses GNU tools. IMOH, this is a real >downfall. I have had many problems with these tools and >getting support through WRS for GNU problems is impossible. >Even though the salesman said it would not be an issue, since >Cygnus was great about problems! Ya right! I am quite surprized by your statement. I have found the GNU tool chain to be very reliable. A little less featurefull than the opposition in regard to embedded systems, but more reliable in the fewer features that are provided. Perhaps the difficulties you encountered are caused by the fact that you used a WRS intermediary rather than purchasing support from, and talking directly to, Cygnus Support. An intermediary who does not fully understand your problem always filters away essential elements. I have dealt with four compiler houses in the recent past: Diab Data for PPC, Green Hills for PPC, Microtec for 68K and GNU (Cygnus) for 68K and Sparc. The best support by far came from Diab Data. My problem report seemed to have reached the actual code writer instantanously, and the answer was right on the mark. Microtec support always went through a customer support intermediary, but the correct answer always came within 2 days. Our Cygnus support was through e-mail only, and also provided correct answers within 2 days. If you use pSOS, you have to go through ISI when having problems with Green Hill's Multi development system. I was lucky to be contracting at ISI when I ran into problems, so I could just walk down the hall to get answers, but the experience of going through an intermediary still seemed unpleasant. >If I were to do it again I would pick pSOS. There are many good reasons to pick pSOS. But this is not necessarely one of them. May I suggest Microtec tools? I still own some rapidly-dwindling stock in its parent company. :-) Valentin - -- "An operating system without virtual memory Valentin Pepelea is an operating system without virtue." Embedded Sytems Consultant (415) 346-7105 - Ancient Inca Proverb valentin@netcom.com --------------------------- Newsgroups: comp.os.vxworks Subject: Floating Point From ROM Date: 3 Nov 1996 18:26:01 GMT From: "Robin Smith" Organization: [not set] Message-ID: <01bbc9b4$6e2d9d40$dc4698c2@prsf56re.prestel.co.uk> We are using VxWorks 5.1.1 under Rational Ada and are having problems with floating point when blowing an app into ROM. It works fine when built as a RAM image but the same floating point call (any of sin/cos/sqrt) causes the task to terminate. Can any body help? Thanks Robin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 96 04:18:28 GMT From: nobody@nowhere Organization: A poorly-installed InterNetNews site Message-ID: <55p3f1$rcg@idiom.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <55md5u$5b@idiom.com> <327F49C5.69DF@med.ge.com> Microtech compilers do have nice IEEE695 (or whatever) output, which current GNU toolchains lack. However, GNU can produce a.out, COFF, ELF, etc. as well, unlike Microtech. If the leverage MRI compilers have over GNU is due to their historical support of IEEE formats, this alone doesn't put WRS in the wrong position for supporting GNU -- after all, it is easy to put in a bfd backend that will handle IEEE formats; it's just that nobody has done it yet. The architecture of the GNU toolchain is superior. I'm not suggesting that GNU is the ultimate solution, just that it is a good toolchain for a lot of useful work. Bashing WRS for going with GNU tools instead of MRI tools seem unfair. --------------------------- Newsgroups: comp.os.vxworks Subject: Sound Card drivers ?? Date: Mon, 04 Nov 1996 11:18:48 -0800 From: Pete Barrie Organization: Comp. Sci. Dept., Strathclyde University, Glasgow, Scotland. Message-ID: <327E4198.2163@cs.strath.ac.uk> I need to write (or get hold of ) hardware-level info on Soundblaster-16 so I can write some sound-sampling, playback and simple FM synthesis code for VxWorks '486 platform in an educational application for disabled users. Has anybody already written some code or have any ideas on this one ? Pete Barrie --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 5 Nov 1996 19:45:10 -0800 From: kla@leland.Stanford.EDU (Earl Mitchell) Organization: Stanford University, CA 94305, USA Message-ID: <55p1k6$24c@elaine25.Stanford.EDU> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> In article <327E0DB7.6513@med.ge.com>, Steve Woloschek wrote: >I second Steve's comments. But most of my problems stem >from the fact that WRS uses GNU tools. IMOH, this is a real ^^^^^^^^^^^^^^^^^^ Most people I know consider this a major plus because they can leverage off their experience with GNU tools, use the same compiler for front end host software, and have a high degree of portability to other targets. Personally, the only time I had a problem with the GNU stuff was when it incorrectly generated floating point code for a particular processor. We sent a bug report to GNU people (not WRS) and somebody sent us a fix within a week. This was a couple years ago. A while back I read that the GNU compiler was the most widely used compiler in the embedded industry. I think WRS made the right choice going with GNU. >downfall. I have had many problems with these tools and >getting support through WRS for GNU problems is impossible. Support has been very good for me when I needed it. >Even though the salesman said it would not be an issue, since >Cygnus was great about problems! Ya right! > >If I were to do it again I would pick pSOS It would be nice if people posted more specifics about the problems they were having with WRS and VxWorks instead of just bitching and moaning. Personally, I would like to know about any potential problems. A lot of the complaints seem more related to people having problems converting from pSOS to VxWorks. The most valid complaints seem to come from the Windoze users. In this case, you all have my sympathy because WRS is heavily UNIX biased. I'd expect the Windoze version to be shaky since it is brand new. Just my 0.02 cents. --------------------------- End of New-News digest ********************** From @positron.CTI-PET.COM:wittner%pcmail.cti-pet.com@cti-pet.com Wed Nov 6 05:57:08 1996 From: Eli Wittner Date: Wed Nov 6 05:57:10 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Text item: Text_1 To all: It is interesting that no one has mentioned that WindRiver requires one to buy Tornado to keep current with VxWorks. That is, you cannot move to v5.3 without buying Tornado. Further, we have been told that our substantial standard yearly maintenance fee (for which we have received minimal "upgrades" and even poorer technical support) does not apply, and we would have to pay a large one-time fee to "upgrade" to Tornado and v5.3. Couple this with all the negative comments regarding the unreliability and bugginess of the product and it is easy to see why we are hesitant to move to Torrnado. On the positive side, I will agree with those who say vxWorks is a robust RTOS that will perform a majority, if not all, of the real-time tasks most of us need. There are still a few features we use that are not easily duplicated by competing OS's. It is for this reason that we will probably continue to use VxWorks (sans Tornado) on our current project, although we will continue to evaluate competing OS's on all new projects. Cheers -- Eli Wittner CTI Cyclotron Systems, Inc. 423-966-0072 x411 Voice 810 Innovation Dr. 423-966-8955 FAX Knoxville, TN 37932 wittner@cti-pet.com From dorlic@gte.net Wed Nov 6 06:38:36 1996 From: "Dan H. Orlic" Date: Wed Nov 6 06:38:38 PST 1996 Subject: two questions... hiya folks, Does anyone know if VxWorks 5.2 supports password encryption? and ... Why in the world doesn't V5.2 have "cret"? Thanks, Dan Orlic Electrospace systems Richardson, texas From han2326@aminet.co.kr Wed Nov 6 07:18:58 1996 From: "Han, Jeong Soo" Date: Wed Nov 6 07:19:00 PST 1996 Subject: Q:vxWorks_rom.hex on the PEP VSBC4(VIUC) board Hi, Does anyone have experience like my problem on the PEP VSBC4[VIUC] board ? I use vxWorks 5.2 & solaris 2.4 platform. My problem is ; I have implemented multiprocessing system using shared memory(1Mb) on the PEP VM30. The VSBC4[VIUC] board have only 1MB SRAM of main memory.(no DRAM) In the developing stage to download with ethernet board, my application program is well running. But, the rommable image(vxWorks_rom.hex: size 350 KB) is not running. I used total 1MB ROM(4Mbit x 2). To find out whether or not make error, I have exclude some objects to reduce the size of rommable image from 350KB to 250KB with same make process and have tested it using total 256 KB(1Mbit x 2). The result is that the reduced image is well operating. The VSBC4[VIUC] board manual is written that the board support up to 2MB. Someone adviced to me that the copies from ROM to RAM in the booting sequence of the bootable image is not a real image size(350 KB ~ 500 KB), but the total size of ROM and then I have to use total 256 KB ~ 512 KB ROM instead of 1MB ROM in the 1MB main memory board. Is it true ? I did't believe it. How can I implement the bootable system to my all program ? I am not available 2Mbit ROM immediately. Any hints or helps would be appreciated. Thanks, J.S.Han From Michael.Wenzel@med.siemens.de Wed Nov 6 09:42:56 1996 From: Michael Wenzel Date: Wed Nov 6 09:42:58 PST 1996 Subject: VxWorks Help ! Dear Ladies and Gentleman, We are using a FORCE SYS68K/CPU-30 Board with a running VxWorks Version 5.1.1 . This CPU is conncted a VME BUS via a SCSI II Controller to a SEAGATE ST32550N Disk (2.1 GByte). Now, we would like to use a defracmentation or squezze command for the disk, but the VxWorks dose not have one. How could we implement such kind of an command into our system or dose one already exist ? Many thnaks in advance for yor help and assistance. Best Regrads, Michael Wenzel From beeman1@llnl.gov Wed Nov 6 09:57:31 1996 From: Bart Beeman Date: Wed Nov 6 09:57:34 PST 1996 Subject: Shared memory? Hi all, I am new to vxWorks and RTOS in general so please excuse this (hopefully) simple question. I have a motorolla MVME162 in a system with a sparc as the backplane master, there is also a mercury processor with it's own real time processes. The mercury is to provide update data I need for the 162 real time controll process (fast steering mirror). Ideally I would set up a large portion of memory to be shared for passing the 162 control block as well as a data circular buffer. However when reading through the config.h of the 162 there is a comment stating that only the backplane master (in this case not the 162) has it's RAM dual-ported onto the VME bus. I very much would like to pass at least 2 data words to the 162 as quickly as possible as not to loose sync of the mercury with it's systems. Seems the best way is to write directly to the 162 ram, is this possible? If the 162 ram cannot be mapped to the vme bus can I at least get to the ram of the other processors? I saw mention of mailboxes in the config.h file as well, what are these? I can't seem to find any more info on them. Perhaps I could use them for my control block and then a socket for the less critical circ. buffer? Thanks for the help Bart Bart Beeman Lawrence Livermore National Laboratory beeman1@llnl.gov (510) 422-5938 voice From burt@xylan.com Wed Nov 6 14:30:51 1996 From: burt@xylan.com (Burt Cyr) Date: Wed Nov 6 14:30:53 PST 1996 Subject: Re: two questions... ================================================================== v _ Xylan, Inc. ____(_)___ Burt Cyr 26679 Agoura Rd. Suite 100 _-_-__-_-_-_ burt@xylan.com Calabasas, CA 91302 --_-_--_-_- (818) 878-4533 ================================================================== From adler@bnlku5.phy.bnl.gov Wed Nov 6 18:49:03 1996 From: Stephen Adler Date: Wed Nov 6 18:49:05 PST 1996 I just got myself an mvme1306 and I'm soon to get an MPMC202 which is a fast ethernet pmc card which will plug into the mvme1306. Has anyone worked with this combo before? When I ordered the pair, some how I got the notion that there was a vxworks driver for the mpmc202 but when I talked to WRS people, they were quick to reply that they had no driver for this board. So, anyone out their with an mpmc202 driver? Steve Adler. From daemon@csg.lbl.gov Thu Nov 7 04:00:23 1996 From: daemon@csg.lbl.gov Date: Thu Nov 7 04:00:26 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Nov 7 04:00:21 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Subject: Task stuck when trying to open file on the harddisk Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: HELP: How to get useful debug info out of an NMI interrupt? Subject: Re: HELP: How to get useful debug info out of an NMI interrupt? Subject: Re: Software Archives Subject: Re: Are you happy with Vx Works and Wind River Subject: causing a task switch ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 1996 06:36:00 GMT From: sgaeke@cris.com (Steve Gaeke) Organization: Concentric Internet Services Message-ID: <55p19f$ju4@herald.concentric.net> References: <9611052007.AA27240@wgsu13.kns.com> jdeangcd@eng.kns.com (Joe DeAngelo) wrote: >Jim Jaskol wrote: >> How is the development environment? >> How good is the support from Wind River? >> Are there lots of board support packages? >> Are the board support packages of high quality? >I've got to agree with Mike Anderson. VxWorks is technically a very nice >product, when you look at the product, the kernel. The development tools >are not the fanciest, but they are robust and work on robust platforms, and >are the up to the state of the industry for embedded systems. There is a VERY >strong Board Support Package presence. Maybe the development tools under UNIX but not Windows. >Service from WRS, however, has been disappointing to me. And it is not limited >to the technical expertise of the service reps. There are administrative >problems, where although on support contract, upgrades for supported >components are very difficult to get in a timely fashion, particularly for >those components provided through WRS from a third party. Even quotes from >their sales people seem to be difficult to get! >As far as Tornado is concerned, there are a few very nice technical improvements >but basically is seems to me as far as the kernel is concerned, that its just >a minor upgrade. I don't have experience with Tornado, and may NEVER have it >because I've been waiting for a quote from the sales guy for over a month. >Joe DeAngelo Although I am admittedly a novice, my impressions is that Tornado is not a minor upgrade and was rushed to market, especially for the host tools on x86. We still do not have a released Windview and Stethoscope for the 95/NT host even though these were suppose to materialize much earlier this year. The TCL language is currently only documented for UNIX hosts (NO Windows examples or libraries) and I don't believe any of the GUI additions are supported under x86 (see appendix F I believe of the TCL API). Your suggestion of building the embedded shell makes sense except now you don't have any Tornado tools since they rely heavily on a host based symbol table and there is currently no way to synchronize or re-build one from a targeted shell. Someone else made a point of real-time. Try running your tornado tools while your target is running. It is _very_ intrusive. I believe we are ripped away by the WDB agent during intial communication on the order of 100ms. We are hoping the next release will fix many of these problems. I agree there is no perfect RTOS / Tool suite out there, but when you pay for technical support and you are told to check the news groups for help, there is something seriously wrong. I have gotten this answer many times. It will probably continue to be a bumpy ride, but in the end, I think WRS will pull it together. It's just right now they lack adequate responsive support. *** I would still like to hear any comparisions from the pSOS people, especially for x86 targets and W95/NT hosts. steve. ######################################################### The opinions expressed are my own and do not reflect the opions of my employer. ######################################################### --------------------------- Newsgroups: comp.os.vxworks Subject: Task stuck when trying to open file on the harddisk Date: Wed, 06 Nov 1996 12:05:25 +0200 From: Dani Gutzeit Organization: NetVision LTD. Message-ID: <328062E5.41C67EA6@ksl.co.il> We upgraded our VxWorks version from 5.1 to 5.2 Now sometimes we have a problem when trying to open ( for write ) a file on harddisk. The task is stuck with following stack: - -> tt 0xaea324 a240 _vxTaskEntry +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0) 38b1a2 _x_main +358: 38aaac (9c7de0) 38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078) d968fe _XtDispatchEvent+4a : d9667e (aea078) d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc) d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00, c1db10, 8]) daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8, aea078]) daf830 __XtMatchAtom +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8]) daf0de __XtMatchAtom +292: df3ea8 (c117c8, aea078, 0, ac7fb0) df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0, ae9ed8]) df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94, ae9e80, c117fc, 0]) d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80) 4a8000 _diepSaveCB +8a : _Save_Die_Parameters (a405c4, 565f6c) a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4) a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0) a17858 _dbSaveObject +1c : _dbFopen (ae9bdc, ae9c16, a1783a) a177d2 _dbFopen +10 : _fopen (ae9c16, a1783a) c218 _fopen +34 : _open (ae9c16, 601, 1b6) 28fce _open +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6) 29ce4 _iosOpen +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16]) 570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5]) 540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90) 55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4) 54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c) 28c2c _hashTblRemove +5c : _sllPrevious (f71590) The task status is READY. Can anybody help? Thanks Dani --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 1996 08:38:57 -0800 From: Michael Levasseur Organization: GDE Systems Inc. Message-ID: <3280BF21.41C67EA6@gdesystems.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <55p1k6$24c@elaine25.Stanford.EDU> Notice anything perculur? There is this long indepth thread and not a single post from Wind River!!!! Don't Wind River's people look at the net. Aren't they in the 90's or are they still working in a vacuum. I've had other issues with Board manufacturers, compiler venders and application venders and usually when I've posted discussions on the net I've gotten their $.02 worth. I've even gotten calls from some of those companies when I flamed them. I use the news groups to solve and discuss many complex issues and I'm totally suprised that no Wind River people have commented. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 6 Nov 1996 15:33:28 GMT From: gerlach@netcom.com (Matthew H. Gerlach) Organization: Netcom Online Communications Services (408-241-9760 login: guest) Message-ID: References: <55md5u$5b@idiom.com> <327F49C5.69DF@med.ge.com> Sender: gerlach@netcom23.netcom.com In article <327F49C5.69DF@med.ge.com> Steve Woloschek writes: >My issue with gnu is due to its lack of support for >ieee695. I have worked with the 2.6 release from Cygnus >for a win32 host. > I think this question comes up a lot; it might even be in the faq. I ran into the same problem bringing up a non-VxWorks i960 board. I used coff format, but the ICE wanted ieee. The GNU tool chain for i960's from intel contain a tool to generate iee suitable for many ices. Matthew --------------------------- Newsgroups: comp.os.vxworks Subject: HELP: How to get useful debug info out of an NMI interrupt? Date: Wed, 06 Nov 1996 09:54:57 -0500 From: Yamudda Wezamibootz Organization: Data General Corporation, Westboro, MA Message-ID: <3280A6C0.77A2@inigo.us.dg.com> (Yes, I've tried to find help in the manuals.) The reason I ask is, I'm working on some custom hardware that's prone to bus hangs, and don't have ready access to an ICE. I managed to talk the hardware folks into making the board do an NMI on a bus timeout. I figured, at the NMI, I could gather some state, and then spit it out on the serial port. But it's not working. So I need to debug my debug routine. I'd also like to know what task got interrupted, since this would be the task that hung the bus. Then maybe I could force a GPF on the task, and get some info from the GPF message. Oh, and when this happens, I lose network connectivity, and my shell on the serial port will echo keystrokes and spit occasional messages, but nothing else. The whole kernel seems comatose, as if crucial system tasks have gone south. (Why, oh why, is the WDB target server implemented as a task? Just so it can crash when I need it most?) Any thoughts out there? Thanks. (Running vxWorks 5.3 on a 386EX. Host is Tornado 1.0 on NT 3.51. WDB is RPC over ethernet.) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HELP: How to get useful debug info out of an NMI interrupt? Date: 6 Nov 1996 22:26:57 GMT From: malloryc@aol.com Organization: America Online, Inc. (1-800-827-6364) (1.10) Message-ID: <19961106222900.RAA24854@ladder01.news.aol.com> References: <3280A6C0.77A2@inigo.us.dg.com> Sender: news@aol.com Use a logic analyzer with a preprocessor for state disassembly. The newer logic analyzer are also C source aware. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Software Archives Date: Wed, 06 Nov 1996 15:02:55 -0800 From: Frank Weissig Organization: Teleport - Portland's Public Access (503) 220-1016 Message-ID: <3281191F.78B4@teleport.com> References: <32767112.7636E565@leland.stanford.edu> Reply-To: faw@teleport.com eric olsen wrote: > > I understand that there is an archive containing publically > available libraries, etc for vxworks. > I am looking for a port of the curses library(to the pc platform). > > Where is this archive located?????? > ftp://ftp.atd.ucar.edu/pub/vxworks/vx/ - -- Frank Weissig Senior Staff Engineer STEP Technology, Inc. frank@steptech.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 1996 21:05:41 -0700 From: Wes Peters Organization: Softweyr LLC Message-ID: <32816014.71D@xmission.com> References: <9611051610.AA27410@worf.dvg.com> Reply-To: softweyr@xmission.com Douglas Davies wrote: > I hope that the Wind River folks are paying attention to this thread > and several other recent threads; ie. C++ compiler support, C++ I/O > streams support/pricing, GNU tool quality/support, etc. With respect to this, which compiler(s) are you using? We have used GCC, first 2.6.1 then 2.7.2, very successfully. My partner-in-crime and I developed an 85,000-line custom C++ system this year using GCC for C++ on VxWorks 5.2; we experienced no significant problems with the system or the tools. We do not use iostreams as they are far too large for the high-speed i/o requirements of our system, but I imagine the GNU libg++ could be ported to VxWorks. > IMHO you have some substantial quality and pricing issues to address... I haven't experienced any problems with the VxWorks kernel on M68000 platform. I haven't used Tornado yet, and don't really expect too in the future; the systems I'm working on are not memory bound, and the new systems use easily expanded SIMM memory. > I have been using VxWorks for almost 8 years now. In the beginning, > I was very impressed with the quality, etc.. That however changed > with the "slick" marketing and exorbitant pricing of tornado. Have any of your recent experiences changed your mind about the VxWorks kernel itself, or just the mis-features of Tornado? > In short, I am no longer impressed... And you can bet that I will be > investigating other RTOS options before we begin any new development. - --- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC softweyr@xmission.com http://www.xmission.com/~softweyr --------------------------- Newsgroups: comp.os.vxworks Subject: causing a task switch Date: Wed, 06 Nov 1996 23:17:53 -0800 From: Todd Hoff Organization: Possibility Outpost Message-ID: <32818D21.390B@possibility.com> Reply-To: tmh@possibility.com For our system integrity system we have a task that periodically wakes up our agents to cause a task switch. If a task has not switched in a certain period of time it is assumed dead. For agents this is easy because all agent's block on a semaphore which i can just give. For tasks i'm not sure how to make them perform a task switch in a general fashion. None of the task library methods seem appropriate. taskDelay works on the current task. suspending and resuming a task is risky and i'm not sure it would do what i want anyway. Any ideas? Thanx - ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell --------------------------- End of New-News digest ********************** From 100656.1507@CompuServe.COM Thu Nov 7 06:02:13 1996 From: John Shaw <100656.1507@CompuServe.COM> Date: Thu Nov 7 06:02:20 PST 1996 Subject: Re: two questions >Subject: two questions... >Submitted-by dorlic@gte.net Wed Nov 6 06:38:36 1996 >Submitted-by: "Dan H. Orlic" >hiya folks, >Does anyone know if VxWorks 5.2 supports password encryption? Hi Dan, Yup is the answer to your first question. But you must add INCLUDE_SECURITY in either bsp/config.h or vw/config/all/configAll.h.... There is a slight problem with that though, if the option is included... remote logins become secure and require users to enter a name and password.... with a few mods to vw/config/all/usrConfig.c you can make this feature optional. The way I have accomplished this is shown below:- #ifdef INCLUDE_SHELL #ifdef INCLUDE_SECURITY loginInit (); if ((sysFlags & SYSFLG_NO_SECURITY) == 0) { shellLoginInstall (loginPrompt, NULL); loginAddUser (LOGIN_USER_NAME, LOGIN_PASSWORD); } #endif INCLUDE_SECURITY The boot parameter flag for a processor should have 0x20 set to disable remote login password entry. Application code should include loginLib.h to access a few functions. The most important is loginDefaultEncrypt (char * in, char * out). You supply a string that holds a readable password (in) and the function will encrypt this (out). You can then compare the encryption with a known password encryption. There is also a UNIX binary in vw/bin/sun4/vxencrypt that, when run, requests a non-echoed password and outputs the encrypted password to stdout. I suspect that the encryption algorithm is NOT one that could be used on really secure systems. Only WRS know. You can supply your own encryption function via a call to loginEncryptInstall (). Hope this helps. John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK. 100656.1507@compuserve.com From mea@mclean.sparta.com Thu Nov 7 06:59:46 1996 From: Mike Anderson Date: Thu Nov 7 06:59:48 PST 1996 Subject: Re: causing a task switch At 04:00 AM 11/7/96 PST, you wrote: >Subject: causing a task switch >Date: Wed, 06 Nov 1996 23:17:53 -0800 >From: Todd Hoff >Organization: Possibility Outpost >Message-ID: <32818D21.390B@possibility.com> >Reply-To: tmh@possibility.com > >For our system integrity system we have a task that >periodically wakes up our agents to cause a task switch. >If a task has not switched in a certain period of time it >is assumed dead. For agents this is easy because all >agent's block on a semaphore which i can just give. >For tasks i'm not sure how to make them perform a task switch in >a general fashion. None of the task library methods >seem appropriate. taskDelay works on the current task. >suspending and resuming a task is risky and i'm not sure >it would do what i want anyway. Any ideas? > Greetings! First, you can do a taskDelay(0) in your respective tasks to force them to give up the CPU without incurring any actual delay. But, another approach would be to have your manager task wake up (at a relatively high priority) and adjust the priority of the task you want to awaken up above the rest of the "managed" tasks and then do a taskDelay in the manager task. If that newly elevated task is the highest priority ready to run, then it will be switched in and it will execute. Make sure that the manager task is a higher priority than the newly elevated task so when the taskDelay expires, the manager takes over the CPU and can adjust the priorities again. There are other actions that can case a context switch though (to the "pended" state rather than the "delayed" state). Things like semGives and semTakes of already available semaphores can also cause these context switches (but these *will* incur some delay over and above the raw context switch time). HTH, ============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235 // / \ \\ SPARTA, Inc. FAX : (703) 893-5494 // \ \\ 7926 Jones Branch Drive EMAIL : mea@mclean.sparta.com \\ \ // Suite 900 Web : http://www.mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." ============================================================================== From MikeMcQuade@connect.com Thu Nov 7 07:33:02 1996 From: Mike McQuade Date: Thu Nov 7 07:33:05 PST 1996 Subject: Re: At 06:49 PM 11/6/96 PST, you wrote: >Submitted-by adler@bnlku5.phy.bnl.gov Wed Nov 6 18:49:03 1996 >Submitted-by: Stephen Adler > > >I just got myself an mvme1306 and I'm soon to get an MPMC202 which >is a fast ethernet pmc card which will plug into the mvme1306. >Has anyone worked with this combo before? When I ordered the >pair, some how I got the notion that there was a vxworks driver >for the mpmc202 but when I talked to WRS people, they were >quick to reply that they had no driver for this board. So, >anyone out their with an mpmc202 driver? > I believe that this card is the same as a RNS 2300, if thats the case, Ross Micro Systems has a driver, Ive been using a 2300 (100 Base-Tx) board with Ross's driver. The driver works good, the installation was easy, the documentation is very complete, and their support is excellent. Mike. MikeMcQuade@connect.com From burns.pentek.com!tkl@pentek.com Thu Nov 7 08:01:31 1996 From: tkl@burns.pentek.com (Terry K. Lim) Date: Thu Nov 7 08:01:33 PST 1996 Subject: MPMC-202 Driver > I just got myself an mvme1306 and I'm soon to get an MPMC202 which > is a fast ethernet pmc card which will plug into the mvme1306. > Has anyone worked with this combo before? When I ordered the > pair, some how I got the notion that there was a vxworks driver > for the mpmc202 but when I talked to WRS people, they were > quick to reply that they had no driver for this board. So, > anyone out their with an mpmc202 driver? > > Steve Adler. A Wind River sales person told me that they have a driver for the DEC 21140 chip that is on the MPMC-202, but not a port to the MPMC-202. -- Terry Lim | Voice: (201) 818-5900 Director of Software Engineering | FAX: (201) 818-5941 Pentek, Inc. | WWW: http://www.pentek.com From tmorris@me.umn.edu Thu Nov 7 08:25:48 1996 From: "Ted Morris" Date: Thu Nov 7 08:25:50 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Ditto. > > Text item: Text_1 > > To all: > > It is interesting that no one has mentioned that WindRiver requires > one to buy Tornado to keep current with VxWorks. That is, you cannot > move to v5.3 without buying Tornado. Further, we have been told that > our substantial standard yearly maintenance fee (for which we have > received minimal "upgrades" and even poorer technical support) does > not apply, and we would have to pay a large one-time fee to "upgrade" > to Tornado and v5.3. Couple this with all the negative comments > regarding the unreliability and bugginess of the product and it is > easy to see why we are hesitant to move to Torrnado. > > On the positive side, I will agree with those who say vxWorks is a > robust RTOS that will perform a majority, if not all, of the real-time > tasks most of us need. There are still a few features we use that are > not easily duplicated by competing OS's. It is for this reason that > we will probably continue to use VxWorks (sans Tornado) on our current > project, although we will continue to evaluate competing OS's on all > new projects. > > Cheers -- Eli Wittner > > CTI Cyclotron Systems, Inc. 423-966-0072 x411 Voice > 810 Innovation Dr. 423-966-8955 FAX > Knoxville, TN 37932 wittner@cti-pet.com > > > ********** > Ted Morris "WWW = World Wide Wait" tmorris@me.umn.edu 612-625-3520 Center For Advanced Manufacturing Design And Control 612-625-9881 Institute of Technology, U of Minnesota FAX: 612-625-8884 From tmorris@me.umn.edu Thu Nov 7 09:49:00 1996 From: "Ted Morris" Date: Thu Nov 7 09:49:03 PST 1996 Subject: A good book... Howdy all, I would like to know if any of you out in the ether could recommend a decent text book appropriate for Junior/Senior level engineering students that covers basic concepts in real-time programming and operating systems. The book should offer simple excersises and/or examples if possible. But first here's some relevant background: ****** We will be offering new controls class starting this Winter (Jan-1) for undergraduate engineering students that requires them to use VxWorks. We will be using VxSIM as a teaching tool for them to explore implimenting various control stategies in a real-time programming environment. Essentially, we already have real-time simulators of various kinds of sensors and dynamic plants that model the actual devices quite accurately. When each student feels confident that their control algorithms work, their tasks are recompiled and tried on the real devices. Note that unforntunately the current course prerequisites follow a very arcane, outdated protocol which does not even require students to have any background in C/C++. Most are familiar with UNIX. Basic Linear Controls, Dynamic Systems, and FORTRAN programming are the only requirements. ***** thanks in advance! Ted Ted Morris tmorris@me.umn.edu 612-625-3520 Center For Advanced Manufacturing Design And Control 612-625-9881 Institute of Technology, U of Minnesota FAX: 612-625-8884 From stan@rti.com Thu Nov 7 11:51:12 1996 From: Stan Schneider Date: Thu Nov 7 11:51:14 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River >> Date: Wed, 06 Nov 1996 06:36:00 GMT >> From: sgaeke@cris.com (Steve Gaeke) >> We still do not have a released Windview and Stethoscope for the 95/NT >> host even though these were suppose to materialize much earlier this >> year. StethoScope for 95/NT on Tornado has been released since last Spring; we're sorry if you somehow got mixed up. We have an update release that went FCS late last month. This will be available from WRS this month; if you're on maintenance, you should get it. If you're in a bigger hurry, you can send your license info to "info@rti.com"; we'll set you up to download it from our (new) web-based shipping system today. >> Your suggestion of building the embedded shell makes sense except now >> you don't have any Tornado tools since they rely heavily on a host based >> symbol table and there is currently no way to synchronize or re-build >> one from a targeted shell. There are several solutions. Leonid posted an unsuppored free TCL script & target module that coordinates the host and target symbol tables after a load; you can get it from his web site (www.rst.co.il). We have added a "target server server" that serves the host-based symbols back to the target to RTILib (free with StethoScope). With it, your target can utilize the host-based symbol functions such as symLib and ldLib. One of these should work for you until WRS addresses the issue. >> Try running your tornado tools while your target is running. It is >> _very_ intrusive. I believe we are ripped away by the WDB agent during >> intial communication on the order of 100ms. Part of this is probably because you're running tWdbtask at its default very high priority. Try lowering it below your critical tasks. WRS ships it at high priority because it's more foolproof that way (harder for users to lock it out with their own task), but it's not great for real-time response. The target-based shell has (had?) the same issue. -- Stan ============================================================================= = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 x104 = = 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 = = Sunnyvale, CA 94089 = http://www.rti.com = = = = ============================================================================= From MikeMcQuade@connect.com Thu Nov 7 14:44:59 1996 From: Mike McQuade Date: Thu Nov 7 14:45:02 PST 1996 Subject: Testing a location over the VME bus. I have a question, in the application Im working on, I need to be able to determine the number of cards available. Since some configurations have only two cards, and other units may have four, Im stuck having to probe addresses to see if a given card is available. Im using both MVME-1603 and 1604 boards, on the 1603, I can access addresses where there is no hardware, this returns garbage, but on the 604, if I try to access an address where there is no hardware, I get an exception. Any ideas why the 604 generates an exception, and the 603 doesn't ? Any suggestions on how to test if a board is available ? Thanks in advance. MikeMcQuade@connect.com From wbrown@csg.lbl.gov Thu Nov 7 15:05:01 1996 From: wbrown@csg.lbl.gov (Bill Brown) Date: Thu Nov 7 15:05:03 PST 1996 Subject: Re: Testing a location over the VME bus. What about using vxMemProbe( )? Disclaimer: Any opinions are my own and have | -bill nothing to do with the official policy or the | wlbrown@lbl.gov management of L.B.L, who probably couldn't | Berkeley, CA care less about employees who play with trains. | aka wlbrown@netcom.com From Edward_D._Shober@dvg.com Thu Nov 7 15:41:50 1996 From: Edward_D._Shober@utsci.com (Edward D. Shober) Date: Thu Nov 7 15:41:53 PST 1996 Subject: Re: 5.3 compability 5.2 compability mode >How do you put 5.3 into 5.2 compatibility mode? When I ported our 5.2 BSPs to 5.3 the only real trick I remember having to do was to #define INCLUDE_TYCODRV_5_2 in config.h. Good luck, Ed (eshober@utsci.com) From Edward_D._Shober@dvg.com Thu Nov 7 16:17:01 1996 From: Edward_D._Shober@utsci.com (Edward D. Shober) Date: Thu Nov 7 16:17:07 PST 1996 Subject: Re: Q:vxWorks_rom.hex on the PEP VSBC4(VIUC) board > Someone adviced to me that the copies from ROM to RAM in the booting > sequence of the bootable image is not a real image size(350 KB ~ 500 > KB), but the total size of ROM and then I have to use total 256 KB ~ > 512 KB ROM instead of 1MB ROM in the 1MB main memory board. > >Is it true ? I did't believe it. >How can I implement the bootable system to my all program ? >I am not available 2Mbit ROM immediately. I fixed this problem on our system by setting ROM_SIZE in config.h and the makefile to just over the application size instead of to the actual, available ROM size. If the application grows bigger make should fail and you can increase the ROM_SIZE as needed. Good luck, Ed (eshober@utsci.com) From guthrie@power.amasd.anatcp.rockwell.com Thu Nov 7 16:23:13 1996 From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie) Date: Thu Nov 7 16:23:24 PST 1996 Subject: unsubscribe unsubscribe From tkb@mclean.sparta.com Thu Nov 7 17:37:26 1996 From: "Thomas K. Buchanan" Date: Thu Nov 7 17:37:28 PST 1996 Subject: Re: 5.3 compability 5.2 compability mode At 03:41 PM 11/7/96 PST, you wrote: >Submitted-by Edward_D._Shober@dvg.com Thu Nov 7 15:41:50 1996 >Submitted-by: Edward_D._Shober@utsci.com (Edward D. Shober) > >>How do you put 5.3 into 5.2 compatibility mode? > put a line like the following in your config.h file: #define INCLUDE_CONFIGURATION_5_2 If you want to use CrossWind w/o Tornado, you'll need the remote debugger task running. To include that add this line also: #define INCLUDE_RDB HTH ----------------------------------------- /\\ Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 7926 Jones Branch Drive / \\\\\ \\ Suite 900 \ \\\\\ // McLean, VA 22102 \ ////// \////// Voice: 703 448 0210 \//// FAX: 703 893 5494 \// WWW: www.mclean.sparta.com From froeber@bbn.com Thu Nov 7 18:53:23 1996 From: Fred Roeber Date: Thu Nov 7 18:53:30 PST 1996 Subject: Re: harddisk open problem On Thu, 7 Nov 1996, Dani Gutzeit wrote: > We upgraded our VxWorks version from 5.1 to 5.2 > Now sometimes we have a problem when trying to open ( for write ) > a file on harddisk. > > The task is stuck with following stack: > > - -> tt 0xaea324 > a240 _vxTaskEntry +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0) > 38b1a2 _x_main +358: 38aaac (9c7de0) > 38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078) > d968fe _XtDispatchEvent+4a : d9667e (aea078) > d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc) > d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00, > c1db10, 8]) > daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8, > aea078]) > daf830 __XtMatchAtom +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8]) > daf0de __XtMatchAtom +292: df3ea8 (c117c8, aea078, 0, ac7fb0) > df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0, > ae9ed8]) > df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94, > ae9e80, c117fc, 0]) > d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80) > 4a8000 _diepSaveCB +8a : _Save_Die_Parameters (a405c4, 565f6c) > a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4) > a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0) > a17858 _dbSaveObject +1c : _dbFopen (ae9bdc, ae9c16, a1783a) > a177d2 _dbFopen +10 : _fopen (ae9c16, a1783a) > c218 _fopen +34 : _open (ae9c16, 601, 1b6) > 28fce _open +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6) > 29ce4 _iosOpen +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16]) > 570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5]) > 540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90) > 55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4) > 54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c) > 28c2c _hashTblRemove +5c : _sllPrevious (f71590) You aren't really just trying to write to a file. From this trace, it looks like you are running a lot of extra packages including X Windows, and some data base code. The error you are seeing could be caused by incompatabilities in any one of those packages and will be hard to track down. You may want to check with the vendors of these other packages as to whether they think there stuff is compatible with 5.2 the same as it was with 5.1. It would appear from the trace that the open call is calling the DOS open function which is calling the DOS file creation function. I must admit I can't imagine why the file creation would end up invoking the hash table functions. Maybe, your stack allocations for tasks is not sufficient with the new release and you are clobbering some task's stack. You should use checkStack to check this. In general, we had few problems upgrading from VxWorks 5.1 to 5.2. Hope that helps. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | | See http://www.bbn.com/tv for TraceMaker info | From 100656.1507@CompuServe.COM Fri Nov 8 02:27:58 1996 From: John Shaw <100656.1507@CompuServe.COM> Date: Fri Nov 8 02:28:00 PST 1996 Subject: Re: Shared Memory? >Subject: Shared memory? >Submitted-by beeman1@llnl.gov Wed Nov 6 09:57:31 1996 >Submitted-by: Bart Beeman >Hi all, >I am new to vxWorks and RTOS in general so please excuse this (hopefully) >simple question. I have a motorolla MVME162 in a system with a sparc as the >backplane master, there is also a mercury processor with it's own real time >processes. The mercury is to provide update data I need for the 162 real >time controll process (fast steering mirror). Ideally I would set up a >large portion of memory to be shared for passing the 162 control block as >well as a data circular buffer........ Hello Bart, We are using several Motorola 167 and 162 68K cards in a chassis using the shared memory backplane anchor for booting. We also use mailbox interrupts between processors. These are really signals passed across the VMEbus that may then interrupt a specific processor or a group of processors in the chassis. There is very little written about them, but VxWorks uses mailbox interrupts so any system files will contain useful information. Have a look at any LBIV_GCSR_XXXX definitions in the following header: vw/h/drv/vme/vmechip2.h, and the source file vw/src/drv/vme/vmeChip2Vme.c too. VxWorks uses the LBIV_GCSR_SIG3 mailbox and you should not! We use the LBIV_GCSR_SIG2 mailbox as a one-to-one processor signal and both LBIV_GCSR_LM0 and LBIV_GCSR_LM1 mailboxes as a signal to a group of processors. With regards to the 162 acting as a VME slave window, it is capable. There are two approaches. You could modify vw/config/bsp/sysLib.c so that the VMECHIP2_VSAR1 and VMECHIP2_VSATR1 registers are programmed to open a shared memory window at a given VME A32 base address, in the sysProcNumSet () function. But there is a much better way that avoids changing VxWorks system files too much. The application can instead open a shared memory window by allocating non-cached memory and by then programming the VMEChip2 on the MVME162 carefully to provide address translation between VME and CPU-local address spaces. Have a look at the Motorola manual on the MVME162 for details on the VMEchip2 and it's miriad functions. I can, if you wish, email you the source for the application-based method of opening a shared memory window. Just email me! Remember, the processor (Mercury) that needs to write the data across the VMEbus to the 162 must have a window into VME A32 space that it can write to without a bus error. The 68k processors usually had these windows defined statically in sysLib.c by adding entries in the sysPhysMemDesc [ ] array near the beginning of the file. Hope this doesn't scare you too much, it's not quite as bad as it seems! John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK. 100656.1507@compuserve.com From daemon@csg.lbl.gov Fri Nov 8 04:00:29 1996 From: daemon@csg.lbl.gov Date: Fri Nov 8 04:00:32 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Nov 8 04:00:26 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: how to writeassembly code for a pc target ? Subject: Delta TAU PMAC vxworks driver searching Subject: Re: causing a task switch Subject: Re: Task stuck when trying to open file on the harddisk Subject: @@@>> HOT COLLEGE BI-MALES!!! >PRIVATE< 1-900-825-6000 xt 9794 Subject: Looking for public-domain NFS client Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: intConnect for VMIC1182 and MVME167 Subject: Re: Are you happy with Vx Works and Wind River Subject: Porting Tcl Library to VxWorks! Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Clarification Of Question - Re: Non Terminating TCP/IP Sockets Subject: Serial ports 3+4 Subject: Does vxWorks include echo server? Subject: kbhit() equivalent Subject: Interrupt vectors and levels ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 6 Nov 1996 14:50:35 -0700 From: softweyr@xmission.xmission.com (Softweyr LLC) Organization: XMission Internet (801 539 0900) Message-ID: <55r17b$ns7@xmission.xmission.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> Jim Jaskol wrote: > We currently use pSOS, and are thinking about using VxWorks. I would > like advice from current VxWorks users--especially those who have used > pSOS. > > How is the development environment? > How good is the support from Wind River? > Are there lots of board support packages? > Are the board support packages of high quality? > > And please don't limit your comments to the above questions. If there's > something I should know before jumping in, let me know. In my current job, we use VxWorks on our own proprietary boards with MC68HC000 and MC68302 CPUs. In two weeks, I'm going to a new job, using VxWorks on NS486; that may color my opinion in the future. We use the GNU tools on HP-UX and FreeBSD for our development environment. This is, essentially, the GNU development environment. I personally use GNU Emacs, GCC, and GDB, and am very familiar with and productive in this environment. A few of the poeple we've hired in the last year, coming in from the DOS-dominated world of itty-bitty embedded systems, have not gotten along well with our environment at all. We have little occasion to call Wind River support; our boards are stable and mature and we've been on VxWorks (originally 5.1, latest releases on 5.2) for about two years now. The basic operating system seems pretty thorough and bug-free in our environment, but I hear that newer chips (to VxWorks, at least) are not as stable as the 68000 platform. We have developed our own BSPs, since our boards are custom designs. The engineer who maintains our BSP functionality (for the rest of this week, anyhow) reports that your best bet for custom work is to get a BSP for a board or CPU similar to yours and hack it up, rather than starting from scratch. Ours are apparently based on Motorola boards using the CPUs we do; support ofr our other oddball devices (ie596, v25 using dual-port ram for serial ports, etc.) rely on in-house drivers and firmware. - --- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Fri, 01 Nov 1996 08:01:56 -0800 From: Michael Levasseur Organization: GDE Systems Inc. Message-ID: <327A1EF4.41C67EA6@gdesystems.com> References: <32794C99.67F9@corp.disney.com> > How is the development environment? I've been working with VxWorks for the last six years on four seperate defense contracts; Seawolf Submarine BSY-2, USMC CATFAE vehicle, USN SLQ-32 and now the USN DIWS. > How good is the support from Wind River? The only complaint I've ever had is their customer support is the worst I've ever delt with. They seem to ignore E-mail, they argue that all problem reports must go through the one person in our company that is the person listed for customer support. > Are there lots of board support packages? I've used VxWorks on Heurikon Boards, Radstone boards, Force boards, Motorola boards, and DY4 boards. I've had great support from Heurikon and Radstone. I've been able to send E-mail to Heurikon in the morning and by afternoon I've gotten answers. Heurikon is by far the best!!! All of the companies have had good BSP and have been very helpful in fixing problems. --------------------------- Newsgroups: comp.os.vxworks Subject: how to writeassembly code for a pc target ? Date: Tue, 05 Nov 1996 17:10:22 -0500 From: Farooq Bari Organization: UTRC Message-ID: <327FBB4E.7FCC@utrc.utc.com> Reply-To: barif@utrc.utc.com Hi, I am using a pc target with an NT host. I am interested in directly accessing and writing to 486 or 586 registers on the pc target. Does tornado compiler support inline assembly code ? I could not find any sample code or documentation on this. will appreciate any help in this regard. Farooq Bari --------------------------- Newsgroups: comp.os.vxworks Subject: Delta TAU PMAC vxworks driver searching Date: Thu, 07 Nov 1996 17:23:06 +0000 From: "Regis C. Schmidt" Organization: Observatoire de Meudon Message-ID: <32821AF8.2634@obspm.fr> Hi, I'm looking for a vxworks driver for a VME motion controler called PMAC from Delta TAU company. If someone has already developped something like that, I'd like to get it, and if possible, the sources of the driver. I'm working for a non-profit organization in France so , be sure that the sources origin will always be signalled. Thanks by advance. - -- Regards - ------------------------------------------------------------------------------ Regis C. Schmidt Observatoire de Paris-Meudon/DAEC 5, place Jules Janssen F92195 Meudon (France) FUEGOS Project E-mail : Regis.Schmidt@obspm.fr Tel : +33 1 45.07.75.27 Fax : +33 1 45.07.79.82 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: causing a task switch Date: Thu, 07 Nov 1996 08:31:11 -0600 From: johncoby@ghgcorp.com (JOHN R. COBARRUVIAS) Organization: Personal Account Message-ID: References: <32818D21.390B@possibility.com> In article <32818D21.390B@possibility.com>, tmh@possibility.com wrote: > For our system integrity system we have a task that > periodically wakes up our agents to cause a task switch. > If a task has not switched in a certain period of time it > is assumed dead. For agents this is easy because all > agent's block on a semaphore which i can just give. > For tasks i'm not sure how to make them perform a task switch in > a general fashion. None of the task library methods > seem appropriate. taskDelay works on the current task. > suspending and resuming a task is risky and i'm not sure > it would do what i want anyway. Any ideas? taskResume, taskSuspend does just what it says. What concerns do you have that makes this approach risky? Also, why not use a semaphore for these tasks also? Maybe I dont know what you mean by task switch. You mean, it is in a pending state and you want it to go into a running state? > > Thanx > > > ------------------------------------------------------------- > tmh@possibility.com | The loyalty of small men can be > http://www.possibility.com | bought cheaply, for greed has no > | pride. - Michael Kube-McDowell - -- ,-_/ . .-,--. ,---. . ' | ,-. |-. ,-. `|__/ | -' ,-. |-. ,-. ,-. ,-. . . . , . ,-. ,-. | | | | | | | | \ ,. | -. | | | | ,-| | | | | | / | ,-| `-. | `-' ' ' ' ' `-' ` `' `---' `-' `-' `-^ ' ' `-' `' ' `-^ `-' / | John R. Cobarruvias johncoby@ghgcorp.com Houston, Tx `--' --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Task stuck when trying to open file on the harddisk Date: Thu, 7 Nov 1996 15:48:14 GMT From: mfisher@dyn.com (Mark Fisher) Organization: The World @ Software Tool & Die Message-ID: References: <328062E5.41C67EA6@ksl.co.il> Reply-To: mfisher@dyn.com Sender: news@world.std.com (Mr Usenet Himself) Dani Gutzeit wrote: >We upgraded our VxWorks version from 5.1 to 5.2 > Now sometimes we have a problem when trying to open ( for write ) > a file on harddisk. > The task is stuck with following stack: >-> tt 0xaea324 > a240 _vxTaskEntry +10 : _x_main (0, 0, 0, 0, 0, 0, 0, 0, 0, 0) >38b1a2 _x_main +358: 38aaac (9c7de0) >38ac12 _setMainLoopSkip+1ac: _XtDispatchEvent (aea078) >d968fe _XtDispatchEvent+4a : d9667e (aea078) >d96860 __XtOnGrabList +284: d960c0 (aea078, c117c8, 8, 9c8adc) >d96338 __XtFreeWWTable+384: __XtTranslateEvent ([c117c8, aea078, 2fca00, >c1db10, 8]) >daf8dc __XtTranslateEvent+6a : daf706 ([c117c8, c117f4, ae9f42, 8, >aea078]) >daf830 __XtMatchAtom +9e4: daf032 ([c117c8, aea078, ac79a4, 0, 9b9ce8]) >daf0de __XtMatchAtom +292: df3ea8 (c117c8, aea078, 0, ac7fb0) >df3eca _XmCreatePanedWindow+186: df3f64 ([c117c8, aea078, 0, ac7fb0, >ae9ed8]) >df40c4 _XmCreatePanedWindow+380: _XtCallCallbackList ([c117c8, c12f94, >ae9e80, c117fc, 0]) >d8dc3c _XtCallCallbackList+36 : _diepSaveCB (c117c8, 0, ae9e80) >4a8000 _diepSaveCB +8a : _Save_Die_Parameters (a405c4, 565f6c) >a2a670 _Save_Die_Parameters+1ae: _Save_item_by_code (0, a405c4) >a15fcc _Save_item_by_code+16a: _dbSaveObject (ae9c16, a, c6d0a0) >a17858 _dbSaveObject +1c : _dbFopen (ae9bdc, ae9c16, a1783a) >a177d2 _dbFopen +10 : _fopen (ae9c16, a1783a) > c218 _fopen +34 : _open (ae9c16, 601, 1b6) > 28fce _open +82 : _iosOpen (fa06a0, ae9a90, 601, 1b6) > 29ce4 _iosOpen +32 : 57068 ([fa06a0, ae9a90, 601, 1b6, ae9c16]) > 570ea _dosFsModeChange+32e: 53f5c ([fa06a0, ae9a90, 1, 8, 5]) > 540e6 _dosFsConfigShow+3f0: 55d92 (fa06a0, fbd858, ae9a90) > 55efa _dosFsDevInitOptionsSet+1964: 546bc (fa06a0, c1cc2c, f390b4) > 54774 _dosFsDevInitOptionsSet+1de: _hashTblRemove (f70c88, f33d5c) > 28c2c _hashTblRemove +5c : _sllPrevious (f71590) > The task status is READY. >Can anybody help? >Thanks Dan, I saw this problem with sllPrevious() months ago -- it's some sort of linked list problem as I recall. The fix is to get the latest patch for the dosFsLib from WRS. Note this is not on their WEB page you have to contact someone at WRS and get them to send it to you. A support guy once told me that dosFsLib is the only part of the OS constantly in need of maintenance. I have also discovered a number of other problesm with dosFsLib over the last year or so. I would recommend to anyone who notices any disk I/O problems to get the latest dosFsLib from WRS before spending ANY time trying to debug it. Only if the problem persists with the lateset dosFsLib should you then try to replicate the circumstances and report it to WRS so they can find the problem. Mark. --------------------------- Newsgroups: comp.os.vxworks Subject: @@@>> HOT COLLEGE BI-MALES!!! >PRIVATE< 1-900-825-6000 xt 9794 Date: Mon, 04 Nov 1996 06:06:10 GMT From: Str8.Man@Nice.Folks.com Organization: Sprynet News Service Message-ID: <55k129$rd9@juliana.sprynet.com> HOT COLLEGE STR8, BI, AND GAY GUYS NEEDED FOR FRIENDS AND/OR RELATIONSHIPS! ALL AREAS! NOWHERE TO BIG OR SMALL FOR THE LOCATOR! ALL PRIVATE! ALL CONFIDENTIAL! ALL AGES! LADIES WELCOME! THE LOCATOR 1 - 9 0 0 - 8 2 5 - 6 0 0 0 xt 9 7 9 4 1 - 9 0 0 - 8 2 5 - 6 0 0 0 xt 9 7 9 4 1 - 9 0 0 - 8 2 5 - 6 0 0 0 xt 9 7 9 4 2.99/min --------------------------- Newsgroups: comp.os.vxworks Subject: Looking for public-domain NFS client Date: 7 Nov 1996 20:04:32 GMT From: watkins@spk.hp.com (Brian Watkins) Organization: Hewlett-Packard, Spokane Division Message-ID: <55tfcg$3e5@hpcvsnz.cv.hp.com> I have written a network driver that allows my VxWorks CPU to exchange IP frames with another CPU that is running pSOS+ instead of VxWorks. It appears that this version of pSOS+ does not include a working NFS client, which I was hoping to use for remote file access. Is anyone aware of a public-domain NFS client that can be made to work with pSOS+? Thanks in advance for any information. - -------------------------- Brian Watkins watkins@spk.hp.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Thu, 7 Nov 1996 21:04:03 GMT From: breti@bit3.com (Bret Indrelee) Organization: Bit 3 Computer Corp Message-ID: References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>, Mike Anderson wrote: >2) WRS's support capabilities are, I believe, typical of the industry. That > is to say, WRS has good people who mean well and are trying to fulfill > the support requirements of a *very* diverse community. Unfortunately, > I believe that there are too few support folks for the size of the user > base. Also, I have a feeling that there is a general lack of what I'll > refer to as "real-world" embedded systems development experience. Perhaps > the support folks should be cycled through the engineering department > to give them a better understanding of the O/S and its features. That may be, but their documentation could certainly use a rework. How come I don't find any mention of IVEC_TO_INUM when reading through intLib, intConnect, etc? It is only by chance that I stumbled on to the sysIntEnable() routine. Another annoyance is that none of the routines say which include files are needed. Sure, I have grep and can search the header files. I really would rather just look up the routine and find all the information I need to use it there. - -Bret - -- Bret Indrelee breti@bit3.com #include --------------------------- Newsgroups: comp.os.vxworks Subject: Re: intConnect for VMIC1182 and MVME167 Date: Thu, 7 Nov 1996 21:11:35 GMT From: breti@bit3.com (Bret Indrelee) Organization: Bit 3 Computer Corp Message-ID: References: <55le7f$cnh@llnews.ll.mit.edu> In article <55le7f$cnh@llnews.ll.mit.edu>, paula l ward wrote: >I am trying to connect a hardware interrupt from a VMIC 1182 digital >input board to an ISR running in vxWorks. My CPU bd is a MVME167. > >The interrupt register on the 1182 is set to 0x047b where 0x4 is the >int. level and 0x7b is supposed to be the int. vector. > >Here's my code in a nutshell but it doesn't work. Any help is greatly >appreciated. BTW, where does int. level 4 come into the picture? [ snip ] >int intVector=0x7B; /* interrupt vector number */ > #define VMEIRQX (4) [ snip ] >void init () >{ >intConnect(INUM_TO_IVEC(intVector) ,emerIsr); sysIntEnable(VMEIRQX); /* Enable VMEbus IRQ4* */ >semSync = semBCreate(SEM_Q_FIFO, SEM_EMPTY); >taskSpawn("tControl",76,0,5000,controlTask); >} [ snip ] Near as I can tell from the documenation, you need to enable the VMEbus interrupt (4 in your example) as shown. That is the impression the documentation gives me, although I haven't had a chance to try it out yet. - -Bret - -- Bret Indrelee breti@bit3.com #include --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 6 Nov 1996 20:00:24 -0800 From: kla@leland.Stanford.EDU (Earl Mitchell) Organization: Stanford University, CA 94305, USA Message-ID: <55rmso$hsl@elaine25.Stanford.EDU> References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>, Mike Anderson wrote: >Jim Jaskol wrote: > boards). I think Windview (especially when coupled with RTI's > Stethoscope product) is extremely useful, especially if you don't have > the bucks for an ICE. However, I'm not as bullish on Tornado. More > on that in a later paragraph. WindView is awesome if you have an application running several tasks with different priorities. The post mortem capabilities are great too. But its still a weak substitute for an ICE. With an ICE you become a god. ;-) WindView is useless for very time critical apps (i.e. response times less than say 2 milliseconds), but there are a large class of apps which don't have such tight constraints. Overall its a great tool. >3) As to BSPs, I seriously doubt that you could find an RTOS with more BSPs Very true, and their porting kit is very good. You can port their BSP to other platforms with very little hassle. >4) Now, what about Tornado? If you were to believe all of the press (and > the WRS salescritters), Tornado is a radically new development approach > that will revolutionize the industry. However, I believe that in an > effort to increase sales, improve the stock price, etc. that many at WRS > have lost sight of the *real* product. That is, the base VxWorks O/S > that runs on the target. Tornado seems to be well suited for the > development model of those large companies such as HP wherein they are > embedding VxWorks into a printer. That is, when you don't have much > RAM, no serial console ports, and maybe no Ethernet, then Tornado > represents a fine development environment *in theory*. And, I > believe, that the Unix implementation comes pretty close to realizing > that environment in practice. However, from what I've heard from the > net, I believe that there are some serious problems (memory leaks, etc.) > in the Tornado product under Win 95 & Win NT. One strategy behind doing Tornado was to scale down the BSP so it could be used for a bigger class of applications. So a lot of the tools were offloaded to the host. For example, VxWorks probably lost a lot of sales to QNX which is more scalable. Now they probably match up better with QNX. The integrated host environment has less benefit too me than scalability. My biggest knock against Tornado is before I could just plug in a vt100 to the serial port and go. Now I either need a UNIX box for WindSh or I have to jump thru some hoops to get the old configuration. For a lot of advanced users the added GUI stuff just gets in the way and slows you down. But a lot of guys like that fancy GUI stuff. > the board because of lack of cycles. Real-time programming is not > as simple as writing a database app. Should WRS have tried to move > Tornado to the 95 & NT platform? I believe that the answer is yes. > But, WRS needed to beef up their support organization to handle the > influx of calls from people just trying to grasp the basic concepts > of the RTOS. WRS had to support Win platform because that's the current trend ... to reduce cost by going PC. Hopefully, companies will wake up and demand a Linux platform instead which is far superior and cost effective. This is what happens when you let managers pick the tools engineers use instead of letting them decide for themselves. I've heard complaints from engineers who switched from UNIX to Win cross development platforms and they all complain about the lack of tools they had available on UNIX which either don't exist on Win or they were implemented half-assed. --------------------------- Newsgroups: comp.os.vxworks,comp.software.testing Subject: Porting Tcl Library to VxWorks! Date: Thu, 31 Oct 1996 17:12:31 -0700 From: "Loay (Louie) Abu-Husein" Organization: Color LaserJet and Consumable Division, R&D Labs Message-ID: <3279406F.1152@boi.hp.com> Has anyone out there ported the Tcl Library to VxWorks? - -- _/ _/ _/_/_/_/ Loay (Louie) Abu-Husein _/ _/ _/ _/ Intranet: http://hpbs4896.boi.hp.com/ _/_/_/_/ _/_/_/_/ Internet: http://www.boi.hp.com/ _/ _/ _/ EMail: mailto:loay@hpbs4896.boi.hp.com _/ _/ _/ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 8 Nov 1996 04:33:17 GMT From: vbv@giskard.cwru.edu ("Virgilio 'Dean' B. Velasco Jr.") Organization: Case Western Reserve Univ. Cleveland, Ohio (USA) Message-ID: <55ud6d$f7p@alexander.INS.CWRU.Edu> References: <32794C99.67F9@corp.disney.com> <327E0DB7.6513@med.ge.com> <55p1k6$24c@elaine25.Stanford.EDU> <3280BF21.41C67EA6@gdesystems.com> In article <3280BF21.41C67EA6@gdesystems.com>, Michael Levasseur wrote: >Notice anything perculur? There is this long indepth thread >and not a single post from Wind River!!!! Don't Wind River's >people look at the net. Aren't they in the 90's or are they still >working in a vacuum. I really don't think that's a fair criticism. True, they have not posted a reply; however, this does not mean that they aren't following the thread. Perhaps they wish to observe the thread first, in order to avoid biasing the discussion. - -- Virgilio "Dean" Velasco Jr, Department of Electrical Eng'g and Applied Physics graduate student slave, roboticist-in-training and Q wannabe http://dora.eeap.cwru.edu/vbv/vbv.html | Remember: Wise men still seek Christ. "And I shall shed my light over dark evil, for darkness cannot stand the light." --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Clarification Of Question - Re: Non Terminating TCP/IP Sockets Date: Fri, 01 Nov 96 16:09:26 GMT From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star Message-ID: <55e3b8$dro@idiom.com> References: <327503B6.7860@gic.gi.com> <32779160.3AF8@peacefulstar.oakland.ca.us> <3279F9DA.711@gic.gi.com> In article <3279F9DA.711@gic.gi.com>, rgilbet@gic.gi.com wrote: >When the SCO client is shutdown, the shutdown code does a kill -9 >on all the tasks communicating with the VxWorks based server (ugly >huh). Now, it seems that on some level, the client system "cleans up" >the socket connections to the server, except for 2 or 3 that just >linger. The fioRead call gets an error for those sockets that are >"cleaned up" and everything is OK, but I am still stuck with the >lingering connections. That is the part that I cannot figure out. Why >would some connections close fine, and others just vanish? OK, kill a process on Unix will close all sockets, which translates to PRU_DETACH in tcp layer. It's possible that some sockets remain in final graceful close state-machine (sockets will be in FIN_WAIT_1 or FIN_WAIT_2 or TIME_WAIT state), waiting for the other side to either ACK the FIN packets, or waiting for 2 * MSL (max segment lifetime) before timing out. This level of code is fairly complicated and some Unix kernels has had some bugs over the years. I'm not certain what SCO kernel does, but I've seen this kind of zombie sockets remaining in old SunOS kernels. The only way in Unix is to reboot! (In VxWorks, if this happens, you can clean up manually). Now, to avoid this problem, you can try to use SO_LINGER socket option with linger value set to 0. (Read setsockopt documentations on how to do this). If you set linger option to zero on your SCO side sockets, when kernel cleans up sockets for the processes that are being killed, the socket will be dropped. Instead of going through the FIN_1,2,TIME_WAIT sequence of state-transitions, you will be sending RST (reset) packet to the other side, which is more abrupt but a sure kill. If this doesn't help, you may have to add application specific close hand-shake in your code (send a message to the other side saying I'm closing, before actual close(), to prompt the other side to initiate the closing state-transition in its TCP), as well as properly shutdown() and close()'ing on SCO side. Good luck. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Serial ports 3+4 Date: 7 Nov 1996 13:37:13 GMT From: pjs@mc.com (Peter Satkwich) Organization: Mercury Computer System Message-ID: <55som9$ft9@newsy.mc.com> Reply-To: pjs@mc.com Does anyone have any information on using serial ports 3 and 4 on a mvme167 or mvme1604 board. --------------------------- Newsgroups: comp.os.vxworks Subject: Does vxWorks include echo server? Date: Thu, 7 Nov 1996 23:11:49 GMT From: "David W. Suh" Organization: Lucent Technologies, Denver Message-ID: <32826CB5.4B40@lucent.com> Sender: news@drnews.dr.lucent.com (Netnews Administration Login) Does vxWorks include an echo server at the well known UDP and TCP port 7? It probably does, but I need to verify this. - -- ================================================================================ David W. Suh Lucent Technologies dsuh@lucent.com ================================================================================ --------------------------- Newsgroups: comp.os.vxworks Subject: kbhit() equivalent Date: 7 Nov 1996 18:28:05 -0700 From: jmh@dante.as.arizona.edu (J.M. Hughes) Organization: Steward Observatory Message-ID: <55u2b5$j9@dante.as.arizona.edu> A little while ago someone asked about an equivalent function to the DOS "kbhit()" call to see when keyboard input was available. I recently encountered a situation where I need something like this as well, and found that there are at least 3 ways to do it: (1) create seperate threads for input and output so blocking is not an issue, (2) use the select() function call, and (3) use ioctl with the stdin file descriptor, which happens to be 0 (zero). I chose method 3 because I didn't want to worry about coordinating multiple threads, and select looked like serious overkill for what I was trying to do. ioctl seems to work just fine, as in: STATUS vwkbhit(void) { int nio; ioctl(0,FIONREAD,&nio); if (nio) return 1; return 0; } Enjoy. - -- - ------------------------------------------------------------------------------ John M. Hughes VOX: 520-621-7804 Senior Systems Programmer FAX: 520-621-3398 Steward Observatory, University of Arizona jmh@canopus.as.arizona.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Interrupt vectors and levels Date: 7 Nov 1996 14:28:36 GMT From: plward@ll.mit.edu (paula l ward) Organization: MIT Lincoln Laboratory Message-ID: <55srmk$69s@llnews.ll.mit.edu> Sender: plw@bart (paula l ward) I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with someone at WRS about interrupts and they gave me the impression that each interrupt level (1-7) could only be associated with a single vector. I was looking in the manuals though, and saw that vectors 61 through 255 were available to the user. How do you associate the same interrupt level with more than one vector? Or do you have to execute intConnect repeatedly and thereby connect it to different vectors? --------------------------- End of New-News digest ********************** From AS_Bridge@MSMAIL3.HAC.COM Fri Nov 8 05:38:34 1996 From: "AS Bridge" Date: Fri Nov 8 05:38:36 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: Re: Shared Memory? Sent: Fri, Nov 8, 1996 4:21 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Fri, Nov 8, 1996 5:37 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From basakc@diebold.com Fri Nov 8 06:05:24 1996 From: Chris Basak Date: Fri Nov 8 06:05:27 PST 1996 Subject: Want x86 device driver for removable mass storage devices I am interested in VxWorks device driver for removable mass storage devices such as Zip drives, JAZ drives, etc. My target is 486 PC. Can someone refer me to a vendor who provides such a driver? From leonid@rst.co.il Fri Nov 8 06:31:13 1996 From: leonid@rst.co.il (Leonid Rosenboim) Date: Fri Nov 8 06:31:16 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River In article <3280BF21.41C67EA6@gdesystems.com>, Michael Levasseur wrote: >Notice anything perculur? There is this long indepth thread >and not a single post from Wind River!!!! Don't Wind River's >people look at the net. Aren't they in the 90's or are they still >working in a vacuum. Note that the original posting which started this thread did not ask opinion from WRS, but from their users. Be confident that many people at Wind River are following this newsgroup and the exploder very very carefully, some of the senior managers read this list on a daily basis. Replying is a completely different issue. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-559-8144 R S T Software Industries Ltd. Fax: +972-3-559-8244 3 Hashikma st. Industrial Zone, E-Mail: leonid@rst.co.il P.O.Box 11502, AZUR 58017, Israel WWW: http://www.rst.co.il From tkb@mclean.sparta.com Fri Nov 8 06:43:55 1996 From: "Thomas K. Buchanan" Date: Fri Nov 8 06:43:57 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River >Another annoyance is that none of the routines say which include files >are needed. Sure, I have grep and can search the header files. I really >would rather just look up the routine and find all the information I >need to use it there. Try checking the SEE ALSO paragraph at the end of all manual entries. It's a pretty standard approach... adios ----------------------------------------- /\\ Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 7926 Jones Branch Drive / \\\\\ \\ Suite 900 \ \\\\\ // McLean, VA 22102 \ ////// \////// Voice: 703 448 0210 \//// FAX: 703 893 5494 \// WWW: www.mclean.sparta.com From tkb@mclean.sparta.com Fri Nov 8 06:55:08 1996 From: "Thomas K. Buchanan" Date: Fri Nov 8 06:55:11 PST 1996 Subject: Re: Interrupt vectors and levels >I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with >someone at WRS about interrupts and they gave me the impression that each >interrupt level (1-7) could only be associated with a single vector. I was >looking in the manuals though, and saw that vectors 61 through 255 were >available to the user. You can use any vector not already used by the processor or any device already running. Check the Motorola docs for the vectors in use by default. >How do you associate the same interrupt level with more than one vector? The vector is parameter passed to intConnect. You may call it repeatedly with different vectors on the same level. >Or do you have to execute intConnect repeatedly and thereby connect it >to different vectors? You can easily do what you want but spend a little time on system design first. Can you live with multiple devices on the same interrupt level? Will it be possible to service all devices in the worst timing case? Is there any problem with priority of VME interrupts versus locally generated interrupts? On the VMEbus, interrupters on the same level have an implied priority going from left to right across the backplane. Are your boards where they should be for your application? And on, and on, and on.... HTH ----------------------------------------- /\\ Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 7926 Jones Branch Drive / \\\\\ \\ Suite 900 \ \\\\\ // McLean, VA 22102 \ ////// \////// Voice: 703 448 0210 \//// FAX: 703 893 5494 \// WWW: www.mclean.sparta.com From john@bos.mcd.mot.com Fri Nov 8 07:17:12 1996 From: John Collins Date: Fri Nov 8 07:17:14 PST 1996 Subject: unsubscribe unsubscribe -- ****************************************************************** John Collins Account Executive PH (617) 932-6085 Motorola Computer Group FAX (617) 932-6125 300 Unicorn Park Woburn MA 01801 ****************************************************************** From AS_Bridge@MSMAIL3.HAC.COM Fri Nov 8 07:31:51 1996 From: "AS Bridge" Date: Fri Nov 8 07:31:53 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: comp.os.vxworks newsdigest Sent: Fri, Nov 8, 1996 6:27 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Fri, Nov 8, 1996 7:29 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From mea@mclean.sparta.com Fri Nov 8 07:33:10 1996 From: Mike Anderson Date: Fri Nov 8 07:33:12 PST 1996 Subject: Re: Interrupt vectors and levels At 04:00 AM 11/8/96 PST, you wrote: >From: plward@ll.mit.edu (paula l ward) >Organization: MIT Lincoln Laboratory >Message-ID: <55srmk$69s@llnews.ll.mit.edu> >Sender: plw@bart (paula l ward) > > >I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with >someone at WRS about interrupts and they gave me the impression that each >interrupt level (1-7) could only be associated with a single vector. I was >looking in the manuals though, and saw that vectors 61 through 255 were >available to the user. > This is impression about vectors and levels is *not* true. You can, in fact, have multiple interrupt *generators* at a given interrupt level. However, you can have only one interrupt *responder* (i.e., board that owns the ISR) at a given level. This enables you to have multiple, say, A/D boards at some interrupt level, such as 5, provided that they all generate different interrupt vectors. >How do you associate the same interrupt level with more than one vector? > >Or do you have to execute intConnect repeatedly and thereby connect it >to different vectors? > Yes. Here is a sequence to setting up a host CPU and 3 similar I/O boards at the same level: The interrupt level will be 5 and the vectors that they will generate are 0xa0, 0xa8, and 0xb0. These are arbitrary vector numbers that I just picked out of the air. You have an ISR called "myIoIsr" and you pass to it a parameter telling the ISR which "board" to look at. # Reset the boards and get them into a know state, programming Interrupt # levels and vectors if necessary (this may be in hardware jumpers on # some boards). *You* have to write this function if necessary. resetBoard0(); resetBoard1(); resetBoard2(); # Next, get the ISRs in place so that when you enable the Int Level, # you don't get a spurious interrupt message (just in case the I/O board # wasn't reset properly and still has an Interrupt hanging out there). # We use intLock/intUnlock just to be sure that one of those vectors # doesn't fire while we're installing the ISR. intKey = intLock(); intConnect(INUM_TO_IVEC(0xa0), myIoIsr, 0); intConnect(INUM_TO_IVEC(0xa8), myIoIsr, 1); intConnect(INUM_TO_IVEC(0xb0), myIoIsr, 2); intUnlock(intKey); # Now, enable the interrupt level from the bus. sysIntEnable(5); HTH, ============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235 // / \ \\ SPARTA, Inc. FAX : (703) 893-5494 // \ \\ 7926 Jones Branch Drive EMAIL : mea@mclean.sparta.com \\ \ // Suite 900 Web : http://www.mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." ============================================================================== From mea@mclean.sparta.com Fri Nov 8 07:50:57 1996 From: Mike Anderson Date: Fri Nov 8 07:50:59 PST 1996 Subject: Book(s) on VxWorks? Greetings! I've had several people ask me over the years (none of them from WRS) to consider the possibility of writing a book about VxWorks. To my mind, there should really be a couple of books. One should deal with the operational concepts of the O/S. Basically, an expanded Programmers Guide. Something that explains the RTOS from say, a Unix/Win NT/95 perspective so that folks coming into this market from non-real time programming environments can understand what's different about VxWorks and why it matters. In this book, I could see chapters on important issues being written by many of our primary net contributors and basically being edited for consistent flow. (How about it Stan, Fred, Leonid, et al.?) The second book is one that I've been lobbying for since I started using VxWorks in 1987. That book would essentially be a "VxWorks Bible" (ala "Turbo C Bible") wherein all of the VxWorks functions are described, the appropriate lib and .h files are referenced *and* a working example piece of code is shown for your edification and enjoyment. What thinks ye? I have no idea what the market for such a set of books would be. But I suspect that the model of the book "OS9 Insights" from the Microware folks would be a reasonable one to start with. That is, the books would definately have to have some form of WRS sanction/support (maybe even $$$). If you think you might have some ideas or interest in writing a chapter or so, drop me a note. Also, if you really think these books could be of some use, send your favorite WRS folks some e-mail about wanting these books to be developed. I doubt that it's going to happen without a swell of popular support from us, the user community. Regards, ============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235 // / \ \\ SPARTA, Inc. FAX : (703) 893-5494 // \ \\ 7926 Jones Branch Drive EMAIL : mea@mclean.sparta.com \\ \ // Suite 900 Web : http://www.mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." ============================================================================== From bff@dspcon.com Fri Nov 8 08:34:29 1996 From: bff@dspcon.com (Robert F. Franz) Date: Fri Nov 8 08:34:31 PST 1996 Subject: bootp,tftpd,ftpd I am looking for a PD or shareware version of bootp,tftpd, and ftpd which anyone has has success using to boot a vxWorks node from a WIN 95 machine. I would also like to get source code possibly so that I could customize it. I would like to say thank you in advance to anybody with any ideas. ------------------------------------------------------------------------------- DSPCon, Inc. -- leaders in digital signal processing solutions ------------------------------------------------------------------------------- Bob Franz 380 FootHill Rd. Bridgewater, NJ 08807 (908)722-5656 Fax:(908)722-3259 bff@dspcon.com ------------------------------------------------------------------------------- From lrichard@redwood.dn.hac.com Fri Nov 8 15:19:47 1996 From: lrichard@redwood.dn.hac.com (Larry Richards) Date: Fri Nov 8 15:19:49 PST 1996 Subject: unsubscribe From aaronn@telerobot.com Fri Nov 8 15:52:44 1996 From: aaronn@telerobot.com (Aaron Needles) Date: Fri Nov 8 15:52:47 PST 1996 Subject: Need STD32, x86 CPU board w/VxWorks support We have an immedate need for a x86 CPU board in STD32 format with VxWorks support (BSP). Please let me know if you know of any such boards (or likely manufacturers), or if you have had any good or bad experiences with these. Also, any pointers to Synchro/Resolver interface boards on STD32 or PC/104 would be appreciated. Thanks much, Aaron Needles aaronn@telerobot.com Schilling Robotic Systems, Inc. From daemon@csg.lbl.gov Sat Nov 9 04:00:31 1996 From: daemon@csg.lbl.gov Date: Sat Nov 9 04:00:34 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Nov 9 04:00:28 PST 1996 Subject: Re: Are you happy with Vx Works and Wind River Subject: Tornado Launcher Subject: Re: Seeking XDR functions/types Subject: Virtual to Physical address conversion. Subject: Re: how to writeassembly code for a pc target ? Subject: Re: Looking for public-domain NFS client Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Interrupt vectors and levels Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Looking for public-domain NFS client Subject: Re: HELP: How to get useful debug info out of an NMI interrupt? Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Thu, 07 Nov 1996 09:38:39 -0500 From: CK Wong Organization: Nortel Technology Message-ID: <3281F46F.3E61@nortel.ca> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <55r17b$ns7@xmission.xmission.com> Does Anyone has any experience and opinion on VxWorks regarding: 1. VxWorks on PowerPC 2. Backwork compatibility of VxWorks software releases, i.e. is the system computing model changes often enough to affect product development. --------------------------- Newsgroups: comp.os.vxworks Subject: Tornado Launcher Date: 8 Nov 1996 18:32:13 GMT From: fred.getz@lmco.com Organization: Lockheed Martin Federal Systems Message-ID: <55vubd$dq3@inetserv2.fs.lmco.com> Reply-To: fred.getz@lmco.com When I start the launcher the launcher window appears, but none of the bitmaps, buttons, or menu items appear. The targets and information list boxes do appear, but there is no title above either of them as shown in the Tornado User's guide. Obviously it's pretty useless this way. I also get a ton of translation error messages in the text window where start LAUNCH from. My host is a SPARC running Sun Solaris 2. I connect to the host via rlogin on an x-station and am trying to run the Tornado launcher at the x-station. I would appreciate any ideas on this. Fred Getz - Lockheed Martin Federal Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Seeking XDR functions/types Date: Fri, 8 Nov 1996 13:32:37 GMT From: noblenet@world.std.com (NobleNet Inc.) Organization: NobleNet, Inc. Message-ID: References: <55b90v$k93@hacgate2.hac.com> In article <55b90v$k93@hacgate2.hac.com>, wrote: >I am seeking some XDR functions/source to allow >data xport (socket based) between a VxWorks target >and a Unix host (AIX & Solaris). Please contact NobleNet for ONC/RPC tools and solutions for UNIX, Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc. NobleNet, Inc. 337 Turnpike Road Southboro, MA 01772 Voice +1 508 460 8222 Fax +1 508 460 3456 PRESS RELEASE For Immediate Release For Further Information, Please Contact: David Burns Vice President of Marketing NobleNet, Inc. Voice: (508) 460-8222 FAX: (508) 460-3456 e-mail: david.burns@noblenet.com "The Client/Server Toolkit for C and C++ Programmers" New Book From NobleNet Turns Programmers Into Client/Server Experts New York, October 8, 1996 -- NobleNet, Inc. today announced the availability of its newly published book that turns C and C++ programmers into client/server experts. Co-authored by middleware experts Steven Lemmo and Rich Grehan, The Client/Server Toolkit for C and C++ Programmers is a self- contained instructional tool that teaches programmers how to distribute any application or Application Programming Interface (API) across a network. The CD-ROM software included with The Client/Server Toolkit features a unique Windows-based client/server simulator that lets programmers gain hands-on experience in client/server partitioning. Programmers are guided through four "real-world" client/server projects: distributed ODBC database, scanner device, image engine, and datafeed. The authors expertise combined with a Rapid Application Development (RAD) environment, demystifies the art of distributing complex applications. "I learned more about client/server development in the last three days of reading your book than I learned in the past few years of doing C and C++ programming," said Pascal Specht, Technical Sales Engineer at Precision Software in Paris, France. "Our new book will help any C or C++ programmer that wants to learn about state-of-the-art client/server computing," said Steve Lemmo, co-author and Chief Technology Officer of NobleNet. "The techniques taught in the book will help programmers learn to use the powerful Interface Definition Languages (IDLs) found in today's most popular distributed computing middleware." Beginning with a monolithic application, readers learn how to separate programs into independent parts that communicate with each other. While other books on client/server computing include sample code, The Client/Server Toolkit goes further and delivers a true client/server Software Development Toolkit (SDK) designed for application partitioning. Unlike other approaches, programmers learn to build client/server applications using industry-standard RPC technology that requires no source code changes. "The Client/Server Toolkit is ideal for programmers that want to get a quick immersion into client/server computing with tools that require very little effort to learn," said Vincent Russo, Assistant Professor of Computer Science at Purdue University. "I like the fact that the book is totally self- contained. It has a wealth of real-world examples that provide the reader with a thorough understanding of client/server development. And the simulator gives programmers hands-on experience with building and running real client/server applications." Although The Client/Server Toolkit is written for C and C++ programmers, examples are given that show "drag and drop" programmers how to create client/server applications utilizing popular GUI front-ends such as Visual Basic, PowerBuilder, Delphi, and Developer 2000. Distributed with the book is a free version of NobleNet's powerful standards-based RPC product used by client/server developers world-wide. Programmers are presented with client and server Windows connected by a simulated network. Using NobleNet RPC, applications developed on the simulator are easily deployed to over 40 platforms including 26 UNIXes, Windows 3.1, 95, and NT, NetWare, Macintosh, OS/2, and VMS. More than 20 Windows-based TCP/IP stacks are supported to ensure operation in existing multi-vendor environments. Co-author Steven Lemmo founded NobleNet, engineered NobleNet's first software product, EZ-RPC(R), and led the team that developed the company's NetWare and Windows-based middleware tools. With an in-depth understanding of both communication and application software, he is a sought after consultant on RPC programming. Steve has over fifteen years of experience in software engineering and tools development in companies such as Computervision Corp., Sun Microsystems, Inc., and Xerox Imaging Systems, Inc. He is widely recognized as an expert on distributed computing and is frequently called upon to appear at industry forums. Co-author Rick Grehan has been on the editorial staff of BYTE Magazine for over 11 years. He is currently the Technical Director of BYTE Labs and the author of BYTE's monthly CodeTalk column. His articles have appeared in BYTE, Embedded Systems Programming, and Forth Dimensions. In addition, he was a contributor to the 1993 edition of The Encyclopedia of Microcomputers, published by Marcel Dekker, Inc. Rick is also the designer of BYTE Magazine's BYTEmark benchmark suite. The Client/Server Toolkit for C and C++ Programmers is published by NobleNet. The 350 page book with CD-ROM can be ordered for $49.95 by calling (800)-250- 6427 or (508)-893-0398. NobleNet offers tools for distributed client/server development for procedural and object paradigms. Incorporated in 1991, NobleNet is a world leader in Remote Procedure Call (RPC) technology and has won numerous awards for its RPC product family. NobleNet also distributes IONA Technologies' industry- leading "Orbix" CORBA-compliant Object Request Broker. The company is headquartered in Southboro, MA, and can be reached at (508) 460-8222 or at . --------------------------- Newsgroups: comp.os.vxworks Subject: Virtual to Physical address conversion. Date: Mon, 04 Nov 1996 17:57:11 +0200 From: Casey Crellin Organization: CCII Systems Message-ID: <327E1257.65792670@ccii.co.za> Hi, I would like to convert an addrtess from virtual to physical. Similar to the unix ktop() or vtop() functions. How do I do this? I see in the manuals there is a vmContextShow() whose output includes both physical and virtual addresses. I would imagine I owuld use the sysPhysMemDesc[] But how? Thanks Casey - -- Casey Crellin casey@ccii.co.za CCII Systems (Pty) Ltd - ----------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: how to writeassembly code for a pc target ? Date: 8 Nov 1996 16:51:56 -0700 From: softweyr@xmission.xmission.com (Softweyr LLC) Organization: XMission Internet (801 539 0900) Message-ID: <560h2s$iga@xmission.xmission.com> References: <327FBB4E.7FCC@utrc.utc.com> Farooq Bari wrote: : I am using a pc target with an NT host. I am interested in directly : accessing and writing to 486 or 586 registers on the pc target. Does : tornado compiler support inline assembly code ? I could not find any : sample code or documentation on this. will appreciate any help in this : regard. The GNU compilers certainly do. You'll need to be careful that your in- line code doesn't clash with the optimizer, which makes very effective use of registers. It is often difficult to determine exactly what each register is being used for, so if you're not certain, better save the register before using it. - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Looking for public-domain NFS client Date: 8 Nov 1996 17:22:31 -0700 From: softweyr@xmission.xmission.com (Softweyr LLC) Organization: XMission Internet (801 539 0900) Message-ID: <560is7$p7u@xmission.xmission.com> References: <55tfcg$3e5@hpcvsnz.cv.hp.com> Brian Watkins wrote: : I have written a network driver that allows my VxWorks CPU to exchange : IP frames with another CPU that is running pSOS+ instead of VxWorks. It : appears that this version of pSOS+ does not include a working NFS client, : which I was hoping to use for remote file access. Is anyone aware of a : public-domain NFS client that can be made to work with pSOS+? FreeBSD, a freely available OS based on 4.4BSD-Lite, includes an implementation of NFS, both client and server. It is distributed with a Berkeley-style copyright that allows you to use the code as you wish. Check out http://WWW.FreeBSD.ORG for more info. - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Mon, 4 Nov 1996 16:31:26 GMT From: gerlach@netcom.com (Matthew H. Gerlach) Organization: Netcom Online Communications Services (408-241-9760 login: guest) Message-ID: References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> Sender: gerlach@netcom23.netcom.com In article <327E0DB7.6513@med.ge.com> Steve Woloschek writes: >I second Steve's comments. But most of my problems stem >from the fact that WRS uses GNU tools. IMOH, this is a real >downfall. Interesting, my experience with GNU tools in general has been great, and Wind River's use of the GNU tools, IMHO is a compelling reason to use VxWorks. Matthew --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Interrupt vectors and levels Date: Fri, 08 Nov 1996 14:41:30 -0500 From: "Bruce K. Gitlin" Message-ID: <32838CEA.253C@wl.corning.com> References: <55srmk$69s@llnews.ll.mit.edu> paula l ward wrote: > > I am running Tornado 1.0 with the MVME167 bd. A short while ago I spoke with > someone at WRS about interrupts and they gave me the impression that each > interrupt level (1-7) could only be associated with a single vector. I was > looking in the manuals though, and saw that vectors 61 through 255 were > available to the user. > > How do you associate the same interrupt level with more than one vector? > > Or do you have to execute intConnect repeatedly and thereby connect it > to different vectors? Here's how I understand interrupts. The vector and level are separate beings. IntConnect is used to connect a vector to a routine that is run when an interrupt occurs, regardless of the level. If you had a timing board, for instance, and you wanted to send an interrupt to the CPU, you would set up the board to interrupt at whatever level you decided on, let's say 2. You would then have to let the timing board know what vector you were using. On the CPU, you would use intConnect to let the system know what to execute when an interrupt with that vector is received. That interrupt can be at any level that is enabled using sysIntEnable, which in our example would be 2. At the right time, the board would generate a level 2 interrupt with your chosen vector. The CPU would execute the code that the vector pointed to, and your off and running. If you wanted to change to level 4 (but keep the same vector), the only thing required on the CPU is to sysIntEnable (4). The rest would be changed on the timing board. Hope that helps, Bruce - -- ============================== || Bruce K. Gitlin || || CTG / Corning || /)| (910)397-8204 |(\ / )| gitlin_bk@wl.corning.com |( \ ( (==============================) ) (((\ \) /,) / ) (/ //)) (\\\\ \_/ / \ \_/ ///// \ / \ / \ _/ \_ / - ----/ /--------------------------\ \---- / / \ \ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Fri, 08 Nov 1996 22:21:03 GMT From: mhayashibara@ccgate.hac.com (Matthew Y. Hayashibara) Organization: Hughes Aircraft Company Message-ID: <560boi$42q@hacgate2.hac.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> <55md5u$5b@idiom.com> Reply-To: mhayashibara@ccgate.hac.com chaos@idiom.com (H.J. Bae) wrote: >GNU toolchain certainly works better than any other >cross-deveopment tools I've used, including pSOS with >MRI tools. The MRI tools have gotten worse by the day, too. I f you haven't been following the threads on comp.arch.embedded a few months ago, their new PC licensing scheme is the absolute worst. The Mentor buyout of pSOS was the last straw. >Have you actually used those tools? >You can't be serious. Maybe it's just our location, but at a short contract I had at JPL, and here at Hughes in Fullerton, getting Russ Eigle or Corey Hutchins (he recently left to do sales in the Rockies) on the phone at the WRS office in Laguna Hills, and now Irvine, isn't that difficult. They have spent some time on-site, too. We got no support whatsoever from ISI or Microtec with pSOS at my last contract, and we had to come up with a bunch of our own workarounds, which was very expensive schedule-wise. Mat Hayashbara --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Looking for public-domain NFS client Date: Fri, 08 Nov 1996 10:24:44 +0100 From: Philippe Le Foll Organization: France Telecom Interactive Message-ID: <3282FC5C.4BD33D25@eurobretagne.fr> References: <55tfcg$3e5@hpcvsnz.cv.hp.com> Check for SUN version, the code is in public domain you should find this on sunsite true ftp anonymous. I port a part of it (RPC?XDR) on NT and the code is quite simple. phillf@iu-vannes.fr Brian Watkins wrote: > > I have written a network driver that allows my VxWorks CPU to exchange > IP frames with another CPU that is running pSOS+ instead of VxWorks. It > appears that this version of pSOS+ does not include a working NFS client, > which I was hoping to use for remote file access. Is anyone aware of a > public-domain NFS client that can be made to work with pSOS+? > > Thanks in advance for any information. > > -------------------------- > Brian Watkins > watkins@spk.hp.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: HELP: How to get useful debug info out of an NMI interrupt? Date: Fri, 08 Nov 1996 13:30:08 -0800 From: John Finley Organization: Netcom Message-ID: <3283A660.4BBF@finley.com> References: <3280A6C0.77A2@inigo.us.dg.com> Reply-To: john@finley.com Yamudda Wezamibootz wrote: > Any thoughts out there? Thanks. Sometimes I like to set aside some memory that the OS doesn't know about, then sprintf debug messages to it. After it dies, you reboot and go look at the memory. The OS can't know about the memory so it won't zero it when it boots. Also, if the memory is DRAM, then there are who's-doing-the-refresh considerations. John - -------------------------------------------------- John Finley Engineering Consultant john@finley.com Real Time Systems (619) 689-0032 Networking Protocols - -------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Fri, 8 Nov 1996 23:24:40 GMT From: breti@bit3.com (Bret Indrelee) Organization: Bit 3 Computer Corp Message-ID: References: <2.2.32.19961108144450.006ce4c0@mailhost.mclean.sparta.com> In article <2.2.32.19961108144450.006ce4c0@mailhost.mclean.sparta.com>, Thomas K. Buchanan wrote: >>Another annoyance is that none of the routines say which include files >>are needed. Sure, I have grep and can search the header files. I really >>would rather just look up the routine and find all the information I >>need to use it there. > >Try checking the SEE ALSO paragraph at the end of all manual entries. It's >a pretty standard approach... Yeah, it is a standard approach. Was also exactly what I was looking for. I double checked. It seems that they only list Include Files (just above the See Also) for the libraries, never the individual routines. IntArchLib has the section at the end of it, but intConnect doesn't. For some reason, I never noticed it at the end of the library man pages. Thanks, - -Bret - -- Bret Indrelee breti@bit3.com #include --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Mon, 04 Nov 96 19:46:33 GMT From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star Message-ID: <55md5u$5b@idiom.com> References: <32794C99.67F9@corp.disney.com> <55eecn$oj7@herald.concentric.net> <327E0DB7.6513@med.ge.com> GNU toolchain certainly works better than any other cross-deveopment tools I've used, including pSOS with MRI tools. Have you actually used those tools? You can't be serious. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- End of New-News digest ********************** From tkb@mclean.sparta.com Sat Nov 9 08:49:57 1996 From: "Thomas K. Buchanan" Date: Sat Nov 9 08:49:59 PST 1996 Subject: Re: Tornado Launcher >When I start the launcher the launcher window appears, but none of the bitmaps, buttons, or menu items appear. >The targets and information list boxes do appear, but there is no title above either of them as shown in the >Tornado User's guide. Obviously it's pretty useless this way. I also get a ton of translation error messages in the >text window where start LAUNCH from. My host is a SPARC running Sun Solaris 2. I connect to the host via rlogin >on an x-station and am trying to run the Tornado launcher at the x-station. I would appreciate any ideas on this. You are having permission problems with some of the Tcl stuff. Look in the vw/host/resource tree for files w/o read permissions for everyone. Wind River ships Tornado with permissions setup for a user and group specified at order time. Many files have no 'world' permissions at all. If you like not having world permissions on those files, you'll have to straighten out your group permission setup. Check with the system administrator. HTH ----------------------------------------- /\\ Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 7926 Jones Branch Drive / \\\\\ \\ Suite 900 \ \\\\\ // McLean, VA 22102 \ ////// \////// Voice: 703 448 0210 \//// FAX: 703 893 5494 \// WWW: www.mclean.sparta.com From daemon@csg.lbl.gov Sun Nov 10 04:00:30 1996 From: daemon@csg.lbl.gov Date: Sun Nov 10 04:00:32 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Nov 10 04:00:25 PST 1996 Subject: MVME 160X Users Subject: Delta-Tau PMAC Driver Subject: VME memory cards Subject: Re: Seeking XDR functions/types Subject: NTP on VxWorks 5.2 and/or 5.3 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: MVME 160X Users Date: Tue, 05 Nov 1996 09:35:54 +0000 From: Doug Owens Organization: Lawrence Livermore National Lab Message-ID: <327F0A0C.DE5@llnl.gov> Reply-To: owens2@llnl.gov Does the MV1603/4 board from Motorola have L2 cache available? There literature is a little vague on this issue. Thanks, Doug Owens (owens2@llnl.gov) --------------------------- Newsgroups: comp.os.vxworks Subject: Delta-Tau PMAC Driver Date: 9 Nov 1996 14:28:49 -0500 From: atathert@mtu.edu (Adam T. Atherton) Organization: Michigan Technological University Message-ID: <562m1h$1lf@maxwell14.ee> I am working on a student project using the PMAC board, and if possible I would like a copy of the driver too. Thanks, Adam Atherton atathert@mtu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: VME memory cards Date: 6 Nov 1996 19:07:30 GMT From: bhanson@bnr.ca (Brian Hanson) Organization: Bell-Northern Research Ltd. Message-ID: <55qnli$ls5@crchh327.rich.bnr.ca> Hi all, Does anyone had any experience(good/bad) using VME memory cards to expand local RAM? I am using Motorola MV167 and MV162 cards in a shared memory network configuration. I am interested in any problems/issues people may have encountered, along with any hints or advice. Any information is appreciated. Thanks, Brian Hanson bhanson@nortel.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Seeking XDR functions/types Date: 6 Nov 1996 14:29:28 -0700 From: softweyr@xmission.xmission.com (Softweyr LLC) Organization: XMission Internet (801 539 0900) Message-ID: <55qvvo$juh@xmission.xmission.com> References: <55b90v$k93@hacgate2.hac.com> scott@tcville.es.hac.com wrote: : I am seeking some XDR functions/source to allow : data xport (socket based) between a VxWorks target : and a Unix host (AIX & Solaris). Do you want XDR, or XDR-like functionality? I have a sample C++ class whose purpose is to allow the programmer to easily serialze and deserialize data packets of arbitrary structure; we use it for both serial and LAN connections. I've used it on VxWorks, FreeBSD, and HP-UX (so far). I'll gladly e-mail or post it if you wish. - --- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: NTP on VxWorks 5.2 and/or 5.3 Date: Wed, 06 Nov 1996 12:03:06 -0800 From: Gary Steven Fish Organization: Hughes Aircraft Co. WSS/NAMS Message-ID: <3280EEFA.38EF@ccgate.hac.com> Does anyone have a port or information on a port of ntp to VxWorks 5.2 and/or 5.3. I know there is a port of ntp3.1 to VxWorks 5.02 on the VxWorks Archive, and I have that as a starting point. I understand that there may be some issues with functions need by the current port of ntp (to the VxWorks 5.02 version) that are not available in the VxWorks 5.2 version now that some functionality has moved up to the POSIX standards. If you have any Information on this topic, please respond. Thanks in advance, Gary S. Fish Hughes Aircraft Co. --------------------------- End of New-News digest ********************** From prb@aplexus.jhuapl.edu Mon Nov 11 05:04:09 1996 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Mon Nov 11 05:04:11 PST 1996 Subject: Re: Are you happy with Vx Works CK Wong writes: > > Does Anyone has any experience and opinion on VxWorks regarding: > > 1. VxWorks on PowerPC > Irregardless of what OS that you use for PowerPC, I strongly recommend that you check out the eratta on the Universe PCIbus to VMEbus bridge chip. The Universe bridge chip is used on practically every PowerPC VMEbus board. Visit Tundra's web page to find the list of eratta: http://www.tundra.com/ Also, if you want to get the best performance using vxWorks on PowerPC then you might want to consider the GreenHills compiler. This definitely gave us a noticeable boost in our number crunching algorithms. +====================================================================+ | __ ____ __ __ | | /\ \ / \ \ /\_\__ /\ \ Johns Hopkins University | | / \_\ | /\ \ \ / / /\_\\ \ \ Applied Physics Lab. | | / /\ | |\ \/ \ \ / / / / / \ \ \ | | / \/ |_| \ /\ \_\ / / / / / \ \ \ Paul R. Bade | | / /\__/_/ \ \ \/_// / / / / / / / (301)-953-6000 x8681 | | / / / \ \_\ \ \/ / / / / / prb@aplexus.jhuapl.edu | | \/_/ \/_/ \__/_/ \/_/ | | __ ____ __ __ | | /\ \ / \ \ /\ \ /\ \ | | / \_\ | /\ \ \ / \_\ / \ \ | | / /\ | |\ \/ \ \ / /\ |_| / /\ \ \ | | / \/ |_| \ /\ \_\ / / / | | \/ / \ \ | | / /\ / / \ \ \/_// / / / / / /\ \_\ | | \ \/ / / \ \_\ \ \/ / / \/ / / / | | \__/_/ \/_/ \__/_/ /_/_/ | | | +====================================================================+ From al@columbia.mcd.mot.com Mon Nov 11 07:23:52 1996 From: Al Currano Date: Mon Nov 11 07:23:55 PST 1996 Subject: Re: Cache on MVME1603/1604 Boards the vxWorks Users Group Exploder wrote: > > Newsgroups: comp.os.vxworks > Subject: MVME 160X Users > Date: Tue, 05 Nov 1996 09:35:54 +0000 > From: Doug Owens > Organization: Lawrence Livermore National Lab > Message-ID: <327F0A0C.DE5@llnl.gov> > Reply-To: owens2@llnl.gov > > Does the MV1603/4 board from Motorola have L2 cache available? There > literature is a little vague on this issue. > > Thanks, > Doug Owens (owens2@llnl.gov) > Yes, Doug, the MVME1603 / 1604 boards are available with L2 Cache. When these boards were first introduced about two years ago, there was no cache option. Since then, however, a number of models have been introduced with 256K L2 Cache. (Unfortunately, the data sheets & Web pages don't have all of the information. I will try to get this rectified.) The MVME1603 is available in both 100 MHz and 200 MHz clock speeds with 256K L2 Cache. Part numbers are MVME1603-04x, -05x, -06x and -07x. The different suffixes correspond to different I/O pinouts, clock speeds & main memory sizes (the "x" can be 1, 2, 3 or 4, corr. to main memory sizes of 8, 16, 32 and 64 MB). The MVME1604 is available in the 133 MHz clock speed with 256K L2 cache. Part numbers are MVME1604-02x and MVME1604-03x. Contact your local sales office (408) 991-8634 for more information. Regards, Al -- Al Currano _/ _/ _/_/_/_/_/ _/_/_/_/_/ al_currano@mcg.mot.com _/_/ _/_/ _/ _/ _/ _/ Motorola Computer Group _/ _/_/ _/ _/ _/ 8945 Guilford Rd., Ste 145 _/ _/ _/ _/ _/ Columbia, MD 21046 _/ _/ _/ _/ _/_/ Phone: (410) 312-5930 _/ _/ _/ _/ _/ _/ FAX: (410) 381-4496 _/ _/ _/_/_/_/_/ _/_/_/_/_/ From genard@imaginet.fr Mon Nov 11 07:46:01 1996 From: genard@imaginet.fr (genard michel) Date: Mon Nov 11 07:46:03 PST 1996 Subject: hello salut Philippe, je suis dans de nouvelle avneture avec ATI (nucleus) www.atinucleus.com les bureaux sont a courtabouef (on reveint toujours sur les leiux du crime) tel 01 60 92 41 11 salut, pardon kenavo et j espere que toute ta famille va bien, michel +---------------------------------+----------------------------------+ | genard@imaginet.fr | tel/voice +33 2 54 88 25 36 | | Michel Genard | fax +33 2 54 88 50 10 | | mobile +33 6 07 44 84 70 | +---------------------------------+----------------------------------+ ************** N E W P H O N E # Take a Look ! ******************* From letchu@zeke.as.utexas.edu Mon Nov 11 10:28:52 1996 From: Lakshmanan Narayanan Date: Mon Nov 11 10:28:54 PST 1996 Subject: unsubscribe unsubscribe =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lakshmanan Narayanan (Letchu) Email: letchu@zeke.as.utexas.edu McDonald Observatory URL : http://zeke.as.utexas.edu/letchu University of Texas at Austin Voice: 512-471-7450 Austin, TX 78751. Fax : 512-471-6016 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From YF.Siu@eng.efi.com Mon Nov 11 11:03:24 1996 From: "Yuet Fung Siu" Date: Mon Nov 11 11:03:30 PST 1996 Subject: ATA2 IDE driver wanted ? Anyone that's kind enough to share the source of an ATA-2 IDE CD-ROM driver for VxWorks ? Thanks, YF From dfraser@wrs.com Mon Nov 11 18:08:16 1996 From: David Fraser Date: Mon Nov 11 18:08:18 PST 1996 Subject: Are you happy with VxWorks (Apologies if your get a duplicate of this message directly on comp.os.vxworks. We've had some weirdness from our news server forwarding correctly) Dear Users, Everyone here at Wind River has been following this particular thread very closely. Far from ignoring the newsgroup and exploder, I think that all of us see it as a vital link to the user community. It's become something of an informal policy of ours, however, not to make too many postings. We have in mind the double-edged sword of communication which can classify us either as being defensive or involved in shameless self-promotion. But we're ready and willing to respond more immediately if that's what you want from us, and we think it appropriate. Since I've started, I probably should comment on the main issues that seem to have surfaced in this thread: the functionality/usability of Tornado, and our support capability. As VP Engineering, with the responsibility for Customer Service this is, after all, what I'm paid to worry about! First of all, Tornado has been out for just about a year and was a big effort for our company. As a medium-sized outfit, Wind River definitely regards a ~50 engineering year effort as significant, although for many of you out there these would be small projects! Far from being some piece of "marketing fluff" as some have suggested, we engineers here had some definite goals in mind for Tornado, over and above our traditional focus on making VxWorks a capable OS. These goals were (a) to make high end development tools work on very small scale systems (little memory, no Ethernet, for example) (b) to make the system customizable and extensible so that it could be modified by our customers to make it work in as productive a manner as possible and (c) to define and publish an API to the tool framework so that all manner of development tools could be brought to bear on the engineering problem at hand. Whether you agree or disagree that these goals were smart priorities or not, that's what Tornado was all about and that's what the project came up with. But it doesn't mean we're abandoning any focus on the RTOS, which is after all one of our crown jewels - we have lots of new things in the pipe there! We decided on these goals specifically to encourage innovation in the tools arena and to make everything work on the deeply embedded systems that many of our customers are working with. Of course, we have a huge and growing number of users with VME targets and other resource rich hardware that may not care about the host-based tools. But we believe the new architecture of Tornado will bring about several advantages for these users also. After all, the unlimited "headroom" on the host will allow us to do really fancy things with the shell, linker, etc. that the target-based approach penalized us too heavily for. And already goals (b) and (c) are making all manner of new tools available from our partners, which is perhaps the thing that I'm most excited about. Beyond this, the embedded world has changed enormously. There are many, many more embedded developers entering our community, as people take advantage of newer and cheaper microprocessors to build all manner of leading edge products. We've tried to serve these newer developers by making Tornado available on Windows (as many come from this space) and to make the tools easier to drive by using GUI facilities. Of course, power users can still dive into the command line if they wish! With the health of this embedded business comes the challenge of extreme growth. Wind River is growing sales at almost 50% per year, and this astonishing pace translates into lots of new users expecting support. This is our biggest challenge, and everyone in the executive staff at Wind River is cognizant of it. Our Customer Support operation is composed of smart and committed individuals, but we need to constantly staff up to handle the demand. We're hiring as quickly as we can, both junior support engineers and senior people with real world embedded experience, but these people are hard to find. We'll continue to hire the best we can find, and spend as much as it takes on new tools and technologies to improve our responsiveness. Additionally we are increasing our emphasis on maintenance releases within R&D, and placing more support function out in our field to be "closer to the customer". Today the ratio of R&D to service is about 2:1 and I would expect the service content to increase as we move forward. Finally, please accept my thanks on behalf of everyone at Wind River for your comments. If there's something that I think sets Wind River apart from most of the companies I've ever worked for it's that we are enthusiasts for our technology: we want to make the best products and services that we can. Our outstanding low level of attrition speaks highly to how committed and long term a team we have here working on that objective. Your feedback is essential at helping us. Regards, David Fraser VP Engineering, Wind River Systems From malcolm.cifuentes@nautronix.com.au Mon Nov 11 19:16:35 1996 From: malcolm.cifuentes@nautronix.com.au (Malcolm Cifuentes) Date: Mon Nov 11 19:16:37 PST 1996 Subject: GNU Development Hi all, I would like to know : 1/ Is any one doing development on the PPC using the GNU compiler in tornado. 2/ What steps did you take to get around the IOSTREAMS problem. 3/ Does any one know if the Wind Foundation Classes can be used with the GNU compiler, and if so is any one using this combination. thanks in advance -- Malcolm Cifuentes ( Nautronix LTD malcolm.cifuentes@nautronix.com.au PH : +61-09-430-5900 FAX : +61-09-430-5901 ) From daemon@csg.lbl.gov Tue Nov 12 04:00:25 1996 From: daemon@csg.lbl.gov Date: Tue Nov 12 04:02:34 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Nov 12 04:00:23 PST 1996 Subject: Re: Are uou happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are you happy with Vx Works and Wind River Subject: Are you happy with VxWorks Subject: RAID max size? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are uou happy with Vx Works and Wind River Date: 10 Nov 1996 12:34:16 -0800 From: chaos@idiom.com (H.J. Bae) Organization: Peaceful Star, Oakland, CA Message-ID: <565e88$6q7@idiom.com> References: <565e0f$5a0@idiom.com> Apparently I'm nobody@nowhere, according to my brilliant Windoze news-program. In article <565e0f$5a0@idiom.com>, wrote: I don't mean to sound like an apologizer for Tornado, because I don't use Tornado IDE due to its bugs, but blaming WRS for trying to make money on their product by hyping it is like blaming the Pope for being against abortion. It's the nature of business. The fact is, even with all bugs and misfeatures, VxWorks is the best RTOS in existence. Unless someone comes out with something better, we're stuck with it. The thing to do, then, is to encourage WRS to fix problems. I am frequently accused of being negative on WRS for exposing VxWorks problems. I am also accused of bashing WRS for selling out to military market. I'm guilty of both. Although I'm less critical on the latter part now, because WRS doesn't seem to depend as much on military customers. However, I'd never accuse WRS for hyping their product. It's all BS, but that's what marketing is. I'd rather hope that WRS will fix a number of fundamental problems: 1. broken stdio architecture. The ioGlobalStd stuff has to go. I've seen too many people lose their mind over this. 2. broken filesystem architecture -- vxWorks does not have one. All filesystems are implemented as IO drivers and libraries. This creates a number of annoying problems and breaks consistent interface for simple things like ls(). 3. non-reentrant target shell. Tornado adds bandages to this problem by allowing multiple instantiations of tcl infused shell-lookalikes. This breaks the consistency of user interface even more -- for example, i() implemented in tcl vs. i() implemented in C -- there is no reconciliation or attempt to resolve oddities that arise from this. 4. use of #include on C files in the config/all files. #include is meant for H files not C files. This creates subtle problems, and there are cleaner alternatives. 5. techsupport. It's terrible. etc. I could go on and on... - -- http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: 11 Nov 1996 18:30:35 -0800 From: kla@leland.Stanford.EDU (Earl Mitchell) Organization: Stanford University, CA 94305, USA Message-ID: <568ngb$nb6@elaine25.Stanford.EDU> References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> In article , Bret Indrelee wrote: >In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>, >Mike Anderson wrote: >Another annoyance is that none of the routines say which include files >are needed. Sure, I have grep and can search the header files. I really >would rather just look up the routine and find all the information I >need to use it there. Look up the routine in the reference manual. You include the .h file corresponding to the library the routine is defined in. For example, to use "sigvec" you include "sigLib.h" because this routine is defined in "sigLib". Foreach function the manual tells you what lib its in. The old manuals said explicity which .h file to include. Now its implicit in the name of the library (i.e. just add .h to lib name). Don't know why they did it this way but its not that big a deal. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 1996 08:35:37 -0600 From: Steve Woloschek Organization: GE Medical Systems Message-ID: <3280A239.2CD2@med.ge.com> References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> I would have suggested the complete opposite of Mike's comment. My opinion is that vxWorks is best suited for a large embedded project. One that has ethernet and lots of Flash and RAM. An ethernet or serial connection is exactly how WRS wants you to debug. This scenario doesn't work well in a smaller embedded environment, i.e. limited RAM/Flash, no ethernet, no serial. It took me a number of phone calls to WRS and a lot of investigation of a BSP do get the vxWorks kernel down from 120k to 50k. This is large for some embedded environments. Steve Woloschek > Mike Anderson wrote: > > 4) Now, what about Tornado? If you were to believe all of the press (and > the WRS salescritters), Tornado is a radically new development approach > that will revolutionize the industry. However, I believe that in an > effort to increase sales, improve the stock price, etc. that many at WRS > have lost sight of the *real* product. That is, the base VxWorks O/S > that runs on the target. Tornado seems to be well suited for the > development model of those large companies such as HP wherein they are > embedding VxWorks into a printer. That is, when you don't have much > RAM, no serial console ports, and maybe no Ethernet, then Tornado > represents a fine development environment *in theory*. And, I > believe, that the Unix implementation comes pretty close to realizing > that environment in practice. However, from what I've heard from the > net, I believe that there are some serious problems (memory leaks, etc.) > in the Tornado product under Win 95 & Win NT. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 06 Nov 1996 08:40:24 -0600 From: Steve Woloschek Organization: GE Medical Systems Message-ID: <3280A358.6F0@med.ge.com> References: <9611052007.AA27240@wgsu13.kns.com> > because I've been waiting for a quote from the sales guy for over a month. > > Joe DeAngelo And you can expect the sales rep to never call you again after you sign the deal. I left a message with ours 2 months go. Apparently there is no follow up to see how things are going after the deal has been signed. WRS also owes me some code that is more than 2 months overdue past the original agreed upon date. Steve Woloschek --------------------------- Newsgroups: comp.os.vxworks Subject: Are you happy with VxWorks Date: 8 Nov 1996 20:25:24 GMT From: "David Fraser" Organization: Wind River Systems Message-ID: <01bbcdb3$e358ac60$0e2b0b93@abyss.wrs.com> Dear Users, Everyone here at Wind River has been following this particular thread very closely. Far from ignoring the newsgroup and exploder, I think that all of us see it as a vital link to the user community. It's become something of an informal policy of ours, however, not to make too many postings. We have in mind the double-edged sword of communication which can classify us either as being defensive or involved in shameless self-promotion. But we're ready and willing to respond more immediately if that's what you want from us, and we think it appropriate. Since I've started, I probably should comment on the main issues that seem to have surfaced in this thread: the functionality/usability of Tornado, and our support capability. As VP Engineering, with the responsibility for Customer Service this is, after all, what I'm paid to worry about! First of all, Tornado has been out for just about a year and was a big effort for our company. As a medium-sized outfit, Wind River definitely regards a ~50 engineering year effort as significant, although for many of you out there these would be small projects! Far from being some piece of "marketing fluff" as some have suggested, we engineers here had some definite goals in mind for Tornado, over and above our traditional focus on making VxWorks a capable OS. These goals were (a) to make high end development tools work on very small scale systems (little memory, no Ethernet, for example) (b) to make the system customizable and extensible so that it could be modified by our customers to make it work in as productive a manner as possible and (c) to define and publish an API to the tool framework so that all manner of development tools could be brought to bear on the engineering problem at hand. Whether you agree or disagree that these goals were smart priorities or not, that's what Tornado was all about and that's what the project came up with. But it doesn't mean we're abandoning any focus on the RTOS, which is after all one of our crown jewels - we have lots of new things in the pipe there! We decided on these goals specifically to encourage innovation in the tools arena and to make everything work on the deeply embedded systems that many of our customers are working with. Of course, we have a huge and growing number of users with VME targets and other resource rich hardware that may not care about the host-based tools. But we believe the new architecture of Tornado will bring about several advantages for these users also. After all, the unlimited "headroom" on the host will allow us to do really fancy things with the shell, linker, etc. that the target-based approach penalized us too heavily for. And already goals (b) and (c) are making all manner of new tools available from our partners, which is perhaps the thing that I'm most excited about. Beyond this, the embedded world has changed enormously. There are many, many more embedded developers entering our community, as people take advantage of newer and cheaper microprocessors to build all manner of leading edge products. We've tried to serve these newer developers by making Tornado available on Windows (as many come from this space) and to make the tools easier to drive by using GUI facilities. Of course, power users can still dive into the command line if they wish! With the health of this embedded business comes the challenge of extreme growth. Wind River is growing sales at almost 50% per year, and this astonishing pace translates into lots of new users expecting support. This is our biggest challenge, and everyone in the executive staff at Wind River is cognizant of it. Our Customer Support operation is composed of smart and committed individuals, but we need to constantly staff up to handle the demand. We're hiring as quickly as we can, both junior support engineers and senior people with real world embedded experience, but these people are hard to find. We'll continue to hire the best we can find, and spend as much as it takes on new tools and technologies to improve our responsiveness. Additionally we are increasing our emphasis on maintenance releases within R&D, and placing more support function out in our field to be "closer to the customer". Today the ratio of R&D to service is about 2:1 and I would expect the service content to increase as we move forward. Finally, please accept my thanks on behalf of everyone at Wind River for your comments. If there's something that I think sets Wind River apart from most of the companies I've ever worked for it's that we are enthusiasts for our technology: we want to make the best products and services that we can. Our outstanding low level of attrition speaks highly to how committed and long term a team we have here working on that objective. Your feedback is essential at helping us. Regards, David Fraser VP Engineering, Wind River Systems --------------------------- Newsgroups: comp.os.vxworks Subject: RAID max size? Date: Mon, 11 Nov 1996 09:46:38 -0500 From: Richard Price Organization: United Space Alliance Message-ID: <32873C4E.74F6@lsoc114x.ksc.nasa.gov> Has anyone else seen or hit the vxworks maximum disk storage size? I believe it is somthing around 4-6 Gbytes. Richard Price at KSC --------------------------- End of New-News digest ********************** From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 12 06:53:42 1996 From: "AS Bridge" Date: Tue Nov 12 06:53:45 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: comp.os.vxworks newsdigest Sent: Tue, Nov 12, 1996 5:38 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 12, 1996 6:51 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From bf@kayser-threde.de Tue Nov 12 06:55:21 1996 From: Florian Bittner Date: Tue Nov 12 06:55:23 PST 1996 Subject: SSI 78Q8373 Hello, has anybody out there tried the Silicon Systems 78Q8373 Ethernet chip ? We are going to use it in a custom hardware design with a CPU32. I would be glad to hear about experiences and/or available software for testing or VxWorks drivers. Greetings from Munich, TNX -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQB1AwUBMdks8VE0+SThqPHNAQHwoAMAouqwFY9xlm2MrOJm4Vt9QEFAxPPOJqNP 3vrdyLzRel0/nPsG3J4p/q38/DUGm69P/OUJBVGTuq8Hg53HAqUI4J3+jX1Bz/YI rTiRta7kRTTd/skoN88CJSSA9TGsb8v0 =FwhG -----END PGP SIGNATURE----- Florian Bittner Software Engineer __ __ Kayser-Threde GmbH Tel +49 89 78720 83 | |/ / Perchtingerstr.3 Fax +49 89 78720 98 | ====< 81379 Munich Germany |__|\__\ From jbrandt@sadira.gb.nrao.edu Tue Nov 12 06:56:24 1996 From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT) Date: Tue Nov 12 06:56:26 PST 1996 Subject: Re: Are you happy with VxWorks I'm glad to hear that Wind River's sales are doing so well. VxWorks is a solid product, however, as other have stated, it lacks several technologies. Let's face it, we all have looked around for real-time O.S's and found that VxWorks is on the high end of the pricing scale. Well, what you pay for should be what you get. But I find that Wind River can be quite unresponsive to our needs. Case in point, Multicast support. The changes to the networking code to enable RFC-1112 level 2 multicast support have been out on the net for years now. At least two persons I know have patched and tested the VxWorks networking code to add multicasting, AND SENT the patches back to WRS. Ask WRS about this and they have no knowledge of it. For pretty much zero effort, they could have added this technology. Why is multicasting a big deal in a RT-OS? How many of your RT systems have some sort of monitoring? Multicast allows a single packet sent from a VxWorks system to be delivered to any number of monitoring stations. For efficientcy reasons multicast is the way to go. I'm sure there are other examples like this out there. ------------------------------------------------------------------------ _/ _/ _/_/_/_/ _/ _/_/_/ National _/ _/ _/ _/ _/ _/ _/ _/ _/ Radio _/ _/ _/ _/_/_/_/ _/____/ _/ _/ Astronomy _/ _/_/ _/ _/ _/ _/ _/ _/ Observatory _/ _/ _/ _/ _/ _/ _/_/_/ Green Bank, WV Joe Brandt (N0NYO) N.R. EMT/FF jbrandt@nrao.edu (304)456-2210 ------------------------------------------------------------------------ From jhend@primenet.com Tue Nov 12 07:08:10 1996 From: John R Henderson Date: Tue Nov 12 07:08:12 PST 1996 Subject: VxMP We are using the VxMP package in version 5.2. I would like to modify the behavior of the VxMP such that the call to usrSmObjInit does not cause the bootup to wait for processor #0 to write a sequence number to shared memory, and for that matter, never write a sequence to shared memory. Currently VxMP does so every second. Our application essentially performs this function and I don't want to duplicate it. Does anyone know how I can do what I want with VxMP? Most of all, I would like to dynamically setup the kernel to be the master or slave at run-time. Furthermore, is there any problem with delaying the call to usrSmObjInit until after our application is up and running? Thank you, John R Henderson HMSC From dleviner@HiWAAY.net Tue Nov 12 07:14:48 1996 From: David Leviner Date: Tue Nov 12 07:14:50 PST 1996 Subject: run VxWorks in FLASH? Hi all, I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the embedded application and the board real estate is limited for adding more DRAM. Because of these issues the board manufacturer (our customer) is wanting us to look into the possibility of running VxWorks in FLASH. First of all, I've never been presented with this memory problem. We've never had this type of DRAM limitation. If I'm going to do this, I am assuming that I will have to run the text section of VxWorks (instructions, constants,etc.) in FLASH and the data section of VxWorks (i.e., C variables) in DRAM. I know with Microsoft compilers/linkers you can relocate code in this manner. Is it possible to do the same in the kernel build for VxWorks. If so, has anyone done this? Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, how? Thanks for the advice. -- David Leviner Systems Engineer Chandler/May, Inc. (CMI) 125 West Park Loop Huntsville, AL 35806 (205)722-0175 (205)722-0144 (fax) dleviner@HiWAAY.net From dleviner@HiWAAY.net Tue Nov 12 07:21:23 1996 From: David Leviner Date: Tue Nov 12 07:21:25 PST 1996 Subject: GP-IB Interface Hi all, Does anyone have any info on a GP-IB interface (general purpose instrumentation bus) VxWorks driver. This interface is based on the TI TMS9914 controller. Thanks fo the info. -- David Leviner Systems Engineer Chandler/May, Inc. (CMI) 125 West Park Loop Huntsville, AL 35806 (205)722-0175 (205)722-0144 (fax) dleviner@HiWAAY.net From dleviner@HiWAAY.net Tue Nov 12 07:24:47 1996 From: David Leviner Date: Tue Nov 12 07:24:48 PST 1996 Subject: VGA Drivers Hi all, Does anyone have any info on VxWorks VGA drivers. The VGA controller is from Chips and Technologies 65535 (ISA Implementation) Thanks fo the info. -- David Leviner Systems Engineer Chandler/May, Inc. (CMI) 125 West Park Loop Huntsville, AL 35806 (205)722-0175 (205)722-0144 (fax) dleviner@HiWAAY.net From rtsc@worldnet.net Tue Nov 12 07:51:49 1996 From: rtsc Date: Tue Nov 12 07:51:51 PST 1996 Subject: Disk defragmentation I look for the source code of a DOS disk defragmenter utility already ported or to be ported on VxWorks. If you have any information, please contact me at bdupre@rtsc.worldnet.net. Bernard Dupre From Scott.Peters@agai.com Tue Nov 12 09:22:11 1996 From: Scott Peters Date: Tue Nov 12 09:22:13 PST 1996 Subject: RE: WRS User's group meeting Hello: Sorry to bother you if you are not the correct person to write to about this. In a response you said there is a WRS user conference coming up in Jan. Please, let me know how to find out more information or to get registration. Thanks Scott Peters AG Associates scott.peters@agai.com From aaronn@telerobot.com Tue Nov 12 09:46:06 1996 From: aaronn@telerobot.com (Aaron Needles) Date: Tue Nov 12 09:46:12 PST 1996 Subject: IP Carrier board... Does anyone know of an IP Carrier board manufacturer for 3U VME? Any hints would be greatly appreciated! Thanks, Aaron Needles aaronn@telerobot.com From jford@sadira.gb.nrao.edu Tue Nov 12 10:01:44 1996 From: jford@sadira.gb.nrao.edu (John Ford) Date: Tue Nov 12 10:01:46 PST 1996 Subject: Re: GP-IB Interface Submitted-by dleviner@HiWAAY.net Tue Nov 12 07:21:23 1996 Submitted-by: David Leviner Hi all, Does anyone have any info on a GP-IB interface (general purpose instrumentation bus) VxWorks driver. This interface is based on the TI TMS9914 controller. Thanks fo the info. -- David Leviner Systems Engineer Chandler/May, Inc. (CMI) 125 West Park Loop Huntsville, AL 35806 (205)722-0175 (205)722-0144 (fax) dleviner@HiWAAY.net We have a C++ handler library for the Mizar VME7500, which uses the TMS9914A chip. You are welcome to it. It is not a vxWorks device driver, though. -- John Ford National Radio Astronomy Observatory Green Bank, WV 24944-0002 jford@nrao.edu From jrturne@isrc.sandia.gov Tue Nov 12 10:26:36 1996 From: "J.R. Turner" Date: Tue Nov 12 10:26:38 PST 1996 Subject: Unsubscribe Unsubscribe Take care, J.R. Turner, MS 1176 Intelligent Systems Robotics Center Email: jrturne@sandia.gov Sandia National Laboratories Phone: (505)845-9069 PO Box 5800 Fax: (505)284-4594 Albuquerque, NM 87185-1176 From pean@mbari.org Tue Nov 12 11:04:09 1996 From: Andrew Pearce Date: Tue Nov 12 11:04:11 PST 1996 Subject: Re: IP Carrier board... Hi, Greenspring lists a product in their catalog that might work for you. Its described as 3U IP carrier, part number VPIC310. I've never this product but I have used the IP octal modules and they work great. -- Andrew Pearce | email: pean@mbari.org Monterey Bay Aquarium Research Institute | tel: (408) 775-1746 7700 Sandholt Rd | fax: (408) 775-1646 Moss Landing, CA 95039 | URL: http://www.mbari.org/~pean "Coping's easy. Not pureeing your loved ones, that's the hard part." Basil Fawlty From pean@mbari.org Tue Nov 12 11:05:27 1996 From: Andrew Pearce Date: Tue Nov 12 11:05:28 PST 1996 Subject: Re: IP Carrier board... Hi, Greenspring lists a product in their catalog that might work for you. Its described as 3U IP carrier, part number VPIC310. I've never this product but I have used the IP octal modules and they work great. -- Andrew Pearce | email: pean@mbari.org Monterey Bay Aquarium Research Institute | tel: (408) 775-1746 7700 Sandholt Rd | fax: (408) 775-1646 Moss Landing, CA 95039 | URL: http://www.mbari.org/~pean "Coping's easy. Not pureeing your loved ones, that's the hard part." Basil Fawlty From jhillman@wrs.com Tue Nov 12 11:10:02 1996 From: Jon Hillman Date: Tue Nov 12 11:10:04 PST 1996 Subject: Re: GNU Development At 07:16 PM 11/11/96 PST, Malcolm Cifuentes wrote: >Hi all, > I would like to know : > > 1/ Is any one doing development on the PPC using the GNU compiler > in tornado. > 2/ What steps did you take to get around the IOSTREAMS problem. > 3/ Does any one know if the Wind Foundation Classes can be used > with the GNU compiler, and if so is any one using this combination. > 1/ Everyone with Tornado/PPC would use the GNU 2.7 compiler (save those working with Green Hills ADA Multi. 2/ WRS provides the Wind Foundation Classes which include, among other stuff, iostreams. Also included in the WFC is tools.h++, booch, vxworks wrapper classes for the os calls. 3/ Yes, they are indeed use WFC with GNU 2.7. _________________________ | Jon Hillman, FAE | | Wind River Systems | /) (407) 273-4646 (\ / ) Email:jhillman@wrs.com ( \ _( (|_________________________) ) /> (((\ \) /,) / ) / //))/ (\\\\ \_/ / \ \_/ ///// \ / \ / \ _/ \_ / ----/ /----------------------\ \---- / / \ \ From stan@rti.com Tue Nov 12 12:11:55 1996 From: Stan Schneider Date: Tue Nov 12 12:11:58 PST 1996 Subject: RE: WRS User's group meeting Hi all, Here's some more advance info on the upcoming user's group meeting: +++++++++++++++++++++++++++++++++++++++++++++ The upcoming Users Conference and Exhibition will be held on January 13 and 14 in Santa Clara, California. More details and registration information will be available in a couple of weeks on the Wind River Web at http://www.wrs.com/usrgroup.html If you need to plan in advance with your company to attend, here is some info about costs. Cost for the meeting depend on the option you choose: Option 1: Pre-conference training + Conference & Exhibition $250 for advance registration received and paid before January 6, 1997 $350 for regular or on-site registration (after January 6, 1997) Option 2: Conference and Exhibition only $75 for advance registration received and paid before January 6, 1997 $100 for regular or on-site registration (after January 6, 1997) Do not hesitate to contact Claire (claire@wrs.com) or me if you have any further questions. -- Stan stan@rti.com From jhillman@wrs.com Tue Nov 12 13:17:51 1996 From: Jon Hillman Date: Tue Nov 12 13:17:53 PST 1996 Subject: Re: VGA Drivers Sorry about the e-mail with the attachment. I hope this did not cause a problem with you all. I thought I was responding directly to the persons' e-mail rather than to the exploder! :-( _________________________ | Jon Hillman, FAE | | Wind River Systems | /) (407) 273-4646 (\ / ) Email:jhillman@wrs.com ( \ _( (|_________________________) ) /> (((\ \) /,) / ) / //))/ (\\\\ \_/ / \ \_/ ///// \ / \ / \ _/ \_ / ----/ /----------------------\ \---- / / \ \ From froeber@BBN.COM Tue Nov 12 18:57:13 1996 From: Fred Roeber Date: Tue Nov 12 18:57:16 PST 1996 Subject: Re: multicast JOE BRANDT writes: > But I find that Wind River can be quite unresponsive to our needs. > > Case in point, Multicast support. The changes to the networking code to enable > RFC-1112 level 2 multicast support have been out on the net for years now. > > At least two persons I know have patched and tested the VxWorks networking > code to add multicasting, AND SENT the patches back to WRS. I am not going to refute Joes point about lack of response from WRS; I have certainly felt that way enough times. The thing is, the area of multicast support is one case where I have some insight into WRS's position. It might be useful to consider this case in the broader context of what it takes to add things to VxWorks. While I doubt that we are one of the two people Joe refers to, I was part of a group at my former employer that had a VxWorks source license and needed to use multicast. We got the PD code for implementing multicast and put the changes into the source and passed them back to WRS. The work wasn't that hard at all. The only trick was that an efficient implementation of multicast requires that you take advantage of the hardware packet filtering that is part of many ethernet chips. It turns out that when you are trying to support BSPs which utilize nearly a dozen different ethernet chips, coming up with a portable way of providing this interface is not at all trivial; especially since the different chips use radically different interfaces to provide such filtering. Thus while it was easy for us to get our one particular implementation to work, getting it working in a general fashion would be quite tough. > Ask WRS about this and they have no knowledge of it. For pretty much zero > effort, they could have added this technology. While I certainly go along with Joe that multicast would be nice to have, I wanted to point out that it wouldn't take "pretty much zero effort". It seems that what we need is some way of quantifying how much different users want different capabilities. Maybe that way we can "help" WRS focus on trying to develop things we really need. As an example, I remember back to when the only way to communicate between processors over the backplane was the backplane driver. It's nice but slow. At some of the user group meetings a lot of people said a big thing they wanted was faster options for multiprocessor communication and eventually VxMP showed up which is quite useful in many situations. I'm just wondering if there is some way to create a central list of "the top ten things people want added to VxWorks"? Just a suggestion. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | | See http://www.bbn.com/tv for TraceMaker info | From p72950@gmcl.co.uk Wed Nov 13 01:55:23 1996 From: Phil Quiney Date: Wed Nov 13 01:55:26 PST 1996 Subject: Re: run VxWorks in FLASH? Hi there, We have successfully run VxWorks from FLASH. In our case the build system was modified to produce the FLASH version as well as the RAM loadable and BOOTROM version. I produced a new makefile (Makefile.fl) which *only* does the FLASH version. The basic changes were: Change the include of 'defs.bsp' to a local file (or in a relative directory). More of this later. Set ROM_TEXT_ADRS & ROM_SIZE to reflect the size & location of the FLASH devices. Change HEX_FLAGS to '-a $(ROM_TEXT_ADRS)' Change the include of rules.bsp to point to a local file (same path as defs.bsp ?). defs.bsp: Change MACH_DEP to '$(MACH_EXTRA) $(ADDED_MODULES) rules.bsp: file follows # rules.bsp - makefile target rules for BSP # # SCCS Ref: @(#)rules.bsp 1.1 8/27/96 # # modification history # -------------------- # 01h,27aug96,pjq special version to produce vxWorks.fl. Added SCCS ref. # 01g,13nov95,jeh restored .cpp.o implicit rule # 01f,08nov95,jeh removed .cpp.o implicit rule # 01e,01nov95,p_m added LIB to rom_res build command # 01d,01nov95,yp added implicit rules for C++ # 01c,30oct95,dat added targets vxWorks.res_rom_nosym and # vxWorks.res_rom_nosym_mips # 01b,27jun95,kkk added VXSIZE. # 01a,12jun95,yp created from makeTarget2 v03d. # # DESCRIPTION # This file contains rules used in building targets. # # VARIABLES # The following variables must be defined (or not, as appropriate): # # ROM_SIZE number of bytes of ROM space as in config.h # LOCAL_MEM_SIZE target RAM size as in config.h # BINHEX binary->hex file conversion program # HEX_FLAGS BINHEX program options # LD_LOW_FLAGS ld(1) options for code in low memory # LD_HIGH_FLAGS ld options for code in high memory # LD_PARTIAL_FLAGS ld flags for linking partially complete objects # LDDEPS host-specific dependencies prerequisite to linking # LDOUT_CONV hpToBsd, coffToBsd, gswab, /bin/cat, etc. # COMPILE_SYMTBL hide flags needed to get compiler to swallow symTbl.c # ROM_ENTRY rom entry point (typically &romInit) # SYS_ENTRY system entry point (typically &sysInit) # USR_ENTRY compressed system entry point (typically &usrInit) # # The following variables are optionally defined: # # LDFLAGS standard ld flags for vxWorks & ROMs. # ROM_LDFLAGS ld flags specific to ROM image # # CONSTANTS # CPU cpu type #*/ ################################################################################ # # meta build targets # ## make will default to "exe" exe : vxWorks.fl.hex release : $(RELEASE) clean : - $(RM) *.o - $(RM) vxWorks* - $(RM) bootrom* - $(RM) depend.$(TARGET_DIR) .s.o : @ $(RM) $@ $(CPP) $(CASFLAGS) -E $< > tmp.s $(CC) $(CFLAGS) -c -o $*.o tmp.s @ $(RM) tmp.s .c.o : @ $(RM) $@ $(CC) $(CFLAGS) -c $< # rule for munchless C++ compiles .cpp.o : @ $(RM) $@ $(CXX) $(C++FLAGS) -c $< # C++ compile and munch .cpp.out : @ $(RM) $@ $(CXX) $(C++FLAGS) -c $< @ $(RM) $@ ctdt.c $(NM) $*.o | munch > ctdt.c $(MAKE) CC_COMPILER="-traditional" ctdt.o $(LD) -r -o $@ $*.o ctdt.o @ $(RM) ctdt.c ctdt.o ################################################################################ # # machine dependent targets romInit_fl.o: depend.$(BSP_NAME) romInit.s - @ $(RM) $@ - @ $(RM) tmp.c - @ $(RM) tmp.s - @ $(RM) tmp.i $(ASM_P1) romInit.s > tmp.c $(CC) $(CASFLAGS) -DROM_RESIDENT -DFLASH_BLD tmp.c > tmp.i $(ASM_P2) tmp.i > tmp.s $(AS) -o $@ tmp.s - @ $(RM) tmp.c - @ $(RM) tmp.i - @ $(RM) tmp.s usrConfig.o : depend.$(BSP_NAME) $(USRCONFIG) - @ $(RM) $@ $(CC) -c $(CFLAGS) $(USRCONFIG) -o $@ bootInit.o : depend.$(BSP_NAME) $(BOOTINIT) - @ $(RM) $@ $(CC) -c $(CFLAGS) $(BOOTINIT) bootInit_fl.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o - @ $(RM) $@ $(CP) $(BOOTINIT) bootInit_fl.c $(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD bootInit_fl.c - @ $(RM) bootInit_fl.c sysLib_fl.o : depend.$(BSP_NAME) sysLib.c - @ $(RM) $@ $(CP) sysLib.c sysLib_fl.c $(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD sysLib_fl.c - @ $(RM) sysLib_fl.c dataSegPad.o: depend.$(BSP_NAME) $(DATASEGPAD) $(CONFIG_ALL_H) config.h - @ $(RM) $@ $(CC) -c $(CFLAGS) $(DATASEGPAD) -o $@ ################################## vxWorks ##################################### # # vxWorks - Version setup for FLASH build - no symbol table vxWorks.fl: depend.$(BSP_NAME) bootInit_fl.o romInit_fl.o \ usrConfig.o sysALib.o sysLib_fl.o \ $(MACH_DEP) $(LDDEPS) $(LIBS) - @ $(RM) $@ tmp.o - @ $(RM) tmp.1 - @ $(RM) symTbl.c - @ $(RM) symTbl.o - @ $(RM) $(IMI) - @ $(RM) $(IBR) - @ $(RM) version.c - @ $(RM) version.o $(MKVERSION) > version.c $(CC) -c $(CFLAGS) version.c - @ $(RM) version.c $(LD) -o $@ $(LDFLAGS) $(ROM_LDFLAGS) -e $(ROM_ENTRY) \ $(RES_LOW_FLAGS) romInit_fl.o bootInit_fl.o usrConfig.o \ sysALib.o sysLib_fl.o $(MACH_DEP) version.o $(LIBS) $(LDOUT_HOST) $@ $(ROMSIZEPROG) -b $(ROM_SIZE) $@ $(LDOUT_CONV) $@ vxWorks.fl.hex: depend.$(BSP_NAME) vxWorks.fl $(IMI) - @ $(RM) $@ $(BINHEX) $(HEX_FLAGS) vxWorks.fl$(TXT_OFFSET) \ $(IMI_SPEC)$(IMI)$(IMI_OFFSET) > $@$(MAP_EXT) -@ $(MV_BIN) imi : $(IBR) $(LD) -o $@ -Ttext $(IMI_TEXT_ADRS) -Tdata $(IMI_DATA_ADRS) $(IBR) End of rules.bsp Note that rules.bsp passes a compile time flag 'FLASH_BLD' into the compiler. Make sure that the definitions in config.h use an #ifdef FLASH_BLD to remap the values of ROM_TEXT_ADDRESS & ROM_TEXT_SIZE to the correct values. This flag can be used anywhere in the BSP files to make compile time changes to the system. To build run the Wind River Make (we find it clashes with unix make so have renamed it 'wrs_make') wrs_make -f Makefile.fl It produces the following vxWorks.fl - object file mapped to FLASH addresses vxWorks.fl.hex - S-Record file ready to download to FLASH If using Tornado you will need to either set the 'Core file' option in the launcher to point to vxWorks.fl or modify bootConfig.c to notice it is about to run from FLASH & change the boot parameters to point to it. (We chose the latter method as it makes it automatic. Also we can change the 'other' parameter to RAM which causes VxWorks to load to RAM as normal). Regards, Phil Quiney >Hi all, > >I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH >and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the >embedded application and the board real estate is limited for adding more DRAM. >Because of these issues the board manufacturer (our customer) is wanting us to >look into the possibility of running VxWorks in FLASH. > >First of all, I've never been presented with this memory problem. We've never had >this type of DRAM limitation. If I'm going to do this, I am assuming that I will >have to run the text section of VxWorks (instructions, constants,etc.) in FLASH >and the data section of VxWorks (i.e., C variables) in DRAM. I know with >Microsoft compilers/linkers you can relocate code in this manner. Is it >possible to do the same in the kernel build for VxWorks. If so, has anyone done >this? > >Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, >how? > >Thanks for the advice. >-- >David Leviner >Systems Engineer >Chandler/May, Inc. (CMI) >125 West Park Loop >Huntsville, AL 35806 >(205)722-0175 >(205)722-0144 (fax) >dleviner@HiWAAY.net > =============================================================================== Phil Quiney _/_/_/_/ _/ _/_/_/_/ email : quiney@gmcl.co.uk GEC Marconi _/ _/ _/ _/ _/ tel : +44 1245 353221x3914 Communications Ltd _/_/_/_/ _/ _/ _/ _/_/ fax : +44 1245 275448 Chelmsford _/ _/_/_/_/ _/_/_/_/ England CM1 1PL _/ =============================================================================== From norpires@cygnus.ci.uc.pt Wed Nov 13 03:35:44 1996 From: "J. Norberto Pires" Date: Wed Nov 13 03:35:55 PST 1996 Subject: Re: IP Carrier board... At 20:19 12-11-1996, you wrote: >Submitted-by aaronn@telerobot.com Tue Nov 12 09:46:06 1996 >Submitted-by: aaronn@telerobot.com (Aaron Needles) > > > Does anyone know of an IP Carrier board manufacturer for 3U VME? Any > hints would be greatly appreciated! > > Thanks, > Aaron Needles > aaronn@telerobot.com > Check Green-Spring Computers 1204 O'briem drive Menlo Park, CA 94025 (415) 327 - 1200 http://www.GreenSprings.com norberto norpires@ci.uc.pt norberto@andromeda.dem.uc.pt From nkhurana@hss.hns.com Wed Nov 13 03:56:22 1996 From: Neeraj_Khurana Date: Wed Nov 13 03:56:24 PST 1996 Subject: unsubscribe unsubscribe NEERAJ KHURANA nkhurana@hss.hns.com From daemon@csg.lbl.gov Wed Nov 13 04:00:21 1996 From: daemon@csg.lbl.gov Date: Wed Nov 13 04:00:24 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Nov 13 04:00:18 PST 1996 Subject: need symbios 53c770 scsi driver Subject: Problem with bind() Subject: Re: run VxWorks in FLASH? Subject: Re: Are uou happy with Vx Works and Wind River Subject: Is your 5.2 X86 target SLOW? Subject: Re: run VxWorks in FLASH? Subject: Re: Are you happy with Vx Works and Wind River Subject: Re: Are uou happy with Vx Works and Wind River Subject: re: multicast Subject: Re: run VxWorks in FLASH? Subject: Re: Testing a location over the VME bus. Subject: Re: Problem with bind() ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: need symbios 53c770 scsi driver Date: Fri, 08 Nov 1996 11:48:49 -0700 From: Daniel Brodsky Organization: Wind River Systems Message-ID: <32838091.5027@wrs.com> hello all, Does anyone know where I could get a vxworks driver for the Symbios 53C770 SCSI device? Thanks in advance, Dan Dan Brodsky Wind River Systems danb@wrs.com (303)486-0850 --------------------------- Newsgroups: comp.os.vxworks Subject: Problem with bind() Date: Wed, 13 Nov 1996 04:38:31 GMT From: brucew@phoenix.net (Bruce) Organization: BranPaul Systems Message-ID: <56bjfm$inq$3@uhura.phoenix.net> We have built a tcpserver from the example code provided in the vxWorks manual. As is accepts connections, it starts a task to handle each connection. All of this is working fine. The problem occurs when we close the socket for any reason. When we call socket() again, it opens ok, but the bind() always fails. We can only fix this by a reboot. Anyone have any ideas? Bruce --------------------------- Newsgroups: comp.os.vxworks Subject: Re: run VxWorks in FLASH? Date: Wed, 13 Nov 1996 03:40:37 GMT From: jdeffner@west.net (john deffner) Organization: West.Net Communications Message-ID: <56bfue$koq@daffy.sb.west.net> References: <32889451.4C5E@HiWAAY.net> On Tue, 12 Nov 1996 09:14:25 -0600, David Leviner wrote: >Hi all, > >I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH - --cut-- >Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, >how? > >Thanks for the advice. >-- >David Leviner >Systems Engineer >Chandler/May, Inc. (CMI) >125 West Park Loop >Huntsville, AL 35806 >(205)722-0175 >(205)722-0144 (fax) >dleviner@HiWAAY.net Actually it's pretty easy. The kernal build you want is vxWorks.res_rom (or vxWorks.res_rom_low if you're running in a small amount of flash). We're doing it with a 386ex bsp (1 meg of flash, 1 meg of ram) and it works fine. It should be pretty similar for a straight 386. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are uou happy with Vx Works and Wind River Date: Sun, 10 Nov 96 20:32:12 GMT From: nobody@nowhere Organization: A poorly-installed InterNetNews site Message-ID: <565e0f$5a0@idiom.com> References: I don't mean to sound like an apologizer for Tornado, because I don't use Tornado IDE due to its bugs, but blaming WRS for trying to make money on their product by hyping it is like blaming the Pope for being against abortion. It's the nature of business. The fact is, even with all bugs and misfeatures, VxWorks is the best RTOS in existence. Unless someone comes out with something better, we're stuck with it. The thing to do, then, is to encourage WRS to fix problems. I am frequently accused of being negative on WRS for exposing VxWorks problems. I am also accused of bashing WRS for selling out to military market. I'm guilty of both. Although I'm less critical on the latter part now, because WRS doesn't seem to depend as much on military customers. However, I'd never accuse WRS for hyping their product. It's all BS, but that's what marketing is. I'd rather hope that WRS will fix a number of fundamental problems: 1. broken stdio architecture. The ioGlobalStd stuff has to go. I've seen too many people lose their mind over this. 2. broken filesystem architecture -- vxWorks does not have one. All filesystems are implemented as IO drivers and libraries. This creates a number of annoying problems and breaks consistent interface for simple things like ls(). 3. non-reentrant target shell. Tornado adds bandages to this problem by allowing multiple instantiations of tcl infused shell-lookalikes. This breaks the consistency of user interface even more -- for example, i() implemented in tcl vs. i() implemented in C -- there is no reconciliation or attempt to resolve oddities that arise from this. 4. use of #include on C files in the config/all files. #include is meant for H files not C files. This creates subtle problems, and there are cleaner alternatives. 5. techsupport. It's terrible. etc. I could go on and on... --------------------------- Newsgroups: comp.os.vxworks Subject: Is your 5.2 X86 target SLOW? Date: 10 Nov 1996 14:18:55 -0600 From: irwin@Starbase.NeoSoft.COM (Bob Irwin) Organization: Realtime Systems / SW Houston Message-ID: <565dbf$kdm@Starbase.NeoSoft.COM> If you are using the X86 bsp with vxWorks 5.2, you may have a serious performance problem with system images that are loaded into low memory (bootable *.st images). To see if your bsp has this problem, boot a vanilla vxWorks image (with timexN support) from the network and enter the following two shell commands. Observe the return values. -> timexN bcopyBytes, 0x200000, 0x300000, 1000 -> timexN bcopyBytes, 0x108000, 0x300000, 1000 ^ LOW_RAM_ADRS The first command times a copy of bytes from 'high mem' to 'high mem', while the second command times a copy of bytes from 'low mem' to 'high mem'. If your low mem copy takes 3-4 times LONGER that your high mem copy, You have this problem. If you load a bootable standalone image, it loads at LOW_RAM_ADDRESS. If you've linked your own code into the kernel, it's gonna run SLOW. Not only your code, but sysLib is loaded here (sysInByte, sysOutByte, etc). As delivered, our bsp's LOW_RAM_ADRS was set at 0x108000 in Makefile, MakeSkel, Makefile.I80486gnu, and config.h. The original sysPhysMemDesc showed 0x100000 as the beginning of cached memory. By using timexN, I found that the first 64K bytes of 'low mem' were likely uncached. This problem existed on different target machines with different CPU types. My 'workaround' was to change LOW_RAM_ADRS in the above 4 bsp files to 0x110000. This lets the 'low mem' copy run at normal speed. A TSR was openened on this several months ago with no resolution. It has been reopened with the above test description. I'm a consultant for Systems Interface Software, Inc. (SIS). We have geen providing custom PC104 boxes and software to NASA at JSC here in Houston. - Bob - -- R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 I don't want to achieve immortality through my work. I want to achieve immortality through not dying. - Woody Allen --------------------------- Newsgroups: comp.os.vxworks Subject: Re: run VxWorks in FLASH? Date: Wed, 13 Nov 1996 08:22:14 +0000 From: Iain Tebbutt Organization: Brunel University, Uxbridge, UK Message-ID: <32898536.749A@brunel.ac.uk> References: <32889451.4C5E@HiWAAY.net> David Leviner wrote: > > Hi all, > > I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH - ------ snip ------ > Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, > how? > Look at rom resident versions of vxWorks. I use vxWorks.res_rom_nosym which runs fine from a "ROM" type area. You will need to make sure that the memory map in config.h and Makefile have the correct ROM address. Using this rom resident portion of VxWorks means that the text areas stay in ROM and RAM is only used for variables/data. Iain (Iain.Tebbutt@brunel.ac.uk) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with Vx Works and Wind River Date: Wed, 13 Nov 1996 08:50:32 GMT From: valentin@netcom.com (Valentin Pepelea) Organization: Netcom Communications, Santa Clara, CA Message-ID: References: <55md5u$5b@idiom.com> <560boi$42q@hacgate2.hac.com> <567s0h$evk@hacgate2.hac.com> Sender: valentin@netcom16.netcom.com In article <567s0h$evk@hacgate2.hac.com> mhayashibara@ccgate.hac.com writes: > >The Mentor buyout of pSOS was the last straw. > >... > > Dave relates the correct acquisition; Mentor bought Microtec. But >imagine having a compiler vendor (Microtec) who was under contract to >ISI (who sold us the Microtec compiler AND pSOS) that migrated to a >different RTOS (VRTX) and didn't want to support pSOS users anymore! >That's the way it is... Let me make some clarifications here. Mentor Graphics bought Microtec Research, not ISI one year ago. Microtec, in return, bought Ready Systems, the makers of the VRTX real-time kernel and the SPECTRA development system upon which Tornado's concepts are based, three years ago. I was at Ready Systems when SPECTRA was rolled out in 1993, and we too were using GNU tools to compile all our code. The idea was to make a development system and kernel that is totally independant of the compiler tool suite used, and even allow the addition of third-party plug in tools through the use of an open API. (sound familiar?) Indeed, demo applications were supplied for GNU, Microtec, and Oasys (Green Hills). Later Metaware, and Diab tools were added for 29K and PowerPC architectures, respectively. After the purchase of Ready Systems by Microtec, that policy of openess continued. However, Green Hills was already at odds with Microtec and were involved in a major lawsuit, so they dropped a continuation of cross-licencing agreements. The purchase of Ready and its kernel, VRTX, placed Microtec in a competitive posture vis-avis ISI. Needless to say, ISI was not happy about it either, (would you?) and might have been trying to distance themselves since then. Given that a *high* percentage of Microtec's sales were associated with pSOS sales' boundling, it was and still is, in Microtec's best interest to keep pSOS customers happy. Valentin - -- "An operating system without virtual memory Valentin Pepelea is an operating system without virtue." Embedded Systems Consultant (415) 346-7105 - Ancient Inca Proverb valentin@netcom.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are uou happy with Vx Works and Wind River Date: Tue, 12 Nov 96 09:58:18 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56c2r2$obb@idiom.com> References: <565e0f$5a0@idiom.com> In article , pjg@parint.svl.trw.com () wrote: >In article <565e0f$5a0@idiom.com> nobody@nowhere writes: > > From: nobody@nowhere > >Hey hj, you need to work on your headers a bit more if you are >trying to be anonymous. > It was ironic that my newsreader program would do that. I've fixed the problem and also posted a note, immediately afterwards. I have no reason to hide behind anonymity. Thanks for playing... but no cookie. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: re: multicast Date: Tue, 12 Nov 96 09:46:44 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56c25c$jvm@idiom.com> References: <199611130250.VAA06027@satchmo.bbn.com> In article <199611130250.VAA06027@satchmo.bbn.com>, Fred Roeber wrote: > It turns out that when you >are trying to support BSPs which utilize nearly a dozen different ethernet >chips, coming up with a portable way of providing this interface is not >at all trivial; especially since the different chips use radically >different interfaces to provide such filtering. Thus while it was easy >for us to get our one particular implementation to work, getting it working >in a general fashion would be quite tough. Implementing the general mechanism for multicast filtering support on network device driver interfaces is not tough at all. Just look at how BSD4.4 does it. The generic interface itself is quite simple. It is true that each device has unique way of setting up filters for multicast filters, therefore device drivers have to implement it differently. However, this does not mean that the generic support for multicast filtering itself is hard at all! The devices may or may not support multicast filtering, and the interface would still work. Given this, the only conceivable reason for not supporting multicast would be unwillingness to study the problem and/or unwillingness to write/port necessary code. The effort involved would be trivial compared to the usefulness of multicasting in a realtime OS. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: run VxWorks in FLASH? Date: Tue, 12 Nov 96 09:49:30 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56c2ai$jvm@idiom.com> References: <32889451.4C5E@HiWAAY.net> In article <32889451.4C5E@HiWAAY.net>, David Leviner wrote: >Or to make the question easier to answer, has anyone run VxWorks in FLASH? If > so, >how? > build vxWorks.res_rom http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Testing a location over the VME bus. Date: Wed, 13 Nov 1996 08:20:24 GMT From: valentin@netcom.com (Valentin Pepelea) Organization: Netcom Communications, Santa Clara, CA Message-ID: References: <1.5.4.32.19961107224614.00712e34@pop01.connect.com> Sender: valentin@netcom16.netcom.com In article <1.5.4.32.19961107224614.00712e34@pop01.connect.com> Mike McQuade writes: > >Im using both MVME-1603 and 1604 boards, on the 1603, I can >access addresses where there is no hardware, this returns >garbage, but on the 604, if I try to access an address where >there is no hardware, I get an exception. > >Any ideas why the 604 generates an exception, and the 603 doesn't ? I have worked on ISI's board-support package for the MVME-1600 series boards, not WRS', but the answer should be useful anyway. The difference between the two processors that is relevant here is the implementation of the MMU. The 603 uses a generic TLB (translation lookaside buffer), where each entry in the lookaside buffer corresponds to a virtual to psysical page translation. There are only 16 such entries available, so if a page is accessed for which no translation is available, a trap occurs. The trap handler then replaces one of the 16 entries. The 604 MMU also uses a secondary 64Kb table located in main memory to automatically store alternate translation entires. It uses a hashing algorithm to find and replace entries that do not fit into the TLB. It is possible to program the MMU in such a way that it either maps an address to physical memory, mirrors address ranges repreatedly, blocks all accesses (or only writes) or that it maps it directly to addressing ranges, regarless of whether memory is there or not. >Any suggestions on how to test if a board is available ? The MMUs should be programmed to translate the VME address range trans- parently. Therefore if a board is not present in its expected slot, or if it broke while running, a machine check exception should occur when its memory was accessed. The code I wrote for ISI's multi-processing pSOS+m would cleanly recover from the exception, as the memory in question was being accessed only after the equivalent of a setjmp() call. The equivalent of a lonjmp() call would allow the continuation of execution from the point of the memory access. First, you have to ensure that both your 603 and 604 boards generate an exception for VME memory that is not there. Perhaps WRS' BSP requires you to indicate at configuration time at which addresses you expect other boards to be mapped, and your problem lies there. If the problem is in their MMU code for the 603 processor, contact their tech support staff. They might already have a patch available. I don't see how they could implement error recovery in their multi-processing version of the kernel without this working properly. Given the current public gripes re: tech support, other readers are probably wishing you good luck. :-) Valentin - -- "An operating system without virtual memory Valentin Pepelea is an operating system without virtue." Embedded Systems Consultant (415) 346-7105 - Ancient Inca Proverb valentin@netcom.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Problem with bind() Date: Tue, 12 Nov 96 09:52:09 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56c2fh$jvm@idiom.com> References: <56bjfm$inq$3@uhura.phoenix.net> Try this: int on = 1; setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- End of New-News digest ********************** From p72950@gmcl.co.uk Wed Nov 13 05:43:46 1996 From: Phil Quiney Date: Wed Nov 13 05:43:52 PST 1996 Subject: Re: run VxWorks in FLASH? Hi there, We have successfully run VxWorks from FLASH. In our case the build system was modified to produce the FLASH version as well as the RAM loadable and BOOTROM version. I produced a new makefile (Makefile.fl) which *only* does the FLASH version. The basic changes were: Change the include of 'defs.bsp' to a local file (or in a relative directory). More of this later. Set ROM_TEXT_ADRS & ROM_SIZE to reflect the size & location of the FLASH devices. Change HEX_FLAGS to '-a $(ROM_TEXT_ADRS)' Change the include of rules.bsp to point to a local file (same path as defs.bsp ?). defs.bsp: Change MACH_DEP to '$(MACH_EXTRA) $(ADDED_MODULES) rules.bsp: file follows # rules.bsp - makefile target rules for BSP # # SCCS Ref: @(#)rules.bsp 1.1 8/27/96 # # modification history # -------------------- # 01h,27aug96,pjq special version to produce vxWorks.fl. Added SCCS ref. # 01g,13nov95,jeh restored .cpp.o implicit rule # 01f,08nov95,jeh removed .cpp.o implicit rule # 01e,01nov95,p_m added LIB to rom_res build command # 01d,01nov95,yp added implicit rules for C++ # 01c,30oct95,dat added targets vxWorks.res_rom_nosym and # vxWorks.res_rom_nosym_mips # 01b,27jun95,kkk added VXSIZE. # 01a,12jun95,yp created from makeTarget2 v03d. # # DESCRIPTION # This file contains rules used in building targets. # # VARIABLES # The following variables must be defined (or not, as appropriate): # # ROM_SIZE number of bytes of ROM space as in config.h # LOCAL_MEM_SIZE target RAM size as in config.h # BINHEX binary->hex file conversion program # HEX_FLAGS BINHEX program options # LD_LOW_FLAGS ld(1) options for code in low memory # LD_HIGH_FLAGS ld options for code in high memory # LD_PARTIAL_FLAGS ld flags for linking partially complete objects # LDDEPS host-specific dependencies prerequisite to linking # LDOUT_CONV hpToBsd, coffToBsd, gswab, /bin/cat, etc. # COMPILE_SYMTBL hide flags needed to get compiler to swallow symTbl.c # ROM_ENTRY rom entry point (typically &romInit) # SYS_ENTRY system entry point (typically &sysInit) # USR_ENTRY compressed system entry point (typically &usrInit) # # The following variables are optionally defined: # # LDFLAGS standard ld flags for vxWorks & ROMs. # ROM_LDFLAGS ld flags specific to ROM image # # CONSTANTS # CPU cpu type #*/ ################################################################################ # # meta build targets # ## make will default to "exe" exe : vxWorks.fl.hex release : $(RELEASE) clean : - $(RM) *.o - $(RM) vxWorks* - $(RM) bootrom* - $(RM) depend.$(TARGET_DIR) .s.o : @ $(RM) $@ $(CPP) $(CASFLAGS) -E $< > tmp.s $(CC) $(CFLAGS) -c -o $*.o tmp.s @ $(RM) tmp.s .c.o : @ $(RM) $@ $(CC) $(CFLAGS) -c $< # rule for munchless C++ compiles .cpp.o : @ $(RM) $@ $(CXX) $(C++FLAGS) -c $< # C++ compile and munch .cpp.out : @ $(RM) $@ $(CXX) $(C++FLAGS) -c $< @ $(RM) $@ ctdt.c $(NM) $*.o | munch > ctdt.c $(MAKE) CC_COMPILER="-traditional" ctdt.o $(LD) -r -o $@ $*.o ctdt.o @ $(RM) ctdt.c ctdt.o ################################################################################ # # machine dependent targets romInit_fl.o: depend.$(BSP_NAME) romInit.s - @ $(RM) $@ - @ $(RM) tmp.c - @ $(RM) tmp.s - @ $(RM) tmp.i $(ASM_P1) romInit.s > tmp.c $(CC) $(CASFLAGS) -DROM_RESIDENT -DFLASH_BLD tmp.c > tmp.i $(ASM_P2) tmp.i > tmp.s $(AS) -o $@ tmp.s - @ $(RM) tmp.c - @ $(RM) tmp.i - @ $(RM) tmp.s usrConfig.o : depend.$(BSP_NAME) $(USRCONFIG) - @ $(RM) $@ $(CC) -c $(CFLAGS) $(USRCONFIG) -o $@ bootInit.o : depend.$(BSP_NAME) $(BOOTINIT) - @ $(RM) $@ $(CC) -c $(CFLAGS) $(BOOTINIT) bootInit_fl.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o - @ $(RM) $@ $(CP) $(BOOTINIT) bootInit_fl.c $(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD bootInit_fl.c - @ $(RM) bootInit_fl.c sysLib_fl.o : depend.$(BSP_NAME) sysLib.c - @ $(RM) $@ $(CP) sysLib.c sysLib_fl.c $(CC) -c $(CFLAGS) -DROM_RESIDENT -DFLASH_BLD sysLib_fl.c - @ $(RM) sysLib_fl.c dataSegPad.o: depend.$(BSP_NAME) $(DATASEGPAD) $(CONFIG_ALL_H) config.h - @ $(RM) $@ $(CC) -c $(CFLAGS) $(DATASEGPAD) -o $@ ################################## vxWorks ##################################### # # vxWorks - Version setup for FLASH build - no symbol table vxWorks.fl: depend.$(BSP_NAME) bootInit_fl.o romInit_fl.o \ usrConfig.o sysALib.o sysLib_fl.o \ $(MACH_DEP) $(LDDEPS) $(LIBS) - @ $(RM) $@ tmp.o - @ $(RM) tmp.1 - @ $(RM) symTbl.c - @ $(RM) symTbl.o - @ $(RM) $(IMI) - @ $(RM) $(IBR) - @ $(RM) version.c - @ $(RM) version.o $(MKVERSION) > version.c $(CC) -c $(CFLAGS) version.c - @ $(RM) version.c $(LD) -o $@ $(LDFLAGS) $(ROM_LDFLAGS) -e $(ROM_ENTRY) \ $(RES_LOW_FLAGS) romInit_fl.o bootInit_fl.o usrConfig.o \ sysALib.o sysLib_fl.o $(MACH_DEP) version.o $(LIBS) $(LDOUT_HOST) $@ $(ROMSIZEPROG) -b $(ROM_SIZE) $@ $(LDOUT_CONV) $@ vxWorks.fl.hex: depend.$(BSP_NAME) vxWorks.fl $(IMI) - @ $(RM) $@ $(BINHEX) $(HEX_FLAGS) vxWorks.fl$(TXT_OFFSET) \ $(IMI_SPEC)$(IMI)$(IMI_OFFSET) > $@$(MAP_EXT) -@ $(MV_BIN) imi : $(IBR) $(LD) -o $@ -Ttext $(IMI_TEXT_ADRS) -Tdata $(IMI_DATA_ADRS) $(IBR) End of rules.bsp Note that rules.bsp passes a compile time flag 'FLASH_BLD' into the compiler. Make sure that the definitions in config.h use an #ifdef FLASH_BLD to remap the values of ROM_TEXT_ADDRESS & ROM_TEXT_SIZE to the correct values. This flag can be used anywhere in the BSP files to make compile time changes to the system. To build run the Wind River Make (we find it clashes with unix make so have renamed it 'wrs_make') wrs_make -f Makefile.fl It produces the following vxWorks.fl - object file mapped to FLASH addresses vxWorks.fl.hex - S-Record file ready to download to FLASH If using Tornado you will need to either set the 'Core file' option in the launcher to point to vxWorks.fl or modify bootConfig.c to notice it is about to run from FLASH & change the boot parameters to point to it. (We chose the latter method as it makes it automatic. Also we can change the 'other' parameter to RAM which causes VxWorks to load to RAM as normal). Regards, Phil Quiney p.s Sorry for the repost but somehow the subject line was missing - just in case someone is trying to follow the thread. >Hi all, > >I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH >and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the >embedded application and the board real estate is limited for adding more DRAM. >Because of these issues the board manufacturer (our customer) is wanting us to >look into the possibility of running VxWorks in FLASH. > >First of all, I've never been presented with this memory problem. We've never had >this type of DRAM limitation. If I'm going to do this, I am assuming that I will >have to run the text section of VxWorks (instructions, constants,etc.) in FLASH >and the data section of VxWorks (i.e., C variables) in DRAM. I know with >Microsoft compilers/linkers you can relocate code in this manner. Is it >possible to do the same in the kernel build for VxWorks. If so, has anyone done >this? > >Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, >how? > >Thanks for the advice. >-- >David Leviner >Systems Engineer >Chandler/May, Inc. (CMI) >125 West Park Loop >Huntsville, AL 35806 >(205)722-0175 >(205)722-0144 (fax) >dleviner@HiWAAY.net > =============================================================================== Phil Quiney _/_/_/_/ _/ _/_/_/_/ email : quiney@gmcl.co.uk GEC Marconi _/ _/ _/ _/ _/ tel : +44 1245 353221x3914 Communications Ltd _/_/_/_/ _/ _/ _/ _/_/ fax : +44 1245 275448 Chelmsford _/ _/_/_/_/ _/_/_/_/ England CM1 1PL _/ =============================================================================== From VXWORKS@hqgate.orbital.com Wed Nov 13 07:12:41 1996 From: VXWORKS@hqgate.orbital.com Date: Wed Nov 13 07:12:47 PST 1996 Subject: Job Opportunity! Orbital Sciences Corporation in Dulles, VA currently has an immediate opening for a Software Engineer. The position involves the design, development, test, and integration of real-time embedded software for custom communications satellite hardware. The position requires a minimum of 3-4 years experience, including C, real-time OS (VxWorks preferred), 68xxx microprocessors, and cross-platform software development in a UNIX environment. Application experience in power systems, attitude control, or RF communications would be helpful. Please submit your resume to this email address (VXWORKS@orbital.com), or fax your resume to the attention of "Orbcomm Software Lead" to (703) 406-5553. From mam@pluto.dspt.com Wed Nov 13 07:32:27 1996 From: "Mark Menge" Date: Wed Nov 13 07:32:29 PST 1996 Subject: Formatting SCSI Disks I have been trying to format a seagate ultra scsi model ST31055 using vxWorks 5.3 and found that the format command wiped out my page mode data. I called tech support, installed the "jumbo patch" and ran some code they sent me which was supposed to restore the saved page mode data, but it did not. I finally bough a ADAPT TEC scsi controller and formatted it in my PC and now it works fine. WHAT THE HELL? WHY DO I HAVE TO DO THAT! This sucks. I got deadlines and I am tired of writing code to do low level stuff for every sticking scsi disk that comes along. Questions: 1. Does anyone have some code that will get the default page mode data and put it into the saved mode data? The code vxWorks sent me assumes that when you format a drive the page mode data is restored which is a bad assumption. 2. Is there a place where we can get/put this stuff once completed into the PD? Mark A. Menge DSP Technology Inc. 795 Higland Dr. Ann Arbor Mi, 48108 Phone: (313) 973-1111 Fax: (313) 973-1103 Email: mmenge@dspt.com From daemon@csg.lbl.gov Thu Nov 14 04:00:23 1996 From: daemon@csg.lbl.gov Date: Thu Nov 14 04:00:25 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Nov 14 04:00:20 PST 1996 Subject: Re: Are uou happy with Vx Works and Wind River Subject: Long Trunk I/O Subject: External VME memory card with MVME162 Subject: Re: Are you happy with VxWorks Subject: $$$$$$VxWorks$$$$$$ Subject: Re: run VxWorks in FLASH? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are uou happy with Vx Works and Wind River Date: 12 Nov 1996 17:13:53 -0800 From: pjg@parint.svl.trw.com () Organization: TRW SIG Message-ID: References: <565e0f$5a0@idiom.com> In article <565e0f$5a0@idiom.com> nobody@nowhere writes: From: nobody@nowhere Hey hj, you need to work on your headers a bit more if you are trying to be anonymous. - -- =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= | Paul Gyugyi paul@gyugyi.com | | Paul_Gyugyi@smtp.svl.trw.com http://www.gyugyi.com/ | =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= --------------------------- Newsgroups: comp.os.vxworks Subject: Long Trunk I/O Date: Wed, 13 Nov 1996 09:49:16 -0500 From: "Matthew R. Singer" Organization: Dot-4 Message-ID: <3289DFEC.13BC7F45@griffon.oe.fau.edu> I have an application that I need put push about 200Kb/Sec over a cable about 2000 meters long. Plus I need to be able to send very low speed commands in the other directions. Any suggestions for COTS products that may do this? - -- - ---------------------------------------------------------------------------- Dot4, Inc. The Real-Time Specialists Matthew R. Singer msinger@dot4.com Real Time Systems Engineer 319 Littleton Road, Suite 304 Voice: 508-392-8860 Westford, MA 01886 Fax : 508-392-8861 - ---------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus,comp.sys.m68k Subject: External VME memory card with MVME162 Date: 13 Nov 1996 16:32:36 GMT From: bhanson@bnr.ca (Brian Hanson) Organization: Bell-Northern Research Ltd. Message-ID: <56ct74$3jt@crchh327.rich.bnr.ca> Hi all, I'm having trouble trying to use an external VME memory board with a Motorola MVME162 card, and was wondering if anyone had experienced similar problems or had any insights. I have a test program that produces the correct results on a MVME167 card (with plenty of local RAM). When I run the same program from a MVME162 using the memory on the external card, it seems to run ok (i.e. no bus errors or other exceptions) but produces incorrect results. I have been able to obtain the correct results on the 162 by loading the object file into local RAM, then adding the external RAM to the system memory pool, and then running the program. (The object file itself fits into local RAM, but the dynamic data does not.) I have also been able to get it to work by enabling the cache on the VME address space that contains the external memory. Both of these "fixes" probably work because they reduce access to the VMEbus, but I fear that they are just masking the real problem, which may recur at a later time. Any ideas? BTW, the cards(MVME167, MVME162) are running VxWorks 5.3 in a shared memory network configuration. Brian Hanson bhanson@nortel.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with VxWorks Date: Wed, 13 Nov 1996 22:03:31 -0700 From: Wes Peters Organization: Softweyr LLC Message-ID: <328AA823.41C67EA6@xmission.com> References: <199611121456.JAA10880@atlas.gb.nrao.edu> JOE BRANDT wrote: > At least two persons I know have patched and tested the VxWorks networking > code to add multicasting, AND SENT the patches back to WRS. > > Ask WRS about this and they have no knowledge of it. For pretty much zero > effort, they could have added this technology. > > Why is multicasting a big deal in a RT-OS? > How many of your RT systems have some sort of monitoring? Multicast allows > a single packet sent from a VxWorks system to be delivered to any number > of monitoring stations. For efficientcy reasons multicast is the way to go. If you didn't count Mark Matthews, then of BTS in Salt Lake City, make that 3 persons. The BTS product line makes heavy use of multicast on vw 5.1 and 5.2; it works, and is very solid. Why WRS hasn't included this in the distribution, or at least had one of their engineers go through it, bless it, and put it on an FTP server as "official unsupported" software is beyond me. Perhaps WRS is struggling to be come a more internet-aware company, and does not yet realize the power of providing a resource such as a "tested but unsupported" tools ftp site? - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: $$$$$$VxWorks$$$$$$ Date: Thu, 14 Nov 1996 07:11:49 GMT From: cbowen@mail.sdsu.edu (Chris Bowen) Organization: San Diego State University Message-ID: <56egkp$ela@hole.sdsu.edu> If you or anyone you know has experience both as a user and as a sytems programmer with VxWorks, I have a company that is urgent to hire. If you or anyone you know has experience doing ports of VxWorks to new hardware (i.e. writing board supporting pakages) please contact me as soon as possible. This person must also have 3+ years experience using UNIX. My client prefers someone with experience using VMEbus. Some EE knowledge is a plus! Any leads or insight on how to find this rare animal will be definitely worth your $$$$ time. Chris Bowen Technical Recruiter Culver Group, Inc. Phone: (619) 278-6767 Fax: (619) 278-2312 Email: cbowen@mail.sdsu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: run VxWorks in FLASH? Date: Wed, 13 Nov 1996 22:13:10 -0700 From: Wes Peters Organization: Softweyr LLC Message-ID: <328AAA66.167EB0E7@xmission.com> References: <32889451.4C5E@HiWAAY.net> David Leviner wrote: > Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, > how? Via a really clever boot loader. The loader runs in DRAM and loads the system image using TFTP. Once the image is loaded into DRAM, it is then programmed into the flash. Then the system reboots, running from flash after the reboot. - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- End of New-News digest ********************** From MikeMcQuade@connect.com Thu Nov 14 10:57:01 1996 From: Mike McQuade Date: Thu Nov 14 10:57:03 PST 1996 Subject: Q: using RPC/XDR with Win NT We using RPC / XDR on an HP-UX workstation, talking to a PowerPC target, in the future, we would like use a PC Windows NT box to talk to the target, does anyone know the difference between XDR and the PC's "NDR" ? Will XDR work with NT ?, if not, what are the possible work arounds ? Thanks in advance. Mike McQuade MikeMcQuade@connect.com From adler@bnlku5.phy.bnl.gov Thu Nov 14 12:02:43 1996 From: "Steve Adler" Date: Thu Nov 14 12:02:51 PST 1996 Subject: VxWorks on Linux Host Survey Results VxWorkers, Its been about 2 weeks since I've posted my initial VxWorks on Linux host survey and got 39 replies. Most of them came in a few days after my posting. In anycase, the intention of my survey was clear, I want Wind River to support Linux as a host platform to develope vxworks code. The resons are obvious for anyone who runs linux on their home PC. I wanted to use the results of this survey to motivate RWS to port their Tornado package to Linux. Unfortuantly, I believe my results are biased. I have a feeling that only those who are interested in Linux replied and those who are not just ignored my survey, thus my intention of measuring the true distribution of VxWorks users who are interested in linux may not be correct. (Its hard to believe that 82% of the VxWorks community want RWS to port their development code to linux) Be that as it may, here are the results. One thing to notice. Of the people who were not interested in VxWorks on Linux, there was only one guy who used VxWorks on a Windows 95 platform. The rest used workstation platforms except for one brave sole who got VxWorks running on a PC running FreeBSD. There was one guy who somehow was able to compile his target code on a linux system but the debugging tools still ran on a SUN. Thanks for your participation. I'm going to forward these results to WRS and see what happens. Maybe if those interested in Linux send e-mail to WRS directly we could get their attention on this matter. VxWorks on Linux Host Survey Results Total number of replies: 39 Linux Interest YES Linux Interest No 32 (82%) 7 (18%) B Knowledge of Linux E No interestin Linux becuse.... 25 Linux Guru 5 Use VxWorks on Workstation 5 Linux Novice 0 Linux is unreliable 2 Linux Twink 0 Don't know what Linux is C Linux Distribution 1 Use Windows 95 10 Redhat 0 Use Windows NT 1 Debian 1 Use FreeBSD 12 Slakware 2 Other 5 None 2 Redhat and Slakware D Linux Support from WRS 27 Only VxWorks Support 3 VxWorks Support and Generic Unix Support 2 VxWorks Support, Generic Unix Support, Linux Support From slirosi@gic.gi.com Thu Nov 14 12:39:16 1996 From: "Lirosi, Salvatore (HT-MS)" Date: Thu Nov 14 12:39:25 PST 1996 Subject: Unsubscribe Unsubscribe... From jford@sadira.gb.nrao.edu Thu Nov 14 14:08:17 1996 From: jford@sadira.gb.nrao.edu (John Ford) Date: Thu Nov 14 14:08:19 PST 1996 Subject: Re: Q: using RPC/XDR with Win NT We using RPC / XDR on an HP-UX workstation, talking to a PowerPC target, in the future, we would like use a PC Windows NT box to talk to the target, does anyone know the difference between XDR and the PC's "NDR" ? Will XDR work with NT ?, if not, what are the possible work arounds ? I successfully used RPC (including XDR) on NT with the help of NobleNet`s RPC libraries for NT. We used rpcgen on a Sun to generate the RPC code, then compiled it using noblenet`s NT DLL libraries, compiling with visual C++. The native NT "DCE RPC" is *Not* compatile with ONC (that is, Sun) RPC. I think that someone here at NRAO has made our ONC RPC stuff work on NT, but I'm not sure of any details. I suspect that for someone who knows NT, the standard RPC source code could be easily ported. -- John Ford National Radio Astronomy Observatory Green Bank, WV 24944-0002 jford@nrao.edu From froeber@bbn.com Thu Nov 14 18:03:49 1996 From: Fred Roeber Date: Thu Nov 14 18:03:56 PST 1996 Subject: Re: MV162 external memory problem On Thu, 14 Nov 1996, Brian Hanson wrote: > I have a test program that produces the correct results on a MVME167 > card (with plenty of local RAM). When I run the same program from a > MVME162 using the memory on the external card, it seems to run ok > (i.e. no bus errors or other exceptions) but produces incorrect results. > > I have been able to obtain the correct results on the 162 by loading > the object file into local RAM, then adding the external RAM to the > system memory pool, and then running the program. (The object file > itself fits into local RAM, but the dynamic data does not.) I have > also been able to get it to work by enabling the cache on the VME > address space that contains the external memory. Both of these "fixes" > probably work because they reduce access to the VMEbus, but I fear > that they are just masking the real problem, which may recur at a > later time. > > Any ideas? > > BTW, the cards(MVME167, MVME162) are running VxWorks 5.3 in a shared > memory network configuration. This sounds like an interesting problem but you don't provide quite enough information to determine what might be wrong. The key thing is that since you aren't getting bus errors you shouldn't be having problems due to data that is corrupted due to access timeouts. I assume that you are using memory for this data that isn't being shared with the 167 in any way. If the 167 was sharing any parts of the memory area then you could run into memory coherency problems. The fact that turning on the cache makes things work better makes me wonder if the problem could be tied to misaligned data access errors. Several years ago I had a case with a Radstone board where it incorrectly handled loading misaligned data over the VME bus. By aligning the data and doing only 32 bit accesses the problem went away. Radstone did fix the problem however. Thing is, I can't imagine the Moto board having a problem in this area as their VME interface tends to be pretty well understood and I have never heard of a problem like this with them. You also don't mention but I would assume your code doesn't use any sort of atomic operations (e.g TAS instructions)? If you do, you have to be careful to set up the snooping control bits correctly for the memory area as there are some known problems in this area with the Moto VME interface (the VxWOrks BSP doc contains warnings about the problem too). I would be interested in hearing what you end up finding the problem to be. I agree that this problem isn't one to ignore since it will likely show up somewhere else. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From eknuds@extremenetworks.com Thu Nov 14 19:30:00 1996 From: Eric Knudstrup Date: Thu Nov 14 19:30:02 PST 1996 Subject: Re: Q: using RPC/XDR with Win NT > Will XDR work with NT ?, if not, what are the possible work arounds ? > > I successfully used RPC (including XDR) on NT with the help of > NobleNet`s RPC libraries for NT. We used rpcgen on a Sun to generate > the RPC code, then compiled it using noblenet`s NT DLL libraries, > compiling with visual C++. The native NT "DCE RPC" is *Not* compatile > with ONC (that is, Sun) RPC. I think that someone here at NRAO has > made our ONC RPC stuff work on NT, but I'm not sure of any details. I > suspect that for someone who knows NT, the standard RPC source code > could be easily ported. I have found source for it on the net. I just can't remember where. You might ask in one of the NT newsgroups. From daemon@csg.lbl.gov Fri Nov 15 04:00:30 1996 From: daemon@csg.lbl.gov Date: Fri Nov 15 04:00:33 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Nov 15 04:00:24 PST 1996 Subject: Re: Are you happy with VxWorks Subject: Re: Are you happy with VxWorks Subject: RE: Are you happy with Vx Works and Wind River Subject: Re: multicast Subject: Re: run VxWorks in FLASH? Subject: Re: Using GNAT Ada with VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with VxWorks Date: 14 Nov 1996 20:17:19 GMT From: vbv@giskard.cwru.edu ("Virgilio 'Dean' B. Velasco Jr.") Organization: Case Western Reserve Univ. Cleveland, Ohio (USA) Message-ID: <56fuof$r5l@alexander.INS.CWRU.Edu> References: <2.2.32.19961112021421.006e0954@mail.wrs.com> In article <2.2.32.19961112021421.006e0954@mail.wrs.com>, David Fraser wrote: >(Apologies if your get a duplicate of this message directly on >comp.os.vxworks. We've had some weirdness from our news server forwarding >correctly) > >Dear Users, > >Everyone here at Wind River has been following this particular thread very >closely. Far from ignoring the newsgroup and exploder, I think that all of >us see it as a vital link to the user community. It's become something of >an informal policy of ours, however, not to make too many postings. We >have in mind the double-edged sword of communication which can classify us >either as being defensive or involved in shameless self-promotion. But >we're ready and willing to respond more immediately if that's what you want >from us, and we think it appropriate. Hear, hear! I, for one, am pleased that WRS has been following this discussion. Earlier on, one poster remarked that Wind River was callous to their customers' needs, as manifested by their lack of any posted response. With all due respect to said poster, such remarks are uncalled for (and somewhat below the belt). I say that while we should freely voice our complaints, we should also be prepared to cut the guys some slack. - -- Virgilio "Dean" Velasco Jr, Department of Electrical Eng'g and Applied Physics graduate student slave, roboticist-in-training and Q wannabe http://dora.eeap.cwru.edu/vbv/vbv.html | Remember: Wise men still seek Christ. "And I shall shed my light over dark evil, for darkness cannot stand the light." --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Are you happy with VxWorks Date: 15 Nov 1996 01:09:04 GMT From: schaffer@rain.org (Jeff Schaffer) Organization: RAIN Public Access Internet (805) 967-RAIN Message-ID: <56gfrg$1l8@news.rain.org> References: <2.2.32.19961112021421.006e0954@mail.wrs.com> <56fuof$r5l@alexander.INS.CWRU.Edu> Virgilio 'Dean' B. Velasco Jr. (vbv@giskard.cwru.edu) wrote: : In article <2.2.32.19961112021421.006e0954@mail.wrs.com>, : David Fraser wrote: : >(Apologies if your get a duplicate of this message directly on : >comp.os.vxworks. We've had some weirdness from our news server forwarding : >correctly) : > : >Dear Users, : > : >Everyone here at Wind River has been following this particular thread very : >closely. Far from ignoring the newsgroup and exploder, I think that all of : >us see it as a vital link to the user community. It's become something of : >an informal policy of ours, however, not to make too many postings. We : >have in mind the double-edged sword of communication which can classify us : >either as being defensive or involved in shameless self-promotion. But : >we're ready and willing to respond more immediately if that's what you want : >from us, and we think it appropriate. : : : Hear, hear! I, for one, am pleased that WRS has been following : this discussion. Earlier on, one poster remarked that Wind River was : callous to their customers' needs, as manifested by their lack of any : posted response. With all due respect to said poster, such remarks are : uncalled for (and somewhat below the belt). : : I say that while we should freely voice our complaints, we should : also be prepared to cut the guys some slack. : I agree totally. Personally, I applaud the posting from WRS for its moderation. Unless they answer "we make a rotten system and our service is terrible", we would all assume their answer is self-promotion (and if they did answer that, I doubt we would do business with them). Better to take the route they took - let your users answer the questions and take your chances as to whether the comments are positive or negative, commenting ONLY when necessary. I think it takes a lot of courage on a company's part to do that. -- Jeff Schaffer TimeQuest Technologies schaffer@rain.org --------------------------- Newsgroups: comp.os.vxworks Subject: RE: Are you happy with Vx Works and Wind River Date: Fri, 15 Nov 96 02:05:15 GMT From: banshee@banshee.com (James Moore) Organization: Banshee Software Message-ID: <56gj0a$sgu@q.seanet.com> References: <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com> In article <3.0.32.19961105125526.006a88e4@mailhost.mclean.sparta.com>, Mike Anderson wrote: >With regards to my viewpoint on VxWorks, I find the following things to >be true: > >1) The development environment in VxWorks is as good as that of any > other *embedded* RTOS. That is, it would be wonderful to have > and IDE like Microsoft Visual C++ with the integrated debugger, etc. Having used both sets of tool chains, I have to say that the gnu/gdb setup blows away MSVC++. (Caveat - I've only used C on the Unix side, and C++ on the MSVC++ side.) MSVC is pretty, but it's nowhere near as functional as gdb for debugging. Not having a scripting language for a debugger is a serious defect, and I think the visual model for printing out variables is badly flawed - when you're using gdb, you can set a breakpoint that prints a variable and continues. You end up with screenfuls of history that can be a lifesaver when you're trying to find what data breaks your code. You can also write functions that do things like print out parts of linked lists. There's just nothing at all in MSVC that gives you anything like the same functionality. The class browser in MSVC is OK, but I haven't used C++ in a Unix environment so I can't compare them to anything. For straight C, the emacs tag system is faster and more powerful than the MSVC system. I've found that MSVC is easily confused about where to find functions, and would frequently only bring me to the header file, not the function implementation. I wouldn't argue if you said that MSVC was easier to learn than a gdb setup. It's usually easier to come up to speed on visual tools than command-line ones. But I don't really care how much time it takes to _learn_ the debugger, since it's a tool I'll be using daily for a long time. What I can do with it is far more important, and gdb and emacs win hands down. For writing MFC Windows code, MSVC is great - the wizards do a lot of work for you. But, IMHO, that's the only advantage it has over the tools on the Unix side. I'd gladly trade back any day. James Moore Stupid elephant tricks! http://www.wa-democrats.org/stupid/index.html banshee@banshee.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: multicast Date: Thu, 14 Nov 1996 20:53:21 -0500 From: gwinn@res.ray.com (Joe Gwinn) Organization: Raytheon Electronic Systems Message-ID: References: <199611130250.VAA06027@satchmo.bbn.com> In article <199611130250.VAA06027@satchmo.bbn.com>, Fred Roeber wrote: > While I doubt that we are one of the two people Joe [Brandt] refers to, I was > part of a group at my former employer that had a VxWorks source license and > needed to use multicast. We got the PD code for implementing multicast [snip] > ... Thus while it was easy > for us to get our one particular implementation to work, getting it working > in a general fashion would be quite tough. [snip] > While I certainly go along with Joe [Brandt] that multicast would be nice to > have, I wanted to point out that it wouldn't take "pretty much zero effort". We still have a problem with the lack of true (high-performance) multicast, and I really don't have any sympathy with WRS on this. Multicast is a major need in their chosen field, and they should just solve the problem, and not mumble about the fact that there is more than one I/O device in the world. That's what BSPs are for. I have seen an infrastructure collapse and be thrown away for lack of multicast support in VxWorks; an entirely different approach had to be developed. Very painful. I think that the true issue is that WRS sees their market niche as improving their customers' time-to-market, which WRS translates into putting the major attention into wizzy new (and initially buggy) tools. The dark side is that the kernel, a survivor from the 1970s, is largely neglected. The advantage is that it's quite mature and stable now. I would hope and assume that there is a new and modern (threaded?) kernel growing in a secret back room somewhere; one never knows. There has to be a limit to how long one can ride a 1970s design, and Lynx will eventually get their LynxOS act together, and become a threat to somebody. Joe Gwinn --------------------------- Newsgroups: comp.os.vxworks Subject: Re: run VxWorks in FLASH? Date: 14 Nov 1996 18:24:21 -0800 From: kla@leland.Stanford.EDU (Earl Mitchell) Organization: Stanford University, CA 94305, USA Message-ID: <56gk8l$g1f@elaine23.Stanford.EDU> References: <32889451.4C5E@HiWAAY.net> In article <32889451.4C5E@HiWAAY.net>, David Leviner wrote: >Hi all, > >I'm in the process of working on a BSP for an embedded PC386 with 4MBytes of FLASH >and 2MBytes of DRAM. The end customer needs a majority of the 2MB of DRAM for the >embedded application and the board real estate is limited for adding more DRAM. >Because of these issues the board manufacturer (our customer) is wanting us to >look into the possibility of running VxWorks in FLASH. > >First of all, I've never been presented with this memory problem. We've never had >this type of DRAM limitation. If I'm going to do this, I am assuming that I will >have to run the text section of VxWorks (instructions, constants,etc.) in FLASH >and the data section of VxWorks (i.e., C variables) in DRAM. I know with >Microsoft compilers/linkers you can relocate code in this manner. Is it >possible to do the same in the kernel build for VxWorks. If so, has anyone done >this? > >Or to make the question easier to answer, has anyone run VxWorks in FLASH? If so, >how? Yes at a previous company we did this. In fact it was the same situation (i.e. couple months before shipping we were told we had to run out of flash, because we were going from 4Mb to 1Mb of DRAM). Deja vu!! You need to build a "res_rom" version of VxWorks (i.e. rom resident) which copies its bss and data sections to ram. I can't remember the nitty gritty details but you need to setup the variables which tell the makefile where rom and ram are located and what the sizes are (e.g. ROM_TEXT_ADRS, ROM_SIZE, RAM_HIGH_ADRS, RAM_LOW_ADRS). We did this for 5.2, so 5.3 may be slightly different. Checkout chapter 9 in Tornado User's Guide this has all the info you need to do it. If your application also needs to run from flash then the easiest way to handle this is to link your application code with the kernel image. You make a relocatable image application.o and just add line MACH_EXTA = application.o to Makefile or MakeSkel file. All of this is in Chapter 9. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Using GNAT Ada with VxWorks Date: 15 Nov 1996 04:46:57 GMT From: steved@pacifier.com@199.2.117.163 (Steve Doiel) Organization: Pacifier BBS, Vancouver, Wa. ((360) 693-0325) Message-ID: <56gsk1$raa@news.pacifier.com> References: <328B724E.6033@wrga.saic.com> Reply-To: steved@pacifier.com (Steve Doiel) In <328B724E.6033@wrga.saic.com>, "J. Dean Roberson" writes: >Does anyone have any experience or is knowledgeable of the feasability >of utilizing the GNAT Ada environment (part of GNU/FSF) to support Ada >development with VxWorks? We have an application where the customer >would like to get away from expensive Ada support environments >(Rational) and go all GNU. GNAT Ada is built on top of GCC and uses the >GNU gcc compiler, so the port shouldn't be too hard. Any >advice/suggestions? Have you tried contacting ACT? (Ada Core Technologies) They offer support for GNAT, and might be aware of such a port if it exists. I also read a comment from Robert Dewar of ACT that made me think they have at least considered such a port of GNAT (on comp.lang.ada). You can check their web site at: http://www.gnat.com I hope this helps, Steve Doiel --------------------------- End of New-News digest ********************** From AS_Bridge@MSMAIL3.HAC.COM Fri Nov 15 07:00:17 1996 From: "AS Bridge" Date: Fri Nov 15 07:00:20 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: comp.os.vxworks newsdigest Sent: Fri, Nov 15, 1996 5:45 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Fri, Nov 15, 1996 6:58 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From MikeMcQuade@connect.com Fri Nov 15 07:28:18 1996 From: Mike McQuade Date: Fri Nov 15 07:28:21 PST 1996 Subject: Re: Q: using RPC/XDR with Win NT At 07:30 PM 11/14/96 PST, you wrote: >> Will XDR work with NT ?, if not, what are the possible work arounds ? > >I have found source for it on the net. I just can't remember where. >You might ask in one of the NT newsgroups. > Thanks, I found the source, and some additional info at: http://set.gmd.de/~mfg/oncrpc.html MikeMcQuade@connect.com From fangcj@ix.netcom.com Fri Nov 15 09:54:19 1996 From: CJ Fang Date: Fri Nov 15 09:54:22 PST 1996 Subject: Slow VxWorks on Pentium I am running into a severe problem on a PCI Pentium PC. VxWorks running on a 75M PCI Pentium is about 20 times slower than on 100M 486. Wind River has not been able to give me any data related to VxWorks performace on Pentium. Wind River can not even tell me when they are going to support Pentium. I am supprised that Wind River is not moving to Pentium. Is anyone of you guys using Pentium? Could you please help me if you know something about my problem? I appreciate! I wrote a short routine and used "timexN" to measure the execution speed of my routine. The results were: Pentium: 25656 microsecs 486: 1006 microsecs My routine: int test() { int i, j; for (i=0; i< 20000; i++) j = i+ 1; } Test() was the only application running after VxWorks booted up. From pardo@rti.com Fri Nov 15 13:19:15 1996 From: Gerardo Pardo-Castellote Date: Fri Nov 15 13:19:17 PST 1996 Subject: Re: GNU tool chain versus MSVC > From: banshee@banshee.com (James Moore) > Having used both sets of tool chains, I have to say that the gnu/gdb setup > blows away MSVC++. (Caveat - I've only used C on the Unix side, and C++ > on the MSVC++ side.) MSVC is pretty, but it's nowhere near as functional as > gdb for debugging. Not having a scripting language for a debugger is a > serious defect, and I think the visual model for printing out variables is > badly flawed - when you're using gdb, you can set a breakpoint that prints a > variable and continues. You end up with screenfuls of history that can be a > lifesaver when you're trying to find what data breaks your code. You can also > write functions that do things like print out parts of linked lists. There's > just nothing at all in MSVC that gives you anything like the same > functionality. I agree with James, it may be easier to bootstrap a project from scratch using MSVC but It has a lot of frustraing limitations. In this respect, MSVC's "make" facility comes out to mind, it is incredibly primitive and seems to lack the ability to use environment variables, or even include other makefiles. This becomes a real problem if you work on many projects or the project starts to grow: you end up duplicating a lot of effort whenever you need to make changes accross the board, or start second similar project. Give me the GNU toolchain any day. -Gerardo =========================================================================== = = = = Gerardo Pardo-Castellote = email: pardo@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 = = Sunnyvale, CA 94089 = http://www.rti.com = = = = =========================================================================== From pardo@rti.com Fri Nov 15 13:33:48 1996 From: Gerardo Pardo-Castellote Date: Fri Nov 15 13:33:51 PST 1996 Subject: Re: Slow VxWorks on Pentium CJ, We have used pentiums with VxWorks and found them significantly faster than 486's Your results seem really unusual (impossible?). your loop is about 4 assembly instructions long and it takes more then 1 usec, thats 75 clock cycles for the 75MHz pentium. I would check the following things: - Check that your cache is enabled on the pentium. - Check that the VxWorks measurement of time is correct (e.g. time a taskDelay(600) with a stop watch. - Are you loading the same object to both? If not check the assembly instructions on the Pentium code. -Gerardo =========================================================================== = = = = Gerardo Pardo-Castellote = email: pardo@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 = = Sunnyvale, CA 94089 = http://www.rti.com = = = = =========================================================================== >> >> I am running into a severe problem on a PCI Pentium >> PC. VxWorks running on a 75M PCI Pentium is about >> 20 times slower than on 100M 486. Wind River has >> not been able to give me any data related to >> VxWorks performace on Pentium. Wind River can not >> even tell me when they are going to support >> Pentium. I am supprised that Wind River is not >> moving to Pentium. >> >> Is anyone of you guys using Pentium? Could you >> please help me if you know something about my >> problem? I appreciate! >> >> I wrote a short routine and used "timexN" to >> measure the execution speed of my routine. The >> results were: >> >> Pentium: 25656 microsecs >> >> 486: 1006 microsecs >> >> My routine: >> >> int test() >> { >> int i, j; >> >> for (i=0; i< 20000; i++) >> j = i+ 1; >> } >> >> Test() was the only application running after >> VxWorks booted up. >> From legoas_marco_a@space.honeywell.com Fri Nov 15 14:12:22 1996 From: "Legoas Marco A" Date: Fri Nov 15 14:12:24 PST 1996 Subject: DOS file-IO question The subroutine below fails intermitently when the file closes. Any ideas? I am using 5.1 with mvme167 and Fujitso 520Meg SCSI drives. Your help will be appreciated. Marco A. Legoas malegoas@space.honeywell.com ================================================ int readVwFile (textFileName, bufferPtr, buffMaxSize) char *textFileName; char *bufferPtr; int buffMaxSize; { extern SEM_ID accessSemId; FILE *textFile; /* FILE pointer for the text file. */ unsigned int numOfBytes; unsigned char * fileBuffer; int rtnVal; semTake(accessSemId,WAIT_FOREVER); if ((textFile = fopen(textFileName, "r")) != NULL) { numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile); bufferPtr[numOfBytes] = '\0'; if (numOfBytes > 0 ) rtnVal = numOfBytes; else rtnVal = ERROR; } else rtnVal = ERROR; fclose(textFile); semGive(accessSemId); return(rtnVal); } ===================================================== -> tt tusrintf f3bc _vxTaskEntry +10 : _cvit2UITask (0, 0, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee, eeeeeeee) 87b7ba _cvit2UITask +ca : _XtAppMainLoop ([af6530, 0, f3be, 0, 0]) 93d688 _XtAppMainLoop +1a : _XtAppNextEvent (af6530) 94343e _XtAppNextEvent+b0 : 943288 (af6530) 9432b2 __XtRemoveAllInputs+1b8: _cvit2UiWorkProc ([0, af6530, f4e6bc, f4e6a4, 943442]) 87bd0c _cvit2UiWorkProc+548: _loadText (845390, f4e578) 897a5c _loadText +2a : _readVwFile (f4e578, 69829c, 19000) 8714b2 _readVwFile +5e : _fclose (6bcd74) 112d2 _fclose +5a : ___sclose (6bcd74) 12ade ___sclose +1c : _close ([11, 0, f4e468, 112d8, 6bcd74]) 307d4 _close +8 : _iosClose ([11, f4e454, 12ae4, 11, 0]) 31472 _iosClose +7c : 28ab4 (fd8288) 28be8 _stat +1e2: _free (6b996c) 32882 _free +e : _memPartFree ([8352e, 6b996c, f4e420, 28bee, 6b996c] ) 32618 _memPartFree +dc : _taskSuspend (0) value = 0 = 0x0 From froeber@bbn.com Fri Nov 15 17:10:50 1996 From: Fred Roeber Date: Fri Nov 15 17:10:52 PST 1996 Subject: Re: Slow VxWorks on Pentium On Fri, 15 Nov 1996, CJ Fang wrote: > I wrote a short routine and used "timexN" to > measure the execution speed of my routine. The > results were: > > Pentium: 25656 microsecs > > 486: 1006 microsecs > > My routine: > > int test() > { > int i, j; > > for (i=0; i< 20000; i++) > j = i+ 1; > } Your performance difference could very well have nothing to do with the processors you are using but everything to do with the compiler and compiler options you are using. The routine above should be turned into a null routine by any compiler with a good optimizer. Try making i and j volatile or global and see if you get the same results. In general, you should be very careful when benchmarking compilers and processors to use non-trivial test programs. There are useful benchmark suites in the public domain that I have used in the past. It has been a while since I ran benchmarks but the comp.benchmarks news group FAQ used to have some good pointers on this issue. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From YF.Siu@eng.efi.com Fri Nov 15 17:14:27 1996 From: "Yuet Fung Siu" Date: Fri Nov 15 17:14:29 PST 1996 Subject: Re: DOS file-IO question > numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile); > bufferPtr[numOfBytes] = '\0'; If fread() happens to return buffMaxSize number of bytes, the next statement is going to write beyond bufferPtr. This could cause memory corruption depending on the size of the allocated buffer. Good Luck, YF From froeber@bbn.com Fri Nov 15 17:25:15 1996 From: Fred Roeber Date: Fri Nov 15 17:25:18 PST 1996 Subject: Re: DOS file-IO question On Fri, 15 Nov 1996, "Legoas Marco A" wrote: > > The subroutine below fails intermitently when the file closes. Any ideas? > > ================================================ > int readVwFile (textFileName, bufferPtr, buffMaxSize) > char *textFileName; > char *bufferPtr; > int buffMaxSize; > { > extern SEM_ID accessSemId; > > FILE *textFile; /* FILE pointer for the text file. */ > unsigned int numOfBytes; > unsigned char * fileBuffer; > int rtnVal; > > semTake(accessSemId,WAIT_FOREVER); > if ((textFile = fopen(textFileName, "r")) != NULL) > { > numOfBytes = fread(bufferPtr, sizeof(char), buffMaxSize, textFile); > bufferPtr[numOfBytes] = '\0'; > if (numOfBytes > 0 ) > rtnVal = numOfBytes; > else > rtnVal = ERROR; > } < CUT...> The "bufferPtr[numOfBytes] = '\0';" statement above could cause problems if you get an error return (ie numOfBytes < 0) since you would be overwriting data that wasn't part of your data area. Not really sure why you want to NULL terminate data you are reading with an fread call anyway? Usually, you want to use fgets if you are reading textual data since that routine takes care of handling newline characters and null terminating input data. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From daemon@csg.lbl.gov Sat Nov 16 04:00:27 1996 From: daemon@csg.lbl.gov Date: Sat Nov 16 04:00:29 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Nov 16 04:00:23 PST 1996 Subject: Re: Using GNAT Ada with VxWorks Subject: Re: varargs on PowerPC with 5.2 Subject: Using GNAT Ada with VxWorks Subject: Re: VxWorks on Linux Host Survey Results Subject: SCSI and ethernet driver ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Using GNAT Ada with VxWorks Date: 15 Nov 1996 16:12:12 GMT From: tadlock@bosch.dseg.ti.com (edward tadlock) Message-ID: References: <328B724E.6033@wrga.saic.com> Reply-To: ed-tadlock@ti.com The best suggestion is to call WRS and ask questions about your plans and see what they suggest. My project at TI is using Rational (VADS) Ada and VxWorks via the VADSWorks package (be careful, some problems with VADSWorks and Tornado). As far as I know and have been told, VADWorks is the only fully supported Ada interface to VxWorks. If you want to use the full real-time capabilites of VxWorks,you'll need to buy/develop something like VADSWorks with allows the Ada run-time to use the VxWorks kernal services. To develop this kind of an interface you will need insight into the actual source code and design of VxWorks at the kernel level. If you need to do this interface yourself, Wind River will sell the source for VxWorks but they do ask a BIG price for copies of the source code. Moving to GNAT is not impossible to do, but it might be cheaper in the long run to buy a package from Wind River or Rational since the price includes support. Also, unless you can get a BSP for your chips and boards from WRS that is also something you'll have to build yourself. WRS has a "porting" kit they sell to help you do this. So, call WRS and ask before committing to using GNAT Ada and VxWorks together. As always, YMMV... Ed --------------------------- Newsgroups: comp.os.vxworks Subject: Re: varargs on PowerPC with 5.2 Date: 15 Nov 1996 17:06:59 GMT From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Organization: Jet Propulsion Laboratory, Pasadena, CA Message-ID: <56i7vj$mbm@netline-fddi.jpl.nasa.gov> References: <555bdp$cms@post.gsfc.nasa.gov> Joe Vitale writes: > We have run into a dead end trying to implement our own functions that > take a variable number of arguments as input. We are using VxWorks > 5.2 on an Ultra PowerPC 603 motherboard. We are using the Green Hills > C/C++ Compiler and everything is hosted on a Solaris workstation. I don't know anything about your specific environment. But if you are willing to consider inserting your own support for varargs, and not using the one provided by your development environment, then you might consider what I've done. Back in the old days on a DEC VAX/VMS machine before DEC's C compiler supported varargs, I wrote a set of macros which worked just fine. I've included them below. They may not work on your system without some modification, but give them a try. If you have any trouble understanding what they are doing, feel free to ask. (In particular, the reason for the +3 and /4 is that VMS only pushed items onto the call stack in multiples of 4 bytes, padding out if necessary.) Below is the contents of varargs.h: /**************************************************************************** * * * varargs.h * * * ****************************************************************************/ /* varargs.h * Implemented by Todd Litwin * February 7, 1984 * * This implementation, which conforms to the Berkeley UNIX manual quoted * below, has been designed to work with the VAX VMS C compiler. */ /* SYNOPSIS #include function(va_alist) va_dcl va_list pvar; va_start(pvar); f = va_arg(pvar, type) va_end(pvar); DESCRIPTION This set of macros allows portable procedures that accept variable argument lists to be written. Routines which have variable argument lists (such as printf(3)) that do not use varargs are inherently nonportable since different machines use different argument passing conventions. va_alist is used in a function header to declare a variable argument list. va_dcl is a declaration for va_alist. Note that there is no semicolon after va_dcl. va_list is a type which can be used for the variable pvar, which is used to traverse the list. One such variable must always be declared. va_start (pvar) is called to initialize pvar to the beginning of the list. va_arg (pvar,type) will return the next argument in the list pointed to by pvar. Type is the type the argument is expected to be. Different types can be mixed, but it is up to the routine to know what type of argument is expected, since it cannot be determined at runtime. va_end (pvar) is used to finish up. Multiple traversals, each bracketted by va_start ... va_end, are possible. [UNIX Programmer's Manual, 7th edition, 1979, VARARGS(3)] */ #define va_alist _VA_Arg1 #define va_dcl int _VA_Arg1; typedef struct { int *ptr; int width; } va_list; #define va_start(pvar) ((pvar.ptr = &_VA_Arg1), (pvar.width = 0)) #define va_arg(pvar, type) \ (((int *) pvar.ptr += pvar.width), \ (pvar.width = (((sizeof (type)) + 3) / 4)), \ (*((type *) (pvar.ptr)))) #define va_end(pvar) - -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 Todd.E.Litwin@jpl.nasa.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Using GNAT Ada with VxWorks Date: Thu, 14 Nov 1996 14:30:31 -0500 From: "J. Dean Roberson" Organization: SAIC Message-ID: <328B724E.6033@wrga.saic.com> Reply-To: roberson@wrga.saic.com Does anyone have any experience or is knowledgeable of the feasability of utilizing the GNAT Ada environment (part of GNU/FSF) to support Ada development with VxWorks? We have an application where the customer would like to get away from expensive Ada support environments (Rational) and go all GNU. GNAT Ada is built on top of GCC and uses the GNU gcc compiler, so the port shouldn't be too hard. Any advice/suggestions? Our target boards are FORCE CPU-2CE (SPARC-yuck!) and some older Heurikon HKV30 (68K) and Heurikon Baja (MIPS R4700) boards for the future (Heurikon forever!). Staying all gcc makes a lot of sense, but we have no experience with GNAT. Thanks for any advice, Dean. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks on Linux Host Survey Results Date: 15 Nov 1996 14:32:08 -0700 From: bgeer@xmission.xmission.com (bgeer) Organization: XMission Internet (801 539 0900) Message-ID: <56ingo$2c9@xmission.xmission.com> References: <9611141501.ZM3551@bnlku5.phy.bnl.gov> "Steve Adler" writes: I responded positively to Steve wrt VxWorks support on Linux. I have at least 3 work colleagues who use Linux extensively & also would like the option to develop for VxWorks on Linux; unfortunately I could not get them to take the time to respond to Steve hence aren't represented in Steve's numbers. You'd have to know Utah culture to understand why these guys couldn't take the time...:-) >... The resons are obvious for anyone who runs linux on their home PC. Actually, I run Linux at both work & home. It beats the hell out of Windoze for networking with Unix boxes, is far more reliable, & has a much more flexible desktop environment. I only boot Windoze to do my time card 'cause it's programmed in Visual Basic...:-( BTW, my 486DX2-66 manages 12.5 Whetstones running Linux, same as a Sun Sparc IPX. My AMD5x86-133 at home manages 25-33.333, same as Sun Sparc 10. Ok...so Whetstone isn't a particularly good benchmark these days; but hey, the numbers are impressive, aren't they? :-) >I wanted to use the results of this survey to motivate RWS to port >their Tornado package to Linux. I'd be happy with Linux (intel) gcc to [68k, mips, sparc, powerpc] cross compiler & object manipulation tools. I'll bet the scripts & makefiles would port almost directly (I have been able to make scripts completely compatible). Considering how easy it is to build applications for both SunOS4 & Linux, I'll bet the compilables would port almost directly as well. Linux gives one a robust, stable environment for development, & it runs very well (including X) on much-cheaper-than-Unix laptops. [Stepping down from soapbox...] Cheers, Bob - -- <> Robert Geer & Donna Tomky / * <> <> bgeer@xmission.com | _o * o * o <> <> Salt Lake City, Utah | -\<, * <\ <> U S A | O/ O __ /__, /> <> --------------------------- Newsgroups: comp.os.vxworks Subject: SCSI and ethernet driver Date: Sat, 16 Nov 1996 01:27:28 +0000 From: Hung Tran Organization: Dynatem Message-ID: <328D1880.479D@dynatem.com> Hi all, Anyone out there have driver source code available for the DEC21140A fast ethernet LAN controller and/or the SCSI Adaptec AIC-7880 ? One for the x86 architecture would be preferable, but anything else would still be helpful. Hung --------------------------- End of New-News digest ********************** From jford@sadira.gb.nrao.edu Sat Nov 16 10:56:03 1996 From: jford@sadira.gb.nrao.edu (John Ford) Date: Sat Nov 16 10:56:06 PST 1996 Subject: Re: Slow VxWorks on Pentium Submitted-by froeber@bbn.com Fri Nov 15 17:10:50 1996 Submitted-by: Fred Roeber On Fri, 15 Nov 1996, CJ Fang wrote: > I wrote a short routine and used "timexN" to > measure the execution speed of my routine. The > results were: > > Pentium: 25656 microsecs > > 486: 1006 microsecs > > My routine: > > int test() > { > int i, j; > > for (i=0; i< 20000; i++) > j = i+ 1; > } Your performance difference could very well have nothing to do with the processors you are using but everything to do with the compiler and compiler options you are using. ... Agreed, But he could also be running into a system management mode problem. The system's, bios/chipset could be putting the CPU in some sort of sleep mode. This could also happen if the CPU is getting too hot, or if the BIOS does not see any activity for a while. -- John Ford National Radio Astronomy Observatory Green Bank, WV 24944-0002 jford@nrao.edu From daemon@csg.lbl.gov Sun Nov 17 04:00:25 1996 From: daemon@csg.lbl.gov Date: Sun Nov 17 04:00:27 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Nov 17 04:00:22 PST 1996 Subject: SCSI Drivers for sequential access? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: SCSI Drivers for sequential access? Date: Sat, 16 Nov 1996 12:56:22 -0800 From: dhayes49@mail.idt.net (Dean Hayes) Organization: IDT Message-ID: Has anyone used the scsiIoctl function call to implement a device driver for sequential access devices? The VxWorks kernel is extremely lacking in this respect. There release notes say to "roll your own", or to higher a third party. IN particular, I am dealing with an HP DAT tape drive. --------------------------- End of New-News digest ********************** From fareed@aloha.nmsu.edu Mon Nov 18 17:52:16 1996 From: Fareed Masarrat Date: Mon Nov 18 17:52:19 PST 1996 Subject: SCSI drives I am having a problem with SCSI drives in a VME enclosure. When a file is created on the drives, it is corrupted by any files which are created after it. It is corrupted in the sense that after the 1024 byte, the data in the file is different that what was originally placed in the file. That might be a jumper problem but it has been checked and verified. I would appreciate if anybody can give us any direction to go further. Thanks ---------------------------- Fareed Research Assistant New Mexico State University ---------------------------- From YF.Siu@eng.efi.com Mon Nov 18 18:15:52 1996 From: "Yuet Fung Siu" Date: Mon Nov 18 18:15:58 PST 1996 Subject: EIDE/ATA-2 driver Has anyone got the EIDE/ATA-2 driver package from WRS ? I would like to gather some comment and know if CDROM support has been included. Thanks, YF From parikh@ll.mit.edu Mon Nov 18 19:00:30 1996 From: Salil Parikh Date: Mon Nov 18 19:00:33 PST 1996 Subject: Cold Boot / Warm Boot Is there a way in VxWorks to distinguish between a warm boot and a cold boot? I'm using the Motorola MVME147 SBC. Thanks! From ensslin@dreisoft.de Tue Nov 19 01:52:23 1996 From: Friedrich Ensslin Date: Tue Nov 19 01:52:26 PST 1996 Subject: 53C810 SCSI Controller Hi all, Does anyone have any info on VxWorks SCSI drivers for the NCR 53C810 SCSI Controller. Thanks fo the info. ------------------------------------------------ Friedrich Ensslin 3SOFT GmbH Wetterkreuz 19a , D-91058 Erlangen , Germany phone: +49 9131 7701-0 , fax: +49 9131 7701-80 email: ensslin@dreisoft.de From ensslin@dreisoft.de Tue Nov 19 01:56:58 1996 From: Friedrich Ensslin Date: Tue Nov 19 01:57:00 PST 1996 Hi all, Does anyone have any info on VxWorks PCMCIA drivers. One of our customers wants to connect a PCMCIA solid state disk to his VxWorks 5.3 target, using a 82365SL PCMCIA controller chip. Thanks for the info. ------------------------------------------------ Friedrich Ensslin 3SOFT GmbH Wetterkreuz 19a , D-91058 Erlangen , Germany phone: +49 9131 7701-0 , fax: +49 9131 7701-80 email: ensslin@dreisoft.de From daemon@csg.lbl.gov Tue Nov 19 04:00:19 1996 From: daemon@csg.lbl.gov Date: Tue Nov 19 04:00:22 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Nov 19 04:00:17 PST 1996 Subject: Re: VxWorks on Linux Host Survey Results Subject: VxWorks and x86??? Subject: VxWorks and x86??? Subject: Re: Using GNAT Ada with VxWorks Subject: multicast & VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks on Linux Host Survey Results Date: 18 Nov 1996 16:21:42 GMT From: thor@ymir.atd.ucar.edu (Rich Neitzel) Organization: National Center for Atmospheric Research Message-ID: <56q2em$jru@ncar.ucar.edu> References: <9611141501.ZM3551@bnlku5.phy.bnl.gov> <56ingo$2c9@xmission.xmission.com> In article <56ingo$2c9@xmission.xmission.com>, bgeer@xmission.xmission.com (bgeer) writes: |> |> I'd be happy with Linux (intel) gcc to [68k, mips, sparc, powerpc] |> cross compiler & object manipulation tools. I'll bet the scripts & |> makefiles would port almost directly (I have been able to make scripts |> completely compatible). Considering how easy it is to build |> applications for both SunOS4 & Linux, I'll bet the compilables would |> port almost directly as well. I've compiled the entire GNU tool chain under Linux for 68k targets. No problems noted to date. Tool compilation was identical to the build under Solaris 2.x. Makefiles for target programs are identical as well. Futher, I've got the 68ks booting off the Linux system via bootp. We could completely replace our Suns as developement hosts if we didn't have so many of them. - -- Richard Neitzel thor@atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjx'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks and x86??? Date: 18 Nov 1996 16:02:47 GMT From: enzo@u1.abs.net (Jerome Kelly) Organization: ABSnet Internet Services - sales@abs.net - (410)-361-8160 Message-ID: <56q1b7$c0b@news.abs.net> - -- - --------------------------------------------------------------------------- | EnzoH2O |"I can picture in my mind a world without | | Jerry Kelly |war, a world without hate. And I can picture| | Alexandria, Virginia, USA |us attacking that world, because they'd never| | |expect it." | - --------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks and x86??? Date: 18 Nov 1996 16:13:40 GMT From: enzo@u1.abs.net (Jerome Kelly) Organization: ABSnet Internet Services - sales@abs.net - (410)-361-8160 Message-ID: <56q1vk$c0b@news.abs.net> - -- - --------------------------------------------------------------------------- | EnzoH2O |"I can picture in my mind a world without | | Jerry Kelly |war, a world without hate. And I can picture| | Alexandria, Virginia, USA |us attacking that world, because they'd never| | |expect it." | - --------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Using GNAT Ada with VxWorks Date: 18 Nov 1996 14:23:58 -0500 From: hartwig@hartwig.lfso.loral.com (Michael R. Hartwig) Organization: Lockheed Martin Federal Systems Message-ID: References: <328B724E.6033@wrga.saic.com> Reply-To: michael.hartwig@lmco.com Sender: hartwig@hartwig.lfso.loral.com In article tadlock@bosch.dseg.ti.com (edward tadlock) writes: > As far as I know and have been told, VADWorks is the only fully supported Ada > interface to VxWorks. Green Hills Ada Multi is supposed to be fully Tornado-aware. It will generate code for VxWorks. I'd give you a better report, but we just got our evaluation copy of the Green Hills compilers on Friday and haven't had a chance to get them up and running yet. Michael - -- Michael Hartwig Michael.Hartwig@lmco.com Lockheed Martin Federal Systems, Owego, NY --------------------------- Newsgroups: comp.os.vxworks Subject: multicast & VxWorks Date: Mon, 18 Nov 1996 17:16:59 -0800 From: Gary Steven Fish Organization: Hughes Aircraft Co. WSS/NAMS Message-ID: <32910A8B.6C@ccgate.hac.com> References: <199611121456.JAA10880@atlas.gb.nrao.edu> <328AA823.41C67EA6@xmission.com> Wes Peters wrote: > > JOE BRANDT wrote: > > At least two persons I know have patched and tested the VxWorks networking > > code to add multicasting, AND SENT the patches back to WRS. > > > > Ask WRS about this and they have no knowledge of it. For pretty much zero > > effort, they could have added this technology. > > > > Why is multicasting a big deal in a RT-OS? > > How many of your RT systems have some sort of monitoring? Multicast allows > > a single packet sent from a VxWorks system to be delivered to any number > > of monitoring stations. For efficientcy reasons multicast is the way to go. > Can anyone tell me where I can get a copy of this multicast software that has been ported to VxWorks 5.2 and/or 5.3? If it is not yet available on one of the archives, can someone email me a copy of the above mentioned patch or tell me who to contact? Thanks in advance, - -- Gary S. Fish Sr. Staff Eng. Work - 714-732-7343 Hughes Aircraft Co. FAX - 714-732-0149 Fullerton Ca. Email - gsfish@ccgate.hac.com --------------------------- End of New-News digest ********************** From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 19 04:16:02 1996 From: "AS Bridge" Date: Tue Nov 19 04:16:04 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Sent: Tue, Nov 19, 1996 3:11 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 19, 1996 4:15 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 19 04:16:04 1996 From: "AS Bridge" Date: Tue Nov 19 04:16:07 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: 53C810 SCSI Controller Sent: Tue, Nov 19, 1996 3:12 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 19, 1996 4:15 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 19 06:19:54 1996 From: "AS Bridge" Date: Tue Nov 19 06:19:56 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: comp.os.vxworks newsdigest Sent: Tue, Nov 19, 1996 5:14 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 19, 1996 6:17 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From legoas_marco_a@space.honeywell.com Tue Nov 19 06:37:23 1996 From: "Legoas Marco A" Date: Tue Nov 19 06:37:25 PST 1996 Subject: Thanks:DOS file-IO question Would like to thanks: Lasse Kinnunen, Fred J Roeber, Yuet Fung Siu, Alan Nishioka. for their valuable feedback. Marco A. Legoas From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 19 06:38:38 1996 From: "AS Bridge" Date: Tue Nov 19 06:38:40 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: Undeliverable Mail Sent: Tue, Nov 19, 1996 5:37 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 19, 1996 6:37 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From AS_Bridge@MSMAIL3.HAC.COM Tue Nov 19 06:41:41 1996 From: "AS Bridge" Date: Tue Nov 19 06:41:43 PST 1996 Subject: Undeliverable Mail Unknown Microsoft mail form. Approximate representation follows. Message: Undeliverable Mail Sent: Tue, Nov 19, 1996 5:38 AM To: Carroll, John C; Claudio, Michael A On Server: 631 Segment5 Date: Tue, Nov 19, 1996 6:39 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From intrepid!minidds@uunet.uu.net Tue Nov 19 08:40:43 1996 From: intrepid!minidds@uunet.uu.net (Lee Kappel) Date: Tue Nov 19 08:40:45 PST 1996 Subject: tnetTask, Serial I/O, and Ring Buffers Has anyone had trouble with corruption of ring buffers and a resulting instruction access exception in tnetTask. We are using VxWorks 5.3, and our target is the PowerPC 604 (Motorola MVME1604). The only application running is doing continuous serial output to comm port 1 (/tyCo/0), and we are not sure why tnetTask is active at all unless it is maintaining some periodic communication with our host. Thanks, >>>>>>>>>>>>>>>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Lee Kappel >>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>>>>>>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Raytheon E-Systems Communications Division ~ ~ P.O. Box 12248, M.S. 61 ~ ~ St. Petersburg, FL 33733-2248 ~ ~ Phone: 813-381-2000 ext. 7209 ~ ~ Fax: 813-347-2890 ~ ~ E-Mail: kappel@eci-cec.com ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From espin@idiom.com Tue Nov 19 09:12:36 1996 From: Geoffrey Espin Date: Tue Nov 19 09:12:42 PST 1996 Subject: Re: Cold Boot / Warm Boot > Submitted-by: Salil Parikh > Is there a way in VxWorks to distinguish between a warm boot and a cold boot? > I'm using the Motorola MVME147 SBC. It's pretty straight-forward to track down on any BSP & Architecture because you have all the source code required. With the traditional 68k bootrom which loads vxWorks, the hand-off is accomplished by the two entry points "cold:" and "warm:" in romInit.s. On a power-cycle "romInit:" goes thru the "cold:" entry point which pushes the startType on the stack which bootInit.c:romStart() picks up, uses and passes on to bootConfig.c:usrInit(). A warm-start by definition goes thru sysLib.c:sysToMonitor() which knows (via Makefile ROM_TEXT_ADRS) the "warm:" entry point in romInit.s. By the time the actual vxWorks image is loaded the startType is considered "warm" in sysALib.s:sysInit(). The sequence is simpler for vxWorks_rom and in fact better because the startType for the new incarnation has not been lost by going thru sysALib.s:sysInit(). Geoff -- Geoffrey Espin espin@idiom.com From sridhar@prc.allied.com Tue Nov 19 10:30:07 1996 From: sridhar@prc.allied.com (Sridhar Adumusilli) Date: Tue Nov 19 10:30:14 PST 1996 Subject: GNU Compiler 2.6 Does any one know if 2.6 version can be used to compile templates? Thanks for any help. Sridhar AlliedSignal Aerospace From mikemcquade@connect.com Tue Nov 19 12:07:10 1996 From: mikemcquade@connect.com Date: Tue Nov 19 12:07:12 PST 1996 Subject: Re: tnetTask, Serial I/O, and Ring Buffers the vxWorks Users Group Exploder wrote: > > Submitted-by intrepid!minidds@uunet.uu.net Tue Nov 19 08:40:43 1996 > Submitted-by: intrepid!minidds@uunet.uu.net (Lee Kappel) > > Has anyone had trouble with corruption of ring buffers and > a resulting instruction access exception in tnetTask. > > We are using VxWorks 5.3, and our target is the PowerPC 604 > (Motorola MVME1604). > > The only application running is doing continuous serial > output to comm port 1 (/tyCo/0), and we are not sure why > tnetTask is active at all unless it is maintaining some > periodic communication with our host. > Ive seen the same thing on a MVME-1604 (133Mhz), my app is reading data off the VME bus, and sending it out over the Lan, Ive seen tNetTask panic: mget, panic: mfree, and more often, the target just crashes with no clues. I can compile the same app for 603, and run on a 603e for hours on end. Mike From stan@rti.com Tue Nov 19 12:51:27 1996 From: Stan Schneider Date: Tue Nov 19 12:51:29 PST 1996 Subject: Re: GNU Compiler 2.6 >> >> Does any one know if 2.6 version can be used to compile >> templates? >> Sort of. You can compile *a* template, but if you ever derive two objects from it & try to use both, it will fail. 2.7.2 fixed this problem. -- Stan stan@rti.com From fareed@aloha.nmsu.edu Tue Nov 19 14:19:02 1996 From: Fareed Masarrat Date: Tue Nov 19 14:19:04 PST 1996 Subject: Re: SCSI drives We are using VxWorks 5.2 and the target is FORCE 68040. We are having a problem with SCSI drives in a VME enclosure. When a file is created on the drives, it is corrupted by any files which are created after it. It is corrupted in the sense that after the 1024 byte, the data in the file is different that what was originally placed in the file. That might be a jumper problem but it has been checked and verified. I would appreciate if anybody can give us any direction to go further. Thanks ---------------------------- Fareed Research Assistant New Mexico State University ---------------------------- From uchenick@tis4000.com Tue Nov 19 14:35:37 1996 From: Gordon Uchenick Date: Tue Nov 19 14:35:39 PST 1996 Subject: errno = EHOSTDOWN Does anyone have any words of wisdom about how to handle errno = EHOSTDOWN after send() on a TCP/IP socket returns ERROR? I'm looking for a less drastic solution than closing the socket and reestablishing the connection. TIA Gordon Uchenick uchenick@tis4000.com From froeber@bbn.com Tue Nov 19 18:49:54 1996 From: Fred Roeber Date: Tue Nov 19 18:49:56 PST 1996 Subject: Re: Cold Boot / Warm Boot On Mon, 18 Nov 1996, Salil Parikh wrote: > Is there a way in VxWorks to distinguish between a warm boot and a cold boot? > > I'm using the Motorola MVME147 SBC. The variable sysStartType contains flag bits that indicate the type of start that occured. There are values that can be used to distinguish a warm vs a cold start. Look at the source files in the config/all directory for uses of sysStartType. Look at the romInit.s file in the config/mv147 for the values it sets startType parameter to (the startType parameter gets stored in sysStartType). While that answers your question, I am not sure that it addresses what you really want. A lot of times, I consider a cold start to be a "power up" start and a warm start to be a restart due to a VME reset. This isn't the meaning of the cold and warm start flags in sysStartType; the VxWorks flags are based on whether the processor boots from a reset or from a "reboot" function call (i.e. a ^X console command). There is a status bit in one of the MV147 peripheral chips that indicates a power-up vs other restart but the bit is cleared by the VxWorks startup code (in sysHwInit function in sysLib.c I think). You could always modify the BSP to save that bit if that is what you really want. Hope the info helps. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From daemon@csg.lbl.gov Wed Nov 20 04:00:22 1996 From: daemon@csg.lbl.gov Date: Wed Nov 20 04:00:24 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Nov 20 04:00:19 PST 1996 Subject: Recursive Makefiles under NT Subject: Re: Cold Boot / Warm Boot Subject: Re: Recursive Makefiles under NT Subject: STREAMS ioctl error Subject: Re: GNU tool chain versus MSVC Subject: Porting DLL Subject: Date/Time on x86 platform?? Subject: test Subject: test Subject: problem if gettimeofday() Subject: Re: Delta-Tau PMAC Driver Subject: need your HELP!!! ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Recursive Makefiles under NT Date: Tue, 19 Nov 1996 15:22:03 GMT From: jasonv@delphi-assoc.com (Jason Velody) Organization: delphi-assoc.com Message-ID: <3291d000.20436640@news1.theplanet.co.uk> Hi there, Has anyone managed to get recursive makefiles to work properly under Tornado for Windows? I am suffering from a singular lack of success. Yours despondently Jason - ------------------------------------------------------------------------------ You are lost in a maze of twisty little standards - all conflicting... Jason Velody jasonv@delphi-assoc.com Senior Network Consultant http://www.angel.co.uk/delphi Delphi Associates Ltd (+44) 171 357 0303 - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Cold Boot / Warm Boot Date: Sun, 17 Nov 96 06:42:21 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56sl6u$3ki@idiom.com> References: <9611182158.AA21018@LL.MIT.EDU> In article <9611182158.AA21018@LL.MIT.EDU>, Salil Parikh wrote: > > >Is there a way in VxWorks to distinguish between a warm boot and a cold boot? > sysToMonitor() gets called with an argument indicating cold/warm boot. In general, this is distinguishable in low level start up code, and you can control it as you please. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Recursive Makefiles under NT Date: Sun, 17 Nov 96 06:40:21 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <56sl36$3ki@idiom.com> References: <3291d000.20436640@news1.theplanet.co.uk> In article <3291d000.20436640@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote: >Hi there, > >Has anyone managed to get recursive makefiles to work properly under >Tornado for Windows? I am suffering from a singular lack of success. > Works fine for me. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: STREAMS ioctl error Date: 19 Nov 1996 17:33:52 GMT From: markkelly9@aol.com Organization: America Online, Inc. (1-800-827-6364) (1.13) Message-ID: <19961119173600.MAA26475@ladder01.news.aol.com> I am trying to port a STREAMS based package to vxWorks using their WindNet STREAMS for Tornado x86 release 1.0 dated Sep 20 1996. I get an error on an ioctl call: if ((retStat = ioctl(B->fd, I_STR, (int)&ioctlmsg)) != 0) { ioctlfailed = TRUE; printf("ioctl failed with return status=%d errno=%d\n", retStat, errno); } retStat is -1 and errno is 74. errno.h defines ENOSR as 74. Does anyone know what causes an ENOSR error? Is there some STREAMS or system V newsgroup I should be reading? Thanks, Mark Kelly --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GNU tool chain versus MSVC Date: Tue, 19 Nov 1996 18:44:49 GMT From: VanCLy@ix.netcom.com (Van Chinh Ly) Organization: Netcom Message-ID: <56sv3s$n5n@sjx-ixn8.ix.netcom.com> References: <199611152123.NAA19052@lassen.rti.com> Reply-To: VanCLy@ix.netcom.com Gerardo Pardo-Castellote wrote: >I agree with James, it may be easier to bootstrap a project from >scratch using MSVC but It has a lot of frustraing limitations. In this >respect, MSVC's "make" facility comes out to mind, it is incredibly >primitive and seems to lack the ability to use environment variables, >or even include other makefiles. This becomes a real problem if you If you are referring to the program NMAKE.EXE, I believe you can use environment variables by referring to them in the makefile with percent signs surrounding the variable name. (e.g. %PATH% would give you the current path). As for including other makefiles, that is possible with the command "!INCLUDE," as most make files from Microsoft start with "!INCLUDE " which basically includes that file in the original makefiles. They may not be the same syntax that the GNU make uses, but I think the capabilities are there. Van --------------------------- Newsgroups: comp.os.vxworks Subject: Porting DLL Date: Wed, 20 Nov 1996 10:18:48 +0900 From: "Lee, Soo-Ryong" Organization: LGNIC Message-ID: <32925C78.315F@gsen.goldstar.co.kr> Hi, everyone I'm wondering how can I port windows DLL program into vxworks environment. Any comment O.K. --------------------------- Newsgroups: comp.os.vxworks Subject: Date/Time on x86 platform?? Date: Tue, 19 Nov 1996 21:47:20 -0800 From: eric olsen Organization: stanford university Message-ID: <32929B68.76D6829D@leland.stanford.edu> Hello, Does anyone have the appropriate code to get the date/time from the bios. The 'ansi' time function supplied with vxworks does not return the actual date, even though there is a clock on the pc keeping track of it. Thanks, - -------------------------------------------------------------- "How can I lose to such an idiot?" Aaron Nimzovich(1886-1935) eric olsen eolsen@leland.stanford.edu - -------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: test Date: Wed, 20 Nov 1996 17:44:31 +0800 From: "Dr. Zexiang Li's Robotic Project" Organization: Hong Kong University of Science and Technology Message-ID: <3292D2FF.167EB0E7@ee.ust.hk> test --------------------------- Newsgroups: comp.os.vxworks Subject: test Date: Wed, 20 Nov 1996 17:52:54 +0800 From: "Dr. Zexiang Li's Robotic Project" Organization: Hong Kong University of Science and Technology Message-ID: <3292D4F6.446B9B3D@ee.ust.hk> test --------------------------- Newsgroups: comp.os.vxworks Subject: problem if gettimeofday() Date: Wed, 20 Nov 1996 17:48:00 +0800 From: "Dr. Zexiang Li's Robotic Project" Organization: Hong Kong University of Science and Technology Message-ID: <3292D3D0.2781E494@ee.ust.hk> when download to MVME166, MC68040CPU, it hints: - -> ld < try.o undefined symbol: _gettimeofday ld error: error reading file (errno = 0x1c0001). value = 0 = 0x0 anyone know the reson? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Delta-Tau PMAC Driver Date: Wed, 20 Nov 1996 18:01:04 +0800 From: "Dr. Zexiang Li's Robotic Project" Organization: Hong Kong University of Science and Technology Message-ID: <3292D6E0.794BDF32@ee.ust.hk> References: <562m1h$1lf@maxwell14.ee> I have some example files for VME bus Delta-Tau PMAC board, have some problems when I compile on VxWork. I do not know if it is what you need. eezhcai@ee.ust.hk Adam T. Atherton wrote: > > I am working on a student project using the PMAC board, and if > possible I would like a copy of the driver too. > > Thanks, > Adam Atherton > atathert@mtu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: need your HELP!!! Date: Wed, 20 Nov 1996 17:19:32 +0800 From: "Dr. Zexiang Li's Robotic Project" Organization: Hong Kong University of Science and Technology Message-ID: <3292CD24.41C67EA6@ee.ust.hk> Hi, everyone: I am using a Bisight system of Helpmate comp, includes a VME PMAC servo board in MVME166 single board computer. I have gotten some example files from Helpmate comp. and it is in standard C mode. Now I want to compile them to MC68040 mode, and I found some error massages include " undefined symbol: _gettimeofday ". following is the process of compile: step 1: cc68k -nostdinc -I/robot/vx/h -I/staff/ee/eerobot/czh/czh - -DCPU=MC68040 -O -c example.c pmacio.c utilities.c ptv.c Step 2: ld68k -o try.o -r example.o pmacio.o ptv.o utilities.o Step 3: ld < try.o result: - -> ld < try.o undefined symbol: _gettimeofday ld error: error reading file (errno = 0x1c0001). value = 0 = 0x0 And when I did not use the -c option, the sys hinted lots of error messages. I am not sure if I must mention a standard C library for cc68k? My VxWork version is 5.1 Waiting for your help. Cai, Zhihong eezhcai@ee.ust.hk --------------------------- End of New-News digest ********************** From alon@radcom.co.il Wed Nov 20 06:45:32 1996 From: "Alon Ecker" Date: Wed Nov 20 06:45:35 PST 1996 Subject: Compilation problem in C++ SYNOPSIS OF PROBLEM : Compilation problem AFFECTED MODULE : PRODUCT NAME : Tornado 1.0 DATE : Nov 20, '96 - 15:30 REPORTED BY : Alon Ecker CONTACT : Alon Ecker COMPANY : RADcom LICENSE NUMBER : 3616 EMAIL : alon@radcom.co.il ADDRESS : 12 Hanechoshet st. 69710, Tel-Aviv Israel. : NA PHONE : 972-3-6455183 CUSTOMER REFERENCE# : SYSTEM CONFIGURATION : HOST : Win NT 3.5 ARCH : I960CA BSP : EP960CX OTHER PERIPHERALS : DESCRIPTION OF PROBLEM : I have tried to compile files test.h test.cpp. The comilation problem appears when I use the '-g' option for the compiler. It shouts that it can't assemble the temporary assembler file. This is the problematic syntaxl: ((this)->*callme)(); I get the following message: cc960 -mca -mstrict-align -O -fvolatile -fno-builtin -Wall -I/h -I. -Id:\Tornado\targe t\config\all -Id:\Tornado\target/h -Id:\Tornado\target/src/config -Id:\Tornado\target/src/ drv -ansi -nostdinc -DCPU=I960CA -DVX_IGNORE_GNU_LIBS -g -c i:\inter.rtc\test.cpp C:\TMP\cca00131.s: Assembler messages: C:\TMP\cca00131.s:9: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:13: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of line ignored. First ignored character is `:'. cc960: Internal compiler error: program as got fatal signal 1 make.exe: *** [test.o] Error 0x1 /* test.h * class Object { typedef void (Object::*Callback0)(void); public: Object(void); virtual ~Object(){}; void funcc0(void); }; /* test.cpp */ Object::Object() { Callback0 callme = &(Object::funcc0); ((this)->*callme)(); } void Object::funcc0(void) { } Without the -g option it has passed compilation. Does anyone use this C++ Syntax ? Do you have any short and nice way around for general callbacks ? Thanks! . Alon Ecker. Software Engineer. Radcom Ltd. 12, Hanechoshet st. Tel-Aviv 69710 Israel Tel: +972-3-6455183 Fax: +972-3-6474681 E-Mail: alon@radcom.co.il Home Page: www.radcom-inc.com From POSTMASTER@CompuServe.COM Wed Nov 20 07:17:44 1996 From: Electronic Postmaster Date: Wed Nov 20 07:18:02 PST 1996 Subject: Undeliverable message Your message could not be delivered for the following reason: Mailbox 75120.1767 is currently full. Please resend your message at a later time. --- Returned message --- Sender: root@csg.lbl.gov Received: from csg.lbl.gov (csg.lbl.gov [128.3.252.184]) by arl-img-1.compuserve.com (8.6.10/5.950515) id KAA19606; Wed, 20 Nov 1996 10:09:03 -0500 Received: by csg.lbl.gov (4.1/0.0) id AA06848; Wed, 20 Nov 96 06:45:37 PST Date: Wed, 20 Nov 96 06:45:37 PST Message-Id: <9611201445.AA06848@csg.lbl.gov> Errors-To: vxwexplo-errs@lbl.gov To: vxworks_users@csg.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Compilation problem in C++ Submitted-by alon@radcom.co.il Wed Nov 20 06:45:32 1996 Submitted-by: "Alon Ecker" SYNOPSIS OF PROBLEM : Compilation problem AFFECTED MODULE : PRODUCT NAME : Tornado 1.0 DATE : Nov 20, '96 - 15:30 REPORTED BY : Alon Ecker CONTACT : Alon Ecker COMPANY : RADcom LICENSE NUMBER : 3616 EMAIL : alon@radcom.co.il ADDRESS : 12 Hanechoshet st. 69710, Tel-Aviv Israel. : NA PHONE : 972-3-6455183 CUSTOMER REFERENCE# : SYSTEM CONFIGURATION : HOST : Win NT 3.5 ARCH : I960CA BSP : EP960CX OTHER PERIPHERALS : DESCRIPTION OF PROBLEM : I have tried to compile files test.h test.cpp. The comilation problem appears when I use the '-g' option for the compiler. It shouts that it can't assemble the temporary assembler file. This is the problematic syntaxl: ((this)->*callme)(); I get the following message: cc960 -mca -mstrict-align -O -fvolatile -fno-builtin -Wall -I/h -I. -Id:\Tornado\targe t\config\all -Id:\Tornado\target/h -Id:\Tornado\target/src/config -Id:\Tornado\target/src/ drv -ansi -nostdinc -DCPU=I960CA -DVX_IGNORE_GNU_LIBS -g -c i:\inter.rtc\test.cpp C:\TMP\cca00131.s: Assembler messages: C:\TMP\cca00131.s:9: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:13: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of line ignored. First ignored character is `:'. C:\TMP\cca00131.s:38: Error: Rest of line ignored. First ignored character is `:'. cc960: Internal compiler error: program as got fatal signal 1 make.exe: *** [test.o] Error 0x1 /* test.h * class Object { typedef void (Object::*Callback0)(void); public: Object(void); virtual ~Object(){}; void funcc0(void); }; /* test.cpp */ Object::Object() { Callback0 callme = &(Object::funcc0); ((this)->*callme)(); } void Object::funcc0(void) { } Without the -g option it has passed compilation. Does anyone use this C++ Syntax ? Do you have any short and nice way around for general callbacks ? Thanks! From anthonyl@atlantis.softeng.lamrc.com Wed Nov 20 08:56:53 1996 From: Anthony Le Date: Wed Nov 20 08:56:55 PST 1996 Subject: Re: Cold Boot / Warm Boot Begin forwarded message: Date: Tue, 19 Nov 96 09:12:44 PST To: vxworks_users@csg.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Re: Cold Boot / Warm Boot Submitted-by espin@idiom.com Tue Nov 19 09:12:36 1996 Submitted-by: Geoffrey Espin > Submitted-by: Salil Parikh > Is there a way in VxWorks to distinguish between a warm boot and a cold boot? > I'm using the Motorola MVME147 SBC. To distinguish between cold boot and warm boot, you need a thermometer. If you boot at 5 degrees or below that is cold boot. If you boot at 80 degrees or above that is warm boot. VxWorks ignores hot boot because it can not handle that temparature. Make sure you record the temparature of your SBC. Hope this answer helps!!!! . From del@rst.com Wed Nov 20 09:20:33 1996 From: del@rst.com (Mark Del Giorno) Date: Wed Nov 20 09:20:35 PST 1996 Subject: SLIP as backup network: problem Heyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy, If anyone has used SLIP in a "fault-tolerant" mode, perhaps you can help me. I am controlling a robotic vehicle using a wireless ethernet link as follows: (A) (B) Wireless Wireless (C) _____________________ Ethernet Ethernet ___ | | | ___|____ ___|____ ___|____ |Control | |"Router"| Wireless SLIP I/F | | |Station | | . |- - - - - - - - - - - -| Robot | |________| |________|(D) (E)|________| The letters A..E represent unique internet addresses. (A, B, and C have a different network prefix than D & E). The SLIP link is to be used as a backup in case we go out of range of the wireless ethernet (which happens often). I'd like to keep both links up at the same time - not switch between them. Right now I do a routeAdd(E, B) on the Control Station. This allows the Control Station to open a stream with the Robot, and the data is (correctly) routed through the Router to the Robot via the RS232 link. Unfortunately the return path that the Robot uses for that same stream is to attempt to use the Wireless Ethernet, rather than go back across the SLIP link. In other words: a write() at the Control station to the file descriptor associated with the Robot's E address takes the following path: A-B-D-E-C-A where the -C-A is the TCP layer's acknowledgement that the packet was correctly received. How can I convince the Robot's TCP task to respond to SLIP requests back along the SLIP, regardless of the source of the message? All processors are MVME162's, with vxWorks 5.2. Thanks in advance for any advice. Mark _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) _/ _/ _/ _/ Robotic Systems Technology _/_/_/_/ _/_/_/_/ _/ 1110 Business Parkway South _/ _/ _/ _/ Westminster, MD 21157 _/ _/ _/_/_/_/ _/ (410) 876-9200 Fax: 876-9470 http://www.rst.com From POSTMASTER@CompuServe.COM Wed Nov 20 09:44:33 1996 From: Electronic Postmaster Date: Wed Nov 20 09:44:35 PST 1996 Subject: Undeliverable message Your message could not be delivered for the following reason: Mailbox 75120.1767 is currently full. Please resend your message at a later time. --- Returned message --- Sender: root@csg.lbl.gov Received: from csg.lbl.gov (csg.lbl.gov [128.3.252.184]) by arl-img-1.compuserve.com (8.6.10/5.950515) id MAA06855; Wed, 20 Nov 1996 12:21:12 -0500 Received: by csg.lbl.gov (4.1/0.0) id AA08168; Wed, 20 Nov 96 08:56:56 PST Date: Wed, 20 Nov 96 08:56:56 PST Message-Id: <9611201656.AA08168@csg.lbl.gov> Errors-To: vxwexplo-errs@lbl.gov To: vxworks_users@csg.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Re: Cold Boot / Warm Boot Submitted-by anthonyl@atlantis.softeng.lamrc.com Wed Nov 20 08:56:53 1996 Submitted-by: Anthony Le Begin forwarded message: Date: Tue, 19 Nov 96 09:12:44 PST To: vxworks_users@csg.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Re: Cold Boot / Warm Boot Submitted-by espin@idiom.com Tue Nov 19 09:12:36 1996 Submitted-by: Geoffrey Espin > Submitted-by: Salil Parikh > Is there a way in VxWorks to distinguish between a warm boot and a cold boot? > I'm using the Motorola MVME147 SBC. To distinguish between cold boot and warm boot, you need a thermometer. If you boot at 5 degrees or below that is cold boot. If you boot at 80 degrees or above that is warm boot. VxWorks ignores hot boot because it can not handle that temparature. Make sure you record the temparature of your SBC. Hope this answer helps!!!! From mam@pluto.dspt.com Wed Nov 20 11:42:01 1996 From: "Mark Menge" Date: Wed Nov 20 11:42:07 PST 1996 Subject: vxWorks and RPC Does anyone know if it is possible to use Visual C's RPC and vxWorks? We are using Netmanage's RPC SDK which requires special installation. I would appreciate mail on anyone's experiences. Mark A. Menge DSP Technology Inc. 795 Higland Dr. Ann Arbor Mi, 48108 Phone: (313) 973-1111 Fax: (313) 973-1103 Email: mmenge@dspt.com From mam@pluto.dspt.com Wed Nov 20 11:43:55 1996 From: "Mark Menge" Date: Wed Nov 20 11:43:57 PST 1996 Subject: SCSI Drive Diagnostics I looking for code that aides in disk diagnostics for scsi drives on vxWorks. Anybody know where I can get some? Mark A. Menge DSP Technology Inc. 795 Higland Dr. Ann Arbor Mi, 48108 Phone: (313) 973-1111 Fax: (313) 973-1103 Email: mmenge@dspt.com From darryl@isys.com Wed Nov 20 12:46:27 1996 From: darryl@isys.com (Darryl Troxel) Date: Wed Nov 20 12:46:29 PST 1996 Subject: Enet locked on bus error? We are running two MVME-167's (25MHz 68040) under VxWorks 5.1.1 in a 21-slot VME cage with mostly proprietary boards. On rare occasions, when one of our tasks attempts to sendmsg on a socket using data from another VME card, we get a bus error on a perfectly good (responds if retried) location. That's bad enough, but when this happens *none* of the tasks on that CPU can do anything on the ethernet. The CPU won't even answer ICMP_PINGs. If I resume the bus-erroring task the network starts working again. We're working on the bus error problem itself with our HW people, but the network side effects keep the application from recovering very well. Q1. Is there some semaphore or something that is being held by the bus-error-ing task, until it is resumed and comes back out of the socket-send (buffer pool, net-chip command area, ...)? Q2. Anyone have a sample buserr handler that can simply retry the access? (If the fault address is in the range we expect, just rerunning the failed fetch will probably succeed.) Here are some sample stacktraces: -> tt "gWriter00" 418b8 _vxTaskEntry +10 : _grayWriter (2b62f94, eac621, e60c52, 0, 0, 0, eac72e, 0, 0, 2b677b0) e6038a _grayWriter +2a2: _processGray (2b62f94, e9adbe) e60966 _processGray +6a : _writeGray (2b62f94, e9adbe) e62ed6 _writeGray +37c: _multiWriteDW (29, 12, 2b26010, 1d, 8edcc, 0) dcbb66 _multiWriteDW +98 : _callDataWriter (29, e9acb0, e9ac88, e9aca0) dcb836 _callDataWriter+1e : _sendmsg (29, e9ac88, 0) 2a38c _sendmsg +da : _sosend (e98d10, 0, e9ac18, 0, 0) 53404 _sosend +308: _uiomove (f80834, 400, 1, e9ac18) 540ec _uiomove +56 : _bcopy (b9c46700, f80b7c, b8) -> tt gWriter00 418b8 _vxTaskEntry +10 : _grayWriter (2b62fa8, eac5ed, e60c66, 0, 0, 0, eac6fa, 0, 0, 2b677c4) e6039e _grayWriter +2a2: _processGray (2b62fa8, e9ad8a) e6097a _processGray +6a : _writeGray (2b62fa8, e9ad8a) e62eea _writeGray +37c: _multiWriteDW (2c, 12, 2b22db4, 37, d2300, 0) dcbb7a _multiWriteDW +98 : _callDataWriter (2c, e9ac7c, e9ac54, e9ac6c) dcb84a _callDataWriter+1e : _sendmsg (2c, e9ac54, 0) 2a38c _sendmsg +da : _sosend (ea4424, 0, e9abe4, 0, 0) 53404 _sosend +308: _uiomove (210f44, 400, 1, e9abe4) 540ec _uiomove +56 : _bcopy (b8429800, 211088, 100) Thanks in advance for any help, Darryl __________________________________________________________________ Darryl Troxel Isys Controls, Inc. darryl@isys.com 2060 Challenger Drive Tel: 510.865.9882, x138 Alameda, CA 94501 USA Fax: 510.865.9927 __________________________________________________________________ From tkb@mclean.sparta.com Wed Nov 20 15:11:21 1996 From: "Thomas K. Buchanan" Date: Wed Nov 20 15:11:27 PST 1996 Subject: Re: Enet locked on bus error? >We are running two MVME-167's (25MHz 68040) under VxWorks 5.1.1 in a >21-slot VME cage with mostly proprietary boards. On rare occasions, >when one of our tasks attempts to sendmsg on a socket using data from >another VME card, we get a bus error on a perfectly good (responds if >retried) location. That's bad enough, but when this happens *none* of >the tasks on that CPU can do anything on the ethernet. The CPU won't >even answer ICMP_PINGs. If I resume the bus-erroring task the network >starts working again. It sounds like you're VME setup works under most conditions but has a failure mode under high traffic conditions. Check what bus release modes you are using on the 167 cards and any other bus masters that you have. A bus master in RWD mode (release when done) will not release the bus unless it is done using it. Sometimes 'done' means a single transfer, a block cycle, when a register is accessed ( RORA - release on register access) or after some minimum number of bus transfers ( sometimes called fair RWD). A bus master in ROR (release on request) will release the bus whenever another master requests it. A bus master in fair mode will attempt to give equal access to all bus masters on the same arbitration level. If there are a lot of bus masters besides the 167s, take a look at using round robin arbitration rather than the normal priority based scheme. If you have any block transfers happening, consider making the block size small enough that no bus error timers can go off or sycnhronize the block transfers with the SM network access. Good luck... HTH ----------------------------------------- /\\ Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 7926 Jones Branch Drive / \\\\\ \\ Suite 900 \ \\\\\ // McLean, VA 22102 \ ////// \////// Voice: 703 448 0210 \//// FAX: 703 893 5494 \// WWW: www.mclean.sparta.com From 100656.1507@CompuServe.COM Thu Nov 21 02:04:29 1996 From: John Shaw <100656.1507@CompuServe.COM> Date: Thu Nov 21 02:04:47 PST 1996 Subject: Re: gettimeofday Re: >>when download to MVME166, MC68040CPU, it hints: >>- -> ld < try.o >>undefined symbol: _gettimeofday >>ld error: error reading file (errno = 0x1c0001). >>value = 0 = 0x0 Hello, The function gettimeofday() is not supported in VxWorks 5.1 at all. However you might try the POSIX clockLib functions below:- #include int clock_gettime (CLOCK_REALTIME, struct timespec * pt); int clock_settime (CLOCK_REALTIME, struct timespec * pf); You will have to generate a new VxWorks image for your MVME-166 with the INCLUDE_POSIX_TIMERS or INCLUDE_POSIX_ALL definition added to to vw/config/mv166/config.h or to the included options section of the file vw/config/all/configAll.h (thus applied to all VxWorks images). I have not tried these functions. I have instead written routines to program the MK48T08 BBRAM, TOD clock directly. This is the real-time clock that stores BCD seconds, minutes, hours, and Julian date information. Have a look at the Motorola hardware manual on details of this chip. Please email me so that I know you have received this mail. I may also be able to email you the source for the routines to set and get time for the TOD clock. John Shaw, Shade (Computer Services) Limited, Calne, Wiltshire, England, UK. 100656.1507@compuserve.com From del@rst.com Thu Nov 21 06:59:38 1996 From: del@rst.com (Mark Del Giorno) Date: Thu Nov 21 06:59:56 PST 1996 Subject: SLIP as backup network: problem (apologies for the repost: my exploder email was truncated, and this message wasn't in it......not sure if it posted to everyone else or not.) Heyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy, If anyone has used SLIP in a "fault-tolerant" mode, perhaps you can help me. I am controlling a robotic vehicle using a wireless ethernet link as follows: (A) (B) Wireless Wireless (C) _____________________ Ethernet Ethernet ___ | | | ___|____ ___|____ ___|____ |Control | |"Router"| Wireless SLIP I/F | | |Station | | . |- - - - - - - - - - - -| Robot | |________| |________|(D) (E)|________| The letters A..E represent unique internet addresses. (A, B, and C have a different network prefix than D & E). The SLIP link is to be used as a backup in case we go out of range of the wireless ethernet (which happens often). I'd like to keep both links up at the same time - not switch between them. Right now I do a routeAdd(E, B) on the Control Station. This allows the Control Station to open a stream with the Robot, and the data is (correctly) routed through the Router to the Robot via the RS232 link. Unfortunately the return path that the Robot uses for that same stream is to attempt to use the Wireless Ethernet, rather than go back across the SLIP link. In other words: a write() at the Control station to the file descriptor associated with the Robot's E address takes the following path: A-B-D-E-C-A where the -C-A is the TCP layer's acknowledgement that the packet was correctly received. How can I convince the Robot's TCP task to respond to SLIP requests back along the SLIP, regardless of the source of the message? All processors are MVME162's, with vxWorks 5.2. Thanks in advance for any advice. Mark _/_/_/_/ _/_/_/_/ _/_/_/_/_/ Mark Del Giorno (del@rst.com) _/ _/ _/ _/ Robotic Systems Technology _/_/_/_/ _/_/_/_/ _/ 1110 Business Parkway South _/ _/ _/ _/ Westminster, MD 21157 _/ _/ _/_/_/_/ _/ (410) 876-9200 Fax: 876-9470 http://www.rst.com From Susan_J_Henry@ccmail.orl.mmc.com Thu Nov 21 07:59:22 1996 From: Susan_J_Henry@ccmail.orl.mmc.com Date: Thu Nov 21 07:59:24 PST 1996 Subject: Ada Tasking/Rendezvous vs. VxWorks Tasking Hello, We are developing a real-time embedded application in Ada (and C as well). Our target is the PowerPC (MVME 1603) and are using Green Hill's Multi Cross Compiler and VxWorks 5.3. We are in the detailed design phase of the project and looking to use the VxWorks tasking model (tasks, message queues, and semaphores) versus using the Ada language Task Structure and the Rendezvous. We have been told (by WRS) that VxWorks tasking is more efficient and less overhead then Ada's. Has anyone out there performed a trade study or have hard throughput numbers to back this up? Our customer is familiar with Ada tasking and not VxWorks and wants justification why we think VxWorks tasks are the way to go. I'm posing the question and hoping to receive an answer, otherwise we are going to have to do this study. Thanks in advance, Sue Henry Lockheed Martin susan_j_henry@ccmail.orl.lmco.com From intrepid!minidds@uunet.uu.net Thu Nov 21 08:58:07 1996 From: intrepid!minidds@uunet.uu.net (Lee Kappel) Date: Thu Nov 21 08:58:09 PST 1996 Subject: Re: tnetTask, Serial I/O, and Ring Buffers I am using the built-in serial TTY driver supplied by WRS with 5.3 for the Motorola MVME1604 board PC87303 Super I/O chip which supports COM1 and COM2 only. I have heard from another team on my project that they are having trouble directly accessing COM1 and COM2 since VxWorks seems to have hooks into these two ports no matter what they do. > From tadlock@bosch.dseg.ti.com Thu Nov 21 08:13:11 1996 > Date: Wed, 20 Nov 1996 17:05:05 -0600 > From: tadlock@bosch.dseg.ti.com (edward tadlock) > To: intrepid!minidds@uunet.uu.net (Lee Kappel), vwwexplo@lbl.gov > Subject: tnetTask, Serial I/O, and Ring Buffers > Reply-To: ed-tadlock@ti.com > Content-Length: 1046 > > we have also had problems writing to the serial ports (COM1) via the > memory mapped addresses. It works for a while and then hangs, but I > have not gotten deep enough to know why. Perhaps we need to be using > some drivers for the ports, but as far as I can see there are not any > built-in drivers for the serial ports of an Ultra603e PowerPC board > from Motorola so we are just writing to know memory addresses. Did you > find serial I/O drivers in 5.3, or did you build them yourself? Note > that we are NOT going out to a TTY, but a device. Routines exist to > drive TTYs via the COM ports,so I guess they have some code somewhere > to talk at the device level to shove the bits out the ports on the > Super I/O chip, but its not accessable to the user. Any input on > your solutions might help me find one. > > Ed Tadlock > TI Systems Group > Adv. Airborne Systems > Open Systems Technology Group > Plano, TX > From stan@rti.com Thu Nov 21 10:16:12 1996 From: Stan Schneider Date: Thu Nov 21 10:16:13 PST 1996 Subject: Re: SLIP as backup network: problem >> From root@csg.lbl.gov Thu Nov 21 07:58 PST 1996 >> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) >> Subject: SLIP as backup network: problem >> Submitted-by del@rst.com Thu Nov 21 06:59:38 1996 >> Submitted-by: del@rst.com (Mark Del Giorno) >> >> (A) (B) Wireless Wireless (C) >> _____________________ Ethernet Ethernet ___ >> | | | >> ___|____ ___|____ ___|____ >> |Control | |"Router"| Wireless SLIP I/F | | >> |Station | | . |- - - - - - - - - - - -| Robot | >> |________| |________|(D) (E)|________| >> >> >> How can I convince the Robot's TCP task to respond to SLIP requests >> back along the SLIP, regardless of the source of the message? >> You should be able to run routeAdd("0", D) on the Robot, setting D up as the default gateway. You can also specify the routes you want individually, e.g. by running routeAdd(A,D) and routeAdd(B,D) on the Robot. HTH, -- Stan stan@rti.com From dgilleland@sntc.com Thu Nov 21 10:22:17 1996 From: dgilleland@sntc.com (Dan Gilleland) Date: Thu Nov 21 10:22:19 PST 1996 Subject: PPP between VxWorks and Windows NT I'm trying to set up a PPP connection across a serial line with a null modem between my workstation running Windows NT 4.0 and a 5.3 VxWorks I960 target. Has anyone done this and can tell me what PPP parameters were used on the VxWorks side and what was done on the Windows side to establish the link? Thanks for any help, -dan --- Dan Gilleland SNT, Inc Email : dan@sntc.com Phone: (612) 404-0070 Ext 211 FAX : (612) 404-0075 From MikeMcQuade@connect.com Thu Nov 21 17:06:50 1996 From: Mike McQuade Date: Thu Nov 21 17:07:07 PST 1996 Subject: Q: printing from Crosswind ? Does anyone know if its possible to print fromm crooswind ? or print mixed assembly / C listings from GDB ? Id like to dump some mixed mode listings. thanks. MikeMcQuade@connect.com From daemon@csg.lbl.gov Fri Nov 22 04:00:56 1996 From: daemon@csg.lbl.gov Date: Fri Nov 22 04:03:38 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Nov 22 04:00:32 PST 1996 Subject: Re: GNU Compiler 2.6 Subject: Re: RTOS abstraction layer Subject: Re: Anyone using ZBufs? Subject: Date/Time from Bios on x86 platform-Software interrupts Subject: Re: PPP between VxWorks and Windows NT ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: GNU Compiler 2.6 Date: 21 Nov 1996 16:16:48 GMT From: varlese@tech.ascom.ch (Chris Varlese) Organization: Ascom Hasler AG, Berne, Switzerland Message-ID: <571v9g$edk@ascomax.hasler.ascom.ch> References: <9611191636.AA01377@venus.prc.allied.com> In article <9611191636.AA01377@venus.prc.allied.com>, sridhar@prc.allied.com (Sridhar Adumusilli) writes: >Does any one know if 2.6 version can be used to compile >templates? Yes, with a few restrictions. The v2.6 compiler cannot automatically detect when identical template specialisations have been compiled from different source files. This gives "foo multiply defined" errors when linking. To work around this try the following. Compile with the - -fno-implicit-templates parameter. Then make one additional source file, compiled without this parameter, which declares one instance of each template specialisation you use. regards, Chris Varlese --------------------------- Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: 21 Nov 1996 03:48:19 GMT From: steved@pacifier.com@199.2.117.163 (Steve Doiel) Organization: Pacifier BBS, Vancouver, Wa. ((360) 693-0325) Message-ID: <570je3$95u@news.pacifier.com> References: <329355D5.237C228A@aud.alcatel.com> Reply-To: steved@pacifier.com (Steve Doiel) Shash Chatterjee writes: >Is there a vendor-independent abstraction layer for typical RTOS >functions like messaging, tasking, events/semaphores, timer-services, >etc? > Funny you should ask. I went to a presentation this morning put on by Rogue Wave software, and they described one of their class libraries Threads.h++, which I believe at least partially fits your description. I don't know about availability for various target OS's. Their web site is: www.roguewave.com Personally, I think Ada95 is a much better solution since tasking is a part of the language. Hope this helps, Steve Doiel --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Anyone using ZBufs? Date: Wed, 20 Nov 1996 09:10:00 GMT From: pete@imc4.eej.ulst.ac.uk (Pete Brett) Message-ID: <848481056.2587.0@hathsys.demon.co.uk> References: <5543lo$jg7@clark.zippo.com> jay@fallcreek.com (Jay Slupesky) wrote: >Hello, >Has anyone tried using ZBufs to improve the performance of >socket-based programs? I have a simple routine that reads data from >one socket and writes it to another. When I use ZBufs, the program >actually runs much SLOWER than when I use read() and write(). >Using ZBufs should make the program faster, not slower, since it >eliminates two data copies. >Anyone have any thougnts? >Jay Slupesky Fall Creek Systems, Inc. >Pleasanton, California, USA >jay@fallcreek.com http://users.aol.com/jslupesky >"Professional Internet user on closed circuit. Do not attempt." I tried the same thing with the same result. I came to the conclusion that the stack cannot release the application layer buffer until an acknowledgement is received for all packets sent from it. Since TCP generally improves its efficiency greatly by sending several packets before receiving any acknowledgements and thus using a greater percentage of the available bandwidth, it is probably necessary for the application layer to make several buffers available, each with its own callback function parameter. In my own case, I solved the problem by switching to UDP with acknowledgements supplied by the application layer. --------------------------- Newsgroups: comp.os.vxworks Subject: Date/Time from Bios on x86 platform-Software interrupts Date: Thu, 21 Nov 1996 14:05:16 -0800 From: eric olsen Organization: stanford university Message-ID: <3294D21C.6355D5EB@leland.stanford.edu> Hello, we are trying to get date/time from the bios. Anyone know how to do that? Anyone know how to generate software interrupts?? Any help appreciated. thanks, - -------------------------------------------------------------- "How can I lose to such an idiot?" Aaron Nimzovich(1886-1935) eric olsen eolsen@leland.stanford.edu - -------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: PPP between VxWorks and Windows NT Date: Fri, 22 Nov 1996 09:43:29 GMT From: jasonv@delphi-assoc.com (Jason Velody) Organization: delphi-assoc.com Message-ID: <329572b3.3123125@news1.theplanet.co.uk> References: <1996Nov21.122100.1487.27186@eagle.sntc.com> dgilleland@sntc.com (Dan Gilleland) wrote: > > >I'm trying to set up a PPP connection across a serial line >with a null modem between my workstation running Windows >NT 4.0 and a 5.3 VxWorks I960 target. > >Has anyone done this and can tell me what PPP parameters >were used on the VxWorks side and what was done on the >Windows side to establish the link? > Hi Dan, We have experienced problems attempting to establish a PPP connection between a VxWorks system equipped with our embedded ISDN T/A and an NT server running RAS(PPP). We have found a bug in WindRiver's PPP implementation. During LCP negotiation, NT sends a ConfigReq asking for CHAP 80 authorisation. VxWorks doesn't understand CHAP 80 and sends a ConfigRej packet in response. This is a clear violation of the protocol as it indicates that VxWorks doesn't understand any kind of authorisation. NT quite reasonably terminates the session. Instead of sending a ConfigRej, VxWorks should reply with a ConfigNak suggesting an alternate authorisation protocol (UPAP or CHAP); NT will accept this reponse and the session should continue through the authorisation phase. We are working with WindRiver to try and sort this out. Their version of PPP is based on the BSD public domain implementation, later versions of which contain a fix for this problem. If we come up with a fix in the short term I'll let you know. Jason Velody - ------------------------------------------------------------------------------ You are lost in a maze of twisty little standards - all conflicting... Jason Velody jasonv@delphi-assoc.com Senior Network Consultant http://www.delphi-assoc.com Delphi Associates Ltd (+44) 171 357 0303 - ------------------------------------------------------------------------------ --------------------------- End of New-News digest ********************** From kboley@frodo.eng.vmic.com Fri Nov 22 07:50:19 1996 From: Kirk Boley Date: Fri Nov 22 07:53:19 PST 1996 Subject: GNU C++ 2.7.2 I need to get the 2.7.2 version of the GNU C++ compiler to fix some problems I'm having with templates. Does anyone know where the sun4 host/68k target compiler can be found? ================================================================================ Kirk Boley VME Microsystems International Corporation 12090 S. Memorial Pkwy. Huntsville, AL 35803-3308 (205)650-8254 EMAIL: Kirk.Boley@vmic.com From froeber@bbn.com Fri Nov 22 16:38:39 1996 From: Fred Roeber Date: Fri Nov 22 16:38:57 PST 1996 Subject: Re: Q: printing from Crosswind ? On Thu, 21 Nov 1996, Mike McQuade wrote: > Does anyone know if its possible to print fromm crooswind ? > > or print mixed assembly / C listings from GDB ? The following worked for me: Subject: Re: C-Compiler for VxWorks.. Date: 15 Jun 1995 21:38:16 GMT From: crash@phydeaux.cygnus.com (Jason Molenda) Organization: Cygnus Support It turned out what this person really wanted to do was get an assembly-and-C listing; you can do this with % gcc -Wa,-ashld -c -g -o foo.o foo.c | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From froeber@bbn.com Fri Nov 22 16:59:46 1996 From: Fred Roeber Date: Fri Nov 22 16:59:48 PST 1996 Subject: Re: comp.os.vxworks newsdigest Shash Chatterjee writes: > >Is there a vendor-independent abstraction layer for typical RTOS > >functions like messaging, tasking, events/semaphores, timer-services, > >etc? Steve Doiel replied: > Funny you should ask. I went to a presentation this morning put on by > Rogue Wave software, and they described one of their class libraries Threads.h++, > which I believe at least partially fits your description. > > I don't know about availability for various target OS's. > > Personally, I think Ada95 is a much better solution since tasking is a part > of the language. Actually, a couple of years ago the RTOS vendors got together to try to come up with a standard API. The spec that they proposed was referred to as ORKID. The work was under the auspices of the VME standardization committee if I remember right. It seems that after the spec was put together, the work faded into oblivion. Seems there wasn't enough impetus for the vendors to standardize between products. Of course having software tied to an RTOS specific API is a powerful marketing edge. Of course this situation isn't unique to the embedded system market; the efforts to come up with an ANSI standard Windows API definition haven't seemed too successful either. I think for the moment, that if you are concerned about portability across different RTOS's you should follow the "recommended" practice of encapsulating all RTOS functionality in generic iterface subroutines. Most of the RTOS out there have largely similar core capabilities. Steve also mentions that he likes Ada 95 tasking. I am just wondering if anybody really has used it much. Whenever I worked on Ada applications using VADSWorks under the Ada 83 language definition I always used the underlying VxWorks tasking constructs. The problem was that the synchronous nature of Ada rendezvous didn't seem to fit real time program constraints very well and resulted in far more tasks than were really required. I haven't looked real close but I didn't think that the Ada tasking interface to VxWorks had changed much under Ada 95. Fred | Fred J Roeber, BBN Systems & Technologies | | 50 Enterprise Place Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From daemon@csg.lbl.gov Sat Nov 23 04:00:27 1996 From: daemon@csg.lbl.gov Date: Sat Nov 23 04:00:29 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Nov 23 04:00:24 PST 1996 Subject: Re: VxWorks and Hitachi SH-2 ??? Subject: Re: Cold Boot / Warm Boot Subject: Re: RTOS abstraction layer Subject: Re: Recursive Makefiles under NT Subject: Re: RTOS abstraction layer Subject: netperf on vxworks available Subject: Transparent Translation Registors??? Subject: Transparent Translation Registers??? more Subject: Self Test on an x86 Platform? Subject: Re: Recursive Makefiles under NT ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks and Hitachi SH-2 ??? Date: Thu, 21 Nov 1996 12:27:36 +1030 From: Matt Brennan Organization: Vision Systems Limited, Adelaide, Australia Message-ID: <3293B710.550B@vsl.com.au> References: <32831992.4D5E@ratol.fi> Jouni Kivirinta wrote: > > Hi > > Have anyone used VxWorks with Hitachi's SH-2 or SH-1 series > controllers? I'm in particular interested in models SH7042 (SH-2) and > SH7034 (SH-1). We asked the same question of the VxWorks distributor in Australia. The answer we received was that VxWorks 5.1.1 and WindView on Unix hosts (standard GNU compiler) were available for the SH1 and SH2. There is a port of Tornado to the SH3 currently in progress apparently. Expected completion in first quarter 97 whereupon the port of Tornado to SH1 and SH2 will be conducted. > We are going to use PC+winNT host environment. Looks like you might be sunk. I'd appreciate any information/confirmation you might receive directly from WindRiver or other users. Any one out there actually used VxWorks with the SH2 (SH7043 particularly) ? Matt - -- Matt Brennan || Vision Systems Ltd || +61 8 8300 4686 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Cold Boot / Warm Boot Date: Fri, 22 Nov 1996 07:27:04 -0500 From: Richard Price Organization: United Space Alliance Message-ID: <32959C18.41E1@lsoc114x.ksc.nasa.gov> References: <9611201654.AA07646@softeng.lamrc.com> Anthony Le wrote: > > Begin forwarded message: > > Date: Tue, 19 Nov 96 09:12:44 PST > To: vxworks_users@csg.lbl.gov > From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) > Subject: Re: Cold Boot / Warm Boot > > Submitted-by espin@idiom.com Tue Nov 19 09:12:36 1996 > Submitted-by: Geoffrey Espin > > > Submitted-by: Salil Parikh > > Is there a way in VxWorks to distinguish between a warm boot and > a cold boot? > > I'm using the Motorola MVME147 SBC. > > To distinguish between cold boot and warm boot, you need a thermometer. > > If you boot at 5 degrees or below that is cold boot. > If you boot at 80 degrees or above that is warm boot. > VxWorks ignores hot boot because it can not handle that temparature. > > Make sure you record the temparature of your SBC. > > Hope this answer helps!!!! > > .I was once told they don't let jack asses in to college because nobody likes a smart ass. But a Cal Berkley anthing is possible --------------------------- Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: 22 Nov 1996 10:39:20 +0100 From: rob@sysgo.de (Robert Kaiser) Organization: Sysgo Real-Time Solutions GmbH Message-ID: <573sc8$2d5@phoenix.sysbe.sysgo.de> References: <329355D5.237C228A@aud.alcatel.com> Followup-To: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Shash Chatterjee (Shash.Chatterjee@aud.alcatel.com) wrote: : Is there a vendor-independent abstraction layer for typical RTOS : functions like messaging, tasking, events/semaphores, timer-services, : etc? : There is such a thing as a POSIX standard specifying real-time functionality of an OS (sorry, I'm awfully bad at keeping numbers in mind, must be POSIX 1003.. something like that). : We use pSOS now. I have extensively used VxWorks in a prior job. We are : now moving toward an OO design (C++ implementation) and it seems to me : that kernel-independence would be a major portability as well as : maintainability benefit. I'm afraid pSOS doesn't support POSIX functions (I'm not sure about VxWorks), but there are several other RTOSes available that claim POSIX compliance (QNX, LynxOS, OS-9). : Also, it would provide a means of some : (probably limited) forms of emulation on UNIX hosts using light-weight : process threads. I happen to know LynxOS pretty well, so I can tell you for that one that there is no need to emulate anything because LynxOS has both hard real-time capabilities *and* full-featured UNIX functions at the same time. Thus, you can use it as development/debugging platform and as a target system. Best Regards Robert - ---------------------------------------------------------------- Robert Kaiser email: rkaiser@sysgo.de SYSGO RTS GmbH Mommsenstr. 19 phone: (49) 30 3270153-0 D-10629 Berlin / Germany fax: (49) 30 3247839 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Recursive Makefiles under NT Date: Fri, 22 Nov 1996 12:53:39 GMT From: jasonv@delphi-assoc.com (Jason Velody) Organization: delphi-assoc.com Message-ID: <3296761b.3995765@news1.theplanet.co.uk> References: <3291d000.20436640@news1.theplanet.co.uk> <56sl36$3ki@idiom.com> hjb@peacefulstar.oakland.ca.us (H.J. Bae) wrote: >In article <3291d000.20436640@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote: >>Hi there, >> >>Has anyone managed to get recursive makefiles to work properly under >>Tornado for Windows? I am suffering from a singular lack of success. >> > >Works fine for me. > >http://peacefulstar.oakland.ca.us >mailto:hjb@peacefulstar.oakland.ca.us Hello there! Perhaps I should be a little more specific. The problem seems to occur with exported MAKE variables - they don't seem to be getting exported to the sub-make. Any handy hints? Jason - ------------------------------------------------------------------------------ You are lost in a maze of twisty little standards - all conflicting... Jason Velody jasonv@delphi-assoc.com Senior Network Consultant http://www.delphi-assoc.com Delphi Associates Ltd (+44) 171 357 0303 - ------------------------------------------------------------------------------ --------------------------- Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: 20 Nov 1996 20:51:16 -0500 From: danh@qnx.com (Dan Hildebrand) Organization: QNX Software Systems Message-ID: <570cik$ga1@qnx.com> References: <329355D5.237C228A@aud.alcatel.com> In article <329355D5.237C228A@aud.alcatel.com>, Shash Chatterjee wrote: >Is there a vendor-independent abstraction layer for typical RTOS >functions like messaging, tasking, events/semaphores, timer-services, >etc? Why does it have to be an abstrtaction layer? Why not POSIX? Between the base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c for threads, and 1003.1d for a few more realtime extensions, everything you've named is very nicely covered. >We use pSOS now. I have extensively used VxWorks in a prior job. We are >now moving toward an OO design (C++ implementation) and it seems to me >that kernel-independence would be a major portability as well as >maintainability benefit. Also, it would provide a means of some >(probably limited) forms of emulation on UNIX hosts using light-weight >process threads. Most UNIX hosts natively support some degree of POSIX, with some of them being quite complete. The result is that your source might simply compile on the desktop platform for development, and recompile for the target runtime environment. >Before I get slammed, I understand that there will be a realtime impact. There's no reason for there to be a realtime impact - there are a number of realtime OS's with a POSIX API today. >I'd like to know (besides the fact if there are such class-libraries >available) what the impacts to debugging such a system would be? It need be no more difficult than debugging POSIX code on a desktop platform. - -- Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd. http://www.qnx.com/~danh 175 Terence Matthews phone: (613) 591-0931 (voice) Kanata, Ontario, Canada (613) 591-3579 (fax) K2M 1W8 --------------------------- Newsgroups: comp.os.vxworks Subject: netperf on vxworks available Date: 22 Nov 1996 17:41:55 GMT From: wiltzius@coral.llnl.gov (David P Wiltzius,LC,21551,) Organization: Lawrence Livermore Nat'l Lab Message-ID: <574ol3$g8k@lll-winken.llnl.gov> Netperf is a network performance measurement tool available at http://www.cup.hp.com/netperf/NetperfPage.html. I modified netperf version 2.1 so that the server and client run on VxWorks. Well, for my VxWorks target (Cyclone Microsystems i960 SB08 board) anyway. It is at ftp://www.llnl.gov/siof/netperf/ It is not a robust port, but I've run the TCP and UDP stream tests and the TCP and UDP request/response tests. You can first view the README and 2 of my logs running nerserver and netperf on the VxWorks target to help you decide if you want to venture further. The compressed tar file includes everything. I make no guarantees and assume no responsibility. I'm not sure if I'll have time to respond to requests for help wrt to this "port" but I will try. Dave Wiltzius LLNL wiltzius@llnl.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Transparent Translation Registors??? Date: Thu, 21 Nov 1996 16:48:22 -0800 From: ggensler@impulse.net (Gary Gensler) Organization: Creative Computer Resources Message-ID: Does anybody out there know the ins and outs of TTR's. I have a few Q's about the ramifications of using them. I would appreciate a call. Gary Gensler Santa Barbara Remote Sensing 805-562-7468 If no answer please leave a message I will call you back. Thanks Gary --------------------------- Newsgroups: comp.os.vxworks Subject: Transparent Translation Registers??? more Date: Thu, 21 Nov 1996 16:52:38 -0800 From: ggensler@impulse.net (Gary Gensler) Organization: Creative Computer Resources Message-ID: FORGOT -> I'm using a Motorola mvme167 (68040) CPU. Does anybody out there know the ins and outs of TTR's. I have a few Q's about the ramifications of using them. I would appreciate a call. Gary Gensler Santa Barbara Remote Sensing 805-562-7468 If no answer please leave a message I will call you back. Thanks Gary --------------------------- Newsgroups: comp.os.vxworks Subject: Self Test on an x86 Platform? Date: Fri, 22 Nov 1996 20:25:05 -0500 From: Jack Birecree Organization: Rochester Public Access, Inc. Message-ID: <32965271.35D9@rpa.net> Does anyone know how to get the results of the BIOS self test after boot-up? Is there anyway to read the results? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Recursive Makefiles under NT Date: Sun, 17 Nov 96 22:05:29 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <5761l1$j1s@idiom.com> References: <3291d000.20436640@news1.theplanet.co.uk> <56sl36$3ki@idiom.com> <3296761b.3995765@news1.theplanet.co.uk> In article <3296761b.3995765@news1.theplanet.co.uk>, jasonv@delphi-assoc.com (Jason Velody) wrote: >Perhaps I should be a little more specific. The problem seems to occur >with exported MAKE variables - they don't seem to be getting exported >to the sub-make. Any handy hints? I've noticed this problem too. I work-around this by passing a command line variable args to sub-make calls. For example, within a Makefile, if I want to call a sub-make and want to pass along variables I call it this way: make -C subdir XXX="xxxyyyzzz". The Makefile in subdir can then use XXX as defined by this command line. It's ugly, but it works. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- End of New-News digest ********************** From leonid@rst.co.il Sun Nov 24 00:22:14 1996 From: leonid@rst.co.il (Leonid Rosenboim) Date: Sun Nov 24 00:22:16 PST 1996 Subject: Re: SLIP as backup network: problem We have struggled with similar problems in the past, and there are two ways to solve this problem: 1. Port routed RIP routing table manager to VxWorks (I beleive there is such a port on the archives). 2. Write the application more specifically to this task. 1. - RIP What RIP does is manage the routing table automatically, adding and deleting routing entries as they become (un)availbale. This is done be means of exchanging routing table info between peer RIP daemons. This poll is usually done once every two minutaes. THis could cause an unpleasant delay in reconfiguring the routing table, during Ethernet down time. The RIP is still applicable however in much more complex situation. 2. Modify application: The easies way to write your application specifically for this scenario, is duplicate your connection to the robot, i.e. open two distinct TCP connections, one to IP address (C), and the other to address (E). The second connection will come in via SLIP, and TCP will try to respond via the same path. This is sure to work if the SLIP was connected DIRECTLY to your Control Station. It may not work with the router, not sure if TCP uses source route. This way you got two distinct TCP connections, one over Ethernet another over SLIP, and you can send iportant requests on both if you feel like it. Drop me a line if you need more details. ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-559-8144 R S T Software Industries Ltd. Mobile: +972-50-307-142 P.O.Box 11502, AZUR 58017, Israel Fax: +972-3-559-8244 WWW: http://www.rst.co.il E-Mail: leonid@rst.co.il From leonid@rst.co.il Sun Nov 24 01:14:39 1996 From: leonid@rst.co.il (Leonid Rosenboim) Date: Sun Nov 24 01:14:42 PST 1996 Subject: Re: RTOS abstraction layer In adtivle <570cik$ga1@qnx.com> of QNX wrote: > Why not POSIX? Between the > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c > for threads, and 1003.1d for a few more realtime extensions, everything > you've named is very nicely covered Before glorifying POSIX, you should know that VxWorks (since 5.2) has complete support for the POSIX Real-Time extentions. I went through all these APIs a couple of times, trying to decicde if a particular application could use them, and time after time I was dissapointed by some thing(s) that where simply missing. For example, a wind mutex semaphore has the Priority Inheritance option, POSIX semaphore does not. So if anybody tells you that POSIX covers hard R-T needs "very nicely", then I suppose he or she understand very little about what hard R-T is. Besides, when a standards body decides to design a spec for a Horse, they end up with somethig more resembling a Camel. Leonid From daemon@csg.lbl.gov Sun Nov 24 04:00:22 1996 From: daemon@csg.lbl.gov Date: Sun Nov 24 04:00:24 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Nov 24 04:00:20 PST 1996 Subject: SOFTWARE ENGINEERS - Permanent & Contract Positions Subject: NFS support Subject: Asynchronous sockets Subject: SOFTWARE ENGINEERS - Permanent & Consulting Positions Subject: Re: Asynchronous sockets Subject: Re: Asynchronous sockets ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: SOFTWARE ENGINEERS - Permanent & Contract Positions Date: Thu, 21 Nov 1996 09:09:07 -0800 From: Ram Balani Organization: Innovative Information Systems Message-ID: <32948CB3.E0D@snet.net> Innovative Information Systems, Inc. (IIS, Inc.) is a software contracting/recruiting company specializing in real time and pharmaceutical systems consulting/placements. We have numerous open positions for two of our large client companies: 1) Software Engineers / Project Leaders / Designers/ Managers Permanent, full time positions ONLY are available with this leading medical systems manufacturer. Positions require a minimum BSCS or BSEE and 2 years programming experience. Real time or embedded systems experience is a must. Working experience must include most BUT not ALL: C C++ UNIX X-Windows/Motif Windows NT Prior real time programming experience with medical systems is a definite PLUS. This fortune 50 company leads in the manufacture of MRIs, XRAYS, Ultrasound, etc. Candidates selected will be paid an attractive salary and excellent benefits. Relocation expenses may be extended subject to company HR approval. 2) Software Engineers Real time systems software engineers are also required for contract or IIS consulting openings in Connecticut. Candidate must have 2 of the requirement listed below: 2 years C++ programming experience Real time or embedded systems experience Unix or Windows NT GUI - ------------------------------------------------------------------------------------------------------------------------ Interested candidates may contact Ram Balani after faxing or e-mailing (ascii text please)CV or resume by: Phone: 860-444-7039 E-mail: iisinc@ix.netcom.com Fax: 860-537-4549 --------------------------- Newsgroups: comp.os.vxworks Subject: NFS support Date: Sat, 23 Nov 1996 07:54:27 -0500 From: Walt Dixon Organization: GE Corporate Research and Development Message-ID: <3296F403.5412@crd.ge.com> Reply-To: dixon@crd.ge.com I am posting this question for a friend. He is running vxWorks on an Advantek p5-75 pentium processor, and he has added NFS support. He can see his vxWorks file system from a Windows NT box running NetManage NFS, but he is not able to see the same vxWorks file system from another PC running Windows for Workgroups and 16 bit NetManage NFS. On this latter system he can mount the vxWorks based file system, but all the file names appear as toto]]].txt. The same 16 bit NetManage can see files on a unix system with no problems. Does anyone have any suggestions as to what might be going on. TIA Walt Dixon --------------------------- Newsgroups: comp.os.vxworks Subject: Asynchronous sockets Date: 23 Nov 1996 16:25:33 GMT From: "James Lewis" Organization: Oklahoma State University Message-ID: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> I was wondering how to make an ethernet socket asynchronous (non-blocking). On the host Sparc station this is done with an ioctl call. I assume that VxWorks handles it the same way. If so, how is it done? Any hints would be greatly appreciated. Thanks, James Lewis ljames@okstate.edu --------------------------- Newsgroups: comp.os.vxworks Subject: SOFTWARE ENGINEERS - Permanent & Consulting Positions Date: Thu, 21 Nov 1996 09:44:29 -0800 From: Ram Balani Organization: Innovative Information Systems Message-ID: <329494FD.1121@snet.net> Innovative Information Systems, Inc. (IIS, Inc.) is a software contracting/recruiting company specializing in real time and pharmaceutical systems consulting/placements. We have numerous open positions for two of our large client companies: 1) Software Engineers / Project Leaders / Designers/ Managers Permanent, full time positions ONLY are available with this leading medical systems manufacturer. Positions require a minimum BSCS or BSEE and 2 years programming experience. Real time or embedded systems experience is a must. Working experience must include most BUT not ALL: C C++ UNIX X-Windows/Motif Windows NT Prior real time programming experience with medical systems is a definite PLUS. This fortune 50 company leads in the manufacture of MRIs, XRAYS, Ultrasound, etc. Candidates selected will be paid an attractive salary and excellent benefits. Relocation expenses may be extended subject to company HR approval. 2) Software Engineers Real time systems software engineers are also required for contract or IIS consulting openings in Connecticut. Candidate must have 2 of the requirement listed below: 2 years C++ programming experience Real time or embedded systems experience Unix or Windows NT GUI - ------------------------------------------------------------------------------------------------------------------------ Interested candidates may contact Ram Balani after faxing or e-mailing (ascii text please) CV or resume by: Phone: 860-444-7039 E-mail: iisinc@ix.netcom.com Fax: 860-537-4549 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asynchronous sockets Date: Mon, 18 Nov 96 02:36:10 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <577lak$4oh@idiom.com> References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> In article <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu>, "James Lewis" wrote: >I was wondering how to make an ethernet socket asynchronous (non-blocking). > On the host Sparc station this is done with an ioctl call. I assume that >VxWorks handles it >the same way. If so, how is it done? Any hints would be greatly >appreciated. > VxWorks doesn't really support asynch sockets. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asynchronous sockets Date: Sun, 24 Nov 1996 06:16:38 GMT From: brucew@phoenix.net (Bruce) Organization: BranPaul Systems Message-ID: <578pdk$d2v$1@gryphon.phoenix.net> References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> In comp.os.vxworks "James Lewis" wrote: >I was wondering how to make an ethernet socket >asynchronous (non-blocking). On the host Sparc station >this is done with an ioctl call. I assume that VxWorks handles >it the same way. If so, how is it done? It is done the same way. I'm at home so I don't have my manuals, but look in your socklib documentation or search your headers for the constant FIONBLK or something similar. If I remember, it is not in the online manuals. Bruce --------------------------- End of New-News digest ********************** From froeber@bbn.com Sun Nov 24 17:39:33 1996 From: Fred Roeber Date: Sun Nov 24 17:39:35 PST 1996 Subject: Re: non blocking sockets James Lewis wrote: > >I was wondering how to make an ethernet socket asynchronous (non-blocking). > > On the host Sparc station this is done with an ioctl call. I assume that > >VxWorks handles it > >the same way. If so, how is it done? Any hints would be greatly > >appreciated. H.J. Bae responded: > VxWorks doesn't really support asynch sockets. I am surprised by this. The sockLib man page talks about the FIONBIO ioctl option to make a socket non blocking and I have used it before and thought it worked. Still, Hae Jin did a lot of the original work on the VxWorks network code and usually is dead on accurate. So what gives? Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From froeber@bbn.com Sun Nov 24 17:54:30 1996 From: Fred Roeber Date: Sun Nov 24 17:54:32 PST 1996 Subject: Re: RTOS abstraction layer In article <570cik$ga1@qnx.com> of QNX wrote: > > Why not POSIX? Between the > > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c > > for threads, and 1003.1d for a few more realtime extensions, everything > > you've named is very nicely covered To which Leonid Rosenboim responded: > Before glorifying POSIX, you should know that VxWorks (since 5.2) has > complete support for the POSIX Real-Time extentions. I went through > all these APIs a couple of times, trying to decicde if a particular > application could use them, and time after time I was dissapointed > by some thing(s) that where simply missing. > > For example, a wind mutex semaphore has the Priority Inheritance > option, POSIX semaphore does not. > > So if anybody tells you that POSIX covers hard R-T needs "very nicely", > then I suppose he or she understand very little about what hard R-T is. I agree with Leonid. First, while Dan is usually at least somewhat unbiased he does work for QNX which is a competing RTOS vendor. My take is that QNX is more UNIX like and therefor more closely matches the POSIX model of things (but is mainly supported on PC type targets). While I wasn't directly involved in the POSIX real time work I did have numerous enlightening discussions with one of my friends from Raytheon who was quite involved. My take on things is that POSIX does include definitions of how to address many things that we care about in the embedded arena. However, the notion of POSIX compliance certainly doesn't guarantee portability. There are large parts of the POSIX spec that are optional and few areas where performance must be specified. I certainly wouldn't count on the fact that two different OS vendors claimed POSIX compliance to mean I could port a POSIX conforming application between them easily. VxWorks supports some aspects of the POSIX real time interface (they had some of their staff on the POSIX working groups) but the basic VxWorks arhictecture is very different from the full blown POSIX model. VxWorks has tasks that are somewhat like POSIX threads. It doesn't have any notion of the more heavy weight processes that POSIX has. I could go on but I think the basic thing I would advise is to view RTOS vendor claims that portability is ensured because of POSIX compliance with healthy scepticism. Then again, I haven't ever heard WRS people make this portability claim. Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-849-2543 (X48) | From mmigdol@crl.mew.co.jp Sun Nov 24 18:37:08 1996 From: Michael Migdol Date: Sun Nov 24 18:37:09 PST 1996 Subject: RT-Win and other VxWorks-Windows hybrids Hi all, We are currently evaluating VxWorks/Win95 hybrids. Does anyone have experience with RT-Win, LP-VxWin, or any other similar products? Would love to hear any comments - good or bad! Thanks in advance, Michael Migdol Matsushita Electric Works From mea@mclean.sparta.com Mon Nov 25 07:40:53 1996 From: Mike Anderson Date: Mon Nov 25 07:41:11 PST 1996 Subject: Re: non blocking sockets At 05:39 PM 11/24/96 PST, you wrote: >Submitted-by froeber@bbn.com Sun Nov 24 17:39:33 1996 >Submitted-by: Fred Roeber > >James Lewis wrote: >> >I was wondering how to make an ethernet socket asynchronous (non-blocking). >> > On the host Sparc station this is done with an ioctl call. I assume that >> >VxWorks handles it >> >the same way. If so, how is it done? Any hints would be greatly >> >appreciated. > > >H.J. Bae responded: > >> VxWorks doesn't really support asynch sockets. > >I am surprised by this. The sockLib man page talks about the FIONBIO >ioctl option to make a socket non blocking and I have used it before >and thought it worked. Still, Hae Jin did a lot of the original work >on the VxWorks network code and usually is dead on accurate. So what >gives? Fred > HwaJin is technically correct. To support asynchronous sockets, you must support the SIGIO signal, which VxWorks does not. This is very different from non-blocking sockets. You can, in fact, make a socket non-blocking in VxWorks by using the FIONBIO ioctl call. However, for the socket to be truly "asynchronous", your task would have to get the SIGIO signal anytime a packet came in that was destined for the port number of the socket you were monitoring. This has long been a topic at the user's group meetings and I know that I personally have asked about SIGIO support for several years, but to no avail. However, all is not lost. You can hook the etherInputHook and look at the protocol field in the IP header and use that info to look at the destination port field in the TCP/UDP header to determine whether or not you wish to send the SIGIO signal to a given task. This would basically require a table that contained the port number of interest and the TID of the task to be signaled. You would then have to write a setup call to enter that info into the table. We've done it here at SPARTA and it works reasonably well. Unfortunately, your network traffic will suffer a slight performance hit because of this additional code. What really needs to happen is for WRS to add the SIGIO capability into the file system. If done properly, this facility could then be used for *any* function that used file descriptors. This means asynchronous pipes, files, and sockets. HTH, ============================================================================== __ Real-Time System Development, Integration, Training and Services //\\ // \\ Mike Anderson // /\ \\ Chief Engineer Voice : (703) 448-0210 ext. 235 // / \ \\ SPARTA, Inc. FAX : (703) 893-5494 // \ \\ 7926 Jones Branch Drive EMAIL : mea@mclean.sparta.com \\ \ // Suite 900 Web : http://www.mclean.sparta.com \\ \ / // McLean, VA 22102 \\ \/ // "Software development is like making \\ // a baby... You can't make a baby in one \\// month by impregnating nine women. -- "Pride in Performance" Some things just take time." ============================================================================== From navarro@emu.sp.trw.com Mon Nov 25 13:34:36 1996 From: Efren Navarro Date: Mon Nov 25 13:34:55 PST 1996 Subject: unsubscribe unsubscribe From royg@semantic.com Mon Nov 25 14:39:46 1996 From: Roy Gordon Date: Mon Nov 25 14:39:55 PST 1996 Subject: signals in 5.3 As a newcomer to the vxWorks world, the recent discussion of SIGIO has gotten me nervous. Do signals in 5.3 actually meet the Posix interface? Are there any known not to work correctly? Are there other signals that simply aren't supported? I notice that SIGIO is defined in sigLib.h #define SIGIO (SIGRTMIN + 0) Does this mean that although it's listed it's still not supported, and ditto for the other signals in this file. Or, can you get it by means of the real time extensions. Do the real time extensions work? We're porting from Solaris to vxWorks (as well as developing vxWorks specific code), and having some idea of what we can expect would be most helpful. -- roy > HwaJin is technically correct. To support asynchronous sockets, you must > support the SIGIO signal, which VxWorks does not. This is very different > from non-blocking sockets. You can, in fact, make a socket non-blocking in > VxWorks by using the FIONBIO ioctl call. However, for the socket to be > truly "asynchronous", your task would have to get the SIGIO signal anytime > a packet came in that was destined for the port number of the socket you > were monitoring. This has long been a topic at the user's group meetings > and I know that I personally have asked about SIGIO support for several years, > but to no avail. : : > What really needs to happen is for WRS to add the SIGIO capability into the > file system. If done properly, this facility could then be used for *any* > function that used file descriptors. This means asynchronous pipes, files, > and sockets. From bdupre@world-net.worldnet.net Tue Nov 26 00:42:14 1996 From: bdupre@world-net.worldnet.net (Bernard DUPRE) Date: Tue Nov 26 00:42:17 PST 1996 Subject: Re: Friedrich, RAMIX provides a RM235 VME/PCMCIA module with a VxWorks driver. Phone number is 818 349 67 72 (California). Bernard /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ < Real Time Skills Center > < 10, Avenue du Quebec - BP 537 > < 91946 - Courtaboeuf Cedex - France > < Tel: 01 69 82 93 32 Fax: 01 69 82 93 28 > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From daemon@csg.lbl.gov Tue Nov 26 04:00:29 1996 From: daemon@csg.lbl.gov Date: Tue Nov 26 04:02:34 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Nov 26 04:00:27 PST 1996 Subject: Re: GNU C++ 2.7.2 Subject: Re: Asynchronous sockets Subject: re: SLIP as backup network: problem Subject: Re: 53C810 SCSI Controller Subject: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Subject: Re: Asynchronous sockets Subject: Making non-standard serial I/O -driver Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Subject: Strange iteraction between malloc & posix timers Subject: re: non blocking sockets Subject: Re: RTOS abstraction layer Subject: z8530 synchronous driver Subject: Re: RTOS abstraction layer Subject: Re: vxWorks and RPC ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: GNU C++ 2.7.2 Date: 24 Nov 1996 16:25:08 GMT From: bill@qstools.com (Bill Cox) Organization: Sirius Cybernetics, Sirius City branch Message-ID: <579st4$lsr@news.scruz.net> References: <199611221549.JAA13396@frodo.eng.vmic.com> Kirk Boley (Kirk.Boley@vmic.com) wrote: : I need to get the 2.7.2 version of the GNU C++ : compiler to fix some problems I'm having with : templates. : : Does anyone know where the sun4 host/68k target : compiler can be found? : Just did this last night (except for the actual build - I was building for my FreeBSD host machine): cd MYDIR ftp gatekeeper.dec.com cd pub/GNU binary get gcc-2.7.2.1.tar.gz exit gunzip gcc-2.7.2.1.tar.gz tar -xvf gcc-2.7.2.1.tar cd gcc-2.7.2.1 mkdir sun4-x-m68k cd sun4-x-m68k # This assumes that you're building on a sun4 host ../configure --target=m68k-wrs-vxworks make -k all >& make.log make install - -- Bill Cox Software Janitor Finger bill@thuvia.qstools.com for PGP public key. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asynchronous sockets Date: Wed, 20 Nov 96 17:08:52 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57aalu$ocf@idiom.com> References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> <578pdk$d2v$1@gryphon.phoenix.net> In article <578pdk$d2v$1@gryphon.phoenix.net>, brucew@phoenix.net (Bruce) wrote: >In comp.os.vxworks >"James Lewis" wrote: > >>I was wondering how to make an ethernet socket >>asynchronous (non-blocking). On the host Sparc station >>this is done with an ioctl call. I assume that VxWorks handles >>it the same way. If so, how is it done? > >It is done the same way. I'm at home so I don't have my >manuals, but look in your socklib documentation or search >your headers for the constant FIONBLK or something similar. >If I remember, it is not in the online manuals. non blocking sockets are *not* the same as asynch sockets. VxWorks supports non-blocking sockets, it does not support asynch sockets. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: re: SLIP as backup network: problem Date: Wed, 20 Nov 96 17:29:02 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57abro$psp@idiom.com> References: <9611240754.AA00611@rst.co.il> In article <9611240754.AA00611@rst.co.il>, leonid@rst.co.il (Leonid Rosenboim) wrote: >2. Modify application: >The easies way to write your application specifically for this >scenario, is duplicate your connection to the robot, i.e. open >two distinct TCP connections, one to IP address (C), and the other >to address (E). The second connection will come in via SLIP, >and TCP will try to respond via the same path. This is sure to work >if the SLIP was connected DIRECTLY to your Control Station. >It may not work with the router, not sure if TCP uses source route. >This way you got two distinct TCP connections, one over Ethernet another >over SLIP, and you can send iportant requests on both if you feel like it. Having two distinct connections (C and E) has nothing to do with how IP layer routing code will determine which route to take. This is not how IP works. The reason it appears to work in a directly connected point-to-point link in a similar setup is due to an entirely different reason. The only way he can do what he wants is using IP source routing (not TCP source routing, there is no such thing). This should be done from the sender's side, using setsockopt. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: 53C810 SCSI Controller Date: Sun, 24 Nov 1996 21:31:01 -0700 From: Wes Peters Organization: Softweyr LLC Message-ID: <32992105.167EB0E7@xmission.com> References: <01BBD607.78FECBE0@pc0055> Friedrich Ensslin wrote: > Does anyone have any info on VxWorks SCSI drivers for the NCR 53C810 > SCSI Controller. If not, FreeBSD has drivers for this NCR part. It shouldn't be terribly difficult to hack the UNIX sources to work under VxWorks. See http://WWW.FreeBSD.ORG/ for more details. - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com --------------------------- Newsgroups: comp.os.vxworks Subject: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Date: Mon, 25 Nov 1996 10:30:27 -0500 From: Tim Meagher Organization: TSI TelSys Inc. Message-ID: <3299BB93.59E2B600@tsi-telsys.com> Can anyone elaborate on why Wind River is providing Epilogue's SNMP Agent instead of SNMP Research's agent? Please provide a comparison of features for embedded systems (size, multi-threading, ease of use, dynamic extensibility of the agent, support for SNMP v2, availability of source code and binaries, and portability) and a comparison of costs (purchase price, maintenance, and royalties). Are there any other SNMP agent tools that should be seriously considered as an alternative? In addition, what kind of web support for testing and managing these agents is provided (JAVA-based and http-based management)? I also understand that ISI (the makers of PSOS+) purchased Epilogue. Can anyone elaborate what affect this will have on Wind River's ability or plans to offer the Epilogue SNMP agent with VxWorks? Thank you. - -- Tim Meagher TSI Telsys Inc. Senior Software Engineer 7100 Columbia Gateway Dr. tmeagher@tsi-telsys.com Columbia, MD 21046 410-872-3928 (voice) http://www.tsi-telsys.com 410-872-3901 (FAX) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asynchronous sockets Date: Mon, 25 Nov 1996 09:20:49 -0800 From: Chet Kackman Organization: GDE Systems Inc. Message-ID: <3299D571.41C67EA6@GDEsystems.com> References: <01bbd95a$e2dc6800$090b4e8b@James.okstate.edu> James Lewis wrote: > > I was wondering how to make an ethernet socket asynchronous (non-blocking). > On the host Sparc station this is done with an ioctl call. I assume that > VxWorks handles it > the same way. If so, how is it done? Any hints would be greatly > appreciated. > > Thanks, > James Lewis > ljames@okstate.edu James You should use the function call ioctl() with the FIONBIO I/O control function. This should allow you to perform asynch I/O on a socket connection. However I would recommend that you read pages 265 through 267 in the VxWorks 5.2 programmers guide, and supplement it with Stevens' TCP/IP Unix Network Programming book pages 322-323. This should provide enough information to construct the call you need. Good Luck kackman@gdesystem.com --------------------------- Newsgroups: comp.os.vxworks Subject: Making non-standard serial I/O -driver Date: Mon, 25 Nov 1996 21:03:33 -0800 From: E van der Laak Organization: Eindhoven University of Technology, The Netherlands Message-ID: <329A7A25.2ACA@topic.nl> Reply-To: evdlaak@topic.nl With respect to the installation and configuration of a VxWorks development environment, I have the following question: Currently we are configuring a VxWorks target for use in an embedded system. We are planning to use a non-standard serial I/O-card of manufacturer Comtrol, being the Hostess 550. Does anyone of you have experience in writing your own driver for such a card? Any suggestions with respect to implementing the standard I/O functions, device list, driver table, etc OR using customary read and write operations provided by a self-made driver using for instance two message queues for I/O from/to the card? Any suggestions are appreciated. Eric van der Laak Topic Automatisering B.V. Oirschot Holland evdlaak@topic.nl --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Date: Mon, 25 Nov 1996 11:58:36 -0800 From: jbs@quiotix.com (Jeffrey B. Siegal) Organization: Quiotix Corporation Message-ID: References: <3299BB93.59E2B600@tsi-telsys.com> In article <3299BB93.59E2B600@tsi-telsys.com>, Tim Meagher wrote: > In addition, what kind of web support for testing and managing these > agents is provided (JAVA-based and http-based management)? Our Embedded WebServer supports an HTTP-based interface to SNMP which does not require that the user have a SNMP console (just a web browser). It works with any agent. See http://www.quiotix.com for a demonstration. - -- Jeffrey B. Siegal Quiotix Corporation +1 415 782-6012 http://www.quiotix.com --------------------------- Newsgroups: comp.os.vxworks Subject: Strange iteraction between malloc & posix timers Date: Mon, 25 Nov 1996 18:32:43 -0800 From: Grant Haidinyak Organization: InterNex Information Services 1-800-595-3333 Message-ID: <329A56CB.7B7A@iwv.com> Hello, We were wondering if anyone else has seen the following problem. 1) Posix timers are being used, (with a rate of about once every .2 seconds). 2) malloc() is being call alot (ok, ok, a lot and a house ;) 3) When a task is in the middle of a malloc(), a timer pops. 4) The execution of the timer signal happens on the texcTask, which takes over the personality of the tasks that set the timer, ie the task id. 5) The signal handling code does another malloc(). 6) Since malloc() appears to use mutex semaphores, the semGet operation succeeds because the task had already gotten the malloc semaphore. 7) The malloc() data structures are now effectively hosed. So, has anyone else seen this behavior? grant ps We actually saw this behavior using an ICE, so this isn't speculation... --------------------------- Newsgroups: comp.os.vxworks Subject: re: non blocking sockets Date: Tue, 26 Nov 96 06:36:48 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57e32v$buh@idiom.com> References: <3298F82D.167EB0E7@bbn.com> In article <3298F82D.167EB0E7@bbn.com>, Fred Roeber wrote: >H.J. Bae responded: > >> VxWorks doesn't really support asynch sockets. > >I am surprised by this. The sockLib man page talks about the FIONBIO >ioctl option to make a socket non blocking and I have used it before >and thought it worked. Still, Hae Jin did a lot of the original work >on the VxWorks network code and usually is dead on accurate. So what >gives? Fred > Again, non-blocking sockets != asynch sockets. The non-blocking one is supported in VxWorks, asynch one is *not*! http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: Sat, 23 Nov 1996 19:59:11 -0600 From: "Steven J. Lee" Organization: NewMonics Inc. Message-ID: <3297ABEF.52FE@newmonics.com> References: <329355D5.237C228A@aud.alcatel.com> Reply-To: sjlee@newmonics.com Shash Chatterjee wrote: > > Is there a vendor-independent abstraction layer for typical RTOS > functions like messaging, tasking, events/semaphores, timer-services, > etc? > Have you had a look at PERC, a clean-room implementation of Java specifically for real-time, embedded systems? - -- Steve Lee, Software Engineer voice: (515) 296-0897 NewMonics Inc. fax: (515) 294-9910 2501 N. Loop Dr., Suite 614-A internet: sjlee@newmonics.com Ames, IA 50010 http://www.newmonics.com Supporting PERC(TM): Portable Executive for Reliable Control --------------------------- Newsgroups: comp.os.vxworks Subject: z8530 synchronous driver Date: Mon, 25 Nov 1996 13:49:32 +0000 From: Doug Owens Organization: Lawrence Livermore National Lab Message-ID: <3299A3D0.51F6@llnl.gov> Reply-To: owens2@llnl.gov Is there a synchronous driver for the Z8530 chip for vxWorks 5.3? Thanks, Doug Owens owens2@llnl.gov --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: Tue, 26 Nov 96 07:01:24 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57e4h3$buh@idiom.com> References: <9611240839.AA00667@rst.co.il> <57dd3r$qpc@qnx.com> In article <57dd3r$qpc@qnx.com>, mphunter@18.com (Michael Hunter) wrote: >Leonid Rosenboim (leonid@rst.co.il) wrote: >: In adtivle <570cik$ga1@qnx.com> of QNX wrote: >: > Why not POSIX? Between the >: > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c >: > for threads, and 1003.1d for a few more realtime extensions, everything >: > you've named is very nicely covered > >: Before glorifying POSIX, you should know that VxWorks (since 5.2) has >: complete support for the POSIX Real-Time extentions. I went through >: all these APIs a couple of times, trying to decicde if a particular >: application could use them, and time after time I was dissapointed >: by some thing(s) that where simply missing. > >: For example, a wind mutex semaphore has the Priority Inheritance >: option, POSIX semaphore does not. > >Well, I'm not exactly sure what a "windy mutex semaphore" is, but >I'll describe how POSIX semaphores and mutexes work. My earlier follow-up to Leonid Rosenboim's article didn't make it to the net, for some reason... anyway, here's a rewrite of what I wrote, just to add more confusion to the issue. VxWorks supports a type of semaphore that can be used for priority inversion avoidance. You can specify an option to the semaphore to indicate that you want the priority to be inherited while the semaphore is being held -- a typical solution to priority inversion problem in a threaded OS. Unfortunately, VxWorks allows this options only on mutex semaphores, but not on counting semaphores and binary semaphores. This is only one of many inconsistencies in VxWorks API. As Michael correctly points out above, POSIX threads do have a priority inheritance option. The way POSIX defines it is different though (better), because the option is settable as an attribute of a given thread. Thread specific attributes are "hints" to the kernels that provide threading. The kernel "implementation" can choose to implement priority inheritence on mutex or conditions (similar to VxWorks semaphores). The API defined in POSIX is generalized and consistent. I'm not into blindly following "standards", but blaming POSIX for something that it does correctly and praising VxWorks for breaking consistency in API seems a little unfair. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Re: vxWorks and RPC Date: Sun, 24 Nov 1996 07:00:09 GMT From: noblenet@world.std.com (NobleNet Inc.) Organization: NobleNet, Inc. Message-ID: References: In article , Mark Menge wrote: >Does anyone know if it is possible to use Visual C's RPC and vxWorks? > >We are using Netmanage's RPC SDK which requires special >installation. Please contact NobleNet for ONC/RPC tools and solutions for UNIX, Windows (3.1/95/NT), Macintosh, VMS, OS/2, NetWare, VxWorks, etc. NobleNet, Inc. 337 Turnpike Road Southboro, MA 01772 Voice +1 508 460 8222 Fax +1 508 460 3456 PRESS RELEASE For Immediate Release For Further Information, Please Contact: David Burns Vice President of Marketing NobleNet, Inc. Voice: (508) 460-8222 FAX: (508) 460-3456 e-mail: david.burns@noblenet.com "The Client/Server Toolkit for C and C++ Programmers" New Book From NobleNet Turns Programmers Into Client/Server Experts New York, October 8, 1996 -- NobleNet, Inc. today announced the availability of its newly published book that turns C and C++ programmers into client/server experts. Co-authored by middleware experts Steven Lemmo and Rich Grehan, The Client/Server Toolkit for C and C++ Programmers is a self- contained instructional tool that teaches programmers how to distribute any application or Application Programming Interface (API) across a network. The CD-ROM software included with The Client/Server Toolkit features a unique Windows-based client/server simulator that lets programmers gain hands-on experience in client/server partitioning. Programmers are guided through four "real-world" client/server projects: distributed ODBC database, scanner device, image engine, and datafeed. The authors expertise combined with a Rapid Application Development (RAD) environment, demystifies the art of distributing complex applications. "I learned more about client/server development in the last three days of reading your book than I learned in the past few years of doing C and C++ programming," said Pascal Specht, Technical Sales Engineer at Precision Software in Paris, France. "Our new book will help any C or C++ programmer that wants to learn about state-of-the-art client/server computing," said Steve Lemmo, co-author and Chief Technology Officer of NobleNet. "The techniques taught in the book will help programmers learn to use the powerful Interface Definition Languages (IDLs) found in today's most popular distributed computing middleware." Beginning with a monolithic application, readers learn how to separate programs into independent parts that communicate with each other. While other books on client/server computing include sample code, The Client/Server Toolkit goes further and delivers a true client/server Software Development Toolkit (SDK) designed for application partitioning. Unlike other approaches, programmers learn to build client/server applications using industry-standard RPC technology that requires no source code changes. "The Client/Server Toolkit is ideal for programmers that want to get a quick immersion into client/server computing with tools that require very little effort to learn," said Vincent Russo, Assistant Professor of Computer Science at Purdue University. "I like the fact that the book is totally self- contained. It has a wealth of real-world examples that provide the reader with a thorough understanding of client/server development. And the simulator gives programmers hands-on experience with building and running real client/server applications." Although The Client/Server Toolkit is written for C and C++ programmers, examples are given that show "drag and drop" programmers how to create client/server applications utilizing popular GUI front-ends such as Visual Basic, PowerBuilder, Delphi, and Developer 2000. Distributed with the book is a free version of NobleNet's powerful standards-based RPC product used by client/server developers world-wide. Programmers are presented with client and server Windows connected by a simulated network. Using NobleNet RPC, applications developed on the simulator are easily deployed to over 40 platforms including 26 UNIXes, Windows 3.1, 95, and NT, NetWare, Macintosh, OS/2, and VMS. More than 20 Windows-based TCP/IP stacks are supported to ensure operation in existing multi-vendor environments. Co-author Steven Lemmo founded NobleNet, engineered NobleNet's first software product, EZ-RPC(R), and led the team that developed the company's NetWare and Windows-based middleware tools. With an in-depth understanding of both communication and application software, he is a sought after consultant on RPC programming. Steve has over fifteen years of experience in software engineering and tools development in companies such as Computervision Corp., Sun Microsystems, Inc., and Xerox Imaging Systems, Inc. He is widely recognized as an expert on distributed computing and is frequently called upon to appear at industry forums. Co-author Rick Grehan has been on the editorial staff of BYTE Magazine for over 11 years. He is currently the Technical Director of BYTE Labs and the author of BYTE's monthly CodeTalk column. His articles have appeared in BYTE, Embedded Systems Programming, and Forth Dimensions. In addition, he was a contributor to the 1993 edition of The Encyclopedia of Microcomputers, published by Marcel Dekker, Inc. Rick is also the designer of BYTE Magazine's BYTEmark benchmark suite. The Client/Server Toolkit for C and C++ Programmers is published by NobleNet. The 350 page book with CD-ROM can be ordered for $49.95 by calling (800)-250- 6427 or (508)-893-0398. NobleNet offers tools for distributed client/server development for procedural and object paradigms. Incorporated in 1991, NobleNet is a world leader in Remote Procedure Call (RPC) technology and has won numerous awards for its RPC product family. NobleNet also distributes IONA Technologies' industry- leading "Orbix" CORBA-compliant Object Request Broker. The company is headquartered in Southboro, MA, and can be reached at (508) 460-8222 or at . --------------------------- End of New-News digest ********************** From Lennart.Bie@emw.ericsson.se Tue Nov 26 06:12:12 1996 From: Lennart.Bie@emw.ericsson.se (FY/DX Lennart Bie) Date: Tue Nov 26 06:12:15 PST 1996 Subject: Synchronous Drivers for VxWorks Can anyone give a hint where I can find a synchronous driver for the serial ports 3 & 4 on the Moto MVME1604 PPC board for VxWorks. -- OR -- Does anyone know where I can get hold of *ANY* synchronous Driver for prefearbly the Z85230 chip or at least the Z8530 chip. If I am lucky it will also use dma's when reading and writing. Thanks in advance. Lennart Bie, Ericsson Microwave Systems AB, Molndal, Sweden From gverdun@fibertek.com Tue Nov 26 06:52:17 1996 From: "Gustavo H. Verdun" Date: Tue Nov 26 06:52:18 PST 1996 Subject: [Q] Does anyone have a PPC exception to signal mapping? I'm trying to create a signal handler for a PPC603e to trap VME bus errors. VMEbus errors produce a machine check exception. What signal should I intercept to capture this exception? Thanks, Gustavo H. Verdun Senior Systems Engineer FIBERTEK, INC. \|/ --------------------------*-- 510 Herndon Parkway /|\ Herndon, Virginia 20170-5225 Voice: (703) 471-7671 Fax: (703) 471-5806 http://www.fibertek.com From tja@radstone.co.uk Tue Nov 26 09:02:18 1996 From: Tim Allen Date: Tue Nov 26 09:02:25 PST 1996 Subject: Re: [Q] Does anyone have a PPC exception to signal mapping? >I'm trying to create a signal handler for a PPC603e to trap VME bus errors. > >VMEbus errors produce a machine check exception. > >What signal should I intercept to capture this exception? VxWorks on the Radstone PPC 60x range of processors reports VMEbus errors in different ways. During coupled cycles the Universe (VME I/F device) will indicate master bus errors with a PCI target abort, this is detected by the MPC105 (EAGLE) processor/PCI bridge and a machine check exception raised. During decoupled cycles, eg posted writes, a master bus error is logged using the V_AMERR register and a VERR interrupt generated. All these events are reported by VxWorks by default. Additionally, it is possible to route the machine check to IRQ14, via jumpers/links on the board. So you can either use excVecSet() to install a function over the existing machine check handler (using excVecGet() first allows you to preserve the original function and call it in your own handler if required) or you can route machine checks to IRQ14 and install a handler using intConnect (14,...). If you need any further information, feel free to contact me directly. +------------------------------------------------------------------+ | Tim Allen phone: +44 (0)1327 359444 | | Radstone Technology PLC, UK. fax: +44 (0)1327 358112 | +------------------------------------------------------------------+ From bawilson@llnl.gov Tue Nov 26 15:34:27 1996 From: "Bruce A. Wilson" Date: Tue Nov 26 15:34:29 PST 1996 Subject: SDLC driver for MV-1603 Does anyone know of an SDLC device driver written for the Motorola MVME-1603 (PowerPC) target? Bruce Wilson LLNL (L-054) 7000 East Ave Livermore, CA 94550 bawilson@llnl.gov -- From amolkho@madge.com Wed Nov 27 02:16:55 1996 From: "Adi Molkho LAN-Tel" Date: Wed Nov 27 02:16:57 PST 1996 Subject: Packed Hello I am working with I960CA processor with VxWorks 5.3 (Gnu toolkit 2.6) when i declare the ip_eth structure (see the attached file) i see that it size (using sizeof) is 64 bytes also the sum of its fields sizes is only 52 bytes and i used the packed attribute all the way. Does anybody know why Thanks Adi ------------------------------------------------------------- Uuencoded File Attachment: PACK.C ------------------------------------------------------------- begin 660 PACK.C M='EP961E9B!S=')U8W0@25!?151(('L*("!U;G-I9VYE9"!C:&%R("!M86-? M9&5S=%LV72!?7V%T=')I8G5T95]?("@H<&%C:V5D*2D["B`@=6YS:6=N960@ M8VAA References: <9611240839.AA00667@rst.co.il> Reply-To: wdfindley@ti.com >>>>> "LR" == Leonid Rosenboim writes: In article <9611240839.AA00667@rst.co.il> leonid@rst.co.il (Leonid Rosenboim) writes: LR> In adtivle <570cik$ga1@qnx.com> of QNX wrote: >> Why not POSIX? Between the base POSIX >> standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c >> for threads, and 1003.1d for a few more realtime extensions, everything >> you've named is very nicely covered LR> Before glorifying POSIX, you should know that VxWorks (since 5.2) has LR> complete support for the POSIX Real-Time extentions. I went through LR> all these APIs a couple of times, trying to decicde if a particular LR> application could use them, and time after time I was dissapointed LR> by some thing(s) that where simply missing. LR> For example, a wind mutex semaphore has the Priority Inheritance LR> option, POSIX semaphore does not. LR> So if anybody tells you that POSIX covers hard R-T needs "very nicely", LR> then I suppose he or she understand very little about what hard R-T is. You're right, POSIX semaphores do not support these protocols. However, POSIX does support Priority Inheritance (PI) and the Priority Ceiling Protocol (PCP) via the POSIX mutexes defined in 1003.1c. Typically, PI is used when a resource has an owner. A semaphore doesn't have an "owner" (an OS can determine the owner of a binary semaphore). As a result, the POSIX mutex is a cleaner mechanism to use for PI and PCP. LR> Besides, when a standards body decides to design a spec for a Horse, LR> they end up with somethig more resembling a Camel. IMHO, they end up with something more like a Shetland pony. That's because they can only standardize on things that people agree on. LR> Leonid - -- Doug ************************************************************************* W. Douglas Findley "There are 2 kinds of people, those who do the work & wdfindley@ti.com those who take the credit. Try to be in the 1st group; (972) 575-5448 there is less competition there." Indira Ghandi ************************************************************************* --------------------------- Newsgroups: comp.os.realtime,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: 26 Nov 1996 00:20:11 GMT From: mphunter@18.com (Michael Hunter) Organization: QNX Software Systems Ltd. Message-ID: <57dd3r$qpc@qnx.com> References: <9611240839.AA00667@rst.co.il> Leonid Rosenboim (leonid@rst.co.il) wrote: : In adtivle <570cik$ga1@qnx.com> of QNX wrote: : > Why not POSIX? Between the : > base POSIX standard 1003.1 and .1a, and 1003.1b for realtime, and 1003.1c : > for threads, and 1003.1d for a few more realtime extensions, everything : > you've named is very nicely covered : Before glorifying POSIX, you should know that VxWorks (since 5.2) has : complete support for the POSIX Real-Time extentions. I went through : all these APIs a couple of times, trying to decicde if a particular : application could use them, and time after time I was dissapointed : by some thing(s) that where simply missing. : For example, a wind mutex semaphore has the Priority Inheritance : option, POSIX semaphore does not. Well, I'm not exactly sure what a "windy mutex semaphore" is, but I'll describe how POSIX semaphores and mutexes work. POSIX semaphores are named objects valid between processes. They do not support priority inheritance. In any case its illogical to compare the POSIX interprocess synconization primative with a lighter intertask syncronization primative. OTOH the POSIX (pthread) mutexs only have to be valid between threads which, AFAIK, are comparable to VxWorks tasks. There is an option to have POSIX (pthread) mutexes valid between processes. Section 13.6.1.2 of 1003.1, 1996 clearly shows that pthread mutexes can support 3 schemes: PTHREAD_PRIO_NONE, PTHREAD_PRIO_INHERIT, and PTHREAD_PRIO_PROTECT. PTHREAD_PRIO_NONE is uninteresting, but PTHREAD_PRIO_INHERIT is the typically used priority inheritance scheme for defeating priority inversion. The PTHRED_PRIO_PROTECT allows for the priority ceiling method of preventing priority inversion. POSIX also support condition variables as a syncronization primative. : So if anybody tells you that POSIX covers hard R-T needs "very nicely", : then I suppose he or she understand very little about what hard R-T is. cheap shot. : Besides, when a standards body decides to design a spec for a Horse, : they end up with somethig more resembling a Camel. This is often true, but its also true that a close minded person that wants to see a Camel will see one even if its a Horse. Or said another way, each to his own, but I'd rather not prejudge something before I've been able to make my own engineering evaulation. : Leonid Back to the original question. In building an abstraction layer for real time I believe you will want to look at the existing standards. In the areas that support is common its economically beneficial to uses the standards. If you can pick a "solution domain" then you can probably find a larger set of common features. By this I mean that if you realize that you always work with machines that have a certain amount of horse power and memory then you can assume more then if you want your abstraction to scale from 8051 projects to Alpha projects. After you've pushed the standards as far as you feel comfortable then its reasonable to define cover functions for functionality that must always exist for you abstraction but doesn't have a common API. If you want to support "wind mutex semaphore" and pthread mutexes then its might be reasonable to pick one or the other API and emulate it on the other OS or pick your own neutral API. This levys requirements on all of the OS' that you port to. Part of this will include performance and reliability requirements. Finally, and this is the part where the fun is, good design can allow you to take advantage of each OS' special capabilities. Good partitioning of your (abstraction and application) code can often mean the difference between being able to port your code in a fairly short time to having each port become a real nightmare. Michael - -- * Michael Hunter (mphunter@qnx.com) --------------------------- Newsgroups: comp.object,comp.realtime,comp.software-eng,comp.os.vxworks Subject: Re: RTOS abstraction layer Date: Tue, 26 Nov 1996 17:27:29 +0200 From: Rami Gideoni Organization: AISYS Message-ID: <329B0C61.70BF@aisys.co.il> References: <329355D5.237C228A@aud.alcatel.com> <3297ABEF.52FE@newmonics.com> Hi, You might want to take a look at VITA (VMEbus International Trade Association), which is working on establishing operation system standard interface. VITA was accredited as an ANSI (American National Standards Institute) standards development organization (SDO) in June of 1993. VITA formed the VITA Standards Organization (VSO) as an independent body of VITA members to develop open technology standards that fit within the scope of VITA's accreditation. The orgainzation can be accesed at : http://www.vita.com and at http://www.vita.com/vso/stds.html. Steven J. Lee wrote: > > Shash Chatterjee wrote: > > > > Is there a vendor-independent abstraction layer for typical RTOS > > functions like messaging, tasking, events/semaphores, timer-services, > > etc? > > > > Have you had a look at PERC, a clean-room implementation of Java > specifically for real-time, embedded systems? > > -- > Steve Lee, Software Engineer voice: (515) 296-0897 > NewMonics Inc. fax: (515) 294-9910 > 2501 N. Loop Dr., Suite 614-A internet: sjlee@newmonics.com > Ames, IA 50010 http://www.newmonics.com > > Supporting PERC(TM): Portable Executive for Reliable Control - -- Rami Gideoni Development Projects Manager AISYS Ltd. E-mail : rami_gideoni@aisys.co.il WWW : http//www.aisys-usa.com - --------------------------- Address : 16 Basel street,P.O.B 10041 Petach-Tikva 49001 ISRAEL Phone : 1-800-397-7922, 972-3-9226860 Fax : 1-800-625-5525,972-3-9226863 - ---------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Date: 26 Nov 1996 09:34:52 -0700 From: bgeer@xmission.xmission.com (bgeer) Organization: XMission Internet (801 539 0900) Message-ID: <57f67c$jcn@xmission.xmission.com> References: <3299BB93.59E2B600@tsi-telsys.com> Tim Meagher writes: >Can anyone elaborate on why Wind River is providing Epilogue's SNMP >Agent instead of SNMP Research's agent? Did WRS change agents? I thought WindNet was based on SNMP Research's agent... >Are there any other SNMP agent tools that should be seriously considered >as an alternative? We ended up using a copy of Peer Networks SNMP agent & sub-agent code ported to VxWorks. The port took well less than a week. (Who knows? Maybe Peer now sells a VxWorks version...) This was for a show- capability project which wasn't delivered, but it worked pretty well. Peer included SMUX protocol, was independent from the VxWorks kernel for convenience of multi-board kernel configuration, & was easily extensible. OTH, the documentation sucked & Peer's handling of table data was very convoluted. I didn't have time to try or even learn much about the CMU SNMP -- the VxWorks archives include a port of this agent. - -- <> Robert Geer & Donna Tomky / * <> <> bgeer@xmission.com | _o * o * o <> <> Salt Lake City, Utah | -\<, * <\ <> U S A | O/ O __ /__, /> <> --------------------------- Newsgroups: comp.os.vxworks Subject: Is this a new group Date: 26 Nov 96 17:33:36 GMT From: "Jim O'Brien" Organization: Embedded Support Tools Inc. Message-ID: <01bbdbd8$d0601fc0$8dad8dcf@jimo.estc.com> I am trying to read messages in this group, but it it returns 0 messages, 0 read. Other people have told me that there are lots of messages in this group. --------------------------- Newsgroups: comp.os.vxworks Subject: Hot-swap support in VxWorks? Date: Tue, 26 Nov 1996 13:21:51 -0800 From: Andy Van Pelt Organization: QUALCOMM, Incorporated; San Diego, CA, USA Message-ID: Does VxWorks support hot-swapping of boards? Specifically, if you are using VxMP, and your board is participating, has anybody found a way to detach the board from the various structures and then attach it back again? This is for a 68K VME setup. - -- Andy Van Pelt Internet: avanpelt@qualcomm.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: non blocking sockets Date: Tue, 26 Nov 1996 18:42:38 -0800 From: Duane C Austin Organization: A customer of Pacific Bell Internet Services Message-ID: <329BAA9E.5DA0@pacbell.net> References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com> Reply-To: dcaustin@pacbell.net [snip] > > Again, non-blocking sockets != asynch sockets. > The non-blocking one is supported in VxWorks, asynch one is *not*! > > http://peacefulstar.oakland.ca.us > mailto:hjb@peacefulstar.oakland.ca.us ok... I thought non-blocking == asynch i/o so....... What is "asynch sockets"? thanks Duane dcaustin@pacbell.net --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SNMP Agents for VxWorks - Epilogue vs SNMP Research (or other) Date: Wed, 27 Nov 96 07:02:50 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57govc$ejl@idiom.com> References: <3299BB93.59E2B600@tsi-telsys.com> <57f67c$jcn@xmission.xmission.com> In article <57f67c$jcn@xmission.xmission.com>, bgeer@xmission.xmission.com (bgeer) wrote: >I didn't have time to try or even learn much about the CMU SNMP -- the >VxWorks archives include a port of this agent. > > I've used CMU SNMP in real products in the past and it works just fine. The VxWorks archive port works well, with one minor bug that gets triggered by snmpwalk (infinite loop), which is easy to fix. Customizing CMU SNMP for a small embedded product is a whole different issue -- due to its way of using text files and parsing routines for MIB construction in run-time, rather than using compiled binaries in-core using tools before the run-time. Other than that, it works great and I highly recommend it. http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Task Deletion Date: Tue, 26 Nov 1996 11:32:32 -0800 From: Grant Haidinyak Organization: InterNex Information Services 1-800-595-3333 Message-ID: <329B45D0.38A@iwv.com> I was wondering, vxWorks lets you allocate the tcb & stack for a task (via the taskInit/taskActivate functions). Does anyone know when it is ok to free these resources. For example, could I just add a taskDeleteHook and free the resources then, or must I be more clever than that? thanks, grant --------------------------- Newsgroups: comp.os.vxworks Subject: How To Turn Off Optimization Date: Tue, 26 Nov 1996 07:24:04 -0800 From: russell.brill@jpl.nasa.gov (Russ Brill) Organization: Jet Propulsion Laboratory Message-ID: How do I turn off all optimization on the Green Hills compiler? --------------------------- End of New-News digest ********************** From laurin@bisco.kodak.COM Wed Nov 27 05:33:37 1996 From: djlaurin@kodak.com (Dave Laurin - 66781 - DK) Date: Wed Nov 27 05:33:39 PST 1996 Subject: Fast Ethernet Drivers Are there any Fast Ethernet Drivers available for vxWorks that support the 100mBit rate? Looking for either a Fast Ethernet PCI bus based board solution for which there are drivers, or a single board computer solution with on board Fast Ethernet hardware, drivers support, and a PCI bus interface in the $1K range. Thanks From p72950@gmcl.co.uk Wed Nov 27 08:04:15 1996 From: Phil Quiney Date: Wed Nov 27 08:04:25 PST 1996 Subject: Finding file descriptors Hi guys, I didn't think this would cause a problem but I haven't found a way to do it yet. The problem is to find the file descriptor (fd) given the name of a serial channel which is already open: eg for channel 'tyCo/3' what is the fd representing this channel. For the record I have tried the following: 1/ Using 'open' returns ERROR if the channel is already open. 2/ Using 'iosDevFind' returns a DEV_HDR* if the device can be found. The info contained is similar to that returned by 'iosDevShow' and does not mention fds. 3/ Using an undocumented function 'iosFdDevFind' returns the same DEV_HDR* given a file descriptor. (So a quick 'for' loop of fds should find the same DEV_HDR* and hence tie the name to the fd) 4/ The above works for '/tyCo/xx' type channels but not for the '/vio' virtual consoles since calls to 'iosFdDevFind' for any of the '/vio/xx' devices returns the same DEV_HDR*. 5/ The routine iosFdShow is not on the target (for Tornado anyway) so I can't redirect & sort the output of this function. Anyone any ideas? Regards Phil Quiney =============================================================================== Phil Quiney _/_/_/_/ _/ _/_/_/_/ email : quiney@gmcl.co.uk GEC Marconi _/ _/ _/ _/ _/ tel : +44 1245 353221x3914 Communications Ltd _/_/_/_/ _/ _/ _/ _/_/ fax : +44 1245 275448 Chelmsford _/ _/_/_/_/ _/_/_/_/ England CM1 1PL _/ =============================================================================== From Ricky.D.Graves@jpl.nasa.gov Wed Nov 27 11:01:58 1996 From: Ricky D Graves Date: Wed Nov 27 11:02:00 PST 1996 Subject: Heurikon symbol load prob. All, Help me please !!! I have been having a an intermittent problem with Heurikon HK68 V3Fs and Vxworks 5.02B. During bootup when loading symbols with all lower case letters I see certain letters get loaded as uppercase. Letters "d" and "a" seem to occur commonly. After the symbol is loaded improperly I get an undefined symbol error when a progrma is loaded that refrences the corrupted symbol. I have been working with Heurikon to determine the cause but so far that can't duplicate the problem. I have even seen one case where the an uppercase letter is shown being loaded and then message showing the address and data shows a lower case letter. I have tried different tranceivers, chassis, etc to no avail. The problem definitely follows particular cards from one chassis to another. I have about 5 cards out of 20 that have the problem. The only difference I have been able to determine is the problem cards have 80ns RAM instead of 70ns which is called out in the manual. If anybody can tell em whether an error like this can get passed the Ethernet error checking that would help narrow the problem down. I don't think it can. Heurikon doesn't think that could cause the problem. Here is a sample of what I See: The error is not flagged until a program is loaded that uses the symbol. The error generated at that point is: _assem_iruA =0xfe000000 new symbol "-assem_iruA" added to symbol table. _assem_iruA = 0x78e434: value = -33554432 = 0xfe000000 \ undefined symbol: _assem_irua ld error: error reading file (errno = 0x1x0001). or _assem_iruB =0xfe010000 new symbol "-assem_irub" added to symbol table. _assem_irub = 0x78e400: value = -33488896 = 0xfe010000 \ undefined symbol: _assem_irua ld error: error reading file (errno = 0x1x0001). I believe this error is just a sympton of the intial error which is the symbol being loaded improperly into the symbol table. I tried booting several of the problem cards using a 10BT transceiver and still observed the same problem. One card (SN 142) seemed to improve after it was on in the chassis for a few minutes but I didn't try it enough times to verify the problem had went away. I also made note of the battery voltges which were around 3.7V but did seem to increase somewhat after they were in the chassis for a few minutes. In the past, I have not been able to correlate the battery condition to the problem. So far about the only thing that seems to be common to these boards is the 80ns RAM. If we can understand what must be happening to cause the symbol to get loaded incorrectly I think that would provide the answer. I looked up ASCII character bit definitions and found the difference between uppercase and lower case letter "a" to be the following: Octal Octal 1 000 001 A 1 100 001 a 1 000 100 D 1 100 100 d If this translates directly to data bits 0-7 on the VME, that indicates bit 6 is being incorrectly read as zero instead of one. Letter "d" and "a" are the errors I see most often. I don't understand the symbol loading process well enough to know what could possibly cause this problem. Do you know somebody at Vxworks that could help with this problem ? P.S. I did notice a slight difference on the symbol load expression between your simulated load and the actual load which I doubt would make any difference but I will mention it anyway. Our loads seem to have several spaces between the symbol name and the "=" like the following: _assem_irua = 0xfe000000 whereas yours _assem_irub=0xfe010001 From wbrown@csg.lbl.gov Wed Nov 27 12:40:57 1996 From: wbrown@csg.lbl.gov (Bill Brown) Date: Wed Nov 27 12:40:59 PST 1996 Subject: Re: Heurikon symbol load prob. > [ ... ] > The only difference I have been able to determine is the problem cards > have 80ns RAM instead of 70ns which is called out in the manual. Well, I don't know anything about the Heurikon boards, but I'd get a logic analizer and take a _REAL_GOOD_LOOK_ at the _actual_ memory timing vs the manufacturers' specs on those 80 nS ram chips. > [ ... ] > Octal Octal > 1 000 001 A 1 100 001 a > 1 000 100 D 1 100 100 d As some famous person once said, "Circumstantial evadence can be particularly damning, like when you find trout swimming in the milk." Or something like that. More or less. Spelling errors ommitted. One might even spend a few hours writing some read/write/compare memory tests, if you could ever get them to run on these boards. It would be interesting to know if the errors tend to cluster around some addresses. I better shut up before I _really_ put my foot in my mouth, which I seem to do far too often. Happy Turkey Day, everyone! Disclaimer: Any opinions are my own and have | -bill nothing to do with the official policy or the | wlbrown@lbl.gov management of L.B.N.L, who probably couldn't | Berkeley, CA care less about employees who play with trains. | aka wlbrown@netcom.com From usd@mee.hwm.com Thu Nov 28 01:09:58 1996 From: Uwe Scheffold Date: Thu Nov 28 01:10:05 PST 1996 Subject: How to set the cursor on vt100-terminal. Hi vxWorkers, it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help? Regards: Uwe Scheffold ------------------------------------------------------------------------- Uwe Scheffold _/_/_/_/_/_/_/_/_/ _/_/_/_/ Mail: usd@mee.hwm.com Tele Robot Engineering _/ _/ _/ _/ Web: http://www.hwm.com Waelischmiller GmbH _/ _/_/_/ _/_/_/ Voice: (+49) 7532 4320 41 Klingleweg 8 _/ _/ _/ _/ Fax: (+49) 7532 4320 99 D-88709 Meersburg _/ _/ _/_/_/_/_/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From daemon@csg.lbl.gov Thu Nov 28 04:00:17 1996 From: daemon@csg.lbl.gov Date: Thu Nov 28 04:00:24 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Nov 28 04:00:15 PST 1996 Subject: "Auto" Routing Subject: Re: "Auto" Routing Subject: delay functions independent on ticks Subject: Re: delay functions independent on ticks Subject: Re: delay functions independent on ticks Subject: Interrupts ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: "Auto" Routing Date: 27 Nov 1996 13:12:12 GMT From: milesm@tif531.ed.ray.com (Michael Miles) Organization: Raytheon Message-ID: <57henc$4rj@news.res.ray.com> Hi-- I was wondering if anyone has any experience with re-routing ip packets to an alternate LAN when the LAN they were originally sent to is down? I am working on a system with 3 LANS. Each is properly configured in the Routing table. It seems to me that if a LAN fails, it is the job of my application code to detect the failure and update the routing table to use a different LAN. A co-worker tells me that he is sure that VxWorks will detect the failure and re-route automatically. Is there anyone with experience in this area who might be able to give me some insight? Thanks Mike Miles --------------------------- Newsgroups: comp.os.vxworks Subject: Re: "Auto" Routing Date: Wed, 27 Nov 96 19:05:32 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57i3bo$on3@idiom.com> References: <57henc$4rj@news.res.ray.com> In article <57henc$4rj@news.res.ray.com>, milesm@tif531.ed.ray.com (Michael Miles) wrote: >Hi-- > >I was wondering if anyone has any experience with re-routing ip packets >to an alternate LAN when the LAN they were originally sent to is down? I >am working on a system with 3 LANS. Each is properly configured in the >Routing table. It seems to me that if a LAN fails, it is the job of my >application code to detect the failure and update the routing table to >use a different LAN. A co-worker tells me that he is sure that VxWorks >will detect the failure and re-route automatically. Your co-worker is wrong. VxWorks will not detect the failure and re-route automatically. You either have to do this in your application (edit routing table), or use a routing protocol daemon (port one on your own). http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: delay functions independent on ticks Date: 27 Nov 1996 21:34:30 GMT From: chrisver12@aol.com Organization: AOL, http://www.aol.fr Message-ID: <19961127213600.QAA04995@ladder01.news.aol.com> I try to find timer or delay function independent on the clock ticks to sample data from an I/O VME board with a period less than the clock ticks (uselly 10 ms) and for a short time 100ms. I dont want to change the ticks rate for that purpose. Function like nanosleep(), taskdelay() or timer functions seems to be dependant on the the clock tiks and the minimum delay given is equivalent to the ticks. Thanks to help me if you know the solution. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: delay functions independent on ticks Date: Thu, 28 Nov 1996 02:36:25 GMT From: VanCLy@ix.netcom.com (Van Chinh Ly) Organization: Netcom Message-ID: <57ito1$c0f@dfw-ixnews2.ix.netcom.com> References: <19961127213600.QAA04995@ladder01.news.aol.com> Reply-To: VanCLy@ix.netcom.com chrisver12@aol.com wrote: >I try to find timer or delay function independent on the clock ticks >to sample data from an I/O VME board with a period less >than the clock ticks (uselly 10 ms) and for a short time 100ms. >I dont want to change the ticks rate for that purpose. >Function like nanosleep(), taskdelay() or timer functions seems to be >dependant >on the the clock tiks and the minimum delay given is equivalent to the >ticks. I use the sysClkRateGet() to find out how many clicks are in a second. From there on, I can find a conversion constant to get the number of clicks I need to get the time period I want. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: delay functions independent on ticks Date: Thu, 28 Nov 96 05:50:57 GMT From: hjb@peacefulstar.oakland.ca.us (H.J. Bae) Organization: Peaceful Star Message-ID: <57j95s$9ta@idiom.com> References: <19961127213600.QAA04995@ladder01.news.aol.com> <57ito1$c0f@dfw-ixnews2.ix.netcom.com> In article <57ito1$c0f@dfw-ixnews2.ix.netcom.com>, VanCLy@ix.netcom.com wrote: >chrisver12@aol.com wrote: > >>I try to find timer or delay function independent on the clock ticks >>to sample data from an I/O VME board with a period less >>than the clock ticks (uselly 10 ms) and for a short time 100ms. > >>I dont want to change the ticks rate for that purpose. > >>Function like nanosleep(), taskdelay() or timer functions seems to be >>dependant >>on the the clock tiks and the minimum delay given is equivalent to the >>ticks. > >I use the sysClkRateGet() to find out how many clicks are in a second. >From there on, I can find a conversion constant to get the number >of clicks I need to get the time period I want. > This is not what original poster is asking for. The usual clock rate is set to 60 hz (60 ticks per second), which is a common tick count for most kernel (historically significant for being the same as current frequency on power line, which was used in old machines). This clock rate is not accurate enough for 10 msec period, and the original poster does not want to change it to higher frequency either. The question is not about how to find clock rates, nor is it about using faster clock rates, it is how to get 10 msec period without changing main system clock rates. One method is using aux clocks, but that will cause extra interrupt handling overhead, which you probably do not want. Another method, if hardware allows it, is to run clock/timer HW at high rates with interrupts turned off (if you have more than one timer channels) or program it to run at high resolution but interrupt you slowly (after the counters runs down to some number, say 100 ticks). Then you can write a delay routine that samples the values of running timer and poll until desired resolution is achieved. This is a "common trick." http://peacefulstar.oakland.ca.us mailto:hjb@peacefulstar.oakland.ca.us --------------------------- Newsgroups: comp.os.vxworks Subject: Interrupts Date: 28 Nov 1996 05:06:31 GMT From: x1593135@ecs.fullerton.edu (--Ext Ed 15931--) Organization: California State University at Fullerton Message-ID: <57j6kn$kd5@wintermute.ecs.fullerton.edu> Does anyone have an example of code which sets up an Interrupt Service Routine in VxWorks which calls a C or C++ routine? Any example would be useful, but my platform is PowerPC 403. Thanks Steve Renate Please post or mail directly (x1593135@titan.fullerton.edu) --------------------------- End of New-News digest ********************** From herve_pellan@grenoble.hp.com Thu Nov 28 04:42:39 1996 From: Herve Pellan Date: Thu Nov 28 04:42:41 PST 1996 Subject: Re: How to set the cursor on vt100-terminal. the vxWorks Users Group Exploder wrote: > > Submitted-by usd@mee.hwm.com Thu Nov 28 01:09:58 1996 > Submitted-by: Uwe Scheffold > > Hi vxWorkers, > > it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help? > This is done through the use of Escape sequences. Cursor Movement Commands Cursor up ESC [ Pn A Cursor down ESC [ Pn B Cursor forward (right) ESC [ Pn C Cursor backward (left) ESC [ Pn D Direct cursor addressing ESC [ Pl; Pc H or ESC [ Pl; Pc f Herve +----------------------------------------------------------------------+ | /\\/\0 Herve PELLAN /\/\ Telnet: 779-5107 | | /\ / \\ /\/ / \ non-TN: (33) 4 76 14 51 07 | |/ \/\/ \ ENSD Lab / \/ \ Fax: (33) 4 76 14 51 86 | / \ \ \_GRENOBLE_____/ \ e-mail: Herve_Pellan@grenoble.hp.com| | HEWLETT PACKARD | +----------------------------------------------------------------------+ From leonid@rst.co.il Thu Nov 28 05:28:11 1996 From: leonid@rst.co.il (Leonid Rosenboim) Date: Thu Nov 28 05:28:29 PST 1996 Subject: Re: Heurikon symbol load prob. Ricky D Graves writes: >... > If anybody can tell em whether an error like this can get passed the Ethernet > error checking that would help narrow the problem down. I don't think it can. > ... The error you described could very well be as a result of timing problems with memory or ethernet or between the two. The error checking that Ethernet applies to all data is very string, CRC-32, but it is applied to data in transit on the Ethernet wire, serially. Once data gets past the EThernet controller, which in turn takes over the memory bus and writes this data in to the board's memory, it is already stripped off the CRC-32, which is checked and generated by the Ethernet controller. In other words, the parallel dat apaths inside a CPU board do bot have any safeguards against error, (usually). We had a similar problem with VME boards from Matrix couple fo years back. Real nasty. A timing problem appeared between the Ethernet mezzanine board and CPU memory, only when the board was cool, i.e. on winter mornings before the air condition warmed the lab, the board did not boot, So we turned off the fans, waited a minute, and it booted. Turned out later, that after it booted, the problem would sometimes re-appear on the 10e-3 probability scale, and the folks thought it was an application bug. Application data arrived with errors despite all measures. Hope this helps, ----------------------------------------------------------------------- Leonid Rosenboim Phone: +972-3-559-8144 R S T Software Industries Ltd. Mobile: +972-50-307-142 P.O.Box 11502, AZUR 58017, Israel Fax: +972-3-559-8244 WWW: http://www.rst.co.il E-Mail: leonid@rst.co.il From p72950@gmcl.co.uk Thu Nov 28 06:09:40 1996 From: Phil Quiney Date: Thu Nov 28 06:09:59 PST 1996 Subject: Re: How to set the cursor on vt100-terminal. Hi Uwe, I found an old VT100 manual. It suggests that the sequences are as follows (3 charactesr ESC (decimal 27) '[' and the letter A B C or D) Up ESC [ A Down ESC [ B Right ESC [ C Left ESC [ D For direct cursor control to a screen co-ordinate try ESC [ y ; x H (where y is row x is column - no spaces by the way) You can try these out by putting the terminal in local mode before writing lots of code ;) Regards Phil Quiney >Hi vxWorkers, > >it sounds simple: set the cursor on VT100-terminal connected to vxWorks tty-a (up,down,left,right). But we did not find a way to do this. Can anyone help? > >Regards: Uwe Scheffold > >------------------------------------------------------------------------- >Uwe Scheffold _/_/_/_/_/_/_/_/_/ _/_/_/_/ Mail: usd@mee.hwm.com >Tele Robot Engineering _/ _/ _/ _/ Web: http://www.hwm.com >Waelischmiller GmbH _/ _/_/_/ _/_/_/ Voice: (+49) 7532 4320 41 >Klingleweg 8 _/ _/ _/ _/ Fax: (+49) 7532 4320 99 >D-88709 Meersburg _/ _/ _/_/_/_/_/ >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =============================================================================== Phil Quiney _/_/_/_/ _/ _/_/_/_/ email : quiney@gmcl.co.uk GEC Marconi _/ _/ _/ _/ _/ tel : +44 1245 353221x3914 Communications Ltd _/_/_/_/ _/ _/ _/ _/_/ fax : +44 1245 275448 Chelmsford _/ _/_/_/_/ _/_/_/_/ England CM1 1PL _/ =============================================================================== From selliott@mkc.com.au Thu Nov 28 20:46:52 1996 From: Steve Elliott Date: Thu Nov 28 20:46:54 PST 1996 Subject: CD-ROM & ZIP drives under VxWorks Does anyone know of implementations of CD-ROM and/or ZIP drive drivers for VxWorks? Steve Elliott ---------------------------------------------------- Steve Elliott, | Voice: +61(2) 9638 4055 | MAYER KRIEG & CO | Fax: +61(2) 9638 6145 | U2, 8-10 Mary Parade | Mobile: +61(418) 236 820 | Rydalmere, NSW 2116 | Email: selliott@mkc.com.au | Australia | From daemon@csg.lbl.gov Fri Nov 29 04:00:14 1996 From: daemon@csg.lbl.gov Date: Fri Nov 29 04:00:21 PST 1996 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Nov 29 04:00:12 PST 1996 Subject: Flash File system Subject: Re: Making non-standard serial I/O -driver Subject: Re: non blocking sockets ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Flash File system Date: 28 Nov 1996 13:16:13 GMT From: "Pekka Tuusjdrvi" Organization: Heinolan Sahakoneet Oy Message-ID: <01bbdd2e$73706340$2fce9dc2@pt.hla> Can anyone give a hint where I can find a Flash File system driver for the on board flash on the MVME162 board for VxWorks. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Making non-standard serial I/O -driver Date: 28 Nov 1996 16:30:21 -0600 From: irwin@Starbase.NeoSoft.COM (Bob Irwin) Organization: Realtime Systems / SW Houston Keywords: Hostess 550 comm driver Message-ID: <57l3pt$7ms@Starbase.NeoSoft.COM> References: <329A7A25.2ACA@topic.nl> In article <329A7A25.2ACA@topic.nl>, E van der Laak wrote: >With respect to the installation and configuration of a VxWorks >development environment, I have the following question: > >Currently we are configuring a VxWorks target for use in an embedded >system. We are planning to use a non-standard serial I/O-card of >manufacturer Comtrol, being the Hostess 550. Does anyone of you have >experience in writing your own driver for such a card? > >Any suggestions with respect to implementing the standard I/O functions, >device list, driver table, etc OR using customary read and write >operations provided by a self-made driver using for instance two message >queues for I/O from/to the card? . . . >evdlaak@topic.nl I assume you're using the x86 bsp and an ISA bus. A library for this card is available from Systems Interface Software, Inc In Houston. commLib supports either the 8 or 16 channel version in either binary or ascii full duplex transfers. It does not use the vxWorks tyLib routines in order to minimize system interrupts. In transmitting, an interrupt on a given channel occurs only when its 16 byte fifo empties, and the ISR also services any other TX fifos that go empty during that one interrupt service. In receiving, a reader task periodically empties the fifos for all the open channels into their respective circular buffers (no interrupts). Contact John Reed at sis@neosoft.com for more info. - Bob - -- R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 A rut is nothing more than a grave with the ends kicked out. - ?? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: non blocking sockets Date: Fri, 29 Nov 1996 08:24:28 GMT From: valentin@netcom.com (Valentin Pepelea) Organization: Netcom Communications, Santa Clara, CA Message-ID: References: <3298F82D.167EB0E7@bbn.com> <57e32v$buh@idiom.com> <329BAA9E.5DA0@pacbell.net> Sender: valentin@netcom23.netcom.com In article <329BAA9E.5DA0@pacbell.net> dcaustin@pacbell.net writes: > >> Again, non-blocking sockets != asynch sockets. >> The non-blocking one is supported in VxWorks, asynch one is *not*! > >ok... I thought non-blocking == asynch i/o so....... What is "asynch >sockets"? Actually, asynchronous I/O usually refers to what happens during the trans- mission of data. If the sender has to block after a send operation, until the receiver replies to confirm that the data has been received, then the I/O operation is called synchronous. If the sender returns immediately from the send(), the operating is called asynchronous. Non-blocking usually refers to what happens to the receiver. If the receiver tries to read data and there is no data present, what happens? If he blocks until some data is present, the call is blocking. If he returns immediately, with or without and error code, the call is non-blocking. I'm not sure about VxWorks, but Berkley sockets are by default asynchronous. A send() call always returns immediately, regardless of whether the data ever reaches the destination. Oh what fun. The recv() call may block or not, as optionally set on a per-socket basis by the programmer. Valentin - -- "An operating system without virtual memory Valentin Pepelea is an operating system without virtue." Embedded Systems Consultant (415) 346-7105 - Ancient Inca Proverb valentin@netcom.com --------------------------- End of New-News digest ********************** From yfan@spar.ca Fri Nov 29 06:53:12 1996 From: Yibing Fan Date: Fri Nov 29 06:53:15 PST 1996 Subject: socket: synchronous, asynchronous, blocking and non-blocking Hi Everyone, I am confused by recent discussion of asynchronous socket. I've been using TCP and UDP socket in both blocking and non-blocking way, and never questioned myself about socket is synchronous or asynchronous. I had no doubt that these (synchronous and blocking) are two different sets of concept. I can rationalize myself that the TCP socket is synchronous, because message is guaranteed delivery, so some sort of acknowledgement has to be send back to sender. This must be done by layers lower than application. I would guess it is done by TCP/IP layer. For UDP socket I always think it is asynchronous. Am I wrong? Someone please strait me out. Thanks ========================= Yibing Fan yfan@spar.ca Video et Taceo ========================= From selliott@mkc.com.au Fri Nov 29 20:54:51 1996 From: Steve Elliott Date: Fri Nov 29 20:55:10 PST 1996 Subject: Code Coverage tools Does anyone know of any code coverage tools which have been implemented for VxWorks applications? Also we are looing for any test case generation tools which may be available. Steve Elliott ---------------------------------------------------- Steve Elliott, | Voice: +61(2) 9638 4055 | MAYER KRIEG & CO | Fax: +61(2) 9638 6145 | U2, 8-10 Mary Parade | Mobile: +61(418) 236 820 | Rydalmere, NSW 2116 | Email: selliott@mkc.com.au | Australia |