Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!nucsrl!tellab5!laidbak!mcdchg!marcal!ceco!sung From: sung@ceco.ceco.com (Sung Han) Newsgroups: comp.realtime Subject: Re: Summary of opinions and info on realtime kernels (long) Summary: clarifications Message-ID: <577@ceco.ceco.com> Date: 10 Jun 91 18:32:16 GMT Organization: Commonwealth Edison Co., Chicago, IL Lines: 113 Gotta keep the wars going... In article <1991Jun7.181339.25325@ready.eng.ready.com> glenn@ready.eng.ready.com (Glenn Kasten) writes: Ready Sys> The following article was written by Theresa Rickman of Ready Ready Sys> Systems. Ready Sys> ... Ready Sys> 3) You also emphasized that PSOS has global and local event Ready Sys> flags. I as far as I know, PSOS only has local (I am referencing Ready Sys> THEIR sales training material, Jan 1991) and that there is no Ready Sys> reason you can't make a global event flag local to a task anyway. Okay, my mistake - what I meant to say was that in pSOS/pSOS+, one can broadcast a message - i.e., you can wake up all the tasks that are waiting at a message queue by sending a single message, instead of having to send one message per task. Ready Sys> You CAN pass parameters to a task, this is provided as a c-source Ready Sys> application example I was told by a FAE to use a message queue to send parameters to a newly-created task - but this seems rather kludgy to me. I see no good reason why I shouldn't be able to pass parameters to a task when I create it. Ready Sys> that you CAN implement timers with VRTX, this is also provided as a Ready Sys> C-source example. It's just not a part of the kernel because not Ready Sys> everybody needs it. IMHO, I consider time and date functions to be an important part of a real-time system; they're used in several systems in our site. I can't imagine that the overhead of including them would be that large. Ready Sys> 4) also, there is no reason you can't run rtshell from a Ready Sys> station that does not have a local disk. It is described in the Ready Sys> documentation how to do this. The example is perhaps not as Ready Sys> clear as it could be, but the information is there, and it does Ready Sys> work. The local FAE tried to convince me this could be done (running RTShell w/o a local disk); however, he came here on-site to get it working, & couldn't. He also couldn't figure out what the documentation was trying to say on this point. Ready Sys> 5) Mailboxes are NOT SINGLE SLOT MESSAGE QUEUES. Mailboxes Ready Sys> are located in user memory which allows you to define dynamic Ready Sys> per-record semaphores. Thus, by simply allocating a lock Ready Sys> variable as part of a record you now have per-record locking for Ready Sys> that array. This is an extremely powerful feature which both PSOS Ready Sys> and VXworks lacks. Indeed, this does appear to be the case. However, mailboxes could still be simulated using semaphores and shared memory - simply stick the semaphore ID in the area reserved for the mailbox entry, and tasks can contest for the semaphore before accessing the record. True, the semaphore itself won't be in local memory, but the functionality should still be similar. Ready Sys> 6) RTsource will allow you dedicate a window to each task in Ready Sys> the system. Ready Sys> ... Ready Sys> You can set a breakpoint on one processor Ready Sys> and ask RTSource to stop all of the processors when that one Ready Sys> processor hits its breakpoint. Good point - multitask debugging is a strong point of RTSource. XRAY+ and VxGDB normally follow a single task at a time, and don't offer any multiprocessor debugging features (I think). Ready Sys> 8) One closing important point. Ready systems has committed Ready Sys> to protecting our customer's investment in our product. Even Ready Sys> code which customers wrote as early as 1981 is still upwardly Ready Sys> compatible. Our customers never lost their software investment. Ready Sys> PSOS's customers had to completely rewrite their code when PSOS Ready Sys> went to PSOS to PSOS+, and so did VXWorks's customers when they Ready Sys> went from 4.x to 5.0. This is not entirely accurate. The change from pSOS to pSOS+ involved the integration of several new calls, and the renaming of the old system calls. pSOS calls did need to be changed to the new ones, but basically a one-for-one match could be made between the old and new calls. As for the introduction of new system calls, this is a natural effect of evolution. Let's not forget that users also had to learn new system calls in going from VRTX to VRTX32. As for VxWorks, that's a different story. They had been pitching their "use-any-kernel-you-want" approach in version 4.0, but that ability appears to have disappeared in version 5.0. Perhaps someone will correct me, but it appears that you can no longer use the VRTX/VRTX32 or pSOS kernels within VxWorks, and are limited to using their WIND kernel instead. If this is true, I'd be interested in hearing what people who had used a third party kernel in VxWorks did when they moved to version 5.0. Ready Sys> -- Ready Sys> Glenn Kasten Ready Sys> Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 Ready Sys> glenn@ready.com (408) 522-7357 >> Remember, I have no affiliation with any of the companies listed here, and >> the opinions listed here are my own, and do not necessarily reflect those of >> my employer. -- ! Sung Han @ Commonwealth Edison Corp., Chicago, Illinois ! ! sung@ceco.ceco.com, or ! uunet!ceco.ceco.com!sung