Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!gate.ready.com!gate.ready.com!glenn From: glenn@ready.eng.ready.com (Glenn Kasten) Newsgroups: comp.realtime Subject: Re: Summary of opinions and info on realtime kernels (long) Message-ID: <1991Jun7.181339.25325@ready.eng.ready.com> Date: 7 Jun 91 18:13:39 GMT Sender: glenn@ready.eng.ready.com (Glenn Kasten) Organization: Ready Systems Lines: 114 The following article was written by Theresa Rickman of Ready Systems. I am posting it to the news on her behalf. This should keep the kernel wars going :-) Glenn Kasten Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 glenn@ready.com (408) 522-7357 ******************************************************** To : Sung Han and comp.realtime From : Theresa Rickman Ready Systems chambers@ready.com I am a field engineer for Ready Systems. I would like to add the following corrections/information to your comparision : 1) Ready systems does have support for multiple platforms. You suggest that the only host we run off of is SUN 3/4. We also support PC/DOS, VAX/VMS, DECstation/Ultrix and will soon be supporting HP as well. Each platform has source-level debugging and most of the suite of Velocity tools available. The compiler supported on the all of the platforms is the Microtec compiler. On the SUN you may use either the Microtec or the Oasys compiler. All the target components are available on all platforms. Ethernet downloading is not provided as part of the PC platform. 2) You seemed to emphasize the "Kernel Jump Interface" that PSOS has. Ready Systems also has a kernel jump interface, and as has this interface since 1981. This allows you to target VRTX from any language/host/compiler. You can run tasks written in different languages on the same processor, and use VRTX to communicate between them. All of our components (ie, TNX, MPV, RTSCOPE, IFX) are also language independent. The only thing that ties you to C or a particular compiler is the host-resident tools. If you want to use our source-level debugger and ethernet download tool, you will have to run on host enviroment we support. However, there is nothing preventing you from using VRTX from another host enviroment and using thier source-level debug tools. We also have ARTX, which is a kernel for ADA applications, and 5 Ada vendors currently targeting their compilers to support this runtime (Verdix, Alsys, Tartan, Meridian, and SD). 3) You also emphasized that PSOS has global and local event flags. I as far as I know, PSOS only has local (I am referencing THEIR sales training material, Jan 1991) and that there is no reason you can't make a global event flag local to a task anyway. You CAN pass parameters to a task, this is provided as a c-source application example, that you CAN implement timers with VRTX, this is also provided as a C-source example. It's just not a part of the kernel because not everybody needs it. 4) also, there is no reason you can't run rtshell from a station that does not have a local disk. It is described in the documentation how to do this. The example is perhaps not as clear as it could be, but the information is there, and it does work. 5) Mailboxes are NOT SINGLE SLOT MESSAGE QUEUES. Mailboxes are located in user memory which allows you to define dynamic per-record semaphores. Thus, by simply allocating a lock variable as part of a record you now have per-record locking for that array. This is an extremely powerful feature which both PSOS and VXworks lacks. 6) RTsource will allow you dedicate a window to each task in the system. You have the flexibility to halt either one or all of the tasks in the system. You can also look at structures and local variables for a task while the task is running. You can also modify memory (at the source code level) while the system is running. Each window is tied to a particular target, and a particular task. Thus, you can use one RTSource session to talk to several different processor boards which can be located in one chassis, or spread across chassis. You only need one Ethernet connection into the chassis to source-level debug all of the boards in the chassis. You can set a breakpoint on one processor and ask RTSource to stop all of the processors when that one processor hits its breakpoint. (This is also an extremely powerful feature which I believe neither VXWorks or PSOS has.) 7) You're right, RTsource is currently sunview. However, we will have XWindows/Motif by the end of the year. 8) One closing important point. Ready systems has committed to protecting our customer's investment in our product. Even code which customers wrote as early as 1981 is still upwardly compatible. Our customers never lost their software investment. PSOS's customers had to completely rewrite their code when PSOS went to PSOS to PSOS+, and so did VXWorks's customers when they went from 4.x to 5.0. Our next generation software, which we have been working on the past 3 years, is already upwardly compatible. We are committed to never cutting our customers off. If you have any questions or would like more information on our products, please don't hesitate to call me. Sincerely, Theresa L. Rickman Ready Systems 7855 Walker Drive Greenbelt, MD 20770 301-345-8700 chambers@ready.com -- Glenn Kasten Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 glenn@ready.com (408) 522-7357